Re: [Talk-de] Garmin eTrex HCx und große Speicherkart en
Am 18.07.2010 08:24, schrieb Benjamin Lebsanft: Also ich habe das bei meinem alten Vista ausprobiert, Firmware 3.20 drauf, Ladezeit endlos lang, wieder 3.0 drauf, schnelle Ladezeit. Ich habe den Eindruck, d.h. Benchmarks habe ich nicht gemacht, als ob die 3.20 dafür mit einer fixeren Kartendarstellung aufwartet, insbesondere beim Herauszoomen. So als ob da ein zusätzlicher Cache im Arbeitsspeicher (o.Ä.) vorbefüllt worden wäre. Muss ich aber erst mit meinem neuen testen, damit ich das bestätigen kann. Dann aber BITTE mit weniger TOFO, o.k.? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Hallo,
Am 18.07.2010 um 00:43 schrieb Frederik Ramm:
> Das ist aber nicht das einzige Problem mit der CC-BY-SA: Es ist nicht nur so,
> dass Leute die Daten nutzen koennen, ohne sich an die Lizenz zu halten, es
> ist umgekehrt auch so, dass die, die sich an die Lizenz halten moechten,
> trotzdem nie sicher sind, ob ihnen nicht doch mal jemand ans Bein pinkelt
> (Stichwort "Namen aller Autoren nennen" und so).
>
> (..) Es stimmt zwar, dass unsere Daten dadurch nicht weniger frei werden,
> wenn irgendjemand sie sich krallt und verwendet, aber es gibt eine gewisse
> Gefahr, dass das Projekt uebernommen werden koennte - stell Dir vor, eine
> grosse Firma schnappt sich die Daten und bietet viel coolere Editoren und
> besser funktionierende Kartenseiten und so weiter an, und wirbt unsere
> Community ab ("macht doch lieber hier bei FreeStreetMap mit, da funktioniert
> alles besser und wir haben bezahlte Mitarbeiter, die Vandalen rauswerfen und
> Newbies einweisen... ach ja, alle Daten, die ihr beitragt, gehoeren
> natuerlich uns, aber ihr kriegt ein kostenloses Mauspad, wenn ihr mehr als
> 1000 Edits habt, ist das nicht toll?"). Das ist das Haupt-Argument der
> PD-Kritiker.
Gut. Diese Gefahren leuchten mir ein.
Wobei ich der Überzeugung bin sie sind längst nicht so dramatisch wie sie sich
zunächst anhören.
Denn was ist es denn was unser Projekt am Leben hält? Ist es nicht eine
Kombination aus freiheitlichem Geist (Selbstbestimmung), selbstlosem Einsatz
für eine höhere Sache (sinnstiftendes ehrenamtliches Engagement) und dem
praktischen Nutzen, den jeder selbst aus unserem Werk zieht?
Sollte nur einer dieser Faktoren entfallen, oder besser gesagt sollte es nur
danach riechen, ist die Community weg, und zwar von heute auf morgen. Diesen
Effekt konnte man bspw. bei dem OpenSource-Projekt Mambo beobachten. Mambo
wurde seinerzeit teilkommerzialisiert und - schwups - wandte sich ein Großteil
der Entwickler laut schimpfend ab - nur um sich im nächsten Moment wieder
zusammenzuschließen. Seitdem gibt es bekanntlich Joomla.
Am 17.07.2010 um 23:43 schrieb Heiko Jacobs:
> Die neue Lizenz ist an sich nicht schlecht.
> Und ist nach Meinung einiger tatsächlich angeraten.
> Sie haben vemrutlich Recht, ich bin aber kein Jurist o.ä.
>
> Das, was kein Mensch braucht, sind nur die Kollateralschäden
> durch Datenverluste für das aktive Projekt.
> Solange diese (und NUR solange diese) im Raum stehen, bevorzuge
> ich es, bei CC zu bleiben. Sobald wir ohne Kollateralschäden
> hinkommen, fix rüber zur ODBL o.ä.
Ich bin exakt dieser Meinung. Drohende Kollateralschäden durch Datenverluste
wiegen für mich bei weitem schwerer. Das würde IMO die aktiven Mapper vor Ort
demoralisieren mit der Folge, dass sich viele enttäuscht für immer
verabschieden. Mach mal jemandem, der nur mappt und der sich sonst keine
Gedanken macht, begreiflich, dass seine ehrenamtliche(!) Arbeit der letzten
anderthalb Jahre umsonst war, weil irgendwelche Juristen herausgefunden haben
das Lizenzierungsmodell sei nicht wasserdicht.
Und noch was:
Vor dem Hintergrund der drohenden Umstellung müsste man (als Befürworter des
neuen Modells) beim Mappen jetzt schon anders vorgehen. Alle Objekte die man
selber anfasst löschen und durch eigene ersetzen.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18. Juli 2010 08:45 schrieb Markus : > Ist es ok, mit Relationen eine relationale DB-Struktur zu simulieren? > Also Objekte zu Klassen zusammenzufassen? > > Beispielsweise alle Tankstellen? > Und in weiteren Relationen die Netze von BP, Esso, etc? > Oder je alle Autogas und Strom-Tankstelle? > Das sind Dinge, die ich im API über amenity=fuel, operator=Aral suchen kann. Wozu noch eine Relation? Die wird nie vollständig sein, hat extra Pflegeaufwand und keinen Mehrwert. Grüße, jens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
On 07/18/2010 09:35 AM, Jens Frank wrote: > Am 18. Juli 2010 08:45 schrieb Markus : > >> Ist es ok, mit Relationen eine relationale DB-Struktur zu >> simulieren? Also Objekte zu Klassen zusammenzufassen? >> >> Beispielsweise alle Tankstellen? Und in weiteren Relationen die >> Netze von BP, Esso, etc? Oder je alle Autogas und >> Strom-Tankstelle? >> > > Das sind Dinge, die ich im API über amenity=fuel, operator=Aral > suchen kann. Wozu noch eine Relation? Die wird nie vollständig sein, > hat extra Pflegeaufwand und keinen Mehrwert. Siehe http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Also Relations sind keine Sammlungen von Daten mit den selben Eigenschaften. Dann könnte man ja auch alle secondary Straßen in Deutschland in einer Relation zusammen fassen etc. Mehrwert ist wie Jens sagt gleich null. Grüße Tilmann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Suche Audio-Karten-Tester fuer mein Masterprojekt
Hallo, im Laufe des letzten Jahres habe ich von den 'OSM users Germany' einige wertvolle Tipps bekommen, fuer die ich mich noch einmal sehr herzlich bedanken moechte. Nun ist mein Uni-projekt fertig und ich suche Leute, die meine Audio-Karten testen wollen. Wer einfach so gucken moechte, wie sich OSM-Daten anhoeren koennen, ist ebenfalls herzlich dazu eingeladen. Viele Gruesse, Esther -- Dear all As part of my Master's project at Queen Mary, University of London, I'm looking for participants to take part in a game centred on wayfinding challenges in urban audio maps. The game should take no longer than 20 minutes to complete and there will be a prize draw with a total of ten £10 Amazon vouchers (or the international equivalent) to be won. To play the game, please download the installer from https://sourceforge.net/projects/team/. It should install without problems on Windows XP, Windows Vista and Windows 7 (32-bit and 64-bit). After you have installed and started TEAM, press Ctrl+Enter to play. For a screenshot and further information, see the project website, http://team.sourceforge.net. The game has been designed with accessibility in mind, so blind and partially sighted participants are very much encouraged to take part. I'd be delighted if you'd be happy to play the game. If you have any questions about the game or the research on which it is based, please don't hesitate to contact me. With kind regards, Esther [ec09500 at eecs dot qmul dot ac dot uk] --- http://forum.openstreetmap.org/viewtopic.php?pid=90441#p90441 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Audio-Karten-Tester fuer mein Masterprojekt
Hallo, Am Sonntag 18 Juli 2010 schrieb Esther Loeliger: > It should install without > problems on Windows XP, Windows Vista and Windows 7 (32-bit and 64-bit). Wie sieht es denn mit Nicht-MS-Windows-Betriebssystemen aus? Grüße, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 02:21, schrieb Tirkon: > Zwei Lösungsvorschläge: > > Vorschlag 1: Bei jeder Umkehr der Straßenrichtung, sei es von Hand > oder bei Vereinigungen gegenläufiger Straßen dreht der Editor > automatisch auf allen richtungsgeänderten ways auch alle forwards und > backwards in betroffenen Tags und Relationsabschnitten um. Moinsen, dies macht JOSM bereits. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Hallo Jens, hallo Tilmann, Das sind Dinge, die ich im API über amenity=fuel, operator=Aral suchen kann. Siehe http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Also Relations sind keine Sammlungen von Daten mit den selben Eigenschaften. Mehrwert ist wie Jens sagt gleich null. Wenn das einhellige Meinung ist, dann sollte man das hier: http://wiki.openstreetmap.org/wiki/DE:Relations und hier: http://wiki.openstreetmap.org/wiki/Relations in einem entsprechenden Abschnitt deutlich dokumentieren. Hier scheint die Meinung anders zu sein: http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Hallo, Tirkon wrote: Wenn eine Funktion so zerstörerisch sein kann und sämtlichen sorgfältig erstellten Richtungstaggings und -Relationen quasi den Arsch unter den Füßen wegzieht Du meinst "den Boden unter den Fuessen wegzieht"? JOSM ist ja mittlerweile so schlau und empfiehlt beim Aendern der Richtung eines Ways, auch die entsprechenden richtungsabhaengigen Tags umzudrehen. Persoenlich finde ich, dass richtungsabhaengige Tags sowieso "asking for trouble" sind, insbesondere alles, was irgendwie "left" und "right" enthaelt. Auch dem "backward" und "forward" als Rollen in Relationen stehe ich eher kritisch gegenueber, ich finde, dadurch wird eine unnoetig hohe Komlpexitaet eingefuehrt. Mir waere es lieber, *wenn* man eine solche Unterscheidung unbedingt modellieren will, dass man dann fuer jede Richtung eine Relation anlegt, aehnlich bei beim OePNV. Schlimmer noch: Was ist, wenn nach einer versehentlichen Änderung jemand Anderes richtungsabhängige Dinge taggt. Dann sind die einen richtig herum und die anderen falsch. Deswegen sollten richtungsabhaengige Tags auf ein absolutes Minimum reduziert werden. "oneway" ist ok, das ist auch in der Karte durch einen Pfeil sichtbar, da passieren nicht so viele versehentliche Fehler. Bei allem anderen sollte man mal gruendlich nachdenken, ob es nicht andere Moeglichkeiten gibt, als sich an der Richtung des Ways zu orientieren. Vorschlag 1: Bei jeder Umkehr der Straßenrichtung, sei es von Hand oder bei Vereinigungen gegenläufiger Straßen dreht der Editor automatisch auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Wie gesagt, mit Ausnahme der forwards und backwards (glaub ich) tut JOSM das ja bereits. Wobei nicht in allen Edit-Szenarien sichergestellt ist, dass JOSM ueberhaupt Kenntnis von einer Relation hat, in der der Way enthalten ist. Vorschlag 2: Die Richtung der Straße könnte bei neuen way-Objekten - zweckmässigerweise zwischen zwei Knotenpunkten ohne Richtungsänderung - entweder vom Editor oder der Datenbank automatisch festgelegt werden und wäre dann für niemanden mehr umkehrbar. Bei einer Vereinigung von zwei gegenläufigen Straßen durch Auflösung einmes Knotenpunktes drehen Editor oder Datenbank (je nachdem, wer oben für diese Aufgabe zuständig war) auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Die Datenbank waere das bestimmt nicht, denn sie kuemmert sich nicht um den Inhalt von Tags. Automatisch festgelegte Way-Richtungen finde ich nicht so gut, weil das dazu fuehren wuerde, dass wir deutlich mehr "oneway=-1" in der Datenbank haetten, und ich bin eigentlich ganz froh, dass das derzeit die absolute Ausnahme ist. Welcher von beiden wäre zu bevorzugen? Keiner. Anstatt ein immer engeres Korsett zu bauen, innerhalb dessen die Editoren - von denen es viele gibt, und von denen nie alle sich einig sein werden - Benutzern Vorschriften machen, sollte man sich Methoden fuer das Tagging ueberlegen, die weniger fragil sind. Worueber man allerdings fuer eine Uebergangszeit mal nachdenken koennte, ist, die Way-Umdreh-Funktion in JOSM etwas mehr zu verstecken. Vielleicht in einem Untermenue "Advanced..." oder sowas. Damit man nicht so leicht versehentlich draufklickt ;) 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] Postleitzahlen-Import
Am 17. Juli 2010 20:42 schrieb Markus : >>> http://www.openstreetmap.org/browse/relation/907244 >>> http://arnulf.us/PLZ >> >> Da gab es aber bisher keinerlei Anstalten eines flächendenckenden Import >> für >> diese Daten, oder? > > Doch, Frederik ist bereits dran. Wurden/Werden die Grenzen dazu noch einmal neu Umprojeziert? Bisher sehe ich durchweg einen Nordost-Drift der Daten. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgehende Mittellinie
Am 18.07.2010 um 01:08 schrieb Tirkon: > Seufz! Irgendwie geht jetzt Deine Interpretationsphantasie mit Dir > durch. Ich habe weder versucht zu belegen, dass das eine Kreuzung ist, > noch dass es keine Kreuzung ist, weil es mir schnurzpiepegal ist. Das habe ich doch auch, mein bester. Wenn ich nicht so geduldig wäre Was versuchst Du überhaupt zu sagen? Deine Zeichnungen belegen, dass man natürlich den way an den Stellen, wo sich die ways treffen direkt so taggen kann. Wieso glaubst Du das denn nicht, dass das geht - Du legst ja auch fest dass der way ein residental ist usw, das geht auch exakt bis dahin wo der Node ist. Es geht genauso exakt, wie die durchgezogene Mitellinie _tatsächlich_ verläuft. Und was Renderer daraus machen, ist nicht das Problem des tagging. Die "müssen" halt für Kreuzungen einen eigenen Lupe/ Zoomlevel einführen, wo das dann gescheit gezeichnet wird. Das wäre doch ein echter Fortschritt für die Renderer. Doch deswegen unterlasse ich doch das taggen nicht! > Darum widerspreche Dir selbst weiterhin oder auch nicht und diskutiere > das mit Dir selbst aus. Und frage mich nie mehr, warum das keine > Kreuzung ist, wenn ich es als Zitat von Dir wiederhole. ;-) Deine Argumentation war, dass es genau an solchen Stellen nicht ginge und Du hast mir solche Kreuzungen sogar aufgezeichnet. Also wo ist Dein Problem. Renderer sind Dein Problem? Dann verbessere die Renderer. Mir ist es auch wurscht, wie Du es nennst, Kreuzung, Einmüdnung, T-Kreuzung, Y-Kreuzung, Abbiegende Vorfahrtstraße, etc.. Das kann alles einwandfrei getaggt werden. Ich sehe da keine Probleme. Du kannst in JOSM sogar metergenau taggen, wenn Du möchtest. Und wenn Die Mittellinie auf zwei Metern bei der Einmündung eben nicht durchgezogen ist, dann machst Du einen Knoten links und einen rechts vom Knoten der Einmündung und tagge dazwischen den "no"-Wert. Wo ist Dein Problem? Jetzt sag nicht der Rednerer! :-) >> Wie gesagt, es gibt keine durchgezogenen Mittellinien in Kreuzungen, damit >> ist Deine Argumentation, dass es über eine Relation abgebildet werden muss >> (wegen der Kreuzungen/Einmündungen/etc. wäre es nötig meintest Du) hinfällig. > Wieso das? Weil die durchgezogene Mittellinie dem Querverkehr verbieten würde weiterzufahren. Deshalb gibt es keine durchgezogenen Mittellinien _in_ Kreuzungen mit vier Straßenanteilen, also die durchgezogene Mittellinie _kreuzt_ niemals eine andere Straße. Das gibt es auch in Parkhäusern nicht. Sonst darf der Querverkehr nicht weiterfahren. Deine Zeichnungs-Fälle sind Einmündungen, bei denen sich die Mittellinie natürlich auch nirgends mit einer anderen Straße kreuzt (nur baulich gesehen, nicht von der Namensgegbung her, die hier völlig unrelevant ist!). Die durchgezogene Mittellinie kann in einer Straße, die einen Bogen macht, natürlich durch diesen Bogen hindurchlaufen, ohne Unterbrechung, klar. Die Straße, die in dieser Kurve einmündet kann auch eine durchgezogene Mittellinie haben. Aber niemals ragt diese bis zum gemeinsamen Mittelpunkt hinein! Sondern sie hört vor der eigentlichen Einmündung (baulich gesehen) auf, weil sie sonst eine Fahrspur der kurvenförmigen Straße kreuzen würde und diesem Verkehr das Weiterfahren verbieten würde. Doch auch das ist einwandfrei taggbar. Wo ist Dein Problem? Die Straßenbreite, die vorgibt, wo die durchgezogene Linie der einmündeneden Straße enden müsste? Schreite sie ab, schätze sie. Es ist der Abstand vom Mittelpunkt der sich treffenden Straßen bis zum Ende der durchgezogenen Linie der einmündenden Strtaße. Aber selbst wenn Du nur eine kleine Unterbrechung zeichen würdest, wären die Konsequenzen für Anwendungssoftware die gleichen. Wichtig ist, dass eine Unterbrechung vorhanden ist, sonst darf man an der Stelle nicht weiterfahren. Wie breit die Unterbrechung ist ist Abiege-Regel-Technisch unerheblich. Es könnte nur wichtig werden, wenn mal Straßenbreiten-Tags von Renderern umgesetzt werden. Doch dann lässt sich so etwas auch schön durch Verschieben des Knotens, an dem die durchgezogene Mittellinie aufhört, wieder korrigieren. Wird schon. > Sind Parkhäuser kein Beispiel? Und wer sagt, dass es sie > außerhalb nicht gibt? Mir fällt bloß momentan kein konkretes Beispiel > ein, an dem die durchgezogene Mittellinie außerhalb des Parkhauses von > drei Seiten kommt aber nur für eine Relation durchgeht. Ansonsten gibt > es durchgezogene Mittellinien an Abzweigungen zuhauf und ich habe > schon in meinem Ursprungsposting die Hauseinfahrten genannt. OK - und was hat das jetzt für eine Konsequenz für Dich/mich? Dann tagge die durchgezogenen Mitellinien so, wie sie verlaufen und gut ists. Wieso kann Deiner Meinung nach die durchgezogene Mittellinie dort nicht getaggt werden, bzw. warum sollte das ein Beispiel dafür sein, dass es kein sinnvolles Tagging wäre? Jede Anwendung (Routingsoftware genauso wie Renderer) müssen sie nur so wie in der Wirklichkeit richtig interpretieren. Die Rdnerer mögen das in Z
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Am 18.07.2010 um 03:06 schrieb Tirkon: > steffterra wrote: > >> Wenn alle Straßen in Orten, in den denen es Hausnummern gibt, in Relationen >> gefasst wären, dann könnten wir OSM für Neuuser dicht machen und wären >> ständig am nachreparieren der Hausnummer-Straßen-Relationen. Weil - selbst >> wenn man nichts mit Hausnummern am Hut hat und auch gar nichts an der >> Relation ändern will - und sei es nur dass sich der Verlauf eines Radweges >> geändert hat, dann ist die Relation futsch und ein Router findet keine >> einzige Hausnummer dieser Relation mehr, wenn der (Neu)User die Relation >> nicht richtig beachtet hat. > > Es bleibt ohne Relation besser menschenlesbar. +1 > Zu all den genannten Argumenten gegen eine Relation hier noch ein > weiteres, das sich auf der Insel Baltrum auftut: Dort werden > Hausnummern in der Reihenfolge der Errichtung der Häuser vergeben. Bei > jedem Bauantrag wird also eine neue Nummer vom Stapel genommen. Damit > hat das erste erbaute Haus auf der Insel die Hausnummer 1. Nummer 11 > könnte durchaus neben Nummer 111 stehen. Die Hausnummer hat dort also > keine geografischen Bezug mehr. Die explizite Adressnennung am Haus > bewährt sich auch dort als die beste Methode. +1 Aber, ohne Dir/mir selbst in den Rücken fallen zu wollen: Hausnummern-Relationen _können_ an _manchen Stellen_ sinnvoller sein, als das Einzeltagging. Aber eben auch umgekehrt, wie man an Tirkons Beispiel Baltrum sehen kann. Sie sind aber defintiv nicht das Allerheilmittel, als das die Informatiker unter uns sie immer (vlt. unbewusst?) hinstellen möchten. Noch ein Frage zu Baltrum Tirkon, Die "durcheinander gewürfelten" Hausnummern von Häusern nebeneinander einer Straße gehören aber schon zur gleichen Straße? Und die Anwohner haben schon die gleiche Adresse, mal abgesehen von der jeweiligen Hausnummer? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postleitzahlen-Import
Hallo, André Riedel wrote: Wurden/Werden die Grenzen dazu noch einmal neu Umprojeziert? Bisher sehe ich durchweg einen Nordost-Drift der Daten. Vorschlaege fuer eine Reprojektion werden dankend entgegengenommen. Ich habe alles denkbare probiert, kam aber zu keinem brauchbaren Ergebnis. Der "Drift" ist auch nicht in ganz Deutschland gleich, sonst koennte man das ja leicht reparieren. Ist aber m.E. nicht so schlimm, weil der Import eh furchtbare Handarbeit ist, da ist eine kleine Verschiebung der Ways in JOSM noch das geringste Uebel. 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
Re: [Talk-de] Suche Audio-Karten-Tester fuer mein Masterprojekt
Leider gibt es nur eine Windows Version. Die meisten Menschen mit eingeschraenktem Sehsinn sind Windows-Benutzer, und die Betriebssystem-eigene Stimme von Windows (insbesondere Win7, Microsoft Anna) klingt wesentlich natuerlicher als beispielsweise eSpeak (grandioses Projekt, nicht zuletzt wg des Sprachen-Supports!), ist damit weniger gewoehnungsbeduerftig fuer Menschen ohne tts-Erfahrung. Beides (und natuerlich der zeitliche Rahmen meines 1-Jahres MSc) hat dazu gefuehrt, dass ich mich fuer eine Windows-Version entschieden habe. On 18/07/2010 09:26, Carsten Gerlach wrote: Hallo, Am Sonntag 18 Juli 2010 schrieb Esther Loeliger: It should install without problems on Windows XP, Windows Vista and Windows 7 (32-bit and 64-bit). Wie sieht es denn mit Nicht-MS-Windows-Betriebssystemen aus? Grüße, Carsten ___ 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] Suche Audio-Karten-Tester fuer mein Masterprojekt
On 18.07.2010 10:26, Carsten Gerlach wrote: > Wie sieht es denn mit Nicht-MS-Windows-Betriebssystemen aus? Es läuft zwar mittels wine problemlos, ohne tts-feature ist's aber nur bedingt sinnvoll. Grüße, yzemaze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Björn-Steiger-Stiftung - Status Rüc kbau und offen für eine Zusammenarbeit
Am 16.07.2010 18:53, schrieb M∡rtin Koppenhoefer: Am 16. Juli 2010 13:22 schrieb Jan Tappenbeck: @michael: würdest du von einem import absehen ??? Glückwunsch Jan, ich freue mich, dass die uns Ihre Daten schenken wollen. Man sollte allerdings das Zeugs nicht alles blind reinimportieren sondern einen Abgleich mit unseren gegenwärtigen Daten machen, und evlt. auch mal Stichproben, wie genau deren Daten sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de hi ! scheinbar ist es nicht ganz klar rübergekommen - man steht dem positiv gegenüber und man muss den kontakt noch vertiefen. jan .-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18.07.2010 um 10:38 schrieb Markus: > Hallo Jens, hallo Tilmann, > >>> Das sind Dinge, die ich im API über amenity=fuel, operator=Aral >>> suchen kann. >> >> Siehe >> http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories >> >> Also Relations sind keine Sammlungen von Daten mit den selben >> Eigenschaften. Mehrwert ist wie Jens sagt gleich null. > > Wenn das einhellige Meinung ist, > dann sollte man das hier: > http://wiki.openstreetmap.org/wiki/DE:Relations > und hier: > http://wiki.openstreetmap.org/wiki/Relations > in einem entsprechenden Abschnitt deutlich dokumentieren. Auf diesen Seiten steht bereits der Hinweis auf http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Ich ergänze es eben noch um einen kleinen erklärenden Satz mit einem aktuellen Beispiel :-) auf DE und EN. doch die anderen Sprachen bekomme ich nicht hin ;-) > Hier scheint die Meinung anders zu sein: > http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations Deshalb ist es auch nur ein Vorschlag. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Björn-Steiger-Stiftung - Status Rüc kbau und offen für eine Zusammenarbeit
Am 17.07.2010 00:03, schrieb Walter Nordmann: hi, als ich anfang des jahres die rettungspunkte des saarlandes (offizielle spende) geladen habe, hab ich überprüft, ob sich in der nähe eines "neuen" rettungspunktes bereits ein alter befindet. die hab ich dann NICHT automatisch geladen sondern per hand überprüft. sowas ähnliches solltest du auch machen. gruss wambacher - Ich bin root, ich darf das. so sehe ich einen möglichen-importweg auch ! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Björn-Steiger-Stiftung - Status Rück bau und offen für eine Zusammenarbeit
Am 16.07.2010 18:23, schrieb Walter Nordmann: klasse, hatte nicht erwartet, dass die das so positiv sehen - und leider nicht selbst angerufen. danke walter - Ich bin root, ich darf das. Hi ! wie schon einmal geschrieben - vielleicht findet sich jemand aus dem Stuttgarter Raum der an mein Gespräch anschließt, denen mal etwas näheres über OSM erzählt, vielleicht auch unserer Bedenken, mögliche Wege .. Wenn es dann zu tiefergehenden Fragen kommt könnte man diese sicherlich diskuttieren. Wenn es um die technische Umsetzung geht würde ich mich dann auch wieder einklinken. Gruß jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Hallo! Am 18. Juli 2010 09:17 schrieb Christian Schmitt : > Hallo, > > Am 18.07.2010 um 00:43 schrieb Frederik Ramm: > [warum CC-by-SA nicht funktioniert] > > Gut. Diese Gefahren leuchten mir ein. > > Wobei ich der Überzeugung bin sie sind längst nicht so dramatisch wie sie > sich zunächst anhören. > > Denn was ist es denn was unser Projekt am Leben hält? Ist es nicht eine > Kombination aus freiheitlichem Geist (Selbstbestimmung), selbstlosem Einsatz > für eine höhere Sache (sinnstiftendes ehrenamtliches Engagement) und dem > praktischen Nutzen, den jeder selbst aus unserem Werk zieht? > [...] > > > Am 17.07.2010 um 23:43 schrieb Heiko Jacobs: > >> Die neue Lizenz ist an sich nicht schlecht. >> Und ist nach Meinung einiger tatsächlich angeraten. >> Sie haben vemrutlich Recht, ich bin aber kein Jurist o.ä. >> >> Das, was kein Mensch braucht, sind nur die Kollateralschäden >> durch Datenverluste für das aktive Projekt. >> Solange diese (und NUR solange diese) im Raum stehen, bevorzuge >> ich es, bei CC zu bleiben. Sobald wir ohne Kollateralschäden >> hinkommen, fix rüber zur ODBL o.ä. > > > Ich bin exakt dieser Meinung. Drohende Kollateralschäden durch Datenverluste > wiegen für mich bei weitem schwerer. Das würde IMO die aktiven Mapper vor Ort > demoralisieren mit der Folge, dass sich viele enttäuscht für immer > verabschieden. Mach mal jemandem, der nur mappt und der sich sonst keine > Gedanken macht, begreiflich, dass seine ehrenamtliche(!) Arbeit der letzten > anderthalb Jahre umsonst war, weil irgendwelche Juristen herausgefunden haben > das Lizenzierungsmodell sei nicht wasserdicht. > Dann mach mal dem glühenden by-SA Anhänger aus Hintertupfingen klar, dass die Feldwege die er gemappt hat, auf einem T-Shirt oder in einer I-Phone App ohne Quellenangabe verkauft werden können, weil die Lizenz nicht wasserdicht ist. Wenn der rausbekommt, dass es der Foundation schon lange klar war, dass so etwas passieren kann, man es aber wegen möglicher Kollateralschäden einfach ignoriert hat, dann ist der Schaden viel größer. Das klingt in meinen Ohren alles ein wenig nach Atomlobby: "Es gibt weltweit zwar kein sicheres Endlager und ein Super-GAU ist nie auszuschließen - diese Gefahren sind aber längst nicht so dramatisch wie sie sich zunächst anhören! Wenn es eines Tages eine 100% sichere und kostenlose Alternative gibt (also die Hölle zufriert und Schweine fliegen können), dann nichts wie rüber. Bis dahin müssen wir aber unsere Investitionen beschützen und billigen Stom anbieten. Bei einem Ausstieg gäbe es Kosten für uns und die Kunden, deshalb produzieren wir weiter munter Atommüll - es wird schon gutgehen!" Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 um 07:36 schrieb fx99: > In der OSM Darstellung müssen die Punkte in einem Weg eine Ordnung haben, > damit man weiß, wie sie zu verbinden sind. Warum? Eigentlich benötigt man eine Richtung nur da, wo man eine Richtung benötigt ;-) > Dabei gibt es bei einem nicht in > sich geschlossenen genau zwei Möglichkeiten: A-B-C-D oder D-C-B-A, was dann > als Richtung bezeichnet wird. Dort wo nötig, sicher sinnvoll, aber sonst? > In vielen Fällen ist die Richtung ohne jede Bedeutung, s.o. > in manchen Fällen > (z.B. Flüsse) wird eine sinnvolle Konvention festgelegt. > Soweit so gut. Was mich jetzt aber stört, ist, dass an eine oft willkürliche > Richtung entscheidenen Eigenschaften durch forward oder backward gekoppelt > werden. Dies führt dann zu den oben aufgezählten Problemen. Richtig. Es sollte Regeln geben, an denen man sich orientieren kann, in welche Richtung ein way gedreht sein muss, dass backward und forward richtig interpretiert werden können. Für den destination-Tag bin ich auch auf so ein Problem gestoßen und habe es so "gelöst", dass der way immer in Richtung der bedeutsameren (hierarchisch höher stehenden) Straßenart zeigen sollte. Also im Falle einer residental zu einer secondary hin. Vielleicht ist das ein allgemein möglicher Vorschlag? > Ich hielt es für wesentlich sinnvoller, diese Eigenschaften durch von der > Richtung des Weges unabhängige, absolut gültige Beschreibungen ergänzt > werden, wie z.B. Himmelsrichtung oder andere geographische Beschreibungen ( > von A nach B etc. ). s.o. ich denke an die Richtung hin zum hierarchisch höher wertigen highway-Klassifizierung. (aber nur, wenn der forward-backward-tag überhaupt genutzt wird!) Wenn zwei gleichwertige ways aufeinander stoßen, dann sollte die Richtung _aus_ der Richtung kommen, die weniger bedeutsam ist. (Z.B. wenn eine secondary aus einem Wohnviertel herausführt und auf eine secondary-Bundesstraße führt) Bei der Bundesstraße bin ich mir nicht sicher, ob es wieder relevant ist... > Damit wären auch die meisten Probleme der unkontrollierten Richtungsumkehr > verschwunden. Solange man diese Regeln, wie der way auszurichten ist, kennt udn diese beachtet. Aber so ist es ja immer in OSM. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 um 10:47 schrieb Frederik Ramm: >> Vorschlag 2: Die Richtung der Straße könnte bei neuen way-Objekten - >> zweckmässigerweise zwischen zwei Knotenpunkten ohne Richtungsänderung >> - entweder vom Editor oder der Datenbank automatisch festgelegt werden >> und wäre dann für niemanden mehr umkehrbar. Bei einer Vereinigung von >> zwei gegenläufigen Straßen durch Auflösung einmes Knotenpunktes drehen >> Editor oder Datenbank (je nachdem, wer oben für diese Aufgabe >> zuständig war) auf allen richtungsgeänderten ways auch alle forwards >> und backwards in betroffenen Tags und Relationsabschnitten um. > > Die Datenbank waere das bestimmt nicht, denn sie kuemmert sich nicht um den > Inhalt von Tags. Automatisch festgelegte Way-Richtungen finde ich nicht so > gut, weil das dazu fuehren wuerde, dass wir deutlich mehr "oneway=-1" in der > Datenbank haetten, und ich bin eigentlich ganz froh, dass das derzeit die > absolute Ausnahme ist. +1 >> Welcher von beiden wäre zu bevorzugen? > > Keiner. Anstatt ein immer engeres Korsett zu bauen, innerhalb dessen die > Editoren - von denen es viele gibt, und von denen nie alle sich einig sein > werden - Benutzern Vorschriften machen, sollte man sich Methoden fuer das > Tagging ueberlegen, die weniger fragil sind. Stimmt auch wieder. Doch hast Du einen Vorschlag, wie dieses Tagging aussehen könnte? Und jetzt kommt nicht wieder mit Relationen um das einfache Taggging zu ersetzen. Bitte. > Worueber man allerdings fuer eine Uebergangszeit mal nachdenken koennte, ist, > die Way-Umdreh-Funktion in JOSM etwas mehr zu verstecken. Vielleicht in einem > Untermenue "Advanced..." oder sowas. Damit man nicht so leicht versehentlich > draufklickt ;) +1 Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Hallo Stef(an?), http://wiki.openstreetmap.org/wiki/DE:Relations Auf diesen Seiten steht bereits der Hinweis auf http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Sollte jemand vielleicht noch auf deutsch übersetzen... Ich ergänze es eben noch um einen kleinen erklärenden Satz mit einem aktuellen Beispiel :-) Danke! habe es in "de" noch etwas umformuliert. die anderen Sprachen bekomme ich nicht hin ;-) Und das mit der "benutze die Suche in OSM" müsste man auch noch irgendwie sinnvoll verlinken (ich wüsste nämlich nicht wie man nach einer Kombination von zwei Schlüssel-/Wertepaaren sucht). Hier scheint die Meinung anders zu sein: http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations Deshalb ist es auch nur ein Vorschlag. Aber einer der Schule zu machen scheint... Und der im Widerspruch zu der Aussage unter "Definition" steht. Das verwirrt den Benutzer. Da müssten zumindest die Vor- und Nachteile der beiden Modelle verständlich beschrieben sein... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Hallo, Am 18.07.2010 um 11:34 schrieb Stefan Schwan: > Dann mach mal dem glühenden by-SA Anhänger aus Hintertupfingen klar, > dass die Feldwege die er gemappt hat, auf einem T-Shirt oder in einer > I-Phone App ohne Quellenangabe verkauft werden können, weil die Lizenz > nicht wasserdicht ist. Wenn der rausbekommt, dass es der Foundation > schon lange klar war, dass so etwas passieren kann, man es aber wegen > möglicher Kollateralschäden einfach ignoriert hat, dann ist der > Schaden viel größer. Ich persönlich finde es nicht dramatisch, dass unsere Datenbank frei verfügbar ist wie Wasser, Sand oder Luft. Ob mit oder ohne Quellenangabe, wen juckt es letztlich? Die Daten sind frei, das ist doch das Tolle daran. Solange dieser Freiheit keine ernstliche Gefahr droht, wo liegt dann das eigentliche Problem? > Das klingt in meinen Ohren alles ein wenig nach Atomlobby: > "Es gibt weltweit zwar kein sicheres Endlager und ein Super-GAU ist > nie auszuschließen - diese Gefahren sind aber längst nicht so > dramatisch wie sie sich zunächst anhören! Wenn es eines Tages eine > 100% sichere und kostenlose Alternative gibt (also die Hölle zufriert > und Schweine fliegen können), dann nichts wie rüber. Bis dahin müssen > wir aber unsere Investitionen beschützen und billigen Stom anbieten. > Bei einem Ausstieg gäbe es Kosten für uns und die Kunden, deshalb > produzieren wir weiter munter Atommüll - es wird schon gutgehen!" *Ähem * hüstel * pardon aber dieser Vergleich wirkt in meinen Augen doch etwas sehr über's Ziel hinaus geschossen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel - wer will was
Hallo Christian, Kollateralschäden durch Datenverluste Drohende Kollateralschäden durch Datenverluste wiegen für mich bei weitem schwerer. Das würde IMO die aktiven Mapper vor Ort demoralisieren mit der Folge, dass sich viele enttäuscht für immer verabschieden. Mach mal jemandem, der nur mappt und der sich sonst keine Gedanken macht, begreiflich, dass seine ehrenamtliche(!) Arbeit der letzten anderthalb Jahre umsonst war, weil irgendwelche Juristen herausgefunden haben das Lizenzierungsmodell sei nicht wasserdicht. Ja das ist eine zentrale Problematik. Solange diese nicht gelöst ist, wäre ein Lizenzwechsel eine grobe Missachtung der Arbeit der Freiwilligen. Coole Idee: Vor dem Hintergrund der drohenden Umstellung müsste man beim Mappen jetzt schon anders vorgehen. Vorschlag: In die Editoren wird eine Auswahlliste eingebaut: - mein Beitrag ist frei: "Public Domain" - mein Beitrag soll CC-by-SA sein - mein Beitrag soll ODbL sein - ich verstehe die Unterschiede nicht, macht was ihr wollt Damit hätte man gleich zwei Dinge erreicht: 1. eine individuelle Attributierung für jede Datenänderung 2. eine kontinuierliche Umfrage, wer denn was will Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Am Sonntag, 18. Juli 2010 12:03:47 schrieb Christian Schmitt: > Ich persönlich finde es nicht dramatisch, dass unsere Datenbank frei > verfügbar ist wie Wasser, Sand oder Luft. Ob mit oder ohne Quellenangabe, > wen juckt es letztlich? Die Daten sind frei, das ist doch das Tolle daran. > Solange dieser Freiheit keine ernstliche Gefahr droht, wo liegt dann das > eigentliche Problem? Ich könnte jetzt sagen, eigentlich will ich PD-Daten, also bin ich für die alte Lizenz, weil die wegen teilweiser Wirkungslosigkeit dem PD näher kommt als die neue. Mir gefällt aber nicht, dass die Nutzungsmöglichkeit dann vom lokal geltenden Rechtssystem und dem jeweiligen Mut des Anwenders abhängt. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Hallo, Am 18. Juli 2010 12:03 schrieb Christian Schmitt : > Hallo, > > Am 18.07.2010 um 11:34 schrieb Stefan Schwan: > >> Dann mach mal dem glühenden by-SA Anhänger aus Hintertupfingen klar, >> dass die Feldwege die er gemappt hat, auf einem T-Shirt oder in einer >> I-Phone App ohne Quellenangabe verkauft werden können, weil die Lizenz >> nicht wasserdicht ist. Wenn der rausbekommt, dass es der Foundation >> schon lange klar war, dass so etwas passieren kann, man es aber wegen >> möglicher Kollateralschäden einfach ignoriert hat, dann ist der >> Schaden viel größer. > > Ich persönlich finde es nicht dramatisch, dass unsere Datenbank frei > verfügbar ist wie Wasser, Sand oder Luft. Ob mit oder ohne Quellenangabe, wen > juckt es letztlich? Die Daten sind frei, das ist doch das Tolle daran. > Solange dieser Freiheit keine ernstliche Gefahr droht, wo liegt dann das > eigentliche Problem? > Das Problem liegt darin, das die by-SA Anhänger genauso emotional wie die PD Anhänger an die Sache rangehen. Die sagen ganz zu Recht, das sie Ihre Daten unter by-SA, und nur unter by-SA, freigegeben haben - weil sie glauben, dass diese Art der Lizenz für das Projekt das beste ist. Die Abstimmung in der OSMF hat ergeben, das eine Mehrheit der (OSMF) Mitglieder das genauso sieht. Mit dem Lizenzwechsel will die Foundtion also dafür sorgen, dass das abgegebene Versprechen "Die Daten sind by-SA" auch eingehalten werden kann. > >> Das klingt in meinen Ohren alles ein wenig nach Atomlobby: >> "Es gibt weltweit zwar kein sicheres Endlager und ein Super-GAU ist >> nie auszuschließen - diese Gefahren sind aber längst nicht so >> dramatisch wie sie sich zunächst anhören! Wenn es eines Tages eine >> 100% sichere und kostenlose Alternative gibt (also die Hölle zufriert >> und Schweine fliegen können), dann nichts wie rüber. Bis dahin müssen >> wir aber unsere Investitionen beschützen und billigen Stom anbieten. >> Bei einem Ausstieg gäbe es Kosten für uns und die Kunden, deshalb >> produzieren wir weiter munter Atommüll - es wird schon gutgehen!" > > > *Ähem * hüstel * pardon aber dieser Vergleich wirkt in meinen Augen doch > etwas sehr über's Ziel hinaus geschossen. > Womöglich - er sollte illustrieren das man Fakten die einem nicht passen aus kurzfristigen Motiven zwar ignorieren und schönreden kann, sie einen irgendwann aber einholen werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18.07.2010 um 12:02 schrieb Markus: >>> http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories > > Sollte jemand vielleicht noch auf deutsch übersetzen... Freue mich auf Deine Übersetzung. Leider ist mien englisch nicht s gut, dass ich das adäquat könnte. > Und das mit der "benutze die Suche in OSM" müsste man auch noch irgendwie > sinnvoll verlinken (ich wüsste nämlich nicht wie man nach einer Kombination > von zwei Schlüssel-/Wertepaaren sucht). Derjenige, der eine Datenbank für seine Zwecke aufbaut, kann auch in OSM-Daten nach Schlüsselpaaren suchen ;-) Bei der Relation müsste das ja auch klappen ;-) >>> Hier scheint die Meinung anders zu sein: >>> http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations >> >> Deshalb ist es auch nur ein Vorschlag. > > Aber einer der Schule zu machen scheint... Woran erkennst Du das bzgl. unseres Themas? Welche Zusammenfassungen von z.B. amenities in Relationen kennst Du? Hast Du Beispiele? Die meisten anderen Proposed_uses_of_relations beziehen sich tatsächlich auch Relationen, wie sie eigentlich gemeint sind, nicht der blosen Zusammenfassung von Daten einer Kategorie. Sie sind nur deshalb noch Vorschläge, weil sie kaum genutzt wurden/werden, oder mittlerweile andere Wege gefunden wurden, die jeweiligen Ziele zu erreichen. > Und der im Widerspruch zu der Aussage unter "Definition" steht. Laut dieser Definition sollen verschiedene Elemente auch in OSM zusammengebracht werden, die mit einer bestimmten Rolle auch in der Wirklichkeit untereinander in Beziehung stehen. Sie sind nicht nur in Beziehung untereinander, weil sie der selben Kategorie angehören. Das ist der Unterschied. > Das verwirrt den Benutzer. Wenn er die Defintion gelesen und verstanden hat nicht. > Da müssten zumindest die Vor- und Nachteile der beiden Modelle verständlich > beschrieben sein... Es gibt nur ein Modell: s.o. bei Definition. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel - wer will was
Hallo Am 18. Juli 2010 12:10 schrieb Markus : > Hallo Christian, > >>> Kollateralschäden durch Datenverluste >> >> Drohende Kollateralschäden durch Datenverluste wiegen für mich bei weitem >> schwerer. Das würde IMO die aktiven Mapper vor Ort demoralisieren mit der >> Folge, dass sich viele enttäuscht für immer verabschieden. Mach mal >> jemandem, der nur mappt und der sich sonst keine Gedanken macht, >> begreiflich, dass seine ehrenamtliche(!) Arbeit der letzten anderthalb Jahre >> umsonst war, weil irgendwelche Juristen herausgefunden haben das >> Lizenzierungsmodell sei nicht wasserdicht. > > Ja das ist eine zentrale Problematik. > Solange diese nicht gelöst ist, wäre ein Lizenzwechsel eine grobe > Missachtung der Arbeit der Freiwilligen. > Eine noch größere Missachtung wäre es, die Unzulänglichkeiten der bisherigen Lizenz einfach zu ignorieren und nach dem Motto "wir sinken nicht" einfach weiter zu machen. > Coole Idee: > >> Vor dem Hintergrund der drohenden Umstellung müsste man beim Mappen jetzt >> schon anders vorgehen. > > Vorschlag: > In die Editoren wird eine Auswahlliste eingebaut: > - mein Beitrag ist frei: "Public Domain" > - mein Beitrag soll CC-by-SA sein > - mein Beitrag soll ODbL sein > - ich verstehe die Unterschiede nicht, macht was ihr wollt > Möglichkeit 4 wäre gleich Möglichkeit 1, CC-by-SA klappt für unsere Daten nicht, man könnte sie einfach als PD wieder veröffentlichen. Das wäre also auch Möglichkeit 1. Bleiben also nur PD oder ODbL über - PD Daten kann man in die ODbL übernehmen... > Damit hätte man gleich zwei Dinge erreicht: > 1. eine individuelle Attributierung für jede Datenänderung > 2. eine kontinuierliche Umfrage, wer denn was will > Man hätte nur eins erreicht - 2 Datensätze: Einen kleineren PD und einen größeren unter der ODbL. Zusätzlich hätte man alle Leute die CC-by-SA ankreuzen gründlich verarscht. > Gruss, Markus > Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Hallo Jens, > Das sind Dinge, die ich im API über amenity=fuel, operator=Aral suchen kann. > Wozu noch eine Relation? Die wird nie vollständig sein, hat extra > Pflegeaufwand und keinen Mehrwert. Solange man via XAPI nur nach einem einzelnen Key und rechteckigen bounding-boxen filtern kann, solange wird es auch Leute geben, die Relationen als Filter 'missbrauchen'.. (Ja, ich gehöre mit zu diesen Leuten. Zumal die Grenzen häufig eh fliessend sind.) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel
Frederik Ramm glaubte zu wissen: > Die Anschuldigung, dass die OSMF den Verlust von Daten in Kauf nimmt, > klingt hohl aus dem Munde von jemandem, der im gleichen Atemzug die > Loeschung seiner eigenen Daten ankuendigt, falls man ihm nicht Gehoer > schenkt. +1 > Mir waere es auch lieber, alles waere von Anfang an PD gewesen, dann > haetten wir den Salat jetzt nicht. ACK! Ich glaube, daß zumindest einige der laufenden Diskussionen schädlicher sind als der Verlust einiger Daten. Zumindest mich nerven solche Streitereien extrem. flo -- > Ich mag keine Saetze die nur aus einem Wort bestehen. Mist![Herbert Steinboeck und Bernd Brodesser in suse-talk] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Am 17.07.2010 22:58, schrieb Guenther Meyer: > was spricht gegen CC-BY ? deutsch: http://wiki.openstreetmap.org/wiki/DE:The_license,_where_we_are,_where_we%27re_going http://wiki.openstreetmap.org/wiki/DE:ODbL/We_Are_Changing_The_License englisch: http://www.osmfoundation.org/wiki/License/Why_CC_BY-SA_is_Unsuitable -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0901°N 8.7868°E Ceterum censeo Carthaginem esse delendam. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Hallo ... , http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Freue mich auf Deine Übersetzung Leider ist meine Englisch ungenügend, aber Google hilft: (aber auch da verstehe ich nur "Bahnhof"...) Gruss, Markus - - - - Lieber Wikipedia Beitragszahler, Sie können zu jedem Artikel in der Wikipedia mit mindestens einer Kategorie verwendet werden kann. Sobald Sie einen neuen Artikel in der Wikipedia, ohne eine Kategorie erstellen, wird es entweder sofort zum Abreißen markiert werden oder hinzugefügt, um eine Kategorie. Es gibt Leute, die nichts anderes tun, als den ganzen Tag hinzufügen sinnvolle Kategorien zu Wikipedia-Einträgen. Die "Beziehungen" haben wir in OpenStreetMap sind keine Kategorien. Sie sollen eine enge (und meist lokale) Beziehung zwischen Objekten Modell, zum Beispiel: Dieser Eingang führt in die U-Bahnstation, oder: Sie können nicht von dieser Straße biegen Sie links in diese Straße. Wir nutzen sie, um Fragmente einer Gruppe unterwegs, wie in: Diese fünfzehn Teile bilden zusammen so-und-so Straße. Wir wissen jedoch nicht, schaffen Beziehungen, die einfach zu sammeln eine lose Gruppe von etwas zugehörige Artikel. Wir tun das nicht "Gehwege in East Anglia", machen wir nicht "Scottish Lochs". Als Autor von Wikipedia, können Sie verspüren den Drang, wenigstens eine Beziehung für jedes Objekt finden Sie berühren - aber bitte, dass Drang widerstehen. Unsere Datenbank ist eine räumliche Datenbank; dies bedeutet, dass es intrinsische Wissen über den Standort von Objekten hat. Wenn Sie sich über alle Gehwege in East Anglia wissen wollen, einfach in einer Bounding Box of East Anglia und pass Anfrage alle Gehwege und die Sammlung ist für Sie on-the-fly. Wer nur das Hinzufügen eines Gehwegs hat dafür zu sorgen ist es an der richtigen Stelle und markierte als Gehweg - die Tatsache, dass diese in East Anglia nicht erfasst werden, weil sie implizit. Also, noch einmal - bitte keine Dinge tun, wie "Gehwege in East Anglia". Aber was ist mit den Beziehungen, die Gruppe Informationen hinzufügen, könnten Sie fragen, wie "HSBC Geldautomaten"? Auch hier ist eine Beziehung in der Regel unnötig, wenn die Geldautomaten mit so etwas wie "Betreiber hat HSBC =" dann jemand einfach extrahieren können alle HSBC Geldautomaten, müssen Sie sich nicht, eine Beziehung zu diesem (dies wird nur das Bearbeiten schwieriger zu erstellen und fehleranfällig). Gruppierung Beziehungen wirklich nur sinnvoll, wenn die Gruppierung ist weder geographische (wie oben erörtert) noch exklusive (wie die HSBC Beispiel - die Cash-Maschine ist unwahrscheinlich, dass von zwei verschiedenen Institutionen gleichzeitig betrieben werden). Ein gutes Beispiel für ein gültiges und nützliches Gruppierung ist die "route" Beziehung, wo mehrere Möglichkeiten, verbunden mit einem Radweg oder Wanderweg oder etwas anderes zu bilden; so können an einer beliebigen Anzahl von Routen werden so kann dies nicht durch diese gelöst werden tagging den Weg mit "route = xxx". Vielen Dank für Ihr Verständnis, Diejenigen, die Beziehungen erfunden. - - - - ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin eTrex HCx und große Speicherkart en
hi, nur mal so als "außenstehender": die sd-karte stellt für euer navi - auch nur ein rechner mit os - sich als platte oder memory dar. als entwickler würde ich "mal kurz" darüber huschen, um zu sehen, ob da alles ok ist, oder um bestimmte bereiche zu initialisieren. und das dauert halt. wie beim sprungbrett: "je höher, des so platsch" gruss walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/AIO-wird-nicht-mehr-aktualisiert-tp5269818p5308477.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] Lizenzwechsel-Bauchscmerzen
Am 18.07.2010 13:18, schrieb Dirk-Lüder Kreie: > Am 17.07.2010 22:58, schrieb Guenther Meyer: > >> was spricht gegen CC-BY ? > > deutsch: > http://wiki.openstreetmap.org/wiki/DE:The_license,_where_we_are,_where_we%27re_going > http://wiki.openstreetmap.org/wiki/DE:ODbL/We_Are_Changing_The_License > > englisch: > http://www.osmfoundation.org/wiki/License/Why_CC_BY-SA_is_Unsuitable CC-Lizenzen sind generell nicht für Datensammlungen geeignet, ausser CC0, die eben von der Creative-Commons explizit für sowas empfohlen wird. -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0901°N 8.7868°E Ceterum censeo Carthaginem esse delendam. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Hallo ... , Hier scheint die Meinung anders zu sein: http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations Die meisten anderen Proposed_uses_of_relations beziehen sich tatsächlich auch Relationen, wie sie eigentlich gemeint sind, nicht der blosen Zusammenfassung von Daten einer Kategorie. Ok, dann habe ich das englische Zeug falsch verstanden. Aber auch das ist für mich nicht wirklich verständlich: Laut dieser Definition sollen verschiedene Elemente auch in OSM zusammengebracht werden, die mit einer bestimmten Rolle auch in der Wirklichkeit untereinander in Beziehung stehen. Sie sind nicht nur in Beziehung untereinander, weil sie der selben Kategorie angehören. Das ist der Unterschied. Hier würden Beispiele helfen für: a) gute Relation b) schlechte Relation --> alternative Lösung Dabei sollte der Grenzbereich deutlich werden. Und vielleicht kann man dann für die wichtigsten Fälle sogar Regeln formulieren :-) In einem anderen Thread wird gerade diskutiert, ob man Häuser, deren Adresse zu einer Strasse gehört, in einer Relation zusammengefasst werden soll? Oder PLZ, Ort, Land als Relation? (wurde dort mehrheitlich verneint, aber steht nicht im Wiki). Oder die Frage, ob gesetzliche Regelungen in Relationen zusammengefasst werden sollen (Geschwindigkeitbegrenzung, Rauchverbot). Oder Verkehrssignale (da ist es "established"). Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin eTrex HCx und große Speicherka rten
> die sd-karte stellt für euer navi - auch nur ein rechner mit os - sich als > platte oder memory dar. > als entwickler würde ich "mal kurz" darüber huschen, um zu sehen, ob da > alles ok ist, oder um bestimmte bereiche zu initialisieren. > > und das dauert halt. Aber es hat sich definitiv etwas zwischen 3.0 und später geändert, ohne dass es im Changelog steht. Liebe Grüße Benni signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Christian Schmitt schrieb: Wobei ich der Überzeugung bin sie sind längst nicht so dramatisch wie sie sich zunächst anhören. Ich las heute morgen zuerst talk. Da sind seit gestern zwei Beiträge reingetrudelt. Einer von einem Polen, der sagt, dass fast ganz Polen auf nur-CC-kompatiblen Daen beruht und futsch wäre bei Wechsel. Und gerade eben ein Beitrag, dass ähnliches für große Teile Australiens droht nach Nachfrage bei einem Anbieter von abgezeichneten Luftbildern oder so ... Ich bin exakt dieser Meinung. Drohende Kollateralschäden durch Datenverluste wiegen für mich bei weitem schwerer. Das würde IMO die aktiven Mapper vor Ort demoralisieren mit der Folge, dass sich viele enttäuscht für immer verabschieden. > Mach mal jemandem, der nur mappt und der sich sonst keine Gedanken macht, begreiflich, > dass seine ehrenamtliche(!) Arbeit der letzten anderthalb Jahre umsonst war, > weil irgendwelche Juristen herausgefunden haben das Lizenzierungsmodell sei nicht wasserdicht. Und die meisten davon werden das erst merken, wenn's passiert ist, der Schaden also entstanden und nicht mehr so eben mal umkehrbar ist. Sprich: wir bekommen hier gerade erst die Spitze des Eisberges mit, was da auf uns zukommen könnte. Wobei nach den beiden besagten Beiträgen soll das Problem in der australischen und polnishcen community schon offensichtlicher sein ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel - wer will was
Hallo Stefan,
Kollateralschäden durch Datenverluste
Solange das nicht gelöst ist, wäre ein Lizenzwechsel eine grobe
Missachtung der Arbeit der Freiwilligen.
Eine noch größere Missachtung wäre es, die Unzulänglichkeiten der
bisherigen Lizenz einfach zu ignorieren
Eben.
Dafür braucht man:
a) Fallbeispiele für die jeweiligen Lizenz-Szenarien
b) Kennzahlen und eine Kosten/Nutzen-Rechnung
Wenn diese den Benutzern verständlich kommuniziert sind,
kann man sie fragen wie sie es denn gerne hätten.
Vorschlag:
In die Editoren wird eine Auswahlliste eingebaut:
- mein Beitrag ist frei: "Public Domain"
- mein Beitrag soll CC-by-SA sein
- mein Beitrag soll ODbL sein
- ich verstehe die Unterschiede nicht, macht was ihr wollt
Möglichkeit 4 wäre gleich Möglichkeit 1
Nein, es ist ein grosser Unterschied, ob ich das was die "Oberen" wollen
verstanden habe und mich für "PD" entscheide (oder etwas anderes) - oder
ob ich nichts veststanden habe und mich deshalb auch nicht mündig für
etwas entscheiden kann.
CC-by-SA klappt für unsere Daten nicht
Wieso? es "klappt" doch seit Jahren...
PD Daten kann man in die ODbL übernehmen...
Ja, auch in /jede/ andere Lizenz - aber sie bleiben trotzdem PD :-)
Damit hätte man gleich zwei Dinge erreicht:
1. eine individuelle Attributierung für jede Datenänderung
2. eine kontinuierliche Umfrage, wer denn was will
Man hätte nur eins erreicht - 2 Datensätze: Einen kleineren PD und
einen größeren unter der ODbL.
Hm - nach einer Umfrage sind 43% für PD.
Und ich vermute, wenn die Frage etwas differenzierter gestell wird,
und unsinnige Koppelfragen aufgedröselt werden,
dann werden sich weitere OSMer für PD entscheiden.
Zusätzlich hätte man alle Leute die
CC-by-SA ankreuzen gründlich verarscht.
Irgendwie scheint mir, als sei das ganze Lizenzgedöns der letzten Jahre
eine einzige "Verarsche". Nicht weil das jemandes Absicht gewesen wäre,
sondern weil man "die Freie Weltkarte" versucht hat in ein juristisches
Korsett zu pressen, und dabei auch noch unserer eigenen Eitelkeit
("meine Daten") dienen wollte. Und weil man uns immer versichert hat,
das sei "das Beste für uns"...
Ich kann mir schwer vorstellen, dass das neue Korsett besser wäre.
Und der damit verbundene Datenverlust ist durch nichts zu rechtfertigen.
Gruss, Markus
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories >> >> Sollte jemand vielleicht noch auf deutsch übersetzen... > Freue mich auf Deine Übersetzung. Leider ist mien englisch nicht > s gut, dass ich das adäquat könnte. Lieber Wikipedia-Benutzer, wahrscheinlich hast Du Dich daran gewöhnt, dass jeder Artikel in der Wikipedia zu mindestens einer Kategorie gehört. Sobald Du einen Artikel ohne Kategorie erstellst, wird er entweder sofort als Lösch- kandidat markiert oder einer Kategorie zugeordnet. Es gibt Leute, die den ganzen Tag nichts anderes tun als Artikeln Kategorien zuzuweisen. Relationen in OSM sind *keine* Kategorien. Sie sind dazu da, um eine enge Verbindung (meistens lokal) zwischen Objekten herzustellen; z.B. 'dieser Eingang führt zu dieser U-Bahn-Station' oder 'Du darfst von dieser Strasse nicht auf jene Strasse abbiegen'. Sie werden auch benutzt, um zusammengehörige Strassenabschnitte zu gruppieren [Anm: Sagen wir nicht andernorts, Relationen für Strassen seien unnötig?] Allerdings werden Relationen nicht benutzt, um lose Gruppen von irgendwie verbundenen Objekten zu sammeln. Es gibt keine Relation "Fusswege in Westangola" oder "Seen in Schottland". Als Wikipedianer hast Du vielleicht das Bedürfnis, für jedes Objekt welches Du anfasst eine passende Relation zu finden - bitte widerstehe diesem Drang. Unsere Datenbank ist eine räumliche Datenbank; dies bedeutet, dass die Datenbank 'weiss', wo ein Objekt liegt. Wenn Du alle Fusswege in Westangola anzeigen möchtest, dann kannst Du einfach alle Fusswege innerhalb der Grenzen von Westangola anfordern, und die Sammlung "Fusswege in Westangola" wird in dem Moment automatisch erstellt. Jeder, der einen Fussweg in Westangola der Datenbank hinzufügt muss nur sicherstellen, dass der Weg korrekt getagged und am richtigen Ort ist - der Fakt, dass der Weg in Westangola ist, muss nicht zusätzlich angegeben werden. Daher, nochmals: Bitte keine Relation "Fusswege in Westangola". Doch was ist mit Gruppen wie "Geldautomaten der HSBC-Bank"? Auch hier ist eine Relation meistens unnötig: Wenn die Geldautomaten mit einem Tag wie "operator=HSBC" versehen werden, dann kann jeder alle HSBC- Geldautomaten in der Datenbank abrufen; es wird keine Relation dafür benötigt. (Eine Relation macht bloss das Editieren komplizierter und fehleranfälliger.) Gruppen-Relationen machen nur sinn, wenn die Gruppierung nicht geographisch (wie oben beschrieben) oder exklusiv (wie das HSBC-Beispiel; es ist unwahrscheinlich, dass ein Geldautomat von zwei verschiedenen Banken betrieben wird) ist. Ein gutes Beispiel für eine sinnvolle Gruppierung ist die Route- Relation, bei der mehrere Way-Elemente verbunden werden, um eine Rad- oder Wanderstrecke abzubilden. Ein einzelner Weg kann in mehreren Routen enthalten sein und daher kann der Weg nicht einfach mit "route=xxx" getagged werden. Vielen Dank für Dein Verständnis, Diejenigen, welche Relationen erfunden haben [Dies ist nur eine Übersetzung und nicht unbedingt meine eigene Meinung.] Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18.07.2010 um 13:36 schrieb Markus: > Hallo ... , > > Hier scheint die Meinung anders zu sein: > http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations >> >> Die meisten anderen Proposed_uses_of_relations beziehen sich tatsächlich >> auch Relationen, wie sie eigentlich gemeint sind, nicht der blosen >> Zusammenfassung von Daten einer Kategorie. > > Ok, dann habe ich das englische Zeug falsch verstanden. Hey, ganz OSM ist englisch. :-) > Aber auch das ist für mich nicht wirklich verständlich: > >> Laut dieser Definition sollen verschiedene Elemente auch in OSM >> zusammengebracht werden, die mit einer bestimmten Rolle auch in der >> Wirklichkeit untereinander in Beziehung stehen. Sie sind nicht nur in >> Beziehung untereinander, weil sie der selben Kategorie angehören. Das ist >> der Unterschied. > > Hier würden Beispiele helfen für: > a) gute Relation O.k. ein paar Beispsiele für Dich: Beispiel Abbiegerelation. Hier wird die Beziehung eines was über einen gemeinsamen Knoten zum nächsten way abgebildet. Z.B. als "Nicht von diesem way 1 über diesen Knoten auf den anderen way 2 fahren"- Regel. In diesem Beispiel stehen die beteiligten beiden ways über den gemeinsamen Knoten in direkter Beziehung zueinander - auch in der Wirklichkeit, darf man nicht von dem Straßenteil (way 1) über den Schnittpunkt beider beteiltigter Straßenteile (node) in den anderen Straßenteil (way 2) abbiegen. > b) schlechte Relation --> alternative Lösung Alle Gebäude, die amentiy=fuel und operator=BP im tag haben innerhalb eines bestimmten Gebietes in einer Relation zusammenfassen. Hier gibt es ausser den abstrakten Beziehungen der Funktion und des Betreibers keine Beziehung in der Wirklichkeit zueinander, noch haben die Elemente eine bestimmte Rolle in dieser Relation/Beziehung.Es ist einfach nur eine Sammlung dieser Kategorie --> Alternative: Ein Programm schreiben/nutzen, das nach diesen Tags suchen und diese dann ausgeben kann. Da man mit der XAPI IMHO nur nach einem Tag suchen kann, kann man aber im Ergebnis der ersten Suche (amenity=fuel) nach einem weiteren Tag suchen (operator=BP). > Dabei sollte der Grenzbereich deutlich werden. Wurde er anhand der Beispiele jetzt auch, oder? > Und vielleicht kann man dann für die wichtigsten Fälle sogar Regeln > formulieren :-) Das geht doch schon aus dem bestehenden Wiki hervor. Ableiten muss man vieles in OSM. > In einem anderen Thread wird gerade diskutiert, ob man Häuser, deren Adresse > zu einer Strasse gehört, in einer Relation zusammengefasst werden soll? Oder > PLZ, Ort, Land als Relation? (wurde dort mehrheitlich verneint, aber steht > nicht im Wiki). Natürlich steht im Wiki (genau: im Proposal), dass es drei Arten der Erfassung von Hausnummern gibt: Einzelnode, Interpolation und Relation. Doch wie und wann diese zu verwenden seien haben wir in dem von Dir genannten Thread besprochen und wurde von mir auch im Proposal als Fazit der Diskussion eingetragen. Es steht doch noch drin , oder? ;-) > Oder die Frage, ob gesetzliche Regelungen in Relationen zusammengefasst > werden sollen (Geschwindigkeitbegrenzung, Rauchverbot). Das wäre wiederum eine Sammlung von Elementen in einer Kategorie, womit Du wieder bei "Relations ar not Categories" bist. Doch davon abgesehen: warum sollten einfache tags, die als Eigenschaft eines Objekts getaggt wurden, in einer Relation zusammengefasst werden? Warum möchtest Du alle ways die den maxspeed-tag :DE:urban tragen in einer Liste haben, und dann noch eine mit maxspeed=100? Und selbst wenn Du es möchtest: diese ways findet man auch über die XAPI mit der Suche nach allem ,was den entsprechenden Tag hat udn kannst es selbst in eine DB schreiben. > Oder Verkehrssignale (da ist es "established"). welche Verkehrssignale meinst Du z.B.? Auch da muss man unterscheiden, welches Verhalten/Regel sich davon ableiten lässt und wie diese am sinnvollsten und einfachsten abzubilden ist: Du kannst eine Richtungsschild in einer Relation packen, indem Du sagts, von dem way, über den node auf den way geht es zum Schwimmbad. Du kannst auch einem Einfahrtverbotsschild in eine Relation packen: von dem way über den node auf den way darf man nicht hinein fahren. Und Du kannst einen Ampelblitzer als Relation eintragen: Wenn Du von dem way über den node auf den way fährst kann es sein, dass Du geblitzt wirst, weil aus dieser Richtung die Einhaltung des roten Ampelsignals überwacht wird. Ein Parkverbotsschild musst Du aber keine Relation abbilden, dazu genügt es den enstprechenden way entsprechend zu taggen. Dazu gibts übrigens auch eine hochqualitatives Proposal: "Parking". Auch ein Stopschild benötigt keine Relation, denn das gilt für alle ways, die direkt nach dem node des Schildes folgen. Da muss ich das von wo über welchen node nach "wohin" nicht noch in Relationen packen. Das gleiche gilt für das Achtung Bahnübergang, oder oder oder ... Du siehst, dass es immer darauf ankom
Re: [Talk-de] Lizenzwechsel - wer will was
Am 18.07.2010 14:00, schrieb Markus: >> CC-by-SA klappt für unsere Daten nicht > > Wieso? es "klappt" doch seit Jahren... Mit *der* Begründung kann man bei Russisch Roulette auch ein zweites Mal abdrücken... -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0901°N 8.7868°E Ceterum censeo Carthaginem esse delendam. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Am 17.07.2010 15:05, schrieb ant: > On 16.07.2010 20:12, Manuel Reimer wrote: >> Davon hätte jeder andere, der auch OSM nutzt, sofort direkt einen >> Vorteil, weil die Daten kompletter werden. > > Daten sind nur dann von Nutzen, wenn es nützliche Anwendungen gibt, die > mit diesen Daten etwas anfangen. Die Möglichkeiten, die sich für solche > Anwendungen eröffnen, steigen mit dem Freiheitsgrad der Lizenz. Und je > besser die Anwendungen werden, desto mehr Leute werden sich OSM > zuwenden, um die Daten zu verbessern. Das sehe ich ganz genauso. OSM hat, wie zuvor Wikipedia, gezeigt, dass Crowdsourcing funktioniert. OSM hat ausserdem geschafft, dass einige, die vorher Geodaten als möglichst proprietär behandeln wollten, sich jetzt Gedanken machen, ob nicht der öffentliche Weg der bessere ist, für alle Beteiligten. Ich persönlich sehe einen Datenverlust als nicht so schwerwiegend, wie einige andere, vielleicht auch, weil ich vor ca. vier Jahren mit Bremen vor einer weißen Leinwand saß, und gesehen habe, wie wenige, motivierte Mapper in vier Jahren gesamt Bremen auf die freie Weltkarte gebracht haben. Ich weiß auch, dass diese Arbeit mit den jetzt angemeldeten Mappern in wenigen Monaten erneut leistbar wäre, es also keinesfalls wieder vier Jahre dauern würde, bis wir Bremen in einem vergleichbaren Zustand wieder zusammen hätten. Und ich bin überzeugt, dass das für ganz Deutschland gilt. Problematisch sind Länder, die von großen Datenimporten/Luftbildspenden mit CC-By-SA-Bedingunen profitiert haben, also z.B. Niederlande, Polen, Australien, und andere. Unproblematisch ist unser größter Import: Tiger, die Daten waren von Anfang an Public Domain. Es hätte damals ein Hinweis sein können, dass By-SA nicht unbedingt das Optimum darstellt. -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0901°N 8.7868°E Ceterum censeo Carthaginem esse delendam. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18.07.2010 um 14:02 schrieb Thomas Ineichen: > Lieber Wikipedia-Benutzer, > > wahrscheinlich hast Du Dich daran gewöhnt, dass jeder Artikel in der > Wikipedia zu mindestens einer Kategorie gehört. Sobald Du einen > Artikel ohne Kategorie erstellst, wird er entweder sofort als Lösch- > kandidat markiert oder einer Kategorie zugeordnet. Es gibt Leute, die > den ganzen Tag nichts anderes tun als Artikeln Kategorien zuzuweisen. > > Relationen in OSM sind *keine* Kategorien. Sie sind dazu da, um eine > enge Verbindung (meistens lokal) zwischen Objekten herzustellen; z.B. > 'dieser Eingang führt zu dieser U-Bahn-Station' oder 'Du darfst von > dieser Strasse nicht auf jene Strasse abbiegen'. Sie werden auch > benutzt, um zusammengehörige Strassenabschnitte zu gruppieren [Anm: > Sagen wir nicht andernorts, Relationen für Strassen seien unnötig?] > Allerdings werden Relationen nicht benutzt, um lose Gruppen von > irgendwie verbundenen Objekten zu sammeln. Es gibt keine Relation > "Fusswege in Westangola" oder "Seen in Schottland". Als Wikipedianer > hast Du vielleicht das Bedürfnis, für jedes Objekt welches Du anfasst > eine passende Relation zu finden - bitte widerstehe diesem Drang. > Unsere Datenbank ist eine räumliche Datenbank; dies bedeutet, dass die > Datenbank 'weiss', wo ein Objekt liegt. Wenn Du alle Fusswege in > Westangola anzeigen möchtest, dann kannst Du einfach alle Fusswege > innerhalb der Grenzen von Westangola anfordern, und die Sammlung > "Fusswege in Westangola" wird in dem Moment automatisch erstellt. > Jeder, der einen Fussweg in Westangola der Datenbank hinzufügt muss > nur sicherstellen, dass der Weg korrekt getagged und am richtigen Ort > ist - der Fakt, dass der Weg in Westangola ist, muss nicht zusätzlich > angegeben werden. > > Daher, nochmals: Bitte keine Relation "Fusswege in Westangola". > > Doch was ist mit Gruppen wie "Geldautomaten der HSBC-Bank"? Auch hier > ist eine Relation meistens unnötig: Wenn die Geldautomaten mit einem > Tag wie "operator=HSBC" versehen werden, dann kann jeder alle HSBC- > Geldautomaten in der Datenbank abrufen; es wird keine Relation dafür > benötigt. (Eine Relation macht bloss das Editieren komplizierter und > fehleranfälliger.) Gruppen-Relationen machen nur sinn, wenn die > Gruppierung nicht geographisch (wie oben beschrieben) oder exklusiv > (wie das HSBC-Beispiel; es ist unwahrscheinlich, dass ein Geldautomat > von zwei verschiedenen Banken betrieben wird) ist. > > Ein gutes Beispiel für eine sinnvolle Gruppierung ist die Route- > Relation, bei der mehrere Way-Elemente verbunden werden, um eine Rad- > oder Wanderstrecke abzubilden. Ein einzelner Weg kann in mehreren > Routen enthalten sein und daher kann der Weg nicht einfach mit > "route=xxx" getagged werden. > > > Vielen Dank für Dein Verständnis, > > Diejenigen, welche Relationen erfunden haben > > [Dies ist nur eine Übersetzung und nicht unbedingt meine eigene > Meinung.] Danke Thomas, ist drin :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Merci Thomas! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18.07.2010 um 14:42 schrieb steffterra: >> Sie werden auch >> benutzt, um zusammengehörige Strassenabschnitte zu gruppieren [Anm: >> Sagen wir nicht andernorts, Relationen für Strassen seien unnötig?] Hier habe ich soeben ein Beispiel ergänzt: '", wie z.B. für offiziell ausgeschilderte Wanderwege des Alpenvereins." Ich denke, dann ist klar, was gemeint ist. Danke nochmals für die Übersetzung (bist im log erwähnt *g*), steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Am 18.07.2010 09:17, schrieb Christian Schmitt: > Am 17.07.2010 um 23:43 schrieb Heiko Jacobs: > >> Die neue Lizenz ist an sich nicht schlecht. Und ist nach Meinung >> einiger tatsächlich angeraten. Sie haben vemrutlich Recht, ich bin >> aber kein Jurist o.ä. >> >> Das, was kein Mensch braucht, sind nur die Kollateralschäden durch >> Datenverluste für das aktive Projekt. > > Ich bin exakt dieser Meinung. Drohende Kollateralschäden durch > Datenverluste wiegen für mich bei weitem schwerer. Das würde IMO die > aktiven Mapper vor Ort demoralisieren mit der Folge, dass sich viele > enttäuscht für immer verabschieden. Mach mal jemandem, der nur mappt > und der sich sonst keine Gedanken macht, begreiflich, dass seine > ehrenamtliche(!) Arbeit der letzten anderthalb Jahre umsonst war, > weil irgendwelche Juristen herausgefunden haben das > Lizenzierungsmodell sei nicht wasserdicht. Du wirfst zu viel durcheinander. Zunächsteinmal werden nicht alle demoralisiert, das weiss ich sicher, weil ich nicht demoralisiert würde. Und ich weiss obendrein, dass viele andere Mapper das genauso sehen, als "prominentes" nicht-Bremer Beispiel sei Frederik genannt. Abgesehen davon lässt die Phasenweise Umstellung viele Möglichkeiten mit Mappern zu reden, die sich weigern die Lizenz anzuerkennen, und es gibt auch ethisch-moralisch unbedenkliche und legale Wege problematische Edits aus der History auszuklammern, so dass die Objekte möglichst vollständig relizensiert werden können. > Und noch was: Vor dem Hintergrund der drohenden Umstellung müsste man > (als Befürworter des neuen Modells) beim Mappen jetzt schon anders > vorgehen. Alle Objekte die man selber anfasst löschen und durch > eigene ersetzen. Das fände ich moralisch bedenklich, es sei denn, du mappst belegbar von null (kannst z.B. GPX-traces, Fotos, Aufzeichnungen vorweisen). -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0901°N 8.7868°E Ceterum censeo Carthaginem esse delendam. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
steffterra schrieb: > Am 18.07.2010 um 03:06 schrieb Tirkon: > >> steffterra wrote: >> >>> Wenn alle Straßen in Orten, in den denen es Hausnummern gibt, in Relationen >>> gefasst wären, dann könnten wir OSM für Neuuser dicht machen und wären >>> ständig am nachreparieren der Hausnummer-Straßen-Relationen. Weil - selbst >>> wenn man nichts mit Hausnummern am Hut hat und auch gar nichts an der >>> Relation ändern will - und sei es nur dass sich der Verlauf eines Radweges >>> geändert hat, dann ist die Relation futsch und ein Router findet keine >>> einzige Hausnummer dieser Relation mehr, wenn der (Neu)User die Relation >>> nicht richtig beachtet hat. >> Es bleibt ohne Relation besser menschenlesbar. > > +1 Mit diesem Argument triffst Du auch alle tags mit mehreren Werten. >> Zu all den genannten Argumenten gegen eine Relation hier noch ein >> weiteres, das sich auf der Insel Baltrum auftut: Dort werden >> Hausnummern in der Reihenfolge der Errichtung der Häuser vergeben. Bei >> jedem Bauantrag wird also eine neue Nummer vom Stapel genommen. Damit >> hat das erste erbaute Haus auf der Insel die Hausnummer 1. Nummer 11 >> könnte durchaus neben Nummer 111 stehen. Die Hausnummer hat dort also >> keine geografischen Bezug mehr. Die explizite Adressnennung am Haus >> bewährt sich auch dort als die beste Methode. > > +1 Wo ist da das Problem zur Relation ? > Aber, ohne Dir/mir selbst in den Rücken fallen zu wollen: > Hausnummern-Relationen _können_ an _manchen Stellen_ sinnvoller sein, als das > Einzeltagging. Aber eben auch umgekehrt, wie man an Tirkons Beispiel Baltrum > sehen kann. Sie sind aber defintiv nicht das Allerheilmittel, als das die > Informatiker unter uns sie immer (vlt. unbewusst?) hinstellen möchten. Meiner Meinung nach sollte entweder eine Relation oder die vollständige Version verwendet werden. Ich verwende eigentlich nur Relatione mit PLZ. Wo es mehrere PLZ gibts teile ich die Relation in zwei Unterrelationen und wenn mal eine eigene PLZ für ein Gebäude existiert tagge ich die an das Gebäude mit zusätzlicher note. Ich habe kein Problem mit der vollständigen Aufzählung an jedem Punkt und wenn ich in meiner Gegend editiere filtere ich immerwieder nach "addr:street" und füge die paar neuen Address-Punkt in die Relation ein. Generell halte ich die Diskussion um Newbees und Relationen für fragwürdig. 1. Existieren immer mehr Relation und man wird damit sehr schnell konfrontiert, somit sollte man neuen Mitglieder diese eher gut erklären als zu behaupten, es wäre kompliziert. 2. Probleme sehe ich eher bei den Editors als den Mappern. Leider können die Editors häufig nicht gut mit Relationen umgehen.(bearbeiten/darstellen) Als ich vor ca. 1 Jahr neu dazu kam, gab es leider noch weniger Dokumentation. Trotzdem war ich recht schnell mit route-Relationen konfrontiert. Schon beim Einfügen einer Abbiegespur mußte ich Relationen bearbeiten. Zu der Zeit existierten zusätzlich noch einige Bugs in JOSM, wodurch ich auch eine Relationen beschädigte. Darauf wurde ich von zwei erfahreneren Benutzern hingewiesen und wir haben die Fehler gemeinsam behoben. Diese Probleme haben mir als neues Mitglied sehr geholfen Erfahrungen und Verständnis zu gewinnen und zusätzlich in einer Gegend ohne user-group erste Kontakte zu lokalen Mappern ermöglicht. Als Anfänger macht jeder Fehler, aber gerade dadurch kann man auch viel lernen. Grüße Colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Dirk-Lüder Kreie schrieb: Problematisch sind Länder, die von großen Datenimporten/Luftbildspenden mit CC-By-SA-Bedingunen profitiert haben, also z.B. Niederlande, Polen, Australien, und andere. Unproblematisch ist unser größter Import: Tiger, die Daten waren von Anfang an Public Domain. Es hätte damals ein Hinweis sein können, dass By-SA nicht unbedingt das Optimum darstellt. Genau, daran sieht man dass PD am wenigsten Probleme verursacht. Man könnte sogar sagen, OSM bedient sich gerne bei PD Daten ohne "etwas zurückzugeben" in Form von genauso "freien" Daten.. ;) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin eTrex HCx und große Speicherkart en
schon mal mit dem herstellen "gesprochen"? alles andere ist doch nur spekulation - auch meine obige bemerkung ;( - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/AIO-wird-nicht-mehr-aktualisiert-tp5269818p5308762.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] Lizenzwechsel-Bauchscmerzen
On 18.07.2010 14:40, Dirk-Lüder Kreie wrote: Am 17.07.2010 15:05, schrieb ant: On 16.07.2010 20:12, Manuel Reimer wrote: Davon hätte jeder andere, der auch OSM nutzt, sofort direkt einen Vorteil, weil die Daten kompletter werden. Daten sind nur dann von Nutzen, wenn es nützliche Anwendungen gibt, die mit diesen Daten etwas anfangen. Die Möglichkeiten, die sich für solche Anwendungen eröffnen, steigen mit dem Freiheitsgrad der Lizenz. Und je besser die Anwendungen werden, desto mehr Leute werden sich OSM zuwenden, um die Daten zu verbessern. Das sehe ich ganz genauso. OSM hat, wie zuvor Wikipedia, gezeigt, dass Crowdsourcing funktioniert. OSM hat ausserdem geschafft, dass einige, die vorher Geodaten als möglichst proprietär behandeln wollten, sich jetzt Gedanken machen, ob nicht der öffentliche Weg der bessere ist, für alle Beteiligten. Ich persönlich sehe einen Datenverlust als nicht so schwerwiegend, wie einige andere, vielleicht auch, weil ich vor ca. vier Jahren mit Bremen vor einer weißen Leinwand saß, und gesehen habe, wie wenige, motivierte Mapper in vier Jahren gesamt Bremen auf die freie Weltkarte gebracht haben. Ich weiß auch, dass diese Arbeit mit den jetzt angemeldeten Mappern in wenigen Monaten erneut leistbar wäre, es also keinesfalls wieder vier Jahre dauern würde, bis wir Bremen in einem vergleichbaren Zustand wieder zusammen hätten. Und ich bin überzeugt, dass das für ganz Deutschland gilt. ... und wenn wir beim Neuerfassen der Straßen gleich alle anliegenden Geschäfte/POI überprüfen und fehlende Hausnummern eintragen, haben wir damit auch noch was gewonnen. Problematisch sind Länder, die von großen Datenimporten/Luftbildspenden mit CC-By-SA-Bedingunen profitiert haben, also z.B. Niederlande, Polen, Australien, und andere. Unproblematisch ist unser größter Import: Tiger, die Daten waren von Anfang an Public Domain. Es hätte damals ein Hinweis sein können, dass By-SA nicht unbedingt das Optimum darstellt. ___ 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] Lizenzwechsel-Bauchscmerzen
On 18.07.2010 04:06, Sebastian Hohmann wrote: ant schrieb: On 17.07.2010 11:47, Sebastian Hohmann wrote: Wenn ich jemanden meine Daten geben und sagen "das steht unter der CC0", dann darf er sie natürlich beliebig lizenzieren, auch ohne sie vorher zu veröffentlichen. Nur möchte ich meine Beiträge schließlich der Allgemeinheit zur Verfügung stellen,nicht der OSMF, die es dann direkt in ODbL umlizenziert. Du möchtest deine Beiträge der Allgemeinheit zur Verfügung stellen, aber nicht der OSMF? Das musst du mir mal erklären. Gerne. Ich möchte es als PD allen zur Verfügung stellen, nicht NUR der OSMF, die es dann direkt umlizenziert und erst dann veröffentlicht. Es geht um das Argument, wer seine Daten als PD ansieht habe automatisch auch kein Problem damit, wenn sie NUR unter einer anderen Lizenz veröffentlicht werden. Mit anderen Worten, du wünscht dir ein OSM/PD. Gibt's aber nunmal nicht. (Aber natürlich steht es jedem frei, etwas derartiges ins Leben zu rufen...) Ich finde man kann nicht davon ausgehen, dass jeder der gerne CC0 hätte, automatisch auch die ODbL gut finden muss oder die Lizenz ganz egal ist. Dann müsste man ja nicht für CC0 sein. Bei den jetzigen Abstimmungsmöglichkeiten fallen alle die aus irgendeinem Grund ablehnen aber PD trotzdem gut finden, komplett unter den Tisch. Ein Lizenzwechsel zu PD stand, wenn ich mich recht erinnere, nie zur Diskussion. Es gibt die Option, damit man angeben kann, dass man gerne PD hätte. Wenn das aber nur geht, wenn man für die ODbL ist, wird das Ergebnis verfälscht. Gruß ___ 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] Durchgehende Mittellinie
steffterra wrote: >[Vieles] Irgendwie denkst Du an bestimmten Punkten anders als ich. Ich verstehe Deine Auffassung in Teilen nicht und umgekehrt. Es scheint momentan nicht zu gelingen, diese Punkte auf dem Weg der gesschriebenen Kommunikation ausfindig zu machen. Da mir die Formulierung noch längerer Texte zu mühsam wird, gebe ich hier auf. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Route-Relationen und TMC:Segments
fly schrieb: > Hi > > In manchen Gegenden werden die Route-Relationen doppelt eingetragen wobei eine > aus den gesamten Wegen besteht (alte Version) und eine aus den TMC:Segmenten > der > Route (neu). > In anderen Gegenden werden die Wege einfach durch die TMC-Segmente ersetzt. > > Auf meine Frage nach Ersetzen von Elementen durch Teil-Relationen habe ich bei > tagg...@osm leider nur eine kurze Antwort erhalten. > Somit nochmal meine Fragen: > > 1. Ist es OK, wenn ich die Wege durch Teilrelationen ersetze und muß der type > der gleiche sein ? > 2. Ist es möglich TMC:Segmente zu verwenden (kann ja auch type=route anstatt > TMC > verwenden - spielt bei TMC keine so wichtige Rolle) > 3. Kann ich in eine Europastraße eine ganze Bundesautobahn einbinden, wenn die > Autobahn komplett auch Europastraße ist. Hat den niemand eine Meinung dazu ? oder wurde diese Diskussion schon geführt ? - Dann bitte link ? Danke Colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Am 18.07.2010 um 15:27 schrieb fly: > Generell halte ich die Diskussion um Newbees und Relationen für fragwürdig. > 1. Existieren immer mehr Relation und man wird damit sehr schnell > konfrontiert, somit sollte man neuen Mitglieder diese eher gut erklären > als zu behaupten, es wäre kompliziert. Ich schrieb ja davon, dass man sowieso Doku lesen muss und sich Hilfe holen sollte. > 2. Probleme sehe ich eher bei den Editors als den Mappern. Leider können > die Editors häufig nicht gut mit Relationen umgehen.(bearbeiten/darstellen) Auch diese sollten sich erfahrenen Usern anschließen, wenn sie es anhand von Doku nicht herausfinden wie es geht. Oder vorerst die Finger von Objekten lassen, die Teil einer Relation sind und sich vor einem erneuten Versuch weiterbilden. > Als ich vor ca. 1 Jahr neu dazu kam, gab es leider noch weniger > Dokumentation. Trotzdem war ich recht schnell mit route-Relationen > konfrontiert. Schon beim Einfügen einer Abbiegespur mußte ich Relationen > bearbeiten. > > Zu der Zeit existierten zusätzlich noch einige Bugs in JOSM, wodurch ich > auch eine Relationen beschädigte. Darauf wurde ich von zwei erfahreneren > Benutzern hingewiesen und wir haben die Fehler gemeinsam behoben. > > Diese Probleme haben mir als neues Mitglied sehr geholfen Erfahrungen > und Verständnis zu gewinnen und zusätzlich in einer Gegend ohne > user-group erste Kontakte zu lokalen Mappern ermöglicht. > > Als Anfänger macht jeder Fehler, aber gerade dadurch kann man auch viel > lernen. Kann ich Dir nur zustimmen und ist auch meine persönliche Erfahrung. Doch speziell beim Thema Adresse/Hausnummerntagging gibt es einen Unterschied zu anderen Relationen: Liebe Diskussionsteilnehmer :-) ->>> Hausnummern werden dringender als alles andere in OSM benötigt. Es gibt immer mehr Anwendungen (u.a. OSM-Router) die unter großem Konkurrenzdruck durch das kostenlose Google-Turn-by-Turn-Routing stehen und OSM _noch_ als die bessere Alternative ansehen und deshalb nicht die Flinte ins Korn werfen, sondern weiter auf OSM bauen. Das Überleben für diese ist nicht leicht. Kommerziell wie nichtkommerzielle OSM-Routinganwendungen haben zur Zeit echt zu kämpfen. Bitte helft doch mit, OSM gerade durch seinen Mehrwert gegenüber Google&Co. konkurrenzfähig zu halten/machen und unterstützt das Adress-Tagging wo es geht. Relationen kann man machen, aber Full-addr:-key-Tagging auch. Letzteres ist für Neuuser faktisch die beste und einfachste Möglichkeit, schnell direkt nutzbare Ergebnisse zu erzielen. Und diese Möglichkeit sollte man ihnen nicht nehmen, indem man ihnen den Einstieg in OSM übers Hausnummern-Taggen durch Relationen _unnötig_ erschwert. Daher rührt mein Engagement für full-addr:-key-Tagging und gegen Relationen _bei Neuusern_. Denn auf die sind wir angewiesen und sie werden über die Anwendungen auch kommen. So wie beim maxspeed-tag auch: Aus dem Anwender eines OSM-Navi zum OSM-Mapper. Das Userpotential gilt es zu nutzen und nicht abzuschrecken. Werbt dafür, dass Neuuser es superleicht haben, Addressen zu taggen, anstatt sie gleich zu Anfang mit Relationen zu demotivieren. Gebt ihnen die einfache Variante an die Hand! Wenn die Daten in DE erstmal genauso vorhanden sind , wie Straßen, kann man immer noch darüber nachdenken, "alle Addr-tags" in Reltionen umzutaggen, (für die Redunzanreduzierung der db) was für einen Bot nicht allzu schwer sein sollte, wenn die Addr-Nodes und Gebäude in korrekter Straßenschreibweise mit PLZ, etc. im full-addr:-key-Tagging erfasst wurden. ->>> Aber lasst es sie doch erstmal tun um Himmels willen! <<<- Es gibt kein richtig oder falsch, beides ist möglich und nicht falsch. Darf man da nicht das eine Verfahren für Neuuser empfehlen und das andere für erfahrene User??? Bitte - besonders im oben dargestellten Kontext! Überlasst nicht google das Feld sondern erleichtert es Neueinsteigern in OSM Hausnummern einzutragen! steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgehende Mittellinie
Am 18.07.2010 um 16:06 schrieb Tirkon: > steffterra wrote: > >> [Vieles] > > Irgendwie denkst Du an bestimmten Punkten anders als ich. Ich verstehe > Deine Auffassung in Teilen nicht und umgekehrt. Es scheint momentan > nicht zu gelingen, diese Punkte auf dem Weg der gesschriebenen > Kommunikation ausfindig zu machen. Da mir die Formulierung noch > längerer Texte zu mühsam wird, gebe ich hier auf. Dennoch war ich immer interessiert an Deiner Meinung. Schade, aber ich verstehe Dich und mir geht es ähnlich. Manchmal endet die Diskussionsgrundlage bei der Textform, stimmt. Falls Du dennoch Interesse am weiteren Meinungsaustausch diesbezüglich hast, kannst Du mich ja auch gerne per eMail und dann per chat kontaktieren. Ich zeichne auch gerne das eine oder andere auf, falls das zum Verständnis beiträgt. Grüße und danke für den regen Gedankenaustausch, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Manuel Reimer glaubte zu wissen: > Sebastian Hohmann wrote: >> Letzlich wird durch eine virale Lizenz nicht erreicht, dass "etwas >> zurückgegeben" wird, wenn ein Unternehmen von OSM profitiert, sondern >> nur wenn es auch eigene Daten reinmischen muss. > > Stimmt. So hatte ich das ursprünglich auch gemeint, aber nicht > geschrieben ;-) > >> Wenn aber einem Unternehmen der Aufwand zu groß ist die Daten >> bereitzustellen oder sogar garnicht dazu in der Lage ist, weil die Daten >> vielleicht jemand anders gehören, dann wird es OSM eben garnicht nutzen. > > Mir persönlich ist es in diesem Fall lieber, wenn ein solches > Unternehmen die Daten nicht nutzt. Nach einer Marktanalyse wird dieses > Unternehmen vielleicht feststellen, dass es sich den Aufwand, die Daten > bereitzustellen, doch leisten kann. > > Das Ziel soll ja schließlich nicht sein, den "armen Unternehmern" > möglichst viele Kosten abzunehmen. Den Aufwand, die veränderten Daten > zurückzuführen, kann man jemandem, der sonst keine Lizenzkosten zahlen > muss, wohl durchaus zumuten. Mir gefällt das Prinzip der freien Daten, die *jeder* nutzen darf, so er Veröffentlichung die Quelle angibt und keinem anderen die Nutzung verbieten darf. Egal ob der Nutzer die alte Oma von nebenan ist oder ein Weltkonzern (unabhängig davon, ob ich den Konzern leiden kann oder nicht). Und unabhängig davon, ob da etwas zurückgegeben wird oder nicht. flo -- Wer meint alles im Griff zu haben, klammert sich in Wahrheit nur an bestimmten sachen fest. [WoKo in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel
Am 18.07.2010 13:07, schrieb Florian Gross: Ich glaube, daß zumindest einige der laufenden Diskussionen schädlicher sind als der Verlust einiger Daten. Zumindest mich nerven solche Streitereien extrem. Ich empfinde es nur bedingt als Streitereien. Was die Notwendigkeit eines Lizenzwechsels angeht fühle ich mich trotz extremer Skepsis inzwischen eher überzeugt. In keiner Weise bin ich jedoch von der bisherigen Migrationsstrategie überzeugt. Hier habe ich das Gefühl, daß man über Allgemeinplätze "wird schon" noch nicht hinausgekommen ist. Erst wenn ich davon überzeugt bin, daß - die neue Lizenz unabdingbar ist und - wenn sichergestellt ist, daß nicht Mannjahre Arbeit leichtfertig verloren gehen bin ich bereit einem Lizenzwechsel zuzustimmen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Am 18.07.2010 15:27, schrieb fly: > Generell halte ich die Diskussion um Newbees und Relationen für fragwürdig. > 1. Existieren immer mehr Relation und man wird damit sehr schnell > konfrontiert, somit sollte man neuen Mitglieder diese eher gut erklären > als zu behaupten, es wäre kompliziert. Ich finde nicht, dass jeder, der in OSM mal eine Hausnummer eintragen will, gleich zum Mapping-Profi ausgebildet werden muss. Es sollte m.E. durchaus einen Platz in OSM für Leute geben, die gar nicht allzu tief eintauchen möchten, sondern nur ein paar Geschäfte und Hausnummern in ihrer Umgebung eintragen wollen. Brauchen können wir solche Beiträge definitiv. Für eine solche Zielgruppe stimmt dein Argument, dass man sich früher oder später eh mit Relationen beschäftigen muss, eben nicht. Wer nicht mehr machen will, als Änderungen nach Art der oben genannten einfachen Aufgaben, für den reichen Punkte und Polygone völlig aus. > 2. Probleme sehe ich eher bei den Editors als den Mappern. Leider > können die Editors häufig nicht gut mit Relationen umgehen. > (bearbeiten/darstellen) Tags sind eben unschlagbar einfach: Zu bearbeitendes Objekt in einer Kartendarstellung anklicken, Eigenschaften in einer Tabelle ändern. Daran werden auch bessere Editoren im Grundsatz nichts ändern können. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
ant schrieb: On 18.07.2010 04:06, Sebastian Hohmann wrote: ant schrieb: On 17.07.2010 11:47, Sebastian Hohmann wrote: Wenn ich jemanden meine Daten geben und sagen "das steht unter der CC0", dann darf er sie natürlich beliebig lizenzieren, auch ohne sie vorher zu veröffentlichen. Nur möchte ich meine Beiträge schließlich der Allgemeinheit zur Verfügung stellen,nicht der OSMF, die es dann direkt in ODbL umlizenziert. Du möchtest deine Beiträge der Allgemeinheit zur Verfügung stellen, aber nicht der OSMF? Das musst du mir mal erklären. Gerne. Ich möchte es als PD allen zur Verfügung stellen, nicht NUR der OSMF, die es dann direkt umlizenziert und erst dann veröffentlicht. Es geht um das Argument, wer seine Daten als PD ansieht habe automatisch auch kein Problem damit, wenn sie NUR unter einer anderen Lizenz veröffentlicht werden. Mit anderen Worten, du wünscht dir ein OSM/PD. Gibt's aber nunmal nicht. (Aber natürlich steht es jedem frei, etwas derartiges ins Leben zu rufen...) Ich spreche damit vor allem an, dass man der ODbL zustimmen muss um sich PD zu wünschen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mapgen Windows-Installation - Geo::Proj4
Hallo, ich versuche gerade, mapgen auf meinem Windows-Rechner zu installieren. Was ich bisher getan habe: * Strawberry Perl installiert * mapgen-Files heruntergeladen * cpan install Math::Polygon -> meldet ok * cpan install GD::graph3d -> meldet ok * cpan install Geo:Proj4 -> folgende Fehlermeldung: --- Running install for module 'Geo::Proj4' Running make for M/MA/MARKOV/Geo-Proj4-1.01.tar.gz Checksum for C:\Programme\strawberry\cpan\sources\authors\id\M\MA\MARKOV\Geo-Pro j4-1.01.tar.gz ok CPAN.pm: Going to build M/MA/MARKOV/Geo-Proj4-1.01.tar.gz ERROR: proj library version not known Warning: No success on command[C:\Programme\strawberry\perl\bin\perl.exe Makefile.PL] MARKOV/Geo-Proj4-1.01.tar.gz C:\Programme\strawberry\perl\bin\perl.exe Makefile.PL -- NOT OK Running make test Make had some problems, won't test Running make install Make had some problems, won't install Failed during this command: MARKOV/Geo-Proj4-1.01.tar.gz : writemakefile NO 'C:\Programme\strawberry\perl\bin\perl.exe Makefile.PL' returned status 6400 --- Der Aufruf von mapgen funktioniert dann natürlich auch nicht: O:\OSM\mapgen>perl mapgen.pl Can't locate Geo/Proj4.pm in @INC (@INC contains: C:/Programme/strawberry/perl/s ite/lib C:/Programme/strawberry/perl/vendor/lib C:/Programme/strawberry/perl/lib .) at OSM/mapgen.pm line 41. BEGIN failed--compilation aborted at OSM/mapgen.pm line 41. Compilation failed in require at mapgen.pl line 92. BEGIN failed--compilation aborted at mapgen.pl line 92. Leider bin ich mit Perl nicht allzu vertraut - wie bekomme ich Geo::Proj4 installiert? tia Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Hallo Sebastian, dass man der ODbL zustimmen muss um sich PD zu wünschen. Man kann sich doch gleich PD wünschen... 43% haben sich bei der letzten Umfrage sowieso schon für PD ausgesprochen. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Hallo Christian, hallo Stefan, unsere Datenbank ist frei verfügbar wie Wasser, Sand oder Luft Solange dieser Freiheit keine ernstliche Gefahr droht Das mit der Freiheit ist nicht so trivial... Darüber haben sich die Phlosophen dieser Welt seit Jahrhunderten viele Gedanken gemacht und konnten sich noch nicht wirklich einigen. Sicher ist: es gibt nicht "die Freiheit". Sondern nur Freiheit für bestimmte Personen in bestimmten Situationen für bestimmte Aktionen. Und jede genutzte Freiheit hat unmittelbare und mittelbare Auswirkungen auf die Freiheit der jeweils direkt und indirekt Beteiligten und Betroffenen. Hat also viel zu tun mit Macht und Moral. Das gilt nicht nur für Wasser, Sand und Luft, sondern auch für unsere Daten. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Erst einmal bin ich dankbar, dass das Problem von den bisher Mitpostenden als solches erkannt wurde. Beim ersten Anlauf hier vor einiger Zeit hatte ich es offensichtlich nicht deutlich machen können und war nicht erfolgreich. Frederik Ramm wrote: >> Wenn eine Funktion so zerstörerisch sein kann und sämtlichen >> sorgfältig erstellten Richtungstaggings und -Relationen quasi den >> Arsch unter den Füßen wegzieht > >Du meinst "den Boden unter den Fuessen wegzieht"? Eigentlich hätten es die Füße sein sollen, die - ähnlich wie bei Glatteis - unter dem Allerwertesten weggezogen werden. Aber Deine stubenreine Formulierung passt natürlich auch. >Deswegen sollten richtungsabhaengige Tags auf ein absolutes Minimum >reduziert werden. "oneway" ist ok, das ist auch in der Karte durch einen >Pfeil sichtbar, da passieren nicht so viele versehentliche Fehler. Bei >allem anderen sollte man mal gruendlich nachdenken, ob es nicht andere >Moeglichkeiten gibt, als sich an der Richtung des Ways zu orientieren. Hmm, das klingt als ob Du da einen Ansatz im Ärmel hättest. Linienbündel würden in vielen Fällen helfan, aber da gibt es nur einige Ansätze mit teilweise aufwendigen Relationen aber kein zu Ende gedachtes Konzept. Und ohne entsprechenden Editor zum Zusammenklicken der Spuren nur ein Fall für Spezialisten. >> Welcher von beiden wäre zu bevorzugen? > >Keiner. Anstatt ein immer engeres Korsett zu bauen, innerhalb dessen die >Editoren - von denen es viele gibt, und von denen nie alle sich einig >sein werden - Benutzern Vorschriften machen, sollte man sich Methoden >fuer das Tagging ueberlegen, die weniger fragil sind. Das wäre natürlich viel besser, als meine Vorschläge. Auch das klingt, als wenn Du noch ein Ass auzuspielen hättest. Es könnte vielleicht ein durchsichtiges und einheitliches Mittel geben, das immer funktioniert und jedem Tag und jeder Relation eine Richtung aufprägen könnte. In der Praxis könnte das so aussehen, dass der Editor eine Richtung vorgibt, die man umdrehen kann - genau so, wie es derzeit bei den Wegen geschieht. >Worueber man allerdings fuer eine Uebergangszeit mal nachdenken koennte, >ist, die Way-Umdreh-Funktion in JOSM etwas mehr zu verstecken. >Vielleicht in einem Untermenue "Advanced..." oder sowas. Damit man nicht >so leicht versehentlich draufklickt ;) Wobei zumindest Potlatch als verbreitet genutzter Editor da auch mitspielen müsste. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Behindertenparkplatz
Hallo zusammen, Ich bastle zur Zeit an einer Karte für Rollstuhlfahrer. Nun gibt es in Städten häufig einzelne Parkplätze, auf welchen nur Behinderte parken dürfen. http://wiki.openstreetmap.org/wiki/File:Behindertenparkplatz_Stampfenbach.jpg Wie sollen diese Parkplätze getagged werden? Gegen amenity=parking capacity=1 capacity:disabled=1 sprechen meiner Meinung nach vorallem zwei Dinge: - Häufig stehen diese Parkplätze einzeln, z.B. direkt neben einem Eingang. Laut Wiki sollen mit amenity=parking aber nur grössere Parkplätze gekennzeichnet werden und nicht einzelne. - Auch wenn es nirgends explizit festgehalten ist, so verstehen sowohl die Renderer als auch die Router unter 'amenity=parking' einen Park- platz für 'normale' Autos. Ein Parkplatz für Fahrräder wird daher auch nicht mit als 'parking' mit 'capacity:bicycle=*' getagged sondern als 'amenity=bicycle_parking'. Mein Ziel ist es aber nicht, dass die Karte mit P-Symbolen zuge- pflastert weil die Berechnung ob es sich um einen reinen Behinderten- Parkplatz handelt zu kompliziert ist. Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 ? (Natürlich kann und soll man bei einem grossen Parkplatz/-haus weiterhin ein capacity:disabled setzen!) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Thomas, > -Ursprüngliche Nachricht- > Von: talk-de-boun...@openstreetmap.org > Thomas Ineichen schrieb am: Sonntag, 18. Juli 2010 17:21 > Betreff: [Talk-de] Behindertenparkplatz > > Hallo zusammen, > > Ich bastle zur Zeit an einer Karte für Rollstuhlfahrer. Nun gibt es in Hast Du dazu mehr Infos? Ich integriere aktuell in Augsburg viele Informationen hierfür [1] und wäre an einer gemeinsamen Karte interessiert, habe auch mit Osmarender Renderdateien begonnen. > Städten häufig einzelne Parkplätze, auf welchen nur Behinderte parken > dürfen. > http://wiki.openstreetmap.org/wiki/File:Behindertenparkplatz_Stamp > fenbach.jpg > > > Wie sollen diese Parkplätze getagged werden? > > Gegen > > amenity=parking > capacity=1 > capacity:disabled=1 > > sprechen meiner Meinung nach vorallem zwei Dinge: > > - Häufig stehen diese Parkplätze einzeln, z.B. direkt neben einem > Eingang. Laut Wiki sollen mit amenity=parking aber nur grössere > Parkplätze gekennzeichnet werden und nicht einzelne. > > - Auch wenn es nirgends explizit festgehalten ist, so verstehen sowohl > die Renderer als auch die Router unter 'amenity=parking' einen Park- > platz für 'normale' Autos. Ein Parkplatz für Fahrräder wird daher > auch nicht mit als 'parking' mit 'capacity:bicycle=*' getagged > sondern als 'amenity=bicycle_parking'. Sehe ich nicht so. Ich würde auch einen Parktplatz mit nur wenige Plätzen markieren, wenn weit und breit keine andere Möglichkeit besteht. Die Autos für Rollstuhlfahrer sind schon noch relativ normal ;) Es ist einfach wichtig, diese Parkmöglichkeiten zu taggen, weil meist nur wenige vorhanden in einem größeren Umkreis. Die tagge ich, wie von Dir oben beschrieben, auch wenn der Parkplatz direkt an der Straße ist und nur 1 Parkplatz umfasst. > Mein Ziel ist es aber nicht, dass die Karte mit P-Symbolen zuge- > pflastert weil die Berechnung ob es sich um einen reinen Behinderten- > Parkplatz handelt zu kompliziert ist. Die Berechnung ist total einfach und mich juckt es nicht, ob die dann in den Standardkarten zu oft vorkommen (wird kaum passieren). Wir erfassen nicht für die Renderer, üblicher Spruch dazu ;) > Daher: Irgendwelche Einwände gegen > > amenity=disabled_parking > capacity=1 Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. Der einzige Grund ist das Rendern in normalen Karten. Wenn Du das nicht möchtest, erstell ein entsprechendes Ticket beim Renderer-System. Oder besser: erstelle ein Ticket, damit die Rolli-Parkplätze mit extra Symbolen versehen werden. Ich habe entsprechende verfügbar, die ein normales P-Icon beinhalten mit dem Rolli-Symbol zusätzlich rechts davon. Grüße Dietmar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
der fehlende Link in meinem Posting eben folgt unten > Dietmar schrieb am: Sonntag, 18. Juli 2010 17:48 > Betreff: AW: [Talk-de] Behindertenparkplatz > > Hast Du dazu mehr Infos? Ich integriere aktuell in Augsburg viele > Informationen hierfür [1] und wäre an einer gemeinsamen Karte [1] http://wiki.openstreetmap.org/wiki/Augsburg/Datenspende_Stadtplan_für_barrie refreie_Mobilität ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 18.07.2010 um 17:20 schrieb Thomas Ineichen : Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 Ja. Es ist ja nicht disabled, sondern für Behinderte. Also was spricht gegen amenity=parking capacity:total=15 capacity:handicap=1 capacity:all=10 capacity:women=2 capacity:family=5 (Anmerkung: gegen ein capacity:normal wehre ich mich, weil das implizieren würde, dass handicap und family, etc. Nicht "normal" wären ;-) steffterra (der hier bisher nicht in bestehenden Proposals recherchiert hat) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel - wer will was
Hallo Markus,
Am 18. Juli 2010 14:00 schrieb Markus :
> Hallo Stefan,
>
> Kollateralschäden durch Datenverluste
>>>
>>> Solange das nicht gelöst ist, wäre ein Lizenzwechsel eine grobe
>>> Missachtung der Arbeit der Freiwilligen.
>>
>> Eine noch größere Missachtung wäre es, die Unzulänglichkeiten der
>> bisherigen Lizenz einfach zu ignorieren
>
> Eben.
> Dafür braucht man:
> a) Fallbeispiele für die jeweiligen Lizenz-Szenarien
> b) Kennzahlen und eine Kosten/Nutzen-Rechnung
>
> Wenn diese den Benutzern verständlich kommuniziert sind,
> kann man sie fragen wie sie es denn gerne hätten.
Meine Vermutung:
3/8 wollen PD
3/8 wollen SA
1/8 will NC
1/8 nichts, oder was anderes.
>
>>> Vorschlag:
>>> In die Editoren wird eine Auswahlliste eingebaut:
>>> - mein Beitrag ist frei: "Public Domain"
>>> - mein Beitrag soll CC-by-SA sein
>>> - mein Beitrag soll ODbL sein
>>> - ich verstehe die Unterschiede nicht, macht was ihr wollt
>>
>> Möglichkeit 4 wäre gleich Möglichkeit 1
>
> Nein, es ist ein grosser Unterschied, ob ich das was die "Oberen" wollen
> verstanden habe und mich für "PD" entscheide (oder etwas anderes) - oder ob
> ich nichts veststanden habe und mich deshalb auch nicht mündig für etwas
> entscheiden kann.
Da sollte sich schon jeder Gedanken drüber machen - ob man PD oder SA
/ by oder etwas anders will, muss jeder für sich entscheiden - genau
genommen sollte man mit dieser Entscheidung durch sein, bevor man
etwas bei OSM eingibt. Anschließend sollte man sich aber auch darauf
verlassen können, dass wo by-SA draufsteht auch by-SA drin ist und
keine Mogelpackung, die anderswo als PD angeboten werden kann.
>
>> CC-by-SA klappt für unsere Daten nicht
>
> Wieso? es "klappt" doch seit Jahren...
>
http://www.osmfoundation.org/wiki/License/Why_CC_BY-SA_is_Unsuitable
>> PD Daten kann man in die ODbL übernehmen...
>
> Ja, auch in /jede/ andere Lizenz - aber sie bleiben trotzdem PD :-)
>
>>> Damit hätte man gleich zwei Dinge erreicht:
>>> 1. eine individuelle Attributierung für jede Datenänderung
>>> 2. eine kontinuierliche Umfrage, wer denn was will
>>
>> Man hätte nur eins erreicht - 2 Datensätze: Einen kleineren PD und
>> einen größeren unter der ODbL.
>
> Hm - nach einer Umfrage sind 43% für PD.
>
Man kann diese (inoffizielle und unverbindliche) Doodle Umfrage auch
erstmal so verstehen, das 75% _nicht gegen_ den Wechsel sind.
Die Umfrage unter den OSMF Members[1] zeigt bei der Frage PD/SA ein
anderes Bild und deutliche Zustimmung zu by bzw SA:
Insgesamt waren 89% dafür, mit dem Wechsel fortzufahren.
Für PD (kein by auf der Database) waren aber nur 11%. Der Anteil der
PD Befürworter ist also genauso hoch wie der die einen Wechsel
grundsätzlich ablehnen.
Not
Wanting Wanting
Require BY on Database: 14 110
Require SA on Database: 31 86
Require BY on Produced Works: 21 91
Require SA on Produced Works: 67 28
Require NC:1285
Der ODbL Kompromiss (by-SA für die Datenbank, nur by für die Produced
Works) ist damit genau das, was eine Mehrheit der OSMF Mitglieder
befürwortet.
> Und ich vermute, wenn die Frage etwas differenzierter gestell wird,
> und unsinnige Koppelfragen aufgedröselt werden,
> dann werden sich weitere OSMer für PD entscheiden.
>
>> Zusätzlich hätte man alle Leute die
>> CC-by-SA ankreuzen gründlich verarscht.
>
> Irgendwie scheint mir, als sei das ganze Lizenzgedöns der letzten Jahre eine
> einzige "Verarsche". Nicht weil das jemandes Absicht gewesen wäre, sondern
> weil man "die Freie Weltkarte" versucht hat in ein juristisches Korsett zu
> pressen, und dabei auch noch unserer eigenen Eitelkeit ("meine Daten")
> dienen wollte. Und weil man uns immer versichert hat, das sei "das Beste für
> uns"...
Man ließt doch häufig Flames von SA-Fans, die fürchten, dass Evil inc.
mit ihren Daten $$$ verdient und ihnen nichts zurückgibt.
Eitelkeit mag dabei eine Rolle spielen, aber auch Pragmatismus: Man
kann zwar auf das Gute hoffen, aber verlassen will man sich doch
lieber nicht darauf.
>
> Ich kann mir schwer vorstellen, dass das neue Korsett besser wäre.
> Und der damit verbundene Datenverlust ist durch nichts zu rechtfertigen.
Doch - man kann das damit rechtfertigen, dass man einen rechtssicheren
by-SA Datensatz möchte. Wenn dir eine andere Lizenz lieber ist, dann
hindert dich doch niemand daran, deine Daten zusätzlich unter der
beer-ware Licence, BSD-Style oder PD freizugeben. OSM ist allerdings
als by-SA Projekt gestartet, und soll es nach dem Willen der Mehrheit
der OSMF Mitglieder auch bleiben - und das nicht nur als
Lippenbekenntnis mit einer Lizenz, die nicht funktioniert, sondern
rechtssicher.
>
> Gruss, Markus
Gruss,
Stefan
[1]http://lists.openstreetmap.org/pipermail/osmf-talk/2009-December/000753.html
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Am 18.07.2010 16:52, schrieb Sebastian Hohmann: > Ich spreche damit vor allem an, dass man der ODbL zustimmen muss um sich > PD zu wünschen. Die Lizenzfrage ist nicht vorrangig als Abstimmung über die Zukunft des Projekts gedacht. Insofern bedeutet eben, dass jemand der seine Edits als CC0/PD ansieht, dass er damit automatisch jeder weiterlizenzierung zustimmt. Natürlich wünsche ich mir als CC0-Verfechter eine Anschlussveranstaltung, in der erörtert wird, ob die CC0 als Lizenz in Frage kommt, und ob genügend Mapper dem zustimmen würden. -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0901°N 8.7868°E Ceterum censeo Carthaginem esse delendam. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am Sonntag 18 Juli 2010, 17:51:01 schrieb steffterra: > Am 18.07.2010 um 17:20 schrieb Thomas Ineichen : > > Daher: Irgendwelche Einwände gegen > > > > amenity=disabled_parking > > capacity=1 > > Ja. Es ist ja nicht disabled, sondern für Behinderte. > disabled ist aber durchaus mit der gaengigste Begriff fuer Behinderte... > Also was spricht gegen > amenity=parking > capacity:total=15 > capacity:handicap=1 > capacity:all=10 > capacity:women=2 > capacity:family=5 > > (Anmerkung: gegen ein capacity:normal wehre ich mich, weil das > implizieren würde, dass handicap und family, etc. Nicht "normal" > wären ;-) > d.h. dein all ersetzt normal? find ich irgendwie komisch. es reicht doch, die Summe anzugeben und die jeweils vorhandenen speziellen Parkplaetze. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Markus schrieb: Hallo Sebastian, dass man der ODbL zustimmen muss um sich PD zu wünschen. Man kann sich doch gleich PD wünschen... Wie? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postleitzahlen-Import
Am Sonntag 18 Juli 2010, 11:01:32 schrieb Frederik Ramm: > Ist aber m.E. nicht so schlimm, weil der Import eh furchtbare Handarbeit > ist, da ist eine kleine Verschiebung der Ways in JOSM noch das geringste > Uebel. Wenn du eine automatische Korrektur (bis zu einem Grad, der akzeptable Qualität verspricht) nicht für möglich hältst, würde vielleicht der Weg von strassen.nrw schneller zum Ziel führen. Einfach OSM-Files für die einzelnen Postleitzahlengebiete erzeugen und irgendwo nen WMS-Layer einrichten. Ich würde mich gerne hinsetzen und diese Grenzen in meiner Gegend so verschieben bis es passt. Kleiner Gedankengang von nem absoluten Laien auf dem Gebiet der Umsetzung: Ich recht vielen Fällen (AFAIK nicht allen!) sind Postleitzahlen-Grenzen deckungsgleich mit Landkreis-Grenzen. Die Kreisgrenzen haben wir ja schon. Wäre es nich möglich, in der Umgebung einer Kreisgrenze nach Postleitzahlen- Grenzen zu suchen und wenn es einen verdächtig ähnlichen Verlauf gibt, der ~100 Meter versetzt ist, diesen auf die Kreisgrenze verschieben. Dann wäre der übrige Versatz innerhalb des Landkreises vermutlich sehr minimal. Gruß, Bernd -- Die Tabakindustrie hat mehr Menschenleben auf dem Gewissen als die Rüstungsindustrie. - Gerhard Kocher (Schweizer Politologe, Gesundheitsökonom und Aphoristiker) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Dirk-Lüder Kreie schrieb: Am 18.07.2010 16:52, schrieb Sebastian Hohmann: Ich spreche damit vor allem an, dass man der ODbL zustimmen muss um sich PD zu wünschen. Die Lizenzfrage ist nicht vorrangig als Abstimmung über die Zukunft des Projekts gedacht. Sie ist dazu gedacht um unverbindlich seine Meinung ausdrücken zu können, aber gebunden an die Zustimmung der ODbL, was das tatsächliche Ergebnis der Meinungsäußerung verfälschen kann. Nicht nur weil man eventuell die ODbL nicht mag, sondern auch aufgrund von Angst vor Datenverlust, weshalb offenbar ja auch viele dagegen stimmen wollen. Insofern bedeutet eben, dass jemand der seine Edits als CC0/PD ansieht, dass er damit automatisch jeder weiterlizenzierung zustimmt. Genau das bedeutet es eben nicht, jedenfalls ist es nicht Sinn der Sache. Wenn ich mir PD wünsche, dann dass die Daten als PD *veröffentlicht* werden, nicht dass sie direkt in eine komplizierte Lizenz ungewandelt werden. Später kann man dagegen freilich nichts mehr tun, aber einmal sollte es eben in die "Public Domain" entlassen werden. Natürlich wünsche ich mir als CC0-Verfechter eine Anschlussveranstaltung, in der erörtert wird, ob die CC0 als Lizenz in Frage kommt, und ob genügend Mapper dem zustimmen würden. Das hätte man ja eigentlich schon vor Jahren machen können, als klar wurde, dass die CC-BY-SA nicht ganz ideal ist. Dann hätte man sich entweder die jahrelange Arbeit an der ODbL sparen können oder jede Diskussion um PD wäre vom Tisch gewesen. Hätte, wäre, wenn bringt jetzt natürlich nicht viel, aber wenigstens jetzt könnte man eine richtige Umfrage durchführen, auch wenn es keine Umfrage sein soll. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 18.07.2010 um 18:23 schrieb Guenther Meyer : Am Sonntag 18 Juli 2010, 17:51:01 schrieb steffterra: Am 18.07.2010 um 17:20 schrieb Thomas Ineichen >: Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 Ja. Es ist ja nicht disabled, sondern für Behinderte. disabled ist aber durchaus mit der gaengigste Begriff fuer Behinderte... Gängig heißt bei welchen Tags (außer parking) noch? Helfe mir bitte auf die Sprünge mit Beispielen und Wikilinks. Danke. Also was spricht gegen amenity=parking capacity:total=15 capacity:handicap=1 capacity:all=10 capacity:women=2 capacity:family=5 (Anmerkung: gegen ein capacity:normal wehre ich mich, weil das implizieren würde, dass handicap und family, etc. Nicht "normal" wären ;-) d.h. dein all ersetzt normal? Ja, aber "all" meinte nicht alle Parkplätze, sondern "alle dürfen hier parken". Denn auch ein Handicap darf natürlich auf einem "normalen" Parkplatz parken. find ich irgendwie komisch. Stimme ich Dir zu. Weißt du was besseres? Ich mache unten einen neuen Vorschlag. es reicht doch, die Summe anzugeben und die jeweils vorhandenen speziellen Parkplaetze. sodass sich die "normalen" errechnen lassen/müssen? Ok kein Aufwand für Anwendungen. Doch zu einer Aufzählung gehören die "normalen" eigentlich dazu. "capacity:all" ist aber wirklich nicht so gut, da man es mit capacity:total verwechseln könnte. Gut, wie wäre es mit capacity:all_allowed für die "normalen". Klingt doch gar nicht so schlecht, oder? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Am Sonntag 18 Juli 2010, 13:33:26 schrieb Dirk-Lüder Kreie: > Am 18.07.2010 13:18, schrieb Dirk-Lüder Kreie: > > Am 17.07.2010 22:58, schrieb Guenther Meyer: > >> was spricht gegen CC-BY ? > > > > deutsch: > > http://wiki.openstreetmap.org/wiki/DE:The_license,_where_we_are,_where_we > > %27re_going > > http://wiki.openstreetmap.org/wiki/DE:ODbL/We_Are_Changing_The_License > > > > englisch: > > http://www.osmfoundation.org/wiki/License/Why_CC_BY-SA_is_Unsuitable > > CC-Lizenzen sind generell nicht für Datensammlungen geeignet, ausser > CC0, die eben von der Creative-Commons explizit für sowas empfohlen wird. das ist nur dummes Nachgeplapper und beantwortet nicht meine Frage. Also noch mal: Was spricht gegen CC-BY ? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel - wer will was
Markus glaubte zu wissen: > Hallo Christian, >> Vor dem Hintergrund der drohenden Umstellung müsste man beim Mappen jetzt >> schon anders vorgehen. > > Vorschlag: > In die Editoren wird eine Auswahlliste eingebaut: > - mein Beitrag ist frei: "Public Domain" > - mein Beitrag soll CC-by-SA sein > - mein Beitrag soll ODbL sein > - ich verstehe die Unterschiede nicht, macht was ihr wollt - Frag nicht so blöd, LAD ENDLICH HOCH! SCNR! flo -- Wer aus Angst vor möglichen Folgen auf das Antworten in detebe verzichtet, Rolft sich implizit aus detebe. [Christian Pree in detebe] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postleitzahlen-Import
Am 18. Juli 2010 11:01 schrieb Frederik Ramm : > Vorschlaege fuer eine Reprojektion werden dankend entgegengenommen. Ich habe > alles denkbare probiert, kam aber zu keinem brauchbaren Ergebnis. Der > "Drift" ist auch nicht in ganz Deutschland gleich, sonst koennte man das ja > leicht reparieren. Da die Daten von GK über PostGis zu WGS84 transformiert wurden, könnte ein Rücktransformieren und anschließendem Reprojektion mittels besserem Verfahren zum Erfolg fürhen !? Von Sven Geggus wurden da bisweilen sehr gute Ergebnisse erziehlt. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki-Doku zu mapnik-Installation
Am 15.07.2010 11:22, schrieb p.pri...@gmx.de: Hallo zusammen, Ich bin nicht ganz sicher, ob ich hier richtig richtig bin - zumindest einer von Euch wird wissen, wo's hingehört... :-) Seit gut zwei Tagen habe ich versucht die Voraussetzungen zu schaffen, dass ich per mapnik meine Tiles selber rendern kann. Die Dokumentation im Wiki unter http://wiki.openstreetmap.org/wiki/DE:Mapnik hat da schon gut geholfen! Ich kann dir noch dieses Tutorial empfehlen: http://wiki.openstreetmap.org/wiki/DE:HowtoMinutelyHstore Ein VM-Image, welches all dies bereits enthält, ist in Arbeit. Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 18.07.2010 um 18:23 schrieb Guenther Meyer: > Am Sonntag 18 Juli 2010, 17:51:01 schrieb steffterra: >> Am 18.07.2010 um 17:20 schrieb Thomas Ineichen : >>> Daher: Irgendwelche Einwände gegen >>> >>> amenity=disabled_parking >>> capacity=1 >> >> Ja. Es ist ja nicht disabled, sondern für Behinderte. >> > disabled ist aber durchaus mit der gaengigste Begriff fuer Behinderte... Ok hab ich kapiert. Leo sagt ja das "disabled" der "Körperbehinderte" ist. Sorry für meine schlechten Englischkenntisse. >> Also was spricht gegen >> amenity=parking >> capacity:total=15 >> capacity:handicap=1 >> capacity:all=10 >> capacity:women=2 >> capacity:family=5 Sorry. Das kommt davon, wenn man nicht in den Proposals nachschaut. Natürlich will ich das Rad nicht neu erfinden und schließe mich erfreut dem vorhanden Proposal von LuLu-Ann an: http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces Das Proposal könnte noch um passende Symbole für Mapnik/Osmarender oder aus existierenden Verkehrsschildern erweitert werden. Besonders gespannt bin ich dabei auf "capacity:horse" ;-) Danke frü dieses Proposal Lulu-Ann! :-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Hallo, Sebastian Hohmann wrote: Genau, daran sieht man dass PD am wenigsten Probleme verursacht. Man könnte sogar sagen, OSM bedient sich gerne bei PD Daten ohne "etwas zurückzugeben" in Form von genauso "freien" Daten.. ;) Das hatten wir damals ja schon mit dem Geonames-Import. Wir haben fleissig deren Daten genommen und bei uns verbessert, aber die Verbesserungen haben wir nicht zurueckgegeben. 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
Re: [Talk-de] Postleitzahlen-Import
Hallo, André Riedel wrote: Da die Daten von GK über PostGis zu WGS84 transformiert wurden, könnte ein Rücktransformieren und anschließendem Reprojektion mittels besserem Verfahren zum Erfolg fürhen !? Von Sven Geggus wurden da bisweilen sehr gute Ergebnisse erziehlt. Hab ich alles probiert. Die Abweichungen von der Realitaet sind in diesem File deutlich groesser als das, was man durch eine GK-Projektion mit nicht-idealen Parametern erklaeren koennte. Rueckprojizieren nach GK und anschliessendes Vorwartsprojizieren mit den BETA-Parametern bringt nur eine minimale Verbesserung. 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
Re: [Talk-de] Mapnikstyle "Germanica"
Am 10.07.2010 22:56, schrieb Johann H. Addicks: Der Style scheint jedoch keine Eisenbahnen zu mögen: http://toolserver.org/~osm/styles/?zoom=16&lat=50.10627&lon=8.66246&layers=F0FFFBFFF Der Style ist schon ziemlich alt und bedarf einer dringenden verjüngungskur. Es fehlen z.B. auch etliche features. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo steffterra, >> Daher: Irgendwelche Einwände gegen >> >> amenity=disabled_parking >> capacity=1 > Ja. Es ist ja nicht disabled, sondern für Behinderte. Das ist ja jetzt bereits geklärt. > Also was spricht gegen > amenity=parking > capacity:total=15 > capacity:handicap=1 > capacity:all=10 > capacity:women=2 > capacity:family=5 > (Anmerkung: gegen ein capacity:normal wehre ich mich, weil das > implizieren würde, dass handicap und family, etc. Nicht "normal" > wären ;-) Nichts, solange es sich wie in deinem Beispiel um einen grossen Parkplatz handelt. Aber wie ich geschrieben habe, geht es mir um *einzelne* Parkplätze. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 18.07.2010 um 19:58 schrieb Thomas Ineichen: > Nichts, solange es sich wie in deinem Beispiel um einen grossen > Parkplatz handelt. Aber wie ich geschrieben habe, geht es mir um > *einzelne* Parkplätze. Wieso für einzelne Parkplätze ein anderes Tagging-Schema nutzen, wie für kombinierte größere? Die Anzahl von tags/keys sind die gleichen, es ist also kein Mehraufwand und flexibler, sollte sich was ändern, weil der amenity-tag der selbe ist. Ich würde deshalb nach dem Proposal vorgehen (auch wenn es dort nicht explizit erwähnt wird): http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces amenity=parking capacity:disabled=1 oder capacity:disabled=yes für eine unspezifische Anzahl, wenn es sich um mehrere handelt, man aber offen lassen möchte wieviele. (warum man das sollte, weiss ich auch nicht, ausser man weiss es nicht mehr, wenn man am mappen ist) Eine Navi-software, die das nutzen kann, würde dahin routen, wo überhaupt welche vorhanden sind. Wie viele vorhanden sind, ist könnte erstmal egal für den Router sein, wäre aber eine nützliche Zusatzinformation, um die Wahrscheinlichkeit einzuschätzen, einen solchen Parkplatz dort zu ergattern. Denn je mehr vorhanden sind, desto höher ist die Wahrscheinlichkeit, dass einer frei ist, aber das nur nebenbei. Auch finde ich das Proposal an sich sehr gut, weil es ein einheitliches Tagging-Schema bietet. Der tag amenity=disabled_parking ist zwar weit verbreitet, könnte jedoch um das einheitliche Schema leicht ersetzt werden. So vermeidet man für alle Arten von Parkplätzen eigene Tags zu nutzen. Keys sind da flexibler und leichter zu ergänzen. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Dietmar, >> Thomas Ineichen schrieb am: Sonntag, 18. Juli 2010 17:21 >> Ich bastle zur Zeit an einer Karte für Rollstuhlfahrer. Nun gibt es in > Hast Du dazu mehr Infos? Ich integriere aktuell in Augsburg viele > Informationen hierfür [1] und wäre an einer gemeinsamen Karte interessiert, > habe auch mit Osmarender Renderdateien begonnen. Ein Link folgt gleich per PM, da die Karte noch zu sehr im Beta- Stadium ist.. >> Mein Ziel ist es aber nicht, dass die Karte mit P-Symbolen zuge- >> pflastert weil die Berechnung ob es sich um einen reinen Behinderten- >> Parkplatz handelt zu kompliziert ist. > Die Berechnung ist total einfach und mich juckt es nicht, ob die dann in den > Standardkarten zu oft vorkommen (wird kaum passieren). Wir erfassen nicht > für die Renderer, üblicher Spruch dazu ;) Es ist eben nicht total einfach. Falls man 'amenity=parking' *auch* für nur-Behinderten-Parkplätze benutzen möchte, ändert man die Bedeutung des Tags. Im Gegensatz dazu ist 'capacity:disabled=*' bei einem grossen Parkplatz eine *Erweiterung* des Tags. (Das ist so ähnlich wie bei der Diskussion ob eine Fahrschule auch als 'amenity=school' getagged werden soll.) Bisher konnte man sich 'als normaler Autofahrer' darauf verlassen, dass man bei einem Node mit 'amenity=parking' einen Parkplatz findet. Das sollte auch weiterhin so bleiben. Der 'übliche Spruch' wird leider von vielen - auch von Dir - falsch verstanden: http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer Mich juckt es eben, ob in der Stadt Zürich plötzlich 200 neue P auf- blitzen, wenn dort der normale Autofahrer gar nicht parken darf. >> Daher: Irgendwelche Einwände gegen >> >> amenity=disabled_parking >> capacity=1 > Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. *Falls* man die Bedeutung von 'parking' ändert. > Der einzige Grund ist das Rendern in normalen Karten. Wenn Du das nicht > möchtest, erstell ein entsprechendes Ticket beim Renderer-System. Die Darstellung auf Karten und das Routing. Mit anderen Worten: die Hauptnutzungen von OSM. Wenn das mal kein Grund ist.. > Oder besser: erstelle ein Ticket, damit die Rolli-Parkplätze mit extra > Symbolen versehen werden. Ich habe entsprechende verfügbar, die ein normales > P-Icon beinhalten mit dem Rolli-Symbol zusätzlich rechts davon. Eine Karte kann auch *zu* viel Information anzeigen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Frederik Ramm glaubte zu wissen: > Tirkon wrote: >> Wenn eine Funktion so zerstörerisch sein kann und sämtlichen >> sorgfältig erstellten Richtungstaggings und -Relationen quasi den >> Arsch unter den Füßen wegzieht > > Du meinst "den Boden unter den Fuessen wegzieht"? > > JOSM ist ja mittlerweile so schlau und empfiehlt beim Aendern der > Richtung eines Ways, auch die entsprechenden richtungsabhaengigen Tags > umzudrehen. Vor einigen Wochen war JOSM dabei richtig konsequent und wollte mir aus uploaded_by ein downloaded_by machen ;-) flo -- Statt daß er endlich einmal ein friedliches Leben führen könnte, wird er immer wieder von ehrgeizigen und sich selbst überschätzenden Grünschnäbeln, die gerade mal gelernt haben einen Colt zu laden, dreist angemacht.[Sepp Neuper in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Am 18.07.2010 um 16:41 schrieb Tobias Knerr: > Am 18.07.2010 15:27, schrieb fly: >> Generell halte ich die Diskussion um Newbees und Relationen für fragwürdig. >> 1. Existieren immer mehr Relation und man wird damit sehr schnell >> konfrontiert, somit sollte man neuen Mitglieder diese eher gut erklären >> als zu behaupten, es wäre kompliziert. > > Ich finde nicht, dass jeder, der in OSM mal eine Hausnummer eintragen > will, gleich zum Mapping-Profi ausgebildet werden muss. Es sollte m.E. > durchaus einen Platz in OSM für Leute geben, die gar nicht allzu tief > eintauchen möchten, sondern nur ein paar Geschäfte und Hausnummern in > ihrer Umgebung eintragen wollen. Brauchen können wir solche Beiträge > definitiv. > > Für eine solche Zielgruppe stimmt dein Argument, dass man sich früher > oder später eh mit Relationen beschäftigen muss, eben nicht. Wer nicht > mehr machen will, als Änderungen nach Art der oben genannten einfachen > Aufgaben, für den reichen Punkte und Polygone völlig aus. > >> 2. Probleme sehe ich eher bei den Editors als den Mappern. Leider >> können die Editors häufig nicht gut mit Relationen umgehen. >> (bearbeiten/darstellen) > > Tags sind eben unschlagbar einfach: Zu bearbeitendes Objekt in einer > Kartendarstellung anklicken, Eigenschaften in einer Tabelle ändern. > > Daran werden auch bessere Editoren im Grundsatz nichts ändern können. Dann ergänze ich diesen Sachverhalt auch mal im Wiki. Sollte der leichteren Orientierung für Neuuser dienlich sein, für welches Verfahren sie sich entscheiden, um das taggen von Adressen grunsätzlich zu fördern. (siehe mein Plädoyer in meiner vorherigen mail an die Liste) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 18.07.2010 um 20:16 schrieb Thomas Ineichen: > Hallo Dietmar, > ... > Es ist eben nicht total einfach. Falls man 'amenity=parking' *auch* > für nur-Behinderten-Parkplätze benutzen möchte, ändert man die > Bedeutung des Tags. Warum. Es ist erstmal ein Parkplatz. Punkt. Und für wen er ist, wird im key angeben. Wo ist das Problem dieses einheitlichen, verständlichen Schemas? > Im Gegensatz dazu ist 'capacity:disabled=*' bei > einem grossen Parkplatz eine *Erweiterung* des Tags. (Das ist so > ähnlich wie bei der Diskussion ob eine Fahrschule auch als > 'amenity=school' getagged werden soll.) Auch da sehe ich es genauso. Wo ist das problem, im key anzugeben, welche Schule es ist? Grundschule, Gesamtschule, Fahrschule ... > Bisher konnte man sich 'als normaler Autofahrer' darauf verlassen, > dass man bei einem Node mit 'amenity=parking' einen Parkplatz findet. > Das sollte auch weiterhin so bleiben. Warum sollte das anders sein? key auswerten und man weiss auch für wen der Parkplatz ist. > Der 'übliche Spruch' wird leider von vielen - auch von Dir - falsch > verstanden: > http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer Ich weiss, Du meintest nicht mich persönlich. Aber genau das wäre Dein vorgehen doch. Nur weil der Renderer derzeit alle Parkplätze mit demselben Icon versieht, gibt es keinen Grund, nach einem gesunden Schema zu taggen. Der Render wird sich darauf einstellen und für jeden key ein anderes Icon einbauen, um das Parken transparenter zu machen. > Mich juckt es eben, ob in der Stadt Zürich plötzlich 200 neue P auf- > blitzen, wenn dort der normale Autofahrer gar nicht parken darf. Das ist ein Problem des Renderers, nicht des taggens. >>> Daher: Irgendwelche Einwände gegen >>> >>> amenity=disabled_parking >>> capacity=1 > >> Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. > > *Falls* man die Bedeutung von 'parking' ändert. Was sollte sich ändern. Parken ist parken. Und wer parken darf, wird im key angeben, udn sogar im gleichen key zusätzlich noch wie viele Parkplätze vorhanden sind. Das kann ein einzelner sein, oder gemischt mit anderen keys jeweils hunderte. >> Der einzige Grund ist das Rendern in normalen Karten. Wenn Du das nicht >> möchtest, erstell ein entsprechendes Ticket beim Renderer-System. +1 > Die Darstellung auf Karten und das Routing. Mit anderen Worten: die > Hauptnutzungen von OSM. Wenn das mal kein Grund ist.. Es hindert aber auch die Renderer und Routing-Software nicht daran, den key auszuwerten. (Nebenbei erwähnt vereinfacht das einheitliche Tagging für Großparkplätze und Einzelparkplätze den Algorithmus ja sogar, da nciht weitere Tags für Einzelparkplätze untertstützt werden müssten) >> Oder besser: erstelle ein Ticket, damit die Rolli-Parkplätze mit extra >> Symbolen versehen werden. Ich habe entsprechende verfügbar, die ein normales >> P-Icon beinhalten mit dem Rolli-Symbol zusätzlich rechts davon. > > Eine Karte kann auch *zu* viel Information anzeigen. dafür gibt es ja das "+" am rechten Rand guter openlayer-Karten ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am Sonntag 18 Juli 2010, 20:16:29 schrieb Thomas Ineichen: > Es ist eben nicht total einfach. Falls man 'amenity=parking' *auch* > für nur-Behinderten-Parkplätze benutzen möchte, ändert man die > Bedeutung des Tags. Und w aendert man hier die Bedeutung? Sind Behindertenparkplaetze etwa keine Parkplaetze? > Im Gegensatz dazu ist 'capacity:disabled=*' bei > einem grossen Parkplatz eine *Erweiterung* des Tags. > es ist eine genauere Spezifizierung. Ich sehe da kein Problem. > Bisher konnte man sich 'als normaler Autofahrer' darauf verlassen, > dass man bei einem Node mit 'amenity=parking' einen Parkplatz findet. > Das sollte auch weiterhin so bleiben. > Ich hab als Autofahrer noch nie einen Node mit 'amenity=parking' gesehen. Dafuer benutze ich eine Software, die mir das so anzeigt, wie ich es brauche... > Der 'übliche Spruch' wird leider von vielen - auch von Dir - falsch > verstanden: > http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer > Und was willst du uns damit sagen?!? > Mich juckt es eben, ob in der Stadt Zürich plötzlich 200 neue P auf- > blitzen, wenn dort der normale Autofahrer gar nicht parken darf. > dann solltest du deinen Renderer anpassen ;-) > >> Daher: Irgendwelche Einwände gegen > >> > >> amenity=disabled_parking > >> capacity=1 > > > > Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. > > *Falls* man die Bedeutung von 'parking' ändert. > tut man doch nicht... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Stats OSM Routing View 2010-07
Hi, weil doch hin und wieder vereinzelt Anfragen kommen: Die neue monatliche Statistik zum Routing View Deutschland findet sich unter: http://neis-one.org/2010/07/18/stats-osm-routing-view-2010-07/ Wer nur Interesse am Diagramm der Bundesländervergleiche hat: http://neis-one.org/wp-content/uploads/2010/07/Stats_OSMI_R_V_201007.png viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Guenther, > Am Sonntag 18 Juli 2010, 20:16:29 schrieb Thomas Ineichen: >> Es ist eben nicht total einfach. Falls man 'amenity=parking' *auch* >> für nur-Behinderten-Parkplätze benutzen möchte, ändert man die >> Bedeutung des Tags. > Und w aendert man hier die Bedeutung? > Sind Behindertenparkplaetze etwa keine Parkplaetze? Nicht im bisher genutzen Sinne von amenity=parking. >> Bisher konnte man sich 'als normaler Autofahrer' darauf verlassen, >> dass man bei einem Node mit 'amenity=parking' einen Parkplatz findet. >> Das sollte auch weiterhin so bleiben. >> > Ich hab als Autofahrer noch nie einen Node mit 'amenity=parking' gesehen. > Dafuer benutze ich eine Software, die mir das so anzeigt, wie ich es > brauche... Dann halt als Render-Stylesheet-Ersteller, als Routing-Algorythmus- Ersteller, als ... Fakt ist: Benutze ich amenity=parking für einzelne Behindertenparkplätze, zwinge ich anderen Arbeit auf, damit sie die Daten wieder so nutzen können wie vorher. Benutze ich amenity=disabled_parking müssen sich nur diejenigen bemühen, welche 'meine' Daten nutzen möchten. >> Der 'übliche Spruch' wird leider von vielen - auch von Dir - falsch >> verstanden: >> http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer > Und was willst du uns damit sagen?!? Dass wir sehr sehr wohl *alle* für Renderer taggen. >> Mich juckt es eben, ob in der Stadt Zürich plötzlich 200 neue P auf- >> blitzen, wenn dort der normale Autofahrer gar nicht parken darf. > dann solltest du deinen Renderer anpassen ;-) Abgesehen davon, dass *ich* für *meinen* Renderer alles anpassen kann: Wenn ein Tagging dazu führt, dass die Daten auf *allen* anderen Renderern zu einem neuen, ungewollten Ergebnis führen, dann darf man sich ruhig überlegen, ob man vielleicht nicht doch sein Taggin-Schema ändern sollte.. @Kompliziertheit: PostgreSQL enthält (soweit ich weiss) keine IsNumeric-Funktion. Da die OSM-Daten in der Tabelle aber als String gespeichert sind, braucht es einiges an Preprocessing, um danach mit Zellenwerten mathematische Funktionen durchführen zu können (capacity - capacity:disabled = 0). Es kann also nicht 'mal eben' das Stylesheet angepasst werden, um zwischen Behinderten- und Nichtbehinderten-Parkplätzen unterschieden werden. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Florian Gross wrote: Mir gefällt das Prinzip der freien Daten, die *jeder* nutzen darf, so er Veröffentlichung die Quelle angibt und keinem anderen die Nutzung verbieten darf. Egal ob der Nutzer die alte Oma von nebenan ist oder ein Weltkonzern (unabhängig davon, ob ich den Konzern leiden kann oder nicht). Und unabhängig davon, ob da etwas zurückgegeben wird oder nicht. Eigentlich wollte ich genau das ausdrücken, also erstmal volle Zustimmung. Mit der Ausnahme, dass ich es schon richtig finde, dass veränderte Daten wieder "greifbar" sein sollten. Und sei es nur ein monatsaktueller Dump, der jedem interessierten zum "zurückführen" zur Verfügung gestellt wird. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am Sonntag 18 Juli 2010, 22:16:46 schrieb Thomas Ineichen: > Hallo Guenther, > > > Am Sonntag 18 Juli 2010, 20:16:29 schrieb Thomas Ineichen: > >> Es ist eben nicht total einfach. Falls man 'amenity=parking' *auch* > >> für nur-Behinderten-Parkplätze benutzen möchte, ändert man die > >> Bedeutung des Tags. > > > > Und w aendert man hier die Bedeutung? > > Sind Behindertenparkplaetze etwa keine Parkplaetze? > > Nicht im bisher genutzen Sinne von amenity=parking. > Das mag sein, aber es widerspricht auch nicht der Definition. > Fakt ist: > Benutze ich amenity=parking für einzelne Behindertenparkplätze, zwinge > ich anderen Arbeit auf, damit sie die Daten wieder so nutzen können > wie vorher. Benutze ich amenity=disabled_parking müssen sich nur > diejenigen bemühen, welche 'meine' Daten nutzen möchten. > falsch. du erfindest neue Tags, obwohl es bereits ein konsistentes Schema gibt, das alles hergibt, was benoetigt wird. Nur weil dieser Teil des bestehenden Schemas bisher kaum genutzt wurde, heisst das nicht, dass man das Rad neu erfinden muss. Erst recht nicht indem man sich einredet, dass anderenfalls bestehendes in der Bedeutung veraendert wuerde. > >> Der 'übliche Spruch' wird leider von vielen - auch von Dir - falsch > >> verstanden: > >> http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer > > > > Und was willst du uns damit sagen?!? > > Dass wir sehr sehr wohl *alle* für Renderer taggen. > Du willst mir nicht wirklich weissmachen, dass du alle Renderer da draussen kennst und bei deinem Tagging beruecksichtigst?! Getaggt wird (oder sollte zumindest) nach einem klar definierten Schema, damit sich die Anwendungen das rausziehen koennen, was sie brauchen. > >> Mich juckt es eben, ob in der Stadt Zürich plötzlich 200 neue P auf- > >> blitzen, wenn dort der normale Autofahrer gar nicht parken darf. > > > > dann solltest du deinen Renderer anpassen ;-) > > Abgesehen davon, dass *ich* für *meinen* Renderer alles anpassen kann: > worueber beschwerst du dich dann ;-) > Wenn ein Tagging dazu führt, dass die Daten auf *allen* anderen > Renderern zu einem neuen, ungewollten Ergebnis führen, dann darf man > sich ruhig überlegen, ob man vielleicht nicht doch sein Taggin-Schema > ändern sollte.. > nochmal: das bestehende Schema enthaelt alles Notwendige und ist gut dokumentiert. Wenn ein Renderer damit nicht zurechtkommt, ist das erst mal sein Problem. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] pastafarian: Fliegendes Spaghettimonster
hi, bin beim stöbern in UNSEREM OSM-WIKI auf das hier gestoßen: http://wiki.openstreetmap.org/wiki/Key:denomination (ganz unten) http://wiki.openstreetmap.org/wiki/Tag:religion%3Dpastafarian u.s.w wo donomination oder religion ein thema ist nähere sachdienstliche hinweise hier: http://de.wikipedia.org/wiki/Fliegendes_Spaghettimonster werd ich demnächst wohl rausschmeißen. gruss walter p.s. eventuell schaut sich mal wer unsere tags in osm an. - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/pastafarian-Fliegendes-Spaghettimonster-tp5310030p5310030.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] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.07.2010 20:59, Florian Gross wrote: >> JOSM ist ja mittlerweile so schlau und empfiehlt beim Aendern der >> Richtung eines Ways, auch die entsprechenden richtungsabhaengigen Tags >> umzudrehen. > > Vor einigen Wochen war JOSM dabei richtig konsequent und wollte > mir aus uploaded_by ein downloaded_by machen ;-) haha! Ähnliches hatte ich auch schon - aus der "Westendstraße" sollte eine "Eastendstraße" werden :-D Nicht schlecht ;-) - - Fips - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxDfEsACgkQnHVyAFIfTkEfTwCcDCbDLIrmUBqoXbBL/OLvGjch 8doAnRD/2S5hktl9f6YT22wS9xm83M8P =zVG5 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] pastafarian: Fliegendes Spaghettimonster
Was ist denn daran des "Rausschmeissens" würdig? Ist doch völlig legitim (mindestens genau so, wie die anderen aufgeführten Religionen) und relevant (ha, ich habs' gesagt) und tut niemandem weh, oder? Claudius Am 18.07.2010 23:59, Walter Nordmann: hi, bin beim stöbern in UNSEREM OSM-WIKI auf das hier gestoßen: http://wiki.openstreetmap.org/wiki/Key:denomination (ganz unten) http://wiki.openstreetmap.org/wiki/Tag:religion%3Dpastafarian u.s.w wo donomination oder religion ein thema ist nähere sachdienstliche hinweise hier: http://de.wikipedia.org/wiki/Fliegendes_Spaghettimonster werd ich demnächst wohl rausschmeißen. gruss walter p.s. eventuell schaut sich mal wer unsere tags in osm an. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] pastafarian: Fliegendes Spaghettimonster
warten mer mal die diskussion ab - wenns überhaupt jemanden interessiert. - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/pastafarian-Fliegendes-Spaghettimonster-tp5310030p5310070.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] pastafarian: Fliegendes Spaghettimonster
Am 19.07.2010 um 00:13 schrieb Claudius: > Was ist denn daran des "Rausschmeissens" würdig? Ist doch völlig legitim > (mindestens genau so, wie die anderen aufgeführten Religionen) und relevant > (ha, ich habs' gesagt) und tut niemandem weh, oder? > > Claudius > > Am 18.07.2010 23:59, Walter Nordmann: >> >> hi, >> >> bin beim stöbern in UNSEREM OSM-WIKI auf das hier gestoßen: >> >> http://wiki.openstreetmap.org/wiki/Key:denomination (ganz unten) >> http://wiki.openstreetmap.org/wiki/Tag:religion%3Dpastafarian >> u.s.w wo donomination oder religion ein thema ist >> >> nähere sachdienstliche hinweise hier: >> http://de.wikipedia.org/wiki/Fliegendes_Spaghettimonster >> >> werd ich demnächst wohl rausschmeißen würde ich vorsest mal nicht. Schaut mal hier: http://wiki.openstreetmap.org/w/index.php?title=Key:denomination&diff=401523&oldid=398675 angeblich wurde es tatsächlich getaggt. Nur wo? Vlt. kann dass ja mal jemand mit "der Wirklichkeit" abgleichen und in DE mal bei dem Ort nachsehen, ob das wirklich an der Haustüre steht und gleich mal ein Foto machen fürs Wiki. Hat mal jemand den Urheber der ursprünglichen Wiki-Einträge angeschrieben und nach seinen Beweggründen gefragt? Vlt. werden wir auch nur getestet, wie wir damit umgehen. steffterra (der sonst recht offen ist, was Religionsfreiheit angeht) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Job fuer einen Bot: Hoehenangabe im Namen
Bei unzaehligen Berghuetten steht die Hoehe im Namen. Das hat wohl historische Gruende. http://www.openstreetmap.org/browse/node/477726059 name = Gehrenalpe (1354m) Hier waere ein umtaggen nach ele=* gut: http://wiki.openstreetmap.org/wiki/Key:ele Wer kennt sich damit aus? -- Jonas Stein ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
