Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen
Am 24.07.2011 09:09, schrieb Walter Nordmann: hi jan, die Strassen auf jeden fall erfassen - ob als residential oder service ist erst mal unwichtig. ich würde residential mit width=* bevorzugen, da es sich um schmale Zufahrten zu Wohnhäusern handelt. Die meisten Anliegerstraßen muss ein dreiachsiges Müllfahrzeug passieren können. Und im Einsatzfall auch die Feuerwehr. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen
Am 24.07.2011 08:02, schrieb Georg Feddern: laut Indizien (Luftbildern) definitiv ja. Luftbilder stimmen nicht 100 prozentig1 sonst bei Häusern die von der Straße was wegliegen versuche ich auch durch eine Zufahrt anzubinden, schon damit deutlich ist wozu das HAus gehört und wie mensch das erreicht. Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] gibt es eine simulierte Lizenzumstellung
Hi ! ich habe durch Zufall eben eine Bachlorarbeit im Web gefunden [1] über die möglichen Auswirkungen der Lizenzumstellung. Gibt es soetwas irgendwo für ganz Deutschland / Europa / die Welt ??? Es müßte ja nicht tagesaktuell sein - aber so im Wochenrythmus wäre das sicherlich ganz interessant - auch als Mittel andere noch zu überzeugen. (hoffentlich nicht zu sehr frustend !) Gruß Jan :-) [1] http://checkout.yourweb.de/thesis/Jakob_Altenstein_Thesis.pdf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gibt es eine simulierte Lizenzumstellung
Hallo, Jan Tappenbeck wrote: ich habe durch Zufall eben eine Bachlorarbeit im Web gefunden [1] über die möglichen Auswirkungen der Lizenzumstellung. Andere, die auf dieser Liste mitlesen, haben das nicht durch Zufall, sondern durch Lesen meines Postings vom 19.5. mitbekommen ;) Gibt es soetwas irgendwo für ganz Deutschland / Europa / die Welt ??? Nein, fuer so grosse Bereiche hat es nie jemand ausprobiert, ausserdem ist ein aktuelles History-Extrakt fuer den betr. Bereich Voraussetzung. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM-Wochennotiz Nr. 53
Hallo, die Wochennotiz Nr. 53 mit allen Neuigkeiten aus dem OpenStreetMap-Universum ist da: http://blog.openstreetmap.de/2011/07/osm-wochennotiz-nr-53/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Place
Hallo Mapper, ich habe gerade die Frage ob das Tag PLACE = besser als Punkt oder Fläche oder Punk und Fläche verwendet werden sollte. Ich habe da so mitgenommen das die erste Erfassungswelle die Punktversion genutzt hat, nun sind viele Orte mit ihrer Landuse=Residential-Fläche erfasst das heißt, die Info der Punktversion könnte in die Fläche wandern und dies ersetzen. Andererseits bietet die Punktversion den Vorteil, dass der User den Ortskern manuell zuordnet - bei einer Flächeninformation kann dieser nur errechnet werden. Meiner Meinung nach sollte man eine Verknüpfung der beiden Merkmale nutzen. So können Renderer und Router diese Informationen zum Druck sowie für Verzeichnisse/Indexe sauber ableiten. Mir ist aufgefallen, das Mapnik bei Punkt und Flächeninfo zwei Ortsnamen rendert. NAVIT scheint nur die Punktinformation für die Ortsnamen heranzuziehen. Das Wiki lässt beide Varianten zu, es bleibt also ein durcheinander das die Komplexität erhöht. Wie seht ihr das? Gruß Ludwich ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen
Am 23.07.2011 19:13, schrieb Jan Tappenbeck: bei knapp werdendem Bauland ist es teilweise in Mode in zweiter Reihe zu bauen. Diese Grundstücke werden dann mit Straßen erschlossen. Stellt sich die Frage - ab wann sind diese Straße in OSM darzustellen ??? Meine Meinung ist das bis zwei Häuser dieses nicht erforderlich ist - dannach wie in [1] sollte das erfolgen. Wie ist Eure Meiung diesbezüglich ??? Immer erfassen. Warum sollte man eine schmale Straßen weglassen? Die Arme, wächst vielleicht noch. Oder wenn man wem den Weg beschrieben will 'Dritter weg rechts', da ist es auch gut wenn alles drin ist. [1] http://www.openstreetmap.org/?lat=53.87556lon=10.632796zoom=19 Die Wege sind aber bischen zerfleddert im Moment: http://www.openstreetmap.org/browse/way/122820350 dessen unteres ende hat Abstand vom Rest, Bing sagt was anderes. http://wiki.openstreetmap.org/wiki/Tag:service%3Dalley Das Bild passt doch. alley==Gasse Wenn da was deutlich abgesetzt ist (Bordsteinkante), es doch eher nach privater Einfahrt aussieht und es keinen Strassennamen hat dann ohne alley. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erschließung in zweiter Reihe - ab wann service mit erfassen
Am 24. Juli 2011 09:09 schrieb Walter Nordmann walter.nordm...@web.de: access=private, wie in der Dornbreite 247ff, bitte nur, wenn da wirklich ein Schild privat steht. privat-Durchgang verboten müsste da m.E. stehen (wenn da nur Privatstraße steht, dann heisst das noch nichts für den access, der kann durchaus trotzdem rechtlich garantiert sein). Wobei eine Einfriedung (Zaun etc) auch ohne Schild und auch wenn das Tor offen steht eindeutig und verbindlich signalisiert, dass es sich um einen privaten Bereich handelt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer - Inselgruppe
Am 24.07.2011 14:38, schrieb M∡rtin Koppenhoefer: Schöner wär's in der Tat IMHO, wenn man pro Insel eine Relation hätte (oder schon als Boundary-MP hat), oder einfach einen geschlossenen way? und diese in eine Sammelrelation (type=collection, place=archipelago oder so) packen täte. man könnte das auch mit einer Multipolygon-Relation machen (type=multipolygon, place=archipelago) So wird es ja derzeit oft gemacht. Ostfriesische Inseln: http://www.openstreetmap.org/browse/relation/963669 Ist ok[1], solange die Inseln klein sind und die Coastline jeweils nur aus *einem* Way besteht. Bei den Kanaren ist es dann aber nicht mehr so schön übersichtlich: http://www.openstreetmap.org/browse/relation/1382469 (Die Relation lädt bei mir jetzt schon seit 5 Minuten) Chris [1] Wobei MPs eigentlich dazu gedacht sind Polygone mit Löchern zu definieren, nicht um Objekte zusammenzufassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer - Inselgruppe
Am 24. Juli 2011 18:26 schrieb Chris66 chris66...@gmx.de: man könnte das auch mit einer Multipolygon-Relation machen (type=multipolygon, place=archipelago) So wird es ja derzeit oft gemacht. Ostfriesische Inseln: http://www.openstreetmap.org/browse/relation/963669 Ist ok[1], solange die Inseln klein sind und die Coastline jeweils nur aus *einem* Way besteht. http://www.openstreetmap.org/browse/relation/1382469 (Die Relation lädt bei mir jetzt schon seit 5 Minuten) das liegt daran, dass die db sich alle Members zusammensuchen muss, und würde sich mit einem anderen Relationstyp auch nicht ändern. [1] Wobei MPs eigentlich dazu gedacht sind Polygone mit Löchern zu definieren, nicht um Objekte zusammenzufassen. Das ist ein Mythos. Multipolygone sind Konstrukte, um aus ways Polygone zu definieren. Die Mindestanforderung ist ein outer way. Löcher braucht man nicht, wenn man sie hat braucht man allerdings Multipolygone. Für das o.g. Beispiel Inselgruppe kann man mit einer Multipolygonrelation ein Objekt (die Inselgruppe) konstruieren, das aus mehreren für sich geschlossenen Polygonen besteht, und diesem dann die entsprechenden Tags zuweisen (Inselgruppe, z.B. natural=archipelago, name=foo) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place
Am 24.07.2011 13:38, schrieb ludwich: ich habe gerade die Frage ob das Tag PLACE = besser als Punkt oder Fläche oder Punk und Fläche verwendet werden sollte. Wie gesagt, es geht beides. Doppelte Erfassung sollte vermieden werden. Da die Flächenerfassung einer Stadt meist bereits durch die admin-Grenze gegeben ist, ist es IMHO ausreichend das (Stadt-)Zentrum als place-Node zu mappen. Über die Rolle 'admin_centre' der Boundary-Relation kann man beides miteinander verknüpfen. http://www.openstreetmap.org/browse/relation/157719 Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Place
Am 24. Juli 2011 20:05 schrieb Chris66 chris66...@gmx.de: Am 24.07.2011 19:55, schrieb M∡rtin Koppenhoefer: Doppelte Erfassung sollte vermieden werden. die Erfassung mit Node und Polygon nicht doppelt, sofern man das über eine Relation zusammenbringt. Welchen types ? egal, das ist von Relationentyp völlig unabhängig. Zugegebenermaßen ist für MP-Relation derzeit kein label-node vorgesehen, aber das könnte man ja ändern, ansonsten könnte man z.B. eine place-relation erfinden, die site-relation passt definitionsgemäß m.E. nicht, hätte aber einen label-Node in ihrer Definition. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer - Inselgruppe
Hallo, Insgesamt gibt es aber gerade bei diesen topographischen Gebieten das Problem, dass man sie nicht besonders geeignet sind für unsere Datenstruktur. Einen genauen Way zu zeichnen, der die Grenze der schwäbischen Alb markiert, geht nicht und wäre auch als Näherung nicht geeignet. wir war unser Mantra: wir mappen nicht für die Renderer. Das eine Insel zu einer Inselgruppe oder zu einem Land gehört ist eine Info die relevant ist und per Relation oder is_in recht einfach einzugeben ist. Wie es dargestellt wird ist dann Sache der Renderer. Google Maps schreibt z.B. nicht Kanarische Inseln auf die Karte, kann aber danach suchen, das sollte auch mit OSM gehen. Habe das Proposal nur überflogen, Ich auch. Man könnte es natürlich nur für Sachen benutzen die bisher nicht vorhanden sind wie z.B. Inselgruppen. Falls es sich etabliert kann man immer noch überlegen auch altes zu wandeln. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS-Verleih
Am 22.07.2011 18:43, schrieb Matthias Winter: kann mir jemand weiterhelfen, wie ich denjenigen erreiche, der die GPS-Leihgeräte (http://openstreetmap.de/gps-verleih/details.html) verwaltet, oder wer das ist? Emails an gps-verl...@openstreetmap.de werden leider nicht beantwortet. Ich bin zwar nicht der Ansprechpartner, aber gab es zwischenzeitlich einen Kontakt oder zumindest eine Antwort? Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Insel im Meer - Inselgruppe
Hallo, man könnte das auch mit einer Multipolygon-Relation machen ( meiner Meinung nach wäre das falsch, die Grenze einer Inselgruppe ist nicht die Summe der Küstenlinien. Meiner Meinung nach gehört das Meer auch dazu. Man müßte also entweder eine eigene Begrenzung einzeichnen, was aber keinen Sinn macht, da die Grenze nicht so genau definiert sein dürfte, oder man faßt sie einfach per Relation zu einer Gruppe zusammen, aber eben nicht als MP. Man könnte sich auch an den Hoheitsgewässern orientieren, aber so einfach ist das auch nicht. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verzeichnisstruktur für Metatiles
Danke für die sehr gute Beschreibung damit läuft es jetzt bei mir. Etwas dauern wird die Umsetzung noch, da ich von meiner spaltenweisen Arbeitsweise auf etwas mit der Z-Kurvenaufteilung umplanen muß. Der Nachteil ist jetzt halt, dass ich durch alle Ordner scannen muß, obwohl mich ja nur einige interessieren. Aber vielleicht ist das auch nicht so schlimm. Man hätte x und y auch schön bitweise verschränken können, dass hätte dann schönere Ordnernamen ergeben Frederik, du hattest ja mal etwas zur Mapnik-Performance geforscht und dazu auch auf der SotM2010 einen Vortrag gehalten. Denkst du, dass mein Ansatz mehrer Stile und Zoomlevel an einer Stelle zur selben Zeit zu rendern was bringen könnte? Die Daten sollten dann doch eigentlich im RAM liegen können. Danke nochmal und Grüße Tim Alder Am 24.07.2011 02:52, schrieb Frederik Ramm: Hallo, Kolossos wrote: Was besonders unschön erscheint, ist dass x und y scheinbar untrennbar miteinander verkoppelt werden. Meinen Plan die Tiles in bestimmten Längengradbereichen abzufragen werde ich damit wohl zu den Akten legen müssen. Ich verstehe nicht ganz, was Du meinst. Letztlich geht es bei der ganzen Sache doch nur darum, dass nicht alle X Milliarden Tiles auf Zoom 17 in einem Verzeichnis liegen. Also teilt man auf. Nun gibt es natuerlich viele Methoden, einen Pfad fuer das Tile x=12345 y=67890 zu bestimmen; man koennte z.B. sowas wie zoomlevel/012/345/067/890.meta oder so machen - aber auch hier waeren X und Y miteinander vermischt. Im konkreten Fall hat man halt eine Methode gewaehlt, bei der die X- und Y-Koordinate des oberen linken Tiles im Metatile in 20 Bits hingeschrieben werden, also x = (a sind die hoechst-, e die niedrigstwertigen bits) y = und dann werden jeweils 4 Bits von einem und 4 Bits vom anderen zu einem Verzeichnis zusammengesetzt: / / / / .png Theoretisch koennen in jedem Verzeichnis die Zahlen 0-255 vorkommen, aber in der letzten Verzeichnisebene sind die letzten drei Bits immer 0, wenn man mit Metatiles arbeitet, d.h. wir haben e000j000.png, d.h. es gibt nur 0.png, 8.png, 128.png und 136.png. In den vorderen Verzeichnissen gibt es auch eine Einschraenkung des Wertebereichs, weil es ja nicht auf jedem Zoomlevel 20-bittige Koordinaten gibt. Bei allen Zoomlevels unter 17 ist das erste Verzeichnis immer 0. Bei allen unter 13 das zweite auch. Bei allen unter 9 das dritte, usw. Also eigentlich kann man damit schon arbeiten. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verzeichnisstruktur für Metatiles
Hallo, Kolossos wrote: Frederik, du hattest ja mal etwas zur Mapnik-Performance geforscht und dazu auch auf der SotM2010 einen Vortrag gehalten. Denkst du, dass mein Ansatz mehrer Stile und Zoomlevel an einer Stelle zur selben Zeit zu rendern was bringen könnte? Die Daten sollten dann doch eigentlich im RAM liegen können. Ich denke, das haengt davon ab, wie aehnlich sich die Stile und die Zoomlevel sind. Bei extrem verschiedenen Stilen - z.B. einer mit nur Ortsnamen und einer nur mit Wald- und Wasserflaechen - ist der Vorteil sicherlich Null; bei sehr aehnlichen Stilen kann ich mir schon vorstellen, dass es was bringt. Ebenso mit den Zoomstufen. Mapnik hat sogar ein eingebautes Resultat-Caching, falls innerhalb eines Rendervorgangs mehrfach derselbe Datenbank-Query gemacht wird (z.B. fuer Casing/Core einer Strasse). Ich weiss nicht, ob das auch ueber Requests hinweg funktioniert; ansonsten waere es natuerlich ideal, dafuer zu sorgen, dass derselbe Mapnik-Prozess die verschiedenen Stile fuer ein Tile durchrechnet, falls diese z.T. gleiche Queries benutzen. Leider wuerde Tirex aber alle reinkommenden Queries auf verschiedene Prozesse verteilen. Man koennte aber darueber nachdenken, Tirex so zu erweitern, dass man auch Multi-Style-Renderer definieren kann und dass es dann Mapnik-Backends startet, die mehrere Stile geladen haben... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
