Re: [Talk-de] Hausnummerierung fehlerhaft
Hallo Andreas, d.h. die Nummern 4 - 22a sind 2 - 18, richtig? Dann passen die Nummern ab 20 wieder. Das hast Du vor Ort überprüft, oder? Ich habe das so korrigiert. Viele Grüße, Rainer Am 12.12.20 um 23:55 schrieb Andreas Schmidt via Talk-de: Liebe Liste, könnte bitte jemand mir helfen? Ich habe heute in Hannover einen Fehler gefunden und weiß nicht, wie weit er geht. Konkret sind Hausnummern in der Kückstraße im Stadtteil Bemerode in Hannover falsch. Es betrifft zumindest die gerade Nummern im unteren Bereich. Die Hausnummer 2 existiert laut OSM gar nicht, hat stattdessen die Nummer 4. Die Nummer 6 ist falsch mit 8 beschriftet usw. Vielleicht kann jemand das korrigieren, der eine Möglichkeit hat, das zu verifizieren, wie weit der Fehler weitergeht. Ich habe gerade eben nur ein paar andere Kleinigkeiten gespeichert, lasse aber das Hausnummernproblem unangetastet https://www.openstreetmap.org/changeset/95739609 Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massenweise Entfernung von oneway=no
Oh, lit ist gut. Als mir das erste Mal ein Waldweg mit lit=no begegnete, habe ich das gelöscht, weil ich dachte, da hat jemand zu brav alle Werte der Vorlage im Editor ausgefüllt. Später, als mir das noch einige Male begegnete habe ich's gelassen, denn es ist ja nicht falsch, aber halt total unnötig. Im Grunde haben wir das Problem, daß ein fehlendes Tag default bedeutet, aber nicht von einem gesetzten mit default-Wert unterscheidbar ist. Das könnte man zwar lösen, indem ein Editor den Wert "unknown" setzt, wenn der Benutzer nicht "yes" oder "no" auswählt. Es würde aber dazu führen, daß jedes Objekt Unmengen an Tags Schlüssel=unknown bekommt, alles was so denkbar ist für ein solches Objekt. Also alles das, was Tobias als "zu Lasten der Übersichtlichkeit" beschrieben hat. Was als default angenommen wird, kann und sollte im Wiki festgelegt sein. Es kann aber durchaus für Wegtypen oder allgemein Objektarten unterschiedliche default-Werte geben und sie können regional abweichen. Wer in Belgien aufgewachsen ist, könnte bei der ersten Auslandsreise versucht sein an Autobahnen lit=no zu ergänzen bis er merkt, daß "no" nicht die Ausnahme ist. Aber ein Fußweg ist bei lit=yes|no anders zu behandeln als eine Autobahn. Da würde ich es nicht wagen fehlendem lit=* einen Defaultwert zuzuordnen. Insofern, ja genau, der gesunde Menschenverstand sollte ein gutes Hilfsmittel sein bei der Überlegung, ob ein Schlüssel mit einem Defaultwert gesetzt wird oder eben nicht, weil es eh klar ist. Ich investiere meine Zeit für OSM lieber, um Dinge zu erfassen, die wirklich noch fehlen oder sich geändert haben, als großflächig Defaultwerte hinzuzufügen. Aber Löschen in der Regel auch nicht. - Rainer Am 25.05.20 um 20:44 schrieb Florian Lohoff: On Mon, May 25, 2020 at 01:08:33AM +0200, Tobias Knerr wrote: Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung besteht – lege ich dann jeweils eine Relation mit restriction=allowed an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer Abfalleimer steht, ...? Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist (weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall sein. Ich überlege gerade was ist mit lit/cycleway/sidewalk/shoulder ? So einfach ist es eben nicht. Es gibt zwar defaults die auch Sinn machen. Es gibt dinge deren "seltenheit" macht es Unsinning eben den umgekehrten fall zu taggen oneway=no als Beispiel. Aber was ist mit lit? Da sind ja sowohl lit=no wit auch lit=yes eine information. Und bei lit ist die Verteilung eher 80/20. Was ist mit sidewalk=no, cycleway=no? hat ja ggfs im Routing eine Auswirkung je nach Straßenklasse. Auf einem residential mit sidewalk=no will ich vielleicht noch laufen. Auf einem primary mit lit=no, sidewalk=no vermutlich eher nicht - vor allem nicht Nachts. Also die Regel das nur weil etwas NICHT existiert wir es nicht taggen ist zu kurz gesprungen. Ich glaube das funktioniert im Moment nur deshalb weil jeder da seinen Menschenverstand benutzt - oder eben auch nicht. Ich denke man müsste für jedes tag einzeln durchgehen ob es Sinn macht yes UND no zu taggen und wenn ja wann. Und für einiges haben wir defaults, für anderes aber eher so nicht - bzw eher undokumentiert und gefühlt. Flo ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Webcam
Hallo, hat openstreetmap ein tag für webcams, wie z.B. diese hier https://kachelmannwetter.roundshot.com/sonnenbuehl/ ? Passen da nach https://wiki.openstreetmap.org/wiki/Proposed_features/ Key:Surveillance und https://wiki.openstreetmap.org/wiki/ Tag:man_made%3Dsurveillance man_made=surveillance surveillance=webcam contact:webcam=https://kachelmannwetter.roundshot.com/sonnenbuehl/ Allerdings klingt Proposed on: 2008-07-08 nicht gerade ermutigend :-/ Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vereinheitlichung Tagging Aufzug-ID und Rolltreppen-ID aus Operator-Sicht
Hallo Dietmar, darauf bei ref die Seriennummer des Herstellers einzutragen wäre ich gar nicht gekommen. Das halte ich nur für die Thyssens, Otis und fürs SAP-System des Verkehrsbetriebes, der die Rolltreppen bzw. Lifte betreibt, für relevant. In M sind, soweit ich sehe, mit ref=* die Kennungen der MVG erfaßt. Siehe http://overpass-turbo.eu/s/RNt Aber einverstanden, ref:elevator_operatorid=* würde diese Unklarheit beseitigen. Wäre nur zu klären, ob irgendeine Anwendung oder Karte, evtl. auch nur in einem einzelnen Verkehrsverbund, diese refs auswertet. Für M kann ich ggf. mithelfen. Grüße, Rainer Am 21.03.20 um 21:30 schrieb Dietmar Seifert: Hallo Eike, Du hast Recht, bei Verwendung des puren ref Keys ist nicht immer und jedem klar, auf was sich der ref Wert bezieht. Es sollte die vor Ort vorzufindende Id sein, aber darauf kann man sich natürlich nicht verlassen. Es gibt ja schon viele Namensräume (ref:xy), einige wenige davon siehe [1]. wenn wir mal bei Aufzügen bleiben, gibt es 22.160 davon. ref kommt 1042 mal vor, und da ist natürlich nicht klar, worauf sich diese bezieht. Weitere nennenswerte spezifischere ref:* Keys mit ihrer Anzahl Vorkommen: ref:operator_inventory: 258 ref:manufacturer_inventory: 212 ref:elevator_operatorid: 122 ref:elevator_machineid: 53 also immerhin grob 20% Hersteller-Refs und zwischen 25 und 37% Betreiber-Refs (nicht geprüft, wieviele doppelte Zuweisungen von ref:operator_inventory und ref:elevator_operatorid). Wenn die Community für eine OSM Objektart nicht klar weiß, was in ref einzutragen ist, sollte wohl besser der Namensraum verwendet werden. Ich bin da allerdings im OSM Wiki auf eine ref: Namensvariante gestoßen, die in der Realität nur gering eingesetzt wurde. Da hilft wohl nur konsequentes kommunizieren (Wiki,..) und unterstützendes (Editoren) Handeln und öfters mal Prüfungen der OSM Erfassungsrealitiät. viele Grüße Dietmar [1] https://wiki.openstreetmap.org/wiki/Key:ref Am 21.03.20 um 20:35 schrieb Rolf Eike Beer: Am Samstag, 21. März 2020, 18:02:56 CET schrieb Dietmar Seifert: Hallo, vorab: es geht hier um das umtaggen von Objekten, daher wäre evtl. die tagging-Mailingliste auch sinnvoll, aber der betroffene Key wird nur in Deutschland verwendet. Ich bin zufällig vor einigen Tagen auch über diese Keys gestolpert und möchte an dieser Stelle nur einen anderen Punkt mit aufführen: "ref". So wie ich das sehe ist "ref" bei Aufzügen die Seriennummer des Aufzugs, bzw. des Herstellers. Das widerspricht irgendwie meinem Bauchgefühl dessen, was ich sonst unter "ref" erwarte. Ganz praktisch ist mir das aufgefallen, weil ich wusste, dass die Seriennummer bei Aufzügen irgendwie erfasst wurde. Bei einer Elektroladesäule stand die auch dran, und ich dachte, die könnte man miterfassen. Aber da ist "ref" eher die Nummer des Betreibers, siehe z.B. auch Parkautomaten. Spaß... Eike ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
Hallo Roland, vielen Dank. Ich schaue mir gerade die Ergebnisse an. Im ländlich geprägten Raum habe ich noch highway=track in die Auswahl hinzugefügt, weil viele Einzelgehöfte wirklich nur über Feldwege erreichbar sind. Zumindest zwei Fälle, in denen die Zufahrtswege fehlen, habe ich auf die Schnelle gefunden. Grüße, Rainer Am 03.05.19 um 13:23 schrieb Roland Olbricht: Hallo zusammen, Wie hast du die Auswertung erstellt, mit Overpass turbo evtl.? Kannst du die Abfrage bekanntgeben? Ohne zu wissen, wie Florian das konkret gemacht hat. Es funktioniert https://overpass-turbo.eu/s/IF0 Empfohlene Zoom-Level 13-19. Liste der Highway-Typen in Zeile 1, Abstands-Schwellwert in Zeile 3, hier "100". Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
Hallo Florian, wie Navigationssysteme das handhaben, ist eine Sache. Mein altes Navigon sagt immer "das Ziel liegt in einem beschränkt befahrbaren Bereich" in Fällen wie Anlieger frei, Fußgängerzone, Waldweg. Das wäre m.E. im Router handhabbar. Interessanter finde ich die Fälle, in denen ein Weg existiert, aber nicht in OSM eingezeichnet ist. Wie hast du die Auswertung erstellt, mit Overpass turbo evtl.? Kannst du die Abfrage bekanntgeben? Ich würde in meiner Gegend mal nach solchen Fällen schauen. Grüße, Rainer Am 03.05.19 um 09:48 schrieb Florian Lohoff: Hi Martin, On Fri, May 03, 2019 at 02:57:14AM +0200, Martin Koppenhoefer wrote: sent from a phone On 2. May 2019, at 23:46, Florian Lohoff wrote: Egal - Hier sind die Daten für NRW - Vielleicht findet die ja jemand anderes auch Spannend. spannender wären die überhaupt nicht erschlossenen (in OSM). Soweit ich deine Ausführungen verstanden habe sind hier alle enthalten, die weiter als 75m von einer allgemein mit dem Kfz befahrbaren Straße liegen, also auch alle die über längere Privatzufahrten erschlossen sind oder in Fußgängerzonen liegen, usw. Für mich ist "gar nicht erschlossen" dasselbe wie "track" oder "access=no/private" auf einem service/driveway. Defakto gibt es keinen legalen weg bis "vor die Tür" zu navigieren. Und die Privatzufahrten sind mit drin - also werden benutzt - so weit sie nicht durch access tags verboten sind. Also ganz normales standard OSRM Car Profile. Ich habe zuhause ein ähnliches Problem. Unbefestigter Waldweg vor der Tür. Ist klar ein Service bzw ein unclassified weil öffentlich. Trägt aber ein motor_vehicle=destination und ich bin der einzige Anlieger. Drumherum gibt es reichlich Forstwirtschaftliche Wege. Wenn ich mit OSMAnd versuche nach hause zu navigieren dann werde ich Kreuz und quer durch den Wald geschickt weil die kosten für eine unclassified mit motor_vehicle=destination höher sind als die eines tracks. Das sind eben die letzten 2-3% Adressen die mit aktuellen Tags und Software nicht lösbar sind. Und die ganze nach Gefühl gemappten access=private/no auf jeder Hauszufahrt machen eben die navigation für diese Adressen kaputt. Wenn das im Wohngebiet nur die 10m Hauszufahrt sind - geschenkt. Wenn aber das Haus/Hof 800m neben der Straße im Wald oder Tal/Berg liegt und ich das nicht einmal sehe bzw der nächstgelegenene Punkt auf einer Öffentliche Straße auf einer Straße ist von der keine Zufahrt möglich ist das halt ziemlich suboptimal. Dann ist OSM für diesen Anwendungsfall auf dieser Adresse einfach kaputt. Flo ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mitbetreuer für die Chemnitzer Linux-Tage gesucht
Hallo André, ich habe mich entschlossen dieses Jahr am OSM-Stand mitzuhelfen. Wie ist der zeitliche Rahmen, d.h. wann geht's am Sa los und wann ist am So Schluß? Wie läuft die Anmeldung, koordinierst du das für den OSM-Stand? Auf der Wiki-Seite habe ich mich eingetragen. Viele Grüße, Rainer Am 03.01.19 um 13:37 schrieb André Riedel: Hallo, für die diesjährigen Chemnitzer Linux-Tage suchen wir noch Mitstreiter, welche uns am OpenStreetMap-Stand unterstützen. Diese finden am 16. und 17. März statt. Weitere Informationen findet ihr im Wiki. Da der Anmeldeschluss in zwei Tagen ist, benötige ich auch eine kurzfriste Zusage. https://wiki.openstreetmap.org/wiki/Chemnitzer_Linux-Tage_2019 Mit besten Grüßen André ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Ortenau] Stammtisch in Straßburg
Hallo, das finde ich eine sehr gute Idee. Gerne würde ich mich anschließen, wenn es vom Termin her klappt. Ich trage mich mal in der Umfrage ein, allerdings nur mit "vielleicht", weil ich vsl. nur an einem der Wochenenden kann, was sich aber erst kurzfristig entscheidet. Also bitte keine Rücksicht auf mich nehmen; wenn's paßt, bin ich dabei, sonst beim nächsten Mal. Auf jeden Fall eine Gelegenheit, mein eingerostestes Französisch zu testen und mit ein paar OSM-Vokabeln aufzupeppen. Viele Grüße, Rainer Am 04.09.18 um 22:58 schrieb Christine Karch: Hallo, demnächst gibt es wieder einen Stammtisch in Straßburg (den zweiten, den ersten haben wir im Frühling gemacht und wir waren auch tatsächlich 5 Leute - drei Elsässer, Frederik und ich). Nachdem wir uns trotz unterschiedlicher Sprachen (die Franzosen verstehen doch alle irgendwie deutsch und Frederik spricht doch etwas französisch, obwohl er das eigentlich immer abstreitet) ganz gut verstanden haben, wollen wir das wiederholen. Wir haben hier einen Poll eingerichtet https://framadate.org/7faqTEWGVNd1hL5t Ihr seid herzlich eingeladen. Traut euch, habt keine Angst vor Sprachschwierigkeiten. Wir reden mit Händen und Füssen und das Wesentliche ist der gemeinsame Abend und der Spass dabei. In An- und Abreise ist übrigens ganz unkompliziert mit ÖPNV: Zug von Offenburg oder Tram von Kehl. Wer sich nicht so auskennt in Straßburg kann sich gerne mir und Frederik anschließen (einfach per Mail bei mir melden). Viele Grüße Christine ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen/Wege // Trolling in changesets
So wie Volker ging's mir beim Mitlesen auch. Das Problem entsteht dadurch, daß highways und waterways linienförmig kartiert werden, landuses aber flächenförmig. Das resultiert letztlich aus der Zielsetzung, auf Straßen und Wegen routen zu können. Daher wurde die Breitenausdehnung von Wegen vernachlässigt. Außerdem werden Wege klassisch in Karten nicht entsprechend ihrer physischen Breite eingezeichnet, sondern die Breite entsprechend ihrer Verkehrsbedeutung variiert, letztlich aber immer breiter als in natura. In Stadtplänen will man ja auch noch einen Straßennamen hineinschreiben. D.h. die Straßenbreite in einer fertigen Karte wird immer von den Präferenzen und Einstellungen des Renderers abhängen, selbst wenn wir die Lücke zwischen z.B. dem landuse=forest links der Straße und dem landuse=meadow rechts der der Straße mit einem landuse=highway füllen. Etwas günstiger sieht's bei Bahnlinien aus, wo wir tatsächlich landuse=railway haben, der von flächendeckender Verwendung auch noch ein Stück entfernt ist, sich aber doch halbwegs rendern läßt. Insofern bin ich dafür, gedanklich von einem landuse=highway auszugehen und die angrenzenden landuses an diesem enden zu lassen, also nicht mit linienförmigen Objekten (highway, waterway, aber natürlich auch railway) zu verkleben. Diese beiden Datenmodelle haben jeweils ihre Berechtigung. Daher mein Vorschlag eines gedanklichen (ggf. später mal realen) landuse=highway, der ein Nichtverkleben der Objekte aus den unterschiedlichen Datenmodellen anschaulich plausibel macht. Ich habe in ein paar Einzelfällen auch schon entklebt, wo ich sowieso landuse bearbeitet habe. Öfter begegne ich aber leicht überlappenden landuses, die zwischendurch auch mal mit einer Straße verklebt sind. Sowas versuche ich meist aufzulösen (Ziel: JOSM-Prüfung vor dem Hochladen wirft weniger Warnungen als nach dem Herunterladen). Viele Grüße, Rainer Am 05.04.2018 09:28, schrieb Volker Schmidt: Ich habe mit Interesse diese Diskussion mitgelesen. Was ich vermisse in diesen Ausfuehrungen, ist ein Hinweis, dass der Konflikt vorprogrammiert ist durch die Tatsache, das das Daten-Modell von OSM ein Hybrid ist. Es koexistieren zwei Datenmodelle: 1) ways mit implizit oder explizit angehefteten Breiten 2) Flaechen (Polygone) Mit ways mit angehefteten Breiten kann man keine komplizierten Flaechen beschreiben, mit Flaechen (shapes) kann man alles beschreiben, aber der Preis dafuer ist ein groeserer Aufwand, der fuer viele Anwendungsfaellee nicht notwendig ist. Wenn man akzeptiert, dass in OSM beide Modelle koexistieren sollen, dann kann man sich den praktischen Aspekten widmen. Und das ist haeufig ein Kompromiss oder besser ein Provisorium. Ich bin auch ein - gelegentlicher - Entkleber, aber nicht aus Prinzip, sondern einfach weil ich mit der Verbesserung der Daten, die ich verbessern kann, vorankommen will. Genauer: ich moechte die Verwendbarkeit von OSM fuer Radfahrer verbessern, weil ich sie selbst benutze. Ich kann nicht ausserdem alle "Fehler" beseitigen, die links und rechts "meiner" Radstrecke liegen. Normalerweise benutze ich meine eigenen GPX tracks und, zumindest seit den letzten zwei Jahren, in der Regel auch Mapillary-Fotos. Ein typischer Fall: Ich treffe auf einen an die Strasse angeklebten, mehrere Hektar grossen landuse=farmland, vor acht Jahren importiert, und wahrscheinlich vom Inhalt her deutlich aelter, und beim Import nicht kontrolliert. Mittlerweile steht dort ein Supermarkt und eine Neubausiedlung. Die Strasse ist von einem freundlichen OSM-Kollegen recht grob eingetragen worden, mit erhebliche Geometrie-Fehlern. Ausserdem sehe ich auf den Fotos, dass neben der Strasse ein Drainage-Graben ist, der auf der Karte fehlt, und der jetzt teilweise unterirdisch verlaeuft, und jenseits davon ein neuer Fuss-Rad-Weg. Was mach ich da? Als erstes wird der landuse entklebt, da er offensichtlich nicht den Tasachen entspricht und ein fixme draufgesetzt. Die Strassen-Geometrie verbessere ich soweit moeglich, Den neuen Radweg, den Graben, wo er sichtbar ist, und die neuen Strassen trage ich ein (falls sie schon auf den Satellitenbildern drauf sind, sonst nur die Einmuendungen von den Mapllary Fotos). Landuse und neue Gebauede lasse ich fuer andere. Ausser dem Supermarkt, falls ich auf den Fotos den Namen sehe. Den setze ich mit ungefaehrer Position ein. Aber der offensichtlich falsche landuse bleibt - mit fixme - auf der Karte, mit seiner falschen Geometrie und tags, aber er ist nicht mehr mit anderen Wegen verklebt. <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> 2018-04-04 18:38 GMT+02:00 "Christian Müller" <cmu...@gmx.de>: Sent: Wed, 4 Apr 2018 17:38:23 +0200 From: "Florian Lohoff"
Re: [Talk-de] Navads-Tankstellenimport
Es sind nur einige Marken in der Liste, nicht z.B. Jet, Esso, Total, die meisten Freien. Wenn du auf welche stößt, die in OSM fehlen, würde ich die ganz normal in OSM erfassen. Sehe ich als nützlichen Beifang der Überprüfung dieser Importdaten. Grüße, Rainer Am 29.03.2018 20:09, schrieb CryptKiddie: Hallo, Ich versuche gerade, die Tankstellenin meiner Umgebung zu validieren, leider sind die meisten nicht verzeichnet, sollte man das auch reporten oder sind "nur" die verzeichneten Tanken? Lukas oder CryptKiddie Am 29. März 2018 10:58:41 MESZ schrieb Falk Zscheile <falk.zsche...@gmail.com>: Am 29. März 2018 um 00:27 schrieb Tom Pfeifer <t.pfei...@computer.org>: Wenn ich eine lokale Tanke herangezoomt habe, und als "good" bestätige, werde ich mit Überlichtgeschwindigkeit an einen anderen Ort in DE gebeamt, von dessen Existenz ich bisher nicht einmal geahnt habe. Das folgende Vorgehen löst das Problem: 1. auf http://audit.osmz.ru/profile gehen 2. ggf. einloggen, 3. ein Rechteck über die Region ziehen, die man begutachten möchte 4. return -- man kommt (wieder) auf die Einstiegsseite mit den zu validierenden Importen (http://audit.osmz.ru/) 5. wenn man nun "NavAds Fuel Stations Import (Germany)" auswählt 6. erscheinen nur noch Einträge aus dem unter 3. gewählten Bereich Ich hoffe das macht es leichter. Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navads-Tankstellenimport
Ja, und jetzt beamt's mich nach einem Edit nicht mehr 5000 km zu irgendeiner Tanke, die ich bestimmt nicht kenne, sondern nur noch ein paar 100 km ;) Der Fahrradladen aus der ersten Runde, der zur Tanke mutieren sollte ist jedenfalls mit "the last reviewer rejected this ..." rausgenommen. Oft ist es hier nur brand, das fehlt und einige Male zweifle ich an den 24/7 Öffnungszeiten, aber es könnte sein, daß eine Zapfsäule, an der man mit Karte zahlen kann, dafür schon ausreicht. Grüße, Rainer Am 28.03.2018 23:06, schrieb Falk Zscheile: Am 28. März 2018 um 21:58 schrieb Harald Hartmann <osm-talk...@haraldhartmann.de>: Hmm, geht's wohl schon in die nächste Runde? weiter geht's mit http://audit.osmz.ru/project/navads_fuel_de Vielen Dank für den Hinweis. Das finde ich jetzt schon ziemlich gut. Man kann nun für jedes Node sagen, ob man die Änderungen haben möchte oder nicht. Das sollte die Qualität des (potentiellen) Imports deutlich verbessern und Datenmüll vermeiden. Und einen Fortschrittsbalken, wie viele Daten schon geprüft wurden, gibt es auch :-) Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navads-Tankstellenimport
Hier ist ein Fahrradladen gelistet: http://audit.osmz.ru/browse/navads_fuel/e9dcf0e6_d404_405c_9061_9091e742b3a6 Ich habe mal auf "Not there" geklickt. Da ist keine Tankstelle, aber der Fahrradladen schon. Danach geht nichts mehr auf der Seite, nur Ajaxskriptfehler. Viele Grüße, Rainer Am 26.03.2018 23:50, schrieb Michael Reichert: Crossposting: https://forum.openstreetmap.org/viewtopic.php?id=61809 Hallo, vor ein paar Tagen hat Ilya Zverev auf der Imports-Mailingliste einen weltweiten Import von ca. 59.000 Tankstellen (in Deutschland größtenteils Änderung von Tags) angekündigt. Er macht das unentgeltlich für die Firma Navads [1]. Da ich nur einen kleinen Teil von Deutschland kenne, möchte ich euch bitten, euch eure Gegend auf http://audit.osmz.ru/browse/navads_fuel mal anzusehen und insbesondere Aspekte zu prüfen: - Stimmt das Matching bei mehreren neben einander liegenden Tankstellen? - Sind die Tags, die geändert werden sollen, korrekt? - Werden Tags ergänzt oder geändert, die man mehrmals pro Jahr ändern müsste, weil sie saisonal verschieden sind? - Habt bitte insbesondere einen Blick auf Tankstellen, die in den letzten zehn Jahren die Marke gewechselt haben. Falls euch solche oder andere Fehler auffallen, so meldet euch bitte hier oder direkt auf der Imports-Mailingliste. Viele Grüße Michael [1] Die Firma hat schon einmal von einem anderen Dienstleister Aral-Tankstellen in Deutschland importieren lassen (die fehlenden konnte man an einer Hand abzählen). Die zweite OSM-Interaktion erfolgte mit einem anderen Anbieter und ging grandios in die Hose. Nummer drei war Ilya mit einem stellenweise fragwürdigen Shell-Import im Vereinigten Königreich. Nummer vier steht jetzt zur Prüfung an. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenz für auf Basis eines Kartenscreenshots geschaffene Werke ✅
Danke für die Hinweise, erst mal ist alles klar! Viele Grüße Rainer Bielefeld! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lizenz für auf Basis eines Kartenscreenshots geschaffene Werke
Hallo, die Lizenzhinweise auf <https://wiki.openstreetmap.org/wiki/DE:Open_Database_Licence_-_Licence_Text#Hinweise_bei_der_Nutzung_von_Ausgaben_.28Daten.29> lassen mich einigermaßen ratlos. Was wäre denn für <https://weststadtbs.files.wordpress.com/2018/01/karte.png> erforderlich, wenn ich das in einer Stadtteilzeitung abdrucken möchte, die es parallel auch als PDF gibt? Und was, wenn ich das im mzm Downloadlink gehörenden Blog veröffentlichen möchte? Eigentlich erscheint mir alles außer CC0 unpraktikabel. Kann mir jemand weiter helfen? Viele Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=residential an Node
Habe mir gerade mal mit der Overpassabfrage ein paar angeschaut. Die Fälle sind alle etwas verschieden. Wenn man sie sich einzeln anschaut und korrigiert, finde ich es in Ordnung. JOSM meckert ja gleich an diesen Punkten. Grüße, Rainer Am 07.09.2017 20:16, schrieb dktue: Hallo, oh, ich wollte gar nicht weltweit löschen, sondern nur bundesweit. Das hatte ich nicht geschrieben. In Deutschland gibt es genau 27 solcher Nodes [1]. Die gehe ich einfach von Hand durch und erzeuge gegebenenfalls aus dem Luftbild die Fläche, die eigentlich gemeint ist. Viele Grüße Daniel [1] http://overpass-turbo.eu/s/rxD Am 07.09.2017 um 18:59 schrieb Martin Koppenhoefer: Am 7. September 2017 um 18:52 schrieb Tom Pfeifer <t.pfei...@computer.org>: Ja, ich habe Einwände. landuse=residential gibt es 5026x auf einer Node, im Vergleich zu 4,2 Mio Flächen. Die Nodes sind weltweit verteilt. All diese Nodes beinhalten die Aussage, dass sich dort ein Siedlungsgebiet befindet. Für ein Löschen dieses Tags gibt es überhaupt keinen Grund, schon gar nicht "auf einen Rutsch" (=mechanical edit[1]). Wenn du etwas verbessern möchtest, lade das Gebiet einer solchen Node, in einer Gegend, in der du den Bebauungs-Stil von Wohngebieten kennst und anhand des Luftbildes einschätzen kannst, und zeichne den Umriss des Wohngebiets. Die Node kannst du im Umring verwenden. [2] +1 prinzipiell müsste man bei einem weltweiten Edit auch international anfragen, nicht nur auf der deutschen Liste. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschwindigkeitsbegrenzungen protokollieren
Etwas spät, aber noch eine Antwort :) Aufgrund eines Beitrags im Users:Germany-Forum habe ich das mit dem OSMTracker getestet. https://forum.openstreetmap.org/viewtopic.php?id=58045 Darin ist ein Beispiel gezeigt, wie man eigene Menüs erstellen kann. Ich habe mir zunächst eins mit Geschwindigkeiten 30, 50, 60, 70, 80, 100, 120, 130 und "aufgehoben" gemacht. Da ich festgestellt habe, daß 40 doch häufiger als gedacht vorkommt und ich auch die Ortstafeln einbauen will, muß ich nochmal ein wenig umbauen. Auch bei meinem Schlaufon haben nicht für alle Schaltflächen im Menü gleiche Breite/Höhe; die Ursache habe ich auch nicht herausgefunden. Das ist aber nicht schlimm. Worauf man m.E. aber achten sollte, ist die Positionierung im Auto. Man sollte ohne Verrenkungen auf den Bildschirm tappen können und es sollte möglichst nahe zu den Instrumenten positioniert sein, damit der Blick nicht weit abschweifen muß. Dazu habe ich noch die App Tempomaster http://www.g-daehling.de/tempomaster/ als Overlay laufen lassen, die mir mit einem "?" anzeigt, daß in OSM für die Straße kein maxspeed gesetzt ist. Sicherheitshalber noch ein Video aufzeichnen, dann kann man Zweifelsfälle klären. Grüße, Rainer Am 19.05.2017 08:56, schrieb Martin Trautmann: Hallo, wie schafft ihr es, die exakte Position von Geschwindigkeitsbegrenzungen aufzuzeichnen und Änderungen einzupflegen? Ich muss gestehen, wenn ich selbst unterwegs bin, dann kann ich auf der Autobahn nicht auch noch ein Gerät bedienen, um zu sagen: ab hier Geschwindigkeitsbegrenzung von 80 km/h. Smartphone-Aufnahme mit GPS-Funktion klappt vermutlich nur, wenn ihr wisst, dass gleich das Schild kommt und der Beifahrer aufnahmebereit dasitzt. Und selbst bei Geschwindigkeiten unter 80 km/h komme ich mit einer Aufzeichnung nicht mit - das klappt vermutlich nur mit ständig mitlaufender Kamera vorne, die auch noch GPS mit aufzeichnen müsste? Wie macht ihr das? Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Diskussionen auf deutsch
On 21.04.17 13:29, Max wrote: Ich hoffe es wird discourse, Hallo für _mich_ ist /discourse/ die Plattform, gegen die ich die ausgeprägteste Aversion habe. Eher langsam, unübersichtlich, überladen ... . Begründet ist meine Aversion durch meine Erlebnisse mit discourse.mozilla-community.org/. Vielleicht ist mein altes Gehirn aber auch nur zu sehr auf klassische Foren geprägt und mag sich nicht mehr umstellen? Ehe ich bei discourse.mozilla-community.org gefunden hatte, wo ich Rat zu einem Problem mit 'ublock' bekommen könnte ... . Eigentlich ist für meine Vorstellungswelt eine Mailingliste das ideale Medium, sofern eine einheitliche, einfache Möglichkeit besteht, Bilder /Dokumente hochzuladen, die man dann in den Postings verlinken kann. Leider ist die Bedienung so einfach, dass tatsächlich jeder mitreden kann, und nach meiner Erfahrung in der Mozilla-Welt führt das dann dazu, dass jeder seinen Senf dazu gibt (egal, ob der Senf zum Thema gehört oder nicht), und damit wird dann jedes Thema eines Threads totgequatscht. Aus unerfindlichen Gründen passiert das in Foren (im weitesten Sinne) nach meiner Erfahrung seltener. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rettungsleitstellen
Sollten wir bei OSM nicht britisches Englisch verwenden? Also emergency=control_centre Grüße, Rainer Am 08.04.2017 17:12, schrieb dktue: Hallo Sven, gefällt mir besser! Danke für den Vorschlag. Hat sonst noch jemand Anregungen? Sollte ich einfach anfangen so zu taggen? Gruß dktue Am 08.04.2017 um 10:30 schrieb Sven Anders: Am Samstag, 8. April 2017, 09:44:59 schrieb dktue: Hallo, ich möchte gerne die Rettungsleitstellen [1] in Deutschland taggen, habe hierzu aber keinen passenden Tag gefunden. Mein erster Gedanke wäre, hierfür emergency=ecc zu verwenden (ECC = Emergency Control Centre). Erweitern könnte man es noch um Details, ob es sich um eine Rettungsdienst-, Feuerwehr- oder Polizei-Leitstelle handelt -- wobei in Deutschland die meisten Leitstellen bereits kombinierte Rettungsdienst- und Feuerwehrleitstellen sind -- die Polizei ist aber größtenteils separat. Ich finde Abkürzungen nicht gut. Was hälst du von: emergency=control_center Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie am besten Uploaden
Hallo Stefan, erstmal willkommen bei OSM :) und auch gut, daß du dich hier mit deiner Frage meldest. Ich halte es so, daß ich zusammengehörende Dinge in überschaubaren Portionen hochlade. Jede eingetragene Hausnummer als einzelnen Änderungssatz halte ich nicht für sinnvoll, weil dann die Übersicht schwierig ist, was der Mapper dort gerade macht. Also, um bei Hausnummern zu bleiben, nehme ich einige Straßen oder auch mal ein halbes Dorf und lade das hoch. Einen aussagekräftigen Kommentar zum Änderungssatz halte ich für wichtig, weil andere dann gleich sehen womit du dich beschäftigst und es sich nicht aus den einzelnen Änderungen zusammenreimen müssen. Und wenn wirklich mal was falsch ist, kann man das gut revertieren. Servus, Rainer Am 08.03.2017 06:41, schrieb Stefan Martinek: Hallo OSM Gemeinde, ich neu beim Mappen bin hat sich für mich nach meinen persönlichen Planungen eine Frage gestellt. Wie sollte man Änderungen am besten uploaden? Ich meine sollte man eher jede kleine Änderung einzeln hochladen oder doch zusammenwarten und grosse Pakete hochladen? Wie kommen die Server damit zurecht beim rendern und einpflegen? Wie macht ihr das so? Danke im Voraus für eure Vorschläge und Erklärungen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgerissene Gebäude
Am 29.08.2015 um 20:50 schrieb Florian Lohoff: On Sat, Aug 29, 2015 at 10:12:01AM +0200, Heinz-Jürgen Oertel wrote: Hallo, sollte man ein abgerissenes Gebäude, bisher building=yes, einfach löschen obwohl es noch im Bing zu sehen ist? Wie verhindere ich, dass es nicht wieder neu aufgenommen wird? Hat jemend eine Idee? building=no note=abgerissen Meist wird ja an der stelle der alten Gebäude was neues gebaut. Ich setze meist einen Note nach dem motto - Gebäude Abgerissen - Bautätigkeit beobachten Wir haben das hier an einer Stelle so gelöst: addr:city Unna addr:housenumber13 addr:postcode 59423 addr:street Massener Straße landuse construction noteBaulücke nach Abriß Das abgerissene Baudenkmal ist btw. fotografisch in der Wikipedia bzw. auf commons dokumentiert. Einen eigenen Wikirtikel hat(te) das Gebäude nicht, immerhin hat noch keiner den Abschnitt Ausgetragene Objekte in dieser Liste gelöscht: https://de.wikipedia.org/wiki/Liste_der_Baudenkm%C3%A4ler_in_Unna#Ausgetragene_Objekte Die Bildersammlung gibt es hier: https://commons.wikimedia.org/wiki/Category:Massener_Strasse_13_%28Unna%29 Frage ist, ob und wie man das mit OSM verknüpfen kann. Aktueller Zustand (seit etwa 2.5 Jahren): Grob planierte Schuttfläche mit Bauzaun drumherum. -- Rainer signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klassifizierung eine Straße im Gewerbegebiet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.07.2015 um 00:38 schrieb Joachim: Schwieriges Thema, ich versuche mich in Stuttgart auch gerade daran. Untergeordnete Straßen in einem Gewerbegebiet können nach einer Meinung durchaus residential sein, denn für untergeordnete Straßen außerhalb von Wohngebieten fehlt uns ein Tag. Zumal es in vielen Gewerbegebieten tatsächlich nicht an Wohnhäusern fehlt, hier in der Gegend haben zahlreiche Inhaber ihr Häusken direkt neben die Firma gebaut. Häufig gehen auch Mischgebiete auf der einen Seite in reine Wohn- und auf der anderen in reine Gewerbegebiete über. Und alles liegt an derselben Straße mit demselben Namen und derselben baulichen Ausführung. Da pappe ich komplett residential dran, sofern es keine Durchgangsstraße mit mehr als lokaler Bedeutung ist. Unclassified ist durch Verbindungsfunktion[1] ausgezeichnet, Ebendrum. Von der Funktion her sind die mit tertiary gleichzusetzen, nur halt mit geringerer Bedeutung. - -- Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJVtzqoAAoJEFIuGFy5SYX0EKQH/2aIn6spmQOYx69qib9lKbQf fcL2GRgbvQOJcpRIAkAsBL73lE99ELYgYiGQoMP/TimbLGiqTBHpe9pnjYV0vY9K H7iUa9AswYjWqRzkHv/NXLhaVj2ec3fE99FWAa/6kgWSO1doaWBOqTFNutY3BYMg W4H1QU1exBmEaYT2mbtIkqCdVJTaW+K1PCr6k6dS/4GmfCk0Qm8SvZBdDmafHCEd 6zgX3FfaY+7vjVX1FcmcTuPyetGwLQac1OS8EMku/HzBNZPmpBvPmyaWOYdB5A8A k7IOHVpoigcwwS0Tuv3xxTO2NYsaGEyXE4h4YsuS/BKG5I7Q1dJNbZU80oyWSGo= =Fp8s -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Richtfunkstrecken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ist es sinnvoll, Richtfunkstrecken zu malen, die, von einem Sendemast ausgehend, ein Stück weit strahlenförmig in die Landschaft zeigen, um dann irgendwo auf dem Acker oder im Wald zu verenden? Ich hätte beinahe gerade sowas gelöscht, weil es wie ein Edit-Unfall aussah. - -- Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTiccyAAoJEFIuGFy5SYX0qcAH/0nVWR2vt0sQBgGH34Y1YF3l 3A+bsAUF/wixiFt9xiAAXIwqP8BQdoalpJE08QubMiA9F+8mUp85RvV5x2lWA9Ru jsxqre8MJobAMIEKUhpFfIWLGUAv60ptXkPFK4EeQLdVdF9pWN4s+Hd8rwIg15Oh 3stq8EluRMhLOEI84oW6oAAiGkM35Ejli4HUkIIulYGOLzcMD/SPHFLdYYN2CIOu ZZkMQWd+7yjFU1n6QNlyTTjPHZTgHdd5ozhIT/0bVIbbqPkorV5Pxf7XCER9KMaM 6EuQAPncTNddHaSLqUl2rucfEqVdjwsOJZ4/NQs6bgdnskLo+52kXRfjAGQSs/U= =bTcY -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Datenlogger gesucht: AA(A), (Micro-)SD, neuzeitlicher Empfänger, Streichholzschachtelformat.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.01.2014 05:05, schrieb Johann H. Addicks: Nachdem mein langjähriger treuer Begleiter an der Phototasche (ein Royaltek RGM-3800) seit letzten Samstag einen neuen Besitzer gefunden hat Wie ärgerlich! Das Dingen tut einfach, was es soll, und wenn mal die eneloop leer sind, packt man einfach Mignons aus dem nächsten Aldi rein. Minihomer 2.8 (42g, Venus6, fest verbauter Akku) gporter GP-102+ (41g, Sirf IV, fest verbauter Akku) Holux 255 (48g, MTK, fest verbauter Akku) Qstarz BT-Q1000XT (65g, MTK2, Wechselakku Nokia BL-5C?) Ich vermute mal: Alle per USB aufladbar? Oder gibt es Schnelllader dafür? Wie lange laufen die mit einer Akkuladung und wie schnell laden die nach? Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJS3OKcAAoJEFIuGFy5SYX0P6AH/083h9Gaib6zVbllTYhPOXB3 tTD0Kkpng1tz7Vic2ciJ53CFRLlYQwNz0qjJat35NqeQ5iJVaaVylgtflOZkFYn3 zFA5SrtgYuynrKvYGOrIrDNG9M4uUsYIluwoVi4WGL8YryZF4oTPSb9Yr8HpJ4m2 MRqFuw45Pt/c606chbt4XrK36AhVPgrBlMdZDMR7oKQrm1e0URZm/Z27wIkKvlHT h1/xZVETvJLcvS1cvFmJVG/jON3nEhDtpC5Ov6JOdenpACP1jqEsulmotZOTcoGG ybGVu7wE7k0E7Txd7glnXh0u3SazaXfp2jEsUkBASfy9fohYxiSoTYVIeacywKg= =ZPEB -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bing-Luftbilder verschwunden?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin, ich bin sicher, daß es westlich dieses Bereichs im potlatch auch mal höher auflösende Luftbilder gab: http://www.openstreetmap.org/#map=18/51.53870/7.67254 Wohin sind die entschwunden? Ist das ein temporärer Aussetzer? Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSqvDJAAoJEFIuGFy5SYX06SwH/2Zw3xu+cT+Hx96nOGWj5VgM scQSyoN5iDbT5q2vJVo7s+uTC5S4SxkTGURTxZ8ayvGw9YsxlOz5IhqBubhgBG/N NJBaVQrEtPfk1ItlpChE4+dkVS25ggzNw0Fx+b4ZEUaf2AxnFFMqCNWlPT4UL0HR XYejnAXiHGg6LeGb9LD23RB/CC+TPw5KSO96zQi8kRWbFp8csTihIxxDxnfaSXre wmKTAbX69kgjwjJWd2ocgppdNxu/T6908pKs2F+wFHA52rUdLSZWujEgr8pluoCx nkpsr2jze4W2HB1ASiQkNrlVQgcGdhZmB43UMdmMRukbJqcXxFmHESNtBnSXLfc= =qttu -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 5 Jahre OSM - eine persönliche Bilanz
Am 17.07.2013 02:03, schrieb Stephan Wolff: am 16.7.2008 habe ich meinen ersten Beitrag zu OpenStreetMap geleistet. Knuffig. Ich bin einen Monat länger aktiv, Jubiläum verpaßt. Damals war selbst in unserem Landeshauptdorf Kiel das Straßennetz nur zu einem kleinen Teil erfasst. Ich bin oftmals mit meinem alten GPS12 durch die Straßen und Wege geradelt, [...] Liest sich, wie bei mir abgeschrieben. Ok, den entsprechenden Essay habe ich tatsächlich nie geschrieben, er hätte aber sehr ähnlich ausgesehen. Trotzdem gibt es für mich auch einige Wermutstropfen. Ja. Für eine Neueinsteiger werden die Einstiegshürden immer größer, zum einen unvermeidlich, da es immer mehr und komplexere Daten gibt, die man nicht zerstören darf, aber zum anderen unnötig, da die Regeln und Gebräuche nur unvollständig und teils widersprüchlich im Wiki abgelegt sind und daneben viele weitere Informationsquellen mit schlecht auffindbaren Diskussionen. Gilt auch für Gelegenheitsmapper wie mich. Das Nachforschen, wie man ein Problem richtig löst, bringt häufig unklare oder widersprüchliche Informationen zu Tage. Ich verbinde dennoch viel positives mit meinem Engagement für OSM. Um fehlende Wege auszumessen, bin ich in viele Sackgassen und Feldwege gefahren und habe manch interessantes Detail entdeckt. Ich habe Ausflüge in schlecht erfasste Gegenden gemacht, die ich sonst nicht besucht hätte. Beim Editieren ergaben sich immer wieder Fragen, die mich zu Google-Recherchen animieren. Als Wikipedia-Knipser bei mir eher WP statt Google. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behinderung des mappens / Internetausdrucker Was: Wochennotiz Nr. 150 28.5.-3.6.2013
Am 06.06.2013 15:19, schrieb Florian Lohoff: Seit dem bin ich nicht mehr Nett Als Wikiknipser (Sehenswürdigkeiten, Baudenkmäler, pipapo, Hausnummern für OSM werden nebenbei mitfotografiert) habe ich relativ häufig Kontakt mit Anwohnern, die sich wundern, was ich denn da so mache. Wenn das Licht ungünstig steht, latscht oder fährt man ja manche Locations u.U. auch mehrfach zu unterschiedlichen Tageszeiten an, damit fällt man halt auf. Ich habe außer in einem Fall(1) durch geduldiges Erklären bisher noch jeden von meinen lauteren Absichten überzeugen können, einmal auch bei jemandem, der mir gleich die Kamera abnehmen wollte bzw. dann verlangte, alle Bilder zu löschen. Als ich mit dem fertig war, meinte er nur noch was von ok, aber nur von vorne, hinten ist ein (denkmalschutzrechtlich) problematischer Anbau. Die Fotos sind dann scheiße geworden, weil in der Zwischenzeit die Sonne untergegangen war. So what, irgendwann komme ich da wohl noch mal vorbei. Die Menschen sind idR nicht böse, sondern schlecht informiert, gerade durch den groben Unfug, der teilweise durch die Presse ging, als die Streetview-Sau durchs Dorf getrieben wurde. - Wer mir doof kommt dem komme ich auch doof Das halte ich, bei allem Respekt, für denkbar ungünstig. Ich bin, wenn ich mit der Knipse unterwegens bin, gewissermaßen Wikipedia-Vertreter, wenn auch latürnich kein offizieller. Aber die Leute sehen einen halt so. Da bemühe ich mich, jeglichen ungünstigen Eindruck zu vermeiden. Ja, das kann u.U. viel Zeit und Nerven kosten. Andererseits bin ich auch schon in einer ehemaligen Zechensiedlung von türkischstämmigen Anwohnern zum Tee eingeladen worden. - Im zweifelsfalle habe ich eine rechtliche Minimalposition Wenn mir einer gleich mit Rechten kommt, kriegt der natürlich Rechte geliefert. Freundlich, aber bestimmt. Sinnlose Zeitverschwendung. Sehe ich nicht so. Rainer (1) der hat, nachdem er mich nicht davon überzeugen konnte, die Speicherkarte rauszurücken, gleich mal die Pozilei gerufen, die dann auch anreiste und mich einige hundert Fotoknipsmeter weiter ansprach. Naja, der Beifahrer meinte, Wikipedia hätte ihm schon oft geholfen, wenn es um Hausaufgaben seiner Kinder ging... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building=yes vs. building=residential
Am 14.05.2013 08:48, schrieb Ronnie Soak: Renderingprobleme sollten nicht dazu fuehren, schlechter zu taggen. +1 Allerdings spricht auch nichts dagegen, das relativ ungenaue building=residential weiter zu verfeinern in z.B. building=house, =terrace, =appartments. Mir ist immer noch unkler, welcher Wert für Gebäude sinnvoll ist, die unten eine Ladenzeile und drüber Wohnungen haben. Da gibt es imo keine überwiegende Nutzung. building=gemischte_nutzung ... Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 10.05.2013 00:13, schrieb Tirkon: Auch ich habe anfänglich mit Potlatch Einiges unbeabichtigt zerstört. Hier selbiges. Dessen wurde ich aber erst gewahr, nachdem ich darauf hingewiesen wurde. Da ich hier im Ort praktisch nahezu alleine unterwegs bin, gibt es auch niemanden, der mich auf Fehler hinweist oder je hingewiesen hätte. Ok, es gibt einen Haufen Tools, die Fehler oder Unklarheiten anzeigen können, aber die muß man auch erstmal alle finden. Sowas wie ein Design Rule Check sollte in jedem Editor eingebaut sein. Es ist doch ein Witz, daß externe Tools nötig sind, um typische Fehler, wie z.B. dicht nebeneinanderliegende, aber nicht verbundene Wege zu finden oder unvollständige Abbiegerelationen. Erst nach dem empfohlenen Umstieg auf JOSM verstand ich und fand mich in der Historie als Verursacher von weiteren gefundenen Relationszerstörungen. Es wäre schön, wenn der Umstieg auf JOSM hierzu zukünftig nicht mehr zwingend erforderlich wäre. +1 Ich glaube, daß ich inzwischen als eingefleischter Potlatcher nicht mehr viel kaputtmache, aber daß es damit immer noch und jetzt mit dem ID erneut möglich ist, unbemerkt komplexere Strukturen zu zersemmeln, ist auf Dauer nicht tragbar. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am 10.05.2013 07:08, schrieb Wilhelm Spickermann: Ein drittes Splittingproblem gibt es bei den Kreisverkehren. Wenn ein Kreisverkehr Element einer Route ist, dann ist damit nur benötigte Teil des Kreisverkehrs gemeint. Splittet man ihn auf, dann gilt diese Sonderregel nicht mehr und man muss nicht zugehörige Teile wegwerfen und die anderen Teile sinnvoll umsortieren. Noch schlimmer: man muss alle anderen betroffenen Relation ebenso laden, den Kreisverkehr ggf. weiter splitten und bei allen nachkorrigieren. Das unterstützt keiner der Editoren. Ich habe mich mal mit dem Potlatch an solch einen Kreisverkehr gewagt, über den mehrere Buslinien und Radwegrelationen gehen mit unterschiedlichen Ein- und Ausgängen und forward/backward usw. Daran kann man, wenn man keine Routine hat, anscheinend stundenlang sitzen, bis das alles plausibel zusammenpaßt... Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Broken Turn Relations in Schweiz, Österreich, Bayern und Baden-Württemberg
Hallo, ich habe mit dem maptool von Navit ein paar Karten prozessiert und ein paar kaputte Turn Relations gefunden: http://bokomoko.de/~rd/navit/broken_turn_relations_130501.log Erfreulicherweise sind es viel weniger als vor 2 Monaten. Viele Grüße Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPS-Tracks in Potlatch 2
Moin! Nach längerer Hochladepause habe ich mal wieder anhand eines GPS-tracks editieren wollen. Dabei mußte ich feststellen, daß der hochgeladene Track http://www.openstreetmap.org/user/smial/traces/1436537 im Potlatch extrem vereinfacht angezeigt wird. Ich habe nicht gezählt, aber es wird gefühlt nur jeder zwanzigste Wegpunkt verwendet oder noch weniger: http://www.smial.prima.de/nmz/OSM/potlatchungenauergpstrack.png Das war früher(tm) nicht so. Ich habe auch alte Tracks von mir ausprobiert - dasselbe Ergebnis. Im Optionen-Dialog habe ich einen slider gefunden Simplify accuracy, der jedoch keinerlei Auswirkungen zeigt. Ist das ein neuer(?) Potlatch-Bug? Oder übersehe ich eine Einstellmöglichkeit? Was mache ich flacsh? Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Buchstaben-Ergänzung bei Hausnummern mappen?
Am 14.03.2013 03:05, schrieb Tirkon: 20a 20 a 20A 20 A Ist bekannt, ob irgendjemand die derzeitige Praxis bei OSM zumindest für Deutschland ermittelt hat? Sollte man sich nicht auf eine einheitliche Darstellng einigen und diese im Wiki empfehlen? Ich mappe, was ich sehe. Bei den Schildern erkenne ich in den allermeisten Fällen kein Leerzeichen dazwischen und der Buchstabe ist eigentlich immer auch klein geschrieben. Freilich habe ich hier auch ein Haus mit der Nummer 22.1 gefunden. Zumindest hier in der Gegend ein Unikat. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
Am 15.01.2013 01:04, schrieb Martin Koppenhoefer: Danke fürs Blocken. Inhaltlich stimme ich allerdings mit dem Mapper überein: foot=yes ist auch m.E. überflüssig an einem highway=footway. Solche Redundanzen rauszulöschen ist ebenso überflüssig, denn sie bringen keinen wirklichen Vorteil für Nachnutzer, blähen dafür aber unnötig die History auf. Redundanzen machen eine Datenbasis gewöhnlich stabiler, vor allem dann, wenn viele Leute an denselben Objekten herumfuhrwerken. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Güllebehälter
Am 09.12.2012 20:45, schrieb Albrecht Will: wer könnte mir sagen, in welchem wiki etwas über die tags für Güllebehälter zu finden ist? Zumal es die in der Standardvariante einfach-so-Güllespeicher gibt. Aber auch mit Hut in Verbindung mit Biogasanlagen. Würde mich also auch interessieren. Beide Varianten. -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzahl der Punkte in einem Polygon für einen Zoom Level optimieren
Der Douglas-Peucker-Algorithmus könnte sowas bewerkstelligen: http://de.wikipedia.org/wiki/Douglas-Peucker-Algorithmus Gruß rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Schönes und nützliches Tool. Ich habe aber keine Möglichkeit gefunden, nur die Labels einer bestimmten Sprache anzuzeigen, d.h. nur den Text aus den name:sprachcode-Tags. Das wäre ganz nützlich, wenn man sich einen Überblick über die Labels einer bestimmten Sprache verschaffen möchte, z.B. in mehrsprachigen Regionen. Man könnte das über einen Eintrag without name tag im Dropdown realisieren. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Leitschwelle, gelb, mit große rote Fahne
Steht da so ;-) Gemeint ist http://www.toool-factory.com/Leitschwelle-gelb-mit-grosse-rote-Fahne.htm Hier gibt es (mindestens) drei Lokalitäten in der Nähe, wo solche bzw. ähnliche Schwellen dauerhaft angebracht sind. Wie würdet ihr das mappen wenn a) schon zwei getrennte Richtungsfahrbahnen gemapt sind und diese Schwellen dazwischen liegen und b) nur ein einzelner way gezeichnet ist und diese Dinger das Abbiegen bzw. den Fahrbahnwechsel verhindern, mithin eine durchgezogene Linie verstärken sollen? Rainer -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leitschwelle, gelb, mit große rote Fahne
Am 29.11.2012 19:58, schrieb Andreas Dommaschk: wenn es irgendeine Bedeutung für das Routing hat dann ja. Ich mappe einklich nicht für Karten oder Routing, sondern das, was ich sehe. Und ich sehe dort eine Barriere, die beispielsweise an zwei der drei erwähnten Stellen aufgestellt wurde, um das offenbar allzuoft mißachtete Linksabbiegeverbot ein wenig moralisch zu unterstützen. An beiden Stellen haben wartende Linksabbieger mehrfach zu Auffahrunfällen geführt, die dritte Angelegenheit behindert allzu rasante Spurwechsel, ebenfalls früher ein Unfallschwerpunkt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Broken Turn Relations
Hallo, hier ist ein Update von Broken Turn Relations, wie sie von Navits maptool berichtet werden: http://bokomoko.de/~rd/broken_turn_relations_121125.log Es ist leider noch ein bug in maptool, der ein paar falsche Warnungen generiert: http://trac.navit-project.org/ticket/1076 Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Broken Turn Relations
Danke, Franz. Rainer Am Sunday 25 November 2012 schrieb Franz vonGordon: Hallo, Deine Liste habe ich in unserem Wiki ergänzt [1], damit jeder seine korrigierten Restrictions dort abhaken kann. [1] http://wiki.openstreetmap.org/wiki/DE:Relation:restriction/Fehlerhafte_Abbi egebeschr%C3%A4nkungen Grüße, Franz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Broken Turn Relations
Hallo Eckhart, guter Punkt, da muss ich selbst nachfragen. Gruß Rainer Am Sunday 25 November 2012 schrieb Eckhart Wörner: Hallo Rainer, Am Sonntag, 25. November 2012, 18:25:58 schrieb Rainer Dorsch: hier ist ein Update von Broken Turn Relations, wie sie von Navits maptool berichtet werden: http://bokomoko.de/~rd/broken_turn_relations_121125.log OSM Warning: http://www.openstreetmap.org/browse/relation/2545313 turn restriction: to member not found Was ist die Bedeutung der Fehlermeldung hier genau? Die Relation sieht einwandfrei aus (und das schon seit dem 1. November). Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdor...@web.de jabber: rdor...@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Detailmapping
Am 16.11.2012 14:48, schrieb tumsi: Hallo zusammen, Ich bin gerade auf einen Fall von außerordentlichem Detailmapping gestossen [1]: Gartenwege, Grundstücksbegrenzungen durch Zäune und Hecken, Garagenauffahrten, kleine Gartnteiche etc. Mir ist schon klar, dass, wenn es die entsprechenden Tags gibt, sie auch benutzt werden. Aber aus meiner Sicht, ist das schon mehr als übertrieben. Was meint ihr. Sollte man den Nutzer weiterhin so gewähren lassen oder ihn vielleicht doch mal drauf hinweisen, dass das, was er macht, übertrieben ist? Viele Grüße, Constanze [1] http://www.openstreetmap.org/?zoom=18lat=51.93865lon=11.22743 Den vielfachen Einsatz von track würde ich mal kritisieren wollen, das sind überwiegend keine tracks und von daher sieht das nach Mappen für den Renderer aus. Man könnte den User auf den sinnvollen Einsatz von access-tags hinweisen und auf highway=service, service=alley. Gegen den Detailreichtum als solchen kann ich eigentlich nichts einwenden, aucn wenn ich denke, daß der Energieeinsatz anderswo u.U. nützlicher wäre. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen
Am 06.11.2012 22:16, schrieb Jörg Frings-Fürst: Als Source für die Grenze Hupperath (Rel.ID. 1259140) war [1] eingetragen. Ich kann zwar nicht verstehen warum so etwas (nicht georeferenziert, viel zu stark vereinfacht) als Vorlage benutzt wird, Ich habe vor rund 2 Jahren ebenfalls viele grobe Gemeindegrenzen für RLP aus Wikipedia genommen. Warum? Weil sie seinerzeit leicht verfügbar waren und für Dinge wie Straßenlistenabgleich absolut ausreichend. Ich habe mir zugegebenermaßen aber die Mühe gemacht, diese groben Grenzen mit anderen, genaueren Quellen abzugleichen. ;) zumal die Grenzen, wenn ich mich richtig erinnere, schon mal viel genauer eingetragen waren. Es gab in RLP importierte Kreisgrenzen, die recht genau waren. Auf den unteren Verwaltungsebenen i.d.R. aber nichts. Beste Grüße, Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Problem mit History eines Ways
Moin, ich hätte da gerne mal ein Problem. http://www.openstreetmap.org/browse/way/35743954/history Laut Chronik gibt es also genau eine Version. Im Potlatch werden mir aber DREI Versionen angezeigt (Edit in Potlatch2, weg anklicken, H drücken). Ich habe auch tatsächlich an dem way herumgeschoben, weil der durch das von mir eingezeichnete Mühlenhaus führte. Außerdem habe ich den anders an den benachbarten way http://www.openstreetmap.org/browse/way/35743953/history angeschlossen. Auch bei dem zeigt potlatch FÜNF Versionen, die Chronik nur zwei. Aber während 35743953 noch genau so aussieht, wie ich ihn hinterlassen habe, hat sich 35743954verdoppelt und schlägt lustige Haken. Was ist da passiert? Rainer Ps: Den Mapper seawolff habe ich schon angeschrieben, aber noch keine Antwort bekommen. Pps: Gerade erst gesehen: http://www.openstreetmap.org/browse/way/35743956/history derselbe Effekt, zusätzlich mit verwaisten Nodes http://www.openstreetmap.org/browse/node/1987807697 http://www.openstreetmap.org/browse/node/1987807696 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit History eines Ways
Am 01.11.2012 11:55, schrieb Jochen Topf: On Thu, Nov 01, 2012 at 10:14:49AM +0100, Rainer Knaepper wrote: ich hätte da gerne mal ein Problem. http://www.openstreetmap.org/browse/way/35743954/history Laut Chronik gibt es also genau eine Version. Im Potlatch werden mir aber DREI Versionen angezeigt (Edit in Potlatch2, weg anklicken, H drücken). Wahrscheinlich wurden Nodes bewegt und Potlatch macht dann eine Pseudo-Version draus. Die Version des Ways ändert sich in der Datenbank ja nur, wenn sich die Tags oder die Node IDs ändern, nicht wenn sich die Koordinaten der Nodes ändern. Wo speichert Potlatch denn diese Pseudo-versionen, wenn nicht in der Datenbank? -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit History eines Ways
Am 01.11.2012 13:00, schrieb Martin Koppenhoefer: Am 01/nov/2012 um 12:21 schrieb Rainer Knaepper sm...@gmx.de: Wahrscheinlich wurden Nodes bewegt und Potlatch macht dann eine Pseudo-Version draus. Die Version des Ways ändert sich in der Datenbank ja nur, wenn sich die Tags oder die Node IDs ändern, nicht wenn sich die Koordinaten der Nodes ändern. Wo speichert Potlatch denn diese Pseudo-versionen, wenn nicht in der Datenbank? Steht ja oben, es sind Node-Versionen aus denen pseudoversionen des Ways generiert werden. Das erklärt immer noch nicht, weshalb der Weg nach dem Edit von seewolff Haken schlägt (und auch von mapnik so lustig doppelt gerendert wurde) und woher die verwaisten Nodes am Mühlteich und neben dem davon abgehenden Bach herkommen. Aber egal, die toten Nodes interessieren mich nicht und den Weg habe ich halt nochmal repariert. Rainer (der einen falsch aufgelösten Bearbeitungskonflikt vermutet, aber wenn das unwichtig ist, dann ist das eben unwichtig) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit History eines Ways
Am 01.11.2012 18:48, schrieb Stephan Wolff: Am 01.11.2012 10:14, schrieb Rainer Knaepper: http://www.openstreetmap.org/browse/way/35743954/history Laut Chronik gibt es also genau eine Version. Im Potlatch werden mir aber DREI Versionen angezeigt (Edit in Potlatch2, weg anklicken, H drücken). Moin, 2009 hatte ich die Mühle nach einem Besuch am Mühlentag (Der deutsche Mühlentag ist jedes Jahr der Pfingstmontag) auf Basis meiner GPS-Daten erstellt. Mehr als drei Jahre hat niemand die Daten angefasst... Sonntag hat Rainer die Mühle und Umgebung verbessert und zeitgleich habe ich ebenfalls den See und den Pfad anhand der jetzt verfügbaren Bing-Luftbilder editiert. Beim Upload meiner Daten kam es zu mehreren Konflikten. Genau sowas hatte ich mir gedacht! Ich war auf Wikiknipserfototour und bastele dann die Objekte, die ich besucht habe, gewöhnlich auch bei OSM rein. Da ich ziemlich lange innerhalb der Mühle zugange war, ist mein GPS-Track freilich ziemlich hudelig, aber zusammen mit den Bing-Bildern kriegt man damit gewöhnlich was brauchbares zustande. Es lohnt übrigens wirklich, dort mal reinzuschauen :-) Ich habe jeweils die aktuelle Datenbankversion bei der Konfliktlösung ausgewählt und meine Änderungen an diesen Objekten verworfen. Trotzdem hat es mein Upload offenbar in die Potlatch- Historie geschafft. Vielleicht kann ein Eingeweihter erklären, welche Transaktionen in der Datenbank intern ablaufen. Potlatch hat jedenfalls keinerlei Konflikte angezeigt. Als ich die Sitzung beendete, war auch sozusagen meine Version bei mapnik aktuell (per Kartenneuanforderung überprüft, mache ich immer, um zu sehen, ob ich nicht versehentlich etwas gründlich versemmelt habe). Hab dann erst einen Tag später entdeckt, daß da was verstrubbelt war. Tjo, und da fand ich dann eben deine etwas später gespeicherten Änderungen. Auch die toten Nodes am Mühlbach südlich der Straße, wo wir offensichtlich einen sehr nahe beieinanderliegenden Verlauf nach Bing gemalt haben, aber die Punkte unterschiedlich gesetzt. Beim Fußweg hat deine Version gewonnen, beim Bach meine. Schon komisch. Es ist natürlich ein vermutlich ziemlich seltener Zufall, daß sich in einem so abgelegenen Landstrich zwei Mapper am selben Abend in die Quere kommen. Trotzdem wundert mich, daß solche Bearbeitungskonflikte nicht von der zur Verfügung stehenden Software besser abgefangen wird. Ich habe die Nachricht zu spät bemerkt. Macht ja nix, Hauptsache wir finden bei Problemen eine Lösung, ich denke, auf einen Tag oder eine Woche mehr oder weniger kommt's nicht drauf an :-) Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Länderübersetzungen mittels CLDR
Hallo, 22/10/2012 10:17 Manfred A. Reiter: Am 22.10.2012 02:20 schrieb Stephan Wolffs.wo...@web.de: - bei einigen Übersetzungen sind falsche Namensteile dabei, z.B. name:ilo = Berlin, Alemania name:pdc = Berlin, Deitschland Da wäre ich Mir nicht sicher, dads das falsch ist. ;-) Im Hunsrücksch (Südbrasilien) heisst es auch Deitschland. Es geht nicht um die korrekte Scheibweise sondern darum, dass der Zusatz , staat' im name-Tag nichts zu suchen hat. Ähnlich ist es bei name=Washington, wo sich in den sprachspezifischen Bezeichnungen die folgenden Zusätze mehrfach finden: DC , DC D.C. , D.C. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=school / building=yes / addr?
Hallo, 21/10/2012 14:31 Florian Lohoff: Das sagt das wiki eben anders - amenity=school soll die Flaeche und nicht nur das einzelne Gebaeude bezeichnen. Was Wiki sagt ist eine Sache, was man in der Realität vorfindet, eine andere. So gibt es zum Beispiel Schulzentren, wo auf einem Gelände mehrere schulische Einrichtungen untergebracht sind, z.B. ein Gymnasium und eine Berufsschule, oft verteilt über mehrere Gebäude und beide Schulen in ein und demselben Gebäude und mit gemeinsamen Einrichtungen (Turnhalle, Mensa). Hier taggt man sinnvollerweise die einzelnen Einrichtungen als Punkt oder Gebäude mit amenity=school. Das Gelände soll natürlich auch erfasst und mit seinem Namen versehen werden, z.B. Schulzentrum Kleinkleckersdorf. Dies mit amenity=school zu machen ist nicht sinnvoll. Es führt zwar beim Rendern zum gewünschten Erfolg, aber eine Applikation, die nach alle Schulen in Kleinkleckersdorf sucht, käme da ins Schleudern, weil das Gelände als weitere Schule interpretiert würde. Aeh - ist doch quatsch - Schulen gehoeren zur Wohnnutzung - genauso wie Kindergärten - Die stehen in Deutschland im überwiegenden Teil immer in der Wohnbebauung. Aus oben genannten Gründen ist es durchaus sinnvoll und in anderen Ländern, wie z.B. Frankreich, auch üblich, ein Schulgelände, auf dem mehr als eine Schule untergebracht ist, mit landuse=school zu taggen. Noch besser fände ich amenity=school_centre, aber das kennt wahrscheinlich kein Renderer und keine Applikation. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ist das taggen für Mapnik?
Am 20.10.2012 02:44, schrieb Martin Koppenhoefer: Am Freitag, 19. Oktober 2012 schrieb Rainer Knaepper : Ich habe hier: http://www.openstreetmap.org/?**lat=49.460967lon=11.093388** zoom=18layers=Mhttp://www.openstreetmap.org/?lat=49.460967lon=11.093388zoom=18layers=M einen U-Bahnsteig gefunden, der als Fußweg gemapt ist und als Tunnel. Ist das so ok? Oberirdisch sieht man dort im wesentlichen gepflasterte Fahr- und Gehwege, Straßencafés, einen Fahrstuhl, Blumenbeete und darin eingebettete lustige Lichtkuppeln. Unterirdisch passt der Fußgängertunnel doch so halb. Den Bahnsteig könnte man auch als platform mappen Hmnaja, wenn jetzt noch einer die unterirdischen Sitzbänke und Infotafeln mapt und oberirdisch die Beete angelegt werden, dürfte die Karte arg unübersichtlich werden. Rainer (der desweiteren auf Reparaturen und Ergänzungen beim naheliegenden Stadtpark verzichtet hat, weil dessen Grenzen allesamt mit den umliegenden Straßen verknüpfnodet sind. Nervig.) Ja, das ist wirklich nervig. Leider haben auch hundert Beiträge lange Diskussionen in der Vergangenheit bei diesem Thema keinen Konsens herstellen können. Ich habe nicht alle verfolgt. Argumente haben beide Seiten. Es gibt Mapper, die das besser finden, weil sie keine weißen Stellen in der Karte haben wollen, daher vergrößern sie alle angrenzenden Flächen bis zur Straßenmitte. Das andere Argument ist, dass man nur so feststellen könne, welche Flächen an eine Straße anschließen. Was im genannten Fall genau problematisch ist. Da stehen Recyclingbehälter herum, natürlich NICHT im Park, auch nicht auf der Straße, sondern am Straßenrand. Und ich habe keine Ahnung, wie ich da die Parkbuchten unterbringen soll, ohne die gemeinsamen Nodes aufzulösen. Für das bisken Verfeinerung ist mir der Aufwand schlicht zu groß. Der parallele Cycleway http://www.openstreetmap.org/browse/way/136351912 geht keineswegs durch den Park, sondern schlängelt sich zwischen (lückenhaftem Parkzaun und Parkbuchten hindurch. Btw. cycled dort kein Mensch, dafür aber auf allen footways /innerhalb/ des Parks. Aber das ist ein ganz anderes Thema. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Länderübersetzungen mittels CLDR
Hallo, 20/10/2012 23:47 Kolossos: Puh, so die Übersetzungen der Hauptstädte sind jetzt mit Hilfe der Wikipedia und Add-tags auch drin. Ich habe mir nur ein Beispiel, Paris, angeschaut und habe dazu zwei Anmerkungen: Du hast capital=2 durch capital=yes ersetzt. Ich entnehme dem proposal zu capital und Taginfo, dass es durchaus üblich ist, den admin_level der Verwaltungseinheit anzugeben, um deren Hauptstadt es sich handelt. Du ersetzt wikipedia=en:Paris durch wikipedia=de:Paris. Aus meiner Sicht ist das nicht ok. Wenn du unbedningt auf die deutsche Wikipedia-Seite verlinken willst, dann mache das mit wikipedia:de=Paris. Der Rest der Welt ist mit Englisch sicher besser bedient. Einem so sensiblen Thema wie das automatischen Taggen von Hauptstädten hätte ich an deiner Stelle erst mal auf der internationalen Liste zur Diskussion gestellt. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ist das taggen für Mapnik?
Ich habe hier: http://www.openstreetmap.org/?lat=49.460967lon=11.093388zoom=18layers=M einen U-Bahnsteig gefunden, der als Fußweg gemapt ist und als Tunnel. Ist das so ok? Oberirdisch sieht man dort im wesentlichen gepflasterte Fahr- und Gehwege, Straßencafés, einen Fahrstuhl, Blumenbeete und darin eingebettete lustige Lichtkuppeln. Rainer (der desweiteren auf Reparaturen und Ergänzungen beim naheliegenden Stadtpark verzichtet hat, weil dessen Grenzen allesamt mit den umliegenden Straßen verknüpfnodet sind. Nervig.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kaputte Turn Relations: Deutschland, Österreich, Schweiz, Italien, Tschechien
Am Tuesday 09 October 2012 schrieb Eckhart Wörner: Hallo Rainer, Am Sonntag, 7. Oktober 2012, 20:18:51 schrieb Rainer Dorsch: habe hier eine lange Liste mit kaputten Turn Relations (Deutschland und Italien sind ca. 1 Woche alt, alle anderen sind von heute): http://bokomoko.de/~rd/broken_turn_relations_121007.log Grrr, immer noch mit Fehlalarm, z.B.: OSM Warning:http://www.openstreetmap.org/browse/relation/3659 turn restriction: multiple via member Hallo Eckhart, ich habe einen maptool bugreport geöffnet: http://trac.navit-project.org/ticket/1076 Bitte kommentiere wenn möglich direkt dort, wenn ich das nicht korrekt oder vollständig dargestellt habe. Danke und Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kaputte Turn Relations: Deutschland, Österreich, Schweiz, Italien, Tschechien
Hallo, habe hier eine lange Liste mit kaputten Turn Relations (Deutschland und Italien sind ca. 1 Woche alt, alle anderen sind von heute): http://bokomoko.de/~rd/broken_turn_relations_121007.log Wenn hilfreich, lasse ich das ganze nächste Woche nochmal laufen. Viele Grüße Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkhaus richtig mappen
Am 04.10.2012 15:13, schrieb Andreas Hubel: Kannst du mal ein paar Kartenauschnitte zeigen (via Link)? Hier (Parking Wilson): http://www.openstreetmap.org/?lat=42.701965lon=2.896005zoom=18layers=M Hier ist ein anderes Beispiel, das nicht von mir stammt: http://www.openstreetmap.org/?lat=49.181392lon=-0.363055zoom=18layers=M Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Parkhaus richtig mappen
Hallo, Eine unterirdisches Parkhaus hat zwei Zufahrten und zwei Ausfahrten und mehrere Abgänge für Fußgänger. Wie mappt man so etwas sauber, so dass alle Zu- und Ausfahrten und die Abgänge dem Parkhaus zugeordnet sind, und dann (hoffentlich) das (Oberflächen-)Routing bei Zieleingabe Parkhaus XXX sowohl für Kfz als auch Fußgänger funktioniert? Mein erster Ansatz war, die Zugänge mit Wegen zu verbinden, welche mit gighway=service service=parking_aisle level=-1 tunnel=yes getaggt sind. An einen Node auf diesen Ways kommt amenity=parking und name=xxx. Damit sollten Router zurecht kommen. Leider sieht das auf den üblichen Karten nicht besonders elegant aus. Ausserdem entspricht die unterirdische Wegführung nicht der Realität. Alternativ käme eine Site-Relation in Frage. In diesem Fall würde ich nur die Zugänge mappen und zu der Relation hinzufügen. Ich befürchte aber, dass kein Router diese Art von Relation auswertet. Gibt es bessere Vorschläge oder Beispiele? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressen
Am 22.09.2012 13:12, schrieb Frederik Ramm: addr:* gehoert an alles, was eine Adresse hat. Eine Stadt oder ein Baum haben keine. Bräutigamseiche, Dodauer Forst, 23701 Eutin :-) http://de.wikipedia.org/wiki/Br%C3%A4utigamseiche Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garagenanlagen und Gassen in Wohnsiedlungen
Moin! Wie mapt ihr diese Gassen zwischen den in Wohnsiedlungen häufig vorkommenden Garagenreihen? highway=service service=[driveway|parking_aisle|irgendwasanderes] Weiters: Diese Reihenhausansammlungen haben oft sehr schmale Stichstraßen zu den abzweigenden Reihenhäusern. Meist Sackgassen. Manche sind so schmal, daß kein Auto reinpaßt, manche, etwas breitere, werden offensichtlich genutzt, um den Wochenendeinkauf vor der Haustür zu entladen, in der Zeit paßt aber nichts anderes da hindurch. Gelegentlich findet sich am Ende eine einzelne Garage oder ein Carport. Die ganz schmalen sind offensichtlich Fußwege. Verpaßt ihr diesen und den etwas größeren Stichwegen auch den Straßennamen? Access grundsätzlich als private annehmen, auch wenn kein Schild da steht? Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aktuelle ODbL Küstenlinien und neuer OSM-Inspector Coastline View
Am 17.09.2012 09:51, schrieb Jochen Topf: Zum JOSM-Link siehe meine andere Mail. Die Links zu den Objektdaten und zur History können in diesem Fall nicht gehen, da die Küstenliniendaten nicht mehr mit OSM-Objekten verbunden sind. Mir ging es um den erwähnten, inzwischen wohl behobenen Fehler in Kroatien, bei dem der Inspector zwar eine OSM-Id (1061888547) angezeigt hat, aber der JOSM-Link nicht funktioniert hat. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aktuelle ODbL Küstenlinien und neuer OSM-Inspector Coastline View
Am 17.09.2012 06:57, schrieb p...@wuzel.de: Bei mir funktioniert der Josm-Link über der Karte, nicht jedoch der Josm-Link in der Selection, also der beim ausgewählten Fehler (gerade getestet mit osm_id: 1061888547 in Kroatien). Auch die Links zu den Objektdaten und zur History auf Openstreetmap.org funktionieren nicht. Da ist offenbar ein Fehler im Skript, mit dem das HTML erstellt wird. Ich habe das mal an Geofabrik gemeldet Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Am 06.09.2012 09:17, schrieb Eckhart Wörner: Doch, sicher. Getaggt wird nicht das Verhalten der Schranke, sondern die Beschränkungen, die sich daraus ergeben. So sehe ich das auch. Schranken sind physikalische Mittel um Zugangssperren durchzusetzen. Wenn an dem im UP angesprochenen Tunnel ein aufklappbares Schild 250 Verbot für Fahrzeuge aller Art angebracht wäre, das nur bei Bedarf aufgeklappt wird, dann hätten wir dieselbe Diskussion. Schranken müssen daher so getaggt werden wie Straßen, für welche dieselben Beschränkungen auf andere Weise festgelegt sind. Ob da ein Schild gesperrt für Fz aller Art zwischen 20:00 und 06:00 hängt oder eine Schranke steht, die abends um acht geschlossen wird, läuft rechtlich auf dasselbe hinaus. Oder um bei dem Beispiel im UP zu bleiben: wenn bei einem Unfall im Tunnel ein Schild 250 auf die Straße gestellt wird, ist das Ergebnis dasselbe, wie wenn eine normalerweise offene Schranke geschlossen wird. Ich würde sogar soweit gehen und die Beschränkungen nur an die Wege zu taggen, und sei es nur ein kleines Stück um die Schranke herum. Hingegen ist es sinnvoll, das Vorhandensein und die physikalischen Eigenschaften sowie die Regeln für des Öffnen/Schliessen der Schranke unabhängig von den damit durchzusetzenden rechtlichen Beschränkungen zu taggen. Das könnte z.B. für Notdienste nützlich sein, die grundsätzlich überall durchfahren dürfen. Da kann es wichtig sein, ob man einen Schlüssel zum Öffnen braucht oder ob dort rund um die Uhr Bedienpersonal sitzt. Oder für Leute, die sich ungern an Verbote halten, die schon im Voraus wissen wollen, ob sie dort über eine Schranke klettern müssen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Am 05.09.2012 23:22, schrieb Tirkon: Das access-Tag beschreibt im verbreiteten OSM Gebrauch die Zugangsmöglichkeit trotz geschlossener Schranke - in diesem Falle also den Zeitpunkt, wenn sie ausnahmsweise nicht offen sein sollte. Oder anders gesagt: wenn die Schranke offen ist, gelten die Access-Tags der angrenzenden Straßen. Wenn sie geschlossen ist, gelten zusätzlich die Access-Tags der Schranke. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Am 06.09.2012 11:02, schrieb Martin Koppenhoefer: oder, grundsätzlich offen, ausser in seltenen Ausnahmefällen: access=yes note:de=bei Tunnelbrand oder Weihnachten an einem Freitag geschlossen Und wo steht, für wen die geschlossene Schranke gilt? Wenn am Freitag nach Weihnachten Kfz nicht, Radfaher und Fußgänger aber schon dürfen? access:if_closed? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Am 06.09.2012 10:44, schrieb Georg Feddern: Am 06.09.2012 09:58, schrieb Rainer Kluge: Oder anders gesagt: wenn die Schranke offen ist, gelten die Access-Tags der angrenzenden Straßen. Wenn sie geschlossen ist, gelten zusätzlich die Access-Tags der Schranke. Und wovon geht ein Router dann bei der Berechnung aus? Ist die Schranke dann gerade geschlossen oder offen? Muss er also die access-Tags der Schranke nun beachten oder nicht? Das ist ein separates Thema, auf das ich in diesem Teilthread, in dem es um die Access-Tags geht, bewusst nicht eingegangen bin. In dem im UP geschilderten Fall hat der Router ohnehin nichts von den Tags an der Schranke, egal was man da alles reinpackt. Oder soll man taggen, dass am 24.12.2012 zwischen 13 und 15 Uhr wegen Unfall geschlossen sein wird? Das ist schon am Anfang von jemandem gesagt worden. Dazu braucht er TMC oder ähnliches, und dann braucht er wiederum die statischen Infos aus OSM nicht. Es geht nur darum, wie man ihm mitteilt, dass normalerweise offen ist. Das soll und kann man nicht über access machen sondern über eine spezielles Tag wie z.B.: barrier:closed=permanently|on_emergency|14:00-17:00|sunday|24.12-06.01 Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Am 06.09.2012 11:21, schrieb Martin Koppenhoefer: Am 6. September 2012 09:58 schrieb Rainer Klugerklug...@web.de: Oder anders gesagt: wenn die Schranke offen ist, gelten die Access-Tags der angrenzenden Straßen. Wenn sie geschlossen ist, gelten zusätzlich die Access-Tags der Schranke. hierzu wurde schon wiederholt festgestellt, dass access-tags auf ways nicht unbedingt mit den access-tags auf einem barrier-node in Beziehung stehen, daher sollte man das auch getrennt betrachten und taggen, egal wie kurz die ways um den node herum sind. Es gelten immer (bzw. in den definierten Zeiten) die access-tags sowohl der nodes als auch der ways. Ob dazu die Schranke offen sein muss, oder ob man bei geschlossener Schranke durchfahren/-gehen darf spielt doch keine Rolle. So war das gemeint. Unabhängig davon, *wie* man die durch die geschlossene Schranke erzwungenen Zugangsbeschränkungen erfasst, gelten diese in Kombination mit den Beschränkungen der Ways. Und wenn die Schranke offen ist, dann gelten nur die Beschränkungen der Ways. Somit geht es um zwei voneinander unabhängige Fragen: 1) Wie erfasst man die Kriterien für das Schliessen der Schranke 2) Wie erfasst man die Beschränkungen durch die Schranke Wenn 1) geklärt ist, braucht man bei 2) den Zustand Schranke offen nicht mehr zu berücksichtigen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM: erster ODbL Planet!
Am 06.09.2012 15:35, schrieb qunuxy-osmmailingli...@yahoo.com: Nein, das liegt daran, dass die Geofabrik-Extrakte heute teilweise leer sind: http://download.geofabrik.de/osm/europe/ Das Problem ist dort wohl bekannt. Dazu wurde heute morgen etwas auf Twitter geschrieben: https://twitter.com/geofabrik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] SOTM Live Stream Videos
Hallo, Vielleicht ist ja schon irgendwo in einem Thread erwähnt worden, es gibt zwei Livestreams von der SOTM: Main: Convention Hall (2F) http://www.ustream.tv/channel/sotm-main Second: Conference Room (3F) http://www.ustream.tv/channel/sotm-second Ausserhalb der Kongresszeiten werden dort Aufzeichnungen gezeigt, zur Zeit auf dem ersten Channel eien Aufzeichnung mit Frederik und seiner Präsentation von I like OSM (ab 26:50) Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM: erster ODbL Planet!
Am 06.09.2012 18:00, schrieb Sven Geggus: Rainer Klugerklug...@web.de wrote: Das Problem ist dort wohl bekannt. Dazu wurde heute morgen etwas auf Twitter geschrieben: https://twitter.com/geofabrik Da das Geofabrik Team auf SOTM ist würde ich da nicht unbedingt eine schnelle Lösung erwarten. Frederik ist wohl schon dran (Info aus Tokio von Emilie Laffray auf der französischen Liste [1]) [1] http://lists.openstreetmap.org/pipermail/talk-fr/2012-September/047383.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezifische Radweg-Karte für Garmin?
Hallo, Am 04.09.2012 11:54, schrieb aighes: schau dir mal folgende Anleitung an: http://noegs.blogspot.de/2012/01/tracks-als-transparente-garmin-karte.html Das ist so ungefähr der Weg, den Sven vorgeschlagen hat. Hier allerdings mit dem Start bei einem gpx-Track, der dann per josm zu einer osm-Datei konvertiert wird. Wenn der Radweg als Relation in OSM komplett vorhanden ist, müsste das auch ohne diesen Umweg nur über den mkgmap-Style und TYP-Datei funktionieren: In der Datei relations eine Regel, mit der man den Elementen der betreffenden Relation ein spezielles Attribut verpasst, diesen in der Datei lines einen freien Garmin-Typ zuweist und diesem in der TYP-Datei eine besondere Farbe. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezifische Radweg-Karte für Garmin?
Hallo Lars, Am 04.09.2012 08:45, schrieb Lars Schimmer: und dann so ein 50-100km breites Band um den Radweg herum mit dazu? Ein Lösungsansatz könnte grob so aussehen: Den Weg mit dem Douglas-Peucker-Algorithmus stark reduzieren, ein Polygon in 50km Abstand um den reduzierten Weg konstruieren, mit osmosis und diesem Polygon als Bbox ein OSM-Extrakt erstellen und die Karte aus diesem Extrakt generieren. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus um Eckernförde und anderswo
Hallo Simon, Am 30.08.2012 16:23, schrieb Simon Poole: Ich bin immer noch der Meinung, dass der attraktivster Weg um das ganze etwas zu entschärfen drin besteht via API gewisse Grenzen die automatisch erhöht werden zu setzen (sprich die fallen dann auch ziemlich schnell weg). Läuft der Neumapper da rein, sollte der Editor/API ihm entweder die Möglichkeit geben den Changeset zu verwerfen oder es in eine Queue zur Validierung zu schicken. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus um Eckernförde und anderswo
Sorry, ich habe zu früh auf Senden gedrückt. Am 31.08.2012 06:51, schrieb Rainer Kluge: Hallo Simon, Am 30.08.2012 16:23, schrieb Simon Poole: Ich bin immer noch der Meinung, dass der attraktivster Weg um das ganze etwas zu entschärfen drin besteht via API gewisse Grenzen die automatisch erhöht werden zu setzen (sprich die fallen dann auch ziemlich schnell weg). Läuft der Neumapper da rein, sollte der Editor/API ihm entweder die Möglichkeit geben den Changeset zu verwerfen oder es in eine Queue zur Validierung zu schicken. Eine Queue, in die man freiwillig einstellt, ist für Neumapper hilfreich, gegen Vandalismus hilft sie natürlich nicht. Wenn man sich mal über die Karten von Pascal stichprobenweise die Neumapper der letzten Woche unter die Lupe nimmt, dann stellt man fest, dass darunter sehr viele Einmal- oder Wenig-Mapper sind. Manche melden sich an und erfassen einen einzigen POI und dann erst mal nichts mehr. Oft ist das ganz offenbar ein POI, zu dem sie einen persönlichen Bezug haben, eine Einrichtung, in der sie arbeiten, ihr eigener Laden oder der Bäcker um die Ecke. Die Zahl der Neu-User, die von Anfang an oder irgendwann später umfangreiche Änderungen durchführt, liegt also wahrscheinlich um Größenordnungen unter den genannten 9000 im Monat. Die zu überwachen wäre mit einer relativ kleinen Zahl von Freiwilligen sicher zu schaffen. Das könnte über ein Monitoring-System organisiert werden, bei dem man per Abo über umfangreiche bzw. kritische Changsets von Neulingen in einem bestimmten Gebiet informiert wird. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus um Eckernförde und anderswo
Hallo, Am 26.08.2012 18:31, schrieb Frank: statt sich auf Provider und Gerichte zu verlassen, wird es vielleicht mal notwendig werden, dass OSM sich selbst aktiv darum kümmert, den Datenbestand besser zu schützen. +1 Dies könnte in einem strengeren Verfahren zur Registrierung bestehen. Ich sehe nicht, was man bei der Registrierung mit einem für beide Seiten vertretbaren Aufwand machen könnte. Da es nach meiner Kenntnis trotz des eigentlich leichtsinnig einfachen Zugangs zu den Lösch- und Änderungsrechten relativ wenig Vandalismus gibt, ist das wohl zur Zeit noch nicht notwendig. Da es sich um ein sensibles Thema handelt, ist damit zu rechnen, dass die Konsensfindung und die Umsetzung sehr lange dauern wird, sollte man trotzdem schon mal anfangen, sich Gedanken zu machen und ggf. Schutzmechanismen implementieren, die man zu gegebener Zeit kurzfristig scharf schalten kann. Bei einer Community, die zu Recht sehr sensibel gegenüber Eingriffen in die Privatsphäre ist, bleiben als einfach zu implementierende Mittel aus meiner Sicht nur gestaffelte Zugriffsrechte als Maßnahme gegen Missbrauch. Schon eine generelle 24-Stundensperre nach der Anmeldung wirkt in vielen Fällen Wunder. Für komplexere Änderungen und vor allem Löschungen, könnte man längere Wartezeiten und/oder Mengenbegrenzungen einführen. Ein Moderationsverfahren oder ein Bewertungssystem wären zumindest in Regionen mit starker Community sicher machbar. Ob das konsensfähig ist, bezweifle ich allerdings. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Braucht es gemappte Flusseinzugsgebiete? - Namen
Am 27.08.2012 15:09, schrieb Markus: Ja, Staaten (und ihre Hauptstädte) sind die einzigen zulässigen Ausnahmen für Übersetzungen. Aber diese sind international geregelt, und zwar in jedem Staat von der jeweiligen Regierung, in DE beispielswaise vom Standiger Aussschuss für internationale Namen (STAGN), in Zusammenarbeit mit den jeweilig anderen Ausschüssen der Partner-Staaten. Der StAGN befasst sich im wesentlichen mit den deutschen Exonymen für ausländische geografische Namen. Das mit den Staaten und ihre Hauptstädten hast du wohl missverstanden. Zitat aus einer Stellungnahme des StAGN zum Gebrauch von deutschsprachigen Exonymen [1]: In Deutschland gibt es keine gesetzlich verbindliche Regelung, durch die bei nichtamtlichem, privatem Gebrauch die Schreibweise oder Verwendung von ausländischen geographischen Namen vorgeschrieben oder verboten wird. Im amtlichen Bereich betrifft das lediglich die Schreibweisen der Staatennamen, Hauptstädte und Dienstorte deutscher Auslandsvertretungen, die vom Auswärtigen Amt festgelegt werden. Namen von Staaten und deren Hauptstädten sind sind also nicht die einzigen Ausnahmenen, die der StAGN zulässt, sondern die beiden Fälle, für die die Festlegungen des StAGN im amtlichen Bereich verbindlichen Charakter haben. Die Exonymlisten des StAGN enthalten darüber hinaus eine Fülle von deutschen Exonymen für Nicht-Hauptstädte (Lüttich, Genf,Nizza), Berge und Gebirge (Olymp, Vogesen) sowie Seen und Flüsse. Dass es international das Ziel gibt, den gebrauch von Exonymen zu reduzieren, ist unbestritten. OSM bildet aber die Wirklichkeit ab und ist nicht das Vehikel für angestrebte Änderungen. Und wenn da jeder in die name-Schlüssel hineinschreibt wozu er gerade Lust hat, wird es m.E. problematisch. Das halte ich für eine böswillige Unterstellung. Genau so wenig wie jeder den Verlauf des Rheins nicht so mappt, wie er gerade drauf ist, schreibt da nicht jeder rein, wozu er Lust hat. Gruß Rainer [1] http://141.74.33.52/stagn/Portals/0/110415_Allg%20Stellungnahme%20StAGN%20Exonyme%20neu.pdf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
Hallo, Am 27.08.2012 23:29, schrieb Felix Hartmann: Und ein Fußweg durch ein Gebäude, ist ein Fußweg, der existiert auch real! Real existiert da in der Regel kein Fußweg sondern eine begehbare Fläche. Fußwege in Gebäuden sind Hilfskonstruktionen für die Unterstützung von Routern, die nicht in der Lage sind, über Flächen zu routen. Das Thema ist für Plätze/Areas schon x mal durchgekaut worden. Es wäre aus meiner Sicht zielführender, Regeln für das Taggen der Zugänglichkeit von Gebäuden und Gebäudeteilen festzulegen (wenn es die nicht schon gibt?). Zum Beispiel: Gebäude mit foot=yes sind grundsätzlich für Fußgänger zugänglich. Wenn dann ein Gebäude zwei Eingänge hat, die mit dem Straßennetz verbunden sind, dann kann der Router durch das Gebäude routen. Wo sich die Zugänglichkeit auf einen Teilbereich des Gebäudes beschränkt, dann muss dieser eben erfasst werden, aber bitte keine Wege wo in der Realität eine große Eingangshalle ist. Was bei einem Platz noch angehen kann, wird bei einer Kirche mit Haupteingang und zwei Nebeneingängen ganz offensichtlich zum Mappen für den Router. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
Hallo, Am 23.08.2012 12:02, schrieb Felix Hartmann: Andere öffentliche Verkehrsmittel, haben wir schließlich auch verbunden mit dem Wege/Staßennetz (etwa Fähren, Autoverladung, Ubahnen, usw.). Was spricht dagegen, Seilbahnen genau so zu handhaben wie schienengebundene Bahnen, d.h. mit einer Plattform aerialway=platform, die mit dem Straßennetz verbunden ist? Dazu kommt noch, dass kaum eine Gondel direkt mit einer Piste verbunden ist, auch im Winter (Sessellifte dagegen schon), so dass man doch schon Wege in OSM haben sollte. Willst du die einzelnen Gondeln mappen? Ich vermute du meinst die Seilbahn, also die Trägermasten, das Kabel und die Berg- und Talstation. Frage ist daher, wie schaffen wir es Gondeln und Sessellifte so an das Wegenetz zu verbinden, das nicht wieder Vandalen dies löschen. Wenn es man mit aerialway=platform, dann stellt es sich für das Routing wie ein Bahnhof oder eine Straßenbahnhaltestelle dar. Und gegen Vandalen hilft nur Aufmerksamkeit. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3. Runde Wikimedia Community Projektbudget
Am 15.08.2012 22:53, schrieb ThomasB: Ich habe eine tolle Idee. [...] Kann mir einer den Rest übersetzen? Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Recyclingbehälter unterirdisch
Am 10.08.2012 09:56, schrieb Walter Nordmann: Wie werden die denn geleert? Kommt da die Metro? ;) So: http://www.youtube.com/watch?v=e_zX7u6v4UY ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Recyclingbehälter unterirdisch
Am 10.08.2012 01:13, schrieb Manuel Reimer: Foto davon hätte ich trotzdem noch gerne gesehen... Hier ein paar Beispiele: http://www.ladepeche.fr/content/photo/biz/2009/12/30/200912301182_zoom.jpg http://www.bourges-info.com/imagesweb/poubelle001.JPG http://actionbarbes.blogspirit.com/media/02/02/1433838552.JPG Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] N3 (Western Sahara) verschwindet beim Reinzoomen
Hallo, Am 08.08.2012 22:28, schrieb Dieter Jasper: Die Straße N3 wird ab Zoomlevel 13 nicht mehr angezeigt. Die wurde heute um 20:36 gelöscht [1]. Da die höheren Zoomlevel häufiger neu gerendert werden, ist sie dort schon nicht merh zu sehen, ab Level 13 sind die Tiles noch nicht auf dem aktuellen Stand. Gruß Rainer [1] http://www.openstreetmap.org/browse/way/175131740/history ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] N3 (Western Sahara) verschwindet beim Reinzoomen
Am 08.08.2012 22:51, schrieb Dieter Jasper: aber warum kann keine Daten der N3 mit JOSM laden. Weil der Nutzer meppen7 (ich vermute, dass du das bist) diesen Weg gelöscht hat. Er existiert in den Daten nicht mehr. Der Renderer hinkt je nach Zoomlevel mehr oder weniger hinterher. Dadurch kommt es dazu, dass die Strasse in manchen Leveln noch angezeigt wird, in anderen schon nicht mehr. Mit dem Redaction Bot hat das übrigens nichts zu tun Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
On 26.07.2012 15:17, Stefan Keller wrote: Peter Wendorff schrieb u.a. - Ein Bildstock wird neu erstellt (jemand löscht und erzeugt neu): Du erkennst die Löschung und musst nachgucken, kannst aber gleichzeitig relativ leicht verifizieren, ob der neu erstellte node vielleicht der adäquate Ersatz ist. - Die Tags eines bildstocks ändern sich, dabei geht das bildstock-tag verloren: Du erkennst das, hast aber immer noch die ID und den Ausschnitt, die passen - aber prüfen musst du sowieso. Bei diesen beiden Punkten versagt die OSM-ID Ich vermute, wir reden aneinander vorbei oder ich stehe total auf dem Schlauch. Zum ersten Punkt: - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese ID gespeichert - Jemand löscht diesen Bildstock - Die Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen und stellt fest, dass dieses nicht mehr existiert Wo ist hier das Problem? Zum zweiten Punkt: - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese ID gespeichert - Jemand löscht das Bildstock-Tag dieses Objekts - Die Bildstockanwendung greift auf das Objekt mit der OSM-ID ID1 zu und stellt fest, dass das Bildstock-Tag weg ist Wo ist hier das Problem? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
On 26.07.2012 18:18, Stefan Keller wrote: Zum ersten Punkt: - Es existiert ein Bildstock mit OSM-ID ID1. In der Bildstockdatei wird diese ID gespeichert - Jemand löscht diesen Bildstock - Die Bildstockanwendung will auf das Objekt mit der OSM-ID ID1 zugreifen und stellt fest, dass dieses nicht mehr existiert Wo ist hier das Problem? Angenommen es handelt sich eigentlich um dasselbe Objekt, und das Objekt wird nicht mehr am derselben Ort erstellt, dann ist die Chance gross, dass man es verliert. Ich habe oben einige solche Situationen zusammengetragen. Sagen wir, es wurde nur um 10m verschoben, aber innerhalb von 10m gibt es noch weitere neue Objekte: Welches ist es nun? Erst mal: wenn das Objekt im Editor mit der Maus um 10m verschoben wird, dann ändert sich die OSM-ID nicht. Nur wenn man ein Objekt als Kopie eines anderen Objekts anlegt, wird eine neue OSM-ID vergeben. Bei Josm ist übrigens Löschen + Einfügen gar nicht möglich, sondern man muss kopieren, einfügen und das Original löschen. Ich frage mich wer so einen Aufwand wegen einer Verschiebung um 10m treibt und warum. Aber sei's drum, jeder nach seiner Façon. Mit einer Projekt-ID/UUID muss man nichts tun. Doch. Ein Beispiel: Die Bildstöcke BS1 und BS2 liegen wenige Meter auseinander, sind aber etwa 10m von ihrer tatsächliche Position P1 bzw. P2 entfernt gemappt. Auch die relative Position der beiden Objekte zueinander ist nicht korrekt, BS1 ist näher an P2 gemappt als an P1. Ein Mapper stellt die ungenaue Positionierung fest und zieht Bildstock 1 nach P2 Bildstock 2 nach P1. Woher soll der Mapper denn wissen, welcher der ungenau positionierten Bildstöcke auf welcher Position steht. Und schon wird ein falsches Foto angezeigt. Ich habe übrigens nichts gegen UUIDS, man sollte sich nur davor hüten zu glauben, man würde es damit der hier diskutierten Anwendung einfacher machen. Man wird nicht umhin kommen, bei jeder Änderung der Position nachzuschauen und ggf. die DB manuell nachzuziehen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
On 26.07.2012 23:23, Stefan Keller wrote: Am 26. Juli 2012 18:57 schrieb Peter Wendorffwendo...@uni-paderborn.de: Vorausgesetzt, die PID/UUID wird mit kopiert Das stimmt. Dabei sind wir uns aber wohl aber einig, dass der Normalfall für den einfachen Mapper. Das mag der Normalfall sein, aber das Konzept muss auch alle anderen Fälle abdecken. Wenn der Editor vom Normalfall ausgeht und die UUID immer ungefragt mitkopiert, dann hat man ein Problem, wenn der Mapper doch mal nicht den Normalfall meint. Bis jetzt gibt es keinen in sich schlüssigen und vollständigen Vorschlag für eine Permanent-ID-Lösung, der weitestgehend ohne manuellen Eingriff des Mappers funktionieren würde. In allen nachfolgenden Fällen ist der Editor auf einen Entscheidung des Bedieners angewiesen: - Ausschneiden und Einfügen. Ist das einfügte Objekt identisch mit dem gelöschten oder ist es ein anderes, neues Objekt? - Ausschneiden und mehrmals Einfügen. Welches der eingefügten Objekte ist das verschobene Originalobjekt? - Kopieren und Einfügen, Löschen des Originals. Im Moment des Einfügens weiß der Editor noch nichts von dem späteren Löschen. Soll er die ID kopieren? Wenn ja, was passiert, wenn dann doch nicht gelöscht wird? Ein Konflikt beim Hochladen? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
On 25.07.2012 12:32, Manuel Reimer wrote: Peter Wendorff wrote: Wo ist jetzt deine Lücke in dem Konzept? Dass immer noch manuell kontrolliert werden muss? Das löst du mit deiner UUID auch nicht. Alle diese Probleme entfallen, wenn ich annehme, dass die UUID von Mappern nicht verändert/angefasst wird. Lies doch bitte den Beitrag von Peter nochmal. Er hat nicht *Probleme* aufgelistet sondern *Lösungen* für realistische Use Cases. Und die Frage war, was fehlt dir noch, wenn du diese *Lösungen* anwendest. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
On 23.07.2012 14:22, Stefan Keller wrote: Er muss tatsächlich möglichst wenig von IDs mitbekommen. Nur eines kann und muss er wissen: Ändern ist nicht dasselbe wie Löschen und wieder einfügen! Wenn jemand in einer Adresskartei einen Kundennamen ändert, dann löscht er auch nicht den ganzen Kunden um ihn gleich nochmals komplett neu zu erfassen. Der Vergleich mit einer Kundendatenbank hinkt. Gibt es keine Referenz per interner ID von und zu einem Kundensatz, dann kann dieser problemlos gelöscht und neu angelegt werden. Wenn aber die Kundendaten über eine interne ID noch mit Bestelldaten verknüpft sind, dann kann der Kundendatensatz nicht gelöscht werden. Vergleichbares ist bei den hier diskutierten Beispielen in OSM nicht möglich, da die Verknüpfung in der externen Anwendungsdatenbank realisiert ist. Der Mapper soll nun natürlich gemäss seiner Wahrnehmung der Realität entscheiden, was nun mit den Bänken geschehen sein könnte: Entscheidet er sich dafür, dass sie verschoben wurden, soll er das mit den vier Bänken tun (unter Beibehaltung der Projekt-ID bei der einen). Meint er, das seien vier brandneue, löscht er die vier (inkl. Projekt-ID) und erfasst vier neue (ohne Projekt-ID). Das Schlafbank-Projekt kriegt ja beides mit und muss reagieren. Nein, der gemeine Mapper nimmt die alten Bänke, verschiebt sie, ändert deren OSM-Tags und fasst deine Projekt-ID dabei nicht an. Er tut OSM damit was Gutes, weil er 4 OSM-IDs spart. Oder er macht sich Gedanken über diese Projekt-ID, verliert Zeit mit der Suche nach deren Bedeutung und dem Umgang mit ihr, ist verunsichert und lässt alles beim Alten, schliesslich will er ja nichts kaputt machen. Beides ist sicher nicht im Sinne des Schlafbankprojekts. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Am Sunday 22 July 2012 schrieb Tobias Knerr: Am 22.07.2012 21:34, schrieb aighes: Deutlich besser: Mach eine Liste draus, zerhacke sie in sinnvolle Paketgrößen und pack sie auf eine Wiki-Seite. Wie bei anderen ähnlichen Aktionen üblich. Würde ich auch besser finden. Ich halte solche Listen zwar grundsätzlich schon für hilfreich, aber habe jetzt natürlich keine Ahnung, ob schon jemand Einträge darauf abgearbeitet hat, und wenn ja welche. Sollte nächstes Mal besser wie eine der älteren Aktionen im Wiki aufgezogen werden: http://wiki.openstreetmap.org/wiki/Aktionen Und dann _eine_ Mail mit Link auf die entsprechende Wikiseite schicken. Die Wiki-Seite aufsetzen schaffe ich vermutlich nicht alleine, gibt es Freiwillige die den Teil übernehmen können und wollen? Danke und Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
/browse/way/56220631 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/58672257 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/66843876 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/67522818 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/70237522 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/72645365 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/85465123 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/91548383 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/120569054 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/127349569 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/133561522 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/135420931 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/136868271 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/147372065 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/147472550 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/147472556 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/156487748 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/158417479 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/158417480 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/160040522 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/160347932 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/161634453 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/164814408 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/165381451 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/165381452 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/165381453 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/169681060 Broken polygon, less than 3 points defined Thanks, Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am Sunday 22 July 2012 schrieb Jörg Frings-Fürst: Am Sonntag, den 22.07.2012, 12:27 +0200 schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris Hi, ist doch eigentlich egal. Bei den ersten beiden wurde doch beim letzten Edit von bigboss die from - rules entfernt, weil er den Weg gelöscht hat. Oder tarnt sich so jetzt der Redaction-Bot?? ;-)) Hallo, die Daten habe ich von http://download.geofabrik.de/osm/europe/germany/baden-wuerttemberg.osm.bz2 heute morgen gezogen. Bin nicht sich, wann der Bot lief/läuft. Danke und Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Warnungen beim Erzeugen einer Navit Karte (Bayern)
than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/120756966 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/124990790 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/154088688 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/169871770 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/171215530 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/171428242 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/172177634 Broken polygon, area is 0 Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)
Hallo, hier die Warnungen für die Österreich: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/92427 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/223509 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/241646 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278859 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278860 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278862 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/302959 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/311734 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/535236 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1318143 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1476938 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1485409 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1492801 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1506472 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1527515 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1683246 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696176 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696177 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1733647 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1779147 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1790945 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1857345 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1866773 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/2090704 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2130728 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1389144 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/1389152 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2102804 turn restriction: to member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2182619 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/34495781 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/44840922 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/51852521 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/72765511 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/101693601 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/116909398 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/123449371 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/151237729 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/162979331 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/165962199 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/169695178 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/171490446 Broken polygon, less than 3 points defined -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Hallo, hier die Warnungen für die Schweiz: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/169051 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/169052 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/169053 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/410435 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/043 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300520 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300522 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300523 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300524 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300525 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1342961 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1756112 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1832623 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082534 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082535 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2266273 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2296937 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1853786 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2019001 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/38696067 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/50759439 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/50760438 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/159742530 Broken polygon, less than 3 points defined -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdor...@web.de jabber: rdor...@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Am Sunday 22 July 2012 schrieb Jochen Topf: Könnt ihr das bitte mal sein lassen, diese Fehler alle hier zu posten. Die allermeisten Leute auf dieser Liste interessiert das nicht die Bohne. Wenns sein muss, macht halt ne Wiki-Seite oder findet sonst einen Platz dafür. Jochen, entschuldige, aber kein Grund zur Sorge, ich habe keine weiteren Daten mehr :-) Da einige Leute Interesse an den Daten gezeigt haben, werde ich sie wenn immer ich welche habe (erwarte etwa alle 2 Monate im Schnitt) zur Verfügung stellen. Ich werde eine Summary-Mail mit Links schicken, anstelle von den Einzelmails. Viele Grüße Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Am 22.07.2012 20:50, schrieb Joerg Fischer: Bernd Wurst wrote: Ist halt die Frage des Anspruchs. Klar, viele Attribute, Oberflächenbeschreibungen und so sind super. Werden aber momentan nicht wirklich irgendwo benutzt. Schau mal in die Stylefiles der MTBMap oder der Velomap... Und wer noch alles diese Daten benutzt hat wissen wir gar nicht. Natürlich hast Du Recht, rudimentäres Routing ist auch ohne surface=asphalt usw. drin. Ack aktualisiert nutzt dann in ein paar Tagen wieder den korrigierten Bestand. Den Optimismus teile ich nicht. IMHO werden es wohl eher Monate werden. Die, die den Götz von Berlichingen machen und nie wieder aktiv werden weil sie mit diesem Umgang mit der Arbeit, die sie in ihrer Freizeit leisteten, nicht einverstanden sind, noch gar nicht mitgerechnet. Den Götz mache ich gar nicht. Aber in der Zeit, als hier in der Gegend OSM im wesentlichen aus ein paar (oft fehlerhaften) Durchgangsstraßen und Autobahnen bestand, habe ich etliche Tankfüllungen vergurkt, mich in Schneewehen festgefahren und manches mal geschwitzt, daß mich keiner anmoppert, weil ich auch mal diverse Zufahrtsbeschränkungen ignoriert habe. Hatte ja ein Anliegen :-) Das tue ich mir nicht nochmal von vorne an. -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Am 20.07.2012 08:20, schrieb Peter Wendorff: Tool X oder Y sagen, da gibt's 'nen Fehler F - ALSO geh ich da mal hin, Ich habe jetzt gelernt, daß man im JOSM nach dem 'user:OSMF Redaction Account' suchen kann, wnen ich in meinen Bereichen Änderungen durch den Botlauf finden will. Nu bin ich aber Gelegenheitsmapper und benutze Potlatch. Welche Hilfen gibt es, mit Potlatch die durch den Bot gelöschten oder geänderten Wege und Nodes zu finden? -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Off. Re: Zurueck in die Steinzeit
Am 20.07.2012 10:27, schrieb Michael Kugelmann: Am 20.07.2012 09:09, schrieb Rainer Knaepper: Welche Hilfen gibt es, mit Potlatch einen sinnvollen Editor wie JOSM nutzen? ;-) Sorry, das musste jetzt sein, ;-) Michael. (Mitglied der Interessengemeinschaft ban Potlatch ;-) Tjo, wenn man Gelegenheitsmapper so hängen läßt, müssen die Profis eben alles alleine machen. Btw: JOSM ist so schon ein Beispiel traurigster Benutzerführung, auf meinem netbook völlig unbedienbar. Aber was soll's. Dann eben /keine/ systematische Suche meinerseits. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Off. Re: Zurueck in die Steinzeit
Am 20.07.2012 16:57, schrieb Simon Poole: Mir ist zwar nicht klar wieso jetzt gerade Editor Wars anfangen, Ich habe keinen Editorenkrieg angefangen, sondern nach (Such-)Hilfen für Potlatch-Benutzer gefragt. Ist das schon ein derartig rotes Tuch? Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Off. Re: Zurueck in die Steinzeit
Am 20.07.2012 19:27, schrieb fly: Also Performance mäßig erkenne ich da bei JOSM keinen Nachteil. Java und Flash nehmen sich da nicht viel. Jupp, flash ist auf dem Atom auch lahm, aber das ist für kleine/spontane Änderungen unterwegs nicht das Problem. Geht halt langsam. Erst recht, wenn man mal wieder kein UMTS hat. Wenn es Probleme mit der Auflösung bzw dem Orientieren ind der GUI gibt Ja. Als ich das vor längerer Zeit ausprobierte, waren irgendwelche aufklappbaren Listen schlicht nicht erreichbar. Am unteren Ende. Sind halt nur 600px vertikale Auflösung. Hab JOSM seitdem aber gar nicht mehr benutzt, ob das heute besser oder schlechter ist, kann ich überhaupt nicht beurteilen. füll doch bitte ein Ticket im JOSM-Trac aus. Ich weiß, daß das der möglicherweise zielführende Weg wäre, aber bei mir reicht das Engagement (und Zeit und Resourcen), um solche Dinge ernsthaft zu verfolgen, nicht aus. Sorry. War ja auch nur eine Nachfrage, mit meinen beschränkten Fähigkeiten besser helfen zu können; wenn das nicht geht, dann eben nicht. Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] QA-Software
On 18.07.2012 08:34, Jan Tappenbeck wrote: deshalb hatte ich ja nachgefragt schon ob einer die Tools von Gary68 auf einer Linux-Umgebung mal eben wieder aktivieren kann. Wenn man Osmose [1], KeepRight [2] und den OsmInspector [3] nutzt, wofür braucht man dann noch ein weiteres Tool? Das kann eigentlich nur zum Aufdecken von exotischen Fehler im Zusammenhang mit deinen speziellen Mappingthemen sein. Ich befürchte, dafür musst du dir selbst was schreiben. Die Tools von Gary68 sind in Perl geschrieben, die bekommt man auch unter Windows zum Laufen, mit Cygwin oder ActivePerl. Gruß Rainer [1] http://osmose.openstreetmap.fr/map/ [2] http://keepright.ipax.at [3] http://tools.geofabrik.de/osmi/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Straßen einer Stadt ermitteln ...
Hallo, On 16.07.2012 21:42, Frederik Ramm wrote: http://help.openstreetmap.org/questions/2980/how-do-i-list-all-the-streets-in-a-city-with-nominatim Ähnlich arbeiten die Tools des Users Geo-francis [1]. Dort ist auch beschrieben, wie man die Polygon-Datei für osmosis aus der Gemeidegrenzrelation erstellen kann. Gruß Rainer [1] http://wiki.openstreetmap.org/wiki/User:Geo-francis ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
