Re: [Talk-de] Vulkan
Am Mittwoch, den 28.12.2011, 00:39 +0100 schrieb Martin Koppenhoefer: > Am 27. Dezember 2011 23:57 schrieb Michael Krämer : > >> >> "ridge" > >> > Bergrücken? Höhenzug? eher rund und flach... > >> > >> > >> ridge bezeichnet durchaus eine Kette von Bergen (also mit Gipfeln) und > >> ist dann steil bzw. spitz, scheint aber eher mehrere Berge zu > >> betreffen, daher nicht für einen Grat / Kamm zu gebrauchen. > > Da möchte ich jetzt doch widersprechen. Ridge entspricht sehr wohl dem > > deutschen Grat. > Moin Ridge kommt aus dem selben Stammwort 'hrukki', wie das deutsche Rücken und hat auch fast die gleichen Bedeutungen. Rücken und Grat sind keine Synonyme, der Rücken ist breit, der Grat scharf. Grat sollte man besser mit Crest übersetzen. > > +1 > danke für den Hinweis. Der erstbesten Wörterbuchdefinition [1] für > ridge gemäß entspricht es ebenfalls dem Grat: > "a long narrow raised part of a surface, especially a high edge along a > mountain > We walked along the narrow mountain ridge. > figurative A ridge (= narrow area) of high pressure will bring good > weather this afternoon. > • the part of a roof where the sloping sides join at the top" > > Ich hatte das aus der englischen Wikipedia (aus der Du auch zitierst), > die fasst "ridge" so zusammen: "A ridge is a geological feature > consisting of a chain of mountains or hills that form a continuous > elevated crest for some distance. Ridges are usually termed hills or > mountains as well, depending on size. There are several main types of > ridges:" was im Deutschen einer Bergkette entspricht (und der Artikel > ist mit "Gebirgskamm" verlinkt). > > Dementsprechend könnte man natural=ridge für die spitzen "linearen > Bergfeatures" verwenden (und ggf. Untertypen subtaggen). I oppose! > > Das "Gegenteil", eine Rinne, könnte man nach [3] dann so taggen: > natural=couloir (schon wieder französisch?) Ich denke gap, gorge oder notch wäre für eine Rinne wohl passender, couloir meint eine steile Rinne, in der darum kein Geröll liegen bleibt. Aber das Gegenteil von ridge nennt man wohl dale oder valley. Moin Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Nur mal so neben bei: Die Franzosen waren in der Vergangenheit, so ca. ab der Revolution bis zum Ende Napoleons auch mal Pioniere und mit führend in der Vermessung der Welt. Deshalb gibt es da noch eine Reihe von französischen Wörtern in der Fachsprache. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Am 27. Dezember 2011 23:57 schrieb Michael Krämer : >> >> "ridge" >> > Bergrücken? Höhenzug? eher rund und flach... >> >> >> ridge bezeichnet durchaus eine Kette von Bergen (also mit Gipfeln) und >> ist dann steil bzw. spitz, scheint aber eher mehrere Berge zu >> betreffen, daher nicht für einen Grat / Kamm zu gebrauchen. > Da möchte ich jetzt doch widersprechen. Ridge entspricht sehr wohl dem > deutschen Grat. +1 danke für den Hinweis. Der erstbesten Wörterbuchdefinition [1] für ridge gemäß entspricht es ebenfalls dem Grat: "a long narrow raised part of a surface, especially a high edge along a mountain We walked along the narrow mountain ridge. figurative A ridge (= narrow area) of high pressure will bring good weather this afternoon. • the part of a roof where the sloping sides join at the top" Ich hatte das aus der englischen Wikipedia (aus der Du auch zitierst), die fasst "ridge" so zusammen: "A ridge is a geological feature consisting of a chain of mountains or hills that form a continuous elevated crest for some distance. Ridges are usually termed hills or mountains as well, depending on size. There are several main types of ridges:" was im Deutschen einer Bergkette entspricht (und der Artikel ist mit "Gebirgskamm" verlinkt). Dementsprechend könnte man natural=ridge für die spitzen "linearen Bergfeatures" verwenden (und ggf. Untertypen subtaggen). Das "Gegenteil", eine Rinne, könnte man nach [3] dann so taggen: natural=couloir (schon wieder französisch?) Gruß Martin [1] http://dictionary.cambridge.org/dictionary/british/ridge?q=ridge [2] http://en.wikipedia.org/wiki/Ridge [3] http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
> >> "ridge" > > Bergrücken? Höhenzug? eher rund und flach... > > > ridge bezeichnet durchaus eine Kette von Bergen (also mit Gipfeln) und > ist dann steil bzw. spitz, scheint aber eher mehrere Berge zu > betreffen, daher nicht für einen Grat / Kamm zu gebrauchen. Da möchte ich jetzt doch widersprechen. Ridge entspricht sehr wohl dem deutschen Grat. Hier ein Zitat aus der englischen Wikipedia zu Ridge: “Volcanic caldera ridges: Large volcanoes often leave collapsed central calderas that are bordered by circular ridges.“ passt doch wunderbar Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] leaflet statt OpenLayer
Am 27.12.2011 20:45, schrieb Chris66: Am 24.12.2011 16:06, schrieb Simon Poole: Ein kleines Geschenk von mir .. http://cleanmap.poole.ch/ Hat es einen besonderen Grund dass die Seite mit leaflet und nicht mit OL programmiert ist? Wolltest Du das mal ausprobieren? Taugt es als OL Ersatz? Programmiert ist wohl übertrieben (wegen den paar Zeilen). Leaflet ist einfacher und sieht deutlich besser aus (ohne weiteres dazutun), dafür kanns halt auch weniger im jetzigen Zeitpunkt (mal von diversen kleine Bugs abgesehen). Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] leaflet statt OpenLayer (was: Re: Bescherung ...)
Am 24.12.2011 16:06, schrieb Simon Poole: > Ein kleines Geschenk von mir .. http://cleanmap.poole.ch/ Hat es einen besonderen Grund dass die Seite mit leaflet und nicht mit OL programmiert ist? Wolltest Du das mal ausprobieren? Taugt es als OL Ersatz? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan - Berg, Grat
Am 27. Dezember 2011 17:27 schrieb Markus : >> ja, "rim" wie von Klaus-Hermann vorgeschlagen passt gut >> natural=crater_rim > Habe ich so eingefügt. würde ich machen wie retaining_wall, cliff und coastlines: der tiefere Teil (bzw. hier der steile) rechts in Wegrichtung > Also Bergkette? oder Gebirgszug? > Sowas wird ja nun wohl besser nicht als Linie in die Karte eingetragen. man könnte z.B. eine route-relation machen (z.B. route=mountain_ridge), wo man einzelne Grate als member einfügt. > Jetzt brauchen wir noch etwas für Grat... ja, mein Vorschlag wäre dafür evtl. natural=mountain_edge (Kommentare?) oder evtl. halt doch natural=arête (-0.7 von mir). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan - Berg, Grat
Am 27.12.2011 17:27, schrieb Markus: Hallo Martin, > ja, "rim" wie von Klaus-Hermann vorgeschlagen passt gut > natural=crater_rim Habe ich so eingefügt. Jetzt brauchen wir nur noch viele Krater-Ränder, damit Mapnik etwas Schönes daraus machen kann :-) auch bei Riesen (meteor) Kratern (nörtlinger ries)? wie ist bei den Maaren, eifel? beides? See und Krater? ok, es gibt auch trockene Maare... Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
SimonPoole wrote > > Achtung ... ich hab nichts zu den Häkchen gesagt (mindestens in dem > Beitrag), die Info ist auch nicht öffentlich zugänglich. > alles klar. gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Neue-Regeln-im-OSMI-ODbL-View-tp7128618p7130550.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] 28c3
Am 26.12.2011 20:21, schrieb Dirk-Lüder Kreie: Ich bin jetzt im bcc und habe unseren Tisch "in Betrieb genommen". Zusätzlich hängt da jetzt eine Weste an der Wand, damit es besser sichtbar ist (bin mehrfach daran vorbeigelaufen )-: Und ist wie "jedes Jahr": zu wenig Platz. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan - Berg, Grat
Hallo Martin, ja, "rim" wie von Klaus-Hermann vorgeschlagen passt gut natural=crater_rim Habe ich so eingefügt. Jetzt brauchen wir nur noch viele Krater-Ränder, damit Mapnik etwas Schönes daraus machen kann :-) - - - - "ridge" Bergrücken? Höhenzug? eher rund und flach... ridge bezeichnet durchaus eine Kette von Bergen (also mit Gipfeln) und ist dann steil bzw. spitz, scheint aber eher mehrere Berge zu betreffen, daher nicht für einen Grat / Kamm zu gebrauchen. Also Bergkette? oder Gebirgszug? Sowas wird ja nun wohl besser nicht als Linie in die Karte eingetragen. Sondern höchstens als Namenszug in niedrigen Zoomleveln gerendert. Oder eben als Relation aus mehreren Gipfeln und Gräten zusammengesetzt. Im Wiki steht dann auch "chain of ways"... Wenn das so Konsens ist, ersetze ich das Bild und nehme "(or single way)" dort raus. "arete" Grat, Flanke. Ich meinte natürlich: Grat, Kamm. Einig sind wir uns wohl darin, nach der Form zu klassifizieren und z.B. die geologische Entstehung erstmal rauszulassen? Form, Funktion, und Entstehung sind verschiedene Klassen. Kann man natürlich alles abblden. Beginnen würde ich aber mal mit der Form :-) Mit Gipfel, Grat und Pass kann man geografisch schon eine ganze Menge anfangen. Jetzt brauchen wir nur noch grafische Symbole für den Renderer, damit er alles hübsch darstellen kann. Gipfel haben wir ja schon, und mit alt kann man auch die Höhe unterscheiden und mit der Dominanz die Wichtigkeit. Pass gibt es auch, und in Verbindung mit Strasse oder Weg kann auch die Bedeutung unterschieden werden. Klippe habe ich auch schon gesehen. Jetzt brauchen wir noch etwas für Grat... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Am 27. Dezember 2011 15:01 schrieb Markus : >> M.E. verdient ein Kraterrand einen eigenen tag > natural=crater > oder eindeutiger: > natural=kraterrand ja, "rim" wie von Klaus-Hermann vorgeschlagen passt gut, ich sehe das als geographisches Feature wie Ihr in natural: natural=rim oder natural=crater_rim >> "ridge" > Bergrücken? Höhenzug? eher rund und flach... ridge bezeichnet durchaus eine Kette von Bergen (also mit Gipfeln) und ist dann steil bzw. spitz, scheint aber eher mehrere Berge zu betreffen, daher nicht für einen Grat / Kamm zu gebrauchen. >> "arete" > Grat, Flanke. eine Bergflanke ist die Seite eines Berges, oder? Die kann steil oder evtl. auch flach sein? Der Grat ist die Schnittlinie zweier geneigter Flächen wenn sie spitz bzw. scharf ist, das hast Du am Dach wie im Gebirge und passt gut. Ob "arête" nun ein allgemeines Wort dafür ist können uns die Engländer sicher besser erklären, da müssen wir mutmaßen. Wikipedia schreibt ja, dass man im Alpenraum das deutsche Wort "grat" oder "kamm" verwendet (für uns nichts neues ;-) ). Einig sind wir uns wohl darin, nach der Form zu klassifizieren und z.B. die geologische Entstehung erstmal rauszulassen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Da is wohl etwas falsch gelaufen, also noch einmal: Eine Caldera ist ein eingestürzter Krater(Senkkrater). Die größte ist meines Wissenas nach die 'Caldera de Taburiente' auf La Palma. Ein roter See wird es wohl nur, wenn man es als area tagt. Hier mal ein Bilderlink, http://www.google.com/search?q=volcanorim&hl=de&client=iceweasel-a&rls=org.mozilla:de:unofficial&prmd=imvns&tbm=isch&tbo=u&source=univ&sa=X&ei=UNv5TvzCKI7zsgbglYzxDw&ved=0CHIQsAQ&biw=1280&bih=592 ist es das, was Ihr meint? Da die Kante ein Attribut des Kraters ist, wäre m.E. crater=rim angemessen. Moin Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Am Dienstag, den 27.12.2011, 15:21 +0100 schrieb Markus: > Hallo Klaus, > > > Kraterrand: natural=crater-rim > > Klingt gut, ausser dass zusammengesetzte Wörter im Wert immer wieder > anders geschrieben werden: > crater-rim > crater_rim > crater rim > craterrim > > Wir bräuchten halt etwas, das den Krater-*Rand* bezeichnet, > und das man als *Linie* zeichnen kann, ggf auch als geschlossene. > (nicht dass der Renderer noch einen roten See malt ;-) ) > > Vielleicht gibt es Geologen hier, die den Fachbegriff kennen? > > Gruss, Markus > > PS: In einem alten Buch habe ich auch noch "caldera" gefunden. > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de Eine Caldera ist ein eingestürzter Krater(Senkkrater). Die größte ist meines Wissenas nach die 'Caldera de Taburiente' auf La Palma. Ein roter See wird es wohl nur, wenn man es als area tagt. Hier mal ein Bilderlink, http://www.google.com/search?q=volcano +rim&hl=de&client=iceweasel-a&rls=org.mozilla:de:unofficial&prmd=imvns&tbm=isch&tbo=u&source=univ&sa=X&ei=UNv5TvzCKI7zsgbglYzxDw&ved=0CHIQsAQ&biw=1280&bih=592 ist es das, was Ihr meint? (; die Felge ist auch dabei. Moin Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Hallo Klaus, Kraterrand: natural=crater-rim Klingt gut, ausser dass zusammengesetzte Wörter im Wert immer wieder anders geschrieben werden: crater-rim crater_rim crater rim craterrim Wir bräuchten halt etwas, das den Krater-*Rand* bezeichnet, und das man als *Linie* zeichnen kann, ggf auch als geschlossene. (nicht dass der Renderer noch einen roten See malt ;-) ) Vielleicht gibt es Geologen hier, die den Fachbegriff kennen? Gruss, Markus PS: In einem alten Buch habe ich auch noch "caldera" gefunden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Am Dienstag, den 27.12.2011, 14:38 +0100 schrieb Martin Koppenhoefer: > Am 27. Dezember 2011 14:20 schrieb Markus : > >>> Wie bezeichnet man den Krater-Rand? > >> soweit ich weiss gibt es hierzu bisher keinen Vorschlag. > > > > Der Kraterrand ist ja selbst auf schlechten Luftbildern anhand der > > Schattenbildung ausgezeichnet zu erkennen. > > > ja, kein Zweifel, er ist auch in mittel aufgelösten DEM (z.B. SRTM) > hervorragend zu erkennen. > > > > Es gibt ein Attribut für "Berggrat": > > http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains > > > welchen der dort vorgeschlagenen Werte meinst Du? > > > > Auch ein Grat lässt sich auf DOPS gut erkennen. > > Bein Vulkan wäre er dann einfach ringförmig ;-) > > > und relativ flach an der Aussenseite ;-). M.E. verdient ein Kraterrand > einen eigenen tag, ein Berggrat ist was anderes. Von der bisherigen > Tags passt ggf. cliff besser für Krater als das, was die vg. Wikiseite > vorschlägt. So ganz klar finde ich die Abgrenzung von "ridge" und > "arete" dort allerdings auch nicht. > > Lt. Taginfo gibt es bereits ein paar hundert mal natural=crater in den Daten. > > Gruß Martin > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de Auch wenn die wenigsten Vulkane sich unter dieser Bilderbuchvorstellung zusammenfassen lassen, würde ich den Kraterrand mit natural=crater-rim taggen. Crater-rim, damit niemand mit Googleenglisch auf die Idee kommt, da läge eine Autofelge. Moin Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Hallo Martin, Es gibt ein Attribut für "Berggrat": http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains welchen der dort vorgeschlagenen Werte meinst Du? Habe dort mal ein paar deutsche Begriffe und vor allem Bilder hinzugefügt (weiss aber nicht so genau, ob ich das Englische richtig verstehe) M.E. verdient ein Kraterrand einen eigenen tag natural=crater oder eindeutiger: natural=kraterrand cliff bedeutet "Steilküste" (Kreidefelsen, irische Küste, etc) "ridge" Bergrücken? Höhenzug? eher rund und flach... "arete" Grat, Flanke. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Am 27. Dezember 2011 14:20 schrieb Markus : >>> Wie bezeichnet man den Krater-Rand? >> soweit ich weiss gibt es hierzu bisher keinen Vorschlag. > Der Kraterrand ist ja selbst auf schlechten Luftbildern anhand der > Schattenbildung ausgezeichnet zu erkennen. ja, kein Zweifel, er ist auch in mittel aufgelösten DEM (z.B. SRTM) hervorragend zu erkennen. > Es gibt ein Attribut für "Berggrat": > http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains welchen der dort vorgeschlagenen Werte meinst Du? > Auch ein Grat lässt sich auf DOPS gut erkennen. > Bein Vulkan wäre er dann einfach ringförmig ;-) und relativ flach an der Aussenseite ;-). M.E. verdient ein Kraterrand einen eigenen tag, ein Berggrat ist was anderes. Von der bisherigen Tags passt ggf. cliff besser für Krater als das, was die vg. Wikiseite vorschlägt. So ganz klar finde ich die Abgrenzung von "ridge" und "arete" dort allerdings auch nicht. Lt. Taginfo gibt es bereits ein paar hundert mal natural=crater in den Daten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Hallo Martin, Wie bezeichnet man den Krater-Rand? soweit ich weiss gibt es hierzu bisher keinen Vorschlag. Der Kraterrand ist ja selbst auf schlechten Luftbildern anhand der Schattenbildung ausgezeichnet zu erkennen. Es gibt ein Attribut für "Berggrat": http://wiki.openstreetmap.org/wiki/Proposed_features/Mountains Auch ein Grat lässt sich auf DOPS gut erkennen. Bein Vulkan wäre er dann einfach ringförmig ;-) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Am 27. Dezember 2011 13:48 schrieb Simon Poole : > Aber CC-by-SA 2.0? Und ohne Möglichkeit je davon wegzukommen? dass die bisherige Lizenz "ewig" gilt und nicht geändert werden kann könnte man auch als Feature auffassen. CC-BY-SA ist aber wohl in der Tat nicht besonders gut geeignet für uns (Gründe sind hinreichend erörtert). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
On 2011-12-26 19:27, Frederik Ramm wrote: [...] Auch die Datenbank auf wtfe.gryph.de und damit die Lizenzwechsel-Anzeige im Editor sollte angepasst sein. [...] Sicher sind noch ein paar Bugs drin, und ich freue mich ueber Meldungen derselben Da hab ich einen, der nur die Editoren betrifft: in JOSM wird ODBL=clean wird ignoriert, egal, ob es nur lokal existiert oder auch schon im OSMI korrekt angezeigt wird (und damit auf jeden Fall in deiner Datenbank ist). In Potlatch sehe ich dort auch orange Markierungen, sodass das hier wohl auch nicht berücksichtigt wird. Beispiel-Stelle: http://tools.geofabrik.de/osmi/?view=wtfe&lon=8.80617&lat=47.98074&zoom=16 Danke für die bisherige Arbeit und viele Grüße! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
Am 27. Dezember 2011 12:35 schrieb Walter Nordmann :
> im Forum gibt es hier was Aktuelles für Bergrücken, Grate.
>
> http://forum.openstreetmap.org/viewtopic.php?id=14865
> Damit könnte man doch auch den Kraterand erfassen.
Wenn "englische" Wörter Akzente beinhalten wäre ich immer ein bisschen
vorsichtig, das sind dann meistens Fachtermini mit eng eingeschränkter
Bedeutung (m.E. eher ungeeignet als allgemeine Tags, sinnvoll dann,
wenn man genau dieses Feature taggen will, also eher als subtag).
Es gab zu Bergrücken eine Diskussion auf der tagging-ML, wo unter
anderem die Wörter "ridge" und "edge" gefallen sind. "Arête" kommt mir
für einen vulkanischen Krater nicht geeignet vor (lt. Wikipedia sind
das Strukturen, die durch Gletscher entstanden sind). Der verlinkte
Artikel http://en.wikipedia.org/wiki/Ar%C3%AAte schreibt, in den Alpen
sei der passende Fachterminus der deutsche ("Grat" oder "Kamm").
Gruß Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Am 27.12.2011 13:31, schrieb Frederik Ramm: Hi, On 12/27/11 11:42, Henning Scholland wrote: Weiterhin habe ich noch eine Frage zu deiner Systematik beim Ändern nur eines Taggs. Ist da sichergestellt, dass ein bspw. wenn ein amenity=place_of_worship in ein amenity=arts_centre geändert wird, würde ich dem schon die Trivialität absprechen. Bei mir ist es trivial, wenn der *key* spaeter weg ist. Also wenn Du als Nichtzustimmer ein "amenity=place of worship" setzt und spaeter ist noch *irgendein* amenity-Tag da, dann wird davon ausgegangen, dass Deine Aenderung nicht trivial war, selbst wenn, wie in Deinem Beispiel, eine komplette Bedeutungsaenderung vorliegt. Das ist nicht ganz optimal. Auch im umgekehrten Fall kann es schiefgehen - Du als Nichtzustimmer setzt "nmae=Freds Kajuete" und jemand anders repariert in "name=Freds Kajuete", da wuerde man ja eigentlich sagen, die Reparatur ist trivial, der Erstmapper hat das Copyright, obwohl sich der Key geaendert hat. Hallo, wie du schon sagst ist es schwer per Bot zu entscheiden, ob die Änderung an dem Tagg trivial ist oder nicht. Selbst über eine Ähnlichkeitsanalyse (wenn man sowas programmiert bekommt) wird der Bot dies nicht in allen Fällen erkennen können. Wäre es dann nicht sinnvoll, wenn man Fälle (key identisch, value geändert und key geändert, value identisch) gesondert markiert (bspw. als: möglicherweise trivialer Edit), sodass ein Mensch sich dies anschaut und entscheiden kann. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Am 20:59, schrieb Markus: Hallo Simon, Ich weiss dass viele OSMer der ODbL deshalb nicht zugestimmt haben, weil PD/CC0 die Lizenz ihrer Wahl ist. Es gab im September 476 mapper mit identifizierbaren PD Erklärungen auf ihrer wiki Seite. Ich hab nochmals mein Auswerteskript mit aktuellen Lizenzdaten laufen lassen (da es keine 1 zu 1 Beziehung zwischen Benutzerkonto und wiki-Seite gibt, sind ~100 nicht zuweisbar) Nur ein kleiner Teil der OSMer hat eine Wikiseite. Nicht alle die für PD/CC=ind, haben dies auf ihrer Wikiseite vermerkt. Klar, hat auch niemand behauptet, aber man daraus durchaus schliessen, dass der überwiegende Teil der Mapper die PD wollen und -keine- WIkiseite haben wohl auch den CTs zugestimmt haben. Du kannst natürlich gerne eine Umfrage oder ähnliches durchführen, nur frage ich mich wen du eigentlich damit erreichen willst. - die Mapper die den CTs schon zugestimmt haben? Wir haben bereits ein festgelegtes Abstimmungsprozedere für einen Lizenzwechsel, also ist keine Umfrage nötig, du musst einfach genügend Leute davon überzeugen eine solche Abstimmung durchführen zulassen. - die ca. 400 Mapper die abgelehnt haben (die meisten wohl definitiv nicht weil sie PD wollen)? Kannst denen gerne eine Mail schicken. - die verbleibenden ~50'000 Mapper die nicht geantwortet haben? Ich verrat dir ein kleines Geheimnis: die meisten sind wohl so oder so nicht mehr erreichbar und erst recht nicht für eine Umfrage. Schlussfolgerung: eine überwiegende Mehrheit der Mapper, die ihre Daten als PD/CC0 erklärt haben, haben (logischerweise und auch vernünftig) auch kein Problem damit die CTs anzunehmen. Das ist nicht schlüssig. Zwar ist ODbL irgendwie auch ein bisschen "frei" - aber halt nicht richtig ;-) Vermutlich gibt es einfach viele, die den Unterschied zwischen "frei" und frei nicht kennen, oder denen das wurscht ist. Wer wirklich freie Daten will, kann den vorgeschlagenen Einschränkungen nicht guten Gewissens zustimmen. Aber CC-by-SA 2.0? Und ohne Möglichkeit je davon wegzukommen? Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Am 27.12.2011 06:35, schrieb Bernd Wurst: Gleiches gilt für einen Way: Wenn jemand die Geometrie verändert und jemand anderes verändert diese an den selben Stellen nochmals, dann ist die Erstbearbeitung eigentlich überholt. Ich hab nur Angst vor solchen Fällen: Ein Erstbearbeiter hat einen Way ERSTELLT und Nachbearbeiter haben daran tags ergänzt und Waypoints verändert/ersetzt/dazugefügt. Wenn dann die ganzen Wege verschwinden, dann haben wir gerne diesen "Tsunami-Effekt", daß ganze Ortsteile verschwinden. Was kann man in diesen Fällen retten? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Hi, On 12/27/11 11:42, Henning Scholland wrote: eine Systematik ist mir eingefallen, ändert aber nichts an deinem View, da es Relationen betrifft. Ueber Relationen hab ich mir noch nicht viele Gedanken gemacht, aber das muessen wir frueher oder spaeter auch angehen. Weiterhin habe ich noch eine Frage zu deiner Systematik beim Ändern nur eines Taggs. Ist da sichergestellt, dass ein bspw. wenn ein amenity=place_of_worship in ein amenity=arts_centre geändert wird, würde ich dem schon die Trivialität absprechen. Bei mir ist es trivial, wenn der *key* spaeter weg ist. Also wenn Du als Nichtzustimmer ein "amenity=place of worship" setzt und spaeter ist noch *irgendein* amenity-Tag da, dann wird davon ausgegangen, dass Deine Aenderung nicht trivial war, selbst wenn, wie in Deinem Beispiel, eine komplette Bedeutungsaenderung vorliegt. Das ist nicht ganz optimal. Auch im umgekehrten Fall kann es schiefgehen - Du als Nichtzustimmer setzt "nmae=Freds Kajuete" und jemand anders repariert in "name=Freds Kajuete", da wuerde man ja eigentlich sagen, die Reparatur ist trivial, der Erstmapper hat das Copyright, obwohl sich der Key geaendert hat. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Hallo Walter, Das "PD-Häkchen" hat afaik keinerlei Bedeutung für irgendwelche Entscheidungen/Aktionen der nächsten Monate. Zumindest wurde: a) das Feld in den CT gut versteckt (und dadurch abgewertet) b) dessen Bedeutung nicht deklariert Es soll geplant sein, NACH der Umstellung die Sache nochmal anzugehen und Jedermann auch die Gelegenheit zu geben, seine damalige Meinung zu ändern. Eine erneute Umfrage, ob man: - der CT zustimmt - die ODbL will und ihr zustimmt? - PD/CC0 will und ihr zustimmt? Sagt wer? und wann soll das erfolgen? Und welche Auswirkungen wird das dann haben? Vielleicht sollten wir warten mit dem ganzen Umstellungsprozess, und dem Neueintragen, bis das geklärt ist? Könnte einen Haufen unnützer Arbeit ersparen... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Hallo Simon, Ich weiss dass viele OSMer der ODbL deshalb nicht zugestimmt haben, weil PD/CC0 die Lizenz ihrer Wahl ist. Es gab im September 476 mapper mit identifizierbaren PD Erklärungen auf ihrer wiki Seite. Ich hab nochmals mein Auswerteskript mit aktuellen Lizenzdaten laufen lassen (da es keine 1 zu 1 Beziehung zwischen Benutzerkonto und wiki-Seite gibt, sind ~100 nicht zuweisbar) Nur ein kleiner Teil der OSMer hat eine Wikiseite. Nicht alle die für PD/CC= sind, haben dies auf ihrer Wikiseite vermerkt. Schlussfolgerung: eine überwiegende Mehrheit der Mapper, die ihre Daten als PD/CC0 erklärt haben, haben (logischerweise und auch vernünftig) auch kein Problem damit die CTs anzunehmen. Das ist nicht schlüssig. Zwar ist ODbL irgendwie auch ein bisschen "frei" - aber halt nicht richtig ;-) Vermutlich gibt es einfach viele, die den Unterschied zwischen "frei" und frei nicht kennen, oder denen das wurscht ist. Wer wirklich freie Daten will, kann den vorgeschlagenen Einschränkungen nicht guten Gewissens zustimmen. Gruss, Markus PS: mach doch mal eine Auswertung, wieviele bei der Zustimmung das "PD-Häkchen" angeklicht haben... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Achtung ... ich hab nichts zu den Häkchen gesagt (mindestens in dem Beitrag), die Info ist auch nicht öffentlich zugänglich. Am 27.12.2011 12:49, schrieb Walter Nordmann: Ich würde diese Sache nicht überbewerten. Das "PD-Häkchen" hat afaik keinerlei Bedeutung für irgendwelche Entscheidungen/Aktionen der nächsten Monate. Es soll geplant sein, NACH der Umstellung die Sache nochmal anzugehen und Jedermann auch die Gelegenheit zu gegen, seine damalige Meinung zu ändern. Viele haben - genauso wie ich- einfach das Häkchen gesetzt, als die Frage nach der Zustimmung zur neuen Lizenz kam. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
SimonPoole wrote > > ... eine überwiegende Mehrheit der Mapper, die ihre Daten > als PD/CC0 erklärt haben, haben (logischerweise und auch vernünftig) > auch kein Problem damit die CTs anzunehmen. > Ich würde diese Sache nicht überbewerten. Das "PD-Häkchen" hat afaik keinerlei Bedeutung für irgendwelche Entscheidungen/Aktionen der nächsten Monate. Es soll geplant sein, NACH der Umstellung die Sache nochmal anzugehen und Jedermann auch die Gelegenheit zu gegen, seine damalige Meinung zu ändern. Viele haben - genauso wie ich- einfach das Häkchen gesetzt, als die Frage nach der Zustimmung zur neuen Lizenz kam. Gruss Walter p.s. Mein PD-Häkchen werde ich dann löschen. - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Neue-Regeln-im-OSMI-ODbL-View-tp7128618p7129935.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] Vulkan
hi, im Forum gibt es hier was Aktuelles für Bergrücken, Grate. http://forum.openstreetmap.org/viewtopic.php?id=14865 Damit könnte man doch auch den Kraterand erfassen. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Vulkan-tp7129788p7129903.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] Neue Regeln im OSMI-ODbL-View
Am 20:59, schrieb Markus: Hallo Frederik, herzlichen Dank für Dein Engagement für eine verlustarme Lizenzumstellung! Mir macht der verbleibende Datenverlust und/oder die damit verbundene Neuerfassung immer noch Sorgen. Ich weiss dass viele OSMer der ODbL deshalb nicht zugestimmt haben, weil PD/CC0 die Lizenz ihrer Wahl ist. Es gab im September 476 mapper mit identifizierbaren PD Erklärungen auf ihrer wiki Seite. Ich hab nochmals mein Auswerteskript mit aktuellen Lizenzdaten laufen lassen (da es keine 1 zu 1 Beziehung zwischen Benutzerkonto und wiki-Seite gibt, sind ~100 nicht zuweisbar) Total found PD mappers: 375 CT accepted: 315 CT refused: 4 CT unknown: 56 Schlussfolgerung: eine überwiegende Mehrheit der Mapper, die ihre Daten als PD/CC0 erklärt haben, haben (logischerweise und auch vernünftig) auch kein Problem damit die CTs anzunehmen. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vulkan
2011/12/27 Markus : > Wie bezeichnet man den Krater-Rand? soweit ich weiss gibt es hierzu bisher keinen Vorschlag. Weder für den Krater noch für den Rand (es gibt nur den Tag für einen "Vulkan"). > Wie wird das dann von Mapnik gerendert? rotes Dreieck. falls vorhanden mit Namen und Höhenangabe, s.z.B. hier (reinzoomen): http://www.openstreetmap.org/?lat=40.8216&lon=14.4271&zoom=13&layers=M > natural=volcano > kommt dann als Punkt ins Innere? ja, bisher gibt es fast nur Vulkane, die als Nodes gemappt sind. Die beste Position für den Node ist entweder die Mitte (auch wenn das nicht der höchsten Erhebung entspricht) oder evtl. besser (wie Du in der Frage suggerierst) der höchste Punkt des Kraterrands. > Und die Höhe bezeichnet den Kraterrand? > oder den sichtbaren Kratergrund? Höhe (tag ele) bezeichnet im allgemeinen die Höhe des Bodens am gemappten Punkt. Wenn nun dieser Punkt gleichzeitig mit natural=vulcano getaggt ist, hielte ich es für die wahrscheinlichste Interpretation, dass es dort die höchste Höhe des gemappten Features ist (also der höchste Punkt des Vulkans). Das kommt aber auch darauf an, ob es z.B. am Kraterrand weitere mit Höhe getaggter Nodes gibt, und welche Höhen diese haben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Hallo Frederik, herzlichen Dank für Dein Engagement für eine verlustarme Lizenzumstellung! Mir macht der verbleibende Datenverlust und/oder die damit verbundene Neuerfassung immer noch Sorgen. Ich weiss dass viele OSMer der ODbL deshalb nicht zugestimmt haben, weil PD/CC0 die Lizenz ihrer Wahl ist. Deshalb habe ich die OSMF nochmal angeschrieben mit der Bitte, doch noch eine Anfrage an alle OSMer zu machen, ob sie denn - wenn sie der ODbL nicht zustimmen wollen - vielleicht PD/CC0 zustimmen möchten. Denn dann hätte man diese OSMer ebenfalls mit im Boot. (und man hätte, falls irgendwann dann doch noch mal ein Wechsel zu PD/CC= geplant wird, gleich valide Zahlen über unproblematische Daten) Leider habe ich darauf nicht mal eine Antwort bekommen. Eine weitere Idee wäre, die OSMer zu fragen, ob sie - wenn sie der ODbL nicht zustimmen wollen - ob sie damit den anderen OSMern auch explizit verbieten, ihre Änderungen weiter zu benutzen? Ich vermute nämlich, vielen ist das völlig egal, oder zumindest so egal, dass sie kein explizites Verbot aussprechen werden. Und das wäre dann doch ganz im Sinne einer "harmlos-Analyse"... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Hallo Frederik, eine Systematik ist mir eingefallen, ändert aber nichts an deinem View, da es Relationen betrifft. * Bei Relationen die keine Fläche darstellen ist die Lage, Geometrie und Eigenschaften der Mitglieder unerheblich ** Bsp: Routenrelation: Ob der Weg gerade ist oder eine S-Kurve macht ist für die Zugehörigkeit des Weges zu dieser Relation unerheblich * Wird ein Weg, der einer Relation angehört nur gesplittet bzw. zwei Wege, die beide einer Relation angehören miteinander verbunden, so ist diese Änderung auch trivial. Weiterhin habe ich noch eine Frage zu deiner Systematik beim Ändern nur eines Taggs. Ist da sichergestellt, dass ein bspw. wenn ein amenity=place_of_worship in ein amenity=arts_centre geändert wird, würde ich dem schon die Trivialität absprechen. Viele Grüße, Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vulkan
Wie bezeichnet man den Krater-Rand? Wie wird das dann von Mapnik gerendert? natural=volcano kommt dann als Punkt ins Innere? Und die Höhe bezeichnet den Kraterrand? oder den sichtbaren Kratergrund? Hier der englische Wikitext: http://wiki.openstreetmap.org/wiki/Tag:natural=volcano Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODbL: "Tainted" Tags in eigenen Namespace schieben statt Daten löschen?
Hallo, On 12/27/11 09:21, Tom wrote: zu dem Thema ist schon so viel gepostet worden, dass ich gar keinen Überblick habe, ob sich schon jemand mit speziellen "Nur-Lese" Namespaces für "tainted" Tags beschäftigt hat. In diesen speziellen Namespace würden am 1.4. alle Tags geschoben werden, die von Nicht-Zustimmern stammen. Die Knoten oder Wege selbst würden dabei allerdings nicht gelöscht werden und bleiben damit zumindest im Editor sichtbar! Eine ODbL-konforme Karte würde dagegen in etwa so die CLEANMAP heute aussehen. Ich glaube, dass es nicht moeglich sein wird, eine "gemischte" Datenbank mit CC-BY-SA und ODbL-Elementen zu veroeffentlichen, da beide Lizenzen gern die einzige sein wollen. Und das Bereitstellen eines API-Aufrufs, mit dem man einen gemischten Datensatz in den Editor laden kann, ist ja bereits "veroeffentlichen". Also ich persoenlich halte auch gar nichts von diesem Festklammern an alten Daten. Ich werde in meinem Bereich darauf hinarbeiten, dass bis April keine CC-BY-SA-Daten mehr da sind. Dann habe ich einen graduellen Uebergang und keine grosse Ueberraschung am 1.4. oder wann auch immer (und die LWG hat keine Arbeit, weil sie in meinem Bereich nichts loeschen muessen). Dass ich dabei eventuell einige CC-BY-SA-Daten ohne Ersatz entfernen muss, nehme ich in Kauf. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Regeln im OSMI-ODbL-View
Hi, On 12/27/11 07:34, Bernd Wurst wrote: Nein, ich habe "gelb" zwar als "eventuell problematisch" verstanden, was es aber nicht aussagt. Ich fände es für den einzelnen Mapper besser wenn die genannten Fälle überhaupt nicht mehr gesondert behandelt würden, aber aus Gründen der Nachvollziehbarkeit macht es bei genauerem Überlegen durchaus Sinn. Ja, das war so ein bisschen mein Gedanke dabei. Eine ganz primitive "problematisch"-Analyse wuerde ja so aussehen: "Alles, bei dem der Username eines Ablehners in der History vorkommt, ist problematisch". Ich habe dem eine "harmlos"-Analyse draufgesetzt und erkenne nun einige Faelle als "harmlos"; das will ich dabei so verstanden haben: "An diesem Objekt hat ein Ablehner gearbeitet; ich denke nicht, dass wir seine Aenderung rueckgaengig machen muessen; selbst wenn wir es aber muessten, waere der Effekt davon vernachlaessigbar." - Daher sind bei mir auch Node-Verschiebungen unterhalb 1 Meter "harmlos". Zugleich bin ich dieser "alles gelb markieren, bei dem ich eine Entscheidung getroffen habe"-Regel nicht 100% treu, weil ich die im letzten Posting erwaehnten Nodes, die von einem Ablehner erzeugt und spaeter verschoben wurden, nun gar nicht mehr erfasse (anstatt gelb). Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie bringe ich das Programmm ogr2osm zum Laufen?
> ich versuche, das Programm ogr2osm zum Laufen zu bringen: > http://wiki.openstreetmap.org/wiki/Ogr2osm > Laut Beschreibung braucht es das "ogr module" aus der gdal-Bibliothek. > Bisher habe ich Python gedownloaded und in ein Verzeichnis "Python27" > entpackt. Hm, wenn ich noch recht erinnere, läßt sich das alles ganz gut über die Shell von osgeo4w abdecken. Zumindest verwende ich ogr2osm damit. Hier die Seite dazu: http://trac.osgeo.org/osgeo4w/ > In dieses Verzeichnis habe ich von dieser Seite > http://svn.openstreetmap.org/applications/utils/import/ogr2osm/ > ogr2osm.py und SimpleXMLWriter.py sowie das zu konvertierende > "Gemarkungen.shp" File kopiert, das im 3. Gauß-Krüger Meridianstreifen > gelagert ist. Das passt soweit, ogr2osm brauchst Du auch bei osgeo4w noch extra. > Was muss ich mit dem "ogr module" machen, sodenn ich es habe - einfach > auch in das Verzeichnis "Python27" hineinkopieren? Hm, python-Erweiterungen kommen normalerweise woanders hin. Da ich aber nich am Rechner bin, kann ich gerade nicht nachsehen. Osgeo4w übernimmt das aber für dich. > Um das Ganze zu starten. müsste ich nach meinen Ermittlungen Folgendes > in die Windows Console eingeben: > E:\Programme\Python27\python E:\Programme\Python27\ogr2osm.py > E:\Programme\Python27\Gemarkungen.shp -e 31467 Bei osgeo4w ist es die zugehörige Konsole. Ich wechsle immer in das Verzeichnis mit dem shapefile. Dann ist der Aufruf Python ogr2osm.py shapefile.shp Sofern das Bezugssystem im Shapefile steht, erkennt das ogr2osm selbst - am besten einfach ausprobieren. Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODbL: "Tainted" Tags in eigenen Namespace schieben statt Daten löschen?
Moin, Am 27.12.2011 09:21, schrieb Tom: In diesen speziellen Namespace würden am 1.4. alle Tags geschoben werden, die von Nicht-Zustimmern stammen. Die Knoten oder Wege selbst würden dabei allerdings nicht gelöscht werden und bleiben damit zumindest im Editor sichtbar! Eine ODbL-konforme Karte würde dagegen in etwa so die CLEANMAP heute aussehen. Wozu? Was versprichst Du Dir davon? Diese Daten/Informationen dürfen doch weder von Mappern noch von ODbL-Nutzern verwendet werden. Abgesehen davon gilt das ja nicht nur für die Tags sondern - je nach Auslegung - eben auch für die Positions-Fakten. Und für das gezielte Überarbeiten / Mappen von "way ohne tags" oder "way ohne namen" etc. gibt es bereits andere Hilfsmittel. just my 0.02 cents... dito. Beim Stopfen einer Rechtslücke tut man sich keinen Gefallen, wenn man den Faden woanders herauszieht ... Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ODbL: "Tainted" Tags in eigenen Namespace schieben statt Daten löschen?
Moin, zu dem Thema ist schon so viel gepostet worden, dass ich gar keinen Überblick habe, ob sich schon jemand mit speziellen "Nur-Lese" Namespaces für "tainted" Tags beschäftigt hat. In diesen speziellen Namespace würden am 1.4. alle Tags geschoben werden, die von Nicht-Zustimmern stammen. Die Knoten oder Wege selbst würden dabei allerdings nicht gelöscht werden und bleiben damit zumindest im Editor sichtbar! Eine ODbL-konforme Karte würde dagegen in etwa so die CLEANMAP heute aussehen. Weiterhin können in diesem Namespace ausschließlich Tags gelöscht werden, Korrekturen oder Hinzufügen neuer Tags wäre per API nicht möglich. Anderenfalls könnte ein Zustimmer nachträglich Daten erzeugen, die nicht der ODbL entsprechen. Gleiches gilt bei Splits von Wegen: hier müssten die Tags mit speziellem Namespace vor dem Hochladen bearbeitet werden. ODbL konforme Extrakte könnten einfach durch Herausfiltern des speziellen Namespaces erzeugt werden - falls unbedingt nötig könnte man auch eine Legacy CC-BY-SA Karte bereitstellen, die den speziellen Namespace noch berücksichtigt. Vorher: highway=residential name=... Nachher: odbl_tainted:highway=residential odbl_tainted:name=... just my 0.02 cents... Gruß, Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
