[Talk-de] Nächstes Karlsruher Hack-Weekend im Februrar
Hallo, das nächste Hack-Weekend in Karlsruhe wird am 21./22.2. sein. Wir haben uns diesmal mit den Berlinern abgestimmt, so dass es keine Terminkonflikte geben sollte. Einen weiteren Termin haben wir für den 17./18. Oktober vorgesehen. Wikiseite dazu kommt später, ich wollte nur schonmal die Termine ankündigen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mittelmeer flutet Italien
Sieht lustig aus in z=9 http://www.openstreetmap.org/#map=9/42.1257/12.9694 Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mittelmeer flutet Italien
Am 12.12.2014 13:13, schrieb Markus: Sieht lustig aus in z=9 http://www.openstreetmap.org/#map=9/42.1257/12.9694 Ja, es gab da wohl gestern eine größere coastline-Störung. http://forum.openstreetmap.org/viewtopic.php?id=28813 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mittelmeer flutet Italien
Hallo Christian, Ja, es gab da wohl gestern eine größere coastline-Störung. Danke für den Link! Wie könnte man so eine Störung im Preprocessing erkennen? Dann könnten wie sie ja vielleicht korrigieren, bevor wir rendern? Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mittelmeer flutet Italien
Markus liste12a4...@gmx.de wrote: Wie könnte man so eine Störung im Preprocessing erkennen? Jochens Coastline script macht das normalerweise eigentlich ganz gut. http://openstreetmapdata.com/data/coastlines Dann könnten wie sie ja vielleicht korrigieren, bevor wir rendern? s.o. Sven -- Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buchten/Meeresarme mappen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.12.2014 08:32, Markus wrote: Moin Mark, um unfallfrei etwas beizutragen (Schottland!) :-) Dazu und zu vergleichbaren Themen hatten wir ja schon mehrere Diskussionen, die mangels schlüssigem Konzept alle irgendwann im Sand verliefen. Es wäre wirklich super, wenn wir das mal erfolgreich angehen könnten! (und nein, ich habe bisher keine Lösung gesehen) So, nun habe ich mir die Diskussionen unter den vorgeschlagenen Links (danke!) mal durchgelesen. Hier steh ich nun ich armer Tor... natürlich habe ich die perfekte Lösung auch nicht. Und egal wie man es nach den momentanen Möglichkeiten macht, irgendwelche Probleme gibt es immer. _Unschärfe_ Methodisch scheint es nicht sinnvoll zu sein, ein unscharfes Gebilde durch eine scharfe Linie begrenzen zu wollen. Das wird geltend gemacht, ja. Solange aber jeder Datennutzer sich leicht klar machen kann, dass da ein unscharfes Gebilde wiedergegeben wird und welcher Art die Unschärfe sein kann (und das ist bei Buchten ja klar), sehe ich da nicht wirklich ein Problem. Tatsächlich machen wir das in OSM ja schon ständig. Gerade bei Objekten, die Landnutzung und/oder Bodenbedeckung wiedergeben sind die Grenzen oft unscharf. Und auf andere Weise machen wir es beim Tagging. Es gibt keine scharf bestimmte Grenze, was noch hamlet und was schon village ist, auch keine scharfe Abgrenzung zwischen den tracktypes, keine zwischen river und stream. Trotzdem machen wir solche Unterscheidungen, und im Gegensatz zu Ansätzen, die das durch scharfe Angaben ersetzen wollen (beim Fließgewässer die genaue Breite angeben, beim Feldweg irgendwelche physikalische Angaben zur Bodenbeschaffenheit machen...), lässt es sich erstens sinnvoll mappen und zweitens sinnvoll benutzen. _Aufwand_ Wenn dafür auf der einen Seite die Küstenlinie hergenommen wird, und auf der anderen Seite eine willkürliche Gerade, dann gibt es an den zwei Schnittpunkten Konflikte ohne Ende. Damit meine ich nicht so sehr politische Bewertungen, wo denn nun die Bucht endet - sondern wie man Mappingfehler mit praktisch vertretbarem Aufwand korrigieren kann. Das verstehe ich jetzt nicht. Welche Konflikte soll es da - abgesehen von dem unten angesprochenen Problem des ungleichzeitigen Renderns - geben? Ist das Teilen der Küstenlinie ein Problem? Genau danach hatte ich ursprünglich gefragt, aber dazu hat bisher niemand was gesagt. Oder gibt es Schwierigkeiten, wenn ein Punkt einerseits zu einer Küstenlinie, andererseits zu einer anderen Linie gehört? Also - was kann praktisch kaputtgehen, wenn ich Küstenlinien plus eine Gerade (oder hin und wieder vielleicht eine komplexere Linien oder mehrere Geraden) benutze, um eine Bucht wiederzugeben? Je komplexer wir das Mappen gestalten, desto weniger Mapper werden damit zurecht kommen. Vorhandene Küstenlinien herzunehmen, um eine Bucht zu beschreiben, erscheint mir nun gerade alles andere als komplex. Kann ja sein, dass das zu Problemen führt und dieser Ansatz deshalb nicht zu empfehlen ist. Aber nach solchen Problemen frage ich ja gerade. Natürlich ist es noch einfacher, nur einen Punkt zu setzen, daran will ich auch niemanden hindern, ich bin hier aber gerade bereit, _etwas_ komplexer zu mappen und bei meinen Versuchen möglichst kein Chaos anrichten. _Küstenlinie_ Die Küstenlinie wird ausserhalb der DB gehändelt und wesentlich seltener gerendert als normale Objekte. Das führt dann automatisch zu unbeherrschbaren unschönen Artefakten. Und welche Probleme sind da nun zu erwarten? Wenn die seeseitige Linie vor den Küstenlinien beim Renderer ankommt, könnte die Bezeichnung der Bucht an einer unerwünschten Stelle oder gar nicht dargestellt werden, was sich aber automatisch wieder geben sollte, sobald die Küstenlinie eben doch neu gerendert wird. Oder? Probleme mit vollaufenden Ländern sollten ja nicht zu erwarten sein, weil die Küstenlinie ja geschlossen bleibt, auch wenn man einen Abschnitt in zwei kürzere zerlegt. Oder? _Hierarchische Abhängigkeit_ Buchten können riesig sein (Rotes Meer, Golf von Aden) oder miniklein (Badebucht, z.B. https://en.wikipedia.org/wiki/Children%27s_Pool_Beach). Das erfordert ein Konzept zur Unterscheidung, um die Verschiedenheit vernünftig auf den Zoomleveln darzustellen. Da sollte aber doch gerade die Erfassung als Polygon hilfreich sein, auch wenn sie wahrscheinlich nicht alle Probleme löst, die da auftauchen können. Gruß, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUiw94AAoJEBrjxFVQEkD/VgcP/0Vre2XpFY3LqpGydQ7qxF91 mBaOgcBTmQDOexMGwt6YtgjGC/rcS37T7oK+oL6VR71vCWqWCJaxMyk3xmmh3CMs MYzP+3w1z+XAczGuy/PTMhSHcW8t8P2dZm6gbnM9MZynMaZpTAqzR76/tlx961Gf qYpUiD+Om6IT/Dp78SizrheNHpqIrWeni0lxjiAuU+BRYz2bvfixN2fNl+OD3faS 0IZJMU2hd2PCrAthfwbyI1UXTZ5DsJC7VJt1iqH5oMhyDDYDd1JUspArVCwgGthA cpRoqmtWUU+mxQDNQQ2zcsDq7KpHm5aCk05xjZMd6AG021hneMY9+uSkfQOBbjVG
Re: [Talk-de] Buchten/Meeresarme mappen
Hallo Mark, Es wäre wirklich super, wenn wir das mal erfolgreich angehen könnten! (und nein, ich habe bisher keine Lösung gesehen) natürlich habe ich die perfekte Lösung auch nicht. Es wäre ja schon ein wesentlicher Fortschritt, wenn wir einen validen methodischen Ansatz hätten... _Unschärfe_ Methodisch scheint es nicht sinnvoll zu sein, ein unscharfes Gebilde durch eine scharfe Linie begrenzen zu wollen. Solange aber jeder Datennutzer sich leicht klar machen kann, dass da ein unscharfes Gebilde wiedergegeben Das reicht m.E. nicht als verlässliche Methode. bei Objekten, die Landnutzung und/oder Bodenbedeckung wiedergeben sind die Grenzen oft unscharf. Das sind verschiedene Themen: a) nicht genau bestimmen wo der Wald anfängt und die Wiese aufhört (aus Makro-Sicht scharf, aus Mikro-Sicht muss man definieren, wie das mit den Baumkronen ist, und ob es ggf. noch weitere Vegetationsarten im Übergangsbereich gibt und wie man diese darstellen will) b) nicht wissen /können/ wo Gebilde wie Berg, Gebiet, Bucht aufhören. (per se unscharf) Grenze, was noch hamlet und was schon village ist Das lässt sich als zwei Klassen definieren. Aber wo die Grenze zwischen Rotes Meer und Golf von Aden ist oder zwischen Schwarzwald und Rheintal oder was die Deutsche Bucht ist - das geht nicht, da unscharf. Wenn wir es dennoch so machen würden, bekämen wir unzählige Linien, die kein geografisches Objekt markieren, sondern viele unscharfe Metainformation begrenzen ;-) _Aufwand_ Wenn dafür auf der einen Seite die Küstenlinie hergenommen wird, und auf der anderen Seite eine willkürliche Gerade, dann gibt es an den zwei Schnittpunkten Konflikte ohne Ende. Damit meine ich nicht so sehr politische Bewertungen, wo denn nun die Bucht endet - sondern wie man Mappingfehler mit praktisch vertretbarem Aufwand korrigieren kann. Das verstehe ich jetzt nicht. Ein Bürger von Djibouti fühlt sich vielleicht zum G.v.Aden zugehörig, ein anderer eher zum RM. Falls sie (und alle anderen) sich einigen können, ist das Umtaggen höchst aufwändig. Problem des ungleichzeitigen Renderns ich fürchte, das ist ziemlich schwierig zu lösen. Ist das Teilen der Küstenlinie ein Problem? Wenn sie wieder richtig zusammengefügt wird ist das kein Problem. Aber es müssen dann auch immer alle Relationen mitgepflegt werden. Und bei so komplexen Gebilden wie Eurasienafrika fürchte ich Chaos. Der Suezkanal ist keine Küste. gibt es Schwierigkeiten, wenn ein Punkt einerseits zu einer Küstenlinie, andererseits zu einer anderen Linie gehört? Ja, wenn Linien unterschiedlicher Klassen zusammengeklebt werden, führt das bei der Wartung immer zu Schwierigkeiten. Folge ist, dass es nur noch von Spezialisten gewartet werden kann. was kann praktisch kaputtgehen Kaputt geht erst mal nichts. Deshalb machen es ja einige auch einfach. Die Frage ist, ob es /sinnvoll/ ist - und welche Folgen das hat. plus eine Gerade (oder hin und wieder vielleicht eine komplexere Linien oder mehrere Geraden) Das wären mehrheitlich Linien, die man nicht sehen kann, und die auch nicht definiert sind. Natürlich ist es noch einfacher, nur einen Punkt zu setzen Das wäre zumindest eine Lösung, bei der das Rendering der Namen dem Renderer überlassen bleibt. Wenn die seeseitige Linie vor den Küstenlinien beim Renderer ankommt, könnte die Bezeichnung der Bucht gar nicht dargestellt werden Deshalb reicht m.E. ein Punkt. Der Renderer kann dann mit Preprocessing schöne Namenszüge rendern. _Hierarchische Abhängigkeit_ Buchten können riesig sein (Rotes Meer, Golf von Aden) oder miniklein (Badebucht, z.B. https://en.wikipedia.org/wiki/Children%27s_Pool_Beach). Das erfordert ein Konzept zur Unterscheidung, um die Verschiedenheit vernünftig auf den Zoomleveln darzustellen. Da sollte aber doch gerade die Erfassung als Polygon hilfreich sein, Es wären abertausende verschachtelter Polygone, jedes mit einer künstlichen scharfen Begrenzung, ohne Entsprechung in der Natur. Eine Idee wäre: Eine zusätzliche *DB für unscharfe Gebiete*, ausschliesslich mit ungefähren Angaben zur Ausdehnung von Namens-Gebilden... Berge, Täler, Rücken, Wüsten, Ebenen, Gebiete, Meere, Meeresteile, Buchten, Lagunen, Gletschern, Gletzscherzungen, Wäldereien, ... Aber ob sowas sinnig realisierbar ist, das müssen die Geoinformatiker sagen. Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Buchten/Meeresarme mappen
am Freitag, 12. Dezember 2014 um 19:25 schrieb Markus: Eine Idee wäre: Eine zusätzliche *DB für unscharfe Gebiete*, ausschliesslich mit ungefähren Angaben zur Ausdehnung von Namens-Gebilden... Berge, Täler, Rücken, Wüsten, Ebenen, Gebiete, Meere, Meeresteile, Buchten, Lagunen, Gletschern, Gletzscherzungen, Wäldereien, ... Warum separate DB? Wäre das nicht was für API 0.7 (sofern es diese irgendwann mal geben wird)? Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, bitte entschuldigt die verzögerte Antwort Am Donnerstag, 11. Dezember 2014 03:24 schrieb 715371 osmu715...@gmx.de: ... Es bleibt irgendwie schwer zu vergleichen. Ja, und wie war das noch gleich: Traue nie einer Statistik die du nicht selber gefälscht hast. ;) ... Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. So richtig elegant finde ich das nicht. Und es gibt auch einige Mapper, die das komplett ablehnen. Zumindest habe ich das in den Diskussionen zu den Proposals von damals gelesen. Ich bin mir auch noch nicht wirklich sicher, dass die Vorteile überwiegen. Allerdings ist es im Moment die einziege Möglichkeit, die Ich sehe, beide Darstellungen zu haben. ... Wobei dann auch solche Dinge wie barrier=retaining_wall/fence etc berücksichtigt werden müssten. Wenn jemand z.B. keine turn-restriction gemappt hat, weil er es ja separat eingezeichnet hat und es deshalb nicht geht, würde das sonst zu Fehlern führen - so würde ich mir das ad-hoc vorstellen. Tut mir leid, aber da kann ich dir gerade nicht folgen. highway=footway + footway=sidewalk wird/soll ja nur gemappt werden, wenn ein Wechsel auf die Straße jeder Zeit möglich ist. Ansonsten wird doch nur highway=footway gemappt, oder? OK. Es kommt definitiv auf die Situation an. Wenn eine Straße nur einen Bürgersteig hat, dann genügt sidewalk=*. Wenn der Fußweg von der übrigen Anlage getrennt ist, kann es sich hingegen lohnen, die Wege separat einzuzeichnen. Deshalb wäre es wohl auch nicht im Sinne der OSM separates erfassen generell zu verbieten, sondern nur in bestimmten Situationen. Ich weis nicht so recht. :/ . Ich bin eher dafür, das auf irgend eine Art und Wiese einheitlich zu haben. Dass mit dem dubiosen approved bei sidewalk=* ist mir auch aufgefallen. Allerdings wäre eine Abstimmung inzwischen irgendwie sinnlos. Bei footway=sidewalk halte ich die für wesentlich wichtiger. Durch den Gebrauch ist das Tagging allerdings auch ziemlich fix. Wenn man sich das Proposal zu footway=sidewalk durchliest, könnte man bei der Abstimmung schon genau die Kritik/Befürchtung, die ich hier auch übe, vermuten. Sehe ich auch so. Vieleicht kann die Doppelrepresentation als Komptomiss dazu dienen, ohne selber alt zu fiel Ärger zu verursachen. Ich werde mal im Laufe der nächsten Woche ein paar Gedanken dazu formulieren. Mal sehen was mir dabei noch alles einfällt. Deine Anwendung ist die erste bei der ich bemerke, dass sie diese Daten benutzt. Und dann auch noch nicht einmal nur die - es sind noch mehr Tags nötig. Ob das Proposal damals mit doppeltagging eine Mehrheit bekommen hätte? Na ja... Wenn man das nur mit Gehwegen machen würde, bräuchte es nicht soviele tags. Viele der Tags sind einfach der sehr unübersichtlichen Lage (Rechtlich, OSM Tagging) beim Thema Fahrrad/Radwege geschuldet. Und dann wird man beim Routen mit simplen Algorithmen nicht mehr weit kommen. Man _muss_ sehr komplexe Algorithmen benutzen. U. a. weil Mapper Wege auch nicht mehr mit der Fahrbahn verbinden werden (weil sie es nicht wissen oder vergessen). Schon möglich, aber das gibt es bei Routern auch jetzt schon. Ich setzt dann den Start/Endepunkt nicht auf ein Gebäude, sonder einfach auf die Straße davor. Mit Maus ist das kein großes Problem, aber unterwegs für den Router macht es das nur komplizierter und die Bedienung umständlicher. Es wäre halt schön zu wissen, dass das was da so viele machen auch funktioniert. Guter Einwand. Allerdings haben viele Fußgänger und Radfahrer Router (immer noch) große Probleme vernünftige Ergebnisse zu liefern. Beste Grüße Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Am 11.12.2014 03:24, schrieb 715371: Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. Verstehe ich nicht. Ein Renderer der beides auswertet malt dann 2 Linien neben der Straße, das soll schön aussehen? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 229 2.12.–8.12.2014
Am 11.12.2014 18:33, schrieb wn reader: die Wochennotiz Nr. 229 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/11/wochennotiz-nr-229/ Kleine Korrektur: http://blog.openstreetmap.de/blog/2014/12/wochennotiz-nr-229/ Grüße, Michael. (ach iss denn schoh Dezember?;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track bei Bordstein Trennung
Hallo, Am Freitag, 12. Dezember 2014 21:18 schrieb chris66 chris66...@gmx.de: Am 11.12.2014 03:24, schrieb 715371: Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das ich für wichtig halte. Verstehe ich nicht. Ein Renderer der beides auswertet malt dann 2 Linien neben der Straße, das soll schön aussehen? Prizipiel hast Du erstmal Recht. Es verlangt von einem Renderer, der das Vernünftig darstellen will, eine etwas kompliziertere Abfrage. Das Tagging müsste außerdem gut durchdacht werden. Als einfaches Beispiel (bitte nicht daran verbeißen) sei aber mal folgendes Situation gegeben: Eine Wohnstraße mit Borstein-Gehwegen auf beiden Seiten. highway=residential + footway:both=sidewalk highway=footway + footway=sidewalk Der Renderer, welcher den Bürgersteig an der Straße darstellen möchte, unterdrückt halt alle highway=footway + footway=sidewalk und stellt die highway=residential + footway:both=sidewalk entsprechend dar. Z.B. als roten Rand. Derjenige, der den Bürgersteig als eigenen Weg darstellen will, malt die highway=residential + footway:both=sidewalk als normale Straßen, ohne roten Rand, und stellt darfür die highway=footway + footway=sidewalk dar. So oder so ähnlich. Gruß Hubert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
