Re: [Talk-de] Wiederherstellen eines partiellen Änderungssatzes
On 13/04/12 13:18, Andre Joost wrote: Am 13.04.12 11:31, schrieb Philippe Rieffel: Hallo zusammen, ich habe eine Frage bezüglich der Wiederherstellung gelöschter Objekte. Vor einigerzeit haben wir in Brasilien mit Brasilianern vor Ort eine Region gemappt, um ihnen OpenStreetMap näher zu bringen. Vor kurzem hat einer der Brasilianer mich angeschrieben und darauf hingewiesen, dass alles, was wir in einer bestimmten Region gemappt haben, gelöscht wurde. Es geht um folgendes Changeset: http://www.openstreetmap.org/browse/changeset/7988248 Gelöscht wurde das ganze vom Nutzer http://www.openstreetmap.org/user/Fernanda%20Ren%C3%B3 der leider nicht auf meine Nachfragen antwortet. Das Ganze geschah im Rahmen einer größeren Löschaktion von ihm: http://www.openstreetmap.org/browse/changeset/9129922 So weit wie mein Portugiesisch noch reicht (Changeset Kommentar: As ruas deletadas serão refeitas em breve.) scheint es ihm um die Entfernung von Objekten zu gehen, die sowieso bald verschwinden (License Change? in 2011?) und neu gemacht werden müssen. Nun frage ich mich, wie ich unser Changeset wiederherstellen kann, ohne das ganze, wesentlich umfangreichere Changeset des Nutzer reverten zu müssen. Die Begründung ist IMHO Blödsinnig, weil die meisten Elemente in eurem Changeset Version 1 waren. Mit dem undelete Plugin von JOSM kann man Objekte wiederherstellen. Habe es in letzter Zeit aber nicht gebraucht/getestet. Viel Erfolg fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiederherstellen eines partiellen Änderungssatzes
On 13/04/12 14:09, Philippe Rieffel wrote: Mit dem undelete Plugin von JOSM kann man Objekte wiederherstellen. Habe es in letzter Zeit aber nicht gebraucht/getestet. Danke für den Hinweis, aber damit kann ich nur einzelne Punkte wiederherstellen, selbst wenn ich Linien wiederherstellen möchte, stellt er nur die Nodes aus denen die Linie besteht wieder her und leider nicht die entsprechenden Tags. Das ist mir für ~120 nodes zu viel Arbeit. https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Reverter#Usage - partial revert 1. Kompletten Changeset herunterladen 2. Linien auswählen 3. Suchen (Strg+F): selected | child (selected type:way) 4. Auswahl hochladen. Für Linien und Punkte sollte das funktionieren. Bei Relationen gibt es noch Probleme. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] etwas übertrieben ?
On 12/04/12 10:20, tumsi wrote: So wie das auf dem Luftbild aussieht, ist das eine große Parkplatzfläche, die nicht (baulich) unterteilt ist. Von daher würde ich das auf jeden Fall in einer Fläche zusammenfassen. Die Wege dazwischen gehören ja auch zum Parkplatz dazu. Original-Nachricht Betreff: [Talk-de] etwas übertrieben ? Datum: Thu Apr 12 2012 10:10:44 GMT+0200 Von: Jan Tappenbeck o...@tappenbeck.net An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org hi ! auch wenn wir nicht für die Renderer taggen - aber sollten solche Parkplatzflächen wie bei sky http://www.tappenbeck.net/osm/maps/deu/index.php?id=1041zoom=18lat=53.85907lon=10.66955layers=BFTlang=de nicht zusammengefaßt werden ? Soviel ich weiß gibt es schon ein proposal welches sich auf das eintragen von einzelnen Stellplätzen/Parkplätze bezieht und mit amenity=parking zusammen funktioniert. Ziel ist es zb Frauen und Behinderten Parkplatze im großen Parkplatz zu finden/bezeichnen. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Seite http://josm.openstreetmap.de/ nicht erreichbar ?
JOSM hat einen neuen Server erhalten und ist am umziehen. Sollte wieder funktionieren. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nodes händisch oder über OpenAdresses/Wheelmap erfasst führen zu Redundanz mit Flächenobjekten an dieser Stelle!?
On 07/04/12 17:00, aighes wrote: Ich sehe da eher einen Übergang. Von Punkt zu Fläche. Ich kann nur zur wheelmap sagen, dass sie genau dieses Problem mittlerweile im Griff haben sollten. Das ist halt das große Problem, wenn ein Editor dem Nutzer nicht in die Daten schauen lassen möchte, weil er meint, dass sei zu kompliziert für ihn. Dann muss man sehr viel Aufwand reinstecken, dass man diese Kontrolle einem Algorithmus überlässt. Yapis geht da einen anderen Weg und zeigt dem Nutzer immerhin vor dem Hinzufügen neuer Daten eine Übersicht aller vorhandenen Daten an. Überzeugt bin ich von keinem Editor, der nicht die Daten so visualisiert, dass man als Nutzer erkennen kann, ob die Daten schon vorhanden sind oder nicht. Da verzichte ich lieber auf einige POIs. +1 Ich hoffe solche ein Editor wird gesperrt bis der Bug behoben ist und dass er seinen Müll auch wieder aufräumt Eine andere Sache sind große Flächen und Multipolygone. Hier braucht man manchmal eine Punkt um den Namen zu setzten. Leider gibt es so eine Punkt mit eigener Rolle bisher nur bei boundary-Relationen, welche in D nicht verwendet werden. Somit setzte Mapnik in meiner Gegend fleißig Namen. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ältere JOSM Version
Am 08.03.2012 13:04, schrieb Andre Joost: Am 08.03.12 12:26, schrieb Walter Nordmann: Wolfgang Wienke wrote nach dem die letzte tested-Version (5047) bei mir nicht läuft: Kann man irgendwo ältere Versionen herunter laden? Bitte bedien dich: http://josm.openstreetmap.de/download/ Aber wirf vorher C:\Dokumente und Einstellungen\Benutzername\Anwendungsdaten\JOSM (oder wie das bei dir heisst) komplett weg, sonst bekommst du mit Sicherheit noch mehr Probleme. Bitte Versuch auch 5047 mal mit einem neuen bzw leeren JOSM-Verzeichniss zu starten und melde jegliche Fehler im JOSM-Trac ! Ansonsten ist es für die Entwickler schwer Fehler abzustellen. Danke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: zwangsweise horizontal / vertikal-Zeichnen
Am 24.01.12 schrieb Jo winfi...@gmail.com: 2012/1/24 Frederik Ramm frede...@remote.org Hallo, On 01/24/12 08:27, Andre Joost wrote: Hier hat es wohl jemand ein wenig übertreiben: http://www.openstreetmap.org/?**lat=51.18219lon=7.74657zoom=** 17layers=Mhttp://www.openstreetmap.org/?lat=51.18219lon=7.74657zoom=17layers=M Die Häuser stehen definitiv nicht in Reih und Glied. Und vermutlich sind sie auch nicht alle gleich gross ;) Ja, da hat jemand die Duplicate Funktion entdeckt. Copy + Paste wohl eher, sonst muß man noch jedes objekt verschieben. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
Am 15.07.2011 13:58, schrieb Henning Scholland: Hallo Wo ist denn der Mehrwert? Der Nutzer will wissen, bis wann er heute einkaufen gehen kann und nicht, bis wann er es vor x-Tagen einkaufen gehen konnte. Ob x nun vor 5 Tagen war oder vor 100 Tagen war ist ihm egal und macht auch ansonsten keinen Unterschied bei der Genauigkeit, weil sich solche Eigenschaften jeden Tag ändern können. Der Ansatz, das Objekt mit zusätzlichen Tags komplexer zu machen ist kontraproduktiv. Was ihr möchtet sind aktuelle Infos. Die erhält man, wenn viele Mapper sich daran beteiligen und Veränderungen eintragen. Diese Mapper gewinnt man, wenn diese die Infos einfach eintragen können. Wenn diese Leute im Editor dann zig Tags vorfinden, deren Bedeutung sie nicht kennen, lassen sie das Editieren aus Angst etwas kaputt zu machen eher sein. Eine tolle Sache um euer Ziel zu erreichen wäre bspw. ein Routenplaner, der entlang der Route ein paar Punkte vorschlägt, die man überprüfen kann und man dafür Punkte für einen Highscore erhält. Je mehr Leute mitmachen desto eher fallen Veränderungen auf. Die Powermapper alleine können das nicht leisten, schon gar nicht flächendeckend. +1 Alles andere bläht nur die History auf. Ich kenne Ecken, wo die Läden fast monatlich wechseln nur wann ist nicht abzusehen. Das kann Morgen oder in fünf Tagen bzw gestern sein. Andere Stellen verändern sich über Jahre nicht. Wenn schon eine Datenbank, dann eine eigene und nicht OSM. Danke fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erfassen von Wanderwegen
Am 12.07.2011 10:09, schrieb hike39: Hast Du das schriftlich und kannst Du das bitte im wiki veröffentlichen ! Hier der Schriftverkehr: Sehr geehrter Herr [hike39], beiliegend erhalten Sie GPS-Tracks der Wanderwege, die vom Naturpark Soonwald-Nahe betreut werden. Die Daten wurden von mir auf der Grundlage von Alpstein-Karten am Bildschirm digitalisiert oder bei einer MTB-Befahrung aufgezeichnet. Unsere Wege finden Sie auch bei Outdooractive unter http://www.outdooractive.com/de/quelle/traegerverein-naturpark-soonwald-nahe-e-v/2687116775237173418/. Bei Abweichungen gibt die Outdooractive-Variante den aktuelleren Stand wieder (Erfassung 01/2011). Sie dürfen alle Tracks gerne im Rahmen des Openstreetmap-Projektes nutzen. Meine Anfrage bei Hrn. Rohr: ... 2) Sie haben mir ja dankenswerterweise viele Tracks zur Verfügung gestellt. Dürfte ich Ihre Erlaubnis diese für OSM zu nutzen der Comunity mitteilen um die Erfassung zu beschleunigen? ... Seine kurze Antwort darauf: zu 2) ja Mit freundlichen Grüßen Marco Rohr Ich glaube dies ist ausreichend, oder? Ja, das ist ok ! Es handelt sich um 8 Routen sehe ich das richtig oder hast Du mehr Daten erhalten ? Super ist wenn Du die beiden Emails mit den Daten, einer kurzen Beschreibung und einer Liste über den Verlauf des Imports (bereits importierte Wege/Bereiche) auf eine Wiki Seite stellst. Danke fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Josm hat ne Macke
Am 12.07.2011 14:57, schrieb Steffen Heinz: Josm hat im Moment ne Macke und stürzt dauernd ab: Die Entwicklungsversion immer die Stabile ab und an. so jetzt mal ne Frage: wie bringe ich Josm bei die Nebendaten also Pluggies und co im gleichen Ordner abzulegen wie Josm? Für was soll das gut sein ? java -Djosm.home=[Pfad]/.josm[-tested/latest] -jar [Pfad]\josm[-tested/latest].jar in der Konsole ausführen. (nein, wie heißt das Ding bei Windows ?) Befehl ist auf jeden Fall: cmd (Windows 7, hab heute ne halbe Stunde nach denen gesucht) Was ist den an der Windows 7 Suchfunktion kaputt ? Oder hast Du sämliche eingebunden Serverfestplatten durchsuchen lassen ? Ich vermute mal das die Stabile und die Entwicklungsversion sich in die Quere kommen Generell solltest Du nicht von latest nach tested zurückwechseln. Das hat schon öfter Problem bereitet. Am besten du verwendest separate Einstellungen, in dem Du jeweils eigene Ordner für latest und tested verwendest. Befehl dafür siehe oben. Verwende kein Windoof, aber hoffe ich konnte Dir trotzdem helfen. Viel Erfolg fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesucht: Straßenstücke in Relation zusammenfassen
Am 11.07.2011 12:31, schrieb Walter Nordmann: Georg Feddern-2 wrote: Trotz eigentlicher Relationale Datenbank Affinität wähle ich hier für mich lieber die robustere Einzeldatenhaltung in solch einem offenen Datenbank-Projekt. Mir gings genau so: ich war mal ein Riesen-Fan von AssociatedStreet und hab das energisch verteidigt. Passte ja auch prima ins Relationale Datenmodell. Doch die Praxis hat mich überzeugt. Das kein Editor diese Relationen bisher richtig unterstützt ist doch kein Datenmodellproblem sonder eher stuktureller Art. Selbst in JOSM braucht man zusätzliche Plugins. Ich habe noch nicht alle getestet, aber zumindest terracer kann nur neue Relationen erstellen, findet aber keine schon Existierenden. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fitness-Geräte-Ansammlung
Am 11.07.2011 14:29, schrieb Kay Drangmeister: Hi, Am 11.07.2011, 12:42 Uhr, schrieb Jan Tappenbeck o...@tappenbeck.net: in Parks habe ich immer mehr so Fitness-Geräte gesehen. Vermutlich so: http://wiki.openstreetmap.org/wiki/Tag:route%3Dfitness_trail Ist zwar nicht ganz identisch, aber meist sind es ja auch Stationen. +1 Auf der Diskussionsseite gibt es schon ein paar Beispielbilder. Ich finde es berechtigt analog zu Spielplätzen auch Fitnessgeräte zu taggen. Kann ja mit: leisure=exercise_station exercise=[Gerätename] sport=exercise (sport=fitness gibt es auch) mal anfangen. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 10.07.2011 02:29, schrieb Garry: Am 08.07.2011 15:31, schrieb Tobias Knerr: rd hab ich mich jetzt freiwillig gemeldet?) Sinnvoller wäre es, erst einmal der unglue-Funktion beizubringen, auch bei mehreren ausgewählten Knoten zu funktionieren. Das würde die Aufgabe schon erheblich vereinfachen. Tut sie doch? Macht aber auch nicht wirklich spass damit - einmal falsch geklickt und man die 50Punkte die man zum trennen ausgewählt hat erneut anklicken. Oder gibt es da auch so was wie ein undo um die letzte Auswahl wieder zu selektieren? Ja, enthalten in utils2 unter Auswahl. (Ctrl+Shift+Z) Zusätzlich noch einige andere Funktionen, die für das Probleme ganz nützlich sind, aber ich vergesse sie auch immer wieder. Viel Spaß damit fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 10.07.2011 03:01, schrieb Stephan Wolff: Am 07.07.2011 09:46, schrieb Florian Lohoff: On Thu, Jul 07, 2011 at 12:05:13AM +0200, Stephan Wolff wrote: Moin! Am 06.07.2011 14:19, schrieb Florian Lohoff: Nein - es gibt kein ausreichend. Jeder darf so viel und so detailreich mappen wie er will solange er nicht dadurch den anderen die nutzung kaputt macht. Aber woran erkennt ein Mapper, ob nicht irgendeine Nutzung kaputt geht oder schwerwiegende Nachteile hat? Es faengt mal da an wo du Objekte entfernst und gegen irgendwas anderes ersetzt. Um bei meinem Beispiel zu bleiben - Straße als Linie oder als Flaeche? Wenn ich die Linie einfach drin lasse ZUSAETZLICH zur Flaeche mache ich nichts kaputt. Bei Flüssen mit zusätzlicher Uferlinie sehe ich auch keine Probleme. Für Straßen wäre ein entsprechendes Konzept möglich, aber für mich nicht sehr nutzbringend. In fast allen anderen Fällen muss man das bestehende Objekt löschen oder umbauen. Selbst wenn man scheinbar nur Neues hinzufügt (etwa Fußwege als ways parallel zur Straße) gibt es oft Nachteile (etwa, wenn ein Router nicht erkennen kann, wo ein Fußgänger die Straßenseite wechseln kann und einen Umweg über die nächste Kreuzung berechnet). Einzelne hinzugefügte POIs sind meist unproblematisch. Sobald man ein bestehendes Objekt in mehrere Einzelteile zerlegt, gibt es meist auch Nachteile. Hast du ein Beispiel? Direkt darunter steht doch eines. Wie könnte man z.B. bei einer Bushaltestelle mit Bank und Unterstand die Lage der drei Einzelobjekte (Haltestellenmast am Fahrbahnrand, Bank hinter dem Fußweg, Unterstand 5 m in Fahrtrichtung) abbilden ohne eine bestehende Auswertung zu schädigen? Was wird denn da heute ausgewertet? Eine gute Frage. Wer kennt schon alle OSM basierten Anwendungen und kann sicher sein, dass eine Information bislang NICHT verwendet wird? Der bus_stop - Aber den kann ich doch auch dem Masten abbilden oder? Den Unterstand als building und die bench da drin moeglicherweise. Bislang ist die Bushaltestelle als highway=busstop, shelter=yes, bench=yes erfasst. Will man die relative Lage des Unterstands zum Haltestellenmast aufnehmen, muss man ein weiteres POI (eher amenity=shelter als building) erstellen. Um Doppelerfassung zu vermeiden, muss man shelter=yes löschen. Um trotzdem die Zuordnung des Unterstands zur Haltestelle zu erhalten, kann man eine Relation erstellen. Dann müssten aber alle Programme, die bislang highway=busstop, shelter=yes auswerten, an die neue Variante angepasst werden. Will man auch noch die Lage relativ zum Rad- und Fußweg darstellen, muss man diesen auch als Weg erstellen (mit allen Problemen der Linienbündel). Bei einem Haltestellenmast zwischen Radweg und Fußweg müsste man dort beide Wege trennen. All das wäre nicht falsch und würde einige bislang nicht vorhandene Zusatzinformationen liefern, aber m.E. überwiegen die Nachteile. Da sind wir doch schon angekommen ! Deshalb brauchen wir auch schnell eine Lösung für Lienenbündelung sonst gehen wir noch in den highway=footway footway=sideway unter. Soll ich da nun beide Gehwege oder die Straße in eine route=foot Relation aufnehmen. Identisches gilt für separate Fahrradwege und route=bicycle Ich wollte nur davor warnen, mehr Details mit einer besseren oder richtigeren Darstellung gleichzusetzten. Man sollte immer Vor- und Nachteile der Datenmodelle abwägen. Generelle sind mehr Details ein großes Plus, nur sollte man sich auf ein funktionierendes Modell einigen. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 10.07.2011 19:01, schrieb Peter: Am 10.07.2011 18:35, schrieb fly: Am 10.07.2011 02:29, schrieb Garry: Am 08.07.2011 15:31, schrieb Tobias Knerr: rd hab ich mich jetzt freiwillig gemeldet?) Sinnvoller wäre es, erst einmal der unglue-Funktion beizubringen, auch bei mehreren ausgewählten Knoten zu funktionieren. Das würde die Aufgabe schon erheblich vereinfachen. Tut sie doch? Macht aber auch nicht wirklich spass damit - einmal falsch geklickt und man die 50Punkte die man zum trennen ausgewählt hat erneut anklicken. Oder gibt es da auch so was wie ein undo um die letzte Auswahl wieder zu selektieren? Ja, enthalten in utils2 unter Auswahl. (Ctrl+Shift+Z) Das ist da. Zusätzlich noch einige andere Funktionen, die für das Probleme ganz nützlich sind, aber ich vergesse sie auch immer wieder. Da find' ich nix passendes: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/UtilsPlugin2 Ist nicht gepflegt. Link zu JOSM habe ich repariert http://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2 http://josm.openstreetmap.de/wiki/Help/Action/MiddleNodes Leider ist nur die Selektion-Hälfte beschrieben. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Redundanz?
Am 10.07.2011 20:07, schrieb Peter: Am 10.07.2011 19:22, schrieb fly: Am 10.07.2011 19:01, schrieb Peter: Am 10.07.2011 18:35, schrieb fly: Am 10.07.2011 02:29, schrieb Garry: Am 08.07.2011 15:31, schrieb Tobias Knerr: [Gemeinsame Konten in mehreren Wegen auflösen] Zusätzlich noch einige andere Funktionen, die für das Probleme ganz nützlich sind, aber ich vergesse sie auch immer wieder. Da find' ich nix passendes: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/UtilsPlugin2 Ist nicht gepflegt. Link zu JOSM habe ich repariert Stimmt, das ging was ins Leere. http://josm.openstreetmap.de/wiki/Help/Plugin/UtilsPlugin2 http://josm.openstreetmap.de/wiki/Help/Action/MiddleNodes Leider ist nur die Selektion-Hälfte beschrieben. Das man damit Wege trennen kann, das fällt einem so wohl kaum auf. Sowas 'Usecase' müsste an ganz anderer Stelle beschrieben sein. Gibt es da schon ein Eckchen in einem Wiki wo Tipps und Tricks nett gruppiert beschrieben sind? s.u. Die Funktion reicht ja, unglue macht den Rest. Aber es wählt halt alle Nodes zwischen zwei gewählten aus, die müssen nicht alle zu beiden/mehreren Wegen gehören. ... probier ... Ok, un_G_lue kommt damit doch zurecht. Ich fand meine Lösung von der Semantik netter, vielleicht landet es ja mal in einem Plugin. Wenn wem noch weitere Anwendungen dazu einfallen noch eher. Unter http:///josm.openstreetmap.de/wiki/Help ist noch jede Menge Platz für all Deine Vorschläge. Gerade was Howtos und deutsche Übersetztungen angeht fehlt viel bzw muß überarbeitet werden. Häufig fehlen auch nur Links zu den Informationen. Leider sind bei JOSM generell nicht so viele Menschen am Werk und auch was das Wiki angeht sind es nicht viel mehr als die Entwickler selber. Wäre schön wenn Du deine Erfahrungen mit uns teilst. Danke fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verschachtelte und auf einander aufbauende Barrieren
Hey Habe auf @tagging nachgefragt aber bisher keine Antwort erhalten. Wie tragt Ihr eine Stützmauer (retaining_wall) mit einem aufgesetzten Zaun und einer Hecke ein ? Habe gerade kein Bild da aber gestern erst gesehen. Mein Ansatz wäre wohl eine Linie und 2 Relation um alles einzeln mit layer zu erfassen. Wie sieht es mit einer Türen in einem Tor aus ? Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 06.07.2011 18:29, schrieb fla...@googlemail.com: http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map/Gebiete Ab morgen gibt es alle 2-3 Tage von allen dort eingetragenen Gebieten downloadbare Listen. Klasse ! Vielen, vielen Danke für diesen schnellen Service. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 09.07.2011 00:44, schrieb fla...@googlemail.com: Dann tragt mal munter Gebiete ein !!! Wenn Du so scharf drauf bist, dann sollten wir das auch außerhalb von @talk-de bekanntmachen. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erfassen von Wanderwegen
Am 07.07.2011 11:35, schrieb hike39: Nach einer Streckenwanderung im Raum Bad Kreuznach - Bad Dürkheim bin ich gerade dabei, die dabei entdeckten Wanderwege zu erfassen. Auf eine Anfrage beim Trägerverein Naturpark Soonwald-Nahe e.V. Geschäftsstelle Bad Kreuznach haben wir die Erlaubnis die von Ihnen betreuten Wanderwege in OSM einzupflegen. Deren Wege findet man unter http://www.outdooractive.com/de/quelle/traegerverein-naturpark-soonwald-nahe-e-v/2687116775237173418/. Hast Du das schriftlich und kannst Du das bitte im wiki veröffentlichen ! Vielen Dank. Da ich zur Zeit sehr mit anderen Dingen beschäftigt bin, könnte ich dabei Hilfe gebrauchen. Wenn das rechtlich gesichert ist, ist eine Wikiseite zur Organisation wohl angebracht. Weiterhin habe ich teilweise schon die Rundwanderwege KHx rund um Bad Kreuznach eingepflegt. Allerdings sind manche Pfade noch nicht in OSM. Wenn jemand in dieser Gegend trackingmäßig tätig ist, bitte ich ihn, die Routen zu vervollständigen. Ein highway=road mit entspechenden note- und source-Tags ist auch möglich. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Netter Artikel auf Heise
Am 01.07.2011 18:36, schrieb Jacques Nietsch: Hey Jacques Kann sein, aber nicht jeder hier kauft die CT, insofern war mein Posting hoffentlich nicht völlig sinnfrei. +1 Danke, da werde ich mal bei nem Freund nachlesen. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der AIOTM (All-in-One-TileManager)
Am 04.07.2011 11:37, schrieb Peter Wendorff: wenn sich an den einzelnen Kacheln durch das neu-zusammensetzen zu einer Karte nichts ändert, kann man doch auch sich überschneidende Gebiete definieren; wäre vielleicht teilweise ganz praktisch. Bin eh der Meinung, daß politische Grenzen nicht gerade die besten Grenzen für Karten sind und wir bei OSM da zumindest ein bißchen großzügiger sein können. Für das Zusammenfügen einzelner Regionen mag es ja sinnvoll sein direkt nach der Grenze zu Enden, für eine AIO ist es wohl eher unpraktisch. Da ist es wohl sinnvoller sich nach Datengrößen zu richten. Zum Beispiel benötige ich bei Wanderungen bzw Kulturreisen im Dreiländereck (F,D,CH) zur Zeit die Europa-Karte (bzw F,BWü und Ch zusammen), ansonsten ist vor dem ersten Gebirgekamm (Vogesen,Schwarzwald,Jura) Schluß. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Operator bei Bundesstraßen und Autobahnen
Am 01.07.2011 07:57, schrieb Wolfgang: Hallo, Am Freitag 01 Juli 2011 07:14:19 schrieb Christian H. Bruhn: Hallo! Es gibt in Deutschland ja einige Streckenabnschnitte von Bundesstraßen (z.B. Herrentunnel in Lübeck) und Autobahnen (z.B. A1 zwischen Hamburg und Bremen) die von privaten Unternehmen betrieben werden. Also kommt an diese Streckenabschnitte ganz klar ein entsprechender Operator. Nun gibt es ja auch die Sammelrelationen für Autobahnen bzw. Bundesstraßen; dort steht aber als Operator 'Bundesrepublik Deutschland' drin. Für die ganze Strecke ist das aber falsch. Wie soll man nun vorgehen? Die Information aus der Relation rausnehmen und alle Streckenabschnitte taggen? Oder der Regel folgen, dass das Spezielle das Allgemeinere verdrängt / überlagert. Ins Wiki eintragen und gut ist. +1 Ja das fehlt noch. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] prüfen von Relationsvollständigkeiten
Generell halte ich den Versuch für zu simpel. Ich begegne immerwieder Relationen bei denen ein kleines Teilstück fehlt. Sowas würde über die Distanz alleine nicht erkannt. Am 29.06.2011 13:17, schrieb M∡rtin Koppenhoefer: Am 29. Juni 2011 09:01 schrieb André Joost andre+jo...@nurfuerspam.de: Am 29.06.11 08:40, schrieb Hermann Peifer: Bei manchen Fahrrad-Routen, die ich gerade aufnehme koennte man locker auf 100% der ausgewiesenen Laenge kommen, weil die Route teilweise beidseitig von secondary (u.ae.) highways verlaeuft, z.B. http://osm.org/go/0NWjZsM0?relation=29135 ja, irgendwo hat alles seine Grenzen. +1 Ja, da sind wir schon wieder bei der Fahrspurproblematik. Woher weiß ich denn, daß der separat eingetragen Radweg an der Straße (name=*) entlangführt ? Ich zeichne deshalb auch immer nur eine Fahrtrichtung ein, und überlasse es dem Nutzer, die STVO-konforme Fahrbahnteilfläche zu nutzen. Wenn man sehr penibel ist kann man auch ähnlich den Bus-Relationen eine Hin- und eine Rückrichtung machen. oder einfach back-/forward als Rolle richtig setzten. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern und Zufahrt
Am 28.06.2011 19:18, schrieb Steffen Heinz: Am 28.06.2011 17:42, schrieb Frank Sautter: ich hab mal im WIki nachgeschaut, bei Hausnummern, aber entweder steht dort nichts oder ich kapier das nicht. im Key:addr proposal stehts noch drin und ich habe das auch schon verwendet. geht über eine roadAccess relation. ob das ausgewertet wird steht auf einem anderen blatt. ist ja das Problem: ich verstehs nicht. Mein englisch ist nicht weit her. Auch beim Fachvokabular hängts... Wäre nett wenn mir das wer (per Email) ausführlich erklären könnte. Was verstehst Du denn nicht ? https://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Angabe_einer_besonderen_Zufahrt ach noch was: sollen Zufahrten zu Häusern mit dem Straßennamen der Straße versehen werden? Wenn das nur private Zufahrten sind (highway=service): Nein. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder für JOSM
Am 25.06.2011 00:27, schrieb Markus: Ich bin grad dabei, eine Hilfe für JOSM zu schreiben. Wo findet man eine deutschsprachige Anleitung, wie man Luftbilder zum Abmalen benutzt? Wo findet man eine Liste mit den URLs? Danke, Markus Wo willst Du die Hilfe den veröffentlichen ? (JOSM, OSM oder wo ganz anderes) Um in einem Gebiet die gleichen Anpassungen der Luftbilder zu verwenden, gibt es den Versuch eine Versatzserver zu benutzen. Findest Du in den Einstellungen für Hintergründe (Imagery). Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pluggie für Häuser
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 24.06.2011 10:52, schrieb Steffen Heinz: Am 23.06.2011 21:25, schrieb M∡rtin Koppenhoefer: Am 23. Juni 2011 20:47 schrieb Steffen Heinzeifelhu...@gmx.de: gäbe es noch ne bessere idee? ich muss so bei jeder straße halt die xml datei verändern ja, nimm lieber die originale Version, die standardmäßig in den Presets dabei ist: item name=Addresses icon=presets/addresses.png type=node,way,closedway link href=http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema; sorry, ich hab keine Ahnung davon :(nachteil: ich muss anscheinend jedesmal alles neu ausfüllen, bei meiner Simpelvariante gehts schneller weil schon alles bis auf die Hausnummer ausgefüllt ist Ich benutze dafür die associatedStreet relation und setzte an die Häuser nur die Hausnummer. Wenn ich dann eine neue Relation brauche, klone ich die alte und muß nur name= und eventuell addr:postcode anpassen. Das Terracer-Plugin hat auch noch einige kleine Funktionen für Hausnummern. cu fly -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk4EZQEACgkQHJwlxKzMjpZDrgCZAZA05t/Z804eUUrAo/hfIgtF OSoAmwfcNrlkmooUIdDUYEEFQJVOU35t =u1IJ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 1st Proposal: Kickerkneipe (sport=table_soccer)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 22.06.2011 23:07, schrieb RalfGesellensetter: http://wiki.openstreetmap.org/wiki/Proposed_features/Table_soccer ist mein erster Versuch eines Proposals. Bitte seid nachsichtig und gebt mir Tipps, wenn etwas fehlt. Du solltest bei jedem Proposal eine mail an tagging@ schreiben, ansonsten könnte es aus formalen Gründen abgelehnt werden. Auch erreicht man dadurch auch internationale Aufmerksamkeit. Gruß fly -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREIAAYFAk4EaGAACgkQHJwlxKzMjpb9RACfQdE0Q7nGFsOIvRxZhTmbuwHI izkAn2ftRbFOLzC5SfTCyU4teeu+SQQR =1AHX -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:zone
Hi Zur allgemeinen Diskussion: 1. Es gibt wohl Klärungsbedarf bei diesem Tag. (-Mailing-Listen) 2. Massenedits sind ein Problem. 3. Erste schritt sollte immer eine Mail an den/die BenutzerIn sein, damit keine Streits - Kämpfe entstehen. Damit käme man wieder zu 1. Ich finde es nicht gut Menschen an den Pranger zu stellen und die Mailingliste mit Problemen zu konfrontieren, welche erstmal persönlich geklärt/erörtert werden können. Wenn dann noch olle Kamellen aus der Kiste gegraben werden, werde ich als Leser wütend. Ich hätte erwartet, daß Ihr beide diesem Problem erst einmal privat kommuniziert, anscheinend kennt Ihr Euch ja schon. Auf jeden Fall, wäre die einzige vernünftig Mail an diese Mailingliste eine mit Titel Uneinheitliche Werte für source:maxspeed mit Erklärung der Problematik. Am 22.06.2011 11:04, schrieb M∡rtin Koppenhoefer: Am 22. Juni 2011 03:55 schrieb phobie omlists.pho...@safersignup.com: Was das taggen von Fahrradstraßen mit highway=cycleway an geht: Soweit ich mich erinnern kann ging es vor 2 Jahren um 2 Fahrradstraßen in Kiel. Ich hatte das Tagging aber schnell wieder aufgegeben, weil es Konsens ist, dass highway nur den Ausbauzustand und nicht die Nutzung beschreibt. highway sollte eigentlich die Verbindungswichtigkeit (bei allgemeinen Straßen) bzw. den rechtlichen Status (z.B. bei Fuß-/Fahrrad-Wegen / Tracks, Autobahnen, etc.) wiedergeben. Der Ausbauzustand wird mit tags wie lanes, surface, tracktype, width festgehalten. Leider gibt es bis heute keinen Tag für Fahrradstraßen und das Rendering ist bis heute unbefriedigend. +1, ich war schon immer für highway=cycleroad (o.ä.) aber bisher (=in den letzten Jahren) war die Mehrheit dafür, das nicht zu machen. das gehört in eine zusatz tag analog zu motorroad=yes. Siehe auch: http://wiki.openstreetmap.org/wiki/DE:Bicycle_road highway=living_street würde ich auch als Unfall definieren und in highway=* (meist residential) und living_street=yes konvertieren ! Ich setzte immer zusätzlich ein living_street=[highway] (residental). Zu tram: Ich kenne bis heute keine bessere Möglichkeit um zu beschreiben, das Bahnschienen in der Straße verlaufen. Ist zwar nicht erlaubt funktioniert aber mit railway=* + highway=* an einer Linie und ist ja auch richtig, da die Linie ja eben beides ist. note? Evtl. einen neuen Extratag, aber tram ist einfach was komplett anderes als eine Eisenbahn. Zu den Laderampen: industrielle Bahnen (Laderampen) haben jedenfalls mit public transport nichts zu tun. +1 Und aggressives Verhalten halte ich für nicht erstrebenswert. Ein editwar bringt uns auch nicht weiter. +1 Bis bald fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access bei Barrieren (WAR: Bootsrutsche)
Am 21.06.2011 13:39, schrieb M∡rtin Koppenhoefer: Am 21. Juni 2011 13:31 schrieb Florian Lohoff f...@zz.de: On Tue, Jun 21, 2011 at 12:27:09PM +0200, M∡rtin Koppenhoefer wrote: das sehe ich nicht unbedingt so. Ein Poller ist durchaus ein Zeichen, dass KfZ dort nicht durchfahren dürfen, und bezeichnet somit einen Das halte ich fuer falsch - durchfahren koennen ist richtig - durchfahren dürfen ist falsch. Nur weil es nicht durchpasst heisst das nicht das ich nicht darf. Es gibt Elektromobile mit PKW zulassung die da super durchpassen und es gibt keinen Grund das sie es nicht duerften. Gerade ein Poller kann meistens entfernt werden, damit da auch Fahrzeug (zB Stadtreinigung) durchfahren können. Auch bei einem Tor dürfte motor_vehicles=private durchfahren, wenn sie denn durchpassen. Ob nun ein Tor offen oder verschlossen ist, ist noch mal ein anderes Thema und selbst nach langere Studie und zB mit Öffnungszeiten versehen, kenne ich noch keine Routing-Software, welche sowas auswertet. Zusätzlich sollte man auch noch an Rettungsdienste denken, welche doch allerlei Sonderrechte haben. wenn PKW-Zulassung bedeutet, dass sie diesen gleich gestellt sind, dann dürfen sie m.E. nicht durch. Google mal nach entsprechenden Gerichtsentscheiden. Was ich gefunden habe waren jeweils Hinweise, dass ein Schild nicht erforderlich ist, um einen als solchen erkennbaren Fußgängerbereich für Autos legal nicht befahrbar zu machen. Wie gesagt: an einem Bordstein muss auch kein Schild stehen, um den Gehweg zum Gehweg zu machen. Da muesste eigentlich ein Verbotsschild stehen. dann wäre es sicher noch eindeutiger, und man findet diese Schilder daher oft auch. Nur dann gibt es eine direkte Vorschrift. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grüne beschilderte Radwege erfassen
Am 16.06.2011 18:06, schrieb Claudius: Am 16.06.2011 15:26, Torsten Leistikow: Claudius schrieb am 16.06.2011 15:03: Hat sich schon jemand mit der Erfassung ausgeschilderter (Bsp. siehe [1] und [2]) lokaler Radwege beschäftigt? Ich kenne nur die Relationen [3] von denen network=lcn wohl am besten geeignet wäre. Aber da diese Radrouten ja oft keinen Anfangs- und Endpunkt haben ist das eher schwierig. Ich könnte alle dieser Radwege im Stadtgebiet in eine lcn-Routenrelation aufnehmen, aber das wäre dann auch sinnfrei. Wie geht ihr damit um? Moin, ich gehe entsprechend http://wiki.openstreetmap.org/wiki/Radwegenetze vor. Da hat sich aber noch kein einheitliches Verfahren durchgesetzt, am Fuss der Seite findest du auch links zu anderen Methoden. Diese Seite kannte ich noch nicht. Vielen Dank, Kannte ich so auch nur für die Niederlande. Bei mir funktioniert das auch nicht mit den Relationen. Wie bei lokalen Wanderwegen setzte ich das Netzwerk-Tag desshalb nur an den Weg/die Straße. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Trainingsgelände und Tribünen
Hi Habe letzte Woche schon eine Mail an tagging@ geschriben, aber bis jetzt keine Antwort erhalten. Ich habe mehrere Trainingsgelände gefunden, welche aus einigen Übungsplätzen und einem Stadion mit nur ein paar Stehplätzen besteht. Die Plätze sind auch schön mit leisure=pitch, sports=*, surface=*, eingetragen und der Bereich des Stadion auch, allerdings fehlen mir die Tags für den ganzen Bereich (Sportplätze, Umkleiden, Vereinsheim und Parkplätze). Auch konnte ich unter building=* keinen Bezeichnung für Tribünen finden. Für das Gesamtareal fällt mir nur: landuse/leisure=club_yard ein. Für Tribünen wäre building=stands möglich. Was sind Eure Vorschläge ? cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trainingsgelände und Tribünen
Am 20.06.2011 15:36, schrieb M∡rtin Koppenhoefer: Am 20. Juni 2011 15:32 schrieb Chris66 chris66...@gmx.de: Am 20.06.2011 15:21, schrieb M∡rtin Koppenhoefer: Ich setze bei größerem Sportgelände meist leisure=stadium für das Gesamtgelände und leisure=pitch für das Spielfeld. leisure=sports_centre geht m.E. auch. +1, oops, das wollte ich eigentlich schreiben (nicht Stadion)... Ja, danke, das hatte ich wohl überlesen, Dachte, das sports_centre nur für Gebäude steht. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performance-Steigerung durch Proxy-Server
Am 15.06.2011 09:56, schrieb Georg Ringer: Am 15.06.2011 09:44, schrieb Walter Nordmann: p.s. der Browser-Cache lässt sich ja als erfahrener Anwender mit z.B shift-reload umgehen - kann man das bei einem internen Proxy auch? Da komm ich etwas ins Schwimmen natürlich, es kommt halt auf die richtige implementierung an. der proxy muss das halt korrekt weitergeben. Ich habe mit lokalen proxies nur gute Erfahrungen gemacht, allerdings habe ich immer richtige proxies verwendet (squid wie Frederik oben schon schrieb). Das erwarte ich bei größeren Netzwerken auch und sollte da auch gegen eine Sperre arbeiten ! Selbst bei drei, vier Rechnern daheim lohnt sich ein Proxy ! @Jan: Kommt darauf an, wie Dein Netzwerk gestrickt ist. Falls, Du den Proxy-Server schneller erreichst als OSM und der Proxy keine langsamere Verbindung zu OSM hat als Deine direkte Verbindung zu OSM lohnt es sich. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte zum heutigen Mühlentag (PR)
Am 14.06.2011 14:13, schrieb Sven Geggus: RalfGesellensetter r...@gmx.de wrote: Ähnlich wie die OpenPlaygroundMap sollte zum heutigen ^^ sollte, würde, könnte... Bei freien Projekten gibt es doch immer nur das was jemand macht. Natürlich wäre eine openanytagmap cool, dann wäre auch meien brewpub Map nur noch Webseitendesign. Datum der Launch einer OpenMillingMap (oder so) für findige Kartenbastler ein Leichtes sein. Das POI Problem ist nicht wirklich ganz so einfach zu lösen, denn man möchte ja nicht nur Punkte sondern auch flächige Objekte berücksichtigen. Unterm Strich bräuchte man dazu so ne Art Extended XAPI ein XXAPI sozusagen Wie sieht das bei POIs in einem Haus aus ? Ich gebe dem Gebäude (geschlossener Linie) die Adressinformation und setzte zB den Laden als Punkt, wo sich der Eingang befindet, auf die Linie. Brauche ich für den Punkt auch nochmal die Adressinformation oder werden die vom Gebäude benutzt ? Die selbe Frage habe ich dann auch noch zur associatedStreet: Soll ich da alle zB alle Läden (POIs) aufnehmen oder reicht das Gebäude. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alternativen und Linienbegleitend
Am 13.06.2011 20:28, schrieb Jan Tappenbeck = wäre dann für soetwas landuse=forest als way und NICHT als AREA passender ??? Dafür gibt es doch natural=tree_row: https://wiki.openstreetmap.org/wiki/DE:Tag:natural%3Dtree_row Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] alternativen und Linienbegleitend
Am 14.06.2011 14:35, schrieb Jan Tappenbeck: Am 14.06.2011 14:38, schrieb fly: Am 13.06.2011 20:28, schrieb Jan Tappenbeck = wäre dann für soetwas landuse=forest als way und NICHT als AREA passender ??? Dafür gibt es doch natural=tree_row: https://wiki.openstreetmap.org/wiki/DE:Tag:natural%3Dtree_row Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Gruß zurück. Sorry, war wohl etwas zu kurz. was Du meinst ist eine Allee!!! Nein, nur mehrere Bäume in einer Linie. Bei einer Allee sind das schon zwei ! Schau mal ins Wiki barrier=hedge_bank da ist auch ein Bild ! Dachte ja auch nur zusätzlich, falls eine Fläche schon als natural oder landuse gemapt ist ! cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte zum heutigen Mühlentag (PR)
Am 14.06.2011 15:27, schrieb Sven Geggus: fly lowfligh...@googlemail.com wrote: Ich gebe dem Gebäude (geschlossener Linie) die Adressinformation und setzte zB den Laden als Punkt, wo sich der Eingang befindet, auf die Linie. Brauche ich für den Punkt auch nochmal die Adressinformation oder werden die vom Gebäude benutzt ? Die selbe Frage habe ich dann auch noch zur associatedStreet: Soll ich da alle zB alle Läden (POIs) aufnehmen oder reicht das Gebäude. Also wie nichtexistente Tools funktionieren kann ich nicht beantworten :) Ich klebe bei Gebäuden mit einzelnen Läden drin normalerweise alle Informationen an das Gebäude dran und setze keine zusätlichen Nodes mehr, aber das ist Geschmackssache. Die POI Geschichte ist jedenfalls schon aufwendig genug um sich auch noch freiwillig so Relationsgeraffel anzudichten. Wie behandelst Du Gebäude mit mehreren Läden im Erdgeschoss + Büros, Praxen und Lofts darüber. Habe vergessen zu erwähnen, dass ich den (Haupt)-Eingang als Punkt mit building=entrance (entrance=main) markiere. Und die komplette Adressinformation an jedes Haus zu hängen ist einfach nur Wahnsinn. Gerade dafür gibt es Relationen. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie verbessert man die qualitaet des routings in OSM? (war: Berliner Abbiegebeschränkungen)
Am 11.06.2011 04:46, schrieb Wolfgang: Hallo, Am Freitag 10 Juni 2011 17:23:35 schrieb Kai Krueger: Welche anderen Moeglichkeiten gibt es die OSM Daten besser routingfaehig zu machen? Indem die Restriction-Relation nochmal überdacht wird. Ich sehe da 2 Probleme: 1. die Notwendigkeit, den from-Way am Via-Punkt unterbrechen zu müssen. Das führt häufig zu den überflüssigen Ansagen auf Schnellstraßen ohne bauliche Trennung links halten oder geradeaus an Abfahrten, wenn man nicht abbiegen soll. Abhilfe wäre hier, für die Role from nicht nur ways, sondern auch nodes zuzulassen. Dann müsste der durchgehende way nicht mehr unterbrochen werden. 2. manche Situationen lassen sich in osm zur Zeit nicht gleichzeitig korrekt in Sinne der baulichen Situation und korrekt im Sinne des Routings darstellen. Beispiel 1 Die baulich korrekte Darstellung: C | | | A-B | | | D Problem: Von B kann man in alle Richtungen fahren. Von A kann man nach B und D fahren Von D kann man nach A und B fahren soweit kein Problem, aber: Von C kann man nur nach A und B fahren das heißt, die Restriction, auf dem Weg B-A nicht links nach D abbiegen zu dürfen, ergibt sich daraus, dass man von C kommt. Von B aus geht es. Vor Ort gelöst wurde das damit, dass es von B aus eine Linksabbiegespur gibt, die vor der Einmündung C beginnt und durch eine ununterbrochene Linie abgetrennt ist. Gemappt wurde: C | | | /-\ A--/---B \--+-/ | | | D Damit wird richtig geroutet, aber falsch dargestellt, auch wenn die Abweichung von der Realität erst in großen Maßstäben sichtbar wird. Ein anderes Beispiel, baulich korrekt wäre: C | | | A--B | | |\ | \ | | E P | | | / |/ | | D Man kan von A, B, C und D in alle Richtungen fahren, aber: Von D nach A und C nur über E Von D nach B nur über P Ein Wechsel der Spuren hinter E und P ist nicht möglich. Die Straße bildet aber wieder eine durchgehende Fläche. Gemappt wurde hier: A---B | | | | E P mit den jeweiligen Restrictions. Damit kann richtig geroutet werden, wenn man aber im Navi die Kreuzung aus Richtung A oder B sieht, sieht sie falsch aus. Eventuell kann das 2. Beispiel über mehrere via-nodes gelöst werden (was vermutlich keine SW kapiert). Für das erste Beispiel sehe ich keine Möglichkeit, der richtigen Darstellung und des richtigen Routens, denn eine Restriction würde auf die erste Einmündung bezogen werden. Ich denke auch das die Restriktionen zu simple gelößt wurden. Ein verbesserungsvorschlag in die richtige Richtung gibt es schon unter: http://wiki.openstreetmap.org/wiki/Relations/Proposed/turn_lanes Habe in aber noch nicht soweit getestet. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Botanischer Garten
Am 12.06.2011 16:56, schrieb Jacques Nietsch: Wie tagt man einen botanischen Garten? Ich habe nirgendwo etwas gefunden Explizit gibt es das auch noch nicht, wobei: name=Botanischer Garten leisure=garden fee=* wohl der beste tag ist. Kannst ja noch garden=botanical und eine note=* dazu setzten. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Wege zu Gärten taggen?
Am 10.06.2011 10:59, schrieb Chris66: Am 09.06.2011 23:02, schrieb Manuel Reimer: wie werden denn Wege zu Nutzgärten, bzw. Schrebergärten korrekt getaggt? Ich tendiere hier zwischen highway=track oder highway=service. Ob ein Weg zu einem Schrebergarten oder zu einem Supermarkt führt ist erstmal egal. +1 Entscheidungskriterien sind: - Breite des Weges - Beschilderung Wenn Autos erlaubt sind: highway=service Der Übergang zwischen track und service ist ja wohl fließend. Wichtiger sind dann wohl Zusatzinformationen wie: access, surface und width. Wenn Autos nicht erlaubt/möglich sind: highway=path Das halte ich bei eim 3m breiten Weg für falsch. Dies ist dann wohl ein track. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Am 09.06.2011 20:06, schrieb M∡rtin Koppenhoefer: Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon länger durch den Kopf geht. Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen: welche Kraftwerke werden von EON betrieben, wo ist die Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen könnten vollständig abgebildet werden (Parlament, Regierungssitz, Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur ungefähr, d.h. man verlässt sich auf gleiche Namen oder muss externe Recherchen anstellen und unsere mit anderen Daten verknüpfen. Im Prinzip ist solches Mappen derzeit schon möglich, da man auch Relationen ohne Members machen kann, die z.B. eine Firma repräsentieren könnten. Das Problem ist vor allem, wie man diese Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn es Interesse daran gibt, wäre das vielleicht lösbar. Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte: Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr drin stehen) http://www.openstreetmap.org/browse/relation/1618278 und eine Metro-Linie, die von der vg. Firma betrieben wird (die Relation taucht hier mit der Rolle operator auf): http://www.openstreetmap.org/browse/relation/207926 Kommentare? Ich denke ein Ansatzpunkt ist auch sich für verbreitet operator=* zu einigen und dafür eine Datenbank zu erstellen. Ob im wiki oder extern ist ersteinmal egal, jedoch sollte sie im wiki verlinkt sein und die Editor-Software sie benutzen (presets, known values, autocompletion). In der Datenbank bräuchte man den 1. Koordinatenbereich, wo der operator anzutreffen ist (kann von der ganzen Welt bishin zu einer Stadt variieren) 2. Name 3. die main-tags, mit welchen der operator zu verknüpfen ist ( zb postbox, vendingmachine, postoffice, building, ... bei der Deutschen Post AG). Für building müß man noch ein bischen besser filtern, da sonst schnell eine zu große Liste entsteht ! Es sollte zb möglich sein alle bekannten operator für Briefkästen in Deutschland im preset amenity=postbox als values zu erhalten, wenn man sich in D befindet und analog für andere Länder/Gebiete. Ich weiß, dass das ein ganze Stück Arbeit erfordert, aber es würde wohl viel mehr Eindeutigkeit schaffen als Monster-Relation-Kombinationen, oder wie stellt Ihr Euch denn so eine Relation für die Post, die Deutsche Bahn bzw andere große, weltweit tätige Konzerne vor ? Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginghilfe innerstädtische Fußwege
Am 10.06.2011 13:27, schrieb Markus Straub: 2011/6/9 M∡rtin Koppenhoefer dieterdre...@gmail.com: Am 9. Juni 2011 20:29 schrieb Markus Straub markus.straub...@gmail.com: Hi, wie taggt ihr folgendes: Gässchen in einer Innenstadt (Altstadt) die keine offiziellen Fußgängerzonen, Wohnstraßen etc sind. Hier in Wien gibt es einige asphaltierte Gassen, ca 2m breit, die nicht von Fahrzeugen befahren werden können weil es keine Gehsteigabsenkung gibt und die Fläche außerdem von Gastgärten belegt ist. highway=pedestrian? highway=footway? Das selbe Frage stellt sich generell für größere Flächen die innerstädtisch klar dem Fußgänger gewidmet aber nicht als Fußgängerzone gekennzeichnet sind - quasi großflächige Aufweitung des Gehsteigs. m.E. highway=service, service=alley, evtl. noch mit width. Mit dem Motorrad könnte ich doch da durchfahren, wenn ich Dich richtig verstehe? Gruß Martin Nein man kann mit dem Motorrad definitiv nicht durchfahren (die Fläche wird ja fast komplett durch den Sommergastgarten genutzt), auch mit dem Rad wäre es schwierig und außerdem illegal. Was heiß hier illegal, gibt es ein Schild ? Wie sieht das am frühen Morgen und im Winter aus ? Ein highway=service kann normal befahren werden, passt also hierfür nicht finde ich. Es gibt auch immer noch access=* und foot=official Leider werden da aber auch etliche Kombination nicht richtig dargestellt. aber width=* geht auf jeden Fall. gibt es das: highway=footway area=yes geht durchaus (bzw siehe oben) ich nehm an kein renderer schluckt das.. Deshalb wird meistens falscherweise highway=pedestrian benutzt. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konflikt mit Relation und Landesgrenze
Am 08.06.2011 10:47, schrieb Markus Bärlocher: Hi Markus Kann Dir leider im Momment auch nicht weiter helfen, da ich sowohl in JOSM als auch auf OSM einen TimeOut bekomme. Vielleicht später. Und - hast Du wieder einen Zugang? Das liegt einzig und allein an OSM und der Monster-Relation Ich habe die Änderungen als OSM lokal gespeichert, aber keine Idee, was ich nun damit anfange... Lade sie noch mal und wähle (select) nur die Relation aus. Führe Auswahl aktualisieren (update selection) aus. Du solltest eine Konflikt erhalten. Im Konfliktdialog hast Du jeweils 3 Spalten. Auf der rechten Seite ist deine Version, auf der Linken die aktuelle vom Server und in der Mitte wird die neue Version angezeigt. Mehr unter: http://josm.openstreetmap.de/wiki/Help/Dialog/Conflict und https://josm.openstreetmap.de/wiki/Help/Concepts/Conflict Leider beides nicht auf Deutsch (auch kein Italienisch) und nicht ganz aktuell, wobei für Elemente das gleiche gilt wie für die Punkte beschrieben. Entlang der Küste von Sardinien habe ich Häfen kartografiert. Mit der Küstenlinen sind oft die Grenzen verbunden, und da habe ich Konflikte erzeugt :-( So schnell verursacht man keine Konflikte. Hast Du außerhalb der Download Area Linien aufgeteilt oder zwischenzeitlich upgeloaded und dann im selben Layer weiter gearbeitet (gabe es einen Bug in JOSM, finde in nur gerade nicht). Wenn Du Dir die History anschaust kannst Du sehen, wer und wann die Relation geändert hat. Letzte Änderung: user:matchman changeset:8373571 Erstellt am:Dienstag, 07. Juni 2011, 20:02 Uhr Anderungen im Norden Sardiniens. davor war 2 Monate nichts. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problematik der Ortsnamenzusätze
Am 08.06.2011 16:32, schrieb Igor Podolskiy: Walter, On 08.06.2011 14:02, Walter Nordmann wrote: Igor Podolskiy wrote: Wer entscheidet, was Prefix und was Suffix ist, wenn man denn schon entschieden hat, dass es ein Namenszusatz ist? natürlich ICH, wenn ich einen Namen dieser Art eintrage ;) richtig, die Entscheidung will ich dir auch nicht nehmen, das ist immer noch _Open_StreetMap hier :) Allerdings muss ich sowohl als Mapper als auch als Anwendungsentwickler mit dieser Entscheidung leben, und darf ganz dezent meine Bedenken hierzu vortragen. Erfahrungsgemäß wird jeder etwas anders entscheiden. Und selbst jeder einzelne wird heute so und zwei Wochen später vielleicht anders entscheiden. Und dann heißt es auf einmal Och, das ist ja so ein Wildwuchs, lasst uns das doch vereinfachen! Ich wäre dafür, es von vorn herein einfach zu lassen. Was ist mit noch interessanteren administrativen Einheiten wie Vereinbarte Verwaltungsgemeinschaft der Stadt Geislingen an der Steige? Wo ist denn da davor oder danach? Frage jemanden aus der Stadt, wo er wohnt; alles davor ist prefix, alles danach postfix. Das kann sooo einfach sein. Wie war das noch einmal: There is always an easy solution to every human problem--neat, plausible, and wrong. ;) Damit hast du die lokale Sichtweise desjenigen, der in der Stadt wohnt. Diese muss nicht mit der amtlichen oder irgendeiner anderen für eine bestimmte Anwendung sinnvollen Sicht übereinstimmen. Irgendjemand, der in Montabaur wohnt, weiß, um welches Limburg es sich handelt, der sagt dann auch immer Limburg. Irgendjemand aus Passau oder London würde vielleicht an der Lahn interessieren. Also muss es auch die Anwendungen interessieren, die diese Leute benutzen. Was ist mit Internationalisierung? name:prefix:en? Oder name:en:prefix? Was ist mit mehreren Zusätzen? name:prefix:prefix? Oder doch durch Semikolon getrennt in einem Tag? das solle doch wohl nur in echt mehrsprachigen Ländern wichtig sein (z.B. Belgien) Ich hoffe nicht, dass du Ortsbezeichnungen wie Limburg an der Lahn in name=Limburg, suffix=an der Lahn , suffix:en=on River Lahn aufbrechen willst - oder? Nein, ich rede von einer Karte von Deutschland, die in Englisch oder in Russisch dargestellt ist. Es mag dich vielleicht überraschen, aber Namen werden nicht nur transliteriert, sondern auch übersetzt (de:München - en:Munich). Ein Beispiel ist Frankfurt am Main im Russischen: de:Frankfurt am Main - Transliteration - ru:Франкфурт-ам-Майн (falsch) de:Frankfurt am Main - Übersetzung - ru:Франкфурт-на-Майне (richtig) Also bräuchtest du ein name:suffix:ru, wenn du tatsächlich name=Frankfurt und name:suffix=am Main hinschreibst. Und die Bindestriche gehören im Russischen anders als im Deutschen wirklich dahin. Frankfurt ist nicht Hintertupfingen, da kannst du nicht sagen wer das anders als in Deutsch lesen will, hat Pech gehabt. Ich will übrigens gar nichts aufbrechen :) Im Gegenteil, ich bin mit name=Limburg an der Lahn vollkommen zufrieden. Auch wenn wir Deutschland als ein nicht wirklich mehrsprachiges Land annehmen, was an sich schon mindestens gewagt ist, sind wir hier bei einem zweifellos wirklich mehrsprachigen internationalen Projekt und es könnte nicht schaden, mindestens darüber nachzudenken, darauf Rücksicht zu nehmen, oder? ;) aber noch besser ist es IMHO, einen vollständigen Namen in name=* zu taggen und nicht zu versuchen, die Namen zu zersückeln. Ist auch viel, viel einfacher. Entweder muss die Software den zerstückelten Namen wieder zusammensetzten, wenn sie den vollständigen Namen haben will oder sie muss den vollständigen Namen irgendwie zerstückeln wenn sie den Kern-Namen haben will; da ist mir ersteres wegen der einmaligen manuellen Bearbeitung 1000x lieber als ein Rumgerate der Software Dein gutes Recht. Mir ist es als Mapper lieber, eine einfache Regel zu haben, wo ich nicht jedes Mal im Wiki nachschauen muss und nachgrübeln muss, was jetzt der Zusatz ist und was nicht. Und als Anwendungsentwickler ist es mir lieber, eine (eventuell regional angepasste) Heuristik für _einen_ Tag zu entwerfen, als x Heuristiken für y Kombinationen aus z Tags für all die unterschiedlichen Variationen von der Sichtweise, was jetzt ein Zusatz ist und was nicht, die bei solchen Sachen unweigerlich aufkommen. Wohlgemerkt: ich habe nichts gegen alternative vollständige Namen (alt_name, old_name, name:alternative, name:official, name:$YOUR_QUALIFIER, ...), nur Bedenken gegen das Zerstückeln. Aber alles in allem: die Welt geht nicht unter, egal wie du es machst :) +1 Ich habe bei Kirchen häufig noch ein name:de=St angegeben und im name= Sankt cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwaltunggrenzen als Multipoligon
Am 06.06.2011 14:46, schrieb Frederik Ramm: Gerhard Schmidt wrote: Hey Wäre es nicht sinnvoller für solche grenzen einen eigenen type zu machen. Einige Leute verwenden type=boundary, das geht auch. Aber ich halte da wenig von; denn sowohl Verwaltungsgrenzen als auch Multipolygone muessen genau gleich behandelt werden in der Software, die damit umgeht (Flaeche aus Stuecken zusammensetzen, ggf. Luecken reparieren, ggf. Enklaven/Exklaven beruecksichtigen usw.) - also sollte man sie auch alle als type=multipolygon taggen, damit das klar ist. die boundary relation haben noch ein paar zusätzliche Rollen um sie mit place=* - Knoten zu verknüpfen. Habe in D öfters das Problem, dass ein Name mehrfach gerendert wird, da die admin Grenzen-Relation, die landuse-relation und der place-node nicht miteinander verknüpft sind. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischen Forest und Scrub
Am 06.06.2011 18:04, schrieb Torsten Leistikow: M∡rtin Koppenhoefer schrieb am 06.06.2011 17:42: Du müsstest irgendwie das Alter (Pflanzdatum, auch ungefähr) der Bäume unterbringen (bzw. die durchschnittliche Wuchshöhe - nicht gerade ein dauerhaftes Attribut allerdings). Naja, wenn man keinen Zaubertrank hat, wachsen Baeume nicht so schnell. Was ist denn jetzt ein Bambuswald ? landuse=farmland landcover=grass cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konflikt mit Relation und Landesgrenze
Hi Markus Am 03.06.2011 21:31, schrieb Markus: Ich habe jetzt einfach mal bei Konflikt abweisen und Speichen auf OK geklickt. Dadurch wurde eine .OSM gespeichert. Damit solltest Du Deine Änderungen gespeichert haben und die Konflikte werden beim nächsten Update wieder erscheinen. Es gibt bei JOSM auch noch mehr Update- bzw Upload-Funktionen. Damit kannst Du auch nur bestimmte Objekte updaten bzw uploaden und somit erstmal alle anderen Änderungen hochladen. Hast Du denn Änderungen an dieser Grenze vorgenommen? Ja, habe ein überflüssiges Stück gelöscht und dabei die Frage, ob das Teilstück auch aus den Relateonen entfernt werden soll, bejaht. Jetzt meldet JOSM einen Konflikt mit einer Realation. Der Relationsmanager sagt aber nicht, worin der Konflikt besteht, sondern bietet zwei Spalten mit Nummern meine und deren. Mein Versuch entweder alle meine oder alle deren hochzuladen funktioniert nicht. Das ist aber merkwürdig. Bist Du Dir sicher, dass nur die Mitglieder den Konflikt verursacht haben (kein rotes Feld mehr in der Kopfzeile)? denjenigen direkt kontaktieren Keine Ahnung wer wie wo... Dafür kannst Du den History Toggle Dialog benutzen (Strg-H) Lade doch mal die Relation in einem neuen Layer und vergleiche sie mit Deiner Version. Wenn Du Deine eigenen Änderungen (an dieser Konfliktrelation) verwerfen willst, dann musst Du einfach im Konfliktmanager jeweils their Version (rechte Spalte) auswählen und in die Mitte nehmen (in der Mitte ist jeweils die Lösung des Konflikts). Hat nicht funktioniert: Lösung anwenden ist nicht klickbar. s.o. Um welche Relation handelt es sich eigentlich (id)? Welche JOSM-Version benutzt Du ? Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kloster, Priorat, Stift, etc.
Am 03.06.2011 19:01, schrieb M∡rtin Koppenhoefer: Am 3. Juni 2011 18:35 schrieb malenki o...@malenki.ch: M∡rtin Koppenhoefer schrieb: Am 3. Juni 2011 17:24 schrieb malenki o...@malenki.ch: Ohne etwas gelesen zu haben (sry, wenig Zeit atm): warum nicht als amenity=place_of_worship taggen? Natürlich plus brauchbare zusätzliche Tags. Hatte ich auch eine Weile so gemacht, finde ich aber eigentlich unbefriedigend, weil man in Klöstern praktisch immer Kirchen und Kapellen findet, und sich dann seltsame Schachtelungen ergeben (und weil praktisch alle aktuellen Anwendungen das als Kirche interpretieren). building=* regelt Mappen für den Renderer eher nicht Also, dass place_of_worship einer Kirche entspricht ist ja wohl nicht Dein Ernst oder hast Du schob buddistische, islamische ... Kirchen gefunden. Meiner Meinung ist hier mal wieder ein alter tag am Bröckeln. Ist nicht eine unterkategorie von place_of_worship nötig ? place_of_worship=monastry place_of_worship=church place_of_worship=chapel place_of_worship=tempel ... Dann kann man auch wieder alle Gebäudetypen mappen oder was machst Du mit dem Glockenturm einer Kirche ? building=* sagt m.E. was über das Gebäude aus (dessen Typologie, also wie es strukturiert ist), nichts über dessen Nutzung. Mit Anwendungen meinte ich nicht nur Renderer, z.B. auch eine Anwendung, die alle Kirchen in OSM auflistet (oder zählt, etc.) würde da vermutlich die Klöster als Kirchen mitzählen. M.E. ist ein building=xy nie eine Alternative zu einer Funktion / Institution (ersteres ist die physische Stätte, letzteres ist eher abstrakt). Wenn Du etwas mehr Zeit gehabt hättest und den Vorschlag gelesen hättest, dann hättest Du sicher gesehen, dass ich eine ganze Reihe von building-Werten vorschlage, monastery ist aber nicht dabei, weil es m.E. mehrere einzelne Objekte und Gebäude mit einer speziellen Nutzung sind, die den Gesamtkomplex Kloster ausmachen (Kreuzgang, Kirchen und Kapellen (Oratorium), Refektorium (Speisesaal), Dormitorium, Küche, Küchengarten, Kräutergarten, Ställe, Brauerei, ...). Vielleicht lege ich da aber auch noch nach, wenn ein pauschales building=monastery allgemein als sinnvoll angesehen wird, und man definieren kann, welche Teile damit getaggt werden sollten. Damit widersprichst Du Dir ja selbst ! Lass es lieber weg. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konflikt mit Relation und Landesgrenze
Am 04.06.2011 16:41, schrieb Markus: Hi, Wo? Bin leider nicht am Meer. Versuche Dir gerade zu helfen, stosse dabei leider auf so einige JOSM Bugs.(vielleicht Doch mal nur r4064 benutzen) Damit solltest Du Deine Änderungen gespeichert haben und die Konflikte werden beim nächsten Update wieder erscheinen. Ok, das beruhigt erst mal. bist du sicher, dass du nur die Mitglieder die den Konflikt verursacht haben (kein rotes Feld mehr in der Kopfzeile)? Rot ist der Reiter Elemente Dort ist in den Kopfzeilen nichts rot. Sorry, ja die Reiter. Habe glaube was gefunden: http://josm.openstreetmap.de/ticket/4564 Lade doch mal die Relation in einem neuen Layer und vergleiche sie mit Deiner Version. Um welche Relation handelt es sich eigentlich (id)? Unter Konflikte steht: Multipolygon (Italia, 2027 Elemente, unvollständig) Aber keine Relationsnummer oder so. Dann mußt Du Dir die Objektids anzeigen lassen. Schau mal unter Preferences - Display settings (oberste linke Reiter) und dann der rechte obere Reiter Look and Feel. Alternative kannst Du auch die Relation auswählen (select Button im conflict toggle dialog) und dann mit View - Info about Elements (Strg-I) auf die OSM-Server-Seite gelangen. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konflikt mit Relation und Landesgrenze
Am 04.06.2011 18:51, schrieb Markus: Hi und danke für Deine Hilfe! Objektids anzeigen lassen: Preferences - Display settings (oberste linke Reiter) und dann der rechte obere Reiter Look and Feel. Hab gerade erst die JOSM wiki seite angepasst, aber es gibt in dem Bereich noch einiges zu tun. Da muss man erst mal drauf kommen... Durchsnittsmenschen suchen die ID im Rechtsklickmenü. Kannst ja ein Ticket im JOSM-trac eröffnen. ID: 957.374 Das ist ja mal wieder eine Relation, wie ich sie hasse ! Bei 500 Mitgliedern hörts ja wohl auf ! Danach sollte man die Relation lieber aufteilen. (leider nicht kopierbar, da im Fenstertitel integriert) dafür gibt es den workaround: siehe letze mail, letzter Abschnitt. Aber weder im Fenster Konflikt noch im Fenster Relation komme ich in die Historie (weder Strg-h noch Rechtsklick) Der History Toggle dialog ist ein Dialog Fenster auf der rechten Seite. Dort werden alle ausgewählen Objekte angezeigt. Von dort kannst Du dann den History Dialog für das jeweilige Objekt öffnen. Und ich habe keine Idee, wie ich nun den Fehler finde oder behebe. Kann Dir leider im Momment auch nicht weiter helfen, da ich sowohl in JOSM als auch auf OSM einen TimeOut bekomme. Ob das an OSM, meiner lahmen + überlasteten Leitung oder meiner Oldschool Hardware liegt, kann ich gerade nicht beurteilen. Vielleicht später. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wohin Monsterrelation führen können + taggen von Grenzen (WAR: Konflikt mit Relation und Landesgrenze)
Am 04.06.2011 21:43, schrieb fly: Am 04.06.2011 18:51, schrieb Markus: ID: 957.374 Das ist ja mal wieder eine Relation, wie ich sie hasse ! Bei 500 Mitgliedern hörts ja wohl auf ! Danach sollte man die Relation lieber aufteilen. Aber weder im Fenster Konflikt noch im Fenster Relation komme ich in die Historie (weder Strg-h noch Rechtsklick) Der History Toggle dialog ist ein Dialog Fenster auf der rechten Seite. Dort werden alle ausgewählen Objekte angezeigt. Von dort kannst Du dann den History Dialog für das jeweilige Objekt öffnen. Bekomme ich für diese Relation auch nicht geöffnet ! Und ich habe keine Idee, wie ich nun den Fehler finde oder behebe. Kann Dir leider im Momment auch nicht weiter helfen, da ich sowohl in JOSM als auch auf OSM einen TimeOut bekomme. Ob das an OSM, meiner lahmen + überlasteten Leitung oder meiner Oldschool Hardware liegt, kann ich gerade nicht beurteilen. Habe mich mal ein bischen umgeschaut: 1. Die Relation 957374 soll die Landmasse von Italien darstellen. Leider hat sie über 2000 Elemente, sodass ich sie nicht in JOSM laden kann, auch öffnet sich der History Dialog nicht. Solche Monster sollten in Segmente unterteilt werden, wie es z.B. bei administrativen Grenzen und Küstenlinien schon Usus ist. 2. Was sollen eigentlich die ganzen name:left/right=, region:left/right=, province:left/right= an den Grenzlinien. Sowas gehört in eine Relation und nicht an die Linie. 3. An Küstenlinien sollte nicht ein boundary tag geklebt werden, dazu genügt die Grenzrelation. Da diese Punkte wohl über Landesgrenzen hinaus zu diskutieren sind, ist diese Mail wohl eher auf talk@ aufgehoben, aber Eure Meinung interessiert mich trotzdem. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Busspur mit Fahrraderlaubnis
Am 02.06.2011 16:26, schrieb Markus Straub: Hi, wie taggt man korrekterweise eine Busspur auf der man auch Radfahren darf? Offiziell scheint es nichts zu geben, aber mit etwas Recherche komm ich auf folgendes: Habe hier noch einen komplizierteren Fall mit Buspur (Taxi,Fahrrad frei) in eine Richtung und nur eine Fahrradspur in Gegenrichtung und natürlich die Straße welche von 22-6 h ein Fahrverbot für Lkws und Motorräder hat, sowie eine Höchstgeschwindigkeit von 30km (am Tag 50km, was aber aufgrund der Ampeln und dem Verkehr unrealistisch ist). In meinem Fall ist die Busspur extra gemapt als highway=service highway = * busway = lane cycleway = share_busway http://wiki.openstreetmap.org/wiki/Key:busway http://taginfo.openstreetmap.de/keys/?key=cycleway#values Ist das eine Einbahnstraße oder gibt es die Buspur in beide Richtungen ? Ansonsten fehlt da auf jeden Fall eine Richtungsangabe (left/right). busway:right=lane ... Leider wird sowas von keinem mir bekannten Rendere ausgewertet. Siehe auch: http://trac.openstreetmap.org/ticket/2195 Darum wird sowas wohl häufig als eigener Weg eingetragen. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 02.06.2011 18:54, schrieb Peter: Ja wird eklig. +1 Man kommt auf die Idee das Josm da einem viel Arbeit abnehmen könnte. z.B. 2 Objekte markieren und 'Alle gemeinsamen Punkte trennen' Oder auch mehrere Objekte als nur 2. So als Featurerequest. Müsste man noch bischen rumdenken und probieren ob es noch eine allgemeinere Möglichkeit gibt. z.B. 'Alle gemeinsamen Punkte markieren'. Danach dann 'trennen' aufrufen. Das hätte den Vorteil das man dann auch die gemeinsamen Punkte gemeinsam bewegen könnte. So hat man beide Fälle erledigt: Getrennte Punkte haben wollend oder halt gemeinsame Punkte. Vielleicht geht ja auch schon alles. Z.B. mit Filtern nur die beteiligten Objekte anzeigen lassen, dann alle Punkte markieren, dann trennen. Aber da kommt leicht zu viel dabei und es werden dann die falschen Dinge getrennt. Das Auftrennen ist bereits implementiert. Auf jeden Fall lohnt sich ein Blick auf den utils2-Plugin. Falls man nicht fündig wird, ist wohl ein Enhancement-Ticket angebracht, wobei ein patch auch gerne gesehen wird. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing-Fehler nüvi vs. openrouteservice
Am 30.05.2011 22:05, schrieb Chris66: Am 30.05.2011 15:31, schrieb Steffen Grunewald: Übersehe ich was? (Angesichts der gesetzten oneway-Tags erscheinen mir die no_right_turn- Relationen ohnehin obsolet...) Ja, ich habe auch die vielen Restriktions an der B5 Auffahrt im Verdacht, blicke da aber nicht durch. Mir sind zB. die Restriktions 569334,569335,569374 suspekt. 569335 wurde bereits gelöscht. 569335,569374 sowie 1607221,1607222 sind meiner Meinung nach überflüssig, da sie alle das abbiegen in eine gegenläufige Einbahnstraße verhindern und somit für das routing überflüssig sind. Wenn überhaupt könnte man das Verkehrszeichen taggen, aber gerade das fehlt in den Relationen. Habe diese Info auch mal dem/r ErstellerIn zukommen lassen. Bis bald fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amazon.de-affiliate für OSM?
Am 27.05.2011 13:01, schrieb Frederik Ramm: Hallo, On 05/27/11 12:26, Henning Scholland wrote: Mit der Information, dass dies nun möglich ist, zwingt man aber keinen bei Amazon einzukaufen. Die, die aber ohnehin über Amazon Dinge beziehen, würden sich über die Info freuen. Ich sag ja - Wikiseite mit allen Anbietern, die uns Provision zahlen, und gut is. Posting im Forum uebrigens gibts jetzt auch bei amazon.de Provision mit Link auf Webseite. Aber kein prominentes sticky-Posting, ausser wenn man bereit ist, auf Dauer *jeden*, der uns Provision gibt, an diesem Ort zu listen. +1 Bitte nicht noch mehr Werbung. Gibt schon viel zu viel davon im Web ! cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kein Micromapping mit landuse
Am 25.05.2011 19:52, schrieb Stephan Wolff: Am 25.05.2011 17:42, schrieb M∡rtin Koppenhoefer: Am 25. Mai 2011 00:41 schrieb Stephan Wolffs.wo...@web.de: Am 24.05.2011 18:52, schrieb Flaimo: Hast Du mal ein Beispiel, wo es störend ist, den landuse kleinteiliger zu erfassen, und wo es daher sinnvoll ist, Teilflächen falsch zu klassifizieren, damit die Daten besser sein sollen? den landuse gibt es nicht. Es gibt verschiedene Ebenen der Beschreibung: - das Industriegebiet - das Firmengrundstück - das Werksgebäude - den Bürotrakt - das Einzelzimmer - die Fensterbank - den Blumentopf Jede Ebene kann man als Fläche beschreiben und keine ersetzt die anderen Ebenen. Jede Beschreibung ist falsch auf den darunterliegenden Ebenen. Der OSM-Key landuse beschreibt die Gebietsebene. - erklären, wie er die die bisherige Information (z.B. Gebietsnamen) erhalten will verstehe ich nicht, wo da ein Problem sein soll. Multipolygone kennst Meinst du Relationen? Eine Relation Waldsiedlung bestehend aus 250 Einzelgrundstücken? Ich habe allerdings ein Problem mit der Namensanzeige. Wenn die admin-Grenzen und das Wohngebiet die gleichen Namen haben wird der Namen zweimal angezeigt. Häufig kommt dazu noch ein place-node. Auch habe ich manchmal kleine Inseln die zu Gebieten gehören. Bei multipolygonen kann entweder in jede Fläche einzeln oder im Mittelpunkt der Namen angezeigt werden. Beides nicht immer sinnvoll. Leider sind multipolygonen sind Rollen admin_centre und label bisher unbekannt. dabei sollte man dann vielleicht auch mal definieren was überwiegend bedeutet Das Problem tritt ebenso bei jeder anderen Flächendefinition auf. Schon innerhalb eines Gebäudes kann es über- und nebeneinander verschiedene Nutzungen geben. Genau das ist ein Problem. Es gibt auch Gewerbemischgebiete, und landuse=commercial;industrial;residential ist auch keine Lösung. Ich kann einen Sinn darin erkennen, eine bestimmte Nutzung für ein Grundstück festzulegen (wobei auch da in seltenen Fällen eine Zusatzinfo wünschenswert ist), aber nicht darin, abweichende Nutzungsarten und Flächen in einem Gebiet zu unterschlagen. Andere sehen einen Sinn in der Aufteilung von Wohn- und Industriegebiet. Niemand hat etwas dagegen, dass du die Nutzungsart der Grundstücke beschreibst. Aber verwende dazu einen anderen Key als landuse. Der Key ist schon vergeben. +1 auf talk@ gabe es eine Diskussion über private (Vor-)Gärten. Das Ergenis war: landuse=residential als große Fläche erhalten und residential=garden bzw. garden=residential zu verwenden. Gleiches kann ich mir gut für andere landuses vorstellen oder doch gleich landcover verwenden. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Einrichtungen im Bau
Am 23.05.2011 19:13, schrieb malenki: Frederik Ramm schrieb: start_date=$(Datum der voraussichtlichen Fertigstellung) http://wiki.openstreetmap.org/wiki/Key:start_date Das bezieht sich ja dann wohl eher auf den Anfang der Bauarbeiten, aber auch ganz gut, somit kann man andere user darauf hinweißsen, dass das Aerial veraltet ist, und es bei Fertigstellung, dann entsprechend anpassen. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19.05.2011 18:40, schrieb Torsten Leistikow: Es hat halt jeder so seine eigene Mapping-Technik, jeder Ansatz hat ja auch seine Vor- und seine Nachteile. Bei den Flussflaechen z.B. gibt es in meiner Region einen Mapper, der an den Trennstellen die beiden Teile immer ein wenig ueberlappen lasst. Das sorgt dann dafuer, dass Renderer an der Schnittstelle keinen sichtbaren Streifen erzeugt, aber ueberlappende Fluss-Abschnitte ist datentechnisch natuerlich totaler Bloedsinn. Ich verwende für Flüsse auch multipolygone. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kundenparkplatz
Am 23.05.2011 17:52, schrieb Kay Drangmeister: Hallo Am 23.05.2011, 16:49 Uhr, schrieb Günther Zin. o...@fh15.homeip.net: Was haltet ihr davon (hab NICHT ich gemacht)? kleiner Unterschied: Mieter-Parkplätze statt Kundenparkplätze: http://www.openstreetmap.org/?lat=48.25943lon=14.28891zoom=17layers=O In der Parkkarte werden Privatparkplätze schwarzbraun gezeichnet, siehe entsprechend: http://parking.openstreetmap.de/?lat=48.25943lon=14.28891zoom=18 während Kundenparkplätze braun dargestellt werden, siehe z.B. hier: http://parking.openstreetmap.de/?lat=48.19289lon=11.46457zoom=17 Das willst Du ja hoffentlich am Namen ausmachen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit josm nach upgrade kubuntu 10.10 - 11.04
Am 12.05.2011 17:40, schrieb M∡rtin Koppenhoefer: Am 12. Mai 2011 13:19 schrieb Christian Knorr os...@gmx.de: Hallo Martin, doch, eine GUI habe ich schon, aber sun-java6-jre ist ohnehin nicht in meinem Repo. Das braucht aber auch nicht. gut, freut mich für Dich, dass es bei Dir auch ohne geht. Bei mir ist openjdk nach dem upgrade (wobei es ohne mein Zutun als default eingestellt wurde) ein paarmal jämmerlich abgestürzt, und auch davor war ich bereits auf sun umgestiegen, weil openjdk ein Hort permanenten Ärgers war ;-) Das ist mal wieder typisch ubuntu. Ist ja schön, dass ubuntu seit längeren openjdk bevorzugt, aber im Endeffekt funktionierts wieder nicht. Habe mit openjdk und debian kein dieser Problem. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnübergang
Am 11.05.2011 18:00, schrieb Wolfgang: Hallo, ich habe im Wiki nichts über beschrankt/unbeschrankt etc gefunden. Habe ich etwas übersehen? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Es gibt zumindest: http://wiki.openstreetmap.org/wiki/Proposed_features/detailed_Railway_Network Ich habe bisher barrier=yes/no/* verwendet. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Am 03.05.2011 09:07, schrieb Peter Wendorff: Am 29.04.2011 16:49, schrieb fly: Der Bezug zur Topologie geht verloren, das ist richtig Bisher ist die Topologie aber häufig schlicht falsch, wenn du die Werte nimmst, die du aus Attributen an der Straße entnimmst. Selbst wenn (was fast nirgendwo der Fall ist) die Straße mit width=* eine Breite mitträgt, die du auswerten kannst, kannst du den Fußweg nur bei konstanter Breite entsprechend erfassen. Parkstreifen über Teile der Straße zwischen Fahrbahn und Fußweg = wo kommt dessen Breite her? Sollte mit width:parking:lane:[right/left/both]=* wohl kein Problem sein. Beim Grünstreifen tragen manche ja wieder den Fußweg explizit ein - warum vermisst du die Topologie da nicht? Dass der Fußweg an den Grünstreifen angrenzt (der oft nichtmal eingetragen ist), ist genausowenig zu erkennen wie die Tatsache, dass ein explizit eingetragener Bürgersteig an die Straße angrenzt. Ja, auch das gefällt mir nicht, aber Grünstreifen kann ich eintragen. Ansonsten s.u. Mein Vorschlag war ja eben, den Bezug zur Straße über Tags herzustellen: sidewalk=yes impliziert, dass es eine dazu passende Straße nebenan gibt. name=name_der_straße erlaubt dann die Zuordnung zu genau dieser Straße - mit weniger aufwändigem Preprozessing. Dein Argument Auch ist highway=* entgültig kein seperater Weg mehr. klingt etwas verdreht: highway=* ist auch sonst oft nicht auf separate Wege eingeschränkt. Beispiele für Abbiegespuren, die auch da, wo sie parallel verlaufen, als highway=*_link eingetragen sind, kann ich dir liefern, wenn Du sie nicht selbst kennst. (Übrigens etwas, was niemand IMHO beanstandet hat, zumindest, solange das Multilane-Problem nicht gelöst ist. Ja, das geht genau in die gleiche Richtung. Wie wird da denn die Gesamtbreite eingetragen ? Das ein Bordstein eine Barriere darstellt und gleichbedeutend wie ein Grünstreifen ist, ist meiner Ansicht, ein sehr dünnes Argument. Aber ein Poller verdient die Einordnung als barrier? Welches Argument ist denn jetzt dünner? Ich meinte, dass nicht jede Barriere auch eine wirkliche Absperrung darstellt. Im Notfall benutzt der Krankenwagen/die Feuerwehr auch den Bürgersteig, ich habe auch mit dem Fahrrad keine Probleme mit Bordsteinen ... Ein Poller wäre für Füßgänger beim Überqueren der Straße keine Barriere, eher wohl eine gespannte Kette. Ich kenne ein paar Rolli-Fahrer und da gibt es gewaltige Unterschiede, was als Barriere angesehen wird. +1 Für manche sind sogar fünf Treppenstufen kein Problem aufwärts? Ja, auch aufwärts. und ein Bordstein ist für mindestens die Hälfte kein Hinderniss. Für die Rollifahrer, die Du häufig draußen triffst, ist das richtig. Für Oma Erna, die Opa Herbert zum Spazierengehen durch die Gegend schieben will, ist es aber sehr wohl ein Problem. Bei der demographischen Entwicklung, die wir momentan haben, eine stetig wachsende Gruppe (und zunehmend nicht mehr technik-scheu) Die werden ja wohl gekennzeichnete Übergänge benutzen. Schön wäre es wohl, schnell eine Lösung für das Multilane-Problem zu finden und in den Editors Relationen noch benutzerfreundlicher (Newbies) zu machen. Nebenbei könnten wir ja noch das Area-Problem lösen.;) Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Am 05.05.2011 16:27, schrieb M∡rtin Koppenhoefer: Am 5. Mai 2011 16:13 schrieb fly lowfligh...@googlemail.com: Nebenbei könnten wir ja noch das Area-Problem lösen.;) Welches? Mir fallen da einige ein. http://wiki.openstreetmap.org/wiki/The_Future_of_Areas/Problems ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Am 05.05.2011 16:53, schrieb M∡rtin Koppenhoefer: Am 5. Mai 2011 16:35 schrieb fly lowfligh...@googlemail.com: http://wiki.openstreetmap.org/wiki/The_Future_of_Areas/Problems ach so, das hat damit ja nun gar nichts zu tun. Ich dachte eher an flächige Treppen, Straßenflächen, etc. Für Treppen gibt es ein Proposal. Doch genau deshalb will ich nicht anfangen eine Straße als Fläche einzuzeichnen, bzw sie als Zusammenfassung von Flächen ( rechter Gehweg, Grünstreifen, rechter Parkstreifen, rechter Fahrradweg ... linker Gehweg) eintragen. Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Am 05.05.2011 21:11, schrieb Felix Hartmann: Etwa diese Krezung hier: http://www.openstreetmap.org/?lat=48.248268lon=16.388447zoom=18layers=M Ist derzeit einfach nicht auch nur halbwegs korrekt eintragbar, mit unserem derzeitigen Datenmodell (weder ist das Autorouting korrekt, noch die Anzeige). Dabei ist die noch gar nicht so komplex (und Fuß und Radwege sind gar nicht eingetragen). Wobei erschwerend natürlich noch dazu kommt, dass es sich hier um eine Kreuzung auf einer Brücke handelt. (und das falscheste ist, es gibt hier nicht zwei separate Brücken, sondern nur eine auf der beide Fahrtrichtungen verlaufen - aber die Brücke ist nicht als Relation eingetragen - was sie eigentlich müsse, aber fast nirgends korrekt ausgewertet wird). Die Fahrradwege von Südosten zur Brücke hin funktionieren so auch nicht: - entweder alle drei Wege treffen sich auf der Brücke oder dort ist gar keine Brücke. Gibt es eigentlich schon einen Tag für Brückenpfeiler ? Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Am 05.05.2011 22:09, schrieb Peter Wendorff: Selbst Zebrastreifen sind nicht unbedingt uneingeschränkt rollitauglich ausgestattet, und du willst ja gekennzeichnete Überwege nicht mit entsprechenden Tags ausstatten. Bleibt Oma Erna also also abseits der Großstädte nur, OSM wegzulegen und, wenn es irgendwie geht, weiterhin zu Hause zu bleiben. Ein zugegebenermaßen Übergangslösung ist auch das Tag wheelchair=* kann ja noch mit description ergänzt werden. Wobei ich dem Ansatz einen Winkel zur Orientierung zu benutzen gar nicht schlecht finde. Ob das nun Uhrzeiten, Grad oder etwas ähnliches ist. Bis dann fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] probleme mit Bing imagery
Am 29.04.2011 14:10, schrieb M∡rtin Koppenhoefer: Am 29. April 2011 13:16 schrieb Stefan Bethke s...@lassitu.de: Am 29.04.2011 um 13:05 schrieb M∡rtin Koppenhoefer: irgendwie habe ich seit gestern (mindestens) Probleme in Josm-latest, dass bei Bing grundsätzlich steht: no tiles at this zoomlevel, selbst weit rausgezoomt (und hier sind die Bilder grundsätzlich eigentlich bis Z.21 vorhanden). Hat noch jemand dieses Problem, oder ist das ein lokales Problem? Kein Problem hier (Ubuntu und Mac, 4064). Seltsam, weil ich das nur bei Bing habe, WMS, Yahoo und OSM-Tiles gehen z.B., das Bing Logo unten links wird auch eingeblendet, aber Tiles bekomme ich nicht (Zoomeinstellungen für Tiles von 2 bis 21). Allerdings habe ich gerade bemerkt, dass unten rechts steht: Error loading Bing attribution data. Was könnte ich denn tun, um das Problem einzugrenzen/zu lösen? Dies hast Du ja schon: josm.openstreetmap.de/wiki/Help/ErrorMessages#Imagery:ErrorloadingBingattributions und josm.openstreetmap.de/ticket/5765 Versuche es mal mit einem proxy. Vielleicht bleibst Du auch in Deiner Firewall hängen. Beachte, dass Du JOSM neu starten mußt, damit imagery die neuen Verbindungseinstellungen benutzt. Viel Erfolg fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Ich glaube, ich würde hier teilweise falsch verstanden: Darum will ich hier nochmal kurz meine Punkte vortragen: 1. Meiner Ansicht gibt es keinen Grund für footway und cyleway, da diese entweder track oder path sind. Alles andere kann mit Zusatztags und entsprechenden Presets gelöst werden. 2. Es gab bisher keine Lösung einen Gehweg und Übergänge exakt einzutragen und habe selber schon die Erfahrung mit nur an einer Seite abgesenktem Bordstein gemacht. Dieses Problem ist aber viel größer als nur Gehwege, sondern beinhaltet die ganze Fahrliniendiskussion. Somit ist die neue Lösung nur ein weiterer Schritt, jede Fahrspur einzeln einzutragen und das alles in eine Relation zu packen. Ich habe damit kein Problem (würde viele tags nur einmal in der Relation brauchen), frage mich aber welcher Editor es unterstütz automatisch eine neue Spur auch die richtige Relation zu zuordnen. Das alles über Areas zu lösen ist zur Zeit wohl auch keine Lösung. 3. Ich halte es für kritisch für Gehwege ein highway=footway zu benutzen, da durch alle Renderer betroffen sind. Auch ist highway=* entgültig kein seperater Weg mehr. Außerdem geht der Bezug zur Topologie, hier der Straße, verloren. Das ein Bordstein eine Barriere darstellt und gleichbedeutend wie ein Grünstreifen ist, ist meiner Ansicht, ein sehr dünnes Argument. Ich kenne ein paar Rolli-Fahrer und da gibt es gewaltige Unterschiede, was als Barriere angesehen wird. Für manche sind sogar fünf Treppenstufen kein Problem und ein Bordstein ist für mindestens die Hälfte kein Hinderniss. Ein Grünstreifen wird aber immer vermieden und ist auch für zB einen Kinderwagen eine größere Hürde. 4. Wenn wir schon über Unterkategorien von footway reden, sollten wir den Karren neu auffahren und gleich über Unterkategorien/Zusatztags für path und track reden. Ich hoffe meine Punkte sind jetzt etwas klarer. Leider habe ich auch keine direkte Lösung parat. cu fly P.S.:Es gibt ein Proposal für Kreuzungen, vielleicht könnte man damit auch Übergänge lösen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Am 27.04.2011 18:54, schrieb Peter Wendorff: Hi. Ich kürze mal das Zitat und antworte dazwischen: Am 27.04.2011 17:03, schrieb fly: Ich habe diese und ähnliche Diskussionen jetzt schön öfters verfolgt und werde jetzt wohl doch einmal Stellung nehmen. Meiner Meinung nach sind wir beim highway-tag nicht konsequent wie der tag verwendet wird. Bei Straßen gehen wir auf Verkehrsdichte und Verkehrsbedeutung ein und bei Wegen wird das access-tag mit reingewurstet. Soweit gebe ich dir recht. Das schlimmste ist jawohl highway=living_street, was unbedingt mal in highway=* + living_street=yes geändert werden sollte, analog zu motorroad,cycleroad Hier allerdings nicht. Meiner Interpretation nach ist highway=living_street die deutsche Spiel- und österreichische Wohnstraße sowie den schweizer Begegnungsbereich [1]. In England wird es als Home zone bezeichnet [2] Bei näherer Betrachtung muss ich zugeben: ich weiß nicht, wie das außerhalb von DACH aussieht, aber das Wiki passt zu dieser Interpretation [3]. Nimmt man dies zugrunde, so handelt es sich um einen signifikant anderen Straßentyp als das, was OSM unter residential fasst, mit eigenen Regeln und meist verringerter Verkehrsbedeutung. Genau da ist der Haken. Die Straße unterscheidet sich nicht umbedingt von highway=residential, öfters ist es auch solch eine Straße, nur mit Zusatzregeln, welche besser als seperater Tag angegeben werden und nicht mit in den highway-tag sollten. Entsprechend ist highway=living_street berechtigt und sinnvoll - solange man es nicht, wie ich bei dir vermute, als Straße mit Wohnbebauung oder sowas interpretiert. Ich verzichte ganz auf footway und cycleway, benutze dafür aber *=official um deutlich zu machen was für ein blaues Schild da steht plus segregated=yes/no. Bei Wegen bis zu zwei Meter Breite verwende ich path, ansonsten track. Leider werden die tracks bisher von keinem Renderer gut dargestellt. Zu allem Überfluss wurde gerade auch noch highway=footway + footway=sidewalk für Gehwege etabliert: wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way Warum das überflüssig ist, musst du mir erklären. Gib mir eine Möglichkeit, Querungsstellen (z.B. Zebrastreifen) zu taggen und dabei die Ausstattung beider Ufer zu berücksichtigen (Bordstein abgesenkt? Taktil gepflastert?), und ich stimme dir vielleicht zu. Wenn es überflüssig ist, weil du den footway für überflüssig hältst: Ja, deine Argumente für die Nutzung von path STATT footway/cycleway sind schlüssig, denen könnte ich mich anschließen. Ich habe das Proposal zu footway=sidewalk aber auch nicht so verstanden, dass es darauf beschränkt sein oder bleiben muss. Genauso denkbar ist auch highway=path; bicycle=official; foot=official; segregated=*; path=sidewalk. Nein, ich halte Gehsteige nicht für überflüssig. Ich bin nur dagegen, diese als Unterkategorie von footway zu definieren, sondern entweder ohne highway=* als seperaten Weg, oder doch eher mit an die eigentliche Straße als tag: sidewalk=none/left/right/both. Als Unterkategorie, muß jetzt jedem Renderer der Unterschied zwischen footway und sidewalk beigebracht werden. Zu Zeit gibt es keinen Unterschied und so werden alle sidewalks falsch dargestellt. Außerdem geht der Bezug zur eigentlichen Straße verloren. Ich habe auch meine Problem an Kreuzungen, gerade wenn der Bordstein nur auf einer Seite abgesenkt ist. Hier finde ich es auch sinnvoll Übergänge seperat zu zeichnen, allerdings nicht als highway=*, sondern z.B als crossing=path/track oder auch mit highway=crossing + crossing=* Wenn umbedingt ein highway-tag verwendet werden soll, dann bitte als ein neuer Wert, aus dem klar wird, daß der Weg zur Straße gehört und nicht einfach als eine Unterkategorie von footway Bis dann fly [1] http://de.wikipedia.org/wiki/Spielstra%C3%9Fe [2] http://en.wikipedia.org/wiki/Home_zone [3] http://wiki.openstreetmap.org/wiki/Tag:highway%3Dliving_street ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Am 27.04.2011 10:45, schrieb Martin Simon: Am 27. April 2011 10:19 schrieb Boris Cornet bor...@osm-at.org: Hallo! Darf ich noch etwas Öl ins Feuer gießen? In Österreich - so ich das überblicken kann - wurde der Vorschlag, path für Geh-/Radwege zu verwenden, glücklicherweise nicht übernommen - vielleicht weil hier der Wanderkarten-Aspekt deutlicher gesehen wird. In meinen Augen kommt man mit dem WischiWaschi-Path vom Regen in die Traufe. Das Problem vom unglücklichen cycle/footway auf den path zu verlegen bringt nichts ausser noch mehr Uneinheitlichkeit. Nein, es bringt einen Wegtyp unterhalb track mit möglichst wenig Implikation, der es ermöglicht, Nutzungsrechte genau und einzeln zu definieren. Das ist gut. Der 'normale' user versteht path als 'Pfad', also 'unbuilt single dirt track', und das ist gut so. Path ist der ideale Tag für Wanderwege im freien Gelände. Sobald man künstlich etwas anderes hinein interpretiert, Was du hiermit tust. path ist *nicht* mit Trampelpfad gleichzusetzen. bike path heiß z.B. Radweg und ist durchaus gerne asphaltiert... ist man gezwungen, mittels zusatztags die Nutzergruppen festzulegen. Das ist man, wenn man *nichts* künstlich hinein interpretiert - und das ist gut. Also müsste man jetzt bei allen Wanderwegen foot=yes, bycicle=no anfügen, Warum? Was ist für dich ein Wanderweg? Ein Weg, über den eine Wanderroute führt? Ein unbefestigter Weg? Ein befestigter, schmaler Weg? Ist Fahrrad fahren in den gesamten Alpen verboten? und noch darauf achten, dass kein mensch auf die Idee kommt, foot=designated zu schreiben, denn die werden unter Mapnik als footway gerendert, und footways in den Alpen sind ein absolutes NO-GO! Man muss Leute daran hindern, einen tag zu benutzen, weil _Mapnik_ dann eine Farbe verwendet, die DU in den Alpen nicht sehen möchtest? Hallo? Die Information, die du sehen möchtest, steckt nicht in path/footway, sondern in width,surface, incline und sac_scale(sowie in Routen-Relationen). Typischer Fall von taggen für den Renderer... Übrigens sind viele dieser cycle/footway-paths im Freiland eigentlich tracks (grade1), weil sie oft auch legal von traktoren u.ä. befahren werden. IMHO ist die einzige Lösung des Dilemmas eine neue highway-kategorie, etwas was einen generischen Fahrweg darstellt - möglicherweise auch ein revival von highway=road. Was, du forderst die Einführung von highway=path? Überraschung: wir haben es schon! Frage: würden wir jetzt *noch einen* tag dieses typs einführen, würden Leute wie du nicht schon wieder ankommen und ihn zu einem Spezialfall umdefinieren, weil z.B. die Farbe in Mapnik so schön passt? ;-) Absolut nicht sinnvoll ist es, einen bestehenden und gut eingeführten Weg-Typ (path) umzudefinieren. Bitte lies das Wiki und das ursprüngliche Proposal. Du definierst hier um und merkst es noch nicht einmal. Ich habe diese und ähnliche Diskussionen jetzt schön öfters verfolgt und werde jetzt wohl doch einmal Stellung nehmen. Meiner Meinung nach sind wir beim highway-tag nicht konsequent wie der tag verwendet wird. Bei Straßen gehen wir auf Verkehrsdichte und Verkehrsbedeutung ein und bei Wegen wird das access-tag mit reingewurstet. Das schlimmste ist jawohl highway=living_street, was unbedingt mal in highway=* + living_street=yes geändert werden sollte, analog zu motorroad,cycleroad Ich verzichte ganz auf footway und cycleway, benutze dafür aber *=official um deutlich zu machen was für ein blaues Schild da steht plus segregated=yes/no. Bei Wegen bis zu zwei Meter Breite verwende ich path, ansonsten track. Leider werden die tracks bisher von keinem Renderer gut dargestellt. Zu allem Überfluss wurde gerade auch noch highway=footway + footway=sidewalk für Gehwege etabliert: wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_as_separate_way Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bolzplatz
Am 20.04.2011 12:15, schrieb Sven Geggus: Jan Tappenbeck o...@tappenbeck.net wrote: nicht schlagen, wenn schon 100x gefragt wurde. aber wie ist ein Bolzplatz zu taggen ? Ballsport Fussball finde ich zu hochgegriffen. Würde das in der Kategorie Freizeit einordnen. leisure=pitch sollte es doch nach wie vor geben, oder? plus surface= cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe: Leere Relation E 54 Europastraße
Am 15.04.2011 20:39, schrieb Toni Erdmann: Am 15.04.2011 20:03, schrieb Toni Erdmann: Am 15.04.2011 19:55, schrieb Toni Erdmann: Am 15.04.2011 19:53, schrieb M∡rtin Koppenhoefer: Am 15. April 2011 19:46 schrieb Toni Erdmanntoni.erdm...@web.de: Hallo zusammen, wie gesagt: die Relation 77040, Europastraße E 54 ist leer, und dass mit der Version 455. Das ist der Link zur Version 454: http://api.openstreetmap.org/api/0.6/relation/77040/454 Danke Martin, also rein damit in JOSM und hochladen: gefixed? wget -O E54.osm http://api.openstreetmap.org/api/0.6/relation/77040/454 dann E54.osm in JOSM öffnen. OK, drei Ways sind in der Zwischenzeit gelöscht worden am 8.4.2011, die musste ich aus der Relation rausnehmen. Für sowas gibt es das undelete Plugin ! Welche waren denn das ? Es gibt by JOSM auch das reverter-plugin, was noch besser funktioniert als die manuelle reperatur. Damit kannst du auch mehrer Objekte eines Changesets und sogar mehrere Changesets gleichzeitig zurücksetzen. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ICE-Relationen
Am 17.04.2011 14:03, schrieb Wolfgang: Hallo, Am Sonntag 17 April 2011 11:25:11 schrieb Carsten Gerlach: Hallo, Am Montag 11 April 2011 schrieb fly: Ich frage mich ob man bei den ICE-Relationen nicht lieber Relationen für die Strecke zwischen einzelnen Bahnhöfen anlegt und diese Relationen jeweils den ICE-Relationen zuordnet. Klingt nicht schlecht diese Idee, aber was ist, wenn zwei ICE-Linien zwischen zwei Bahnhöfen unterschiedliche Gleise verwenden? Soll das dann auch in zwei Relationen abgebildet werden? Konkretes Beispiel: Der ICE Köln-Berlin fährt in Duisburg auf Gleis 13 ab, kommt in Essen auf Gleis 6 an. Der ICE München-Dortmund fährt in Duisburg auf Gleis 13 ab, kommt in Essen auf Gleis 4 an. ich steck da jetzt nicht so tief im Thema drin, aber hast du keine Angst, etwas zu übertreiben? Ich kenne das eigentlich so bei der DB, das der Zug überall abfährt und ankommt, nur nicht auf dem vorgesehenen Gleis. Es sollte eigentlich ausreichen, die Relation von Duisburg nach Essen zu definieren. Notfalls kann man die Gleise ja in eine site packen. Oder in ein Multipolygon, dann kreisen sie immer um den Hbf :-) Wenn der eine Zug über Mülheim und der andere über Oberhausen fährt, wäre das natürlich etwas anderes. Bin mir auch nicht sicher, ob die Bahnhofs-Gleise wirklich so exakt anzugeben sind. Denke hier nimmt man eher alle wo auch gehalten werden kann (die länge ist da wohl entscheident). Falls man wirklich über exakte Gleise aussagen treffen will, kann man ja bis zur entscheidenten Weiche als Abschnitts-Relation mappen und die Bahnhofsgleise wieder in die Haupt-Relation packen. Bis bald fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe: Leere Relation E 54 Europastraße
Am 17.04.2011 15:52, schrieb Toni Erdmann: Am 17.04.2011 15:57, schrieb fly: Am 15.04.2011 20:39, schrieb Toni Erdmann: Am 15.04.2011 20:03, schrieb Toni Erdmann: Am 15.04.2011 19:55, schrieb Toni Erdmann: Am 15.04.2011 19:53, schrieb M∡rtin Koppenhoefer: Am 15. April 2011 19:46 schrieb Toni Erdmanntoni.erdm...@web.de: Hallo zusammen, wie gesagt: die Relation 77040, Europastraße E 54 ist leer, und dass mit der Version 455. Zu solchen Relation gilt im Übrigen das Gleiche wie zu den ICE-Relation. Kann man die nicht nach Ländern oder sogar in noch kleine Teile Gruppieren ? Wenn eine Bundestraße oder Autobahn die ganze Zeit auch Europastraße ist, kann man auch die ganze BS/BAB-Relation in der E-Relation aufnehmen Das ist der Link zur Version 454: http://api.openstreetmap.org/api/0.6/relation/77040/454 Danke Martin, also rein damit in JOSM und hochladen: gefixed? wget -O E54.osm http://api.openstreetmap.org/api/0.6/relation/77040/454 dann E54.osm in JOSM öffnen. OK, drei Ways sind in der Zwischenzeit gelöscht worden am 8.4.2011, die musste ich aus der Relation rausnehmen. Für sowas gibt es das undelete Plugin ! Welche waren denn das ? 3c3 relation id=77040 visible=true timestamp=2011-04-02T19:20:12Z user=Flacus uid=77446 version=454 changeset=7747354 --- relation id=77040 visible=true timestamp=2011-04-15T18:36:46Z user=ToniE uid=8748 version=456 changeset=7872293 596d595 member type=way ref=54570668 role=/ 598,599d596 member type=way ref=54621962 role=/ member type=way ref=54570669 role=/ Aus der B 316, vermute ich. Nachzuschau ist besser. Da würde doch ein bisschen übermütig aufgeräumt. Es geht um diesen Kreisverkehr: http://www.openstreetmap.org/?lat=47.5773011147976lon=7.79675781726837way=27164192zoom=18 Ich bin mir nicht sicher ob ich die Relationen (vorallem die public_transport mit Richtungen) hier richtig hinbekomme. Mache mich aber an die Arbeit. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und Hausnummerneingabe
Ich selber verwende ja immer die associatedStreet Relation und gebe den Häusern (Points/closed-ways) nur addr:housenumber (+building). Das AddrInterpolation-Plugin kann auch einzelne nodes erzeugen ! Habe ich allerdings noch nie benutzt Auch das Terracer-Plugin kann Gebäuden Hausnummern anfügen ! Wieweit das mit allein stehenden Häusern funktioniert, habe ich noch nicht geteste, aber bei aneinanderhängenden Häusern funktioniert es wunderbar. Nur mit der associtefStreet-Relation funktioniert es leider noch nicht richtig. So muß ich leider die Objekte noch manuell als Mitglieder deklarien. Auch nicht viel Arbeit, aber halt noch keine Automatisierung ohne sich mit Relationen beschäftigen zu müssen. Schade. Viel Erfolg fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ICE-Relationen
Hi Ich frage mich ob man bei den ICE-Relationen nicht lieber Relationen für die Strecke zwischen einzelnen Bahnhöfen anlegt und diese Relationen jeweils den ICE-Relationen zuordnet. Im Momment sind die ICE-Relation doch sehr groß und auf manchen Strecken fahren eine ganze Menge ICEs ganz zu schweigen von EC/ICs und sonstigen Verbindungen. Im Unterschied zu Bus/Straßenbahn-Linien verlaufen diese Linien lange auf der selben Strecke. Was ist Eure Meinung ? cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sanitätsbedarf - Wiki angelegt
Am 06.04.2011 11:26, schrieb Jan Tappenbeck: Hi ! habe mal eine Wiki-Seite angelegt. http://wiki.openstreetmap.org/wiki/DE:Tag:shop%3Dmedical_supply (Englisch und Deutsch) da fehlt ja zumindest noch um was es geht !! find nirgends auf der Seite shop und medical_supply Ciao fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aktion 15 - Japans Nordosten
Am 04.04.2011 11:13, schrieb Dietmar: Hallo Gerhard, Der Süden Japans ist erstmal nicht mehr erforderlich, derzeit werden massiv neue Straßen importiert über [1]. Ich habe auf japan-talk mal nachgefragt, ob die noch importieren und die wiki Seite ins englische übersetzen können. Wenn da mal alles klappt und nicht wieder lauter unconnected highways entstehen erspart das eine Menge Arbeit. Sinnvoll wäre auch den von anderen Anbietern am schlechtesten abgedeckten Teil zuerst abzuarbeiten. Vorerst dürfte ein gebietsweises arbeiten erstmal sinnvoller sein, die Fehler liegen z.T. in großer Menge direkt nebeneinander. Vielleicht kann man die Berechnung auch besser einteilen. (kleinere Gebiete berechnen, Filtern der Ausgabe nach Positionen) ? Möglichst zeitnahe Updates wären schon weiter schön ;) Vielleicht sollten wir auf der Aktionsseite gebietsweise Edits zusätzlich eintragen, damit auch der Hinsicht Transparenz für alle an der Aktion Beteiligten vorhanden wäre. das hilft leider nicht viel. Ist die gebietsweise Abarbeitung auch aus Sicht Anderer sinnvoll? Ich habe schon jetzt immer Validator in JOSM benutzt und das ganze Gebiet auf Fehler überprüft. Leider findet Validator zur Zeit keine unconnected highways. Ticket existiert! cu fly [1] http://wiki.openstreetmap.org/wiki/JA:Yahoo_Data_Import_Highway ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Nuklearkarte Deutschland
Am 02.04.2011 15:39, schrieb Jens Frank: Hallo, 2011/4/2 Gary68 g...@gary68.de So, neu, nun mit allem, was ich gefunden habe: http://wiki.openstreetmap.org/wiki/File:MapgenGermanyNuclear.pdf Zur Standortbewertung müsste man sich natürlich noch anschauen, ob man nicht evtl in der Nähe ausländischer AKWs wäre. Frankreich stellt seine AKWs z.B. gerne in Grenznähe auf. Die Schweiz ist da auch nicht besser, wobei Leibstadt ja schon angezeigt wird. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check für unverbundene route=ferry?
generell sind diese Checks nicht umbedingt Fehler. Am 30.03.2011 15:11, schrieb Henning Scholland: Am 30.03.2011 14:50, schrieb fly: Ich würde checken auf: * schneiden mit andern route=ferry. Das ist kein Fehler. Oder bist du schon mal unterwegs von einer Fähre auf die nächste umgestiegen? Ja auch das ! Hast Du recht, wobei ich dabei eher an Verzweigungen gedacht habe. Sollte aber mit dem unconnected first/last node check abgefangen werden. * schneiden mit coastline Führt zu vielen falschen Fehlern, wenn die Fähre zu einer Straße wird (Anleger). Fähre und Straße mit der coastline zu verbinden mache ich idR nicht, da coastline was recht sensibles ist. Ein Fähranleger schwimmt oder er ist die Küstenlinie alles andere macht keine Sinn ! Dort ist dann genau der Schnittpunkt. * schneiden mit highways mit gleichem layer. Ob man das extra checken muss? Sicher ist es ein Fehler, aber sowas wird doch bestimmt schon bei den highway-checks mit überprüft, oder? Ich kenne keinen aktuell laufenden check für die Küstenstraßen von Mittelmeer und Nord/Ostsee. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check für unverbundene route=ferry?
Am 30.03.2011 14:19, schrieb Henning Scholland: Am 29.03.2011 16:48, schrieb malenki: Henning Scholland schrieb: ich hatte aus einem ähnlichem Grund vor ca. einem Jahr mal einen sochlen Check für Deutschland und Nordeuropa gemacht [1]. Der basierte auf checkconn.pl von Gary68 [2]. Man muss in dem Perlscript nur die zu prüfenden Tags ändern. Ich hatte route=ferry mit allen bekannten highway-Typen geprüft. highway=* scheint nicht zu funktionieren, oder? Ich hab's mit highway=* glaub ich nie probiert, aber meine Vermutung war damals, dass man die values explizit angeben muss. Gary68 macht doch ähnliche checks bei seine Aktionen. Unteranderem hat er checks für crossing und für unconnected ways. Soviel ich verstehe werden da jeweils zwei listen von typen in bezug gesetzt. Bei Fähren besteht die erste Liste nur aus route=ferry. Ich würde checken auf: * schneiden mit andern route=ferry. * schneiden mit coastline * schneiden mit highways mit gleichem layer. * endnode einer route=ferry nicht verbunden. Sollte alles mit den scripten für Japan laufen !! Viel Erfolg fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] n paar Fragen
Am 30.03.2011 14:41, schrieb Tobias Knerr: Am 30.03.2011 14:04, schrieb Wolfgang: wobei ich da der Meinung bin, wenn man schon eine extra Auswertung (also z.B. site-relationen) macht, kann man auch gleich die Polygone auswerten, die mit Adressen getaggt sind, und nachsehen, was da jeweils innerhalb liegt. [...] Eine zusätzliche Relation schafft hier Klarheit. Damit ist eindeutig geklärt, welche Adresse mit welchem Polygon und welchem Node zusammengehört. Die Tatsache, dass ein Node in einem Polygon liegt, bedeutet nicht in jedem Fall, dass auch die Adresse gleich ist, z.B. bei Eckgrundstücken. Nein, nicht in jedem Fall. Aber in den Fällen, wo es keine explizite abweichende Adressangabe für den Node gibt, ist es exakt so zu interpretieren. Bei Wohnblocks mit einer größeren Zahl von Eingängen wird meistens die Adresse nur als Node am Eingang angegeben. Da funktioniert die Polygon-Methode gar nicht. Die sehe ich eher als die Methode an, die man benutzt, wenn die Relation fehlt. Ich sehe die Relation als eine Methode an, die man höchstens in den (relativ gesehen seltenen) Sonderfällen braucht, die jetzt schon wieder hervorgekramt werden. Einfacher Fall in der Realität: Gebäude mit einer Adresse, alle Eingänge des Gebäudes und die Läden darin haben auch diese Adresse. Umsetzung in OSM: Gebäudeumriss mit Adress-Tags versehen, Nodes für die Läden ins Innere der Fläche und ggf. Eingänge in die Umrandung setzen. Können wir erst einmal festhalten, dass das in diesem normalen Fall ausreicht? Damit wäre die eigentliche Frage nämlich beantwortet. + 1 site-relation nur wenn es wirklich nötig ist !! Danach kann weiter über die Exotenfälle diskutiert werden, solange keiner verlangt, dass jetzt jedes 0815-Gebäude eine Relation braucht. @Wolfgang: Warum hast Du die tags den alle im Label-node und nicht in der Relation ? Wenn Du schon einen Label-node verwendest, warum sind beide direkt nebeneinander an einer Seite des Geländes ? So wird es dem renderer erstrecht schwer gemacht. Gruß fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lagegenauigkeit
Am 19.02.2011 09:39, schrieb Florian Lohoff: On Fri, Feb 18, 2011 at 11:44:48PM +0100, Garry wrote: Am 18.02.2011 15:27, schrieb Florian Lohoff: Fuer Nutzer ist es viel wichtiger zu wissen auf welcher Straßenseite der Briefkasten steht als das die Straße 5m neben irgendwelchen Koordinaten liegt. Du verallgemeinerst Deine Sichtweise... Wenn man Luftbilder oder andere Karten (z.B. eingescannte Pappierkarten) nach OSM Daten georeferenzieren möchte ist es ärgerlich wenn entgegen besseren Wissens die Strasse nicht korrigiert wurde nur damit der Briefkasten auf der richtigen Strassenseite bleibt. Es spricht nichts dagegen wenn die Lagegenauigkeit korrigiert wird die Topologie beizubehalten. Ja, um so mehr ärgert es mich wenn Hausnummern nicht mit verschoben werden und nun alle Hausnummern auf einer Seite der Straße liegen. Bitte haltet die Topologie bei. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 06.02.2011 17:22, schrieb Sven Anders: Nachdem ich mich durch den Wald an Nachrichten zu diesem Thema gewühlt habe und es so aussieht als ob sich langsam was sinnvolles aus der Diskussion ergibt, habe ich noch ein paar Anmerkungen: Ja, genau das habe ich mit dem Aufbau des TMC Validators [1] bezweckt. Er hat sicherlich viele Schwächen und zeigt z.Z. auch an manchen Stellen blödsinn an (weil ich mal wieder Basteln musste, arbeite aber schon an einer Korrektur). Klingt gut. Warum vergißt der TMC-Validator eigentlich so häufig seine Daten ? Achtet der nicht nur auf Veränderungen ? Sicherlich fallen bei Pascals Auswertungen von OSM-TMC auch noch Validator daten an. Allerdings brauchte man vermutlich noch eine Meta Datenbank dazu, um die ungereimtheiten im TMC zu dokumentieren. (z.B. Straßen die zwar in TMC Daten noch existieren, in der realität aber nicht mehr). oder erst im Bau sind, bzw in Planung und manchmal nie in die Realität umgesetz werden. Auch kenne ich Stellen, wo zur Zeit noch der alte Datensatz aktuell ist, weil man sonst von der Bundesstraße abbiegt und direkt im Baustellenstau landet. So haben wir auch schon einige Fehler in den TMC-Daten entdenkt. Und das Tagging-Schema ist ja noch nicht einmal in sich konsistent (es gibt z.B. keine Einigkeit darüber wo der Knotenpunkt für eine Autobahn-Auffahrt am sinnvollsten gesetzt werden sollte.) Endlich wird das auch erwähnt. Für mich sind TMC-Points die Wege zwischen Ab- und Auffahrt und nicht nur ein Knoten. Eine Kreuzung ist in OSM häufig nicht nur Knoten. fly [1] http://osm-tmc.anders-hamburg.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
Am 27.01.2011 18:56, schrieb ant: Hi, On 27.01.2011 10:49, Richard Mann wrote: I think we've got three broad decisions: 1) Whether the use of stop area / group relations should be a) widespread b) exceptional b a) possibility to micromap. 2) Whether route relations should a) contain all the variants in one relation, with no attempt at ordering, just stops identified as forward/backward b) try to match all the individual stop-sets that you might find in a timetable c) contain an ordered set of ways/stops, in whatever fashion the mapper feels appropriate b (by the way: how would (a) work in the case of a ring line?) c) with b) prefered 3) Whether there should be a new public_transport key, to try to clarify the bus_stop/tram_stop distinction a) aim to move tram_stops to alongside the track, and put something else (tram_stop_group / tram_station?) on the track b) aim to move bus_stops onto the road, and put something else (platform?) alongside c) encourage the use of platforms on tram systems, and use those in the relation instead of tram_stop d) add a new public_transport key, so that public_transport=platform can be used for everything c and d (we shouldn't redefine tags that are in million-times use!) why not use public_transport=stop_position and platform from OXAMA cheers ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-de] catastre-fr: gebäude farben und meer a ngaben
Danke für Eure Anworten. Bin gerade informiert worden, daß die Gebäude semi-automatisch importiert werden. Somit hat sich das erstmal erledigt. Zu den Küsten kann ich nur sagen, das die vorhanden Daten viel ungenauer waren als die catastre-Daten. Bis bald colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Am 16.08.2010 21:44, schrieb Thomas Ineichen: Hallo fly, We sieht das eigentlich für wheelchair dann aus wenn vehicle=no gesetzt ist ? wheelchair=* wird eher für die physische Zugänglichkeit (e.g. Toiletten, Treppen, ...) genutzt. Mir ist allerdings kein Land bekannt, in dem Rollstühle von einem allg. Fahrverbot erfasst werden. Dann ist aber die Klassifizierung unter vehicle auf der access-Seite falsch und wheelchair sollte unter Besonderheiten und nicht unter vehicle=* stehen. Grüß colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Am 06.08.2010 18:19, schrieb Heiko Jacobs: Jens Wahnes schrieb: Für Deutschland möchte ich mal behaupten, daß es eine reine Fahrradstraße (ohne Freigabe für andere Verkehrsteilnehmer) in der Praxis überhaupt nicht gibt. Demjenigen, der mir als Erster eine ausschließlich mit Verkehrszeichen 244 ausgeschilderte Fahrradstraße zeigt, gebe ich jedenfalls gerne ein Eis aus. Das war uns ein Titelbild wert: http://umverka.de/hefte/heft305/titel.jpg *wart* ;-) Gruß Mueck Hier sollte aber auf jeden Fall noch ein footway=both gesetzt werden was dann wieder foot=designated impliziert. We sieht das eigentlich für wheelchair dann aus wenn vehicle=no gesetzt ist ? Gruß colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 16.08.2010 02:49, schrieb Stephan Wolff: Am 14.08.2010 17:05, schrieb M∡rtin Koppenhoefer: Am 1. August 2010 20:39 schrieb Hartmut Holzgraefehart...@php.net: On 08/01/2010 05:48 PM, Klaus Hanauer wrote: Also es ist (meistens) nicht nur korrekt ist es nicht, denn die Flächen links und rechts der Straße haben in Wirklichkeit keine gemeinsame Kanten sehe ich auch so, es ist in allen Fällen falsch, wo ein Weg dazwischen liegt. Lässt du wirklich jedes Waldstück zwei Meter rechts vom Waldweg enden und zwei Meter links des Weges neu beginnen? Trennst du jedes landuse-Gebiet an jedem Weg und jeder Straße? Falls nicht, dann gibt es auch keinen Grund für eine Lücke, wenn links Laub- und rechts des Weges Nadelwald ist. Wenn eine Straße mit beidseitiger Wohnbebauung innerhalb eines residential-Gebiets liegen kann, dann kann sie bei einseitiger Wohnbebauung auch zur Hälfte darin liegen. Nur die Modelle Straßen und Wege sind nie innerhalb oder auf der Grenze eines landuse-Gebiets oder Straßen und Wege sind Bestandteil eines landuse-Gebiets. Bei unterschiedlicher Nutzung liegt die Grenze der landuse-Flächen in der Straßenmitte sind logisch konsistent. Ich bevorzuge die zweite Interpretation. Bei großen Flächen sehe ich kein Problem dabei Wege und Straßen nicht mit einem eigenen landuse= einzutragen, obwohl es ja nicht exakt ist. Kommt auf den grad des Mappens an. Bei landuse= -Grenzen sollten diese sich aber nur berühren, wenn kein Übergang/Straße/weg besteht. cu colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was is'n 'ne Eisdiele
Am 13.08.2010 17:08, schrieb Chris66: Am 13.08.2010 16:45, schrieb Claudius: Finde nach diesen Zeilen shop=ice_cream für einen Eis-Straßenverkauf gar nicht mehr dumm :) Aber das Aufräumen lässt sich da wohl kaum mit einem Bot bewerkstelligen, da man wohl immer vor Ort feststellen muss, ob eine Eisdiele oder ein Eiscafé vorliegt. ich will auch nicht das amenity=cafe+cuisine=ice_cream (Eiscafe) ersetzen, sondern amenity=ice_cream durch shop=ice_cream. Oder man lässt es so und interpretiert amenity=ice_cream als Eiswagen und shop=ice_cream als Eisdiele. ;-) Es gibt ein proposal für amenity=ice_cream um alle shops und cafes zu ersetzten. Allerdings gibt es Widerstand, da sowas nicht mehr unter amenity soll. Gruß colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Grenzen: multipolynom - boundary
Was ist die Bezeichnung von Grenzen? type=multipolynom oder type=boundary ? In D wurden die Grenzen als multipolynome importiert, aber was spricht gegen type=boundary ? Auf der deutschen Wiki-Seite steht kein Verweiß zu multipolynome, jedoch auf der englisch-sprachigen: wiki.openstreetmap.org/wiki/DE:Relation:boundary Sollten wir nicht eher boundary verwenden, um sie von Landflächen und anderen Multipolynomen abzugrenzen ? Grüß colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenzen: multipolynom - boundary
Am 11.08.2010 11:24, schrieb Frederik Ramm: Hallo, fly wrote: Was ist die Bezeichnung von Grenzen? multipolygon. (Ein Polygon ist ein Vieleck. Ein Multipolygon ist eine Gruppe von einem oder mehreren solchen Vielecken.) das habe ich mich ja fürchterlich vertippt. Das nächste Mal wohl besser auf deutsch. In D wurden die Grenzen als multipolynome importiert, aber was spricht gegen type=boundary ? Dagegen spricht, dass man die Tatsache, dass es sich um eine Grenze handelt, bereits am boundary=administrative erkennt. Von der geometrischen Verarbeitung her ist eine Grenze aber nichts anderes als z.B. ein Waldgebiet oder so (Aussenlinie, die aus mehreren Stuecken bestehen kann; 0 oder mehrere innere Bereiche, die ebenfalls mehrere Stuecke haben koennen). Wenn man nun anfinge, verschiedene Arten von Multipolygonen mit unterschiedlichen type=... zu belegen, dann muesste jeder, der die Daten verarbeitet, bei sich eine Logik haben: wenn typ=multipolygon oder typ=boundary oder typ=naturschutzgebiet oder typ=einzugsgebiet oder..., dann wende die Multipolygon-Zusammenbau-Regeln an. Um das zu vermeiden, sollte man alles, wofuer Multipolygon-Regeln gelten sollen, auch als type=multipolygon taggen. Danke für die Erklärung. Dann schreib ich das mal so ins wiki. cu colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Am 07.08.2010 10:59, schrieb Martin Simon: Am 5. August 2010 19:35 schrieb Sebastian Klein basti...@googlemail.com: Hi, Da sich die Diskussion um das Tagging von Fahrradstraßen schon recht lange hinzieht, habe ich mir mal die Freiheit genommen, den (aus meiner Sicht) aktuellen Stand in einer neuen Wiki Seite zu dokumentieren: http://wiki.openstreetmap.org/wiki/DE:Bicycle_road Ganz vergessen: +1, was du dort niedergeschrieben hast, würde ich zu 100% unterstützen! :-) Sehe ich genauso. Danke für die Arbeit. colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Max. Speed für highway = service ?
Tom Müller schrieb: Am 02.08.2010 14:51, schrieb Alexander Matheisen: Wenn nichts angegeben ist, kann man eigentlich auch kein maxspeed angeben, denn dies gibt ja die erlaubte Höchstgeschwindigkeit an. Ist nichts angegeben, kann man ja z.B. auch nicht für zu schnelles Fahren bestraft werden. Ich greife das doch nochmal auf. Wenn ein highway=service kein max_speed-Tag hat, gilt doch einfach innerorts 50km/h und außerorts 100km/h, oder? Ob man da dann nur 10km/h fahren kann ist ja für die maximal erlaubte Geschwindigkeit egal ... Das ist richtig ! colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße (neue Wikiseite)
Garry schrieb: Am 05.08.2010 19:35, schrieb Sebastian Klein: Theoretisch wäre es wünschenswert, wenn die anderen Merkmale durch dieses eine Tag impliziert wären. Da die Anzahl der Fahrradstraßen in den meisten Städten noch überschaubar ist, halte ich es allerdings für vertretbar, die wichtigsten Merkmale noch explizit anzugeben. (Insbesondere bicycle=designated) Zumal in vielen Fällen die Fahrradstrasse mit Zusatzrechten für andere Verkehrsteilnehmer beschildert ist. Genausowenig wäre es notwendig gewesen für die verkehrsberuhigten Zonen einen eigenen Strassentyp einzuführen. +1 ich halte da ein bicycle_road=yes analog zu motorroad=yes/no für passender. skyper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
Martin Hollmichel schrieb: stimmt, da wo die Gräben breit genug sind, ist oft kein Zaun mehr nötig. Aber wie katographiert man eigentlich am besten Gräben, diese sind zum Abzeichnen oft zu schmal, also log gehts mit Gummistiefeln, Floß und dem GPS Empfänger ? :-) barrier=ditch width= depth= cu colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auto ist nicht gleich Auto
Heiko Jacobs schrieb: Da stoßen wir aber auf das Problem, dass Gehwege meistens weder separat gemappt werden, noch als Zusatzeigenschaft zum highway erfasst werden. Normalerweise dürfen ja Fußgänger auch überall hin mit Ausnahme von Autobahnen und Kraftfahrstraßen und expliziten Verboten, die alle getaggt werden können. Auch bei cycleways wäre foot=yes eigentlich obsolet, da normalerweise parallel zu diesem ein Gehweg da ist, der meistens nur nicht erfasst ist. Wenn das nicht zutrifft, kann man immer noch foot=no dran hängen. Trotzdem hängen viele foot=yes o.ä. an cycleways incl. mir ... ;-) In highway=residential ist footway=yes schon enthalten. Hier wird leider häufig footway=no/none vergessen. Bei den anderen Straßen muß es schon explizit angegeben werden, wobei ich als Werte both/left/right/none als geeigneter ansehe (andere Baustelle). Apropos Fahrradstraße ... Gibt's da eigentlich mittlerweile ein brauchbares tagging-Schema? Mit residential und Zusatz-Tags war ich nie zufrieden, weil da die Besonderheit einer Fahrradstraße nicht rauskommt. Ich war ja schon immer der Meinng, dass man analog zu living_street ein cycle_road braucht, habe das aber nicht mehr verfolgt ... living_street war ein Unfall ! highway=residential foot=designated living_street=yes wäre viel geeigneter. Wenn Du die kleine Besonderheit, daß Ihr als RadfahrerInnen explizit zu zweit nebeneinander fahren dürft unterbingen willst, halte ich ein bicycle_road=yes als passend, highway=residential footway=both bicycle_road=yes sollte von bicycle_road=yes impliziert werden: bicycle=designated sollte von footway=both impliziert werden: foot=designated + sonstige access-beschränkungen. Nebenbei, ich finde es nicht gerade gut, daß die meisten Rendere leider nur access=* auswerten und nicht die angaben für die Fahrzeuge. Dadurch kommt dann folgendes Beispiel zustande. access=agricultural foot=yes bicycle=yes horse=yes ski=yes mofa=yes ice_skates=yes inline_skates=yes carriage=yes snowmobile=yes wheelchair=yes emergency=yes und bei jeder neuen (Unter-)Klasse muß ich ein neues Tag anhängen, wenn doch: motor_vehicle=agricultual moped=yes snowmobile=yes emergency=yes ausreicht. Dazu kommt noch die Frage ob ich ein access= generell nur als restiction-Relation taggen sollte, solange ich nicht weiß ob man über einen anderen Weg doch noch auf diesen Weg gelangen kann, ohne an Verbotsschilder zu kommen. Häüfig sind an den Enden des Weg für beide Richtungen unterschiedliche Schilder. Hier muß man entweder wieder auf forward/backward zurückgreifen, oder sowieso eine restriction-Relation verwenden. Grüße colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
bkmap schrieb: mir ist auch eher der Zaun wichtig. Ob Tiere herumlaufen sehe ich schon und dann gibt es ja auch noch die Schäfer. Ob da ein Zaun steht oder nicht, ist nicht DAS Unterscheidungsmerkmal. Weidezäune werden meist nur aufgebaut, wenn sie gerade benötigt werden. Wenn man aber etwas genauer hinsieht, hat man meistens keine Schwierigkeiten, eine Weide von einer Wiese zu unterscheiden. 1. Eine Wiese wird mindestens 1x Jährlich gemäht. Deshalb wachsen dort auch nicht große Disteln oder andere Pflanzen, die auf Weiden von dem Vieh verschmäht werden. Die Arten, die auf einer Wiese wachen, sind andere als auf einer Weide. Eigentlich sieht man das sofort, auch wenn man nicht alle Pflanzen mit Namen kennt. 2. Auf Wiesen liegen nicht massenweise Kuhfladen, Perdeäpfel oder andere fäkale Überbleibsel. Wenn man soetwas sieht kann man die Fläche getrost als Weide bezeichnen :-) 3. Wenn Vieh auf einer Weide stand, sind auch immer Bereiche zu sehen, die mehr oder weniger zertrampelt sind. Z.B. dort, wo Wassterstellen sind oder waren. Sicher gibt es noch andere Hinweise, die man bemerken kann, wen man nur genauer hinschaut. Probiert es doch einfach mal aus. Bitte verstehe mich nicht falsch. Ich habe kein Problem mit der Unterscheidung von Wiesen und Weiden, aber bitte Gruppiert diese beiden Grasflächen richtig, und schreibt doch eine kurze Beschreibung dazu wie man sie unterscheidet. Oben stehen schon ein paar gute Punkte, allerdings ist ein Graben genau so gut wie ein Zaun und es sollte besser lauten: Das einfachste Erkennungsmerkmal ist eine Abgrenzung, wie Zaun oder Graben. cu skyper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postleitzahlen-Import
Frederik Ramm schrieb: Chris66 wrote: Hmm, wieso taucht das denn im PLZ-WMS auf? Ich hab den PLZ-WMS so gebaut, dass er alle Flaechen, die mit addr:postcode getaggt sind, beruecksichtigt. Darunter auch ein Gebaeude In Deutschland haben manche Firmen/Institutionen eigene PLZ. Ein Gutes Beispiel ist die verhaßte GEZ in Koln Vielleicht einen eigenen Layer für addr:postcode ? cu colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
