[Talk-de] AIO-Karten (Re: Verweise auf dev.openstreetmap.de kaputt)
fla...@googlemail.com fla...@googlemail.com writes: Hinweisen möchte ich drauf das es dann auch imer frische Logfile mit vielen Fehlern gibt ... http://dev.openstreetmap.de/aio/mkgmap-errors/ Das ist aber zZ nicht userfreundlich aufgebaut. Ich werde mal einen Blick reinwerfen; mal schauen, ob ich etwas verstehe... Hilfe / Vorschläge per Mail gerne an mich. ftp://ftp5.gwdg.de/pub/misc/openstreetmap/download.openstreetmap.de/aio/germany/aio-germany.7z scheint momentan nicht neu gepackt zu werden. Die zugehörige gmapsupp.img ist wohl ok. -- Karl EICHWALDER ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mehrere Bibliotheken (ISIL) in einem Raum
Hallo, Bibliotheken haben ja normalerweise ein Bibliothekssigel (ISIL). Hat jemand eine Idee, wie man am besten zwei Bibliotheken kartiert, die sich am gleichen Ort (Node) befinden? Verwendet man zweimal den Key ref:isil oder bekommt er beide ISIL als Werte und wie wuerde man die dann trennen? Danke und Gruss -- Michael Neumann michael.neum...@uni-dortmund.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Bibliotheken (ISIL) in einem Raum
Moin, Michael Neumann schrieb: Hat jemand eine Idee, wie man am besten zwei Bibliotheken kartiert, die sich am gleichen Ort (Node) befinden? ganz pragmatisch würde ich erst mal sagen, dass das gar nicht sein kann. ;-) Von daher wäre es sinnvoll, hier konkretere Angaben (Permalink, Ortsangabe, Bibliotheksangabe) zu machen, damit man sich davon selbst ein Urteil bilden kann. Verwendet man zweimal den Key ref:isil oder bekommt er beide ISIL als Werte und wie wuerde man die dann trennen? unterscheiden sich die Bibliotheken denn tatsächlich nur im ISIL, nicht auch im Namen, Betreiber und/oder sonstigen Eigenschaften? Jedenfalls würde ich da ggf. eher zwei nodes draus machen - aber das hängt ggf. eben von den näheren Umständen ab - siehe oben. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Osm-Kartenlink mit Marker
Hi ! gibt es eigentlich eine Möglichkeit (außerhalb von esytools) eine OSM-Karte auf openstreetmap.org mit Marker zu erzeugen ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Bibliotheken (ISIL) in einem Raum
Am 28.09.2011 09:17, schrieb Georg Feddern: ganz pragmatisch würde ich erst mal sagen, dass das gar nicht sein kann. ;-) Von daher wäre es sinnvoll, hier konkretere Angaben (Permalink, Ortsangabe, Bibliotheksangabe) zu machen, damit man sich davon selbst ein Urteil bilden kann. An der TU Dortmund befinden sich z.B. die Bereichsbibliothek Bio- und Chemieingenieurwesen (BCT) und die Bereichsbibliothek Elektrotechnik und Informationstechnik (BE) in den gleichen Raeumlichkeiten. Ein weiteres Beispiel sind die Bereichsbibliothek Informatik (BI) und die Bereichsbibliothek Physik (BP), die sich in den gleichen Raeumlichkeiten befinden. unterscheiden sich die Bibliotheken denn tatsächlich nur im ISIL, nicht auch im Namen, Betreiber und/oder sonstigen Eigenschaften? Jedenfalls würde ich da ggf. eher zwei nodes draus machen - aber das hängt ggf. eben von den näheren Umständen ab - siehe oben. Ausser im Namen und in der ISIL gibt es keine Unterschiede. Man koennte eventuell auch der Meinung sein, Bereichsbibliotheken gar nicht zu mappen, eine eigene ISIL haben sie aber jedenfalls. http://www.ub.tu-dortmund.de/Orgaplan/bereich.htm Gruss Michael -- Michael Neumann michael.neum...@uni-dortmund.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker
http://m.osmtools.de/ Gruß, - Bartosz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwischenstand Aerowest-Aktion
Am 27.09.2011 22:57, schrieb Christian H. Bruhn: Hallo! Irgendwie habe ich das Gefühl, daß die Aktion mit den Aerowest-Bildern im Sande verlaufen ist. Die Bilder sind nur sehr eingeschränkt nutzbar. Man muß einzelne Ausschnitte runterladen und diese in JOSM öffnen. Einige Wenige betreiben wohl den technische und zeitlichen Aufwand die Bilder zu laden. Aber die große Masse bleibt außen vor. Viele wissen wahrscheinlich gar nichts von den qualitativ sehr guten Bildern. Die technische Umsetzung ist allerdings mangelhaft. Es wurde doch immer von Dortmund als Beispiel erzählt. Dort hatte man aber einen WMS-Server, also nicht vergleichbar. Ich fühle mich über den Umfang der Aktion getäuscht und finde es schade, daß dafür 5.000 € Wikimedia-Spendengelder an ein kommerzielles Unternehmen gegangen sind. Fragen zum Projekt [1] sind übrigens seit einigen Monaten beantwortet. Anscheinend ist jetzt, nach dem das Geld geflossen ist, niemand mehr zuständig für das Projekt. Hätte z.B. nicht die FOSSGIS diese Aktion personell und technisch unterstützen können? Christian [1] http://wiki.openstreetmap.org/wiki/DE_talk:WissensWert/Luftbilder Hallo Christian, auf der einen Seite kann ich Deine Gedanken teilen auf der anderen Seite siehe die Häuser und Anpassungen die ich alleine in Lübeck schon erfaßt habe. Auch für Städte wie Lübeck könnte man mit etwas absprache sehr schnell und koordiniert die Bilder ziehen. Ich habe für meinen schon Übersichten erstellt damit andere diese nicht noch ziehen müssen - dann kann man die Bilder mit anderen tauschen. Siehe http://wiki.openstreetmap.org/wiki/L%C3%BCbeck/Style - WMS-Download / data sharing Wenn man sich am Sontag Rosemude Pilcher ansieht dann kann man mal wunderbar nebenbei eine große Fläche ziehen. Mir fehlt leider derzeit etwas die Zeit die Daten abzuzeichnen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker
Am 28.09.2011 09:27, schrieb Bartosz Fabianowski: http://m.osmtools.de/ Gruß, - Bartosz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hi ! das ist gut - so kenne ich das noch nicht. In meinem Links [1] werden immer noch die Bearbeitungsfunktionen (unten) angezeigt. Kann man diese irgendwie unterdrücken ? Gruß Jan :-) [1] http://m.osmtools.de/index.php?mlon=10.670533mlat=53.869304icon=7zoom=17 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker
In meinem Links [1] werden immer noch die Bearbeitungsfunktionen (unten) angezeigt. Kann man diese irgendwie unterdrücken ? Du könntest die Parameter an die Standard-OSM-URL anhängen. So wird aus [1] dann [2] und die Bearbeitungsfunktionen verschwinden - allerdings bekommst Du dann nur noch den roten Standardmarker. Gruß, - Bartosz [1] http://m.osmtools.de/index.php?mlon=10.670533mlat=53.869304icon=7zoom=17 [2] http://www.openstreetmap.org/?lon=10.670533lat=53.869304zoom=17mlon=10.670533mlat=53.869304icon=7 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker
Jan Tappenbeck schrieb am 28.09.2011 09:24: gibt es eigentlich eine Möglichkeit (außerhalb von esytools) eine OSM-Karte auf openstreetmap.org mit Marker zu erzeugen ? Eine Alternative wäre vielleicht manchmal noch sowas hier: http://www.openstreetmap.org/?node=991860789 http://www.openstreetmap.org/?way=77472286 Ist aber nicht so auffällig... -- Grüße Holger Jeromin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerke [ war urspr. landuse=road .. ]
Am 28. September 2011 04:41 schrieb Christian Müller cmu...@gmx.de: Am 27.09.2011 11:58, schrieb Martin Koppenhoefer: Am 26. September 2011 22:54 schrieb Christian Müllercmu...@gmx.de: Es werden beliebige Granularitäten erfasst, die über die Flächengrenze in Bezug (in Relation) stehen sollten. Die Granularitäten ergeben sich dann daraus, dass ein feiner granulares Gebiet in der Rolle 'inner' an einem grobgranularen Gebiet teilnimmt (das wiederum an einem grobgranulareren Gebiet teilnehmen /kann/, usw.). Interessieren einen Datennutzer feingranularere Gebiete nicht, lässt er die 'inner' Mitglieder einfach außer Acht. Am Beispiel des Forstgebiets mit Siedlungen: Forstgebiet (outer) Siedlung mit 2 Häusern (inner) Siedlung mit 5 Häusern (inner) Siedlung mit 350 Häusern (inner) +1: der Mapper entscheidet Je nachdem, wieviel Detail bei der Nutzung interessant ist, können die beiden kleineren Siedlungen oder alle weggefiltert werden, indem z.B. die Rollenmitgliedschaft oder die Flächengröße als Filterkriterium verwendet wird - evtl. sind auch andere / geeignetere Kriterien denkbar - das lässt sich separat erörtern.. Hier mal ein Beispiel aus dem echten Leben das schön erläutert, warum die Flächengröße (Grundfläche) ggf. unzureichend ist: Ein Forstgebiet mit 3 Häusern (und 1600 Einwohnern) in Stuttgart: http://www.openstreetmap.org/?lat=48.7248lon=9.19383zoom=16layers=M http://de.wikipedia.org/w/index.php?title=Datei:Hannibal_Stuttgart.jpgfiletimestamp=20061001221112 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Bibliotheken (ISIL) in einem Raum
Am 28.09.2011 08:47, schrieb Michael Neumann: Hallo, Bibliotheken haben ja normalerweise ein Bibliothekssigel (ISIL). Hat jemand eine Idee, wie man am besten zwei Bibliotheken kartiert, die sich am gleichen Ort (Node) befinden? Verwendet man zweimal den Key ref:isil oder bekommt er beide ISIL als Werte und wie wuerde man die dann trennen? Danke und Gruss Es sind 2 verschiedene Bibliotheken, die sich die Räumlichkeiten teilen. Also würde ich 2 Nodes mit ihren jeweiligen Eigenschaften (Name, ISIL etc.) in das Gebäude setzen. Raimond. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Bibliotheken (ISIL) in einem Raum
Hallo Michael. Auch innerhalb der Räumlichkeiten sind vermutlich die Bereichsbibliotheken voneinander abgrenzbar. Und selbst wenn nicht, sollte es doch möglich sein, für jede Bereichsbibliothek einen Node zu setzen mit den entsprechenden Informationen. Die sind dann vielleicht nah beieinander, aber das ist ja kein Problem. Die meisten Renderer werden es zumindest hinkriegen, korrekt ein Bibliothekssymbol draus zu machen; möglicherweise gehen allerdings einige Namen unter - im Kartenbild. Gruß Peter Am 28.09.2011 09:27, schrieb Michael Neumann: Am 28.09.2011 09:17, schrieb Georg Feddern: ganz pragmatisch würde ich erst mal sagen, dass das gar nicht sein kann. ;-) Von daher wäre es sinnvoll, hier konkretere Angaben (Permalink, Ortsangabe, Bibliotheksangabe) zu machen, damit man sich davon selbst ein Urteil bilden kann. An der TU Dortmund befinden sich z.B. die Bereichsbibliothek Bio- und Chemieingenieurwesen (BCT) und die Bereichsbibliothek Elektrotechnik und Informationstechnik (BE) in den gleichen Raeumlichkeiten. Ein weiteres Beispiel sind die Bereichsbibliothek Informatik (BI) und die Bereichsbibliothek Physik (BP), die sich in den gleichen Raeumlichkeiten befinden. unterscheiden sich die Bibliotheken denn tatsächlich nur im ISIL, nicht auch im Namen, Betreiber und/oder sonstigen Eigenschaften? Jedenfalls würde ich da ggf. eher zwei nodes draus machen - aber das hängt ggf. eben von den näheren Umständen ab - siehe oben. Ausser im Namen und in der ISIL gibt es keine Unterschiede. Man koennte eventuell auch der Meinung sein, Bereichsbibliotheken gar nicht zu mappen, eine eigene ISIL haben sie aber jedenfalls. http://www.ub.tu-dortmund.de/Orgaplan/bereich.htm Gruss Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28. September 2011 03:57 schrieb Christian Müller cmu...@gmx.de: Ein Wald endet an der Straßenfläche oder dem Ufer eines Flusses! ggf. kann das so sein Wenn die Straßenfläche in OSM durch eine Linie repräsentiert wird, und es zudem nicht gewünscht wird/wäre, dass eine Straßenfläche extra erfasst wird wer entscheidet, dass das nicht gewünscht ist? Manche Mapper machen das ja jetzt schon, hier und auf anderen Listen wurde jedenfalls schon öfters darüber diskutiert und es gibt durchaus eine Gruppe von Leuten, die gerne auch Straßenflächen zumindest stellenweise mappen wollen. , /dann/ ist es richtig, die Waldgrenze oder die Flussgrenze mit dieser Linie zu identifizieren. Man könnte auch argumentieren, dass dort in der Karte noch Flächen fehlen (Uferbereich, ggf. Straßenfläche bzw. Straßennebenflächen) und daher der Mapper erstmal den Wald (oder jede andere Fläche) bis an seine Grenze zeichnet, und später wird jemand evtl. die Straßenfläche oder Uferfläche ergänzen. Wir haben in OSM ja immer work-in-progress und nie eine endgültige Situation. All das ändert nichts daran, dass an jeder Flächengrenze mindestens zwei Flächen teilnehmen (von überlappenden Flächen, Enklaven, einmal abgesehen). und auch abgesehen von fehlenden Flächen, die vorübergehend dazu führen können, dass eine Fläche auch mal nirgends angeschlossen werden kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker
Wenn dir der rote Standard-Marker reicht, kannst du im Permanentlink von osm.org lat und lon in mlat bzw mlon umbenennen, und der Mittelpunkt wird entsprechend mit 'nem marker markiert. Wenn Du mlat und mlon ZUSÄTZLICH zu lat und lon einträgst, kannst du auch 'nen marker abseits des Mittelpunkts setzen. Beispiel: http://www.openstreetmap.org/?mlat=51.3mlon=10.5lat=51lon=8zoom=5layers=M Gruß Peter Am 28.09.2011 09:24, schrieb Jan Tappenbeck: Hi ! gibt es eigentlich eine Möglichkeit (außerhalb von esytools) eine OSM-Karte auf openstreetmap.org mit Marker zu erzeugen ? 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] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28. September 2011 05:36 schrieb Christian Müller cmu...@gmx.de: Am 27.09.2011 11:49, schrieb Martin Koppenhoefer: Weshalb diskutieren wir darüber eigentlich - einen closed way derselben Länge / desselben Detailgrads müsste schließlich auch in den Editor geladen werden, um ihn zu bearbeiten - das wiederum _immer_ komplett. Ich sehe hier den Bezug nicht, den Du zum aktuellen Thema herstellen möchtest. wenn wir von einer Nachricht zur nächsten den Bezug vergessen bringt die Diskussion wirklich nichts. Der Bezug war: im Zweifel lieber fragmentieren als zusammenfassen. Eine weitere Frage ist, ob, wenn es solche Monster gibt, nicht schon vorher etwas falsch gelaufen ist.. Schließlich müssen sie ja erstmal da sein, bevor ich sie auseinandersplitte. ganz genau Von Mythen war bei mir keine Rede, schau einfach mal nach Japan in die Wälder und versuche, einen der Riesenwälder in kleinere Stücke zu teilen. Link? Ich habe mal ein enorm großes Waldstück geteilt, welches basisgeometrisch erfasst war - ich kann nicht behaupten, dass das einfacher war. Wenn Du Dich dort betätigen willst, da wären Dir vermutlich einige dankbar, im Prinzip ist wohl ganz Japan betroffen, ein Beispiel ist glaube ich hier: http://www.openstreetmap.org/?lat=35.104lon=134.106zoom=10layers=M Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein klares Usability-Problem und kein Problem von Multipolys an sich. nein, das Problem ist dem Datenmodell immanent, wie sollte das denn sonst funktionieren? Wenn durch diese Operation eine neue Version entsteht, dann evtl. aufgrund eines Konfliktes? das verstehe ich nun nicht Es wäre vielleicht besser, die (echten) Probleme mit Multipolygonen beim Namen zu nennen. Das Konzept /Multipolygon/ ist gut, die Editorumsetzung dürftig. Warum schließt Du dich dieser Sichtweise nicht einfach an, wenn es in deiner Gegend ohnehin schon usus ist, sie zu benutzen? wie bereits verschiedentlich erwähnt bin ich kein Gegner der Multipolygone --- im Gegenteil nutze ich sie fast täglich. Ich hatte lediglich einen Hinweis angebracht, dass man aufpassen sollte, diese nicht zu groß und komplex werden zu lassen, weil sonst a) die Bearbeitung schwierig und langwierig wird b) im Laufe der Zeit unzählige Versionen der Relation entstehen, weil jede kleine Änderung eine neue Version entstehen lässt c) das Rendern und andere Weiterverarbeitung unnötig aufwändig werden Lieber fragmentieren als zusammenfassen war dazu die Empfehlung. Je größer und gröber man das anfängliche Polygon macht, um so komplexer wird tendenziell (je nach Kontext) das entstehende Multipolygon-objekt im Laufe der Zeit. Ich habe das hier verschiedentlich beobachtet. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Bibliotheken (ISIL) in einem Raum
Ja, 2 Nodes gehen immer, wenn es 2 Bibliotheken sind, würde ich auch 2 Objekte machen. Wenn man es flächig machen will, dann würde ich 2 Multipolygone machen, je Bibliothek eins (im einfachsten Fall jeweils mit einem outer way als Member). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 00:33 schrieb Garry GarryD2@gmx. Multipolygone führen dazu dass ähnliche Flächengrenzen zusammengefasst werden damit es übersichtlich aussieht (weil nur noch eine statt viele Linie im Editor zu sehen ist) aber in Wahrheit die realen Flächengrenzen verfälscht. Ein Wald endet nicht an der Mittellinie einer Strasse oder eines Flusses! Das ist Quatsch und das weißt du vermutlich auch selbst. Die Benutzung von Multipolygonen und das zusammenlegen von Flächengrenzen und Linienobjekten (Straßen,...) sind zwei verschiedene Dinge. Es gibt genügend Mapper, die auch “normale“ Flächen an Straßen etc. anpappen - diejenigen, die dies ablehnen (wie ich) werden wohl auch bei der Nutzung von MPs nicht plötzlich damit anfangen. Diese Frage taugt also nicht als Argument gegen MPs. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rundwanderweg wird aufgegeben - disused relation?
Am 27.09.11 21:22, schrieb Bernhard Weiskopf: Hallo Henning und Mitleser, das kann man sicherlich unterschiedlich betrachten. Aus meiner Sicht muss eine Route nicht zwangsläufig in der Natur makiert sein, manche Routen sind nur in Karten markiert. Das widerspricht aber dem OSM-Grundsatz, dass wir nur *nachprüfbare* Tatsachen (hier: Wegmarkierungen) in unsere Datenbank eintragen. Tourenportale mit selbst zusammengestellten Routen gibt es anderswo zuhauf. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Bibliotheken (ISIL) in einem Raum
Am 28.09.2011 11:01, schrieb Martin Koppenhoefer: Ja, 2 Nodes gehen immer, wenn es 2 Bibliotheken sind, würde ich auch 2 Objekte machen. Wenn man es flächig machen will, dann würde ich 2 Multipolygone machen, je Bibliothek eins (im einfachsten Fall jeweils mit einem outer way als Member). Danke fuer eure Antworten, werde dann jeweils einen Node pro Bibliothek anlegen. Gruss Michael -- Michael Neumann michael.neum...@uni-dortmund.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 11:31, schrieb Martin Simon: Die Benutzung von Multipolygonen und das zusammenlegen von Flächengrenzen und Linienobjekten (Straßen,...) sind zwei verschiedene Dinge. +1 full ack. Evtl. lässt sich das sogar erweitern: Das Zusammenlegen von Flächengrenzen zum einen Flächengrenzen mit Linienobjekten zum anderen sind auch verschiedene Dinge - über die sich auch getrennt reden lässt. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker
Am 28.09.2011 10:00, schrieb Jan Tappenbeck: Hi ! das ist gut - so kenne ich das noch nicht. In meinem Links [1] werden immer noch die Bearbeitungsfunktionen (unten) angezeigt. Kann man diese irgendwie unterdrücken ? Für den IFrame wird das ausgeblendet, also iframe=1 an die URL hängen: http://m.osmtools.de/index.php?mlon=10.670533mlat=53.869304icon=7zoom=17iframe=1 Gruß Gruß Jan :-) [1] http://m.osmtools.de/index.php?mlon=10.670533mlat=53.869304icon=7zoom=17 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi Martin, Am 28.09.2011 10:45, schrieb Martin Koppenhoefer: wenn wir von einer Nachricht zur nächsten den Bezug vergessen bringt die Diskussion wirklich nichts. Der Bezug war: im Zweifel lieber fragmentieren als zusammenfassen.(*) lecker. Ich weiß nicht, ob die Möglichkeit, bestimmte Bezüge nicht herstellen zu können, rechtfertigt, anderen das Vergessen vorzuwerfen. Es macht keinen Sinn, im Kontext dieser (*)-Regel, von einem Unterschied zwischen MP und closed ways zu sprechen, denn sie passt durchaus auf beide dieser Arten, Flächen zu erfassen. MP bilden da /keine/ Ausnahme. Deshalb habe ich die Frage gestellt, weshalb Du (*) überhaupt als Argument bringst - es ist kein Argument für oder gegen eine bestimmte Mappingpraxis, wenn alle Praxen Möglichkeiten der Fragmentierung bieten. closed way-Flächen können bel. fragmentiert werden, man zerreißt dabei i.d.R. das Original. MP-Flächen können fragmentiert werden, ohne das Original zu zerreißen, sie fragmentieren UND fassen zusammen. Ein Argument gegen MP-Flächen ist, dass solche MP, die sehr viele Flächengrenzen zu einer Fläche zusammenfassen, so groß werden können, dass .. sie nicht mehr handhabbar sind. .. und deshalb sollte man sie nicht nutzen.. Erstens trifft das nur für MPs zu, die größer sind als ihr closed way-Pendant (die also schon zusammenfassen..) und zweitens bedeutet die Möglichkeit, dass man zusammenfassen /kann/, nicht, dass man zusammenfassen /muss/. Drittens /ist/ die Nicht-Verwaltbarkeit von wirklich umfangreichen MPs hauptsächlich ein usability-Problem, dass sich u.a. schon dadurch lösen lässt, dass umfangreiche MP in Kind-Relationen ausgelagert werden können. Z.B. durch Gruppierung der 10.000+ outer ways in Kind-Relationen, die dann als 'outer' an einer Eltern-Relation teilnehmen. Die /Möglichkeit/ mit MPs komplexe Flächen mit 10.000+ Grenzsegmenten zu bilden, bietet Lösungen für Probleme, welche mit closed ways überhaupt nicht, oder mindestens genauso schwer, zu lösen sind. Weshalb sollte man also closed ways, welche in solchen Grenzbereichen ebenso versagen, in ein besseres Licht rücken, als MPs, die zwar die /Möglichkeit/ bieten, in solche Bereiche vorzudringen, aber erst dort schwer zu handhaben sind? Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein klares Usability-Problem und kein Problem von Multipolys an sich. nein, das Problem ist dem Datenmodell immanent, wie sollte das denn sonst funktionieren? Du schriebst: Beim Splitten eines ways, entsteht eine neue Version des kompletten Multipolygons. /So/ entstünden schnell /Unmengen/ an Versionen von riesigen Objekten. Ich schrieb: /Dies/ ist ein usability Problem. /Das/ /Unmengen/ von Objekten erzeugt werden, liegt doch nicht am Datenmodell - dieses zwingt den Programmierer deines Editors mitnichten, jedes Mal eine neue Version eines MP zu erzeugen, wenn ein way member gesplittet wird. Wenn durch diese Operation eine neue Version entsteht, dann evtl. aufgrund eines Konfliktes? das verstehe ich nun nicht Manchmal in JOSM, und das betrachte ich pers. auch als Krankheit, kannst Du eine Relation mit dem Rel.-Dialog öffnen. Du kannst dort lustig ways hinzufügen und entfernen. Da dieser Dialog natürlich nicht modal arbeitet, kannst Du im MapView, während der Dialog noch geöffnet ist, die Basisgeometrien ändern, sprich ways splitten oder löschen, die an der Relation teilnehmen. Da das ganze Prozedere nicht synchronisiert stattfindet, kann, wenn der Relationen-Dialog geschlossen wird, dieser eine andere Version der Relation vorhalten, als das im Editor geladene Dataset - Konflikt wird erzeugt. Üblicherweise verschwindet aber nach Lösung des Konflikts die ungewünschte Version der Relation wieder. Evtl. könnte der Relationen-Dialog selbst Observer des DataSets sein, um das zu vermeiden. Aber dies und das Erzeugen von Unmengen neuer Versionen in einem Editor sind für mich editor-spezifische Details. ... dass man aufpassen sollte, diese nicht zu groß und komplex werden zu lassen, weil sonst a) die Bearbeitung schwierig und langwierig wird +/- 1 Das ist momentan evtl. richtig, je nach tatsächlicher Komplexität. Dies trifft aber z.T. auch auf riesige closed ways und dergleichen zu. Das ist, in beiden Fällen, zunächst ein usability-Problem, welches sich mit MPs einfacher lösen lässt, als mit closed ways - letztere lassen sich im Editor nicht getrennt laden (obwohl das denkbar ist, schließlich ist ein Weg auch nur eine Knotenliste, welche sich als Relation interpretieren lässt). b) im Laufe der Zeit unzählige Versionen der Relation entstehen, weil jede kleine Änderung eine neue Version entstehen lässt Das verstehe ich nach wie vor nicht, und
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 10:26, schrieb Martin Koppenhoefer:
.. und es zudem nicht
gewünscht wird/wäre, dass eine Straßenfläche extra erfasst wird
wer entscheidet, dass das nicht gewünscht ist?
ich nicht, deshalb habe ich dazu keine Aussage getroffen. vielleicht
Joe Mapper ;-)
Wenn die Datenlage gut ist (Luftbilder), würde ich das auch gutheißen.
Nur ist da natürlich wieder auszudiskutieren, /wie/ - Konsens fürs
tagging usw. muss gefunden werden - Garry sprach schon an, welches
Verwechslungspotenziale bestehen: Verkehrsfläche vs. Gesamtfläche der
Straße (mit Entwässerungsanlagen, Schallschutzbauten, etc.)..
Wenn die entsprechende landuse=road Seite im Wiki nach aktuellem
Wissensstand (des Projekts) erklärt, was genau damit gemappt werden
soll, ist schonmal viel getan - ansonsten wird das Tag irgendwann so
unklar verwendet, wie landuse=residential (eine neblige Sammlung der
Verständnisse und Interpretationen aus verschiedenen Themenbereichen und
Kontexten, nicht nur notwendigerweise auf die Bodennutzung Bezug nehmend).
, /dann/ ist
es richtig, die Waldgrenze oder die Flussgrenze mit dieser Linie zu
identifizieren.
Man könnte auch argumentieren, dass dort in der Karte noch Flächen
fehlen (Uferbereich, ggf. Straßenfläche bzw. Straßennebenflächen) und
daher der Mapper erstmal den Wald (oder jede andere Fläche) bis an
seine Grenze zeichnet, und später wird jemand evtl. die Straßenfläche
oder Uferfläche ergänzen. Wir haben in OSM ja immer work-in-progress
und nie eine endgültige Situation.
+1 full ack. Gerade deswegen fand und finde ich es unsinnig, immer und
überall Platz zu lassen - wenn jemand später mehr Detail ergänzen
möchte, wird der sich nicht daran stören, dass da schon etwas
(ungenaueres) ist. /Wie/ er dann sein Detail ergänzt, ist seiner
eigenen Einschätzung überlassen ( werden die Grenzen des groben Gebiets
verschoben und eine neues erzeugt ('outer'-Rolle)? oder wird sein
Detail /als Teil/ eines der vorhandenen, groben Gebiete erfasst
('inner'-Rolle)? )..
All das ändert nichts daran, dass an jeder Flächengrenze mindestens zwei
Flächen teilnehmen (von überlappenden Flächen, Enklaven, einmal abgesehen).
[..] abgesehen von fehlenden Flächen, die vorübergehend dazu
führen können, dass eine Fläche auch mal nirgends angeschlossen werden
kann.
+1
Gruß,
Christian
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verweise auf dev.openstreetmap.de kaputt
Moin, Am 27.09.2011 18:07, schrieb fla...@googlemail.com: Hinweisen möchte ich drauf das es dann auch imer frische Logfile mit vielen Fehlern gibt ... http://dev.openstreetmap.de/aio/mkgmap-errors/ Das ist aber zZ nicht userfreundlich aufgebaut. Hilfe / Vorschläge per Mail gerne an mich. vielleicht nicht sehr userfreundlich, aber doch zumindest verständlich - und grundsätzlich hilfreich. Ich habe mal kurz exemplarisch die mich interessierenden Fehler (70013119.txt vom 2011/09/27) angetestet und dabei ein paar Unschönheiten entdeckt - auf die Du aber evtl. gar keinen Einfluß hast? WARNING (MultiPolygonRelation): Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/51477 Geht auch gar nicht, da das ja nur mit einem Bruchteil aller ways des Multipolygons versucht wird. Erzeugt also zuviele 'false positives' (nach 5 hab ich aufgegeben). OK, ich verstehe den Unterschied zwischen Warning und Error - aber kann man nicht evtl. doch vorher abprüfen, ob die Anzahl der 'joined ways' mit der Gesamtanzahl übereinstimmt? Multipolygon http://www.openstreetmap.org/browse/relation/173745 contains errors. Some polygons are intersecting. This is not allowed in multipolygons. Bei den drei von mir überprüften sind diese Fehler definitiv nicht vorhanden - waren es auch nie, habe die History aller Elemente überprüft. Allerdings nähern sich dort die beiden Wege auf 0,6 m bzw. bei einem sogar bis auf 0,04 m. Evtl. ein Auflösungs-/Rundungsproblem? Mehr konnte ich bis jetzt leider noch nicht testen - aber ich bleibe mal dran. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Suburb vs. Village
On 26.09.11 18:14, Martin Koppenhoefer wrote: bisher wird das in der jeweiligen boundary-Relation gemacht, indem ein Node (könnte auch ein Way sein) mit dieser Rolle eingefügt wird. Davon hatte ich gesprochen. Mir fallen eben die Rollen admin_centre und label ein, die schon so durchs OSM-Universum geistern. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerke [ war urspr. landuse=road .. ]
Am 28.09.2011 10:16, schrieb Martin Koppenhoefer: Hier mal ein Beispiel aus dem echten Leben das schön erläutert, warum die Flächengröße (Grundfläche) ggf. unzureichend ist: Ein Forstgebiet mit 3 Häusern (und 1600 Einwohnern) in Stuttgart: +1 insbesondere zu ggf.: Das ist hier ein kleines wichtiges Wörtchen - es gibt Anwendungen, für die die Existenz auch dieses mini-landuse mit 1600 Einwohner bei der Betrachtung des Forstgebiets keine Rolle spielt (z.B. bei der Flächenversiegelung - die ist hier, gegenüber dem Forstgebiet, sehr klein und evtl. vernachlässigbar), genau so, wie es in anderen Anwendungen entscheidend ist, diese 3 Häuser in Betracht zu ziehen (Einwohnerdichte, etc.). Danke für dieses Beispiel zur Granularität. Es legt den Gedanken nahe, die Bedeutung eines landuse=residential zu irgendeinem anderen landuse=residential dadurch anzugeben, dass grob die Einwohnerzahl (population=* gibt es ja schon) mitgetaggt wird. Dadurch hätte man zwei weitere Filterkriterien neben der Flächengröße: die Einwohnerzahl und die -dichte. Das Beispiel ist wirklich verdammt gut, um aufzuzeigen, dass allein die Betrachtung der Flächengröße nicht für jeden Anwendungsfall ausreicht. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suburb vs. Village
On 26.09.11 17:17, Martin Koppenhoefer wrote: nö, ist aber auch egal. Manhattan ist ziemlich sicher ein suburb in OSM http://www.openstreetmap.org/browse/node/158810611 - Hamlet Manhattan http://www.openstreetmap.org/browse/node/158875120 - Hamlet Harlem http://www.openstreetmap.org/browse/node/158857828 - Hamlet Brooklyn Aber egal. IMO müssen griffige Begriffe her (city_district, neighbourhood halte ich zB für griffig), nicht zweifelhafte/solche mit verschiedensten Deutungen (suburb, quarter)! Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verweise auf dev.openstreetmap.de kaputt
Zu beachten ist auch das die Logs die aus MKGMAP rausfallen sich auf Daten beziehen nachdem sie vom Splitter verzlgt und aufgeteilt wurden. Turn restriction und Oneways kann man aber ganz gut verbessern. Dirk Am 28. September 2011 16:40 schrieb Georg Feddern o...@bavarianmallet.de: Moin, Am 27.09.2011 18:07, schrieb fla...@googlemail.com: Hinweisen möchte ich drauf das es dann auch imer frische Logfile mit vielen Fehlern gibt ... http://dev.openstreetmap.de/aio/mkgmap-errors/ Das ist aber zZ nicht userfreundlich aufgebaut. Hilfe / Vorschläge per Mail gerne an mich. vielleicht nicht sehr userfreundlich, aber doch zumindest verständlich - und grundsätzlich hilfreich. Ich habe mal kurz exemplarisch die mich interessierenden Fehler (70013119.txt vom 2011/09/27) angetestet und dabei ein paar Unschönheiten entdeckt - auf die Du aber evtl. gar keinen Einfluß hast? WARNING (MultiPolygonRelation): Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/51477 Geht auch gar nicht, da das ja nur mit einem Bruchteil aller ways des Multipolygons versucht wird. Erzeugt also zuviele 'false positives' (nach 5 hab ich aufgegeben). OK, ich verstehe den Unterschied zwischen Warning und Error - aber kann man nicht evtl. doch vorher abprüfen, ob die Anzahl der 'joined ways' mit der Gesamtanzahl übereinstimmt? Multipolygon http://www.openstreetmap.org/browse/relation/173745 contains errors. Some polygons are intersecting. This is not allowed in multipolygons. Bei den drei von mir überprüften sind diese Fehler definitiv nicht vorhanden - waren es auch nie, habe die History aller Elemente überprüft. Allerdings nähern sich dort die beiden Wege auf 0,6 m bzw. bei einem sogar bis auf 0,04 m. Evtl. ein Auflösungs-/Rundungsproblem? Mehr konnte ich bis jetzt leider noch nicht testen - aber ich bleibe mal dran. Gruß Georg ___ 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] landuse, highway, alles über- und ineinander...
Auf die dauer wird es nicht gutgehen, wenn dies zeux alles so kleinteilig zusammengebrutzelt wird... So hat's hier in N die Krelingstraße verrissen: http://www.openstreetmap.org/?lat=49.46012lon=11.07844zoom=17layers=M und ich weiß nicht, wie ich das mit meinem josm ohne löschen und neuzeichnen wiederherstellen kann... Ich vermute, dass das passiert ist, als jemand so mini-landuse-sachen reingefummelt hat. Die straßen und insbesondere hauptstraßen in wohngebieten sollten nicht als grenzen für residentials herhalten, wenn dies nicht zwingend erforderlich ist. Wenn auf beiden seiten einer straße residential ist, dann pinselt man den highway einfach drüber und fertig. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suburb vs. Village
Am 28. September 2011 16:57 schrieb Andreas Labres l...@lab.at: On 26.09.11 17:17, Martin Koppenhoefer wrote: nö, ist aber auch egal. Manhattan ist ziemlich sicher ein suburb in OSM http://www.openstreetmap.org/browse/node/158810611 - Hamlet Manhattan http://www.openstreetmap.org/browse/node/158875120 - Hamlet Harlem http://www.openstreetmap.org/browse/node/158857828 - Hamlet Brooklyn Aber egal. ich meinte nicht: in der OSM-Karte sondern gem. dem OSM-tagging-System (d.h. nicht wie es tatsächlich getaggt ist, sondern wie es m.E. vermutlich sein sollte). Je nachdem, welches Manhattan man meint, kann auch place=island zutreffend sein (bzw. ein administratives Gebiet Manhattan (borough), welches auch ein paar andere Inseln miteinschließt). - es gibt schon hier mind. 2 Manhattan in der Realität, d.h. logischerweise könnte es auch in OSM mehrere geben. Siedlungsgeographisch ist Manhattan allerdings ein klarer Fall weil es rundum von Flüssen begrenzt wird, d.h. man wird kaum über die Grenzen streiten ;-) http://en.wikipedia.org/wiki/Manhattan#Geography IMO müssen griffige Begriffe her (city_district, neighbourhood halte ich zB für griffig), nicht zweifelhafte/solche mit verschiedensten Deutungen (suburb, quarter)! Ja, wenn man place=suburb (immerhin schon 53 979 mal in Gebrauch) anzuzweifeln bereit ist, also nochmal grundsätzlich neu herangeht, dann wäre ich da auch für einen anderen Begriff. Allerdings wird man das immer definieren müssen, city_district ist auch nicht klarer als quarter in der Bedeutung (Wikipedia schreibt dazu jedenfalls: City district is a type of administrative division of Pakistan and Croatia. It is also the English translation of German Stadtbezirk and Swedish Stadsdel.), nach meinen bisherigen Recherchen scheint district ausschließlich eine Verwaltungseinteilung zu sein, während quarter eher im vagen bleibt und mir daher als allgemeine Unterteilung in place besser geeignet scheint: http://en.wikipedia.org/wiki/Quarter_(country_subdivision) . Übrigens, zur Sprachbedeutung: selbst place=city ist nicht wirklich klar, s. http://en.wikipedia.org/wiki/Cities wo für jedes Land einzeln versucht wird zu definieren, was eine city ist, wobei allerdings die Seite mit Vorsicht zu genießen ist, die Aussagen zu Deutschland und Italien sind schon in sich nicht konsistent. Oft findet man für city auch: mehr als 20.000 Einwohner und ökonomisch selbsttragend im Gegensatz zu Schlafstädten und Vororten, d.h. city als Großstadt zu übersetzen ist auch nur eine von mehreren Möglichkeiten, Stadt trifft es teilweise besser. Langer Rede kurzer Sinn: wir (müssen) definieren, was ein bestimmter tag bedeutet. Zwar sollte die sprachliche Bedeutung der in OSM nicht diametral entgegenstehen, aber nur mit sprachlichem Verständnis/Bedeutung kommt man auch nicht weit. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker - Doku dazu ?
Am 28.09.2011 15:01, schrieb Sebastian Hohmann: Am 28.09.2011 10:00, schrieb Jan Tappenbeck: Hi ! das ist gut - so kenne ich das noch nicht. In meinem Links [1] werden immer noch die Bearbeitungsfunktionen (unten) angezeigt. Kann man diese irgendwie unterdrücken ? Für den IFrame wird das ausgeblendet, also iframe=1 an die URL hängen: http://m.osmtools.de/index.php?mlon=10.670533mlat=53.869304icon=7zoom=17iframe=1 Gruß Gruß Jan :-) [1] http://m.osmtools.de/index.php?mlon=10.670533mlat=53.869304icon=7zoom=17 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hi ! woher kennst Du die Parameter - gibt es eine Doku ? Gruß Jan .-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28. September 2011 16:19 schrieb Christian Müller cmu...@gmx.de: Sobald man an einem riesigen Multipolygon mit hunderten von Membern irgendwo einen way teilt entsteht gleich eine neue Version des kompletten Multipolygons. So entstehen sehr schnell Unmengen an Versionen von riesigen Objekten. In welchem Editor? Wenn es so ist, wie Du es beschreibst, ist das ein klares Usability-Problem und kein Problem von Multipolys an sich. nein, das Problem ist dem Datenmodell immanent, wie sollte das denn sonst funktionieren? Ich schrieb: /Dies/ ist ein usability Problem. /Das/ /Unmengen/ von Objekten erzeugt werden, liegt doch nicht am Datenmodell - dieses zwingt den Programmierer deines Editors mitnichten, jedes Mal eine neue Version eines MP zu erzeugen, wenn ein way member gesplittet wird. nochmal: wie sollte das denn sonst gehen? Liegt sehr wohl am Datenmodell. (klar, die Version entsteht erst beim Hochladen, nicht bereits beim Splitten im Editor). Manchmal in JOSM, und das betrachte ich pers. auch als Krankheit, kannst Du eine Relation mit dem Rel.-Dialog öffnen. Du kannst dort lustig ways hinzufügen und entfernen. Da dieser Dialog natürlich nicht modal arbeitet, kannst Du im MapView, während der Dialog noch geöffnet ist, die Basisgeometrien ändern, sprich ways splitten oder löschen, die an der Relation teilnehmen. ach so, das meinst Du. Das ist in der Tat eher ein Editor-Problem (evtl. könnte der Editor Änderungen in der Karte in den Fenstern der geöffneten Relationen jeweils live nachführen). Konflikte durch parallele Edits (verschiedener Mapper) entstehen allerdings auch (weiterer Punkt) um so eher, je ausgedehnter ein Objekt ist. c) das Rendern und andere Weiterverarbeitung unnötig aufwändig werden Aberglaube. Es ist ein anderer Aufwand, nicht mehr oder weniger unnötig als der, den man ohne MP betreibt. IIRC werden MPs z.B. von Renderern ohne zu Murren gehandhabt. Zudem ist es möglich, simple Tools zu schreiben, welche Dir Multipolygone in closed ways konvertieren - probiere das mal anders herum. Bestimmte Arten der Weiterverarbeitung profitieren durch MP. ich meine nicht beim Importieren des MP in den Editor. Wenn ein Wald sich über 2500 km² hinzieht, mit allen kleinen Lichtungen und anderen inner ways, dann musst Du beim Rendern das komplette Monster in jedem einzelnen zoom18-Tile betrachten (glaube ich zumindest), obwohl nur ein winziger Teil in Deinem Kartenausschnitt liegt. Wenn man den Wald an jeder größeren Straße auftrennt, wird er kleiner (weniger Versionen bzw. kleinere Versionen, schneller zu rendern, weniger potentielle Konflikte). Es ist natürlich richtig, dass man sowohl mit Einzelflächen als auch mit Multipolygonen eher groß oder eher fragmentiert arbeiten kann, aber wenn man von vornherein riesige Flächen erzeugt ist es sehr wahrscheinlich, dass der nächste Mapper da einfach per Multipolygon was rausschneidet. Je mehr das machen, um so eher wird das ein Monster. Wenn man dagegen fragmentiert beginnt, dann ist die Chance größer, dass der nächste Mapper so weitermacht und irgendwann aus diesem Flickenteppich ein Bild wird (übrigens ein detailliertes, weil von vornherein kaum Vergröberung drin ist). Mit Deinem Plädoyer für Multipolygone bei Grenzen rennst Du offene Türen ein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse, highway, alles über- und ineinander...
Am 28. September 2011 18:15 schrieb Karl Eichwalder k...@gnu.franken.de: Auf die dauer wird es nicht gutgehen, wenn dies zeux alles so kleinteilig zusammengebrutzelt wird... So hat's hier in N die Krelingstraße verrissen: http://www.openstreetmap.org/?lat=49.46012lon=11.07844zoom=17layers=M Könntest Du kurz erläutern, was dort das Problem ist? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse, highway, alles über- und ineinander...
Martin Koppenhoefer dieterdre...@gmail.com writes: Am 28. September 2011 18:15 schrieb Karl Eichwalder k...@gnu.franken.de: Auf die dauer wird es nicht gutgehen, wenn dies zeux alles so kleinteilig zusammengebrutzelt wird... So hat's hier in N die Krelingstraße verrissen: http://www.openstreetmap.org/?lat=49.46012lon=11.07844zoom=17layers=M Könntest Du kurz erläutern, was dort das Problem ist? Die Krelingstraße kommt von N und geht in natura weiter über die Pirckheimer, dann an dieser kirche vorbei und biegt schließlich nach W um auf den Vestnertorgraben zu (wo diese andere kirche ist). Momentan (in unseren daten) biegt sie aber schon auf der Pirckheimer um nach W und geht dann auf der Piloty hoch zum Vestnertorgraben (wo diese andere kirche ist). Siehe Attachment: [Attachment gelöscht...] Ich hoffe, es wird jetzt etwas klarer. Die treppe oberhalb (südlich) der kirche endet völlig unsinning in einer landuse-begrenzung. Ich könne schwören, dass ich die treppe vor jahr und tag mit der straße verbunden hatte... -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [Karl Eichwalder] Re: landuse, highway, alles über- und ineinander...
Noch ein versuch... -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [WISY-Spam]Anzeigenamen im Garmin 62x beeinflussen
Hi ! ich rechne meine Karten immer selber mit mkgmap, splitter und gmaptools. In meinem Garmin steht dann als Kartenname immer gmaptool. Weiß einer von Euch ob man irgendwie den Namen beeinflussen kann - die Reit und Wanderkarte hat in der Anzeige auch einen anderen Namen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Hi Martin, Am 28.09.2011 19:40, schrieb Martin Koppenhoefer: nochmal: wie sollte das denn sonst gehen? Liegt sehr wohl am Datenmodell. (klar, die Version entsteht erst beim Hochladen, nicht bereits beim Splitten im Editor). Ah, ok - Du beziehst Dich in der Tat auf den Versionszähler /eines/ Multipolygons und nicht darauf, dass /mehrere/ Multipolygone entstehen - das kam in der ursprünglichen mail nicht so rüber - meine Frage an Dich muss also anders lauten: Wo liegt für Dich das Problem, wenn der Versionsstand eines Multipolygons bei 249.000 steht? Schließlich beschäftigen wir uns beim Editieren eigentlich nur mit dem aktuellen Stand. Und beim Editieren ohne MP entstehen schließlich auch Unmengen an Versionsständen (z.B. von ways oder nodes). , dann musst Du beim Rendern das komplette Monster in jedem einzelnen zoom18-Tile betrachten (glaube ich zumindest), obwohl nur ein winziger Teil in Deinem Kartenausschnitt liegt. Wenn man den Wald an jeder größeren Straße auftrennt, wird er kleiner (weniger Versionen bzw. kleinere Versionen, schneller zu rendern, weniger potentielle Konflikte). Folgen wir dieser Argumentation, ohne zu Betrachten, wie 'teuer' die Beantwortung der Inklusionsfrage von Z18-Tiles bezüglich MP-Monstern wirklich ist. Das einzige, was Du dann erreichst, ist, dass die Renderzeit für Kacheln auf hoher Zoomstufe sinkt, auf niedriger aber enorm steigt. Was wir aber eigentlich wollen, ist das beides vernünftig läuft. Also MP-Monster für niedrige Zoomstufen, und normale MPs als inners von inners von inners (..) vom MP-Monster. Es ist nicht ganz wahr, dass für jede Z18-Kachel das ganze Monster jedes Mal von neuem betrachtet wird - Du musst für die meisten Kacheln nur wissen, ob sie innerhalb oder außerhalb des Monsters liegen. Das wird im Zusammenhang mit ein paar Rechteck-Bäumen als cachende Datenstruktur für die Bounding-Boxes dieser Monster i.d.R. vernachlässigbar. Dazu unten mehr. Es ist natürlich richtig, dass man sowohl mit Einzelflächen als auch mit Multipolygonen eher groß oder eher fragmentiert arbeiten kann, aber wenn man von vornherein riesige Flächen erzeugt ist es sehr wahrscheinlich, dass der nächste Mapper da einfach per Multipolygon was rausschneidet. Je mehr das machen, um so eher wird das ein Monster. Wenn man dagegen fragmentiert beginnt, dann ist die Chance größer, dass der nächste Mapper so weitermacht und irgendwann aus diesem Flickenteppich ein Bild wird (übrigens ein detailliertes, weil von vornherein kaum Vergröberung drin ist). Auf welchem Zoomlevel entsteht denn da ein Bild? Auf einem ganz bestimmten.. Es ist nicht immer auf einfache Weise möglich, per render-regel ein microgemapptes Gebiet sinnvoll auch für niedrigeren Zoom zu erzeugen. Ich sehe das, mal nur für die Renderinggeschichte, so: Wenn es einen 2500 km² großes Multipolygon als Wald gibt und eine Kachel für niedrigen Zoom gerendert werden soll, dann reicht es ggf. aus (hängt vom Zoom ab), nur den outer-way zu betrachten, und die 'inner' zu ignorieren. Das heißt, ich muss mir dieses Waldgebiet nicht erst zusammenbauen, bzw. mehrere Fetzen davon rendern, im Falle dass es an jeder Straße aufgetrennt vorliegt (evtl. werden ja auch manche Straßen auf einem niedrigen Zoom nicht angezeigt). Mehrere Fetzen auf einem niedrigen Zoom zu rendern ist aufwendiger, als den großen Batzen zu rendern: weil dann alle innenliegenden Grenzen mitberechnet werden müssen, nicht nur die wichtige, entscheidende, außen umliegende Grenze des Gebietes. Umgekehrt, wenn wir uns auf Z18 befinden, und das Tile liegt komplett innerhalb eines Polygons, dann ist auch nur dieses kleinste umliegende MP für eine Färbung interessant. Für den Fall, dass die kleineren Strukturen des großen Waldgebietes als 'inner's und 'inner's von 'inner's gemappt sind, muss also für das Z18-Tile nicht der große Batzen betrachtet werden. Angenommen das kleinste umliegende MP ist aber dieses 2500 km² Waldgebiet, dann stellt sich für die meisten Z18-Tiles nur die Frage, ob sie innerhalb oder außerhalb der Fläche liegen. Dieses Problem hast Du sowohl mit einem closed way, als auch mit einem MP und die Inklusionsfrage ist mittels gecachten bounding-boxen des MP in annehmbarer Zeit lösbar. Dein Ansatz, nach bottom-up Manier erst kleine Gebiete zu erfassen, ist in der Praxis gerade für große, unbesiedelte Gebiete nicht brauchbar - da existieren oft nur grobe Satfotos mittels derer man grob ein riesiges Gebiet erfassen kann - und das ist besser als gar nichts, bzw. besser, als darauf zu warten, dass in 10 Jahren dasselbe Gebiet auf Z16 detailiert erfasst ist. Das wir beide zusammenbringen können (den, der von unten auf Z16 mappt, und den, der mittels Grobfoto auf Z8 mappt) verdanken wir der Schachtelungsmöglichkeit von MPs. Die Frage also, ob Du für ein Z18-Tile ein MP-Monster (sehr grobe Daten), ein normales MP (detailierte Daten) oder
[Talk-de] Suburb vs. Village
Am 28.09.2011 16:57, schrieb Andreas Labres: On 26.09.11 17:17, Martin Koppenhoefer wrote: nö, ist aber auch egal. Manhattan ist ziemlich sicher ein suburb in OSM http://www.openstreetmap.org/browse/node/158810611 - Hamlet Manhattan http://www.openstreetmap.org/browse/node/158875120 - Hamlet Harlem http://www.openstreetmap.org/browse/node/158857828 - Hamlet Brooklyn Das sollte man kurzfristig umtaggen, hamlet für eine Miniansiedlung mit wenig Häusern steht, was hier falsch ist. Machst du es oder soll ich? IMO müssen griffige Begriffe her (city_district, neighbourhood halte ich zB für griffig), nicht zweifelhafte/solche mit verschiedensten Deutungen (suburb, quarter)! suburb ist definiert und gängig und es in OSM klar dargestellt, was es bedeuten soll, eben ein Stadtteil nicht ausschliesslich einen Vorort. Bei neighbourhood sind wir uns einig. Wieso du city_district für besser hältst als quarter erschliesst sich mir nicht. City_district ist neben suburb von der Bedeutung angesiedelt und ebenfalls beliebig interpretierbar und würde in Bezug auf die Hierarchie von Gebieten innerhalb einer Stadt nicht erkennbar Klarheit schaffen. Aber viele viele suburbs müsste man umtaggen. Quarter ist ein gängiger Begriff für einen kleineren Teil einer Stadt der mit einem Namen belegt ist. Und genau so ist das proposal. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [WISY-Spam]Anzeigenamen im Garmin 62x beeinflussen
Jan Tappenbeck schrieb: ich rechne meine Karten immer selber mit mkgmap, splitter und gmaptools. In meinem Garmin steht dann als Kartenname immer gmaptool. Weiß einer von Euch ob man irgendwie den Namen beeinflussen kann - die Reit und Wanderkarte hat in der Anzeige auch einen anderen Namen. gmaptool -h (bzw -w?) Hilfen sind zum Lesen da. malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osm-Kartenlink mit Marker - Doku dazu ?
Am 28.09.2011 19:23, schrieb Jan Tappenbeck: Hi ! woher kennst Du die Parameter - gibt es eine Doku ? Gruß Jan .-) Liegt eventuell daran, dass ich die Seite erstellt habe. :) Mehr Parameter gibt es aber auch nicht. Höchstens die Shortlink-Parameter wären eventuell noch erklärensbedürftig. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk mit Multipolygonen - Beispiel
Am 28.09.2011 16:38, schrieb Christian Müller:
Am 28.09.2011 10:26, schrieb Martin Koppenhoefer:
.. und es zudem nicht
gewünscht wird/wäre, dass eine Straßenfläche extra erfasst wird
wer entscheidet, dass das nicht gewünscht ist?
ich nicht, deshalb habe ich dazu keine Aussage getroffen. vielleicht
Joe Mapper ;-)
Wenn die Datenlage gut ist (Luftbilder), würde ich das auch
gutheißen. Nur ist da natürlich wieder auszudiskutieren, /wie/ -
Konsens fürs tagging usw. muss gefunden werden - Garry sprach schon
an, welches Verwechslungspotenziale bestehen: Verkehrsfläche vs.
Gesamtfläche der Straße (mit Entwässerungsanlagen, Schallschutzbauten,
etc.)..
Wenn die entsprechende landuse=road Seite im Wiki nach aktuellem
Wissensstand (des Projekts) erklärt, was genau damit gemappt werden
soll, ist schonmal viel getan - ansonsten wird das Tag irgendwann so
unklar verwendet, wie landuse=residential (eine neblige Sammlung der
Verständnisse und Interpretationen aus verschiedenen Themenbereichen
und Kontexten, nicht nur notwendigerweise auf die Bodennutzung Bezug
nehmend).
So einfach ist das leider nicht. Mein Standpunkt ist das die
highway-ways in erster Linie Routingdaten sind die nichts direkt mit
Flächendaten zu tun haben -
mit der wesentlichen Aussage dass (landuse-)Flächen nicht mit highways,
sondern nur mit den Flächendaten der Strasse
(also dann highway= road)verknüpft werden dürfen.
, /dann/ ist
es richtig, die Waldgrenze oder die Flussgrenze mit dieser Linie zu
identifizieren.
Man könnte auch argumentieren, dass dort in der Karte noch Flächen
fehlen (Uferbereich, ggf. Straßenfläche bzw. Straßennebenflächen) und
daher der Mapper erstmal den Wald (oder jede andere Fläche) bis an
seine Grenze zeichnet, und später wird jemand evtl. die Straßenfläche
oder Uferfläche ergänzen. Wir haben in OSM ja immer work-in-progress
und nie eine endgültige Situation.
+1 full ack. Gerade deswegen fand und finde ich es unsinnig, immer
und überall Platz zu lassen - wenn jemand später mehr Detail ergänzen
möchte, wird der sich nicht daran stören, dass da schon etwas
(ungenaueres) ist. /Wie/ er dann sein Detail ergänzt, ist seiner
eigenen Einschätzung überlassen ( werden die Grenzen des groben
Gebiets verschoben und eine neues erzeugt ('outer'-Rolle)? oder wird
sein Detail /als Teil/ eines der vorhandenen, groben Gebiete erfasst
('inner'-Rolle)? )..
Genau das ist der Punkt.
Wenn ich etwas ergänzen/die Genauigkeit verbessern möchte dann sollte
das dadurch möglich sein dass ich vorhandenes idealerweise einfach
nur etwas zurechtrücken muss ohne in eine Struktur einzugreifen mit der
ich mich erst intensiv auseinandersetzen muss, einen komplexen Editor
benötige
und einen grösseren Schaden durch kleine Fehler anrichten kann.
D.h. eine Detailverbesserung an Flächen und Linien muss mit
Basisoperationen möglich sein ohne dass im Hintergrund ein komplexes
Programm arbeitet
das tausende von Überprüfungen vornehmen muss um sicherzustellen dass
ich nicht irgendwelche Daten zerstöre die ich übehaupt nicht bearbeiten
möchte.
Z.B. wenn ich eine Waldgebiet bearbeite möchte ich nicht einen Jakobsweg
zerstören, mich aber auch nicht damit befassen nur weil dessen Verlauf
nach einer groben Annäherung mit der Kante einer Waldgrenze gekoppelt
wurde. Hier entsteht also ein Konflikt durch Kopplung der Daten wenn ich
nur genaue Walddaten
oder nur genaue Jakobswegdaten habe. Wenn ich nur eins von beidem habe
kann ich nichs an den Daten verbessern weil ich nicht garantieren kann
dass ich den anderen Teil der Daten dadurch nicht verschlechtere.
Garry
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [WISY-Spam]Anzeigenamen im Garmin 62x beeinflussen
Am 28.09.2011 21:35, schrieb malenki: Jan Tappenbeck schrieb: ich rechne meine Karten immer selber mit mkgmap, splitter und gmaptools. In meinem Garmin steht dann als Kartenname immer gmaptool. Weiß einer von Euch ob man irgendwie den Namen beeinflussen kann - die Reit und Wanderkarte hat in der Anzeige auch einen anderen Namen. gmaptool -h (bzw -w?) Hilfen sind zum Lesen da. malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hi ! Du markst recht haben aber die Arbeiten mit dem Tool sind solange her das ich nicht mehr die einzelnen Zusammenhänge weiß. Ich dachte das wäre vielmehr eine einfache Option. Danke trotzdem. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
