Re: [Talk-de] Fahrbahn für kleine E-Mobile auf einem Spielplatz
Am Sonntag 28 August 2011, 23:56:19 schrieb Garry: Am 28.08.2011 22:44, schrieb RalfGesellensetter: Hallo Albrecht, meinst du Matchbox-Autos oder solche, in die die Kinder selbst einsteigen können? Letzteres. Eigentlich ein fester Autoscooter auf einem Kinderspielplatz, Oberfläche Asphalt, 2 m breit. Bei der Gelegenheit: Gibt es schon etwas für eine Sommerrodelbahn? Gesehen habe ich schon *attraction*: summer_toboggan Eigentlich sind die Tracks dafür wenig interessant, da man sich ja wohl kaum verfahren kann, oder?... Man möchte sich sowas ja vielleicht auch mal in voller Pracht auf der Karte ansehen bevor man da hin fährt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rechtlich bedenkliche Grenzen in Berlin
On Sun, Sep 04, 2011 at 06:42:47PM +0200, Martin Koppenhoefer wrote: wobei es nicht irgendwas ist, sondern Grenzen. Irgendwo müssen die doch so veröffentlicht werden, dass man sie bekommen kann? Aeh ja - Meist in irgendwelchen Amtsblaettern - die ja gemeinfrei sein sollten. Da stehen aber keine GPS oder sonstwas koordinaten drin sondern Die Flurstuecke 30,33,34 der Gemarkung Nordrheda gehen an die Gemeinde Herzebrock Und dann? Damit habe ich nichts gewonnen. Flo -- Florian Lohoff f...@zz.de „Für eine ausgewogene Energiepolitik über das Jahr 2020 hinaus ist die Nutzung von Atomenergie eine Brückentechnologie und unverzichtbar. Ein Ausstieg in zehn Jahren, wie noch unter der rot-grünen Regierung beschlossen, kommt für die nationale Energieversorgung zu abrupt.“ Angela Merkel CDU 30.8.2009 signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wenn das Hochladen fehlschlägt
Guten Morgen, wenn sowas passiert, geht es sehr ins Detail. Da gucke ich im Moment wie ein Schwein ins Uhrwerk. Bitte mal um Hilfe bei folgender Meldung. Hochladen auf dem Server ist fehlgeschlagen, da der Datensatz eine Vorbedingung nicht erfüllt. Die Fehlermeldung ist: ResponceCode=412, Error Header=Precondition failed; Cannot update way 118372221: Data is invalid. Es geht um folgendes Gebiet http://www.openstreetmap.org/?lat=52.4451899528503lon=11.9369888305664zoom=14 (Das Multipolygon 101498667 wird beim Hochladen bevor ich es erstmalig anfaßte, schon mit Warnungen bedacht. Inzwischen habe ich immer mal wieder Präszisierungen an dessen ways gemacht und sie meinen eigenen mappings und auch Bing angepaßt. Ich weiß nicht, ob es jetzt mit diesem Multipolygon einen Zusammenhang gibt.) Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=locality nodes und mapnik
Am 5. September 2011 07:43 schrieb Martin Simon grenzde...@gmail.com: Wie wäre es stattdessen mit einem subtagging von place=locality in der Art von locality=cadastral_section? Dann kann ein Renderer selbst entscheiden, ab wann er sowas rendert. wobei er das erst dann sinnvoll kann, wenn auch andere Werte (darüber/darunter) festgelegt (und möglichst getaggt) sind, die locality haben könnte. Unterhalb der section könnte z.B. das lot kommen (Flurstück, in OSM überschneidet sich das ggf. mit addr:housename), darüber kommt in Deutschland im Kataster die Gemarkung, auf Englisch in der Wikipedia habe ich gefunden: * counties (Grafschaft/Landkreis) * parishes (Parocchie, Pfarrgemeinde, Landkreis), wobei civil_parish explizit nichts mit der Kirche zu tun hat. * ridings * quarter sessions (Gerichtsbezirke) * hundreds/wapentakes (dt. Harde) Durch die Flurbereinigungen könnte ich mir allerdings vorstellen, dass es viele Flurnamen gibt, die mit dem Kataster gar nicht mehr zu tun haben. Das Thema ist ein weites Feld ;-) und sehr von den lokalen Gegenheiten (Struktur, Kultur, Geschichte, Politik) abhängig. M.E. ist es vermutlich sinnvoller, so was wie admin_level auch für places zu haben (z.B. locality_level?), d.h. ein numerisches hierarchisches System, wo man bewusst Lücken lässt (siehe admin_level=3), damit auch Untereinheiten, die es nicht in allen Ländern gibt, bei Bedarf eingebettet werden können. Zusätzlich wäre dann eine Tabelle für die einzelnen Länder/Gegenden sinnvoll, die die Entsprechungen im Wiki dokumentiert. Da diese Einheiten teilweise nicht mit der politischen Verwaltungsstruktur übereinstimmen, halte ich eine von admin:level und boundary=administrative getrennte Erfassung durchaus für gerechtfertigt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wenn das Hochladen fehlschlägt
Am 5. September 2011 10:18 schrieb Albrecht Will albrecht.w...@online.de: Es geht um folgendes Gebiet http://www.openstreetmap.org/?lat=52.4451899528503lon=11.9369888305664zoom=14 (Das Multipolygon 101498667 wird beim Hochladen bevor ich es erstmalig anfaßte, schon mit Warnungen bedacht. Inzwischen habe ich immer mal wieder Präszisierungen an dessen ways gemacht und sie meinen eigenen mappings und auch Bing angepaßt. Ich weiß nicht, ob es jetzt mit diesem Multipolygon einen Zusammenhang gibt.) Ich würde beginnen, die komplexen/großen Multipoligone in kleinere Teile aufzuteilen. Siehe z.B. auch dieses MP hier: http://www.openstreetmap.org/browse/relation/265063 das sieht nicht so aus, als müsste dieses Gebiet unbedingt in der Art zusammengehören. Mit kleineren Teilen ist es einfacher sowohl für die Mapper als aus Datenbanksicht (es entstehen weniger Versionen, man muss weniger hoch- und runterladen, weniger Konfliktwahrscheinlichkeit, weniger Daten im Editor, einfacher zu überblicken, kleinere und einfachere Flächen beim Rendern von highzoom-Tiles verkürzen die Renderzeit, etc.). Die Aufteilung könnte z.B. entlang von Straßen stattfinden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dummy Beginner mit openlayers
Hallo! Am 05.09.2011 00:31, schrieb Michael Prieß: Hallo Wolfgang, dein Schnipsel sieht eigentlich okay aus und funktioniert bei mir auch. Sicher das OpenLayers.js geladen wird? Wenn du nicht soviele Funktionen brauchst und etwas schlankes suchst, ist eventuell noch Leaflet eine Alternative für dich. Gruß, Michael [0] http://leaflet.cloudmade.com http://leaflet.cloudmade.com/ Ist das komplett freeware? Ich sehe keine Angaben dazu! -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dummy Beginner mit openlayers
Am 5. September 2011 10:35 schrieb Wolfgang Wienke wo_wie...@gmx.net: Hallo! Am 05.09.2011 08:40, schrieb Andre Joost: Im Firefox unter Extras/Fehlerkonsole nachschauen, was ihm nicht gefällt. Die meint: Fehler: OpenLayers.Layer.OSM.Mapnik is not a constructor und fehlende Styles. Hast Du die Datei src=OpenStreetMap.js lokal vorhanden? Das ist AFAIR die js-Datei, die OpenLayers.Layer.OSM.Mapnik definiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rechtlich bedenkliche Grenzen in Berlin
Am 5. September 2011 10:10 schrieb Florian Lohoff f...@zz.de: On Sun, Sep 04, 2011 at 06:42:47PM +0200, Martin Koppenhoefer wrote: wobei es nicht irgendwas ist, sondern Grenzen. Irgendwo müssen die doch so veröffentlicht werden, dass man sie bekommen kann? Aeh ja - Meist in irgendwelchen Amtsblaettern - die ja gemeinfrei sein sollten. Da stehen aber keine GPS oder sonstwas koordinaten drin sondern Die Flurstuecke 30,33,34 der Gemarkung Nordrheda gehen an die Gemeinde Herzebrock Und dann? Damit habe ich nichts gewonnen. ja eben. Im vorliegenden Fall habe ich bisher recherchiert, dass bei der letzten Bezirksreform (2001) wohl lediglich die Namen der Bezirke die zusammengelegt wurden benannt sind. Die Definitionen der Bezirke sind älter und für den Ostteil aus DDR-Zeit (AFAIR). Eine große Reform (Groß-Berlin) war 1920, danach 1938 eine große Reform, d.h. die Daten dort könnte man sicherlich bedenkenfrei abzeichnen. Allerdings gibt es vermutlich auch eine Reihe von kleinen Anpassungen (wo mal 2 Straßen den Bezirk wechseln oder so), die man theoretisch alle nachvollziehen müsste, um zum aktuellen Stand zu kommen. Koordinaten sind da aber wohl trotzdem nie drin, d.h. man muss vermutlich zum vollständigen Verständnis eine amtliche Karte (Kataster?) parallel zu Rate ziehen. Zurück zum Thema: Frederik hat wohl Recht (Klar ist es irgendwo veroeffentlicht und Du hast das Recht, diese Daten zu konsumieren, um Dich an die Vorschriften zu halten - ob du die Daten konsumieren kannst, um daraus eine Karte zu malen, ist eine ganz andere Frage und hat nicht unbedingt damit zu tun!) Um das zu ändern könnte man sich evtl. auf das Informationsfreiheitsgesetz berufen und klagen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rechtlich bedenkliche Grenzen in Berlin
Am 05.09.2011 10:57, schrieb Martin Koppenhoefer: ... Um das zu ändern könnte man sich evtl. auf das Informationsfreiheitsgesetz berufen und klagen ;-) ... Das nützt im Allgemeinen auch nichts, da du auch da zwar schon das Recht hast die Daten einzusehen, aber die Weiterverwendung genau so eingeschränkt werden kann. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rechtlich bedenkliche Grenzen in Berlin
On Mon, Sep 05, 2011 at 10:57:42AM +0200, Martin Koppenhoefer wrote: ja eben. Im vorliegenden Fall habe ich bisher recherchiert, dass bei der letzten Bezirksreform (2001) wohl lediglich die Namen der Bezirke die zusammengelegt wurden benannt sind. Die Definitionen der Bezirke sind älter und für den Ostteil aus DDR-Zeit (AFAIR). Eine große Reform (Groß-Berlin) war 1920, danach 1938 eine große Reform, d.h. die Daten dort könnte man sicherlich bedenkenfrei abzeichnen. Allerdings gibt es vermutlich auch eine Reihe von kleinen Anpassungen (wo mal 2 Straßen den Bezirk wechseln oder so), die man theoretisch alle nachvollziehen müsste, um zum aktuellen Stand zu kommen. Koordinaten sind da aber wohl trotzdem nie drin, d.h. man muss vermutlich zum vollständigen Verständnis eine amtliche Karte (Kataster?) parallel zu Rate ziehen. Zurück zum Thema: Frederik hat wohl Recht (Klar ist es irgendwo veroeffentlicht und Du hast das Recht, diese Daten zu konsumieren, um Dich an die Vorschriften zu halten - ob du die Daten konsumieren kannst, um daraus eine Karte zu malen, ist eine ganz andere Frage und hat nicht unbedingt damit zu tun!) Um das zu ändern könnte man sich evtl. auf das Informationsfreiheitsgesetz berufen und klagen ;-) Hilft dir IMHO nicht - Daten die du nach dem Informationsfreiheitsgesetz bekommst koennen ja auch einem Urheberrecht unterliegen oder etwa nicht? Flo -- Florian Lohoff f...@zz.de „Für eine ausgewogene Energiepolitik über das Jahr 2020 hinaus ist die Nutzung von Atomenergie eine Brückentechnologie und unverzichtbar. Ein Ausstieg in zehn Jahren, wie noch unter der rot-grünen Regierung beschlossen, kommt für die nationale Energieversorgung zu abrupt.“ Angela Merkel CDU 30.8.2009 signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wenn das Hochladen fehlschlägt
Am Montag 05 September 2011, 10:39:35 schrieb Martin Koppenhoefer: ch würde beginnen, die komplexen/großen Multipoligone in kleinere Teile aufzuteilen. Siehe z.B. auch dieses MP hier: http://www.openstreetmap.org/browse/relation/265063 Eigentlich wollte ich nicht an solche Riesen ran, die mein Vorgänger erstellt hat. Ich bin noch nicht lange dabei und möchte ja nichts falsch machen. Ich hatte ihn angeschrieben als ich das erste mal eine Warnung für das Polygon bekam und machte darauf meine Änderungen rückgängig. Inzwischen liefen meine Änderungen trotz Warnung durch. Nun also ein erstes Herantasten an das riesige Gebilde. Da sind nodes und ways für verschiedene landuse miteinander verschmolzen. Ich war dann mal mutig und habe in Kleinarbeit aufgetrennt . Mal sehen, was das Hochladen bringt. Es funzt! Das geht also auch, daß sich 2 outer-Flächen nicht berühren müssen und gehören trotzdem zu einem Multipolygon Die heutige Meldung könnte mit dem Aus des Servers am Wochenende zu tun haben? Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wenn das Hochladen fehlschlägt
Am 5. September 2011 12:12 schrieb Albrecht Will albrecht.w...@online.de: Am Montag 05 September 2011, 10:39:35 schrieb Martin Koppenhoefer: ich würde beginnen, die komplexen/großen Multipoligone in kleinere Teile aufzuteilen. Siehe z.B. auch dieses MP hier: http://www.openstreetmap.org/browse/relation/265063 Eigentlich wollte ich nicht an solche Riesen ran, die mein Vorgänger erstellt hat. ja, das ist einer der Hauptpunkte, warum sie schlecht sind: viele Mapper trauen sich gar nicht mehr ran, dort Änderungen vorzunehmen. Das geht also auch, daß sich 2 outer-Flächen nicht berühren müssen und gehören trotzdem zu einem Multipolygon Ja, outer-ways müssen sich nicht berühren, sie müssen lediglich jeweils geschlossene Gebiete bilden, das können aber durchaus auch voneinander abgesetzte Gebiete sein. M.E. muss es aber gute Gründe geben, diese abgesetzten Gebiete in einem Objekt zu haben, d.h. dieses Gebiet sollte auch für eine Einheit stehen (z.B. _ein_ politisches Gebiet das Exklaven enthält). Wenn es nur vom gleichen Typ (z.B. Nadelwald) ist, dann macht es keinen Sinn und einzelne Objekte sind aus den genannten Gründen sinnvoller. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Probleme mit Bigmap ??
HI ! ich wollte mir gerade eine Karte mit Bigmap ziehen - das klappte mit folgendem Link nicht ... http://openstreetmap.gryph.de/bigmap.cgi?xmin=4002xmax=4004ymin=3194ymax=3196zoom=13scale=256baseurl=http%3A%2F%2Fb.tile.openstreetmap.org Kann das einer bestätigen oder ist mir ein Fehlerunterlaufen - müßte in der Nähe von Malaga sein. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Bigmap ??
Hallo Jan! Da auch der Test-Link der auf der Startseite von Bigmap verlinkt ist, nicht funktioniert, gehe ich davon aus, dass der Server anderweitige Probleme hat. Auf sowas kann man ganz schnell von alleine kommen :) Gruß, Philip -- View this message in context: http://gis.638310.n2.nabble.com/Probleme-mit-Bigmap-tp6760518p6760557.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wenn das Hochladen fehlschlägt
Hallo, Am Montag 05 September 2011 12:20:22 schrieb Martin Koppenhoefer: Am 5. September 2011 12:12 schrieb Albrecht Will albrecht.w...@online.de: Eigentlich wollte ich nicht an solche Riesen ran, die mein Vorgänger erstellt hat. ja, das ist einer der Hauptpunkte, warum sie schlecht sind: viele Mapper trauen sich gar nicht mehr ran, dort Änderungen vorzunehmen. Das geht also auch, daß sich 2 outer-Flächen nicht berühren müssen und gehören trotzdem zu einem Multipolygon Ja, outer-ways müssen sich nicht berühren, sie müssen lediglich jeweils geschlossene Gebiete bilden, das können aber durchaus auch voneinander abgesetzte Gebiete sein. M.E. muss es aber gute Gründe geben, diese abgesetzten Gebiete in einem Objekt zu haben, d.h. dieses Gebiet sollte auch für eine Einheit stehen (z.B. _ein_ politisches Gebiet das Exklaven enthält). Ohne jetzt was lostreten zu wollen: Es kann dann Sinn machen, statt eines Riesen-Multipolygons die einzelnen Polygone in einer Site zu sammeln. Da entsteht zwar eine Hierarchie, aber die einzelne Relation ist viel schlanker. Wenn es nur vom gleichen Typ (z.B. Nadelwald) ist, dann macht es keinen Sinn und einzelne Objekte sind aus den genannten Gründen sinnvoller. +1 Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Bigmap ??
Hi, On 09/05/11 13:02, Jan Tappenbeck wrote: ich wollte mir gerade eine Karte mit Bigmap ziehen - das klappte mit folgendem Link nicht ... http://openstreetmap.gryph.de/bigmap.cgi?xmin=4002xmax=4004ymin=3194ymax=3196zoom=13scale=256baseurl=http%3A%2F%2Fb.tile.openstreetmap.org http://openstreetmap.gryph.de/bigmap.cgi?xmin=4002xmax=4004ymin=3194ymax=3196zoom=13scale=256baseurl=http%3A%2F%2Fb.tile.openstreetmap.org/!z/!x/!y.png waere richtig. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dummy Beginner mit openlayers
Hallo Wolfgang, mit Deinem Beispiel sehe ich bei mir zumindest mal eine Karte. Was noch fehlt, sind Icons für die Controls und ein CSS Style (aus Ordner img und theme). Falls nicht schon gemacht, könntest Du ein Release von openlayers.org herunterladen und von dort die noch fehlenden Dateien kopieren (siehe auch readme.txt). Im Unterordner examples findest Du mit osm.html auch ein funktionierendes Beispiel. Die OpenStreetMap.js ist in Deinem Beispiel nicht nötig, darin sind die Layers von osm.org als Ableitungen der OpenLayers Klasse OpenLayers.Layer.OSM definiert, wie das erwähnte OpenLayers.Layer.OSM.Mapnik. Speziell werden dort mehrere URLs angegeben, damit im Browser mehr Tile-Requests gleichzeitig abgesetzt werden. Gruß, ikonor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wenn das Hochladen fehlschlägt
Hi, On 09/05/11 12:12, Albrecht Will wrote: Eigentlich wollte ich nicht an solche Riesen ran, die mein Vorgänger erstellt hat. Ich bin noch nicht lange dabei und möchte ja nichts falsch machen. +1 zu Martin: Wir sind hier nicht beim Kunst-Workshop. Sachen zu erstellen, die so kompliziert sind, dass sich ausser einem selber niemand an eine Aenderung wagt, ist zum Nachteil des Projekts. Insofern ist es zwar richtig, wenn man als Neuling ein bisschen Respekt hat und immer erstmal annimmt, dass man vielleicht selbst einfach keine Ahnung hat - aber wenn man es mit Datenbiestern zu tun hat, die zu kompliziert sind, darf man schon auch mal mit der Machete fuer eine bessere Daten-Wartbarkeit sorgen. Das geht also auch, daß sich 2 outer-Flächen nicht berühren müssen und gehören trotzdem zu einem Multipolygon Im Gegenteil: Das geht nicht nur auch - das ist Vorschrift. Wenn Du mehr als eine outer-Flaeche hast, dann *duerfen* sie sich nicht linienhaft beruehren, sonst ist das ein ungueltiges Polygon. (Denn man koennte ja dann die beiden Flaechen als eine modellieren.) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rechtlich bedenkliche Grenzen in Berlin
Hallo, Am Sonntag 04 September 2011 23:57:00 schrieb Frederik Ramm: Hallo, On 09/04/2011 11:07 PM, André Reichelt wrote: Wenn ihr anderer Meinung seit müssen wir uns ernsthafte Gedanken darüber machen, wie wir in Zukunft wem auch immer erklären, woher wir diesen oder jenen Straßennamen haben. Wir hätten ein massives Problem, wenn die Aussage das weiß man halt als Ortsansässiger/Interessierter nicht mehr genügt. Erstens: Ein exakter Grenzverlauf ist was anderes als ein Strassenname. Niemand, auch kein alteingesessener Berliner, wird saemtliche Stadtteilgrenzen exakt einzeichnen koennen. Zweitens: In diesem Fall hat der Autor ja selbst gesagt, dass er sich zwecks Grenzbestimmung die DVD gekauft hat. Es duerfte also schwer sein, jetzt ploetzlich zu behaupten, man habe die in irgendeinem Buch gelesen. Drittens (an Martin): Leider ist es mitnichten so, dass alles, was irgendwie Gesetzeskraft hat, auch copyright-frei veroeffentlicht ist, ich bin da auch schon manchmal mit meinem gesunden Menschenverstand auf die Nase gefallen. (Klar ist es irgendwo veroeffentlicht und Du hast das Recht, diese Daten zu konsumieren, um Dich an die Vorschriften zu halten - ob du die Daten konsumieren kannst, um daraus eine Karte zu malen, ist eine ganz andere Frage und hat nicht unbedingt damit zu tun!) Ich würde mal vermuten, dass das Urheberrecht hier die falsche Baustelle ist. Eine Schöpfungshöhe könnten die Daten nur erreichen, wenn sie falsch eingezeichnet werden. Die reine Darstellung der Wirklichkeit (oder Gesetzeslage) entfaltet kein eigenes Urheberrecht. Von einer Interpretation oder sonstigen künstlerisch hochwertigen Maßnahmen würde ich bei einer Grenze in 1:5000 nicht ausgehen. Eine andere Baustelle sind die Benutzungsbedingungen der DVD, die sich allerdings wiederum dem AGB-Recht des BGB unterordnen müssten... Hinzu kommt die Keule, die gerade wegen des Problems des häufig nicht hinreichenden Urheberrechts geschaffen wurde, das Datenbankrecht. Einzelne Korrekturen könnten noch gehen, insbesondere wenn man nicht so explizit die DVD als Grundlage nennt, aber eine gesamte Entnahme wird wohl ein Problem sein. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wenn das Hochladen fehlschlägt
Hi Martin Fredrick, mir ist schon mal was vom Herzen geplumst. Danke Da es aber anscheinend keine übergeordnete Eigenschaft für die jetzt aufgetrennten Multipolygone gibt, sollte die Relation für das ursprüngliche MP wohl besser bereinigt werden. Ich dachte an folgendes Vorgehen: - Polygone ohne innere Flächen gehen raus als einfache Forstflächen. - Polygone mit inneren Flächen gehen raus und erhalten als MP eine jeweils eigenständige Relation Nun habe ich aber noch ein Problem. Das Rest-MP hat eine innere Fläche, die durch die Teilungen am Außenrand liegt. Bei einer Neukonstruktion war mir das bisher nicht möglich. Was hat es damit auf sich? Gruß Albrecht Am Montag 05 September 2011, 13:48:34 schrieb Frederik Ramm: Hi, On 09/05/11 12:12, Albrecht Will wrote: Eigentlich wollte ich nicht an solche Riesen ran, die mein Vorgänger erstellt hat. Ich bin noch nicht lange dabei und möchte ja nichts falsch machen. +1 zu Martin: Wir sind hier nicht beim Kunst-Workshop. Sachen zu erstellen, die so kompliziert sind, dass sich ausser einem selber niemand an eine Aenderung wagt, ist zum Nachteil des Projekts. Insofern ist es zwar richtig, wenn man als Neuling ein bisschen Respekt hat und immer erstmal annimmt, dass man vielleicht selbst einfach keine Ahnung hat - aber wenn man es mit Datenbiestern zu tun hat, die zu kompliziert sind, darf man schon auch mal mit der Machete fuer eine bessere Daten-Wartbarkeit sorgen. Das geht also auch, daß sich 2 outer-Flächen nicht berühren müssen und gehören trotzdem zu einem Multipolygon Im Gegenteil: Das geht nicht nur auch - das ist Vorschrift. Wenn Du mehr als eine outer-Flaeche hast, dann *duerfen* sie sich nicht linienhaft beruehren, sonst ist das ein ungueltiges Polygon. (Denn man koennte ja dann die beiden Flaechen als eine modellieren.) Bye Frederik ___ 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] place=locality nodes und mapnik
Ich konnte nichts finden zu locality=cadastral_section Kannst du kurz definieren, was es, als Erweiterung von place=locality, genau bedeutet? Es scheint jedenfalls nicht das zu sein, wonach ich suche. Die Flurnamen sind in jedem Fall historisch und gehen auch über administrative Grenzen hinaus, sind eher geographischer Natur, sprich die Benennung von Waldstücken, aber auch die Benennung von nicht klar abzugrenzener Wiesen, Täler usw. Ich denke, eine administrative Ebene festzulegen, wäre das falsche Vorgehen. Auch offiziell sind die Gebiete nur benannt, aber _nicht_ klar umrissen und wurden zur Orientierung in noch dörflich-landwirtschaftlich geprägteren Zeiten benutzt, sind daher einfach interessante Zeugen einer vergangenen Zeit. Es reicht daher auf jeden Fall ein node mit der Ortsbezeichnung. Es gibt keine Hierarchie, jedenfalls ist diese in der Liegenschaftskarte nicht sichtbar. Sinnvoll wäre es, diese Bezeichnungen bei kleinerem Zoomlevel nicht anzuzeigen, da im Moment die Karte bei z=..16 etwas überfüllt aussieht. Sicher ist eine einfache Änderung des map style sheets ausreichend. Am 05.09.11 10:30, schrieb Martin Koppenhoefer: Am 5. September 2011 07:43 schrieb Martin Simongrenzde...@gmail.com: Wie wäre es stattdessen mit einem subtagging von place=locality in der Art von locality=cadastral_section? Dann kann ein Renderer selbst entscheiden, ab wann er sowas rendert. wobei er das erst dann sinnvoll kann, wenn auch andere Werte (darüber/darunter) festgelegt (und möglichst getaggt) sind, die locality haben könnte. Unterhalb der section könnte z.B. das lot kommen (Flurstück, in OSM überschneidet sich das ggf. mit addr:housename), darüber kommt in Deutschland im Kataster die Gemarkung, auf Englisch in der Wikipedia habe ich gefunden: * counties (Grafschaft/Landkreis) * parishes (Parocchie, Pfarrgemeinde, Landkreis), wobei civil_parish explizit nichts mit der Kirche zu tun hat. * ridings * quarter sessions (Gerichtsbezirke) * hundreds/wapentakes (dt. Harde) Durch die Flurbereinigungen könnte ich mir allerdings vorstellen, dass es viele Flurnamen gibt, die mit dem Kataster gar nicht mehr zu tun haben. Das Thema ist ein weites Feld ;-) und sehr von den lokalen Gegenheiten (Struktur, Kultur, Geschichte, Politik) abhängig. M.E. ist es vermutlich sinnvoller, so was wie admin_level auch für places zu haben (z.B. locality_level?), d.h. ein numerisches hierarchisches System, wo man bewusst Lücken lässt (siehe admin_level=3), damit auch Untereinheiten, die es nicht in allen Ländern gibt, bei Bedarf eingebettet werden können. Zusätzlich wäre dann eine Tabelle für die einzelnen Länder/Gegenden sinnvoll, die die Entsprechungen im Wiki dokumentiert. Da diese Einheiten teilweise nicht mit der politischen Verwaltungsstruktur übereinstimmen, halte ich eine von admin:level und boundary=administrative getrennte Erfassung durchaus für gerechtfertigt. Gruß Martin ___ 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] Begleitgrün an Wegen und Bächen
Hallo, Es gibt häufig bis zu 10 breite (aber natürlich auch schmalere) Gehölzstreifen neben Wegen und Bächen. Sie gliedern eine Landschaft angenehm und haben außer dem Windschutz vielfältige Vorteile. Sie werden meist als Hecken oder Knicks bezeichnet. Jetzt muß ich selber solche Flächen eintragen und fand beim Suchen, wie es andere Mapper in ähnlichen Fällen halten, den tag natural=wood. Über Alleen (Baureihen) hatten wir hier schon geschrieben. Das trifft aber nicht das Besondere solchen Grüns. Mir schmeckt jedenfalls der Naturwald nicht. Forstlich werden die Flächen zwar nicht unbedingt genutzt, wenn es jedoch zu Gefährdungen kommt, greift der Rechtsträger ein oder ein Baulastträger (Straße). Bis jetzt habe ich noch nicht so recht was gefunden. Wikipedia kennt diesen Begriff als eigenständige Kategorie. Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Begleitgrün an Wegen und Bächen
Hallo, Am Montag 05 September 2011 14:38:13 schrieb Albrecht Will: Hallo, Es gibt häufig bis zu 10 breite (aber natürlich auch schmalere) Gehölzstreifen neben Wegen und Bächen. Sie gliedern eine Landschaft angenehm und haben außer dem Windschutz vielfältige Vorteile. Sie werden meist als Hecken oder Knicks bezeichnet. Jetzt muß ich selber solche Flächen eintragen und fand beim Suchen, wie es andere Mapper in ähnlichen Fällen halten, den tag natural=wood. Über Alleen (Baureihen) hatten wir hier schon geschrieben. Das trifft aber nicht das Besondere solchen Grüns. Mir schmeckt jedenfalls der Naturwald nicht. Forstlich werden die Flächen zwar nicht unbedingt genutzt, wenn es jedoch zu Gefährdungen kommt, greift der Rechtsträger ein oder ein Baulastträger (Straße). Bis jetzt habe ich noch nicht so recht was gefunden. Wikipedia kennt diesen Begriff als eigenständige Kategorie. http://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dhedge_bank Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] josm und natural=tree_row
Hallo, Josm hat wohl noch Probleme mit diesem neuen tag. Als Warnung kommt, daß die Linie nicht geschlossen ist. Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Begleitgrün an Wegen und Bächen
Am Montag 05 September 2011, 14:42:55 schrieb Wolfgang: http://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dhedge_bank Gruß, Wolfgang Hi Wolfgang, danke für den Tip. Nur finde ich die dünnen Linien für ja eigentlich grüne Flächen unproportioniert. Wie würdest Du mit der Situation http://www.openstreetmap.org/?lat=52.4625398218632lon=11.9349476695061zoom=17 in JOSM umgehen? Ich habe erstmal nur den einen etwa parallen Streifen mit o.g. tag markiert. Der verbreitert sich dann nach Osten, Gruß Albrecht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Begleitgrün an Wegen und Bächen
Gebüsch kann man auch mit natural=scrub mappen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=locality nodes und mapnik
Am 5. September 2011 14:22 schrieb Andi K test9...@gmx.de: Ich konnte nichts finden zu locality=cadastral_section Kannst du kurz definieren, was es, als Erweiterung von place=locality, genau bedeutet? Der Vorschlag kam von Martin Simon. Ich hatte das so interpretiert, dass es ein englischer tag für Flurnamen (als nähere Beschreibung der Art des im locality-tag beschrieben Objekts) sein soll, habe aber selbst vorgeschlagen, stattdessen einen numerischen Wert _ähnlich_ dem admin_level zu entwickeln, z.B. place_level, und die genaue Wortbedeutung der Werte in den einzelnen Sprach- und Kulturräumen in einer Wiki-Liste zu führen. Flurnamen sind in jedem Fall historisch und gehen auch über administrative Grenzen hinaus, sind eher geographischer Natur, sprich die Benennung von Waldstücken, aber auch die Benennung von nicht klar abzugrenzener Wiesen, Täler usw. Ich denke, eine administrative Ebene festzulegen, wäre das falsche Vorgehen. klar, das hat bisher auch noch niemand vorgeschlagen hier. Auch offiziell sind die Gebiete nur benannt, aber _nicht_ klar umrissen und wurden zur Orientierung in noch dörflich-landwirtschaftlich geprägteren Zeiten benutzt, sind daher einfach interessante Zeugen einer vergangenen Zeit. Ziemlich sicher werden diese Gebiete klar umrissen gewesen sein, vielleicht haben sich diese Grenzen im Laufe der Zeit auch geändert. Wenn Du in alten Katastern nachsehen kannst, würdest Du sie vermutlich finden. In OSM freuen wir uns aber auch schon über nodes ;-) Es reicht daher auf jeden Fall ein node mit der Ortsbezeichnung. Es gibt keine Hierarchie, jedenfalls ist diese in der Liegenschaftskarte nicht sichtbar. die Hierarchie muss ja nicht unbedingt in der Karte erkennbar sein, es kann auch sein, dass die Namen Deiner Karte alle in derselben Hierarchie-ebene sind, das schließt aber eine Hierarchie nicht aus (vermutlich benötigte man mehrere Dokumente, um diese nachzubilden). Es ging mir darum, an welcher Stelle der Hierachie Deine Flurnamen sich befinden. In dem Bereich sind wir ja bisher noch am Sammeln, haben nur Bruchstücke. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wenn das Hochladen fehlschlägt
Am 5. September 2011 14:19 schrieb Albrecht Will albrecht.w...@online.de: Ich dachte an folgendes Vorgehen: - Polygone ohne innere Flächen gehen raus als einfache Forstflächen. - Polygone mit inneren Flächen gehen raus und erhalten als MP eine jeweils eigenständige Relation +1, mach es so Nun habe ich aber noch ein Problem. Das Rest-MP hat eine innere Fläche, die durch die Teilungen am Außenrand liegt. Bei einer Neukonstruktion war mir das bisher nicht möglich. Was hat es damit auf sich? Vermutlich musst Du ein neues Multipolygon für das Objekt dieser inneren Fläche machen (diese neue Relation erhält die Tags die bisher die innere Fläche hatte, falls die welche hatte, ansonsten brauchst Du kein neues Multipolygon). Danach kannst Du den Umfassungs-way an den Stellen teilen, wo der way jetzt zusätzlich outer-Member des anderen Multipolygons werden muss. Als inner-member fliegt die Fläche raus wenn sie jetzt am Rand liegt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Begleitgrün an Wegen und Bächen
Am 05.09.2011 14:38, schrieb Albrecht Will: Hallo, Es gibt häufig bis zu 10 breite (aber natürlich auch schmalere) Gehölzstreifen neben Wegen und Bächen. Sie gliedern eine Landschaft angenehm und haben außer dem Windschutz vielfältige Vorteile. Sie werden meist als Hecken oder Knicks bezeichnet. Jetzt muß ich selber solche Flächen eintragen und fand beim Suchen, wie es andere Mapper in ähnlichen Fällen halten, den tag natural=wood. bei mir laufen die einfach ;-) unter Hecke sind halt unterschiedlich, mache sind mitlerweile Baumreihen, andere eben Haushohe Hecken. oft werden zur Brennholzgewinnung in der Hecke Bäume stehen gelassen Über Alleen (Baureihen) hatten wir hier schon geschrieben. Alleen sind im Grunde was anderes, Alleen werden als solche gepflanzt, entstehen eigentlich nicht aus Hecken. http://wiki.openstreetmap.org/wiki/DE:Tag:barrier%3Dhedge_bank ist mir auch neu na ja, bei mir mit Hecke sind grüne Linien... die Gegend hier heißt übrigens auch Monschauer Heckenland http://de.wikipedia.org/wiki/Monschauer_Heckenland beide Bilder sind Hecken und wurden von mir gemacht Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dummy Beginner mit openlayers
On 05.09.2011 19:01, Martin Koppenhoefer wrote:
Am 5. September 2011 18:54 schrieb Wolfgang Wienkewo_wie...@gmx.net:
Am 05.09.2011 10:42, schrieb Martin Koppenhoefer:
Die meint: Fehler: OpenLayers.Layer.OSM.Mapnik is not a constructor
und fehlende Styles.
Hast Du die Datei src=OpenStreetMap.js lokal vorhanden? Das ist
AFAIR die js-Datei, die OpenLayers.Layer.OSM.Mapnik definiert.
warum?
Die Doku von Openlayers sagt, dass das dort bereits enthalten ist. Ganz
ohne was Spezielles:
OpenLayers.Layer.OSM
A class to access OpenStreetMap tiles. By default, uses the
OpenStreetMap hosted tile.openstreetmap.org ‘Mapnik’ tileset. If you
wish to use tiles@home / osmarender layer instead, you can pass a layer
like:
new OpenLayers.Layer.OSM(t@h,
http://tah.openstreetmap.org/Tiles/tile/${z}/${x}/${y}.png;);
This layer defaults to Spherical Mercator.
Inherits from
OpenLayers.Layer.XYZ
Ein Blick in den Source bestätigt das auch...
http://trac.osgeo.org/openlayers/browser/trunk/openlayers/lib/OpenLayers/Layer/XYZ.js
Also einfach verwenden. Nix spezielles von OSM erforderlich.
Falls die Website etwas mehr Traffic hat bitte mal überlegen einen
alternativen Tileserver, z.B: von Mapquest verwenden.
Stephan
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dummy Beginner mit openlayers
Am 5. September 2011 21:37 schrieb Stephan Knauss o...@stephans-server.de:
On 05.09.2011 19:01, Martin Koppenhoefer wrote:
Hast Du die Datei src=OpenStreetMap.js lokal vorhanden? Das ist
AFAIR die js-Datei, die OpenLayers.Layer.OSM.Mapnik definiert.
warum?
Die Doku von Openlayers sagt, dass das dort bereits enthalten ist. Ganz ohne
was Spezielles:
OpenLayers.Layer.OSM
This layer defaults to Spherical Mercator.
Inherits from
OpenLayers.Layer.XYZ
http://trac.osgeo.org/openlayers/browser/trunk/openlayers/lib/OpenLayers/Layer/XYZ.js
Also einfach verwenden. Nix spezielles von OSM erforderlich.
ja, es ist nicht erforderlich, aber er hatte diese Fehlermeldung
gepostet: Fehler: OpenLayers.Layer.OSM.Mapnik is not a constructor
und hatte die js-Datei von OSM eingebunden: script
src=OpenStreetMap.js/script
Das kann man auch machen (so macht es die Karte auf osm.org), dann
wird u.a. dieser Code mit eingebunden:
/**
* Class: OpenLayers.Layer.OSM.Mapnik
*
* Inherits from:
* - OpenLayers.Layer.OSM
*/
OpenLayers.Layer.OSM.Mapnik = OpenLayers.Class(OpenLayers.Layer.OSM, {
/**
* Constructor: OpenLayers.Layer.OSM.Mapnik
*
* Parameters:
* name - {String}
* options - {Object} Hashtable of extra options to tag onto the layer
*/
initialize: function(name, options) {
var url = [
http://a.tile.openstreetmap.org/${z}/${x}/${y}.png;,
http://b.tile.openstreetmap.org/${z}/${x}/${y}.png;,
http://c.tile.openstreetmap.org/${z}/${x}/${y}.png;
];
options = OpenLayers.Util.extend({
numZoomLevels: 19,
buffer: 0,
transitionEffect: resize
}, options);
var newArguments = [name, url, options];
OpenLayers.Layer.OSM.prototype.initialize.apply(this, newArguments);
},
CLASS_NAME: OpenLayers.Layer.OSM.Mapnik
});
Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] NMEA
Hallo, ich schlage mich gerade mit NMEA herum und wunder mich über sehr unterschiedliche Kurse in verschiedenen Sätzen: $IIRMC,203740,A,3700.660,N,00813.710,W,3.1,105.0,280711,3,W,A*10 IIHDG,043.0,,,3,W*2A $IIHDM,043.0,M*25 $IIHDT,040.0,T*26 in den letzten 3 ist der Kurs bei 43 bzw 40 Grad (magnetisc / Karte) soweit so gut, aber was soll die 105.0 in IIRMC? Bei NMEA-File im Netz habe iich ähnliche Abweichungen gefunden, scheint also kein Defekt zu sein Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NMEA
Hallo Dimitri In IIRMC wird nicht der Kurs angezeigt sondern die Magnetic Variation in Grad. Das ist Deklimation oder auch Missweisung. Gruß Rolf -Ursprüngliche Nachricht- Von: Dimitri Junker [mailto:o...@dimitri-junker.de] Gesendet: Dienstag, 6. September 2011 02:00 An: talk-de@openstreetmap.org Betreff: [Talk-de] NMEA Hallo, ich schlage mich gerade mit NMEA herum und wunder mich über sehr unterschiedliche Kurse in verschiedenen Sätzen: $IIRMC,203740,A,3700.660,N,00813.710,W,3.1,105.0,280711,3,W,A*10 IIHDG,043.0,,,3,W*2A $IIHDM,043.0,M*25 $IIHDT,040.0,T*26 in den letzten 3 ist der Kurs bei 43 bzw 40 Grad (magnetisc / Karte) soweit so gut, aber was soll die 105.0 in IIRMC? Bei NMEA-File im Netz habe iich ähnliche Abweichungen gefunden, scheint also kein Defekt zu sein Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de - eMail ist virenfrei. Von AVG überprüft - www.avg.de Version: 10.0.1392 / Virendatenbank: 1520/3878 - Ausgabedatum: 05.09.2011 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
