Re: [Talk-de] Alle Jahre wieder ...
Am 15.11.2012 09:32, schrieb Wolfgang Hinsch: Am Mittwoch, den 14.11.2012, 23:34 +0100 schrieb Henning Scholland: Hallo, also jemand der xmas-Tags auswertet sollte sich schon bewusst sein, dass das ein begrenztes Vergnügen ist. Da braucht es nicht unbedingt eine zeitliche Eingrenzung. Genauso wie wir bei den Ski-Pisten sowas auch nicht erfassen und highway=* im Winter auch nicht raus nehmen, wenn sie komplett zu geschneit sind. Anders sieht es aus, wenn man Objekte erfasst, die typischerweise ganzjährig nutzbar sind, aber im konkreten Fall nur kurzzeitig existieren. Für xmas hast du sicher Recht. Aber es gibt ja auch andere Ereignisse wie z.B. Jahrmarkt, Wochenmarkt etc, die immer zu einem bestimmten Termin am selben Ort stattfinden. Wie gesagt, wenn man Objekte, die nur kurzzeitig verfügbar sind, in der Regel aber von dauerhafter Natur sind, dann sollte das mit speziellen Taggs eingeschränkt werden. Für highway könnte ich mir durchaus vorstellen, z.B. die Wintersperre der Alpenpässe aufzunehmen. Etabliert ist glaub ich nur, dass man erfasst, dass es im Winter gesperrt ist. Der genaue Zeitpunkt hängt ja auch davon ab, wie das Wetter ist. Es hat aber kaum einen Mehrwert, an jedem highway=* zu erfassen, dass es im Winter, bei Überflutung, etc. Einschränkungen gibt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingprobleme
Hallo Falk, bei den beiden turn-restrictions only_straight_on waren jeweils die to-Member falsch gesetzt. Hab ich soeben behoben. Viele Grüße Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sammelbehälterfür Altbatterien und abgelaufene Arzneimittel
Wenn man so spitzfindig sein möchte, dann gehört das mit Sicherheit nicht in den Haupttag. Dieser beschreibt allgemein einen Ort, wo man bestimmten Müll hinbringt. Ob die jetzt das Papier recyceln oder verbrennen ist für den Sammelbehälter egal. Bspw. kann es bei den Medikamenten auch gut sein, dass die Alu-Tube wieder verwertet wird. Ebenso die Hustensaftflasche. Auch die Verpackung von den Tabletten wird mit Sicherheit wieder verwertet. Wo will man da jetzt die Grenze ziehen? Ich kann mir gut vorstellen, dass der weitere Weg des Mülls interessant sein kann. Aber bitte nicht dafür unterschiedliche Haupttags verwenden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingprobleme
Am 07.11.2012 12:58, schrieb Chris66: Hi, Leider war es (auf die schnelle) in der Darstellung von JOSM nicht zu erkennen, die Pfeile haben vorher und nachher in die Richtige Richtung gezeigt. Ist mir auch schon aufgefallen. Der Renderer schaut nach der Richtung des from-ways und malt dann in diese Blickrichtung das Symbol, dass man mit restriction=* getaggt hat. Klar wird es erst, wenn man die Relation auswählt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Sandbox
Am 04.10.2012 11:51, schrieb Manfred A. Reiter: Allerdings wird das, was man da hinmalt, nirgends gerendert. hm ... dann können sie also nicht sehen, welchen Mist sie gerade gebastelt haben Muss ich drüber nachdenken ... Das wirst du bei jeder Sandboxlösung haben. Und ganz allgemein: Woher soll denn der Sandbox-Nutzer wissen, ob er Unsinn gebaut hat oder nicht? Wenn das Resultat dann in Mapnik hübsch aussieht, sagt das ja noch nichts darüber aus, ob alles ok ist. Als Stichworte: Routenrelationen zerschießen, falsches Tagging allgemein, nicht verbundene Wege. Eine erste Sandbox ist ja schonmal josm. Da kann man sich das Ergebnis seiner Arbeit anschauen. Je nach Einstellungen sieht mehr oder weniger hübsch aus und der Validator sagt einem, was falsch sein könnte. Ob die Einschätzung des neuen Mappers nun gut war (hochladen) oder schlecht (weiter testen), sieht er aber nur, wenn er Mecker von anderen bekommt, wenn er Unsinn gebaut hat. Das ist aber bei jeder Sandboxlösung so. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderungen rückgänig machen
Bspw: http://wiki.openstreetmap.org/wiki/Revert Oder einfach das Changeset verlinken und es andere machen lassen. Auf jeden Fall aber den Verursacher ansprechen und ihm sagen, dass er etwas falsch gemacht hat und wie man es richtig macht. Beim Revert aber drauf achten, dass alle guten Änderungen erhalten bleiben. Ebenso sollte man einfach nur so reverten nur machen, wenn es sich um einen offensichtlichen Fehler handelt. Beispielsweise nur weil du der Meinung bist, dass ein Kreisverkehr ein geschlossener Weg sein muss und jemand anders das anders sieht, ist das noch kein Grund für einen revert ohne, dass man mit dem anderen User bzw. der Community den Fall ausdiskutiert hat. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus, wie Änderungen ansehen?
Hallo, bspw. mit http://zverik.osm.rambler.ru/whodidit/?lat=47.8717lon=10.60084zoom=16layers=BTTage=187 kannst du dir deine Gegend anschauen. Am 28.8. war der zweite Redaction-Bot in deiner Gegend und hat sich um das Entfernen von vermeintlichem CopyPaste-Ramappings gekümmert. Viele Grüße Henning Am 02.10.2012 10:31, schrieb Benjamin Lebsanft: Hallo zusammen, gerade sind mir in meinem Heimatort fehlende Straßen aufgefallen, die nicht vom redaction bot gelöscht wurden, zumindest tauchen sie hier nicht auf: http://tools.geofabrik.de/osmi/?view=redactionbotlon=10.60098lat=47.87008zoom=16overlays=overview,bot_point_cleared,bot_point_superseded,bot_line_cleared,bot_line_superseded,bot_point_modified,bot_line_modified_cp,bot_line_modified,bot_point_deleted,bot_line_deleted_cp,bot_line_deleted Ich habe das jetzt soweit wie möglich wiederhergestellt, ich würde aber dennoch gerne wissen wer die gelöscht hat. Der Owl-Viewer geht ja nicht mehr, gibt es was vergleichbares? Danke Benni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder via OpenGeoServer.at
Hallo, wenn ich es als Laie richtig verstehe, ist der Vorteil für mich, dass ich automatisch das höchstauflösende Luftbild angezeigt bekomme und nicht hin und her schalten muss, richtig? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Etwas Ratlos -- taggen für den Renderer
Am 27.09.2012 12:35, schrieb Martin Koppenhoefer: ja, wenn man leisure=nature_reserve nicht mehr rendern würde, dann würde da das tagging sicherlich deutlich langsamer vonstatten gehen ;-) Ich denke nicht, dass Falk meinte, man solle keine Naturschutzgebiete rendern, sondern dass man halt nur noch über boundary=protected_area gehen sollte und leisure=nature_reserve als veraltet markieren sollte, bzw. einfach ignorieren sollte. Halte ich jedenfalls für eine sinnvolle Idee, da so der Anwender entscheiden kann, was dargestellt werden soll. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte, ODbL Daten
Das Problem ist, dass der deutsche Stil aus dem allgemeinen abgeleitet ist und dessen Lizenz unklar ist. Aus dessen Lizenz ergeben sich aber Anforderungen an die Lizenz der Tiles. Mal ein hypothetisches Beispiel: Der Stile dürfte nur nc genutzt werden, dann kann man schlecht die Tiles als PD deklarieren ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Am 26.09.2012 10:57, schrieb Sven Geggus: Michael Kugelmann michaelk_...@gmx.de wrote: Wäre es viel Arbeit einen Button hinzuzufügen Ich wäre gegen einen zusätzllichen Button. OK, ich seh schon wir brauchen ein greasemonkey-script. Wie wäre es mit einem URL-Parameter? Bspw. ein Permalink mit zusätzlichem dirty markiert den aktuellen Ausschnitt zum neurendern. Knopf fände ich auch eher schlecht. Das dürfte für viele Nutzer verwirrend sein. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Hallo Sven, freut mich zu hören. Darf ich dem Lizenzhinweis entnehmen, dass die Tiles auch ODbL sind? Viele Grüße Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte, ODbL Daten
Am 25.09.2012 23:24, schrieb Kolossos: Laut einem legal-talk Beitrag[1] würde folgende reichen: (c) OpenStreetMap contributors: license Stimmt das? Ja...wobei license ein Link auf osm.org/copyright sein muss oder direkt auf die ODbL und zusätzlich halt noch die Lizenz der Tiles und was dafür nötig ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update von nominatim.osm.org
Am 24.09.2012 12:06, schrieb Georg Feddern: Nur dem halte ich entgegen, dass das a) gar nicht immer möglich ist b) für das label nur die Koordinaten benötigt werden, also doch gar keine Tags am node nötig wären Würde ich auch denken. label soll ja nur für den Renderer anzeigen, wo er das Label am besten platzieren sollte, bzw. wo der Ortsmittelpunkt ist. Die anderen Infos stecken in der Admin-Relation drin. Es kann aber sein, dass der label-Node zusätzlich auch noch Tags hat, u.a. auch ein place. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotos von denkmalgeschützten Häuser verlinken?
Hallo Willi, also wenn jemand image=* taggt, dann erwarte ich dahinter egtl. ein Bild und keine Website. Von daher halte ich das für verwirrend und in der Auswertung problematisch. Das Eintragen des Links ist unproblematisch im juristischen Sinne. Nur was bringt das, wenn man den Link zum Bild nicht ruhigen Gewissens nutzen kann? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fotos von denkmalgeschützten Häuser verlinken?
Hallo, ich denke es gibt bessere Dienste, um ein Bild mit einer Koordinate zu verbinden. Henning Am 22.09.2012 14:41, schrieb Steffen Heinz: Würde es Sinn machen denkmalgeschützte Häuser auf ein Foto bei Wikipedia zu verlinken? Ich habe so gut wie alle in Simmerath fotografiert und die absolut meisten in Monschau, im Rahmen von Wiki Loves Monuments (war schon ein riesiger Aufwand), dürften so 250 bis 300 Bilder sein Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amtlicher BayernAtlas mit OSM-Layern
Am 20.09.2012 09:30, schrieb Manuel Reimer: Getreu dem Motto Etwas geht immer schief wurden unsere Daten vom 13.07.2012 unter ODbL attributiert, obwohl zu diesem Zeitpunkt unsere Lizenzumstellung noch nicht abgeschlossen war. Dieses kleine Missgeschick wird in Kürze behoben. Es handelt sich um eine Ausleitung von POIs. Rein technisch sollten die alle ODbL-Clean gewesen sein. Ne, weil die Daten sind noch vor der Zeit, als der Redaction-Bot los gerannt ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Am 19.09.2012 10:46, schrieb Jochen Topf: Diese Abstimmerei über ein Theoriegebäude bringt doch nix. +1 Der GUI ist es doch letztlich nahezu egal, was sie in die Tags schreibt und dem Auswerter ist es auch nahezu egal, was in dem Tag steht (es gibt ein paar Einschränkungen, wie konstante Keys). Egal wie simpel das Schema sein wird, es wird für die meisten Mapper zu kompliziert sein, als das sie es von Hand eintippen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Am 19.09.2012 11:41, schrieb Eckhart Wörner: Hallo aighes, Am Mittwoch, 19. September 2012, 11:28:37 schrieb aighes: Der GUI ist es doch letztlich nahezu egal, was sie in die Tags schreibt und dem Auswerter ist es auch nahezu egal, was in dem Tag steht (es gibt ein paar Einschränkungen, wie konstante Keys). Egal wie simpel das Schema sein wird, es wird für die meisten Mapper zu kompliziert sein, als das sie es von Hand eintippen. Das halte ich jetzt für eine nicht ganz zutreffende Verallgemeinerung. Ich glaube nicht, dass maxspeed:wet=80 zu kompliziert ist, um von Hand eingegeben zu werden. Es wird eher so sein, dass eine GUI das letzte ist, was kommt. Das war nicht speziell zu diesem Fall gemeint. Es ist eher allgemein so, dass ein Großteil der Mapper primär sich die Tags über die Presets zusammen klickt. Das manuelle Eintragen machen egtl. nur noch die Spezialisten/Pro's, die Sachen eintragen, die ungewöhnlich sind oder es einfach aus vergangen Zeiten gewohnt sind. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions
Am 19.09.2012 17:18, schrieb Martin Koppenhoefer: Am 19. September 2012 12:21 schrieb aighes o...@aighes.de: Das war nicht speziell zu diesem Fall gemeint. Es ist eher allgemein so, dass ein Großteil der Mapper primär sich die Tags über die Presets zusammen klickt. Das manuelle Eintragen machen egtl. nur noch die Spezialisten/Pro's, die Sachen eintragen, die ungewöhnlich sind oder es einfach aus vergangen Zeiten gewohnt sind. Ist das wirklich so? Geht doch viel schneller mit autocompletion die tags Freihand einzutragen. Ausserdem sind die presets doch nach wie vor unvollständig, oder hat sich da viel getan? Bisher fand ich immer, bis man sich durch die Menüebenen geklickt hat, hätte man schon 5 andere Objekte getaggt ;-) Du gehst davon aus, dass der Mapper auswendig weiß, wie man ein Objekt einträgt. Das trifft auf einen Großteil der Mapper nicht zu (vor allem die, die nicht hier bzw. im Forum aktiv sind). Ich arbeite auch bei bekannten Sachen mit autocomplete, weil schneller. Nur wir Pro's bilden eher nicht die Mehrheit der Mapper und wenn ich die Alternative /Preset nutzen /und /Wiki dursuchen/ hätte, würde ich wohl das Preset nehmen. Ich kann mit der Vermutung auch falsch liegen. Ich denke nur, dass man nicht davon ausgehen sollte, dass ein Anfänger solche Sachen eintippt, sodass ihm die Komplexität vollkommen egal ist. Er muss erkennen können, dass da ein conditional-Tag vorhanden ist und dann schaut er diesen im Editor entsprechend an. Henning ___ 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:58, schrieb Jochen Topf: Bei allen anderen Fällen, insbesondere auch den Großen Seen in Nordamerika, handelt es sich um Seen und die sollten auch so getagged werden. Allerdings finde ich das okay, wenn man erstmal mit diesen paar Ausnahmen lebt. Es wäre relativ viel Arbeit das sauber umzustellen und die Handhabung großer Relationen ist so mühsam und fehlerträchtig, dass es vielleicht besser ist, erstmal beim Bewährten zu bleiben. Das ist halt so eine Sache. Die Finnen haben da auch sehr zu kämpfen gehabt. Mit den resultierenden MP's kam kaum einer zurecht und kaputt waren die bei den großen Seen auch regelmäßig. Die haben dann die großen Seen auch in kleinere MPs aufgeteilt. Viel besser als über eine Küstenlinie ist das dann auch nicht. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten-Aushang
Achso: Dafür würde ich mir Maperitive näher ansehen und für die Nacharbeit dann inkscape. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten-Aushang
Am 17.09.2012 14:59, schrieb Bernd Wurst: Hallo. In meiner unmittelbaren Umgebung wurde schon vor vielen Jahren eine öffentlich einsehbare, topologische Karte an einer Bushaltestelle aufgehängt. Erst jetzt habe ich das mal genauer angesehen und es handelt sich meiner Einschätzung nach um eine um jeglichen eindeutigen Hinweis beschnittene Wanderkarte des Städte-Verlags. Vermutlich ist dieser Aushang also eigentlich gar nicht so erlaubt. Nun dachte ich, das könnte man doch einfach durch eine OSM-Karte ersetzen. Unabhängig vom Render-Stil (meine TileMill-Experimente waren ernüchternd. Tipps, anyone?) ist das doch jetzt nach der Lizenzumstellung so, dass eine gedruckte Karte im Prinzip gar keine verpflichtenden Lizenzhinweise erhalten muss? Als Werbung würde ich das gerne trotzdem aufdrucken, aber lizenzrechtliche Probleme kann man eigentlich nie bekommen, egal was man draufdruckt. Ist das richtig? Was drauf muss, ist der Hinweis, dass die Daten von OSM stammen und unter ODbL verfügbar sind. Das könnte dann so aussehen: Daten (c) OpenStreetMap Mitwirkende, verfügbar unter ODbL evtl. noch ergänzt um einen Link, evtl. auch als QR-Code. Zusätzlich könnt ihr die Karte an sich auch noch unter eine Lizenz stellen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF-Vorstand
Wie wäre es, wenn man dafür ein schwarzes Brett macht. Ich denke schon, dass es da draußen Mapper gibt, die dabei mitmachen würden (auch jenseits der ML). Nur müssen die eben auch wissen, dass dafür einer gesucht wird. Oder solche Stellenausschreibungen in den Blog bringen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinien
Am 16.09.2012 11:43, schrieb Oliver Raupach: Unterliegen diese Karten auch dem Verfahren mit dem Shapefile und der manuellen Sichtung? Oder sind von diesem Verfahren nur die offiziellen Karten betroffen? Nicht unbedingt. Wie Raumbezug das macht, kann ich dir nicht sagen. Es gibt beim Erstellen von Garminkarten zwei Möglichkeiten. Entweder man nimmt die Küstenlinien direkt aus den Daten, was fehleranfälliger ist, oder man nimmt ebenfalls vorberechnete Küstendaten. Die Karten, die mit den ODbL-Daten erstellt werden, dürften aber Küstendaten haben, die nicht älter als ein paar Tage sind, da es vorher noch keine ODbL-Küstenlinien gibt. Henning ___ 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 16.09.2012 17:55, schrieb Oliver Raupach: Am 16.09.2012 12:51, schrieb Jochen Topf: Ähm, schick. Aber demnach ist im Moment ja fast die ganze Welt etwas buggy (Invalid geometry). Kann man zu diesem Fehler mehr sagen? Die Beschreibung dieses Layers auf der Wiki-Seite sagt es eigentlich alles: Invalid geometry shows coastlines that are invalid for some reasons, for instance because there are self-intersections or so. This is somewhat of a catch-all, i.e. it is shown when we can't give a more specific error message. Fix all specific errors shown on some other layer on this coastline and this error should go away also. Für den amerikanischen Kontinent wird das der Fehler an der Küste Venezuelas sein, für Eurasafrika einer der Overlapping-Fehler, die angezeigt werden. Der invalid geometry-Check ist sehr strikt und zeigt auch Fehler, die nicht unbedingt dazu führen, dass die Daten nicht nutzbar sind. In diesem Fall ist das z.B. so, der Mapnik rendert die Kontinente brav trotz dieses Fehlers. (Aber das heisst natürlich nicht, dass jede Software damit zurecht kommt, daher ist es trotzdem sinnvoll diesen Fehler anzuzeigen.) Bedeutet das, das die gesamte Küstenlinie als Invalid geometry angezeigt wird, wenn nur ein einzelner Fehler dort vorhanden ist, der dann auch als overlapping Fehler extra angezeigt wird? Ich habe diesen Fehler mal gefixed: http://tools.geofabrik.de/osmi/?view=coastlinelon=-66.94621lat=10.60325zoom=15overlays=coastline,coastline_error_lines,line_not_a_ring,line_overlap,line_invalid,line_direction,coastline_error_points,unconnected,intersections,not_a_ring,double_node,tagged_node Hier fehlte an der Linie einfach das tag natural=coastline. Dazu noch eine Frage: müssen die Linien direkt miteinander verbunden sein (ist dort nicht der Fall)? Oder reicht es, wenn sie sich in einem Punkt treffen? Wenn du alle Küstenlinien zusammensetzen würdest, müsste ein geschlossenes Polygon rauskommen, deren Teilwege alle die gleiche Richtung haben. (*L*and ist *L*inks). Henning ___ 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 16.09.2012 22:28, schrieb Oliver Raupach: Am 16.09.2012 00:22, schrieb Jochen Topf: On Sun, Sep 16, 2012 at 12:03:37AM +0200, aighes wrote: vielen Dank für die Info. Hat es einen Grund, warum der Josm-Remote-Link nicht geht? Der geht schon. Wahrscheinlich musst Du nur weiter reinzoomen. In kleinen Zoom-Stufen macht es ja keinen Sinn, den zu benutzen, weil man von der API nicht so viele Daten auf einmal bekommt. Hat bei mir erst auch nicht funktioniert. Dann habe ich gemerkt, dass man im JOSM erst die Fernststeuerung aktivieren muß (Bearbeiten-Einstellungen-Fernsteuerung-Fernsteuerung aktivieren). Ne, daran liegts bei mir nicht. Der Routing-View geht ohne Probleme und wenn ich im Küstenlinien-View das ganze über den Potlatch-Knopf lädt er über den Umweg über osm.org auch ins josm rein. Nur der direkte Weg geht nicht. Henning ___ 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 16.09.2012 23:21, schrieb Jochen Topf: On Sun, Sep 16, 2012 at 12:51:56PM +0200, Jochen Topf wrote: Für den amerikanischen Kontinent wird das der Fehler an der Küste Venezuelas sein, für Eurasafrika einer der Overlapping-Fehler, die angezeigt werden. Da muss ich mich selbst korrigieren. Nachdem fleissige Hände alle (!) Fehler korrigiert haben, die der OSMI anzeigt, waren die Kontinente immernoch invalid. Bin dem nachgegangen und der Grund waren zwei Inseln innerhalb von Wasserflächen innerhalb der Kontinente, die falschrum eingetragen waren und dadurch zu Löchern innerhalb von Löchern innerhalb der Land-Polygone wurden. Das geht halt nicht und daher die Meldung als invalid. Dieser spezielle Fehler wurde aber nicht an den OSMI weitergegeben. Solche Fehler sind relativ selten, weil es nur wenige Wasserflächen innerhalb der Kontinente gibt, die als Küstenlinie getagged sind (üblicherweise tagged man sowas als See). Das wird aus historischen Gründen nur für einige sehr grosse Seen gemacht. Ich habe diese beiden Fälle in den Daten jetzt gefixt und nach dem nächsten Update sollte dann alles okay sein. Ich muss mal schauen, ob ich das in den Code irgendwie einbauen kann. Wäre schön, wenn du da was coden könntest. coastlines innerhalb von Binnenwasserflächen kommt immer mal wieder als Fehler vor. Henning ___ 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
Hallo, vielen Dank für die Info. Hat es einen Grund, warum der Josm-Remote-Link nicht geht? Viele Grüße Henning Am 15.09.2012 23:52, schrieb Jochen Topf: Ich habe openstreetmapdata.com auf den aktuellen Stand gebracht. Dort findet Ihr jetzt die aktuellen Küstenlinien und Land- und Wasser-Polygone, die aus den ODbL-Daten generiert wurden als Shapefiles zum Download. Ab sofort werden diese Daten wieder täglich aktualisiert. Diese Daten wurden mit dem Programm OSMCoastline generiert (das ist Open Source und Ihr könnt es auch selbst laufen lassen, siehe http://wiki.openstreetmap.org/wiki/OSMCoastline). Die Daten können als Ersatz für die processed_p-Shapefiles verwendet werden, die man üblicherweise braucht, wenn man mit Mapnik Tiles rendert. Um beim Finden und Korrigieren von Fehlern in der Küstenlinie zu helfen, haben wir dem Geofabrik OSM Inspector einen neuen View spendiert: http://tools.geofabrik.de/osmi/?view=coastline . Eine detaillierte Beschreibung dieses Views mit Tipps, wie man die Küstenlinien korrigiert, gibts im Wiki unter http://wiki.openstreetmap.org/wiki/OSM_Inspector/Views/Coastline . Dieser View wird ebenfalls täglich aktualisiert (und nutzt dazu auch die Ausgabe von OSMCoastline). Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF-Vorstand
Am 14.09.2012 09:09, schrieb Michael Kugelmann: Ist auch meine Meinung: de OSMF braucht m.E. deutlich mehr Mitglieder so dass sie die Community besser wiederspiegelt. Wie man dies erreicht, z.B. über Lokal Chapter welche auch stimmberechtigt sind oder wie auch immer, das sei mal dahingestellt, dafür habe ich auch keine Patentlösung. BTW: dadurch kann man auch Gefahren, welche von manchen Personen in der Vergangenheit an die Wand gemalt wurden (Firma XYZ übernimmt die OSMF und damit das Projekt) auch wirksam begegnen: 160 Mitglieder kann man mal auf die Beine bringen, ein paar tausend Strohmänner geht schlichtweg nicht. Dafür braucht es halt Wissen in der Community, was einem so eine Mitgliedschaft bringt. Worüber kann ich mitbestimmen? Dazu wären sowohl ehrliche Berichte von Mitgliedern sinnvoll, als auch interne Pressemeldungen der OSMF sehr sinnvoll. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorteile OSMF-Mitgliedschaft
Hallo, genau das ist doch der Punkt. So denkt ein durchschnittlicher Mapper: Ich habe keinerlei Bonus. Das Board zu wählen ist auch nicht gerade wichtig. Was macht denn das Board schon? Den Beitrag als Spende sehen: Schön und gut, aber dann kann ich auch direkt Spenden und zwar einen Betrag, den ich mir aussuchen kann. Von dem Like-Button hab ich ja auch nur was, wenn andere sehen, dass ich ihn gedrückt habe. Ich denke den SOTM eintritt kann man bei den meisten auch in den Skat drücken. Es ist halt schwer für einen Verein Mitgleider zu sammeln, wenn er seine Aufgabe darin sieht sich im Hintergrund zu halten. Letzteres ist so gewollt und auch in Ordnung. Nur bedeutet das gleichzeitig eben auch, dass ich nicht Mitglied sein muss um über das für den Mapper wesentliche zu entscheiden. Viele Grüße, Henning Am 14.09.2012 10:34, schrieb Falk Zscheile: Am 14. September 2012 10:05 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: aighes osm at aighes.de writes: Dafür braucht es halt Wissen in der Community, was einem so eine Mitgliedschaft bringt. Worüber kann ich mitbestimmen? Genau das ist die Frage aller Fragen. Ich denke das Mitentscheiden sollte nicht das ausschlaggebende Kriterium sein, um beizutreten. Die Einflussmöglichkeiten der OSMF wird sich gegenüber der Community immer in grenzen halten (müssen), da ein Projekt wie OSM mit Regeln von oben grundsätzlich Probleme hat. Zudem ist Mitentscheiden, ob in der OSMF oder nur auf einer Mailingliste immer mit Zeitaufwand verbunden. Man muss sich durchlesen, was andere wollen, sich eine eigene Meinung bilden, diese auch vertreten, versuchen sie argumentativ durchzusetzen und nach Kompromissen suchen. Wem das hier auf der Liste Spaß macht, der hat daran sicher auch in einem Verein Spaß. Alle anderen sollten sich nach einem anderen Grund für einen Beitritt umsehen. Eine Mitgliedschaft ist nicht teuer und da OSM mehr oder weniger eines meiner Hobbies ist, tendiere ich dazu, auch beizutreten. So halte ich es bei meinen anderen Hobbys auch. Meist unterstütze ich sie durch einen Vereinsbeitritt. Frage ist aber: Was habe ich davon? Was bekomme ich, was ich ohne Mitgliedschaft nicht habe? Ist alles, was ich bei Zahlung bekomme, eine knappe E-Mail, die mich als OSMF-Mitglied begrüßt? Wie oben bereits dargelegt, sehe ich die Mitbestimmung (häufig eh klein-klein) nicht als vordergründige Motivation an, einem Verein beizutreten. Für mich ist es eher ein kostenpflichtiger Like Button. Was bekomme ich nun (bestenfalls) dafür? Leute, die sich in ihrer Freizeit nicht nur dem Mappen widmen, sondern sich um sonstigen Krimskrams kümmern -- Außendarstellung, Kontaktpflege, Serverbetrieb und Verwaltung von Spendengeldern. Die Spendengelder wollen dann auch wieder sinnvoll angelegt sein. Habe ich in einem so großen Projekt den Überblick und die Geldmittel, um etwas direkt zu fördern? Nein! Schön, dass es da jemanden gibt, der das Organisiert und sich damit auseinandersetzt, ob einer Förderung lohnt und sich die ganzen Diskussionen antut. Bei OSM kommt als Unterschied zu vielen anderen Vereinen aber hinzu, dass hier schon die Meisten durch die Erfassung von Geodaten beitragen und sich natürlich berechtigterweise die Frage stellen, warum sie dann auch noch für die Sache Geld ausgeben sollen, die sie schon durch ihre Mitarbeit fördern ... Vielleicht aus einem der oben genannten Gründe. Möglicherweise spielt es auch eine Rolle, das es an einem echten local chapter für Deutschland fehlt. Einen deutschen Verein kennt jeder aus (mehr oder weniger guter) Erfahrung und weiß worauf er sich einlässt. Aber bei einer Foundation nach englischen Recht? Und auch nicht jeder kann oder möchte auf englisch in einer Vereinigung mitwirken ... Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit Linie mit Flächenzeichenstil nicht geschlossen
Hallo Am 08.09.2012 23:14, schrieb Andreas Schmidt: Wie finde ich heraus, ob der Name Herrschaft gelöscht werden darf? In dem du dir lokales Wissen aneignest und darüber zu dem Schluss kommst, dass das Waldstück nicht diesen Namen hat, oder in dem du mit dem Vorbearbeiter sprichst, der den name vergeben hat und ihn fragst, ob das wirklich der Name ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News report license switch done
Hallo Stephan, noch ist alles CC, steht auch bereits in einem Kommentar zum Artikel. Henning Am 08.09.2012 18:22, schrieb Stephan Knauss: Hi, german IT newsticker heise online did report that we finally switched the license to ODbL. They said it was announced during SOTM. Is this right? http://www.heise.de/newsticker/meldung/OpenStreetMap-schliesst-Lizenzwechsel-ab-1703197.html If so, I'm quite disappointed that the community was not informed first... If this is a false announcement, the OSMF might want to have that corrected. Stephan Bei Heise Online wird berichtet, dass der Lizenzwechsel auf ODbL abgeschlossen ist. Wäre auf der SOTM verkündet worden. Ist das so? Enttäuschend, dass die Community das aus den Nachrichten erfahren muss. Falls nicht will vielleicht jemand von der OSMF Heise über ihren Fehler aufklären und um Richtigstellung bitten. http://www.heise.de/newsticker/meldung/OpenStreetMap-schliesst-Lizenzwechsel-ab-1703197.html Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenzen und Adminlevel
Hallo Ich sehe das mal aus den Augen eines Laien auf dem Verwaltungsgebiet. Das System ist hierarchisch aufgebaut. Will eine Gemeinde admin_level=7 haben, sollte es andere Gemeinden mit level=8 unter sich haben. Den Rest (wer hat welche Macht) kann man meiner Meinung nach auf einer so groben Skala kaum abbilden. Reicht es dafür nicht aus, die ganzen Schlüssel zu interpretieren? Für den Laien (der mit den Daten arbeiten muss/will) ist es jedenfalls deutlich einfacher zu verstehen, wenn eine einzelne Gemeinde level=8 bekommt und ein Zusammenschluss aus mehreren Gemeinden level=7 Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezifische Radweg-Karte für Garmin?
Am 05.09.2012 11:10, schrieb Sven Geggus: malenki o...@malenki.ch wrote: Nicht jeder hat auf einer zünftigen Radreise Laptop und Notstromaggregat dabei. ;) Pah schon alleine um die Trackaufzeichnungen zu sichern hab ich in der Regel den Netbook dabei. Sven Kommt halt immer drauf an wie und wo man reist ;) Bei den Geräten der neueren Generation (also ohne Trackanzahlbeschränkung) ist ein Sichern egtl. nicht mehr nötig. Einmal am Tag den aktuellen Track exportieren und gut ist. Wenn es um sichern gegen Datenverlust wegen kaputtem Garmin geht, so hätte ich da unterwegs andere Sorgen, als ein verlorener Track. ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Am 05.09.2012 15:46, schrieb Martin Koppenhoefer: Am 5. September 2012 14:05 schrieb Bernd Wurst be...@bwurst.org: Am 05.09.2012 11:04, schrieb Martin Koppenhoefer: Eine Schranke ist nunmal ein Hindernis, die wird ja praktisch nie immer offen sein, sonst wäre da auch keine Schranke, was wiederum im Umkehrschluss bedeutet, dass sie auch mal zu sein kann. So wie eine Ampel ein Hindernis ist, das auch mal rot sein kann und dennoch würde keiner auf die Idee kommen einen drastischen Umweg in Kauf zu nehmen nur sicher nicht an einer Ampel vorbei zu kommen. Ich glaube nicht, dass die typischen Schranken vor Tunneln im Mittel mehr als einmal im Jahr zu sind, also nicht weit weg von immer offen. Diese Schranken sind genauso möglicherweise zu wie jede andere Straße möglicherweise gesperrt ist wegen irgendwas. Und, was willst Du damit sagen? Ist Deiner Ansicht nach barrier der geeignete key für diese Schranken oder nicht? Darum ging es. Wie bereits in einer anderen Mail geschrieben halte ich es für sehr sinnvoll geöffnete Schranken von geschlossenen Schranken zu unterscheiden und access-Tags nur auf den geschlossenen Zustand zu beziehen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Staatsgrenze mit der Tschechei
Am 05.09.2012 16:41, schrieb Florian Lohoff: Hi, On Wed, Sep 05, 2012 at 03:26:54PM +0200, Butrus Damaskus wrote: Hallo, in der tschechischen OSM sind (laut talk-cz) einige Leute dabei, nach freigestellten offiziellen Daten die OSM zu verbessern. In der letzen paar Wochen haben sich diese vor allem auf Verwaltungsgrenzen und deren Genauigkeit konzentriert. Es zeigte sich, dass sogar die Staatsgrenzen nicht immer ganz genau in der OSM dargestellt sind. Siehe diese Karte: http://osm.pada.cz/cr.html, wo Stellen angezeigt sind, die sich um mehr als 50m von den offiziellen Quellen unterscheiden. Ich habe mal nach 2-3 Stellen geschaut und das sieht ziemlich offensichtlich aus das die aktuellen Daten ungenau sind. http://osm.pada.cz/cr.html?zoom=17lat=49.32091lon=12.99265layers=B0T Da ist ziemtlich offensichtlich das der Fluß die Grenze ist aber die Aktuellen Daten das mal mehr Approximieren ... Ich wuerde sagen - macht mal ... +1 Henning ___ 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, 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. So etwas für alle Garminkarten anzubieten ist kompliziert, da jede Karte nahezu ein anderes Farb- und Linienkonzept hat. Da eine Farbe und eine Linienart zu finden, die mit allem harmoniert ist nahezu unmöglich. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezifische Radweg-Karte für Garmin?
Am 04.09.2012 12:21, schrieb Rainer Kluge: 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. Ist nur deutlich zu kompliziert, wenn man mit einer anderen Karte zufrieden ist und nur den Radweg hervorgehoben haben will. Wenn man sich ohnehin eine eigene Karte rechnet, dann ist dein Weg der sinnvollste Weg. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Hallo, das access eines barrier-Nodes beschreibt nur wie die Situation an der Barriere ist. Das access am Weg nur, wie es sich auf dem Weg davor und danach verhält. Es ist sowohl denkbar, dass man an eine üblicherweise geschlossene Schranke von beiden Seiten heranfahren darf, als auch, dass man dies an einer üblicherweise nicht geschlossenen Schranke von beiden Seiten heranfahren darf. Das access des Weges kann darüber also nicht zuverlässig Auskunft geben. Über ein access ist es schwer, weil eine Schranke eben diese zwei Zustände hat. Durch eine geöffnete Schranke darf in der Regel jeder durch. Daher sollte sich access auf den geschlossenen Zustand beziehen. Bspw. mit default_state=open könnte man angeben, was der übliche Zustand der Schranke ist und der Router kann das access überschreiben, wenn er es für richtig hält. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Schranken
Am 03.09.2012 14:50, schrieb Martin Koppenhoefer: Am 3. September 2012 13:53 schrieb Tobias Knerr o...@tobias-knerr.de: Übrigens: barrier ohne jedes access-Tag sind fast immer fragwürdig. Sollte eigentlich routinemäßig mitgetaggt werden, sonst müssen die Router raten. +1 Nunja...raten müssen sie nicht. Es gibt ja noch die Defaults. Ob das dann besser ist als raten ist eine andere Geschichte. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3. Runde Wikimedia Community Projektbudget
Am 16.08.2012 04:36, schrieb Falk Zscheile: Am 15. August 2012 22:53 schrieb ThomasB toba0...@yahoo.de: @Tim, das jetzt hat nichts mit Dir oder Wikipedia zu tun Ich habe eine tolle Idee. Trotz der Ankündigung von Bing, neue sehr hochauflösende Bilder rauszubringen, kaufen wir welche von eine Firma. Am liebsten von einer Firma, die mit A anfängt. Firmen mit A am Anfang sind immer gut. Dann lassen wir die Leute die Bilder einzeln ausm Internet rausfrimmeln und schauen dabei zu, ob sie es ohne unsere Hilfe schaffen einen Mapserver aufzusetzen oder ob sie die Bilder einzeln in JOSM laden müssen. Vorteilhaft wäre es noch, wenn es kein geeignetes JOSM Plugin für die Bilder geben würde sondern erst eins angepasst werden muss. Das erhöht den Spaßfaktor ungemein. Angebotene Hilfe blocken wir ab, es würde ja den Mappern zu einfach gemacht werden und uns den Spaß verderben. Nach ca. 9-10 Monaten stellen wir dann den ersten TMS/WMS bereits. Sonst merken die Leute ja gar nicht, wie einfach es hätte sein können. Und nach Ablauf des Vertrags schreiben wir mal einfach im Forum oder der ML, dass es uns weiterhin erlaubt ist, die Bilder zu nutzen. Sollen sie doch selber grübeln, ob das okay ist oder nicht. Vielleicht solltest du (ThomasB) einmal überlegen, ob deine Anspruchshaltung mit dem Ansatz und dem Wesen freier Projekte vereinbar ist. Anderen zu sagen du hättest aber [...], du müsstest aber [...], so wäre es doch viel einfacher gewesen [...], ich habs doch gleich gesagt [...] etc. ist immer einfach. Es zu machen oder etwas zu organisieren hingegen deutlich aufwendiger, denn plötzlich muss man eigene Zeit und eigenes können investieren bzw. sich das wissen auch erst noch erarbeiten ... Und das dauert in der Regel viel länger als eben mal ein paar Zeilen zu tippen, wie es hätte besser laufen können. Hallo, Thomas hat im Forum zu Zeiten, als man die Bilder nur über einen eigenen MapServer ins JOSM bekommen hat, das Angebot gemacht, ein paar Städte als WMS zu hosten. Anscheinend war das aber damals nicht gewollt oder was auch immer. Das kann ich nicht einschätzen. Stattdessen haben wir (meint einige Pro-Mapper, der Normalmapper hatte kaum etwas davon) uns knapp 1 Jahr damit beschäftigt Bildfetzen umständlich von einer Website zu laden und diese dann ins JOSM gebracht. Kurz vor Ende gabs dann 3 WMS-Server... Ich kann da schon verstehen, warum da einige (nicht nur Thomas) nicht gerade erfreut drüber sind ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSB-Cyclemap-Layer nicht aktualisiert?
Hallo schau mal da: http://cycling.lonvia.de Die Karte wird ~täglich aktualisiert. Viele Grüße Henning Am 15.08.2012 11:56, schrieb Steffen Grunewald: Nach dem Redaction-Bot-Durchlauf gab es hier in der Region etliche Lücken in den Radweg-Relationen (z.T. auch bei OpenStreetBugs eingetragen), die ich versuche zu flicken. Leider scheint der CM-Layer nicht mehr aktualisiert zu werden, so daß nicht zu sehen ist, ob die Bemühungen erfolgreich waren - wo hängt's, gibt es Alternativen? Ich würde gern einen OSB schließen, ohne sicher zu sein, dass das auch berechtigt ist... S ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erstelle ich ein *.poly
Hallo Andreas, steht egtl. am Anfang von osm2poly.pl, was die osm-Datei haben muss. Einen Weg mit den Tags: polygon_file=* polygon_id=* file und id muss sich unterscheiden bei den einzelnen Wegen einer Polygon-Datei. Bei einem Polygon je osm-Datei ist es egal, was du da einträgst. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=cemetary vs. amenity=feeding_place?
place_of_worship ist ein Platz, um Gott zu preisen/danken/etc. Für mich klingt das eher nicht so, kenne mich aber in der entsprechenden Religion nicht aus. Wenn das ein Ort ist, wo die Toten bestattet werden, dann ist das für mich ein Friedhof. Wie die Bestattung dann aussieht ergibt sich an dem religion-Tag oder anderweitigen beschreibenden Tags. Die Seebestattungsstellen sind bei uns bspw. als landuse=cemetry + cemetery=sea erfasst. Das die Leiche auf einem Friedhof eine längere Zeit liegt, muss auch in unserem Kulturkreis nicht so sein. Siehe bspw. den Streuwiesen. In andere Kulturkreisen sind die rieten halt anders, aber wenn das ein Ort ist, wo die Toten ihren letzten physischen Platz finden, dann sollte man das als Friedhof eintragen und näher spezifizieren. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 10:38, schrieb Manuel Reimer: Stefan Keller wrote: Die Projekt-ID würde ich - im Ggs. zur UUID - auch nicht an *alle OSM-Objekte hängen, sondern nur an die, auf die wirklich verlinkt wird (oder wurde). Ich würde auch die UUID nicht an *alle* Objekte hängen. Der, der sie zuerst braucht, legt sie an. Schon deshalb, weil ein Objekt ja mehr als eine UUID haben kann. Wenn jemand eine Referenz auf das Gebäude will, dann legt er ein uuid:building-Tag an. Der nächste interessiert sich vielleicht für die Funktion des Gebäudes (z.B. Restaurant) und packt noch ein uuid:amenity dazu. Wenn Gebäude und Funktion einmal unabhängig voneinander werden (Restaurant zieht auf andere Straßenseite um), dann verbleibt das uuid:building dort wo es war und das uuid:amenity zieht mit dem Restaurant auf die andere Straßenseite um. Wie soll das dann in der Praxis aussehen. Wenn ich ein Gebäude mit Restaurant indizieren möchte, soll ich dann uuid nehmen, oder gleich uuid:building. In der Regel ist es wohl so, dass der erste uuid setzt und alle weiteren dann Unterwerte...aber woher weiß ich dann als Unterwertsetzer, worauf sich die uuid bezieht? Wie lässt sich das vereinbaren mit amenity=restaurent;cafe ? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 12:09, schrieb Manuel Reimer: Kommt darauf an. Wenn der Betreiber der selbe ist, dann reicht uuid:amenity. Wenn unterschiedliche Betreiber, dann diese Aufzählung auf zwei Nodes aufteilen. Betreiber ist der selbe. Ergo, wie du sagst eine uuid:amenity=1. Nun meint ein Mapper das ist aber blöd, mein Garmin zeigt das falsch an, ich teile das auf zwei Nodes auf. Was nun: beide nodes mit uuid:amenity=1 oder mit unterschiedlicher uuid:amenity? Aber egal wie ich es mache, als Betreiber des Portals würde ich doch nun gerne eine Meldung bekommen und mir die Sache anschauen um dann selber zu entscheiden, ob ich mich für das Cafe interessiere, das Restaurant oder gar für beides. Dementsprechend müsste ich dann meine Links anpassen. Wenn ich keine uuid hätte sondern nur die osm-id, dann würde es auf das gleiche hinauslaufen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 17:15, schrieb Stefan Keller: Wenn das Restaurant aus der bbox rausrutscht, will ich es als ein anderes Objekt betrachten, also SOLL die ID kaputtgehen. Nein; keinesfalls: Habe oben bereits ein halbes Dutzend Beispiele zusammengetragen, wo die Koordinaten sich ändern, in dem ganze Gegenden einen Versatz haben. Und ich glaube es ist unbestritten, dass es dieselbe Bushaltestelle ist wenn man eine Bushaltestelle verschiebt, weil sie dann eher am Ort ist wo sie sein sollte. Und wer dieser Verschiebung nicht traut, kann selber nachschauen - das aber nicht auf Kosten der anderen verlangen, dass die Bushaltestelle damit à priori eine andere sei. Wenn ich dich richtig verstehe, ist es dir/dem Projekt also egal, wenn das OSM-Objekt von Hamburg nach Berlin verschoben wird? Wenn ich das Projekt betreiben würde, würde mich diese Änderung schon interessieren. Mein Gedankengang wäre dieser: OSM-DB, gib mir mein Objekt mit der ID x Dann prüfe ich, ob das Objekt noch da ist, wo ich es vermute, ob es noch die Eigenschaften hat, die ich vermute und dann nutze ich diese Infos. Wenn nicht möchte ich eine Info bekommen und dann nachschauen/nachschauen lassen. Wie eng ich die Grenzen setze, muss ich mir dann überlegen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 27.07.2012 19:20, schrieb Peter Wendorff: Am 27.07.2012 17:31, schrieb Stefan Keller: Lieber Peter Am 27. Juli 2012 17:18 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 27.07.2012 16:23, schrieb Stefan Keller: ... Gegeben ein Gebäude in OSM mit den Tags Gebäude, Tankstelle und Shop dann erhält das OSM-Objekt eine einzige PID. In der anderen Fachdatenbank werden drei Objekte verwaltet, die alle auf das eine permanente/stabile OSM-Objekt zeigen. Oh, das ist gut. Dann baue ich einen Bot, der vorsichtshalber an jedes Objekt eine ID klebt, z.B. die ID, die das Objekt schon aus osm hat. Solange mein Bot der schnellste ist, bin ich immer der erste und alle anderen müssen damit klarkommen. Ich habe niemals von einem Bot gesprochen, sondern dass die Interface-DB immer dann eine PID vergibt, wenn ein OSM-Objekt verlinkt wird und zwar als PID gegen aussen und als PID auf dem OSM-Objekt. Diese PID wird dann von möglichst vielen via LinkdOSMDB genutzt. Ein OSM-Objekt - eine PID, fertig. Zudem: Mapper erkennen die ID-Eigenschaft und Freiwillige helfen, Spezialfälle zu fixen, wie sie oben z.T. oben diskutiert worden sind. Das funktioniert aber nicht. Ich bin dummerweise das zweite Projekt, das eine ID auf ein OSM-Objekt braucht, und dummerweise ist die aber anders definiert, weil ich wirklich das Gebäude aufgrund der historischen Bausubstanz meine, die PID aber dummerweise auf das Restaurant verweist. Wenn ich von der LinkdOSMDB keine ID für meine Zwecke kriege, habe ich nichts gewonnen. Wenn ich von der LinkdOSMDB nur dann eine ID kriege, wenn zufällig sonst niemand anders vorher eine hatte, habe ich nichts gewonnen. In beiden Fällen muss ich nämlich doch eine Fallback-Lösung implementieren, die der von mir gewünschten ID entspricht, womit wir wieder beim Anfang wären. Hallo, nein, diese PID würde, wenn ich es richtig verstanden habe, auf das OSM-Objekt in Gänze. Sprich die Bauwerk-DB und die Restaurant-DB würden auf die gleiche PID linken. Die beiden Projekte müssen dann nur unterschiedlich auf eine Änderung reagieren. Daher hab ich ja das große Problem, dass ich keinen Vorteil gegenüber der OSM-ID sehe. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hallo Frederik, die Idee mit dem Löschen an sich finde ich sinnvoll. Denke aber das es nur sinnvoll sein kann, da zu löschen, was auch remappt/kontrolliert wurde. Ich denke es hilft keinem, wenn ein Mapper jetzt hingeht und bspw. alle Feldweg rauslöscht, nur weil ihn diese nicht interessieren. Wenn man das so handhabt, dann können die Objekte auch komplett weg. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Am 25.07.2012 01:20, schrieb Stefan Keller: Ich habe einfach Bedenken mit Koordinaten arbeiten. Die machen fast noch grösseren Kummer als die OSM-ID. Das klingt für mich etwas komisch. Du willst nicht mit einer festen Koordinate/BBox arbeiten, aber dir dann über mehr oder weniger Raten eine Koordinate aus der OSM-DB holen? Mal ganz praktisch gefragt: Was verspricht sich ein Projekt egtl. aus so einer Verlinkung? Die meisten Eigenschaften wird das Projekt sowieso selber erheben müssen. Bei OSM gibt es neben der Koordinate in der Regel maximal noch die Adresse. Ist es da nicht allgemein deutlich einfacher, diese Daten selber zu speichern? Das hindert ja kein Projekt daran, die Daten nicht aus OSM zu holen. Aber wenn ich mir so überlege, welcher Aufwand getrieben werden soll, um das ganze zu verknüpfen, frage ich mich ob das überhaupt einen nennenswerten Vorteil bringt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 24.07.2012 09:56, schrieb Stefan Keller: Letztlich sagst du damit, dass jedes OSM Objekt identifiziert oder zumindest verfolgt werden kann, wenn man vom ihm 1. die OSM ID(?), 2. die Version und 3. das Change-Datum (aus der Historie) verwaltet, oder? Nein...du kannst mit ID und Datum immer das Objekt bekommen, dass du in deine DB eingetragen hast. Bsp.: Du verknüpfst gestern eine Bushaltestelle mit deiner DB. Heute lösche ich die Bushaltestelle und trage eine neue ein. Dann kannst du aus der History DB das Objekt so bekommen, wie es gestern war. Was ich dann mit dem Objekt gemacht habe, kannst du auch in Erfahrung bringen, aber das muss dann nicht mehr das Objekt sein, auf das sich deine DB bezieht. Da diese weiterverfolgung nicht geht, kannst du dir aber auch gleich die Daten aus OSM kopieren und in deine DB einfügen. Da ist der Aufwand geringer. Denn so eine History-DB ist mit Sicherheit nicht ohne ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 23.07.2012 12:38, schrieb Manuel Reimer: Beispiel: Ich habe für unseren Heimat- und Geschichtsverein eine Karte gebaut, auf der alle Bildstöcke, Wegkreuze, Kirchen und Sehenswürdigkeiten als kleine Pinnadeln gezeigt werden. Beim Anklicken der Pinnadel geht ein Popup mit kurzem Text und einem Foto auf. Die Verknüpfung zwischen Punkt (Hole ich aus der OSM-DB) und Text + Foto mache ich aktuell anhand der ID. Wenn sich die ID mal ändert, dann muss ich in meiner DB eine Änderung durchführen. Hätte ich nun UUIDs, dann könnte ich stattdessen eine von einem Mapper kaputtgemachte UUID einfach wieder einfügen und die Verknüpfung passt wieder. Eventuell ist der Mapper sogar so nett und zieht beim Umbauen von Node auf Way alle Tags mit um. Dann passt es direkt wieder. Ich fasse mal zusammen: mit OSM-ID musst du eingreifen, wenn das benötigte Objekt eine andere OSM-ID bekommt und bei UUID musst du eingreifen, wenn jemand das Objekt mit der UUID ändert. Wo ist der Vorteil der UUID? Das Permanent ID Konzept taugt für mich garnicht, denn für die meisten Bildstöcke ist nur ein Tag dran. Und zwar das, was diesen Node als Bildstock auszeichnet. Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 23.07.2012 18:27, schrieb Toni Erdmann: On 07/23/2012 06:17 PM, Garry wrote: Am 23.07.2012 17:24, schrieb Michael Herbold: Hallo, erst mal vielen vielen Dank für das zahlreiche und konstruktive Feedback. Wir haben heute früh schon angefangen, die Strecken entsprechend zu taggen (siehe http://www.openstreetmap.org/user/synyx/edits). Wie Robert S. korrekt bemerkt hat ist toll:hgv=yes nicht korrekt, da die Maut erst ab 12 Tonnen gilt. Den Vorschlag toll:N3=yes finden wir gut und würden dies auch an den bereits erstellen Tags anpassen (thx @ jimmy für den Vorschlag). hmm, ich würde dann aber noch den Geltungsbereich des 'N3' einbeziehen. Nicht dass die USA noch 'N3' = 'Bicycle' einführen für die man dann Toll zahlen muss. toll:EU:N3 oder wo auch immer diese 'N2' und 'N3' ihre Gültigkeit haben. ...nur das damit keiner mehr etwas anfangen kann. Wenn ich mal ans extended access-Schema zurückdenke, wäre es sowas wie toll:hgv:(weight12)=yes Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 23.07.2012 17:41, schrieb Stefan Keller: Am 23. Juli 2012 13:16 schrieb aighes o...@aighes.de: Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist? Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben wurde, dann ist es weg, ausserhalb der BBOX. Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen. Bspw. Restaurantführer: Wenn die Anzahl der Tische etc. erfasst haben, wäre es fatal, die Daten nach einem Umzug nicht zu aktualisieren. Man will also wissen, ob das Objekt sich deutlich bewegt hat. Beim blinden kopieren der UUID merkt man davon leider nicht viel. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Hallo Frederik, meiner Meinung nach ist die Maut eine Eigenschaft der Straße und sollte daher auch an der Straße getaggt werden und nicht an einer Routenrelation. Für eine Auswertung wäre es auch deutlich einfacher, wenn die Wege (in irgendeiner Form) entsprechend getaggt sind. Bei anderen Eigenschaften eines Weges erfassen wir ja auch nicht Start- und Endpunkt der Eigenschaft, sondern geben dem Weg diese Eigenschaft. Ich sehe jetzt erstmal keinen Grund hiervon abzuweichen. Henning ___ 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 22.07.2012 21:25, schrieb Rainer Dorsch: 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. 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. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 22.07.2012 21:38, schrieb Jo: Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche spezifischen Tags an Objekte hängt? Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und ein neues ohne all die ref-Tags erstellt? Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 22.07.2012 22:45, schrieb Stefan Keller: Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Verstehe ich nicht. Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine Datenbank für alle sein kann und einfach vollgestopft werden soll mit Tags, die von externen Projekten kommen. Der einzige Tag den ich vorschlage ist diese eine Projekt_ID. Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil gegenüber der normalen Objekt-ID. Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört, oder zu dem Objekt Restaurant. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge haben). In beiden Fällen kommt bei dem Projekt Unsinn an, der evtl. nicht bemerkt wird und wenn er bemerkt werden würde, dann würde er auch bemerkt, wenn man nach der OSM-ID gegangen wäre. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Am 21.07.2012 13:27, schrieb Peter Wendorff: Am 21.07.2012 12:07, schrieb Walter Nordmann: cottaer wrote Was ist eigentlich mit denen, die die Mapnik-Kacheln für zum Beispiel eine Anfahrtsbeschreibung (als Google-Alternative) nutzen? Zum Beispiel hier: http://www.openstreetmap.org/?lat=-33.9181lon=151.2052zoom=14layers=M hi, wie lautet das osm-prinzip? wenn dir etwas fehlt, dann trag es ein und das sollte für reine Kartennutzer auch gelten, wenn sie eine vernünftige, korrekte Darstellung Ihrer Anfahrt haben wollen. Die basierte nun mal auf illegalen Daten und muss jetzt nachgebessert werden. Hart und ein wenig unfair, aber anders geht es nicht. Alternativ kann man aus den alten Daten selbst rendern oder jemanden rendern lassen. Das ist nicht zwingend kostenlos, aber ständige Verfügbarkeit oder irgendein Qualitätskriterium ist für die Tiles von osm.org auch niemals und von niemandem garantiert worden. Eher im Gegenteil...es wird sogar für den produktiven Einsatz dazu geraten, etwas eigenes aufzusetzen oder MapQuest zu nutzen. Und bevor das Argument kommt: Viel zu kompliziert...bei einer Anfahrtskizze tut es schon ein Screenshot der Karte. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Wissenschaft: Schlussfolgerung aus BOT-Laufzeit (wenn ja: welche)
Neben der reinen Datenmenge kommt es wohl primär darauf an, wie komplex die Gegend gemappt ist. Komplex meint nicht nur die Datendichte, sondern auch die Anzahl der Versionen der Objekte und die unterschiedlichen Bearbeiter. In einer deutschen Kachel muss der Bot deutlich mehr Objekte, deutlich aufwändiger untersuchen als in anderen Regionen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Am 19.07.2012 09:55, schrieb Chris66: Es wurde immer gesagt, dass die Bad-Map (bzw. Clean-Map) nicht 100% genau sind Um das noch zu konkretisieren: Es steht sogar explizit bei jedem Aufruf da. What this map does not do: * show changes in geometry due to way nodes being deleted, this may be implemented in a future version * show information loss due to edits by non-agreers Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Announce] Redaction progress
Hallo Kurz Zusammengefasst bedeutet das, das der Bot nochmal wieder kommt und die restlichen Elemente noch bearbeitet. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing Bilder ... aber anders
Hallo In der Türkei gibt es schon recht viele Gegenden, wo es sehr gute Bilder gibt. Allerdings ist dort auch schon recht viel gemappt. Nimm mal Kontakt zu katpatuka auf. Ist ein deutscher, der in der Türkei lebt und dort das meiste gemappt hat. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Changemap+ ähnlich wie Badmap
Am 19.07.2012 21:48, schrieb Steffen van Bergerem: Vom darauf beschränken war nie die Rede. Wenn ich zum Beispiel sehe, dass der maxspeed-Tag gelöscht wurde, kann ich diesen vor Ort überprüfen und im gleichen Atemzug noch weitere fehlende Tags ergänzen. Und wenn du jetzt siehst, dass es keinen maxspeed-Tag gibt, kannst du ihn nicht ermitteln und eintragen? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Am 19.07.2012 21:50, schrieb Garry: Am 19.07.2012 18:03, schrieb Jimmy_K: Am 19.07.2012 14:31, schrieb Garry: Für den Aufwand den man jetzt hat könnte man OSM auch gleich neu aufsetzen und die Erfahrungen vergangener Jahre nutzen um strengere Regeln zu definieren die ein konsistenteres Datenmodell schaffen. Das kann man aber nur erreichen, in dem man die Community weniger mitreden lässt, was aber gleichzeitig ein Kritikpunkt ist?! Wenn man beide Optionen parallel laufen lässt kann jeder selbst entscheiden. Mit dem jetztigen Zustand kann jedenfalls kaum jemand zufrieden sein. Da hat OSM jahrelang bewiesen dass es entgegen aller externen Provezeiungen relativ unempfindlich gegen Vandalismus ist und dann setzt es sich selber ausser Gefecht.. Ich denke, keiner hält dich auf, ein neues OSM mit einer leeren Welt zu starten... Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachfrage OSMF Redaction Account - was tut der?
Am 20.07.2012 01:03, schrieb SteMo: Danke Peter! Ja, das ist das, was ich meinte! Etwas mehr Hirnschmalz in den BOT gesteckt und das wäre möglich gewesen, denn die Informationen, was von welchem Bearbeiter dem jew. Node/wire hinzugefügt wurde, ist ja offensichtlich bekannt. So viel semantische Intelligenz bräuchte der BOT vielleicht gar nicht. Punkt 1: Seit mindestens März 2012 hat man nach Leuten gesucht, die den Hirnschmalz in den Bot stecken...wo warst du da? Punkt 2: Läuft das nicht auf klare Fälle hinaus. Wenn ich ein maxspeed setze, muss das noch lange nicht heißen, dass ich irgendwas von den vorhandenen Infos auch hätte eintragen können. Man kann Raten, dass jemand, der maxspeed eingetragen hat, auch Tag xyz=abc eintragen hätte können. Aber sicher sagen kann das nur ein Mensch im Einzelfall und zwar der, der den Edit gemacht hat. Um genau dies zutun, hatte er mehr als 1 Jahr Zeit. Ein falsches Raten hat dann entsprechende Konsequenzen, für all jene, die die Daten nutzen wollen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Och...es gibt da so eine gewisse Gruppe Mapper, die bspw. wegen dem Datenverlust abgelehnt haben und genau damit haben sie für den Datenverlust gesorgt. Ich nehme es keinem übel, der aus rechtlichen Gründen nicht zustimmen konnte, den man nicht mehr erreicht hat oder der sich vorher von der Community verabschiedet hat. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nachfrage OSMF Redaction Account - was tut der?
Am 18.07.2012 15:59, schrieb Martin Feuersaenger: Hallo, da will ich gleich mal an dieser Stelle meine (eventuell auch blöden ;-) ) Fragen hinterherschieben: 1.) Zum derzeitigen Bot-Status: Laut Harry Woods Karte ist der Bot im Moment nicht mehr in Westeuropa aktiv. Das scheint aber nicht ganz zu stimmen, denn laut Account des Redaction Bots treibt er sich im Moment gerade in außer in den südlichen USA auch westlich von Wismar herum. Ist da was bekannt, das die Bot Progress Karte im Moment nicht läuft? Also ich sehe da noch 7 gelbe Rechtecke und noch ein paar nicht bearbeitete in Deutschland. Polen wurde erstmal zurück gestellt. 2.) Wenn ein Gebiet in Harry's Karte als succesfull markiert ist: - Kann man den Mapnik-Tiles auf www.osm.org vertrauen, d.h. basieren die auf den aktualisierten Karten oder ist der rendering lag im Moment zu groß? Hintergund: Es verwirrt mich, das Objekte, die im OSM Inspector als nodes und ways von Nichtzustimmern angezeigt werden, nach dem Redaction bot run immer noch in den Mapnik tiles und auch in einem aktuellen Download im Editor angezeigt werden. Der OSMI ist nicht die Visualisierung des Bots, sondern er hat einen Anhaltspunkt gegeben, wo Probleme liegen. Der Bot prüft halt deutlich genauer und umfangreicher, als es der OSMI-View getan hat. Erklärt evtl. auch die leicht unterschiedlichen Rechenzeiten ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation Analyzer im neuen Gewand
Hallo Adrian, wäre es möglich, dass du noch ein Datum anzeigst, wenn du eine Relation aus dem Cache analysierst. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM T-Shirt?
Am 15.07.2012 13:17, schrieb malenki: aighes schrieb: ich hatte mal über ein Rad-Trikot nachgedacht, mit dem Slogan Mapping in progress und OSM Logo etc. Lohnt sich halt aber nur, wenn da ein paar zusammen kommen. Ein einzelnes kostet ~100€... Ein Baumwoll-T-Shirt mit dem Aufdruck eines selbstgebastelten Bildes Schriftzugs kostete mich 20 EUR/Stück. Folgendes als Bild auf einem Oberbekleidungsstück gefiele mir: Stilisierter Radfahrer auf einer Fahrbahn, die ein Stück nach dem Fahrrad zu einem GPS-Log wird, ein Stück dahinterer zu einem Stück stilisierter Landkarte. Weiß nicht, ob ich das Bild irgendwo im Wiki sah oder ob es komplett meiner Phantasie entspringt. Könnte von ¹ inspiriert sein. ¹ http://wiki.openstreetmap.org/wiki/Tshirt_competition#Richard.27s_entry Ja, an sowas hätte ich auch gedacht... Ich habe hier geguckt: http://www.owayo.de/radsport-radtrikots/preise/preislisten.htm Qualitativ sind die ganz gut. Baumwolle wäre natürlich auch eine alternative. Wobei ich auf die Qualität Fotodruck aufs T-Shirt eher nicht so optimal finde. Das wäscht sich recht fix raus und wird dann blass. Gibt es denn überhaupt einen Shop für OSM-Artikel? Oder wäre das etwas für den Fossgis? Das könnte man ja auch durchaus mit einer Spende/Aufwandsentschädigung verbinden, in dem man die Teile dann teurer verkauft, als sie im Einkauf und Versand sind. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM T-Shirt?
Am 15.07.2012 18:13, schrieb Sven Geggus: aighes o...@aighes.de wrote: Qualitativ sind die ganz gut. Baumwolle wäre natürlich auch eine alternative. Wobei ich auf die Qualität Fotodruck aufs T-Shirt eher nicht so optimal finde. Das wäscht sich recht fix raus und wird dann blass. Jepp und außerdem haben diese Shirts immer so einen Regenjacken-Effekt. Der Flexdruck den Spreadshirt für Vektormotive verwendet ist ganz gut! Nachteil kann je nachdem sein, dass es eine Mindestbreite für die aufgedruckten Objekte gibt. und man ist auf drei Farben je Motiv beschränkt. Halte ich jetzt bei der Idee mit Radler-Track-Editor-Karte für problematisch. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM T-Shirt?
Am 13.07.2012 10:19, schrieb Manuel Reimer: Sven Geggus lists at fuchsschwanzdomain.de writes: Ich finde es ehrlich gesagt verwunderlich, dann noch niemand ein script gebaut hat, das automatisch Karten für T-shirts rendert. Muss ja nicht unbedingt ein Kartenausschnitt sein. Nennung des Projektnamens, ein monochrones Logo, vielleicht noch irgendein Slogan. Das Shirt sollte ausreichend neutral sein, dass es im Alltag getragen werden kann. Hallo, ich hatte mal über ein Rad-Trikot nachgedacht, mit dem Slogan Mapping in progress und OSM Logo etc. Lohnt sich halt aber nur, wenn da ein paar zusammen kommen. Ein einzelnes kostet ~100€... Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [OSM-talk] Licence redaction ready to begin
Am 12.07.2012 10:29, schrieb cottaer: Am 11.07.2012 17:36, schrieb Simon Poole: Die Edits des bots sind hier: http://www.openstreetmap.org/user/OSMF%20Redaction%20Account/edits Mal interessehalber gefragt, warum hat dieser Node überlebt, wenn Versionen 1 bis 3 nicht sauber waren? (Gibt auch noch mehr Beispiele.) http://www.openstreetmap.org/browse/node/631811125/history Nachvollziehen kann man es nicht mehr wirklich, da ja die Infos fehlen, was der Knoten vorher war. Denkbar wäre, dass es einfach nur ein leerer Knoten war, der dann in v3 verschoben wurde und den name-Tag bekommen hat. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: [OSM-talk] Licence redaction ready to begin
Ich muss mich revidieren...dann müsste ja v3 clean sein. Oder der Bot setzt sich dann an die Stelle des ersten cleanen Beitrags. Mogelt sich als zwischen Ablehner und erstem Zustimmer. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kemmt Mapnik?
Ja...die diffs waren zeitweise kaputt...laufen jetzt aber wieder. http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/replication_delay.html Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Mal ein Beispiel aus der Vergangenheit zu Radrouten/Wanderrouten: Zu Beginn wurden diese einfach an den Weg getaggt, über den diese verlaufen (Bsp: ref_rcn=ThSk). Das funktionierte sehr gut, bis es gehäuft vorkam, dass über manche Wege mehrere Routen verliefen (Bsp: ref_rcn=Ilm;ThSk;Fei). Für meine Karte wäre das vollkommen ausreichend. Mich interessiert die Info, ob auf diesem Weg eine Radroute verläuft und die ganzen Abkürzungen als ein String für den Namen, den man noch mit Stringreplace etwas aufhübschen kann. Projekte wie die Karten von Lonvia dürften damit nur sehr kompliziert umsetzbar sein. Was nun der einfache Weg ist und was nicht halte ich für nebensächlich, sobald ein Editor mit ins Spiel kommt. Den kann man immer so anpassen, dass dieser eine Weg möglichst einfach ist. In josm sind doch eineige Sachen über Relationen nur so einfach, weil josm die Relation speziell behandelt und Tools bereit stellt, einfach damit zu arbeiten. Wenn man sich nicht auf Routenrelationen geeinigt hätte, hätte josm wahrscheinlich andere Tools, die die Arbeit mit Routen unterstützen würden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Ihr redet ein klein wenig an einander vorbei. Die Relation ist einfacher. Aber eben nicht alle Goethestraßen sind auf diese weise eingetragen und für diese muss man dann trotzdem den komplexeren Algorithmus entwerfen. Wenn man also gleich nur den komplexeren Algorithmus nutzt, spart man sich das auslesen der Relation. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Am 08.07.2012 17:06, schrieb Jimmy_K: Am 08.07.2012 12:28, schrieb Florian Lohoff: Relationen sind schoen um dinge abzubilden die sich anders nicht abbilden lassen. Gerade bei Geschaeften spricht aber nichts dagegen die Adresse auf allen nodes zu haben. Das ist einfach und fuer jeden gut zu pflegen. Flo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Kann nur dann zum Problem werden, wenn ich nach einer Adresse Suche und dann 35 Mal das mehr oder weniger selbe Ergebnis bekommen. Macht das Navigieren nicht gerade übersichtlich. Es wurde einmal der Ansatz diskutiert: Hausnummer auf die Gebäudefläche und alle POI die darin liegen, bekommen die Adresse dann automatisch, aber keine Ahnung, ob es da konkrete Entwicklungen gibt. Sehe ich recht ähnlich. Da aber jeder Tagt, wie er möchte muss ein Auswerter sowohl mit der site-Relation klar kommen, als auch mit der von dir angesprochenen Annahme, als auch mit der Situation, dass jedes Objekt eine eigene Hausnummer hat. Das führt zu einem recht hohen Aufwand, den nicht jeder leisten möchte. Wenn man sich nicht auf eine Variante einigt wird es immer eine Glücksache sein, ob es ausgewertet wird und wie dann das Ergebnis ist. In der Theorie kann man mit jedem obigen Ansatz einen Algorithmus schreiben, der etwas sinnvolles ausspuckt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätskontrolle POI in OSM
Am 07.07.2012 11:48, schrieb Peter Wendorff: OSM ist und bleibt ein Freiwilligenprojekt, aber zunehmend gibt es auch Interessenten, die OSM eben nicht nur als Hobby nutzen wollen. Wenn Frederik mit der Geofabrik Dienstleistungen rund um OSM verkaufen will - angepasste gedruckte Karten, Analysen, Web-Angebote oder was auch immer, dann kann er das nur, wenn die Daten zumindest akzeptabel in Qualität und Vollständigkeit sind. Ich bin mir ziemlich sicher, dass er trotzdem weiterhin viel Zeit einfach auch als Hobby in die OSM steckt oder zumindest in Bereiche, bei denen er kein Geld damit verdient, aber trotzdem will er was verkaufen. Hallo, wenn ich Dienstleistungen auf Basis von OSM anbiete, muss ich entweder das an bieten was die Freiwilligen so Zusammenmappen oder aber ich muss der Anbieter für die Qualität sorgen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitaetskontrolle stochastisch
Hallo, wenn man schon den Nutzer befragt kann man ihn doch auch gleich den Fehler melden lassen ala OpenStreetBug. Das wollte ja mal in die Hauptseite integriert werden Ansonsten sehe ich halt auch die Gefahr, dass das Ergebnis unbrauchbar ist, weil jeder Nutzer andere Kriterien für Daumen hoch und Daumen runter nimmt. Wenn man sehr verwöhnt ist von Region A wird man evtl. in einer Region B Daumen runter wählen, weil die Öffnungszeiten fehlen. Dem Mapper würde es sicher deutlich mehr helfen, wenn man konkret weiß, wo der Fehler zu suchen ist und nicht in dem Kartenausschnitt suchen muss. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitaetskontrolle stochastisch
Am 06.07.2012 14:54, schrieb Frederik Ramm: Genau. Wenn man das irgendwo auf Freds kleiner Runzelkarte installiert, geht es nicht. Sowas muss dann gross auf einer Karte, die sehr viele Leute sehen. Wie vorhin schon gesagt - allein zu wissen, diese Karte auf diesem Zoomlevel haben in den letzten 24 Stunden 157 Leute angeschaut, ohne auf Daumen runter zu klicken, waere schon etwas wert. Diese Aussage ist aber an den Haaren herbeigezogen. Woher weißt du, wie jemand die Karte findet, wenn er nicht abstimmt? Nein, das halte ich fuer nicht praktikabel. Aber wenn ein z15-Tile schon 20 Daumen runter kassiert hat, traue ich mir durchaus zu, das Problem zu finden. Das Problem ist halt, dass der Browser nicht nur ein Tile anziegt, sonder ein paar mehr. Wenn auf einem Tile nun ein Fehler ist, bekommen viele Tiles eine negative Bewertung, obwohl sie egtl. völlig ok sind. Wobei Fehler völlig undefiniert ist und alles sein kann. Von fehlendem Kiosk bis zu Kartenbild an sich hässlich. Wenn ich nicht weiß, was da falsch ist, kann ich es weder beheben, noch hab ich Lust eine weitere Anreise zu machen, um einen Reality-Check zu machen. Das nächste Problem ist dann ja, dass wir vieles auch so schon wissen. Das in einem Großteil der Länder noch Unmengen an Straßen fehlen kann ich dir auch so sagen. Dafür muss mir keinen den Kartenausschnitt negativ Bewerten. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitaetskontrolle stochastisch
Hallo Am 06.07.2012 19:35, schrieb Frederik Ramm: Ja, deswegen habe ich auch nicht von Fehlern gesprochen (zumindest nicht absichtlich). Ein Benutzer, der einen Fehler genau identifizieren kann (dieser Briefkasten gehoert hier nicht hin), der kann das vielleicht auch praeziser mitteilen. Ein Benutzer, der nur so ein Gefuehl hat (also als ich letztes Mal da war, waren die Briefkaesten glaub ich woanders...), Aber bringt es da nicht dem Mapper (und in Folge dessen auch dem Melder) mehr, wenn dann nicht nur Daumen runter gemeldet wird, sondern ein Bug erzeugt wird, mit dem Text: Ich hab das Gefühl, die Briefkästen stehen woanders? Bei Daumen runter kann eben alles mögliche verbesserungswürdig sein. Von einem Straßennamen über die Geometrie einer Straße bis hin zu Details wie Campingplatz ist nicht als Fläche gemappt. Ich versteh dich schon ein wenig, nur denke ich, dass die Aussagen, die du aus dem Tool ziehen willst keinen großen Nutzen haben, eben weil die Ansprüche der Nutzer unterschiedlich sind. Die Unterschiede könnte man auch darauf zurückführen, dass die Nutzer in Frankfurt deutlich kritischer sind als die Nutzer in Islamabad, einfach weil sie mehr Qualität gewohnt sind. Wenn ich mir die Karte von Islamabad anschaue, gehe ich mit der Hoffnung an die Sache ran, dass alle Hauptstraßen da sind und viele Nebenstraßen. In Frankfurt eher mit der Hoffnung, dass selbst kleinste Fußwege gemappt sind, am besten noch mit surface, etc. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätskontrolle POI in OSM
Hallo Christian, das Problem ist doch aber: Entweder es gibt eine, der sich für den POI verantwortlich fühlt und ihn auf dem aktuellen Stand hält, oder es gibt ihn nicht. Wenn Ersteres, dann braucht es kein lastcheck, da der Mapper über seine Region Bescheid weiß und nicht jeden Monat ein lastcheck hochzählen muss. Wenn Zweiteres, dann hilft auch kein lastcheck. Dann bleibt die Situation halt so wie sie ist. Wie die Daten genutzt werden, ist für das Problem unerheblich. OSM lebt davon, dass es einen aktiven Mapper vor Ort gibt. Ist dies nicht der Fall, hilft auch keine Erinnerungsfunktion. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 05.07.2012 08:42, schrieb Rainer Kluge: Ausgangspunkt ist, dass die Nutzung der Garmin-Karten für ein breites Publikum erleichtert werden soll, um möglichst viele Nutzer zu gewinnen. Andererseits werden Lösungen mit flexibler Konfiguration und Gebietsauswahl angedacht, die für jeden Zugriff mindestens das Mergen der Tiles zu einem gmapsupp erfordern. Mit steigender Zahl der Abrufe verlängern sich also die Wartezeiten, die Akzeptanz sinkt, die Nutzerzahl stagniert oder geht zurück. Was man aus meiner Sicht braucht, sind eine Handvoll Kartentypen, tagesaktuelle Karten für die wichtigsten Länder, wochenaktuelle Karten für die Hauptreiseländer und für den Rest der Welt Karten on Demand mit Wochencache. Ausschneiden und Mergen kann jeder selbst machen. Das Problem ist eher: Wie bringen wir den Nutzern die Vielfalt an OSM Karten näher, sodass sich jeder eine für ihn passende Karte auswählen kann. Ich nehm' dich jetzt mal und mach die Hand voll, also 5 Karten. Eine Karte fürs Motorad, eine fürs Auto, eine für den Wanderer, eine für den Radfahrer und eine für den Wassersportler. Doch was ist dann mit dem LKW-Faher oder dem Reiter? Wo bleiben die unterschiedlichen Bedürfnisse der Radfahrer? Wenn man eine Auswahl trifft, dann kommt bei dem Nutzer als Botschaft an: Das sind DIE OSM-Karten und der Rest sind irgendetwas anderes. Das Problem haben wir derzeit schon bei den Online-Karten und eine Wiederholung sollte man sich meiner Meinung sparen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hallo Rainer, mir geht es nicht primär um die Optik der Karte sondern um den Unterbau (Routing). Die OpenMTBMap routet halt so, dass MTB'ler zufrieden sind, die VeloMap eher mehr für die Rennräder. Der Motoradfahrer möchte evtl. eher auf den Landstraßen fahren der Autofahrer eher Autobahnen und der Spediteur wieder anders. Im Kartenbild kann das aber auch unterschiedlich sein. Hervorhebung von Wanderwegen vs. Radwegen vs. Wasserwanderwegen. Oder Hervorhebung von Mautstrecken. Hier kommt es halt immer drauf an wie sehr man die Wege optisch unterschiedlich differenzieren möchte. Packt man alles in eine Karte rein, kann das auch sehr unübersichtlich werden. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 05.07.2012 11:38, schrieb Ronnie Soak: Deshalb klappt das alles nur MIT den Kartenanbietern. Wenn diese ihre Toolchain nicht offenlegen wollen, dann klappt das natürlich nicht. Mag sein, dass der einen oder andere das als 'Betriebsgeheimnis' sieht, ich hoffe aber eigentlich, dass dem im breiten Feld nicht so ist. Deshalb auch die schon erwähnte Ausrichtung durchaus auch FÜR den (potentiellen) Kartenabieter. Das wäre auch eine Plattform FÜR ihn, wo er seine Karte an einem zentralen 'Marktplatz' anbieten kann. Technisch läuft das natürlich darauf hinaus, die Toolchain des Anbieters auf dem zentralen Server zu clonen. Wo sich Gemeinsamkeiten finden klappt das sicher sehr gut (lediglich style-/typfiles anpassen), wo Spezialtools nötig sind ist es aufwendiger (spezielle mkgmap-version, zusätzliche Datenimports von extern etc.). Ich denke an technische Grnezen stossen wir erst dann, wenn die Karte mittels Handarbeit und irgend welchen Windows-only tools erstellt wurde. Dann bleibt uns wirklich nur das Spiegeln der fertigen Karten. Ich sehe das Problem dann eher in der Aktualisierung der toolchain. Wenn der Kartenanbieter einen Bug fixt, mag er uns wahrscheinlich nicht extra Bescheid sagen oder es gar an 2 Stellen ändern (selbst wenn er das z.B. über einen SVN Zugang könnte.) Wir bleiben dann also auf der alten Version sitzen. Wenn, dann würde ich es eher so sehen, dass die Karte dann nur dort gerendert wird. Es macht schließlich nicht viel Sinn, eine Karte an zwei Orten anzubieten. Wie wäre es denn, wenn man gewisse Regionen (auch abhängig von der Kartenart) vorrendert und nur den Rest OnDemand macht. Ich meine so Standardregionen wie Deutschland, etc. Das könnte man dann einmal in der Woche oder im Monat rechnen lassen, wenn wenig Last ist. Dann spart man sich für so Standardzeug die Rechenarbeit. Kleine Länder kann man wirklich OnDemand rechnen. Dänemark rechnet bei mir bspw. 2min. Die Türkei, Neuseeland und Zentralasien ist in der gleichen Größenordnung. Hast du mal mit Lambertus gesprochen, wie es mit Feedback, Last und Hardware bei ihm ausschaut und geschaut, wie teuer die nötige Hardware wäre? Es lohnt ja nicht hier tolle Ideen auszugraben um dann festzustellen, dass das über Spenden nicht finanzierbar ist. Henning Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 05.07.2012 12:51, schrieb Ronnie Soak: Leider bekomm ich die kachelweise Auswahl, wie sie Lambertus macht, noch nicht so im Konzept unter. Wir brauchen ja die Länder als Gruppierung und ID für den Cache. Ich persönliche finde die Kachelweise Auswahl aber auch extrem nützlich. Ich muss da noch mal nachgrübeln... Ich weiß nicht wie sehr du beim Erstellen von Garminkarten in der Materie drin steckst. Mal am Beispeil von Deutschland erklärt. Wenn man mkgmap die pbf-Kacheln gibt, rechnet er bei mir ~37min diese in img-Kacheln um. Dann folgen ~3min für das Zusammenfassen zur gmapsupp.img. Dieses Zusammenfassen würde immer Anfallen, wenn der Nutzer eine andere Kachelzusammenstellung wählt. Daher wäre es fürs cachen natürlich sinnvoll, wenn alle, die eine Deutschlandkarte wollen, die gleichen Kacheln herunterladen. Meine Idee wäre jetzt eine Kombination aus fertigen, fixen Extrakten der frequentierten Länder und zusätzlich eine variable Auswahl der Kacheln. Hast du mal mit Lambertus gesprochen, wie es mit Feedback, Last und Hardware bei ihm ausschaut und geschaut, wie teuer die nötige Hardware wäre? Leider nein, ich hatte gestern Abend keine Zeit mehr dafür. Ich hoffe ich komme heute noch dazu, einige Anbieter anzuschreiben. Mag jemand von euch vielliecht noch ein bisschen die Wikiseite füllen? Genug Alternativen mit pros und cons haben wir ja hier inzwischen durchgekaut. Lambertus hat sich auf meine Mail auf mkgmap-dev gemeldet. Sein deutsch (und Google Translate) reicht nicht ganz aus, um alles zu verstehen. Ich werde es ihm (und evtl. auch einigen anderen, die dort mitlesen) mal etwas zusammenfassen. Es lohnt ja nicht hier tolle Ideen auszugraben um dann festzustellen, dass das über Spenden nicht finanzierbar ist. Ich fürchte, so wird es kommen. Aber ich denke, das Konzept skaliert recht gut und mit schwächerer Hardware können wir immer über längere Wartezeit gegensteuern. Das Spendenaufkommen kann ich eigentlich gar nicht abschätzen, deswegen wäre es wichtig, überhaupt erst einmal etwas Prototypenhaftes aufzusetzen. Von vorrauseilendem Pessimusmus halte ich nämlich auch nix. So war das auch nicht gemeint. Ich hab von der Serverwelt kaum Ahnung. Ich kann grob Abschätzen, was ein Desktop kosten würde, mit dem man fix Karten rechnen kann. Ich hab aber keine Ahnung, was man beim Server an Zusatz (Anbindung, etc.) braucht, worauf man beim Preis achten muss etc. Von daher kann ich auch nicht abschätzen, ob man nun 50€ im Monat einnehmen muss oder 500€. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 05.07.2012 13:01, schrieb Peter Wendorff: Soweit ich das in Erinnerung habe, gibt es mehrere Grenzen: 1) Größe der Karte insgesamt - relativ stark begrenzt, das wurde bei der AIO immer mal wieder zum Problem 2) Größe einzelner Kacheln innerhalb der Datei: Eine Kachel kann eine beliebig große geographische Region abdecken, aber nur eine bestimmte Anzahl an Objekten enthalten 3) Anzahl der Kacheln in einer Karte. Begrenzt ist die Kachelgröße über die Anzahl der Objekte darin. Das ist die einzige Beschränkung aus dem Format, wenn man mal die Genauigkeit und die Anzahl der verschiedenen Objekte außen vor lässt. Die anderen Beschränkungen verursachen die Handgeräte. Diese schlucken nur FAT32, ergo maximal 4gb je Datei. Weiterhin ist die maximale Anzahl aller Kacheln auf einem Gerät auf ~4000 beschränkt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hallo Rainer, da bin ich mir nicht so sicher. Sicherlich radeln die meisten auf dem Gerät via Tracks, die vorher geplant wurden. Meine Erfahrung ist aber eher, dass diese Tracks primär übers Routing erstellt werden. Das ist einfach viel schneller, als alle 20m einen Mausklick zu machen. Diese Route wird dann in einen Track umgewandelt und auf das Gerät geschickt. Unterwegs findet dann primär Umleitungssuche oder Unterkunftssuche statt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hier die Antwort von Lambertus: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q3/014710.html Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 09:40, schrieb Ronnie Soak: Am 4. Juli 2012 09:09 schrieb Carsten Schwede computerte...@gmx.de: Am wichtigsten würde ich finden, daß endlich einen vernünftige Verlinkung oder meinetwegen eineeigene Seite bei osm.de erstellt wird, wo die ganzen Kartenpakete z.B. tabellarisch abrufbar sind, meinetwegen mit einer Bedienungsanleitung für die Verwendung der Fertigpakete (also auf die Speicherkarte und fertig) Das hatten wir schon mal in alten Threads und am Anfang dieser Diskussion: Wir können in der Tabelle jeweils nur die Hauptseite der Kartenanbieter angeben, keine Deeplinks zu den Karten (weil sonst zu fragil, Werbe-/Spendenumgehung, heterogene Struktur etc..) Damit sind wir nicht weiter als die Tabelle im Wiki. Man wäre meiner Meinung nach damit schon weiter. Weil man dem Nutzer eine Filterung anbieten könnte und eine begrenzte Vorschau. Wenn der User Fahrradkarten für Dänemark sucht, dann bleibt aus der langen Liste des wikis noch 4-5 Karten über, die er in einer Liste zu sehen bekommt. Derzeit im wiki muss man erstmal für Dänemark an 4 Stellen suchen (Worldwide, Europe, several Countries in Europe und Single Countries) und dann auf der entsprechenden Seite nach Infos suchen, ob es überhaupt eine Radkarte ist, für welche Räder sie gemacht ist usw. Ich denke jedoch, das man erstmal ein paar mehr Entwickler von Karten fragen sollte, wofür sie bereit sind und dann schauen sollte, ob ein Hackweekend sinnvoll ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Projekt. War: Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 09:07, schrieb Ronnie Soak: Also ich würde schon mal das Ausfindig-machen der bisherigen Garminbastler und das Anfragen übernehmen. Am Wiki arbeite ich auch gern mit. Für Softwareentwicklung im Bereich serverseitige Dienste bin ich leider ungeeignet. Ich hab auf mkgmap-dev mal auf diese Diskussion hingewiesen. Ich denke dort lesen alle größeren Entwickler mit. Evtl. wäre es auch sinnvoll, die Diskussion international durchzuführen? Allgemein wäre ich auch bei einem Hackweekend dabei. Kommt halt drauf an, ob es für einen Kartenentwickler sinnvoll ist, oder ob eher Webentwickler etc. gefragt sind. Anreise und Unterkunft ist ja auch nicht ohne für den Geldbeutel, da wäre es dann blöd, wenn man nicht wirklich mitarbeiten kann. In jedem Fall stehe ich aber dann via Skype für Fragen zur Verfügung. Henning Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 12:15, schrieb Florian Lohoff: On Tue, Jul 03, 2012 at 04:24:43PM +0200, Ronnie Soak wrote: Am 3. Juli 2012 15:48 schrieb aighes o...@aighes.de: Mit einer guten, neutralen Übersichtsseite, die dann auf die Downloadseiten verlinkt hat sicher keiner ein Problem. Dennoch würde ich eine Listung dort freiwillig für den Anbieter machen. Denn man sollte nicht unterschätzen, welcher Traffic erzeugt wird, wenn genug Leute die Karten laden. Damit muss dann das Projekt auch klar kommen. Ebenso sollte man bedenken, dass viele der Projekte nur laufen können, weil sie Spenden bekommen. Von daher sollte man auch nicht einfach die Downloads direkt verlinken. Ich denke, es ist schon fair, wenn man den Weg unterstützt, den der Anbieter vorsieht oder die Karte eben nicht listet. Ja, das waren in etwa so die Argumente aus den vorherigen Diskussionen: - man darf den Leuten den Traffic nicht wegnehmen, wegen Werbe-/Spendenfinanzierung - man darf den Leuten nicht mehr Traffic schicken, wegen Begrenzungen - eine Übersichtsseite mit Direktlinks ist beinahe unmöglich, wegen der extrem heterogenen und auch noch instabilen Organisationsstruktur der Kartennabieter Also hier kann man ja durchaus mal automatisiert torrents erzeugen und den direktdownload erst nach 48 Stunden ermoeglichen - dann hat man eine menge traffic gespart - Ich habe da auch kein problem mit wenn man sich da einigt das durch aktive seeder die automatisch neue torrents holen zu unterstuetzen. Bei Torrents sehe ich zwei Probleme: Lohnt sich für kleinere/upopuläre Karten nicht wirklich. Aber die kann man dann ja raus nehmen und nur die großen/populären Karten auf torrent-Basis verteilen. Torrent ist bei den Leuten, die in der Regel das Problem haben, über das wir reden, mit illegalem Herunterladen assoziiert. Sprich ob sie das Angebot nutzen ist sehr fraglich. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 13:12, schrieb Florian Lohoff: On Wed, Jul 04, 2012 at 12:51:40PM +0200, Carsten Schwede wrote: Ich habe torrents eine Zeitlang mit angeboten, hat gar nicht funktioniert, da durch den geringen Traffic alles veraltet war und sich keine Userbasis aufbauen konnte. Wir wollen ja das Problem mit dem Traffic loesen und da muss man die leute zwingen sowas zu benutzen - deshalb ja die idee das man die daten im direktdownload erst 24-48 Stunden spaeter anbietet ... Hallo Florian, die Nutzer wollen nicht unbedingt die aktuellen Daten. Vielen ist auch nicht wirklich bewusst, das sich die Daten groß ändern. Bspw. wurde ich gefragt, ob ich nicht einen Changelog schreiben könnte, was sich von einer Version zur nächsten ändert. Es gibt auch diverse Nutzer, die noch mit der Radfahrer-Karte von vor 2 Jahren durch die Gegend radeln. Aktuelle Daten (bezogen auf Tage) wollen egtl. nur die Mapper, die ihre Änderungen sehen/nutzen wollen. Ich würde den Traffic auch erstmal nicht als zentrales Problem betrachten. Man sollte halt den Herausgeber fragen, ob bei so einer Übersicht seine Karte genannt werden soll, oder ob ihm das recht ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hallo, Mal ein paar Zahlen zu einer Karte. Meine Deutschlandkarte besteht zur Zeit aus 155 Kacheln. Dabei arbeite ich mit statischen Kachelgrenzen. Sprich ich rechne die einmal mit einem zurecht geschnittenen Extrakt aus und lass den splitter dann direkt aus dem planet ausschneiden. Das dauert rund 1:05 h für alle meine Karten (~630 Kacheln). mkgmap dürfte kaum noch Zeit verlieren durch das aussortieren von Tags. Genaueres müsste man auf mkgmap-dev erfragen, das ist aber schon recht weit optimiert worden. Sinnvoll nutzbar wäre die Overpass-API, wenn sie direkt die Kacheln liefert. Idealerweise als pbf, mit xml ist mkgmap 5-7mal langsamer. Und die Frage ist: Ist das von der Last her sinnvoll. splitter erzeugt recht wenig Last und der RAM-Verbrauch hält sich sehr in Grenzen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 14:10, schrieb Ronnie Soak: Sinnvoll nutzbar wäre die Overpass-API, wenn sie direkt die Kacheln liefert. Idealerweise als pbf, mit xml ist mkgmap 5-7mal langsamer. Und die Frage ist: Ist das von der Last her sinnvoll. splitter erzeugt recht wenig Last und der RAM-Verbrauch hält sich sehr in Grenzen. Wenn die (CPU?) Last gering ist und auch der RAM nicht voll, dann wird I/O die Grenze sein, an der er sich 1h aufhält. Da kann ich mir schon vorstellen, das ein vorgefiltertes .osm (ich schätze mal 50% der Originalgrösse) was bringt. Allerdings hast du recht, dass wir von der API nur XML bekommen. Wenn pbf wirklich so viel schneller ist, werden wir nichts gewinnen, wenn wir in der Toolchain noch eine Umwandlung haben. Gilt das 5-7x auch für splitter? Hallo, primär kommt der Unterschied ja aus der I/O-Bremse. Bei xml muss deutlich mehr eingelesen werden. Die Zahlen stammen aus der Zeit, als splitter und mkgmap pbf gelernt haben. Wenn ich mich recht erinnere beziehen sie sich nur auf splitter, der ja primär Daten schaufelt. Bei mkgmap ist das Einlesen nur ein Teil der Arbeit. Hier sollte es etwas weniger werden. Aber es ist schon deutlich schneller ein pbf einzulesen als ein xml. Was mir noch eingefallen ist: Sinnvoll ist der Weg über die OverpassAPI natürlich nur, wenn das über schnelles LAN angebunden ist oder auf dem gleichen Server läuft und ob dann die OverpassAPI schneller ist als osmfilter bzw. mkgmap intern würde ich erstmal verneinen. Aber wenn du es testen willst nur zu. Wäre ja mal interessant zu wissen, wie es wirklich ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 14:43, schrieb Sven Geggus: aighes o...@aighes.de wrote: Das Problem ist nicht, dass es keine aktuelle Vielfalt gibt, sondern dass die Nutzer diese Vielfalt anscheinend nicht finden. Es ist ein Problem, dass die Vielfalt nicht konsistent ist. Viele Karten gibt es halt nur für wenige Regionen. Was durchaus auch nicht verkehrt ist. Schließlich weiß der lokale Ersteller in der Regel am besten, wie er die Daten für die Region interpretieren sollte. ;-) In speziellen Fällen hilft auch das Anschreiben des Erstellers. Wenn es unbedingt die RadReiseKarte für die Reise nach Grönland sein soll, dann hab ich damit auch kein Problem, die einmalig mitzurendern, solange es nicht überhand nimmt. Ein weiteres Problem ist, dass man den Karten häufig ansieht ob das Kartenbild eher für Geräte mit kleinem Display oder für Geräte mit großem Display optimiert ist. Wobei man dies mit einem anderen TYP-File simpel ändern kann. Da könnte ein WebGUI auch helfen indem es die Angabe eines Gerätes ermöglicht. Genau. Diverse Filtermöglichkeiten wären denkbar. Es sollte halt verständlich bleiben. Vieles kann man auch mit Icons erschlagen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 14:29, schrieb Sven Geggus: aighes o...@aighes.de wrote: Die Toolchain ist in der Regel einheitlich bzw. ähnlich. Wobei es natürlich schon Unterschiede gibt. AFAIK ist das nicht so einfach, weil jeder Garminkartenstil eine Andere Zuordnung der osm Typen zu Garmintypen verrwendet. Dadurch sind TYP-Dateien leider nicht von einer Karte auf die andere übertragbar. Die Toolchain ist schon einheitlich. osmupdate/osmosis zum updaten eines planets oder aktuelles Extrakt herunterladen - einfach zu vereinheitlichen splitten der Kacheln mit splitter - hier müsste man sich dann einigen, dass bspw. alle Deutschlandkarten die selben Kacheln nehmen mkgmap ist von Karte zu Karte unterschiedlich. Daran kann man nichts ändern. Ebenso die TYP-Files. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 16:30, schrieb Ronnie Soak: Also ICH sag das schon. Meiner Meinung nach ist der Komfortgewinn gegen eine Wikiliste nur unwesentlich, wenn hinter dem Link wieder bunte Seiten mit unterschiedlichen Bedienkonzepten stecken. Ich habe weniger den Eindruck, dass es daran scheitert, die ausgewählte Karte herunterzuladen. Sondern eher daran, die Karte überhaupt zu finden und das könnte man mit einem prominent verlinkten Portal prima lösen. Die bisherige Wiki-Seite hat zwei Probleme. Zum einen ist sie unübersichtlich und zum anderen findet man sie kaum. Zur weltweiten Abdeckung einer Karte: Das ist nicht immer sinnvoll. Bspw. weil die Straßenverhältnisse global sehr unterschiedlich sind und sich das leider nicht immer in den Tags widerspiegelt. Eine primary in Afrika sieht anders aus als hier bei uns, ist aber vollkommen richtig als primary getagt, sollte aber anders behandelt werden. Beim erstellen einer Karte trifft man gewisse Annahmen, weil Objekte in der Regel nicht vollständig getagt sind. Diese Annahmen sind aber eher regional gültig. Das global sinnvoll in ein Style-File zu bringen ist nicht trivial. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
