Re: [Talk-de] Night of the living maps 07.02.2012 - Globale virtuelle Mapping Party
Hallo, ich weiß nicht, ob's schon erwähnt worden ist, aber netzpolitik.org hat berichtet: http://netzpolitik.org/2012/openstreetmaps-karten-zum-leben-erwecken/ Grüße ant On 27.01.2012 09:33, Matthias Meißer wrote: Hallo Community, schon seit einigen Wochen ist eine Idee für eine Aktion gereift, die wir heute vorstellen wollen: www.nightofthelivingmaps.org Am Mittwoch, den 07.02.2012 wollen wir probieren gemeinsam eine ganze Nacht lang für unser Projekt Luftbilder abzupausen und zwar genau dort, wo wir bisher noch schwach aufgestellt sind: im ländlichen Raum, jenseits der großen Städte eures Bundeslandes. Bisher gibt es leider nicht so viele größere Events bei OSM, vielleicht können wir das mit dieser LAN-Party ja ändern? Daher wollen wir euch bitten, doch mal bei euren lokalen Mappern zu fragen, ob ihr nicht selber solch eine kleine lokale Party auf die Beine stellen wollt. Das ist nicht viel Aufwand und in der Regel kriegt man über Unis/Hackerspaces/Stadt/... kostenlos auch einen Raum. Der FOSSGIS hat ein wenig Geld bereitgestellt, damit ihr euch mit ein paar Snacks versorgen könnt und mit Kaffee das ganze auch durchhaltet ;) Eure Edits ladet bitte mit einem Kommentar, der mit #notlm ... beginnt hoch, damit wir da später ein schönes Video davon machen können und auch mal beobachten können, wo gerade gearbeitet wird. Auch wenn es nicht unmittelbares Ziel ist, für OSM zu werben und Neulinge zu rekrutieren (wir wollen ja was schaffen ;)), wäre es natürlich super, wenn ihr probiert das vor Ort bei euch ein wenig bekannt zu machen. Flyer sowie Social Media findet ihr auf der Seite/könnt ihr für alle hier hochladen: http://wiki.openstreetmap.org/wiki/Night_of_the_living_maps/promotion http://www.facebook.com/pages/Night-of-the-living-maps/163865540386200 https://twitter.com/NightOfTheMap Wir würden uns auch sehr freuen, wenn vielleicht der ein oder andere die Wikiseite übersetzen könnte, oder sich vielleicht daran macht Statistiken oder Animationen vorzubereiten. Wir sind uns natürlich bewusst, dass bingen nicht unumstritten ist, dennoch sind wir der Meinung, dass in diesem Fall die Vorteile überwiegen (siehe Hinweise im Wiki). Eine definitive Antwort, ob das gut oder schlecht ist, scheint es bisher nicht zu geben und die wird es besten Falls, wohl erst in ein paar Jahren geben, wenn wir zurückblicken. Also lasst uns einfach das machen, was wir am besten können: Zusammen eine richtig gute Karte erstellen :) Gruß Matthias (user:!i!) ___ 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] Bilder dauerhaft lagern
Hi Stefan, Am 25.11.2011 14:07, schrieb Stefan Kopetzky: Das Haben Wollen wenn ich an ein zentrales Bilder-Repository f. OSM denke, sieht in etwa so aus: Nutzer können Fotos, die fürs Mappen relevant (incl. Zeitstempel, Geo-Tagging) sind über eine Webplattform speichern (katalogisieren, taggen etc.) und anderen zur Verfügung stellen. Im jeweiligen Editor könnte man dann eine Ebene mit allen (oder evtl. einer Submenge, nach div. Filterkriterien) Fotos im konkreten Ausschnitt einblenden und ein Klick aufs Icon öffnet das Bild. Technisch halt ich das jetzt nicht für so kompliziert. Aufwendig wird vermutlich die Serververwaltung in Hinblick auf Platzverbrauch und Performance. Wenn Interesse an so einem Dienst besteht würd ich mich im Winter dranmachen und einen Prototypen hinklotzen. ich fände das klasse - sitze nämlich auf einem Haufen Tracklogs mit Fotos, die ausgewertet werden wollen. Gäbe es so einen Service, könnte ich die einfach hochladen und sagen: Happy mapping... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ikea-Besuch: Defibrator-Mappen
Hi, wie mappst du sowas? In der Münchener U-Bahn gibt's die Dinger nämlich auch... Grüße ant Am 17.11.2011 11:40, schrieb Jan Tappenbeck: hi ! habe gerade bei IKEA HH Moorburg beim Kundenservice (Express) einen Defi gesehen. Da IKEA alles einheitlich ist vermute ich das dieses auch bei anderen Stores so ist - also vielleicht könnt Ihr beim nächsten Besuch mal darauf achten. Wäre also fast 50 mehr. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mal wieder eine maxpeed-Frage
Am 10/21/2011 07:11 PM, schrieb Chris66: Am 21.10.2011 18:59, schrieb Christian H. Bruhn: Es verstößt nicht nur gegen den gesunden Menschenverstand diese Geschwindigkeit zu fahren, sofern es überhaupt möglich ist, sondern der §3 Abs.1 STVO setzt diese setzt dem Ganzen mit den Sätzen 2 [1] und 4 und 5 [2] auch rechtliche Grenzen. Ich persönlich habe Bauchschmerzen auf solchen Wegen ein 'maxspeed=100' zu setzen, weil es etwas etwas vortäuscht, was so nicht machbar ist. Was sollte man stattdessen taggen? Entweder gar nicht oder maxspeed:practical. Chris -1 maxspeed=100 ist korrekt und sollte so getaggt werden. Hilfreich fürs Routing wären jedoch zusätzliche Tags wie surface, smoothness, width, incline, etc. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fussgaengerampeln
Hallo, Am 10/20/2011 10:17 PM, schrieb Michael Neumann: Hallo, wenn ich das im Wiki richtig verstehe, wird eine Fussgaengerampel nur mit highway=crossing und crossing=traffic_signals aber *nicht* mit highway=traffic_signals getaggt, korrekt? Das wird bei Mapnik und Osmarender aber leider nicht gerendert. Ich habe schon einige Fussgaengerampeln in OSM gesehen, wo zusaetzlich highway=traffic_signals gesetzt wurde, dann bekommt man auch ein schoenes Icon gerendert :-) Was meint ihr? Ich meine, wenn ich als Fussgaenger eine Ampel habe, dann haben die Autofahrer doch logischerweise auch eine?! das Tag crossing=traffic_signals würde als eine Kategorie von Fußgängerquerungen auffassen - neben Zebrastreifen etc. highway=traffic_signals hat damit nichts zu tun, weil es an Straßenkreuzungen verwendet wird. Daher ist es meiner Ansicht nach unnötig, Fußgängerampeln mit beiden Tags zu versehen. Denn dass sich an einer Querung mit crossing=traffic_signals auch für Autofahrer eine Ampel befindet, ist, wie du richtig erkannt hast, eine logische Schlussfolgerung :) Grüße ant Danke und Gruss ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMs Gedächnis
Am 10/17/2011 07:18 PM, schrieb malenki: Nicht ganz falsch, was du da sagst. Wenn mir etwas besseres einfällt/ über den Weg läuft, werde ich das ändern. Evtl einfach for_rent=shop nehmen? Und woher wissen, ob ein leer stehender Laden zu vermieten ist? Vielleicht will der Eigentümer lieber verkaufen... Es gibt noch dies hier: http://wiki.openstreetmap.org/wiki/Tag:shop%3Dvacant ant malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gemeindedaten aus OpenGeoDB
Hallo zusammen, mir ist gerade aufgefallen, dass vielerorts (zumindest im Landkreis Stade) Gemeindedaten aus OpenGeoDB an place-Nodes drangepappt worden sind, meist Dörfer, die den Namen der Gemeinde tragen. Das erscheint mir etwas unglücklich. Soll wohl eine Übergangslösung sein? Jedenfalls war das Dorf Jork im Alten Land, Ortsteil der Gemeinde Jork, fälschlicherweise als place=town getaggt - vermutlich aufgrund von openGeoDB:population=11706, was sich natürlich auf die gesamte Gemeinde bezieht... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Hallo, Am 09/11/2011 02:26 PM, schrieb Peter Wendorff: Die Nutzung der Daten ist dagegen aber leider so extrem facettenreich, dass es einfach nicht genug Interessenten gibt, um eine benutzerfreundliche Lösung in einer Facette so weit voranzubringen. das sehe ich nur eingeschränkt so. Eine Facette im Sinne von ich möchte nur die Siedlungsflächen oder ich möchte nur 24h-Tankstellen in Soundso-Land lässt sich meistens in eine Kombination aus Tags und umschließenden Polygonen übersetzen. Damit ist im Grunde jedes Export-Tool parametrisierbar. Ein benutzungsfreundliches Export-Tool, das diese Parametrisierung beherrscht, würde schon vielen helfen. Es gibt Nischen, in denen das ja schon passiert: - Die Geofabrik-Extrakte bedienen alle, die einfach nur Ausschnitte für bestimmte Länder brauchen - diverse Garmin-Karten bedienen zwar mit vorgegebener Auswahl, aber doch die Gruppe der Garmin-Nutzer - Der Export von Bildern als SVG oder Rastergrafik direkt auf der Webseite bedient Grafiker, Layouter oder sonstwen, der einfach mal eben ein Kartenbild braucht. - Nominatim etc. bedienen alle, die nur mal nachschlagen wollen, wo Hintertupfingen liegt. Eine All-in-one-Lösung wäre aber auch schön! Wenn Du nun argumentierst, du könntest da nicht helfen, dann stelle ich, ohne mich damit als Programmierer direkt anbieten zu können, doch einfach mal die Frage zurück, die nämlich keine Programmierkenntnisse voraussetzt: Wie sollte denn die Exportmöglichkeit (als Programm, Web-Schnittstelle oder was auch immer) aussehen, die du dir vorstellst? Gute Frage! Mir schwebt in etwa Folgendes vor: Ein Web-Interface oder Programm mit GUI, in dem ich ein Rechteck oder Polygon über eine Karte ziehe und sage, welche Daten (Tags) ich möchte. Das Programm holt für mich die Daten und filtert sie, wandelt sie ggf. um, und dann kann ich damit tun, was ich möchte (z.B. in QGIS laden oder in eine DB importieren). Weil die Probleme aber schon beim Holen der Daten anfangen (XAPI down, Länderextrakte zu groß oder zu klein usw. usf.), arbeite ich weiterhin an der Generierung von Tiles von OSM-Daten, die als Grundlage für ein solches Export-Tool dienen könnten. (Beim OSM-Camp in Nürnberg werde ich vielleicht schon etwas zeigen können.) Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exportmöglichkeiten, war: Siedlungsflächen exportieren
Moin, Am 09/11/2011 06:25 PM, schrieb Peter Wendorff: Das stimmt, aber ob dieses Tool benutzungsfreundlich für nicht-techniker bleiben kann, die sich auch nicht mit dem tagging-schema in allen Varianten auseinandersetzen wollen oder können, bezweifle ich. Osmosis wird durch osmembrane schon ziemlich benutzerfreundlich, finde ich. Trotzdem muss der Nutzer immer noch ein natürlich sprachlich formuliertes Problem irgendwie in die Filter umsetzen. wenn ich in Potlatch ein Restaurant eintragen will, klicke ich auf das Symbol mit Messer und Gabel und fertig. Das kommt der sprachlich formulierten Aufgabe schon sehr nahe. Wer dennoch spezielle Tags eintragen möchte, klickt auf Advanced und tippt Schlüssel und Wert ein. Dieses Konzept lässt sich auf beliebige Anwendungen übertragen. Bei einer guten Export-GUI müsste ein Datennutzer nicht unbedingt wissen, welche Tools im Hintergrund die Arbeit machen, welche Entity Streams wie gefiltert werden usw. Im Übrigen geht es mir nicht primär um die Tags - ich gehe davon aus, dass ein potenzieller Nutzer der Daten weiß, an welchen Tags er interessiert ist. Anders sieht es jedoch bei der Kenntnis der Kommandozeilentools - die nötig ist, um OSM-Daten nutzbar zu machen - aus. Klar, man könnte eine Datenbank von pipelines anbieten, die häufige Aufgaben einfach abrufbar macht ((warum) gibt's das eigentlich noch nicht?). Aber es wird immer wieder Anfragen geben, die in dem Katalog nicht da sind, oder Facetten, die eben anders interpretiert werden könnten. Gehören Verkehrsflächen jetzt zu den Wohngebieten dazu oder nicht? Gehören Treppen zu den Wegen oder nicht? Wenn man sich mit den Tags selbst auseinandersetzen will/kann, dann gibt es die entsprechenden Tools. Wenn nur eine Frage in natürlicher Sprache vorliegt, wird kein Tool im Allgemeinen die Antwort liefern können. Um beim Potlatch-Bild zu bleiben: Simple hieße bei unserem Tool nunmehr Tag-Kombinationen eingeben, Bbox ziehen und Enter drücken; advanced hieße, bei Bedarf die Prozess-Pipeline an den gewünschten Stellen manipulieren zu können. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage bez. Kacheln
oh ja stimmt, habe osmosis 0.34 aus dem Debian-Paket benutzt, ohne es zu merken... Grüße ant On 07.09.2011 10:49, Lars Schimmer wrote: On 2011-09-06 19:04, ant wrote: On 06.09.2011 18:27, ant wrote: osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted --read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm Nochmal schnell nachgebessert: mit conflictResolutionMethod=timestamp kannst du verhindern, dass Original-Nodes durch Fremdkachel-Nodes überschrieben werden: osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted --read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge conflictResolutionMethod=timestamp inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm Hm, das Osmosis 0.39 meckert da aber fleissig: task type read-xml-0.5 not existant task type --migrate not existant... Grüße ant MfG, Lars Schimmer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage bez. Kacheln
Hallo, On 07.09.2011 11:29, Lars Schimmer wrote: Und die Tiles von Computerteddy/ oder die SRTM Teiles sind kein 0.6 API: SEVERE: Thread for task 1-read-xml failed org.openstreetmap.osmosis.core.OsmosisRuntimeException: Node 20 does not have a version attribute as OSM 0.6 are required to have. Is this a 0.5 file? Sep 7, 2011 11:28:24 AM org.openstreetmap.osmosis.core.pipeline.common.ActiveTaskManager waitForCompletion SEVERE: Thread for task 3-read-xml failed org.openstreetmap.osmosis.core.OsmosisRuntimeException: Node 150542520 does not have a version attribute as OSM 0.6 are required to have. Is this a 0.5 file? er meckert, weil einige Nodes kein version-Attribut haben. Das Migirieren von 0.5 nach 0.6 ist nur eine Lösung. Alternativ könntest du auch einfach mit dem Texteditor deiner Wahl ein version=1 überall dort einfügen, wo es fehlt, und die Datei damit API-0.6-kompatibel machen... dann sollte osmosis auch still sein. Grüße ant Jetzt muß ich doch nur noch diese beiden joinen und dann ein gmapsupp.img daraus bauen. Ciao Igor MfG, Lars Schimmer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage bez. Kacheln
Moin, On 06.09.2011 15:32, Lars Schimmer wrote: Moin! Ich bin nun wieder ein ein kleines Problemchen angekommen: Wie joine ich die Dateien von Computerteddy zu einer *.osm Datei zusammen? osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted --read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm was evtl. stören könnte, sind Nodes mit Fremd-Kachel = xy Tags, aber die kann man ggf. auch noch rausfiltern. Oder besser: ist es besser, auch die SRTM Daten in 1°x1° liegen zu haben und erst mit mkmap mit den ComputerTeddy Kacheln zusammen zu fügen in eine garmin.img Datei ODER das Gebiet von 5°x5° als eine SRTM *.osm zu haben und die 25 Kacheln von ComputerTeddy zu einer *.OSM Datei zusammen zu bauen und dann die beiden Dateien zusammen zu joinen und dann zu einer .IMG umbauen lassen? Danke. Letzteres könnte problematisch werden, weil mkgmap meckert (oder gar abstürzt?), wenn Eingabedateien eine bestimmte Größe überschreiten... aus diesem Grund gibt's ja die Kacheln. MfG, Lars Schimmer Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage bez. Kacheln
On 06.09.2011 18:27, ant wrote: osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted --read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm Nochmal schnell nachgebessert: mit conflictResolutionMethod=timestamp kannst du verhindern, dass Original-Nodes durch Fremdkachel-Nodes überschrieben werden: osmosis --read-xml-0.5 0001.osm --migrate --sort outPipe.0=1sorted --read-xml-0.5 0002.osm --migrate --sort outPipe.0=2sorted --merge conflictResolutionMethod=timestamp inPipe.0=1sorted inPipe.1=2sorted --write-xml merged.osm Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projektidee: Segmentierung von OSM-Daten
Hallo Frederik, On 07.06.2011 01:29, Frederik Ramm wrote: gerecht würden, und die Verteilung von OSM-Daten über Bittorrent und Co. würde möglich werden, Naja, fuer sich staendig aendernde Daten (selbst wenn sie sich nur taeglich aendern) ist das nicht gerade der beste Verbreitungsweg. Vorallem, wenn man verschiedene Quadrate (nicht unbedingt die ideale Aufteilung) hat, die unterschiedlich alt sind ;) Klar, ich würde erstmal den wöchentlichen Planeten anvisieren und dann mal sehen, ob sich da in Sachen Updates was Schlaues implementieren lässt... Ich möchte mich näher mit dieser Problemstellung auseinandersetzen und meine Frage ist nun: Arbeitet schon irgendjemand daran? Was Du mal studieren koenntest, ist TRAPI, da werden die OSM-Daten auf der Platte in solchen Segmenten abgelegt, so dass man sehr schnell ein bestimmtes Rechteck runterladen kann. Der Knackpunkt bei TRAPI ist, dass auch ein differentielles Update auf diese verteilte Plattenstruktur aufgespielt werden kann, d.h. man kann praktisch minutenaktuelle Rechtecke anbieten und muss nicht einmal am Tag den kompletten Planeten zerhacken. Danke für den Hinweis, werde ich mir anschauen! Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Projektidee: Segmentierung von OSM-Daten
Hallo, ich werde in Kürze beginnen meine Bachelorarbeit zu schreiben und visiere ein OSM-Thema an. Ich habe mich da mittlerweile auf etwas eingeschossen, das unter den Projektideen im Wiki gelistet ist und wozu es auch einen Forum-Thread gibt: http://wiki.openstreetmap.org/wiki/GSoC_Project_Ideas_2011#Vector_data_squares_containing_SVG_objects http://forum.openstreetmap.org/viewtopic.php?id=11699 Die Idee, OSM-Daten in Chunks - oder Segmente, wie ich es nennen würde - aufzuteilen, ist großartig. Mit den Segmenten ließen sich Extrakte zusammenbasteln, die den verschiedenen Anforderungen an Größe und Umfang gerecht würden, und die Verteilung von OSM-Daten über Bittorrent und Co. würde möglich werden, ohne dass irgendjemand dafür den gesamten Planeten herunterladen müsste. Voraussetzung dafür ist natürlich ein reibungsloses Splitten und Zusammensetzen der Quadrate. Ich möchte mich näher mit dieser Problemstellung auseinandersetzen und meine Frage ist nun: Arbeitet schon irgendjemand daran? Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Funkmasten in SH - geheim und jeder kann es lesen
On 08.03.2011 15:13, Sven Geggus wrote: Jan Tappenbecko...@tappenbeck.net wrote: Die dürfen wir nicht bekommen weil diese geheim sind - siehe Bauschild - stehen dort wegen möglicher Rettungsdienstanforderungen. Merkwürdige Definition von öffentlich und geheim. Was von öffentlichem Grund aus ohne Hilfsmittel sichtbar ist dürfte wohl schwer als geheim einzustufen sein. Genauso ist es mit Fahrplandaten - hängen an jeder Haltestelle aus, tw. sogar im Internet - aber nen kompletten Datensatz würden die Betreiber niemals rausgeben. Grüße ant Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Funkmasten in SH - geheim und jeder kann es lesen
On 09.03.2011 14:08, Steffen Heinz wrote: Am 09.03.2011 13:45, schrieb ant: Genauso ist es mit Fahrplandaten - hängen an jeder Haltestelle aus, tw. sogar im Internet - aber nen kompletten Datensatz würden die Betreiber niemals rausgeben. ??? hä? krieg ich entweder zu kaufen oder bekomme es in kleinerem Bereich umsonst ins haus, dann gibts nich das Kursbuch Bahn und was weis ich so alles. In gedruckter Form, ja. Oder als PDF. Aber nicht als Datenbankabbild zur freien Verfügung... zugegeben, der Vergleich hinkt ein bisschen. Grüße ant Es gibt mehr als mensch denkt auch im Netz. für NRW (auch andere Bundesländer) gibt es so was wie messtischblätter im Netz, mit Grundstücksgrenzen und Hausumrissen. Ich meine auch vor Jahren mal ne Liste alle Mobilfunkmasten gesehen zu haben Grüße aus der Eifel Steffen ___ 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] Bing als Map-Layer
Hallo, 2011/2/23 Peter Wendorff wendo...@uni-paderborn.de Hi. Am 23.02.2011 17:50, schrieb ant: Hoffe, ich konnte deine Fragen beantworten! Weitgehend, ja. Was mich noch stört ist: woher weiß ich, ob ein höheres Zoomlevel bekannt nicht vorhanden ist oder einfach noch nicht von jemandem aufgerufen wurde? Scrollen in Zoom 20 und höher ist ziemlich unhandlich - und zurecht soll das ja eben nicht automatisch gemacht werden (sonst bräuchte man den analyzer nicht). Als Luftbild-Mapper ist eine grüne Kachel toll: hier gibts tiles zoom 18. Als Nutzer des analyzers heißt das aber noch nichts, denn spannend ist ja die Information, dass es 19 nicht mehr gibt - oder eben, dass das noch nicht bekannt ist. Die Unterscheidung von 19 unbekannt und 19 nicht vorhanden ist die, die mir noch fehlt. Stimmt. Das war ja auch so konzipiert: grün = mindestens Z14 vorhanden, rot = Z14 nicht vorhanden (im Gegensatz zu keine Farbe = unbekannt). Bei den später eingeführten zusätzlichen Farben für Z18 usw. - die von einigen gewünscht worden waren -, gibt es diese Unterscheidung hingegen nicht, denn dafür bräuchten wir je Zoomstufe eine Farbe für mindestens X vorhanden und eine für X nicht vorhanden. Macht dann alles in allem _acht_ Farben. Und das würde vermutlich mehr Verwirrung stiften als hilfreich sein... Grüße ant ;) trotzdem bis dahin ein schönes Tool. Gruß Peter ___ 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] Bing als Map-Layer
Hallo, On 23.02.2011 11:39, Peter Wendorff wrote: Hi ant. Ich hangel mich grad 'n bisschen über die Bing-Luftbilder im bingimageanalyzer, und frage mich, was Du im Hintergrund so speicherst: Wenn das Overlay Farbe x zeigt - heißt das mindestens bis Zoom Y sind Luftbilder vorhanden, oder heißt das nicht mehr als Zoom Y? mindestens bis Zoom Y sind Luftbilder vorhanden Spannend ist ja vor allem das höchste zoomlevel, nicht irgendeins, das vorhanden ist. siehe meine Erklärung unten Insofern zwei kleine Verbesserungsvorschläge: 1) Du schreibst in einer anderen Mail, der analyzer beachte immer die nächsten zwei Kachelstufen. Wenn ich - weil das in benachbarten Gebieten immer die höchste Zoomstufe war - auf Zoom 18 durch die Landschaft scrolle, sehe ich aber nicht, ob da noch mehr ist; entsprechend hab ich auch wenig Motivation, weiter reinzuscrollen. Ein zusätzlicher Hinweis wäre also nicht schlecht, dass noch höhere Auflösungen zur Verfügung stehen (sobald die Software das weiß). Da habe ich mich in jener Mail wohl nicht klar ausgedrückt, also versuche ich es nochmal... es geht hier um zwei verschiedene Dinge: das Erkennen von Luftbildern und das Rendern der farbigen Tiles. Das Erkennen der Luftbilder (und damit auch das Speichern der entsprechenden Farbe) ist flach und passiert immer nur in demjenigen Zoomlevel, in dem man die Karte betrachtet. Wenn du also wissen willst, ob es irgendwo Luftbilder in Zoomstufe 20 gibt, musst du die Karte in Z20 betrachten. Das Rendern hingegen ist derjenige Vorgang, bei dem gespeicherte Farben aus höheren Zoomleveln verarbeitet werden (woraus sonst sollte das Mosaik auch zusammengesetzt werden). Diesbezüglich galt bis vor kurzem, dass zwei weitere Zoomlevel berücksichtigt werden. Vor ein paar Tagen habe ich den Code nochmal überarbeitet, seitdem sind es vier. 2) ein Permalink zu OSM, ohne direkt in Potlatch zu arbeiten, wär schön. Potlatch direkt zu laden, wenn man nicht weiß, was vom Luftbild denn schon auf der Karte ist, ist Zeitverschwendung. Das klingt gut, das werde ich mal umsetzen. (Vielleicht klappt es irgendwann auch mal mit OpenLayers...) Hoffe, ich konnte deine Fragen beantworten! Gruß Peter Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing als Map-Layer - Abdeckung
On 09.02.2011 17:48, Robert S. wrote: Wobei, grün für 14-17 ergibt natürlich eine gewisse Abwärtskompatibilität zur jetztigen Situation. Dann vlt. 2 blautöne - ein satteres blau für die richtig hochauflödenden Bilder. genau... Farbe nachträglich umdeuten kommt nicht so gut. Andererseits bekommt damit das grün natürlich 2 Bedeutungen: - Hier hat noch niemand nach der genauen Zoomstufe geschaut - Hier gibt es nur Bilder mit maximal z17 Richtig, aber diese Ambivalenz besteht ja unabhängig von den gewählten Farben (weil eben nicht unterschieden wird zwischen 14-17 vorhanden, aber mehr nicht und 14-17 vorhanden, evtl. auch mehr). Hat jemand eine Idee, wie man dieses Problem lösen könnte? Zwischen z18 und z19 seh ich ehrlich gesagt nicht so den gewaltigen Unterschied. Und: Vergleich mal z19 in New York mit z19 in Santiago de Chile. Da liegen - aufgrund der unterschiedlichen Schärfe - dann doch Welten dazwischen. Ich sehe jetzt nicht, warum gerade bei dieser Stufe der Unterschied so gering sein soll. Es gilt doch eher allgemein: Ein Luftbild in hoher Qualität in Zoomstufe n ist mindestens genauso gut wie ein Luftbild in schlechterer Qualität in Zoomstufe n+1. Da hast du auch wieder recht. Ich hab jetzt also mal zusätzliche Farben für 18, 19 und 20 aktiviert: http://ant.dev.openstreetmap.org/bingimageanalyzer/ Viel Spaß damit. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing als Map-Layer - Abdeckung
Hallo, On 08.02.2011 00:59, Robert S. wrote: Jepp, einen eigenen Farbton für jede Zoomstufe ab 14 wäre sehr gut. Es macht schon einen Unterschied, ob man bei Zoomstufe 17, 18, 19, 20 oder 20+ mappt. Habe auf Talk einen Vorschlag hierzu gemacht. Eine eigene Farbe für jede Zoomstufe ist unnötig, denn anscheinend sind Luftbilder immer bis einschließlich Zoomstufe 17 vorhanden, wenn sie schon in 14 vorhanden sind. Darüber hinaus gibt's dann noch drei weitere Stufen. Daher mein Vorschlag: Grün wie bisher für Zoomstufe 14-17, dunkelgrün für 18-19, blaugrün für 20 (20 ist der höchste Zoomlevel). Ich könnte es sofort umschalten, will aber vorher noch ein paar Meinungen hierzu einholen. Einen Screenshot (wie es aussehen könnte) füge ich hier auch einmal bei. Und noch eine Kleinigkeit: Verschieb mal das A Very Fury Thing-Symbol mind. 10 Pixel nach oben, z.T. verdeckt es nämlich die Copyrighthinweise (die durchaus zweizeilig seien können). is wech... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing als Map-Layer - Abdeckung
On 09.02.2011 00:30, Robert S. wrote: 2011/2/8 antantof...@gmail.com Habe auf Talk einen Vorschlag hierzu gemacht. Eine eigene Farbe für jede Zoomstufe ist unnötig, denn anscheinend sind Luftbilder immer bis einschließlich Zoomstufe 17 vorhanden, wenn sie schon in 14 vorhanden sind. Darüber hinaus gibt's dann noch drei weitere Stufen. Daher mein Vorschlag: Grün wie bisher für Zoomstufe 14-17, dunkelgrün für 18-19, blaugrün für 20 (20 ist der höchste Zoomlevel). Was ich bisher gefunden habe, sind die maximalen Zoom-Stufen 17, 19 und 20. Aber 18 dürfte es doch bestimmt auch irgendwo geben!? Peking, Kapstadt, Rio de Janeiro Ich fände es gut, wenn in dem Bereich jede Zoomstufe ihren eigenen Code hätte. In diesem Sinne vlt: (14-)17: gelbgrün 18: grün 19: dunkelgrün 20: blaugrün Wobei, grün für 14-17 ergibt natürlich eine gewisse Abwärtskompatibilität zur jetztigen Situation. Dann vlt. 2 blautöne - ein satteres blau für die richtig hochauflödenden Bilder. genau... Farbe nachträglich umdeuten kommt nicht so gut. Zwischen z18 und z19 seh ich ehrlich gesagt nicht so den gewaltigen Unterschied. Und: Vergleich mal z19 in New York mit z19 in Santiago de Chile. Da liegen - aufgrund der unterschiedlichen Schärfe - dann doch Welten dazwischen. Ich weiß jetzt zwar nicht wie die Technik dahinter aussieht, aber vlt. könnte man eine Verknüpfung mit JOSM herstellen, und die maximale Zoomstufe bei den Bing-Hintergrundbildern durch dieses Tool automatisch vorgeben lassen. Dann müssten aber die genauen Zoomstufen gespeichert werden. Hmm... das sollte JOSM doch wohl alleine hinkriegen... Und noch ein Vorschlag: Unter edit in potlatch2 einen JOSM-RemoteControl-Link. Einen Screenshot (wie es aussehen könnte) füge ich hier auch einmal bei. kam nicht an... http://img694.imageshack.us/img694/3289/binganalyzerzoomlevels.jpg Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing als Map-Layer
Hallo, On 07.02.2011 13:24, Markus wrote: PS: wo finde ich eine Weltkarte mit den Auflösungen der Bing-Bilder? Hier findet man zwar die Stufen, aber erst wenn man weit reinzoomt, aber keine Übersicht: http://mvexel.dev.openstreetmap.org/bing/ und das ist nur für DK: http://wiki.openstreetmap.org/wiki/da:Bing gerade neu: http://ant.dev.openstreetmap.org/bingimageanalyzer/ grün = hochauflösend rot = nicht hochauflösend Um ein Gebiet zu rendern, muss man bis Zoomlevel 14 (oder weiter) reinzoomen, dann färbt sich die Karte. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing als Map-Layer
Hallo, On 07.02.2011 17:47, Frederik Ramm wrote: Hab grade wie wild in einem Gebiet rumgesurft auf z14, das halb rot und halb gruen war. Dann wieder rausgezoomt in der Hoffnung, nun meine Spuren auf einer uebersichtlichen Karte zu sehen, aber keine Resultate. Funktionirt das Speichern evtl. grad nicht? es funktioniert nur dann, wenn man langsam rauszoomt, denn die Neuberechnung der Kacheln beachtet immer nur die in den zwei nächsten Zoomstufen vorhandenen Kacheln (damit die Rechenlast nicht zu groß wird). Wenn auch das nicht klappt, kann ein Neuladen der Seite helfen. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing als Map-Layer - Abdeckung
Hallo, On 07.02.2011 18:30, Markus wrote: Weiss jemand die Auflösung von rot/grün/Rest ? im Augenblick steht grün für Luftbilder auf Zoomstufe 14 vorhanden, rot ist dessen Verneinung. Der Rest ist schlicht nicht geprüft. Auf Talk wurde nun der Wunsch nach feineren Abstufungen (z18, z20) geäußert, dem ich hoffentlich bald nachkommen werde... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
Hallo, On 25.01.2011 14:07, Henning Scholland wrote: Solange der Radweg auf einem straßenbegleitenden Radweg verläuft, nehme ich egtl. immer die Straße in die Relation und nicht den Radweg, eben weil dieser egtl. ein oneway sein müsste und ich keine Lust auf doppelte Arbeit hab. Wenn der Radweg für beide Richtungen freigegeben ist, dann kommt die Relation auf den Radweg. wenn die Radwege eingetragen sind, würde ich dem auch Tribut zollen, indem ich die Radrouten auf diese lege. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
On 25.01.2011 14:33, Falk Zscheile wrote: Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? Ja, wobei forward bzw. backward die Beziehung zwischen der Richtung des Weges und der Richtung der Route angeben (forward, wenn Wegrichtung = Routenverlauf, backward, wenn Wegrichtung != Routenverlauf). Beispiel: http://www.openstreetmap.org/?lat=51.8lon=0.89395zoom=17layers=00B0FTF Dieses Konzept wird leider häufig falsch verstanden und daher z.B. bei Busrouten immer seltener benutzt. Die Alternativen sind: a) auf die Richtungsunterscheidung ganz verzichten b) separate Relationen für die Routen A-B und B-A anlegen. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rasweg
On 25.01.2011 17:47, Manuel Reimer wrote: Falk Zscheile wrote: Gab es für solche Fälle (wenn Hin- und Rückweg über unterschiedliche Straßen führen) nicht die Möglichkeit den Elementen einer Relation Rollen wie forward und backward zuzuweisen? Setzt voraus, dass die Relation sortiert ist Wieso? Ein Sortieralgorithmus würde dann nach zwei Lösungen suchen: eine für den Pfad A-B und eine für den Pfad B-A (eine Kante muss in jeder der beiden Sortierungen enthalten sein, es sei denn, sie hat die Rolle forward oder backward, dann muss sie in genau einer Sortierung enthalten sein). Schwierig wird's jedoch bei Radrundwegen... und zumindest ich mache mir den Aufwand nicht. Relationen, die ich anlege, sind generell unsortiert. Gruß Manuel Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
Hallo, On 17.01.2011 00:42, Garry wrote: Hallo Ant, Hauptanwendung von maxspeed ist eine eindeutige, verlässliche Angabe für Navis/Geschwindigkeitswarner etc bzgl der zul. Höchsgeschwindigkeit beruhend auf einem leicht auszuwertenden Zahlenwert zu haben. Das habe ich auch nie in Frage gestellt. Es macht keinen Sinn eine einfache Erfassungsmöglichkeit durch Polygondefinitionen statt Einzeltags zu schaffen wenn man die dadurch geschaffenen Fehlerquellen nicht einfach erkennen und beheben kann. Was ich angeregt habe, soll ja auch keinen Ersatz für den normalen Gebrauch des maxspeed-Tags darstellen. Ich versuche nur zum Nachdenken darüber anzuregen, ob die massenweise Verwendung der source:maxspeed-Tags eine so gute Idee ist. Bisher ist dieses Schema ja noch weit davon entfernt, dass es flächendeckend ausgewertet werden kann, und ich dachte, Polygone wären der effektivere und einfachere Weg. Ich könnte sogar noch einen Schritt weiter gehen und sagen: Wir brauchen nichtmal Polygone zu mappen, denn wenn alle Ortseingans-/-ausgangsschilder einer Stadt gemappt sind, kann das Routingprogramm sich dieses Polygon auch selbst zurechtbasteln. Einen Wert maxspeed benötigt man insbesondere dann wenn man Ortsfremd ist und auf eine nicht einschätzbare Konstellation trifft wie eine deutliche Geschwindigkeitseinschränkung auf einer gut ausgebauten Strasse (z.B. Tempo60 auf einer autobahnähnlich ausgebauten Einfallstrasse) oder ausgeschilderte Tempo 70 auf einer Ortsdurchfahrt auf der man wegen der Ortsschilder von 50km/h ausgegangen wäre. Alle diese Sonderfälle, die es sicherlich gibt, haben mit der Diskussion eigentlich nichts zu tun, weil sie ohnehin explizit getaggt werden. In der Schweiz hat übrigens ein Ortschild keine Aussage bzgl. der zul. Geschwindigkeit - hier muss die Geschwindigkeit immer separat ausgeschildert werden. Damit würde eine Polygonlösung schon gleich im nächsten Nachbarland versagen... Heißt das, dass es in der Schweit keine implizite Geschwindigkeitsbegrenzung für Ortschaften gibt? Umso besser, dann brauchen wir dort weder Polygone noch source:maxspeed. Je einfacher, desto besser. Fazit: Die auf den ersten Blick einfach erscheinende Polygon-Lösung für maxspeed-Erfassung bringt mehr Probleme/Falsche Daten als dass sie löst. Wenige, aber genaue Daten helfen hier mehr als eine flächendeckende Erfassung mit vielen Fehlern die schwer auffindbar (warum bekomme ich an dieser Stelle einen falschen Wert angezeigt?) und korrigierbar sind(was muss ich jetzt wo ändern?). Was meinst du mit wenige, aber genaue Daten? Ich finde die praktizierte Methode ziemlich redundant... Ich weise nochmal darauf hin: Es ist nicht meine Absicht, irgendwelche Taggingregeln, die sich gewissermaßen anerkannt sind, abzuschaffen. Die anfängliche Diskussion hierzu habe ich ja anscheinend verpasst. Das ist nicht weiter schlimm, ich störe mich nicht weiter daran. Ich beobachte lediglich eine stark steigende Tagging-Komplexität insbesondere im deutschsprachigen Raum, die die Einsteigshürde für Neulinge anhebt. Da wird man ja mal nachhaken dürfen, ob das denn auch alles so sein muss. Übrigens: Die Debatte um das Public-Transport-Proposal [1] ist ähnlich gelagert. Auch dort würde ich mir eine breitere Beteiligung in der Diskussion wünschen (auch auf Talk-transit, wer mag). Grüße ant [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
On 17.01.2011 03:40, Per wrote: Um nun mit Hilfe eines einfachen Polygons Innerorts zu definieren, müsste man erstmal alle öffentlichen Straßen als solche markieren. Auf Privaten Straßen gilt ja schließlich nicht das Limit 50 km/h sondern unbegrenzt (solange der Besitzer nichts anderes verlangt) Und wenn man schonmal dabei ist owner=public zu taggen kann man auch gleich zone:traffic=DE:rural taggen... owner=public erschließt sich mir schonmal leichter als zone:traffic=DE:rural. Besser noch: den Spieß umdrehen und owner=private taggen, alles andere impliziert dann owner=public. Ich glaube, manche wollen einfach ignorieren, dass es in gewissen Anwendungsfällen Defaults gibt und auch geben muss. Siehe z.B. die Implikationen fürs Routing [1]. Wir können nicht ernsthaft danach streben, durch explizites Tagging sämtliche Defaults überflüssig zu machen. *Das* ist nämlich fehleranfällig, weil OSM nie vollständig sein wird. Grüße ant [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed und highway=residential (War: maxspeed)
Hallo, On 17.01.2011 09:40, Andreas Tille wrote: Hi, der Thread wurde mir zu lang, um alles zu lesen, denke aber dieses Thema war noch nicht dran. Im Wiki[1] steht unter highway=residential: Straße an und in Wohngebieten, die keiner anderen Straßenklasse angehört (unclassified, secondary, usw.). Impliziert nicht maxspeed=30. Bitte für Tempo-30-Zonen explizit maxspeed setzen. Für *mich* impliziert das aber in Deutschland maxspeed=50. Sehe ich das richtig und wenn ja, kann man damit nicht schon einen Großteil des im Thread gesagten abhandeln? Guter Hinweis. Diese Implikation ist vermutlich in 95% der Fälle richtig. Übrigens: Maxspeed findet in Bezug auf Routing zwei Anwendungen: 1. Die Höchstgeschwindigkeit, die auf einem Weg gilt - egal ob explizit oder implizit -, kann herangezogen werden um den Preis des Weges zu ermitteln. Diese Anforderung ist zentral für die Berechnung der schnellsten Route, und je zuverlässiger die Implikation von Tempolimits, desto besser das Routing. 2. Ansage der Höchstgeschwindigkeit durchs Navi. In meinen Augen eine Nebensache. Kann sogar zu leichtsinnigem Verhalten im Straßenverkehr und mithin zu Todesopfern führen. Wie oft würde derartiges in die Nachrichten kommen, wenn Navis Tempolimits auf OSM-Basis ansagen würden? Ich mag gar nicht dran denken... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
On 17.01.2011 11:33, Henning Scholland wrote: Das selber basteln halte ich für verkehrt, eben weil es viele Wege gibt, auf denen man die Stadt verlassen kann und auf denen kein Schild steht. Allein schon wenn man eine zweispuriege Straße mit links und rechts jeweils einem Rad-Fußweg müsste man dann 4 Ortsausgangsschilder eintragen, damit der Algorithmus das Polygon zeichnen könnte. Man müsste diese Punkte also ohnehin seperat von den Ortseingangsschildern erfassen, dann kann mana uch gleich ein Polygon machen. Ein Schild wird nur dort eingetragen, wo auch tatsächlich eins steht. Neben die Straße. Track und service können wir bei der Berechnung des Polygons ignorieren. Und Radwege sind für Autorouting nicht wirklich von Belang... Mit deiner obigen Begründung könnte man sich auch das highway=residential sparen. Alle Wege, die innerhlab von landuse=residential sind, sind per default Ortsstraßen und Abweichungen könnte man explizit erfassen. Das lässt sich aber nur umständlich auswerten und man muss erst das landuse-polygon zeichnen können. Eigenschaften die ein Objekt direkt betreffen sollten auch direkt an diesem Objekt pappen, bzw. indirekt über eine Relation, wenn dies sinnvoller ist. So weit wollen wir es dann doch nicht treiben... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
Hallo, On 17.01.2011 12:38, M∡rtin Koppenhoefer wrote: Am 17. Januar 2011 11:21 schrieb antantof...@gmail.com: Ich glaube, manche wollen einfach ignorieren, dass es in gewissen Anwendungsfällen Defaults gibt und auch geben muss. Siehe z.B. die Implikationen fürs Routing [1]. wertet das denn jemand aus? Weiß ich nicht, ob das so schon genutzt wird. Wenn nicht, ist das immerhin aber schonmal eine gute konzeptionelle Grundlage für zukünftige Anwendungen. Die expliziten Maxspeeds in Kombination mit source:maxspeed haben halt den Vorteil, dass sie transparent sind, bereits von Anwendungen (z.B. Garminkarten) ausgewertet werden Für Routing oder fürs Auffinden ungemappter maxspeeds? und dennoch ggf. bei Gesetzesänderungen (Änderung des Default) problemlos angepasst werden können. Mit dem Polygon müsste man ggf. die komplette Stadt runterladen um zu prüfen, ob es schon ein Polygon gibt, ob sie geschlossen und vollständig sind, ob sie geometrisch gültig sind, und sobald jemand das Polygon durch sein Mappen ungültig macht, (z.B. Lücke) gehen alle Anwendungen baden. Eben das gleiche, was für admin-boundaries auch gilt. Interessanterweise ist der is_in-Key weitestgehend in Verruf geraten, wenn mich nicht alles täuscht. Wir können nicht ernsthaft danach streben, durch explizites Tagging sämtliche Defaults überflüssig zu machen. *Das* ist nämlich fehleranfällig, weil OSM nie vollständig sein wird. m.E. ist der Rückschluss genau das Gegenteil: je mehr explizite Tags dran hängen, um so sicherer wird es, eben weil die Daten nicht vollständig sind. Sich da auf Defaults zu verlassen ist doch extrem riskant. Andererseits wäre es fatal, sich ausschließlich auf das Vorhandensein der source:maxspeed-Tags zu verlassen. Ein Fallback ist also immer sinnvoll. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
On 17.01.2011 13:00, M∡rtin Koppenhoefer wrote: Andererseits wäre es fatal, sich ausschließlich auf das Vorhandensein der source:maxspeed-Tags zu verlassen. Ein Fallback ist also immer sinnvoll. source:maxspeed ist per Konzept nicht für die Router sondern für die anderen Mapper. Der Wert für die Router steht im maxspeed. maxspeed meinte ich auch. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
Hallo, On 17.01.2011 20:13, ht321 wrote: Hierzu eine Frage: Laut Wiki (DE:Road_Signs) kann das Schild sowohl als Note auf auch auf der Straße eingetragen werden. Gibt es hier eine grundsätzliche Regelung, wie es für D zu machen ist? Im Prinzip ist das ja so ein eherner Grundsatz von OSM: Trage alle verifizierbaren Objekte dort ein, wo sie sich tatsächlich befinden. Das hat sich mittlerweile auch für Bushaltestellen durchgesetzt (neben der Straße und nicht darauf). Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
On 16.01.2011 10:20, Georg Feddern wrote: Moin, Andreas Tille schrieb: Ich frage mich, wozu das gut ist, da ja in Städten implizit sowieso 50km/h gilt und sich eine explizite Auszeichnung IMHO erübrigt. Sehe ich da was falsch? relativ einfache Gegenprobe: Bestimme einmal anhand der OSM-Daten die jeweils gültige maxspeed. Nicht per Gehirn optisch auf der Karte, sondern wirklich logisch/programmtechnisch anhand der OSM-Daten. Warum nicht einfach ein XX:urban-Polygon ums Innerortsgebiet zeichnen? Das wäre vielleicht nicht ganz so oversized wie an zigtausend Wege die immergleichen Tags zu pappen... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
On 16.01.2011 16:17, Tobias Knerr wrote: Am 16.01.2011 15:57, schrieb ant: Warum nicht einfach ein XX:urban-Polygon ums Innerortsgebiet zeichnen? Das wäre vielleicht nicht ganz so oversized wie an zigtausend Wege die immergleichen Tags zu pappen... Ja, damit könnte man mit etwas Extra-Aufwand die gültige Höchstgeschwindigkeit auf einem Way bestimmen. Man bräuchte Tags an Ways dann zwar gelegentlich immer noch, aber nur für den Fall, dass die dritte Dimension - auf vs. unter der Brücke - den Unterschied macht. Eben nur dann, wenn die implizite Höchstgeschwindigkeit nicht gilt. Man kann so allerdings nicht zwischen implizit gültigen und explizit ausgeschilderten Höchstgeschwindigkeiten unterscheiden. Wenn man das haben will, braucht man eben doch ein Tag wie source:maxspeed=* an den einzelnen Ways. Der Wert dieser Information erschließt sich mir nicht, aber wer's denn haben will, kann ja source:maxspeed=sign für explizite Tempolimits verwenden. Wie ist das denn mit der Polygon-Methode - wird die benutzt bzw. ist sie dokumentiert? Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
Hallo, On 16.01.2011 17:43, Henning Scholland wrote: Hallo, die Polygon-Methode hat 3 Nachteile 1. Die Auswertung ist deutlich komplexer und erfordert deutlich mehr Rechenaufwand. Es gibt zig Way/Node in Polygon Prüfungen, Wege müssen an der Grenze geteilt werden uvm. Wenn wir Hardwareanforderungen gegen Mehraufwand für den Mapper aufwiegen, dann sehe ich den Mehraufwand für den Mapper klar als das größere Übel. 2. Es ist nicht eindeutig, man hat innerhalb des Polygons dann Straßen ohne maxspeed, wo man nicht weiß, ob diese bewusst ohne maxspeed sind oder ob sie nur noch nicht im Bezug auf maxspeed erfasst wurden. Das kann nicht als Argument für oder gegen ein Tagging-Schema gelten. Was nicht erfasst ist, ist nicht erfasst. Im Gegenteil ist das Polygon sogar besser als Fallback zu gebrauchen, denn sonst müsste für nicht erfasste Maxspeeds im Stadtgebiet wahrscheinlich die Höchstgeschwindigkeit für außerorts angenommen werden. 3. Das Polygon ist nie genau bzw. sind vielerorts noch nicht mal die Städte als Polygon erfasst. Warum ist es nie genau? Die Positionen der Ortseingangsschilder lassen sich genau so genau erfassen wie alle anderen Objekte. Viele Grüße, Henning Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
Hallo, On 16.01.2011 18:42, Henning Scholland wrote: Hallo Zu 1.) Also die Tags bringe ich schneller an die Straßen als ich das Polygon gezeichnet habe ;) jOSM - Filter als Stichwort Mag sein, aber gerade für Anfänger ist die Situation äußerst verwirrend und herausfordernd (siehe Threadstarter). zu 2.) Es ist ganz klar ein Vorteil, wenn man einen Unterschied zwischen nicht näher erfasst und erfasst erkennen kann. Bei der Polygon-Methode ist das für die einzelne Straße nicht gegeben. Das ist eine generelle Frage: inwieweit die Erfassung nicht vorhandener Auszeichnungen, in anderen Worten: die Erfassung der Erfassung, sinnvoll ist. Ich könnte jetzt auch loslegen und alle Straßen in meinem Viertel mit maxweight=none taggen. Viel ist damit nicht gewonnen - zumindest wenn die Defaults, wie hier, offensichtlich oder aber anderweitig definiert sind. Bei der Auswertung muss man also annehmen, dass alle Wege innerhalb des Polygons, die kein maxspeed haben die maxspeed für innerorts hat. Stimmt ja auch meistens. Zu 3. Da hab ich mich etwas verquer ausgedrückt. Wenn ich eine Straße mappe, kann ich erfassen, wie die maxspeed-Situation an dieser Stelle ist. Das kann also auch ein Tourist machen, der nur punktuell die Stadt durchfährt. Für das Polygon muss man alle Ausgänge der Stadt/Dorfes kennen und erfasst haben und erst dann kann man das Polygon zeichnen. Mapping-Touristen können doch nach wie vor explizite Tempolimits erfassen und einpflegen. (Vermutlich sind es nur die wenigsten, überaus engagierten Mapping-Touristen, die sich vor Bereisung ihres Zielorts einen genauen Plan machen, wo was fehlt und sich daraus eine Traveling-Salesman-Mapping-Route berechnen - oder täusche ich mich da?) Die Erstellung des Polygons wäre hingegen eine Aufgabe für die Community vor Ort und kann auch iterativ, d.h. zunächst durch Eintragen einzelner Ortseingangsschilder, geschehen. Ehrlich gesagt bin ich nicht ganz im Bilde darüber, wie weit die source:maxspeed-Idee verbreitet ist. Hier in Bremen ist sie jedenfalls noch nicht angekommen. Kannst du ein paar Beispielregionen nennen, insbesondere auch außerhalb DE/AT/CH? Viele Grüße, Henning Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
On 16.01.2011 19:37, Klaus Hartmann wrote: Ehrlich gesagt bin ich nicht ganz im Bilde darüber, wie weit die source:maxspeed-Idee verbreitet ist. Hier in Bremen ist sie jedenfalls noch nicht angekommen. Kannst du ein paar Beispielregionen nennen, insbesondere auch außerhalb DE/AT/CH? Gemäß taginfo insgesamt 45872 mal, wobei die Schwerpunkte in Deutschland und Italien liegen (dort kommt das meiner Erinnerung ursprünglich her). ..und davon etwa 2/3 nach dem Schema countrycode:[urban|rural|motorway]. Naja, immerhin... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed
Hallo, On 16.01.2011 21:43, Jörk wrote: jetzt habe ich hier aber ein admin/grenz-polygon und innerhalb dessen diverse Ortseingangs-/Ausgangs-Schilder... Was mache ich denn dann? die administrativen Grenzen werden wohl selten deckungsgleich mit der innerörtlichen Zone sein, also wären separate Grenzflächen dann schon notwendig. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Häuserumrisse unterschiedlich
Hallo, On 16.01.2011 22:10, Benjamin Lebsanft wrote: http://www.openstreetmap.org/?lat=47.85278lon=10.42868zoom=17layers=M das sind Duplikate, zwei Wege, wo eigentlich nur einer sein sollte. Wird dann halt zweimal gerendert, wodurch die Farben die zweifache Intensität bekommen. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRouteService mit direkter Adresseingabe
Hallo, On 11.01.2011 23:38, Heinz-Jürgen Oertel wrote: Hallo, Gibt es eine Möglichkeit Start und Ziel direkt beim Aufruf anzugeben? Etwa http://openrouteservice.org/such?start=meinort?ziel=deinort vielleicht hilft dir die Nur-Text-Version weiter: http://koenigstuhl.geog.uni-heidelberg.de/accessible_routing/ Start und Ziel können hier auch als GET-Parameter übergeben werden, z.B. http://koenigstuhl.geog.uni-heidelberg.de/accessible_routing/?start=aend=b Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neu: Ein schwarz/weißer Base-Layer
Hi, On 02.11.2010 20:37, Kay Drangmeister wrote: Hi Nach einigen Diskussionen wie man Karten mit Layern ansprechender gestalten könne, kommt hier eine einfache Lösung: eine Mapnik-Karte in Graustufen. Weiterhin gibt es eine no icons-Version mit nochmals reduzierter Grund- information. gut, aber ein echter Graustufen-Style müsste schon mehr sein als eine Graustufenkonvertierung des Originals: Es braucht stärkere Kontraste, weniger Farben (im Sinne von Helligkeitswerten) und eine geänderte Darstellung derjeniger Objekte, die sich mangels Farbe nicht mehr unterscheiden lassen (z.B. footway vs. bridleway = rot vs. grün). Dann hätte der Style einen echten Mehrwert sowohl für Menschen, die keinen Farbdrucker besitzen, als auch für Farbenblinde. Grüße ant Hier ein Beispiel: Original-Mapnik: http://toolserver.org/~osm/styles/?zoom=17lat=52.50964lon=13.37659layers=00B0F0FFF0FF00 S/W wie Mapnik: http://toolserver.org/~osm/styles/?zoom=17lat=52.50964lon=13.37659layers=F0FFF0FFB0 S/W ohne Icons: http://toolserver.org/~osm/styles/?zoom=17lat=52.50964lon=13.37659layers=F0FFF0FF0B Ein Komplettbeispiel mit hillshading und Bicycle-Layer: http://toolserver.org/~osm/styles/?zoom=15lat=47.6322lon=13.00511layers=F0FTF0TF0B Die Tiles findet ihr hier, bitte probiert es mit euren Karten aus: http://toolserver.org/tiles/bw-mapnik/13/4400/2686.png http://toolserver.org/tiles/bw-noicons/13/4400/2686.png Viele Grüße, Kay Drangmeister ___ 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] Redaktionssystem für schnelle OL, wa r: Karten gegen den Castor
Hallo, Am 25.10.2010 11:16, schrieb Markus: _Redaktionssystem für schnelle OL_ Vergleichbar wie in Haiti (wenn auch zu einem ganz anderen Zweck) wäre hier (und bei ähnlichen Aktionen) eine schnelle Kartografie hilfreich, die Ansammlungen, Marschrichtungen, Versorgungseinrichtungen, Sperren, Staus, etc zeigt, und aus der sich Strategien ableiten lassen. Wäre cool, für solche Overlays ein simples Redaktionssystem zu haben, dessen Ergebnisse webbasiert auf verschiedenen Plattformen und Mobilgeräten nutzbar wäre (Punkte, Linien, Pfeile, Flächen, Schrift, Farben, Symbole). ... interessanter Ansatz. Wie ließe sich so etwas realisieren? - Slippymap, normal und für mobile Geräte (siehe khtml.org) - Newsfeed - POI Editor für mobile Geräte (die Mapper wären hier in erster Linie Personen, die vor Ort sind) - Twitter-Overlay - SMS Shortcode wie bei haiti.ushahidi.com Das wäre ein erstes Brainstorming hierzu. Weitere Ideen? Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Das neue Taginfo
On 05.10.2010 15:44, Jochen Topf wrote: Die letzten Monate hab ich an einer Software namens Taginfo gearbeitet, die Informationen über OSM-Tags aus der OSM-Datenbank, dem Wiki und anderen Orten sammelt und aufbereitet. Ähnlich wie Tagwatch, Tagstat und OSMdoc, aber etwas ambitionierter. :-) Ich freue mich, das Ergebnis ankündigen zu können: http://taginfo.openstreetmap.de Es sind immernoch ein paar Bugs drin und viele Features fehlen, aber es ist benutzbar. Updates mache ich derzeit noch von Hand, will aber bald auf automatisierte tägliche Updates umstellen. Klasse! Gibt's ein Bugtracking-System? Ansonsten hier schonmal ne Kleinigkeit: die Möglichkeit nach Objekttypen zu filtern ist mit der Dropdownlist nicht so super intuitiv. Schön wäre es, könnte man die gefilterte Statistik durch Klick auf das jeweilige Symbol (oder sonstige Schaltfläche) im blauen Kasten oben rechts aufrufen. Vielen Dank für die tolle Arbeit. Grüße ant Alle Software dahinter ist Open Source, also spielt mit rum und schickt mir Patches. Mehr Details und Hintergrund gibts in diesem Blogeintrag: http://blog.jochentopf.com/2010-10-05-introducing-taginfo.html Bug-Reports und Ideen für weitere Features sind willkommen. Jochen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] railway=halt
Hallo, sehr häufig hierzulande anzutreffen sind Objekte, die mit railway=halt getaggt sind. Dabei handelt es sich oft um kleinere Bahnhöfe, die jedoch regel- und planmäßig vom Zugverkehr bedient werden. Beispiele: http://www.openstreetmap.org/browse/node/257290391 http://www.openstreetmap.org/browse/node/299325021 Im Wiki [1] steht zum Key railway=halt aber: Haltepunkt (kein Bahnhof, z. T. ohne Bahnsteig, z. T. nur bei Bedarf) Demzufolge wären die oben genannten Beispiele nicht als halt, sondern als station zu taggen. Sehe ich das richtig? (Gibt es in D überhaupt noch Haltepunkte, die dieser Definition entsprechen würden?) Grüße ant [1] http://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dhalt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=halt
Am 24.09.2010 16:29, schrieb Andreas Titz: ant wrote: Im Wiki [1] steht zum Key railway=halt aber: Haltepunkt (kein Bahnhof, z. T. ohne Bahnsteig, z. T. nur bei Bedarf) Demzufolge wären die oben genannten Beispiele nicht als halt, sondern als station zu taggen. Sehe ich das richtig? (Gibt es in D überhaupt noch Haltepunkte, die dieser Definition entsprechen würden?) Ja, die gibt es. z.B. sind selbst solche großen Stationen wie Hamburg Dammtor oder Jena Paradies aus Sicht der Eisenbahn nur Haltepunkte und keine Bahnhöfe, weil ein entscheidendes Kriterium fehlt: eine Weiche. Für einen Bahnhof braucht man mindestens eine Weiche und weitere Voraussetzungen (z.B. müssen Züge dort Wenden oder mit Gleiswechsel überholen können). Ist diese Definition denn auch international gültig? Dann sollte der Wiki-Eintrag entsprechend angepasst werden... Ob ein Bahnsteig vorhanden ist oder nicht, ist für die Einstufung als Haltepunkt unwichtig (Beispiele für Haltepunkte ohne Bahnsteig sind übrigens: Bad Doberan Stadtmitte, Bad Doberan Goethestraße, Kühlungsborn Mitte). Ebenso kommt es nicht darauf an, ob die Züge regelmäßig dort halten oder nur bei Bedarf. Das sollte sich dann ebenfalls im Wiki-Artikel widerspiegeln. Ich finde, die Unterscheidung zwischen Bahnhof und Haltepunkt sollte sich auch in unseren Daten korrekt widerspiegeln - schon um eine OpenRailMap richtig rendern zu können ;-) Zumal es in anderen Ländern ähnliche Unterscheidungen zwischen Bahnhöfen und Haltepunkten gibt. Gruß Andreas Grüße ant ___ 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] Minor nicht verbunden mit highway
Hallo, On 12.09.2010 18:34, dieter jasper wrote: Hallo, der OSM-Inspector (Routing) meckert häufig, dass minor ways /cycleway, footway) nicht mit highway verbunden sind. Häufig sind es auch footway, die im Nichts enden. Siehe z. B. hier: http://tools.geofabrik.de/osmi/?view=routinglon=8.29478lat=52.38112zoom=18opac Was kann man da ohne Ortskenntnisse machen? Kann an der markierten Stelle keinen Fehler erkennen. Gut möglich, dass der Radweg entlang der Straße Im Hinterbruch in Richtung Süden weitergeht, aber darüber kann man ohne Ortskenntnis schlecht urteilen. und noch ein Beispiel: http://tools.geofabrik.de/osmi/?view=routinglon=8.31435lat=52.37482zoom=17 Dieser Fehler ist hingegen offensichtlich. Der Radweg sollte mit der Ziegenstraße verbunden werden. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPX-Generator?
Hi! Ich suche ein Online-Tool, mit dem man GPX-Dateien durch Klicken auf einer Karte generieren kann, ähnlich wie http://www.maptogps.com/ - dieses Beispiel ist leider auf UK beschränkt... Wäre für sachdienliche Hinweise sehr dankbar ;) Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPX-Generator?
On 11.09.2010 16:34, Volker wrote: Vielleicht hilft Dir das ? http://www.gpsies.com/ Das ist genau das, was ich gesucht habe. Danke! Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPX-Generator?
On 11.09.2010 17:35, malenki wrote: ant schrieb: Ich suche ein Online-Tool, mit dem man GPX-Dateien durch Klicken auf einer Karte generieren kann, ähnlich wie http://www.maptogps.com/ - dieses Beispiel ist leider auf UK beschränkt... Wenn es mit OSM sein darf: http://www.pifpafpuf.de/cycleroute/map http://map.meurisse.org/ http://www.wanderreitkarte.de/ Erhebe keinen Anspruch auf Vollständigkeit der Liste malenki perfekt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
On 19.07.2010 18:29, Heiko Jacobs wrote: Schön. Einerseits wird gesagt, es ändert sich ja eigentlich gar nix, alles weiterhin by-sa wie vorher, oder wahlweise, dass die Daten (bis auf in England o.ä. erhobene evtl.) gar nicht unter irgendeinen Schutz stehen. Wenn schutzlos oder wenn sich angeblich nix ändert, dann dürfte ein Lizenzwechsel ohne Datenverluste ja kein Problem sein. Wenn schutzlos: Dann wären wir die Letzten, die das ausnutzen würden. Wenn sich angeblich nix ändert: ändert das nichts daran, dass CC-BY-SA und ODbL inkompatibel sind. (Und das entdeckt man nicht erst bei genauerer Betrachtung, das steht in Großbuchstaben oben drauf.) Komischerweise entdeckt man bei genauerer Betrachtung aber dann doch, dass die Lizenzen so unkompatibel ist, dass von jedem Mapper, der nicht mehr erreichbar ist oder der Nein sagt zum ändert-sich-ja-nix, rausgekegelt werden müssen aufgrund eines zweifelhaften Schutzes. Man sollte sich mal einigen auf ändert sich fast nix oder ändert sich sehr schwerwiegendes und nicht einmal das eine, ein anderes mal das andere sagen. Und das dummerweise zum dnekbar ungüsntigsten Fall miteinander kombiniert, der mit Sicherheit zu Datenverlust führt. Und komischerweise haben schon einige, u.a. Nearmaps, entdeckt, dass die ebenfalls zu beschließenden Contribution Terms das by-sa nicht auf Dauer sichern, was aber Grundlage der bisherigen Spende war ... Und dann gibt es alles nur in eine Abstimmmöglichkeit vereint. Man hat nur 1 Möglichkeit ja oder nein zu sagen. Das umfasst halt eigene Daten, eigene weitere Mitarbeitsmöglichkeit, Lizenzwechel und CT. Wem neue Lizenz (warum auch immer) oder CT nicht passen, hat ja keine andere Möglichkeit, als seine Daten zu verweigern, weil nur das wird abgefragt. Und danach ist er raus, persönlich und seine Daten. Florian Lohoff schrieb: Es ist keine Angst - ich bin Sauer. Ich bin Sauer ein Friss oder Stirb vorgesetzt zu bekommen. Ob man nun lieber PD hätte (was aber einen noch größeren Rattenschwanz an Datenverlusten großer Importe und by-sa-liebenden Usern nach sich ziehen würde) und/oder auf Datenintegrität besonders Wert legt. Florian Lohoff schrieb: Und vor allem ist fuer mich eben das Procedere inakzeptabel. +1 Gruß Mueck ___ 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] Lizenzwechsel-Bauchscmerzen
On 18.07.2010 14:40, Dirk-Lüder Kreie wrote: Am 17.07.2010 15:05, schrieb ant: On 16.07.2010 20:12, Manuel Reimer wrote: Davon hätte jeder andere, der auch OSM nutzt, sofort direkt einen Vorteil, weil die Daten kompletter werden. Daten sind nur dann von Nutzen, wenn es nützliche Anwendungen gibt, die mit diesen Daten etwas anfangen. Die Möglichkeiten, die sich für solche Anwendungen eröffnen, steigen mit dem Freiheitsgrad der Lizenz. Und je besser die Anwendungen werden, desto mehr Leute werden sich OSM zuwenden, um die Daten zu verbessern. Das sehe ich ganz genauso. OSM hat, wie zuvor Wikipedia, gezeigt, dass Crowdsourcing funktioniert. OSM hat ausserdem geschafft, dass einige, die vorher Geodaten als möglichst proprietär behandeln wollten, sich jetzt Gedanken machen, ob nicht der öffentliche Weg der bessere ist, für alle Beteiligten. Ich persönlich sehe einen Datenverlust als nicht so schwerwiegend, wie einige andere, vielleicht auch, weil ich vor ca. vier Jahren mit Bremen vor einer weißen Leinwand saß, und gesehen habe, wie wenige, motivierte Mapper in vier Jahren gesamt Bremen auf die freie Weltkarte gebracht haben. Ich weiß auch, dass diese Arbeit mit den jetzt angemeldeten Mappern in wenigen Monaten erneut leistbar wäre, es also keinesfalls wieder vier Jahre dauern würde, bis wir Bremen in einem vergleichbaren Zustand wieder zusammen hätten. Und ich bin überzeugt, dass das für ganz Deutschland gilt. ... und wenn wir beim Neuerfassen der Straßen gleich alle anliegenden Geschäfte/POI überprüfen und fehlende Hausnummern eintragen, haben wir damit auch noch was gewonnen. Problematisch sind Länder, die von großen Datenimporten/Luftbildspenden mit CC-By-SA-Bedingunen profitiert haben, also z.B. Niederlande, Polen, Australien, und andere. Unproblematisch ist unser größter Import: Tiger, die Daten waren von Anfang an Public Domain. Es hätte damals ein Hinweis sein können, dass By-SA nicht unbedingt das Optimum darstellt. ___ 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] Lizenzwechsel-Bauchscmerzen
On 18.07.2010 04:06, Sebastian Hohmann wrote: ant schrieb: On 17.07.2010 11:47, Sebastian Hohmann wrote: Wenn ich jemanden meine Daten geben und sagen das steht unter der CC0, dann darf er sie natürlich beliebig lizenzieren, auch ohne sie vorher zu veröffentlichen. Nur möchte ich meine Beiträge schließlich der Allgemeinheit zur Verfügung stellen,nicht der OSMF, die es dann direkt in ODbL umlizenziert. Du möchtest deine Beiträge der Allgemeinheit zur Verfügung stellen, aber nicht der OSMF? Das musst du mir mal erklären. Gerne. Ich möchte es als PD allen zur Verfügung stellen, nicht NUR der OSMF, die es dann direkt umlizenziert und erst dann veröffentlicht. Es geht um das Argument, wer seine Daten als PD ansieht habe automatisch auch kein Problem damit, wenn sie NUR unter einer anderen Lizenz veröffentlicht werden. Mit anderen Worten, du wünscht dir ein OSM/PD. Gibt's aber nunmal nicht. (Aber natürlich steht es jedem frei, etwas derartiges ins Leben zu rufen...) Ich finde man kann nicht davon ausgehen, dass jeder der gerne CC0 hätte, automatisch auch die ODbL gut finden muss oder die Lizenz ganz egal ist. Dann müsste man ja nicht für CC0 sein. Bei den jetzigen Abstimmungsmöglichkeiten fallen alle die aus irgendeinem Grund ablehnen aber PD trotzdem gut finden, komplett unter den Tisch. Ein Lizenzwechsel zu PD stand, wenn ich mich recht erinnere, nie zur Diskussion. Es gibt die Option, damit man angeben kann, dass man gerne PD hätte. Wenn das aber nur geht, wenn man für die ODbL ist, wird das Ergebnis verfälscht. Gruß ___ 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] Lizenzwechsel-Bauchscmerzen
On 17.07.2010 11:47, Sebastian Hohmann wrote: Wenn ich jemanden meine Daten geben und sagen das steht unter der CC0, dann darf er sie natürlich beliebig lizenzieren, auch ohne sie vorher zu veröffentlichen. Nur möchte ich meine Beiträge schließlich der Allgemeinheit zur Verfügung stellen,nicht der OSMF, die es dann direkt in ODbL umlizenziert. Du möchtest deine Beiträge der Allgemeinheit zur Verfügung stellen, aber nicht der OSMF? Das musst du mir mal erklären. Und: Wenn du deine Daten eh als PD freigeben möchtest, kannst du das doch alles viel gelassener sehen. Sollte es irgendwann mal einen PD-Fork geben, wirst du sicherlich herzlich eingeladen sein, daran mitzuarbeiten. Ich finde man kann nicht davon ausgehen, dass jeder der gerne CC0 hätte, automatisch auch die ODbL gut finden muss oder die Lizenz ganz egal ist. Dann müsste man ja nicht für CC0 sein. Bei den jetzigen Abstimmungsmöglichkeiten fallen alle die aus irgendeinem Grund ablehnen aber PD trotzdem gut finden, komplett unter den Tisch. Ein Lizenzwechsel zu PD stand, wenn ich mich recht erinnere, nie zur Diskussion. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
On 17.07.2010 13:49, Heiko Jacobs wrote: Alle meine Bearbeitungen inklusive derer, wo ich an betehende ways weitere tags drangehängt habe oder korriigert habe, hatten den Zweck, der OSM-Community für eine weitere Benutzung und Weiterentwicklung des Projekts OSM zu dienen. Wie können sie diesem Zweck dienen, wenn sie in einem veraltetenden last-CC-planet.osm liegen? Man darf sie ja von dort nicht wieder in OSM einschleusen. Bleib mir weg mit dieser Theorie ohne praktischen Wert. snip Nein, rauskopieren aus dem last-CC-planet und im ODBL-OSM wieder einschleusen darf ich sie nicht, da infiziert, ohne fremden highway=track hängen meine erhobenen surface=*-Originaldaten in der Luft. Die Frage ist, wie der Datenumzug auf der technischen Seite abläuft (im besten Fall natürlich so, dass keine in der Luft hängenden Bearbeitungen unter den Tisch fallen). Ich bin da optimistisch - ich denke, es werden Lösungen gefunden werden, wie solche Bearbeitungen überführt werden können. Vielleicht über eine Art zusätzliches Layer im Editor, das diese problematischen Bearbeitungen enthält und eine einfache, vielleicht automatisierte Rückführung erlaubt. Das wird auch alles nicht von heute auf morgen passieren. Aber ein Projekt mit dieser Dynamik wird das schnell und gut verkraften. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
On 16.07.2010 20:12, Manuel Reimer wrote: nimix wrote: Das lässt sich auch der schön auf OSM übertragen. Wenn beispielsweise Google die OSM-Daten nehmen und damit zusammen mit Ihren eigenen Daten ein hervorragendes Fahrradrouting anbieten würde wäre das für alle eine super Sache. Von der zusätzlichen Freigabe ihrer eigenen Daten hätten glaube ich nur wenige Spezialisten etwas. Davon hätte jeder andere, der auch OSM nutzt, sofort direkt einen Vorteil, weil die Daten kompletter werden. Daten sind nur dann von Nutzen, wenn es nützliche Anwendungen gibt, die mit diesen Daten etwas anfangen. Die Möglichkeiten, die sich für solche Anwendungen eröffnen, steigen mit dem Freiheitsgrad der Lizenz. Und je besser die Anwendungen werden, desto mehr Leute werden sich OSM zuwenden, um die Daten zu verbessern. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
On 17.07.2010 17:45, Thomas Reincke wrote: Am 17.07.2010 14:27, schrieb ant: Das wird auch alles nicht von heute auf morgen passieren. Aber ein Projekt mit dieser Dynamik wird das schnell und gut verkraften. Redest Du Dir da nicht zumindest teilweise etwas schön? Ich war vor knapp einem Jahr in einem Dorf im Hunsrück zu Besuch. http://www.openstreetmap.org/?lat=49.7393lon=7.4602zoom=14layers=B000FTF Seither ist dort *nichts* geschehen. Mag sein, daß dort alles 50 Jahre später kommt, aber von Dynamik erkenne ich da nichts. Dass OSM in ländlichen Gegenden schwach ist, ist ja keine Neuigkeit. Dafür ist die Problematik des Lizenzwechsel dort aber längst nicht so schwerwiegend! Nehmen wir an, Mapper X hat seinen Landkreis im Alleingang eingepflegt. Dann wird er um seine Zustimmung zur Lizensierung seiner Daten unter der ODbL gebeten werden, und die Gefahr eines Datenverlusts ist somit relativ gering. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Routenrelationen sortieren
Hallo! Gibt es ein Tool, mit dem man Routenrelationen (z.B. Fahrradrouten) automatisch sortieren kann? Das heißt, zusammenhängende Teile sollen in sich so sortiert sein, dass aufeinanderfolgende Elemente stets verbunden sind... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenrelationen sortieren
On 16.07.2010 12:29, André Joost wrote: Am 16.07.10 11:55, schrieb ant: Hallo! Gibt es ein Tool, mit dem man Routenrelationen (z.B. Fahrradrouten) automatisch sortieren kann? Das heißt, zusammenhängende Teile sollen in sich so sortiert sein, dass aufeinanderfolgende Elemente stets verbunden sind... Das macht josm schon seit einiger Zeit, wenn man im relationseditor die Schaltfläche A...Z betätigt, und nicht gerade nur einige Elemente markiert hat. Und nein, das wird nicht alphabetisch sortiert, sondern lagerichtig ;-) Beim Hochladen bleibt diese Sortierung auch erhalten. Danke. Ich dachte wirklich, der würde alphabetisch sortieren. -1 fürs Icon... Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenrelationen sortieren
On 16.07.2010 21:03, Manuel Reimer wrote: Dann drehe ich die Frage doch gleich mal um: Müssen die Relationen sortiert sein, oder darf ich Wegstücke, die ich als zur Relation zugehörig erkannt habe, einfach ans Ende rankleben? Ich denke, das hängt davon ab, welchem Zweck die Relation dient. Wenn eine Liste der längsten Flüsse durch eine Relation dargestellt werden soll, dann ist die Sortierung wohl entscheidend. Bei Routenrelationen ist sie dagegen nur Kosmetik, ebenso bei Busrouten, wenn die Haltepunkte denn auch schön auf dem Weg (anstatt daneben) eingetragen sind. Hintergrund: Merkaartor kennt AFAIK eine Sortierung nicht. Ein anderes Programm will ich nicht, da ich die Darstellung im Merkaartor gefälliger finde. Die bunten Linien im JOSM gehen irgendwie nicht an mich. In der Version 0.16 hat Merkaartor eine Sortierfunktion. Relation auswählen, dann erscheinen im Properties-Fenster zwei Knöpfe zum Verschieben von Relationsmitgliedern. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] village, hamlet, locality?
Fandarel wrote: Hmm, Arnis z.B. ist nur als 'place=village' getagged, sollte man das ändern? Arnis hat ca. 300 Einwohner. Und Stadtrecht. Ich habe die Diskussion verfolgt und denke, dass weniger die rechtliche Einstufung als die harten Fakten, kombiniert mit etwas Intuition, fürs place-Tag sinnvoll sind (es soll ja vor irgendwelchen rechtlichen Konstrukten in erster Linie die Wirklichkeit abgebildet werden). Aber wär das nicht was für einen neuen Key? Z.B. de:status=stadt, de:status=flecken etc. Könnte man super politische Karten mit erstellen. Abgesehen davon sollten wir die Definition des Weilers im Wiki wohl ändern. Ich höre so etwas wie bis 100 Einwohner aus der Diskussion heraus. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] village, hamlet, locality?
Martin Koppenhoefer wrote: - m.E. wäre es durchaus sinnvoll, auch nach oben noch eine weitere Stufe hinzuzufügen (oberhalb city, die dann Städte ab 1 Mio Einwohnern bedeutet) +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] village, hamlet, locality?
Moin, wie werden Ortschaften in D üblicherweise beschrieben? Im Wiki habe ich dazu nichts gefunden. Geht das nach Einwohnerzahl? Oder sind geschlossene Ortschaften mindestens place=village? Und was ist mit den Orten, die diese kleinen grünen Schilder haben? Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] village, hamlet, locality?
Norbert Kück wrote: Hilft das http://wiki.openstreetmap.org/wiki/DE:Key:place wirklich nicht weiter? Doch, nur habe ich da anscheinend elegant drumherumnavigiert Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenbahnen, Straßen, Busse
Hallo zusammen, dies ist mein erster Post auf Talk-de, ich pflege eine Benutzerseite auf [1]. Nachdem ich mich ein wenig am Bosporus ausgetobt habe, will ich nun Bremen mappen. Beim Eintragen von Bushaltestellen sind mir ein paar Fragen gekommen: 1) Ich stelle fest, dass Bushaltestellen vornehmlich neben der Straße eingetragen werden, während Straßenbahnhaltestellen - zumindest hier in Bremen - meist auf die railway-Wege gesetzt werden. Was gilt aber für Haltepunkte, die sowohl von Bussen als auch von Bahnen bedient werden? 2) Verläuft ein Straßenbahngleis auf einer Straße, deren Spuren nicht baulich voneinander getrennt sind, gehört dann genau ein Weg dorthin, mit highway=... und railway=tram, oder besser zwei Wege am selben Ort? 3) Wie ist eine Straße zu taggen, die nur Busse befahren dürfen? Grüße ant [1] http://wiki.openstreetmap.org/wiki/User:Ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbahnen, Straßen, Busse
Claudius wrote: Wirf doch mal einen Blick auf dieses erweiterte ÖPNV-Schema [1], dort Danke... habe mir das schon einmal angeschaut, und es hat mich gleich überzeugt. Ich hab bisher jedoch gezögert es umzusetzen. Grüße ant ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
