Re: [Talk-de] Schreckgespenst Datenverlust
Am Dienstag 20 Juli 2010, 07:23:44 schrieb Jens Frank: Am 19. Juli 2010 17:02 schrieb Florian Lohoff f...@zz.de: Weiter wird dann sogar sowas verblödetes wie ein Fork in die Diskussion eingebracht. Statt die Arbeit dann in die osm zu stecken und an EINER freien Weltkarte zu schrauben würde dann an anderer Stelle neu angefangen. Noch viel sinnloser und Resourcenverschwendung im Quadrat. _Eine_ Freie Weltkarte wuerde bedeuten das wir unter bedingungen Arbeiten die fuer alle Akzeptabel ist. Die CC-BY-SA war fuer alle Akzeptabel die bisher daran teilgenommen haben. Sie war deshalb akzeptabel (zumindest fuer mich), weil es schwierig ist, was vergleichbares neu aufzuziehen und die Ressourcen dafuer bereitzustellen. Ich hatte durchaus mal darueber nachgedacht. Ich finde aber, es spricht nichts dagegen, beim Lizenzwechsel auch eine zweite CC0-Version zu erstellen. Man wird ja dann sehen, welche sich besser entwickelt... Das Problem ist nur, dass man dann auch die Infrastruktur zweimal braucht... Nein. Die CC-BY-SA ist nur deshalb scheinbar akzeptabel, weil sich bisher keiner dran hält. Nicht eine Webseite, die OSM-Karten benutzt, erfüllt die CC-BY-SA. Sie müssten nämlich nicht nur by openstreetmap.org sagen, sondern alle Autoren des jeweiligen Kartenausschnitts aufführen. Falsch! Zitat CC-BY-SA-Lzenz: ...and give the Original Author credit reasonable to the medium or means You are utilizing by conveying the name (or pseudonym if applicable) of the Original Author if supplied; the title of the Work if supplied; to the extent reasonably practicable,... Jeden Autor direkt anzugeben ist nicht wirklich praktikabel. Soweit ich weiss, war es Konsens, dass der Hinweis auf das OSM-Projekt ausreichend ist. Und damit ist der Lizenz genuege getan. 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] Behindertenparkplatz-Die Lösung
Am Dienstag 20 Juli 2010, 01:50:27 schrieb Thomas Ineichen: Und wer bringt das alles den Rolli-Fahrern bei, die eigentlich nur ein paar Behinderten-Parkplätze einzeichnen möchten? ein entsprechendes Preset im Editor? 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] Behindertenparkplatz-Die Lösung
Moin, On 20.07.2010 01:50, Thomas Ineichen wrote: Hallo ihr, highway=residental parking:lane:right=inline capacity:standard=3 capacity:disabled=1 parking:condition:right=residents parking:condition:right:residents=G bzw. highway=residental parking:lane:right=inline capacity:disabled=1 bzw. parking:lane:right:capacity:disabled=1 bzw. parking:condition:right=disabled Und wer bringt das alles den Rolli-Fahrern bei, die eigentlich nur ein paar Behinderten-Parkplätze einzeichnen möchten? Gruss, Thomas Ich wage mal zu behaupten, dass jeder, der einen Parkplatz einzeichnen und korrekt taggen kann, auch in der Lage ist, umfangreichere tags anzuwenden, wenn er nur um diese weiß. Wie bei jedem komplexen tagging-Schema empfiehlt sich natürlich josm-presets zu nutzen [1], auch das roadsigns-plugin könnte man sicher für diesen Fall gebrauchen. Ansonsten ist's halt wie mit allem anderen auch, wenn der mapper nicht sicher weiß, was er machen kann/darf/soll/muss, setzt er eben fixme oder nutzt osb. Im proposal wird auf disabled nur bedingt eingegangen, disabled_spaces wird erwähnt, disabled=yes und parking:condition:side=disabled werden angedacht, eine Diskussion dazu gibt es aber auf der entsprechenden Seite nicht. Das Ganze wird niemals alle Fälle abdecken können, Behindertenparkstände zu integrieren sollte aber problemlos möglich sein, man müsste sich eben nur auf ein einheitliches und sinnvolles tagging verständigen und dieses konsequent anwenden. Wenn aber niemand die Bedenken dazu äußert, wird es auch nicht in den Fokus rücken und wohl bei zitiertem Schema bleiben. Grüße, yzemaze [1] http://osm.sebastian-klemm.eu/josm/josm-preset_parkinglane.xml (disabled fehlt komplett) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehler in mapgen.pl 1.05?
hi, habe es herausgefunden, woran es liegt. steigt die horizontale distanz auf über 180 grad, so gibt geo proj4 bei der transformation der koordinaten negative werte für maxlon zurück. daraus ergibt sich ein falsches verhältnis von höhe zu breite, also ein negatives. so wie es im augenblick aussieht, kann ich dazu keine lösung anbieten... mir fehlt schlicht die idee. evtl. kannst du zwei karten produzieren und sie dann aneinanderreihen? ciao gerhard On Sat, 2010-07-17 at 21:55 +0200, Carsten Gerlach wrote: Hallo, ich habe gerade mit mapgen.pl (http://wiki.openstreetmap.org/wiki/Mapgen.pl) experimentiert und dabei festgestellt, daß eine negative Höhe des Bildes berechnet wird, wenn die horizontale Ausdehnung der Karte größergleich 180° ist. Bei geringerer Ausdehnung ist alles in Ordnung. Die SVG enthält auch im fehlerhaften Fall alle Elemente, nur alles ganz unglücklich verschoben und verdreht. Am besten mal mit den zwei Beispieldateien probieren (der Unterschied ist nur in der lon-Koordinate von Punkt 1): ==in_ordnung.osm== ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='1' visible='true' version='1' lat='50' lon='99' / node id='2' visible='true' version='1' lat='-50' lon='-80' / way id='1' visible='true' version='1' nd ref='1' / nd ref='2' / tag k='highway' v='primary' / tag k='name' v='In Orndung' / /way /osm ==fehlerhaft.osm== ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='1' visible='true' version='1' lat='50' lon='100' / node id='2' visible='true' version='1' lat='-50' lon='-80' / way id='1' visible='true' version='1' nd ref='1' / nd ref='2' / tag k='highway' v='primary' / tag k='name' v='Fehlerhaft' / /way /osm Leider hab ich noch nicht nachvollziehen können, an welcher Stelle die Höhe berechnet wird, sonst hätte ich mich selbst an einen Patch gewagt. Somit bin ich für jede Hilfe dankbar. :-) Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehler in mapgen.pl 1.05?
mir ist noch was eingefallen. evtl. kann man den nullmeridian der projektion auf einen anderen wert setzen. im augenblick steht da (in mapgen.pm) my $l0 = int($l) - 1 ; der liegt also außerhalb des zu zeichnenden bereichs vielleicht kann man den so verwursten my $l0 = int($r+$l) / 2 ; so läge er in der mitte des zu zeichnenden bereichs müsste man mal für diverse karten probieren, ob dann noch alles geht... ich könnte es mir vorstellen. aber manchmal steckt der teufel im detail! ciao gerhard On Sat, 2010-07-17 at 21:55 +0200, Carsten Gerlach wrote: Hallo, ich habe gerade mit mapgen.pl (http://wiki.openstreetmap.org/wiki/Mapgen.pl) experimentiert und dabei festgestellt, daß eine negative Höhe des Bildes berechnet wird, wenn die horizontale Ausdehnung der Karte größergleich 180° ist. Bei geringerer Ausdehnung ist alles in Ordnung. Die SVG enthält auch im fehlerhaften Fall alle Elemente, nur alles ganz unglücklich verschoben und verdreht. Am besten mal mit den zwei Beispieldateien probieren (der Unterschied ist nur in der lon-Koordinate von Punkt 1): ==in_ordnung.osm== ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='1' visible='true' version='1' lat='50' lon='99' / node id='2' visible='true' version='1' lat='-50' lon='-80' / way id='1' visible='true' version='1' nd ref='1' / nd ref='2' / tag k='highway' v='primary' / tag k='name' v='In Orndung' / /way /osm ==fehlerhaft.osm== ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='JOSM' node id='1' visible='true' version='1' lat='50' lon='100' / node id='2' visible='true' version='1' lat='-50' lon='-80' / way id='1' visible='true' version='1' nd ref='1' / nd ref='2' / tag k='highway' v='primary' / tag k='name' v='Fehlerhaft' / /way /osm Leider hab ich noch nicht nachvollziehen können, an welcher Stelle die Höhe berechnet wird, sonst hätte ich mich selbst an einen Patch gewagt. Somit bin ich für jede Hilfe dankbar. :-) Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] SOTM 2010 - feedback
Hallo,
leider hatte es auf der SOTM 2010 nicht mit dem Feedback geklappt -
kleine organisatorische Panne...
Deswegen gibt es einen Aufruf in den News mit der Bitte um Teilnahme:
http://stateofthemap.org/feedback-please/
Dort sind sowohl die Teilnehmer als auch die Nicht-Teilnehmer
aufgerufen ein Feedback zu geben. Wenn ich es richtig sehe, hat noch
niemand hier den Aufruf weitergegeben.
Feedback please!
We, the organizing committee, are looking back on a great conference. Of
course, we are also a bit prejudiced… That’s why we also like to hear
feedback from you.
Did you attend SotM10? Please go to this feedback form.
[http://spreadsheets.google.com/viewform?formkey=dGFUc1c5UjFaOFphbXVWbTZYVmJjNHc6MQ]
{Teilnehmer}
Did you not attend SotM10? We also have some questions for you. Please
go to this feedback form.
[http://spreadsheets.google.com/viewform?formkey=dEFCYWR4d3JSbXJnQWV3LVBmUWhoanc6MQ]
{Nicht-Teilnehmer}
Thanks for taking the effort to complete the feedback form.
Grüße,
Michael.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
heiko.jac...@gmx.de (Heiko Jacobs) am 20.07.10: Rainer Knaepper schrieb: Da müssen Fußgänger, Rollifahrer und Radler durch, weil die benachbarte Hochstraße für selbige verboten ist. Nö, ist nicht verboten laut OSM! ;-) Kraftfahrstraßenschild? -- motorroad=yes explizite Verbotsschilder für Fuß/Rad? -- foot=no, bicycle=no Wenn beides nicht: erlaubt Da gibt es afaik sowas, aber ich werde da noch mal zwecks Dokumentation hinfahren müssen, bislang habe ich die Situation ausschließlich aus Autofahrersicht betrachtet. Zuständigen Planer teeren + federn und so auf dem Rad da durch jagen ;-) Die dürften im Ruhestand sein, die Anlage ist afaik über 20 Jahre alt. Sollte jemand auf die Idee kommen, da was korrekt als Gehweg auszuschildern, würde ich das beim Radverkehrsnetz NRW petzen, wie man eine überörtliche Radverbindung so kastrieren kann mit Hinweis, dass es auch behinderte Radfahrer gibt, die keine Möglichkeit hätten, ihr Rad zu schieben. Oder sowieso dort mal fragen, wie sowas enges und gefährliches sein kann auf einer überörtlichen Route ... mir kam auch der Gedanke, wie jemand auf einem Liegerad wohl da durchkommen soll. Auch die Kurven sind sehr eng :-) Abgesehen davon, daß zwei abgesessene Radler wohl erst recht nicht aneinander vorbeikommen: Wie taggt man sowas? So wie's aussieht, ist's schon recht getaggt... Kleine Inkonsistenz zwischen bicycle=designated und bicycle=yes, würde ich auf letzteres vereinheitlichen. wie geschrieben, ich schaue es mir nochmal genau an. Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
sh...@nurfuerspam.de (Fabian) am 20.07.10: schonmal die kleinigkeit das garkeine fussgaenger hinkommen weil nur cycleways hinfuehren. Dieses radfahrerzentrierte Tagging gibt es hier überall, an allen Ecken und Enden und auch noch uneinheitlich. Und nein, das stammt nicht von mir, ich bin eher selten mit dem Rad unterwegs und halte mich bei Radwegen an sich raus. Die Radwege, die ich hier in der Gegend persönlich kenne, sind allesamt auch für Fußgänger erlaubt, warum das mal auf die eine, mal auf die andre Art getaggt ist, entzieht sich meiner Kenntnis. Was ich selber anlege, tagge ich idR als Fußweg mit bicycle=yes. Ausnahme sind die ehemaligen (Zechen-)Bahntrassen, die zu Radwegen umgebaut wurden, das sind dann eben Radwege mit Foot=yes. Auch sehe ich nicht wie man von level 0 auf -1 kommt bei den radwegen. irgenwo sollte da noch ein ramp hin IMHO ramp kannte ich nicht. Ist das ein eingeführtes tag? wuerde aber auch sagen alles was nciht als radweg ausgeschilder ist wird als fussweg angenommen. radfahrer muessten also untendurch sowieso schieben. am besten wuerden die traffic_sign=DE:xxx hier weiterhelfen. nachdem was du geschrieben hast muesste da eh ein [1] irgnwo stehen [1] http://wiki.openstreetmap.org/wiki/File:120px-Zeichen_260.svg.pn g Ich werde da wohl noch mal hinfahren, und die ganze absurde Konstruktion mal fotografisch dokumentieren müssen. Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SOTM 2010 - feedback
Hallo Michael, gibt es denn schon Erfahrungs- und Erlebnisberichte? (in Deutsch) Gab es Mitschnitte von Veranstaltungen? Wo kann man sich diese anschauen/hören? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
Am 20. Juli 2010 00:36 schrieb Fabian sh...@nurfuerspam.de: schonmal die kleinigkeit das garkeine fussgaenger hinkommen weil nur cycleways hinfuehren. Auch sehe ich nicht wie man von level 0 auf -1 kommt bei den radwegen. irgenwo sollte da noch ein ramp hin IMHO Moin! Das ist kein Problem. Da layer=* nur die relative Lage sich kreuzender Objekte auf der z-Achse zueinander angibt, muß es kein Gefälle geben, um von 1 auf -1 zu kommen. Das besagt nur, daß der Tunnel unterhalb der Bahnlinie liegt wie weit die Bahnlinie dafür angehoben oder der Fußweg abgesenkt wird, geht daraus nicht hervor. (viele implizieren auch layer=-1 bei Tunneln) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz-Die Lösung
Am 19. Juli 2010 14:08 schrieb steffterra steffte...@me.com: Nach so einer Lösung hattest Du doch gesucht, oder? Für den einzeln stehenden Behinderten-stand- aus Deinem Themenstart wäre es dann das: highway=residental parking:lane:right=inline capacity:disabled=1 Dein Anliegen war ja genau das. . Saubere Lösung. - Also kein neuer amenity-Tag (da aus Proposal genommen) nötig und Lösung in bestehendem Proposal gefunden. Das ist doch gut für Deine Behindertenkarte, oder? (welche ich sehr begrüße!) Hallo! Ich glaube du antwortest eher Thomas, der hatte das Thema ja losgetreten und baut auch die Karte. Für mich ists auch ok, ich hätte abe auch nichts gegen ein tag für einzelne Parkstände als node einzuwenden, wenn es nicht amenity=parking heißt. ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
Bernd Wurst be...@bwurst.org wrote: Bei der Karte habe ich einen drastischen Versatz von Maus-Cursor und Maus- Aktion (z.B. beim zoom via Shift+Ziehen). Das habe ich bei anderen OL-Karten früher schonmal gesehen, weiß aber nicht mehr ob es ein Client- oder ein Server-Problem war. Hab ich auch schon bemerkt. Eventuell mal das Openlayers austauschen. Sven -- In my opinion MS is a lot better at making money than it is at making good operating systems (Linus Torvalds, August 1997) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
bundesrainer o...@bundesrainer.de wrote: Mal eine Frage zur Definition von Hausbrauerei: Sind damit Gaststätten, Restaurants u.ä. gemeint, die selbst brauen und dieses Bier nur direkt vor Ort verkaufen? Die Grenze ist denke ich erreicht wenn das Bier Bundesweit erhältlich ist. Mir ist schon klar, dass es da im fränkischen Bierland Grenzfälle geben wird. Gruss Sven -- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. (Anselm Lingnau in de.comp.os.unix.discussion) /me ist gig...@ircnet, http://sven.gegg.us/ im WWW ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
Rainer Knaepper rain...@smial.prima.de wrote: Für welche Bildschirmauflösung ist das gedacht? *urgs* ich gebs zu ich hätte das mit dem Netbook testen sollen. Mal schaun ob ich die Tage dazukomme das zu fixen. Ist statischer HTML Code, ich nehme gerne patches :) Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Am 20.07.2010 01:39, schrieb Frederik Ramm: Stimmt. Deswegen bleibt die alte Datenbank auf ewig als CC-BY-SA erhalten. Wird man in der odbl-DB die durch Nicht-Übernahme entstandenen Lücken durch abmalen von einem Old-Mapnik-WMS-Layer beheben dürfen ? Was ist mit den GPX-Tracks? Wird es dort auch eine Trennung geben in darf und darf-nicht weiterverwendet werden ? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Hallo, Chris66 wrote: Stimmt. Deswegen bleibt die alte Datenbank auf ewig als CC-BY-SA erhalten. Wird man in der odbl-DB die durch Nicht-Übernahme entstandenen Lücken durch abmalen von einem Old-Mapnik-WMS-Layer beheben dürfen ? Nein. Aber man kann sicherlich gewisse automatische Analysen mit den alten Daten machen, a la hier muss mal jemand hin und diese Gegend vervollstaendigen, da fehlen 4 Strassen oder sowas. Angucken darf man die alten Daten ja schon noch, bloss halt genau so, wie man heute eine Google-Karten angucken darf. Abmalen geht nicht. Was ist mit den GPX-Tracks? Wird es dort auch eine Trennung geben in darf und darf-nicht weiterverwendet werden ? Ehrlich gesagt, weiss ich gar nicht, was da der Stand ist, da hab ich mich nie mit beschaeftigt. Vielleicht kann Ulf M. dazu was sagen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Am 20.07.2010 10:49, schrieb Chris66: Am 20.07.2010 01:39, schrieb Frederik Ramm: Stimmt. Deswegen bleibt die alte Datenbank auf ewig als CC-BY-SA erhalten. Wird man in der odbl-DB die durch Nicht-Übernahme entstandenen Lücken durch abmalen von einem Old-Mapnik-WMS-Layer beheben dürfen ? Nein, das ist die gleiche Situation als wenn du von Google abmalst - die Lizenz ist nicht kompatibel. Ich gehe davon aus, das ein WMS (o.ä.) mit den alten Daten zur Verfügung stehen wird. Du kannst die alten Daten dann wohl dazu verwenden, zu schauen wo Sachen fehlen und dort vor Ort nachzuarbeiten. Abmalen ist aber - wie auch von Google o.ä. - nicht möglich. Was ist mit den GPX-Tracks? Wird es dort auch eine Trennung geben in darf und darf-nicht weiterverwendet werden ? Wahrscheinlich ja. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verlauf der B 311 in Ulm.
Am 13.07.2010 09:32, schrieb fly: Kann jemand mal den Verlauf der B 311 in Ulm überprüfen ? Unter wikipedia steht nicht viel und die TMC-Daten gehen bis weit in die Stadt (sind leider häufig auch nicht richtig oder Musik aus der Zukunft). Was die Beschilderung anbelangt, so habe ich heute morgen mal die in OSM der B311 zugeordnete Strecke abgefahren und dort nirgends ein Schild B311 oder eine entsprechende Beschriftung auf einer Richtungstafel gefunden. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lizenz - warum nicht individuell?
Hallo Liste, bei uns in Dresden auf dem Stammtisch gab es viel Zustimmung für eine PD Lizenz. Wurde denn hier mal ernsthaft über PD diskutiert und das als Möglichkeit gesehen? PD bietet maximale Rechtssicherheit, maximale Freiheit und kommt damit meiner Intention bei OSM mitzumachen am nächsten. Natürlich wird es schwierig mit Datenspenden, Lizenzumstellung etc. Da es offenbar doch genug Gründe für ODbl gibt, kam mir eine weitere Idee. Warum müssen eigentlich alle Mapper mit der selben Lizenz beitragen? Sagen wir mal die Datenbank an sich ist unter der restriktivsten Lizenz, die sich die Leute hier wünschen - ich sag jetzt einfach mal das ist ODbl. Wenn jetzt jeder individuell die Möglichkeit hat seinen Lizenzregler so einzustellen wie er das für richtig hält und die Lizenzen abwärtskompatibel sind, dann könnte man doch so einen Zwischenweg gehen oder? Mal angenommen, dem nächsten ist nur Namensnennung wichtig und der nächste möchte nur PD oder so. Das wäre ja alles ODbl kompatibel und könnte somit auch unter dieser Lizenz ausgeliefert werden. Sind halt Daten mit unterschiedlicher Freiheit in der DB. Wenn jetzt alle ihren Lizenzregler auf PD stellen und der Großteil der Daten vielleicht irgendwann wirklich frei ist, kann man über ne Lizenzumstellung noch mal ganz anders nachdenken. Man könnte dann vielleicht auch einen PD-Auszug der OSM-Daten generieren etc. Grüße Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenz - warum nicht individuell?
Christoph Wagner wrote: Wurde denn hier mal ernsthaft über PD diskutiert und das als Möglichkeit gesehen? *POPCORN!* Mal die letzten Threads gelesen? Man kann sich natürlich auch ewig im Kreis drehen. Warum nicht einfach mit ODbL abfinden? PD bietet maximale Rechtssicherheit, maximale Freiheit und kommt damit meiner Intention bei OSM mitzumachen am nächsten. Natürlich wird es schwierig mit Datenspenden, Lizenzumstellung etc. Beim Switch zu ODbL geht es von einer Share-Alike-Lizenz zu einer eben solchen und bereits bei einer solchen eher geringfügigen Änderung gibt es Bedenken wegen zu großem Datenverlust. Eben dieser Datenverlust wäre bei einer erheblich krasseren Änderung der Lizenz noch viel extremer! Wobei maximale Rechtssicherheit wohl nur für den Nutzer der Daten gilt, da der Autor so gut wie alle seine Rechte aufgibt. Vom Urheberrecht abgesehen, das in Deutschland niemals weitergegeben werden kann. Warum müssen eigentlich alle Mapper mit der selben Lizenz beitragen? Sagen wir mal die Datenbank an sich ist unter der restriktivsten Lizenz, die sich die Leute hier wünschen - ich sag jetzt einfach mal das ist ODbl. Wenn jetzt jeder individuell die Möglichkeit hat seinen Lizenzregler so einzustellen wie er das für richtig hält und die Lizenzen abwärtskompatibel sind, dann könnte man doch so einen Zwischenweg gehen oder? Mal angenommen, dem nächsten ist nur Namensnennung wichtig und der nächste möchte nur PD oder so. Das wäre ja alles ODbl kompatibel und könnte somit auch unter dieser Lizenz ausgeliefert werden. Sind halt Daten mit unterschiedlicher Freiheit in der DB. Wenn jetzt alle ihren Lizenzregler auf PD stellen und der Großteil der Daten vielleicht irgendwann wirklich frei ist, kann man über ne Lizenzumstellung noch mal ganz anders nachdenken. Man könnte dann vielleicht auch einen PD-Auszug der OSM-Daten generieren etc. Was, wenn sich der entsprechende Mapper z.B. an Luftbildern bedient, die eben nicht PD sind? Dazu kommt, dass ein Element, das von einem PD-Benutzer erstellt wurde, durch die erste Änderung eines ODbL-Benutzers direkt zu ODbL wird. Alle nicht-PD-Änderungen automagisch wieder von diesem Objekt zu bekommen, halte ich für nicht ganz trivial. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
Heiko Jacobs wrote: So wie's aussieht, ist's schon recht getaggt... Kleine Inkonsistenz zwischen bicycle=designated und bicycle=yes, würde ich auf letzteres vereinheitlichen. Da wäre ich vorsichtig! Zumindest bicycle=designated heißt in Deutschland wohl Benutzungspflichtiger Radweg und der liegt hier wohl eher nicht vor. bicycle=yes ist dann wohl sowas wie Radfahrer frei. Also nicht benutzungspflichtig. Da man hier mit Schildern Radfahrer aber eher warnen will, ist das wohl auch nicht Radfahrer frei. In meiner Umgebung habe ich da selber schon Radwege umgebaut, um die Benutzungspflicht, wo nicht gegeben, entsprechend rauszunehmen. Als Radfahrer sind oft gerade solche Bereiche interessant, da man da je nach Route entscheiden kann, ob man den nicht benutzungspflichten Radweg nutzen will oder nicht. Laut http://wiki.openstreetmap.org/wiki/Key:access wäre wohl bicycle=unknown denkbar. Ich würde für die fragliche Stelle das bicycle-Tag ganz löschen. Was nicht explizit verboten ist, kann jeder vor Ort für sich entscheiden, ob er es für machbar hält. Ich habe in meinem Gebiet auch fast alle bicycle=no gelöscht, da diese Wege nicht direkt für Fahrräder verboten und mit dem Mountainbike durchaus passierbar waren. Hier und da habe ich stattdessen mtb:scale nachgetragen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SOTM 2010 - feedback
Markus wrote: gibt es denn schon Erfahrungs- und Erlebnisberichte? (in Deutsch) Gab es Mitschnitte von Veranstaltungen? Wo kann man sich diese anschauen/hören? Schließe mich der Frage an. Interessant wären auch eventuell gezeigte Präsentationen zum Nachlesen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SOTM 2010 - feedback
Hallo, Manuel Reimer wrote: Gab es Mitschnitte von Veranstaltungen? Wo kann man sich diese anschauen/hören? Die Mitschnitte sind noch nicht veroeffentlicht, das soll aber bald kommen. Schließe mich der Frage an. Interessant wären auch eventuell gezeigte Präsentationen zum Nachlesen. Einige Praesentationen sind bereits hier verlinkt: http://wiki.openstreetmap.org/wiki/State_Of_The_Map_2010 Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
Am 20. Juli 2010 09:29 schrieb Rainer Knaepper rain...@smial.prima.de: sh...@nurfuerspam.de (Fabian) am 20.07.10: schonmal die kleinigkeit das garkeine fussgaenger hinkommen weil nur cycleways hinfuehren. Fußgänger dürfen auf highway=cycleway durchaus gehen, nur nicht auf deutschen Radwegen (die daher m.E. foot=no benötigen). Dieses radfahrerzentrierte Tagging gibt es hier überall, an allen Ecken und Enden und auch noch uneinheitlich. Was ich selber anlege, tagge ich idR als Fußweg mit bicycle=yes. Ausnahme sind die ehemaligen (Zechen-)Bahntrassen, die zu Radwegen umgebaut wurden, das sind dann eben Radwege mit Foot=yes. Allgemein gilt (bzw. galt?) die Regel, dass das höhere Fahrzeug die Wegklasse bestimmt, also in Fällen von Radwegen mit Fußgänger frei (oder auch kombinierten Fuss-Radwegen nach altem Schema ohne path) cycleway und foot=yes, und nur für Fußwege mit Fahrräder frei footway und bicycle=yes, wobei mit path (bzw. designated/official?) ja eine Variante zur Verfügung steht, die das genauer abbilden kann, und daher verwendet werden sollte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenverlust
Für eine sinnvolle Diskussion und als Basis für eine verantwortliche Entscheidung braucht man möglichst valide Daten. Deahalb habe ich mal ein paar konkrete Idee zusammengefasst: http://wiki.openstreetmap.org/wiki/DE:Datenverlust_bei_Lizenzwechsel Basis für solche Analysen sind konkrete Fallbeispiele. Einige habe ich in Bezug auf kaskadische Wirkungen von Datenverlust fomuliert und meine (laienhafte) Vermutung angefügt. (bitte ergänzen) Vielleicht können die Profis uns ja zeigen, welche Folgen ein Lizenzwechsel bezüglich Datenverlust hat. Gruss, Markus ___ 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 20.07.2010 06:20, schrieb Bernd Wurst: Am Montag 19 Juli 2010, 23:48:30 schrieb Ulf Lamping: Das hat dann dazu geführt, daß ich nichts kaputt machen wollte und die angedachten Änderungen nicht hochgeladen und JOSM schlicht zugemacht habe. Meine Mutter hätte vermutlich genau so reagiert. JOSM kann mittlerweile ziemlich gut mit Relationen und ich weiß nicht wieso hier immer noch so viele Leute sich gegenseitig die Angst hoch schaukeln. Wer es noch nichtmal probiert ist selbst schuld. Man muss halt evtl vorher schauen *was* für ne Relation ist das und danach schauen ob sie noch Sinn macht. In der Regel sind es ja Routen-Relationen und da ist das Einfügen beider Wegteile (nach dem Split-Way) ja das einzig sinnvolle und das macht JOSM auch. Klar, ich kann darauf vertrauen das JOSM dafür zuständig ist das die Relationen beim editieren schon nicht kaputt gehen und es ist ja nicht mein Problem wenn Busrouten (oder was auch immer) danach nicht mehr stimmen. Ich kann auch ignorieren das es noch andere Editoren gibt, die sowas wohl noch viel eher kaputt machen. Ist nur nicht meine Art fahrlässig anderer Leute Arbeit kaputt zu machen. Ich habe hier nicht von hätte, könnte oder wollte gesprochen. Ich habe von einem konkreten (negativen) Effekt der Relationen gesprochen, die mir auch schon von anderen Mappern so berichtet wurde. Wenn da vor Ort nur eine (Art von) Relation vorhanden ist, kann man sich das schnell noch mal genauer anschauen. Wenn da aber mehrere Relationstypen und dutzende von Relationen im Spiel sind (Nürnberg), vergeht einem schnell die Lust sich durch den Wust zu arbeiten. Die (gefühlte) Wahrscheinlichkeit dabei was kaputt zu machen geht auch beim JOSM dann so gegen 100%. Ich habe keine Angst vor Relationen und selber auch schon eine Reihe davon angelegt. Mir ist aber bewußt, daß Relationen (inherent) eine zusätzliche Komplexität aufbauen, die man nur dann aufbauen sollte, wenn es *wirklich* notwendig ist (also z.B. eine Abbildung über Tags noch komplexer wäre). Gruß, ULFL P.S: Ja, die Editoren können hier sicher noch besser werden um die Komplexität zu vertuschen, aber ich finde es besser von vornherein Komplexität nur da aufzubauen wo sie unbedingt notwendig ist. KISS ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenz - warum nicht individuell?
Am 20.07.2010 12:21, schrieb Manuel Reimer: Christoph Wagner wrote: Wurde denn hier mal ernsthaft über PD diskutiert und das als Möglichkeit gesehen? *POPCORN!* Mal die letzten Threads gelesen? Ja so grob schon. Ich meine gibts Umfrageergebnisse oder sowas? Ich meine mich mal an sowas beteiligt zu haben. Will jetzt hier auch keine neue Diskussion anstacheln - gibt ja schon genug. Man kann sich natürlich auch ewig im Kreis drehen. Warum nicht einfach mit ODbL abfinden? Würd ich auch machen - klar. Was, wenn sich der entsprechende Mapper z.B. an Luftbildern bedient, die eben nicht PD sind? Klar - das geht dann eben nicht, dafür wäre das Ergebnis wirklich frei. Dazu kommt, dass ein Element, das von einem PD-Benutzer erstellt wurde, durch die erste Änderung eines ODbL-Benutzers direkt zu ODbL wird. Alle nicht-PD-Änderungen automagisch wieder von diesem Objekt zu bekommen, halte ich für nicht ganz trivial. Stimmt, kommt genau die Problematik raus wie die jetzige Diskussion um den Urheber eines Objektes. Ich seh schon ein, dass die Idee etwas dumm war. Hab nur laut gedacht ;) Sorry Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SOTM 2010 - feedback
Hier hat Holger Dieterich von http://wheelmap.org/ eine Zusammenfassung seiner Eindrücke von der SOTM auf Deutsch geschrieben: http://holgerd.posterous.com/ Bei der Geofabrik gibt es ebenfalls einen (sehr kurzen) Bericht: http://blog.geofabrik.de/de/?p=42 -Jonas Am 20.07.2010 um 10:06 schrieb Markus: Hallo Michael, gibt es denn schon Erfahrungs- und Erlebnisberichte? (in Deutsch) Gab es Mitschnitte von Veranstaltungen? Wo kann man sich diese anschauen/hören? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenz - warum nicht individuell?
Hallo, Christoph Wagner wrote: Wurde denn hier mal ernsthaft über PD diskutiert und das als Möglichkeit gesehen? PD bietet maximale Rechtssicherheit, maximale Freiheit und kommt damit meiner Intention bei OSM mitzumachen am nächsten. Ja, deswegen finden PD auch viele Leute gut. Unter anderem die halbe Mannschaft der License Working Group, nachdem sie sich jetzt lang genug mit den Alternativen herumschlagen durften. Der Trend ist etwa so: Jeder, der sich nicht richtig damit beschaeftigt hat, ist fuer Share-Alike, weil das auf dem Papier gut klingt (Stichwort man will sich ja nicht ausbeuten lassen usw.). Je mehr er sich mit Einzelfaellen beschaeftigt (ist dies und das jetzt noch erlaubt oder schon nicht mehr, was genau muss man tun um jenes zu erreichen, was passiert, wenn jemand in den USA dies macht und die Daten dann jemandem in Korea gibt, der dann eine Diskette in der Bahn liegen laesst und jemand anders findet sie...), ist er geneigt, zu sagen: Leute, lasst uns einfach PD machen und gut is'. Warum müssen eigentlich alle Mapper mit der selben Lizenz beitragen? Grundsaetzlich ist dual licensing keine schlechte Idee, das wird auch andernorts oft gemacht. Bei uns ist es natuerlich eine grosse technische Herausforderung, weil Objekte so stark voneinander abhaengen. Wenn jemand eine Strasse als Public Domain anlegt und ein anderer sie als ODbL weiterbearbeitet, dann muesste jemand, der eine Public Domain-Karte anfordert, praktisch die alte Version der Strasse sehen, die dann vielleicht nicht zu anderen Dingen passt, usw. Ich wuerde das aber auch begruessen, wenn es moeglich waere, praktisch eine Public Domain-Sicht auf die Karte zu haben, in der alles ausgeblendet wird, was mit Restriktionen belegt ist. Allerdings ist das derzeit nicht vorgesehen. Die ODbL schuetzt auch ungeschuetzte Elemente in der Datenbank, also hilft es niemandem was, wenn ich sage mein Beitrag ist PD - als Teil der Datenbank ist er trotzdem von der ODbL abgedeckt. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Liste, hallo Thomas, hallo Dietmar! 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'. Hier ist die Lösung, die sauber funktioniert: http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces Es wird getaggt: amenity=parking capacity=1 capacity:disabled=1 und optional: capacity:standard=0 So funktioniert es sauber und widerspruchsfrei. Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. Ja, da hab ich auch was dagegen. Tipp: Immer erst mal im Wiki nachlesen, was es schon gibt. Die Sachen sind da schon diskutiert. Gruß Lulu-Ann -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Am 20.07.2010 10:53, schrieb Frederik Ramm: Wird man in der odbl-DB die durch Nicht-Übernahme entstandenen Lücken durch abmalen von einem Old-Mapnik-WMS-Layer beheben dürfen ? Nein. Hmmm, OSM-neu wird also nicht von OSM-alt (der freien Weltkarte) abmalen dürfen lustich. Gibt es denn schon Aussagen zur Schmerzgrenze, also wieviel Prozent Datenverlust ist man bereit zu akzeptieren? Chris ___ 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 Dienstag 20 Juli 2010, 13:48:50 schrieb Ulf Lamping: Mir ist aber bewußt, daß Relationen (inherent) eine zusätzliche Komplexität aufbauen, die man nur dann aufbauen sollte, wenn es wirklich notwendig ist (also z.B. eine Abbildung über Tags noch komplexer wäre). Wo ist es denn deiner Meinung nach zu viel des Guten? Ich bin noch unschlüssig, wie ich die Routen-Relationen a la B 123 finde, aber alle anderen Routen-Typen die ich hier bei mir bisher gesehen habe finde ich sinnvoll (z.B. Buslinien, Grenzen, Multipolygone) und schwer bis gar nicht durch reines Tagging ersetzbar. Abbiegerelationen sind meiner Meinung nach ohne Relationen auch nicht zu machen aber für den aktuellen Zweck sind sie zu fragil definiert, da stimme ich dir zu. Werden aber auch nicht wirklich so sehr häufig benutzt, ich hab noch nie eine gesehen. Da eine größere Straße in einer größeren Stadt mit hoher Wahrscheinlichkeit einer Busroute, einer Rad-Route oder ähnlichem angehört, kommt man nicht drum herum, irgendwelchen Relationen zu begegnen. Wenn man aber sagt: Wenn ich eine Straße auftrenne, die vorher Teil einer Route war, dann sind nachher eben beide Teile in der Route, dann ist das so trivial, dass JOSM das richtig macht und es ist so trivial, dass man das verstehen kann. Leider kommt vor dem nüchternen Betrachten und ach, so kompliziert ist das ja gar nicht hier zu oft das kollektive Anti-Relationen-FUD und plötzlich denken alle, Relationen wären etwas komplexes. Gruß, Bernd -- Homer Simpson: Jetzt sei doch nicht so betrübt über Krustys Tod. Tagtäglich sterben viele Menschen. Das ist doch ganz normal. Vielleicht wachst auch Du morgen früh tot auf. 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] Schreckgespenst Datenverlust
Am Dienstag 20 Juli 2010, 14:38:11 schrieb Chris66: Hmmm, OSM-neu wird also nicht von OSM-alt (der freien Weltkarte) abmalen dürfen lustich. Findest du es genau so lustig, dass TeleAtlas und Navteq nicht bei uns abmalen dürfen? Sind ja auch nur Kartendienste mit anderer Lizenz. Gruß, Bernd -- Hoffnung ist nur ein Mangel an Information. 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] Radweg oder nicht Radweg?
Am Dienstag 20 Juli 2010, 13:26:36 schrieb M∡rtin Koppenhoefer: wobei mit path (bzw. designated/official?) ja eine Variante zur Verfügung steht, die das genauer abbilden kann, und daher verwendet werden sollte. Ich will keine neue Diskussion darüber anfangen sondern frage ganz nüchtern: Wie taggst du einen Radweg mit Fußgänger frei und wie einen Fußweg mit Radfahrer frei unter verwendung von path und welches ist der Mehrwert zu dem von dir schon gut beschriebenen alten Tagging? Gruß, Bernd -- Zuviel Freizeit kann dazu führen, daß die Menschen in Zukunft dazu übergehen, das zu tun, was sie schon immer gern getan haben, nämlich sich gegenseitig umzubringen. - Alexander Mitscherlich (dt. Psychoanalytiker und Sozialpsychologe) 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] Radweg oder nicht Radweg?
Am 20. Juli 2010 15:01 schrieb Bernd Wurst be...@bwurst.org: Am Dienstag 20 Juli 2010, 13:26:36 schrieb M∡rtin Koppenhoefer: wobei mit path (bzw. designated/official?) ja eine Variante zur Verfügung steht, die das genauer abbilden kann, und daher verwendet werden sollte. Ich will keine neue Diskussion darüber anfangen sondern frage ganz nüchtern: Wie taggst du einen Radweg mit Fußgänger frei und wie einen Fußweg mit Radfahrer frei unter verwendung von path und welches ist der Mehrwert zu dem von dir schon gut beschriebenen alten Tagging? Tagging steht im Wiki. Es ist im Prinzip egal ob altes oder neues Tagging, entscheidend ist yes vs. designated/official. highway=path bicycle=official foot=yes wäre m.E. z.B. eine Variante für Radweg mit Fußgänger frei. Ob man nun official oder designated nehmen soll ist mir nicht komplett klar, official ist aber wohl am eindeutigsten (wer will kann dann noch dt. Straßenschildnummern dazuschreiben), weil designated ja auch schon wieder desputed ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
Am 19.07.2010 um 21:56 schrieb M∡rtin Koppenhoefer: An einer Kreuzung sind _alle_ Schilder ein Stueck weit von der Kreuzung entfernt plaziert. ... ja eben Das Stueck weit resultiert aber aus rein praktischen Gesichtspunkten, da man eben schlecht das Teil direkt auf die Kreuzung plazieren kann ... +1 Was mich an dieser Diskussion stört ist, dass man dazu neigt, alle Schilder in einen Sack zu schmeissen. Schilder, die die Vorfahrt an einer Kreuzung regeln gelten selbstverständlich an der Kreuzung an der sie stehen und nicht erst am dem Punkt, wo man sie hingestellt hat Wir reden hier aber die ganze Zeit über das Einfahrtverbotsschild. Und das gilt halt nunmal da, wo es steht, bzw dort, in 50m wenn es das Zusatzschild sagt. Dann gibts noch Schilder, die so lange gelten, bis wieder ein Einmündung folgt (z.B. Vorfahtsstraßenschild), sie gelten aber ab da, wo sie stehen, nämlich nach der vorherigen Einmüdung. sie stehen niemals vor der Einmündung. Bei Kreuzungen ist das anderes. Da stehen die Vorfahrtsregelnden Schilder , wo auch die Ampel steht. Aber solche Feinheiten werden in der Fahrschule anscheinend nicht mehr gelehrt. Also bitte jedes Schild so interpretieren, wie es in der Wirklichkeit seine Gültigkeit hat und nicht alles in einen Sack schmeissen, nur um es als Argumentation verwenden zu können. Danke. keineswegs. Bei dem Schild handelt es sich um Verbot der Einfahrt, und das kann überall stehen, mit Kreuzungen hat das nichts zu tun. Man darf das Schild nicht in Richtung des Schildes passieren. +1 s.o. Ein Schild, das am Beginn einer Strasse steht, steht genau da: am Beginn der Strasse. Da die Strasse am Kreuzungsknoten beginnt, gilt es daher ab dem Kreuzungsknoten. nope -1 Erbsenzaehlen tue ich gerne da, wo es auch notwendig und sinnvoll ist, wo ich also wirklich ausdruecken will, dass es wichtig ist, dass ein kleines Stueck Weg andere Eigenschaften hat. Ansonsten muesste ich auch alle Speed-Bumps, Zebrastreifen etc. nicht mit einem einfachen Knoten, sondern mit einem Mini-Stueck Weg modellieren, da ja alles eine gewisse Ausdehnung aufweist. kommt drauf an, Ausdehnungen in die Breite sind m.E. eigentlich erst sinnvoll, wenn Du die Straßenfläche auch drin hast. In der Länge würde ich dagegen durchaus auf Präzision achten. +1 Du siehst das deutlich eingeschraenkter, wobei mir beispielsweise nicht klar wird, wo die Strasse nun bei einer Kreuzung fuer dich nun anfaengt (bzgl. des Schildes oder allgemein): - am Kreuzungsmittelpunkt, - am Schnittpunkt der verlaengerten Fahrbahnbegrenzungen der Querstrasse mit der Mittellinie der Strasse, - am Ende der Eckausrundung, Was hat diese Diskussion mit dem Thema des Threads zu tun? das spielt für die Frage hier keine Rolle, +1 steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
Am 19.07.2010 um 23:04 schrieb Tirkon: Mitunter ist es offenbar absichtlich ein paar Meter in die Straße hinein gestellt, z.B. um es wahrnehmen zu können und das Wenden zu ermöglichen, Eben und genau aus dem Grunde gilt das Einfahrtverbotsschild ja auch erst ab da, wo es steht. Sonst dürfte man ja nicht bis dahin fahren, um überhaupt ans Wenden denken zu können ;-) um vorne liegende Ziele noch erreichen zu können oder dort abseits einer stark befahrenen Straße als Nothaltebucht zu nutzen. Insofern würde ich es da mappen, wo es steht. +1 eben. Etwas anders wäre beispielsweise das Geisterfahren falsch herum in eine Abfahrt hinein, Ich bin mir fast sicher, dass die StVO sagt, dass die Einfahrt _an dieser Stelle_ nicht erst ab dem Schild gilt. Es wäre auch zu gefährlich. sofern dies nicht ohnehin per durchgezogener Mittellinie angezeigt ist. Da sollte man auch die möglichen Meter nicht nutzen. Aber da taggen wir der Einfachheit und Übersichtlichkeit wegen ebenso wie einige andere Kartendienste ohnehin mit Einbahnstraßen. Auch weil es faktisch welche sind. Autobahnen und ähnlich ausgebaute Straßen müssen nur nicht extra dafür mit Einbahnstraße ausgeschildert sein, da die Verkehrsregelung für Autobahnen dies aussagt, dass man hier nur in einer Richtung fahren darf. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Ulf Lamping ulf.lamp...@googlemail.com wrote: Abmalen ist aber - wie auch von Google o.ä. - nicht möglich. Da zeigt sich, wie falsch dieser Satz ist: Du brauchst nur OSM als Quelle anzugeben und gut ist. ___ 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: Florian Gross wrote: Ich hab nicht geschrieben, daß ich mich dagegen wehren würde, sollte etwas zurückkommen. ;-) Und ich würde es eben lieber in der Lizenz festgeschrieben wissen, dass Unternehmen die Veränderungen freigeben müssen. Dann wären das meinem Verständnis nach keine freien Daten mehr. Sollen die Daten dann eingeklagt werden, falls sich ein Unternehmen nicht an die Lizenz hält? flo -- Ach was, so ein bisschen Strom macht doch einem alten Elektriker nichts aus.. ...jaja, *sicherungsrausdreh* *reinlang* Jo, dor is Strom in [cmt und MOW in dasr] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 20.07.2010 um 14:38 schrieb lulu-...@gmx.de: Hallo Liste, hallo Thomas, hallo Dietmar! 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'. Hier ist die Lösung, die sauber funktioniert: http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces Es wird getaggt: amenity=parking capacity=1 capacity:disabled=1 und optional: capacity:standard=0 So funktioniert es sauber und widerspruchsfrei. Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. Ja, da hab ich auch was dagegen. Tipp: Immer erst mal im Wiki nachlesen, was es schon gibt. Die Sachen sind da schon diskutiert. Hallo Lulu-Ann, vlt. konntest Du diese Diskussion nicht vollständig verfolgen. Ich erlaube mir, Dich mal auf den aktuellen Stand zu bringen, auch wenn ich voll Deiner Meinung bin. 1. Das Problem ist , dass hier manche sagen, ein Behindertenparkplatz sei, trotz seines Namens und dem Schild, das auch Parkplatz heisst, gar kein Parkplatz (deshalb sei amenity=parking, siehe wiki, falsch), sondern ein Parkstand. Sie möchten für Parkstände einen eigenen Tag. 2. Parkstände für Motorräder sollten auch einen eigenen Tag bekommen, weil sie nicht in die gleiche Kategorie wie Frauenparkplatz und Elternparkplatz fallen, die ja eigentlich für 4-rädrige KFZ sind ... 3. Ich bin genervt, da es für Parkstände (Definition siehe wikipedia bitte) aber schon ein Proposal gibt, das das per Tag für parking:lane regelt. Ich bin mittlerweile der Meinung, dass man die Defintion für amenity=parking auf Parkstände erweitern sollte, dann wäre es alles einfach zu taggen. Sowohl einzelne, als auch gemischte Parkplätze/Stände. Doch auch dies scheitert an zwei Tatsachen: 1. Wenn es eigene Tags für Frauenparkplatz, Elternparkplatz, Motorradparkplatz, Behindertenparkplatz usw. gäbe, dann könnte man diese auch per Node auf einem großen Parkplatz als POI eintragen, dass man auf der Karte auch sieht, wo sich diese jeweils auf diesem befinden. Eine Unterteilung des großen Polygon in kleinere (oder mit inner und outer-polygonen) mit entsprechendem Tagging für diese Spezialparkplätze, sei auch nicht in Ordnung, da es ja dann mehrere Parkplätze wären ,diese aber auf einem großen amenity=parking vereinigt sind und nur Parkstände innerhalb des amenity=parking sind. 2. Mein Vorschlag per parking:lane die Lokalisation des Behindertenparkplatzes auf dem amenity=parking zwischen zwei Knoten des service per parking:lane anzugeben scheiterte hier an dem Argument, dass das zu kompliziert zu taggen sein, wenn man eben mal ein paar Behindertenparkplätze eintragen möchte. Ich bin am Ende, denn es wird hier keine Lösung gefunden werden. Schon diskutiert, oder auch nicht, denn wenn amenity=parking nur explizit für Parkplätze mit parking_aisles gelten darf, wie dessen Exklusivität derzeit im wiki interpretiert wird. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenverlust
Markus liste12a4...@gmx.de wrote: Deahalb habe ich mal ein paar konkrete Idee zusammengefasst: http://wiki.openstreetmap.org/wiki/DE:Datenverlust_bei_Lizenzwechsel Dort heißt es: |Luftbilder aus Bayern | |In den Nutzungsbedingungen steht: | | Die zeitlich befristete Nutzung der DOP-Daten beinhaltet | das Recht, die während der Tesphase erhobenen Vektordaten | im OSM-Projekt dauerhaft und frei zu nutzen. |freibedeutet hier PD (oder so). |Damit sind schon mal 2 Mannjahre Arbeit gesichert, egal welche Lizenz wir wählen. Die Luftbilder wurden nicht 1:1 importiert. Vielmehr haben die Mapper von Hand aus den Luftbildern abgemalt und damit dasselbe getan, was man mit den GPS-Spuren macht. Daher könnte der Beitrag des Abmalers hier eine Rolle spielen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fragen zur OSM-Lizenzvererbung
Die alte Lizenz CC by SA besagte, dass man das Material beliebig verändern darf. Dabei müsse aber das so entstandene Gesamtwerk wiederum CC by SA lizensiert werden. Ich weiß nicht, ob die neue Lizenz das ebenso regelt. Ich gehe mal davon aus, dass dem so ist, da dies bei freier Software ähnlich geregelt ist. In vielen Fällen wird die OSM Karte in einem, Fremdelemente in einem anderen Layer dargestellt. Die Frage ist, ob zwei Layer - komponiert dem Publikum präsentiert - schon als Gesamtwerk gelten. Wenn nicht, dann ist die oben genannte Klausel damit ausgehebelt. Ich kann dann sogar auf Papierkarten meine eigenen Objekte hinzufügen. Dazu brauche ich die OSM Karte nur auf Papier zu drucken und eine Folie mit eigenen Objekten drüber zu kleben. Um das Ganze weiter herauszuarbeiten, hier zwei verschiedene Wege, OSM Material mit Fremdmaterial zu vereinigen, das Ergebnis aber dasselbe ist: Im ersten Falle vereinige ich kurzfristig Material aus der OSM Datenbank und aus einer weiteren Datenbank und rendere diese Komposition im Internet mit Mapnik. Im anderen Falle rendere ich beide getrennt mit Mapnik und lege die Daten in zwei Layern übereinander. Raus kommt in beiden Fällen dasselbe. In welchem der Fälle kann man von Vereinigen sprechen? Wo also fängt Vereinigen an und wo hört es auf? Was ist, wenn das OSM Datenmaterial vom Inhaber oder Lizenznehmer eines proprietären Renderers mit selbigem gerendert veröffentlicht wird? Ist das nicht auch ein resultierendes Werk und wird damit das so erzeugte Bild auch frei? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Markus glaubte zu wissen: Hallo Wolfgang, 2 neue DBs, eine unter CC0 und eine unter ODBL. Wer mappt, kann ankreuzen, für welche DB. Cool! Ich kreuze beide an :-) Das war auch mein Gedanke. *g* flo -- Finde ich auch immer wieder putzig, wie aus Bakterien in den Joghurt-Werbungen lebende Kulturen werden. Dürfen Vegetarier sowas überhaupt essen...? Vegetarier dürfen alles essen. Sie wollen bloß in vielen Fällen nicht. [Bettina Fink, Stefan Wust und Ralph Angenendt in daff] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Sind Relationen komplex? was: Zum 1 000. mal - Hausnummern und Straßennamen?
Am 20.07.2010 14:55, schrieb Bernd Wurst: Leider kommt vor dem nüchternen Betrachten und ach, so kompliziert ist das ja gar nicht hier zu oft das kollektive Anti-Relationen-FUD und plötzlich denken alle, Relationen wären etwas komplexes. Hier mein Geständnis: Ich finde den Umgang mit Relationen auch komplex. Wenn ich einen Weg bearbeite, der in einer Relation enthalten ist, fühle ich mich oft unwohl - habe ich wirklich alles richtig gemacht? Mit Relationen im Allgemeinen kenne ich mich natürlich aus. Ich habe sogar schon Software programmiert, die Relationen auswertet. Was mir aber Probleme macht: Es gibt nicht die Relation, sondern viele unterschiedliche Arten von Relationen - prinzipiell kann OSM-typisch sogar jeder seine eigene erfinden. Die Situation, vor der ich hier stehe, ist diese: * Jeder Relationstyp hat seine eigenen Regeln. (Manchmal spielt die Reihenfolge der Mitglieder eine Rolle, manchmal nicht. Manchmal brauchen die Mitglieder Rollen. Unter Umständen darf es jede Rolle nur einmal geben - oft aber auch mehrmals. Und so weiter.) * Diese Regeln sind nicht in Software gegossen, sondern Konventionen. * Der von mir genutzte Editor JOSM geht infolgedessen nicht automatisch korrekt mit Relationen um, wenn man eine seiner eingebauten Operationen - Weg teilen, vereinigen, etc. - verwendet, sondern erfordert manuelle Eingriffe. Folge: Ich muss die Regeln des von der Bearbeitung betroffenen Relationstyps kennen, um eine Beschädigung der Relation ausschließen zu können. Bei den Typen, mit denen ich vertraut bin (weil ich mich für das entsprechende Thema interessiere und solche Relationen auch selber bearbeite und anlege) ist das natürlich der Fall. Aber manche habe ich eben noch nie selber verwendet, und in einigen Bereichen fühle ich mich auch überfordert, bei den unterschiedlichen Verfahren und Proposals auf dem aktuellen Stand zu bleiben. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Am Dienstag 20 Juli 2010, 18:33:58 schrieb Tirkon: Um das Ganze weiter herauszuarbeiten, hier zwei verschiedene Wege, OSM Material mit Fremdmaterial zu vereinigen, das Ergebnis aber dasselbe ist: [...] Das ist einer der Gründe, warum die Lizenz CC-by-SA eben nicht so recht zu unseren Daten passt. Die ODbL regel übrigens die von dir angesprochenen Fälle sehr viel expliziter und sollte in solchen Standardsituationen zu einer verlässlichen Aussage kommen. Gruß, Bernd -- I believe in making the world safe for our children, but not our children's children, because I don't think children should be having sex. - Jack Handey 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] Sind Relationen komplex?
Hallo. Am Dienstag 20 Juli 2010, 19:18:27 schrieb Tobias Knerr: * Jeder Relationstyp hat seine eigenen Regeln. (Manchmal spielt die Reihenfolge der Mitglieder eine Rolle, manchmal nicht. Manchmal brauchen die Mitglieder Rollen. Unter Umständen darf es jede Rolle nur einmal geben - oft aber auch mehrmals. Und so weiter.) * Diese Regeln sind nicht in Software gegossen, sondern Konventionen. * Der von mir genutzte Editor JOSM geht infolgedessen nicht automatisch korrekt mit Relationen um, wenn man eine seiner eingebauten Operationen - Weg teilen, vereinigen, etc. - verwendet, sondern erfordert manuelle Eingriffe. Ich bleibe bei meiner Meinung, dass die *verbreiteten* Relationen einfach sind. In dem Sinne, dass maximal ein automatisches Sortieren der Elemente nötig ist um den korrekten Zustand zu erhalten. Meistens nichtmal unbedingt das. Dennoch ist das natürlich ein Punkt und es gibt ja sehr viele Relationen- Konventionen, die sich augenscheinlich mal eben jemand kurz vor dem (viel zu späten) Schlafengehen ausgedacht hat. Daher wäre es doch wünschenswert, wenn JOSM dem interessierten Benutzer irgendwo einen Link zur Wiki-Seite des betreffenden Relations-Typen zeigen könnte. Ich boykottiere das Wiki i.d.R., daher bin ich da jetzt nicht so firm: Kann man die Doku zu den Relations-Typen irgendwo per algorithmisch erkennbarem Seitentitel aufrufen? Wenn nicht, wäre eine Zuordnungs-Liste vielleicht gut (im Wiki), die type=?? auf eine Wiki-Seite leitet. Dann könnte man (auch wenn ich gerne glaube dass einige Leute da nicht so recht Bock drauf haben) sich kurz die Dokumentation anschauen wenn man nicht weiter weiß. Gruß, Bernd -- Auf einem Baum, da saß ein Specht. Der Baum war hoch, dem Specht war schlecht 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] Fragen zur OSM-Lizenzvererbung
Am 20.07.2010 18:33, schrieb Tirkon: Die alte Lizenz CC by SA besagte, dass man das Material beliebig verändern darf. Dabei müsse aber das so entstandene Gesamtwerk wiederum CC by SA lizensiert werden. Ich weiß nicht, ob die neue Lizenz das ebenso regelt. Ich gehe mal davon aus, dass dem so ist, da dies bei freier Software ähnlich geregelt ist. Die neue Lizenz unterscheidet ausdrücklich zwischen abgeleiteten Datenbanken und Produced Works. Letztere umfassen Dinge wie Bitmaps oder Ausdrucke - Resultate eines Verarbeitungsprozesses also, aus denen man nicht mehr ohne weiteres die Rohdaten zurückgewinnen kann - und diese erfordern nur eine Namensnennung, nicht aber eine Weitergabe unter derselben Lizenz.* In vielen Fällen wird die OSM Karte in einem, Fremdelemente in einem anderen Layer dargestellt. Da du den OSM-Layer nicht unter der ODbL veröffentlichen musst, sondern eine beliebige* zu den Auflagen der anderen Layer kompatible Lizenz wählen kannst (siehe oben), wäre so etwas auf Basis von ODbL-OSM-Daten praktisch immer legal. Genau diese Klarstellung das ist übrigens eine beabsichtigte Vereinfachung für Weiternutzer. Im ersten Falle vereinige ich kurzfristig Material aus der OSM Datenbank und aus einer weiteren Datenbank und rendere diese Komposition im Internet mit Mapnik. Im anderen Falle rendere ich beide getrennt mit Mapnik und lege die Daten in zwei Layern übereinander. Da du bei letzterem Vorgehen OSM nur in Form eines Produced Work verwendest, ist es ohne Share-Alike-Auflage möglich, wieder wie oben. Beim Vereinigen von Daten: Wenn du keine Veränderungen an den beiden Datensätzen vornimmst, sondern sie unverändert in den Renderer steckst, gilt dasselbe. (Es handelt sich dann sich um eine sogenannte Sammeldatenbank.) Würdest du aber z.B. erst die Lage von OSM-Straßen auf Basis deiner Infos verändern, dann müsstest du die resultierende - von OSM abgeleitete - DB unter ODbL freigeben. Tobias Knerr * aussuchen kann sich das natürlich nur der, der das Produced Work anfertigt, also z.B. die Karten rendert. Wer fertige Produced Works verwendet (etwa die Kacheln von openstreetmap.org) muss sich an deren jeweilige Lizenzen halten, die dann durchaus auch Share-Alike-Bestimmungen enthalten können. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Wäre es z.B möglich, dass ein Anwender nach einer Lizenzumstellung die alten CC-BY-SA mit den aktuelle, unvollständigen ODbL Daten zusammenfasst und daraus eine Karte erstellt? Unter welche Lizenz müsste er dieses Werk dann stellen? -- View this message in context: http://gis.638310.n2.nabble.com/Fragen-zur-OSM-Lizenzvererbung-tp5317403p5317787.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] Announce: Die Hausbrauereikarte - Open Brewpub Map
Sven Geggus li...@fuchsschwanzdomain.de wrote: *urgs* ich gebs zu ich hätte das mit dem Netbook testen sollen. Mal schaun ob ich die Tage dazukomme das zu fixen. Sch*** css, mit jedem Browser anders :( Ich hab das jetzt mal schnell mit klassischem Tabellenlayout gemacht. Nicht schön aber tut. Im Gegnsatz zu vorher auch im IE8 und auf meinem Netbook mit 1024x600 Auflösung. Getestet sind derzeit IE8, FF und chrome. Die letzeren beiden tun am besten. Mit IE8 gibts ein paar kleinere Macken. Wer damit Probleme hat soll patches schicken! Ist eigentlich der IE6 noch in relevanter Zahl in freier Wildbahn vertreten? Ich nehm mal an mit dem gehts eher nicht hab aber keine Möglichkeit mehr damit zu testen. Gruss Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Am 20.07.2010 17:27, schrieb Tirkon: Ulf Lamping ulf.lamp...@googlemail.com wrote: Abmalen ist aber - wie auch von Google o.ä. - nicht möglich. Da zeigt sich, wie falsch dieser Satz ist: Du brauchst nur OSM als Quelle anzugeben und gut ist. Bitte im Zusammenhang. Du darfst natürlich *nicht* von alten Tiles die CC-By-SA geschützten Daten durch abmalen in ODbL-Lizenzierte überführen. In den USA vielleicht, aber das war ja der Grund für das ganze Theater. -- 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] Datenverlust
Hi ... , Die Luftbilder wurden nicht 1:1 importiert. Vielmehr haben die Mapper von Hand aus den Luftbildern abgemalt Richtig. und damit dasselbe getan, was man mit den GPS-Spuren macht. Nicht ganz. GPS-Spuren gehören (meistens) dem Abzeichner selbst. Er darf also entscheiden, wie die Tracks verwendet werden dürfen. Bei den Luftbildern hat das Ministerium entschieden, dass die Produkte für immer frei sind. OSMer, die im Rahmen des Projektes unter diesen Bedingungen Luftbilder abgemalt haben, taten das zu diesen ihnen bekannten Bedingungen. Rechtlich taten sie das in der Rolle des Erfüllungsgehilfen. Natürlich darf die OSMF die PD-Daten nehmen und unter einer anderen Lizenz veröffentliche. Das ändert aber praktisch nicht: die Daten bleiben unter PD (sie sind halt dann doppelt lizenziert). Entscheidend für die künftige Praxis ist hingegen, wieweit die PD-Daten durch nachträgliche Änderungen infiziert wurden, also welche Datenmenge dadurch kaskadisch verloren geht. Gruss, Markus PS: ich hoffe ich habe Deine implizite Frage/Aussage richtig interpretiert? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lizenzverpflichtung für Nutzer von OSM D aten?
Es wird hier viel darüber diskutiert, welchen Lizenzvereinbarungen die Mapper zustimmen sollen. Dass ein Nutzer von OSM irgend einer Lizenzvereinbarung zustimmen soll, ist mir bisher nicht begegnet, alles kann frei, dh. ohne einen Klick auf ein Kästchen, ich stimme zu heruntergeladen werden. In allen mir bekannten Planet Datei (*.osm), ist der geringste Hinweis auf eine Lizenz, wie es z.B. in dem meisten GPL Programm-Texten vorhanden ist. Beim download mit wget wget http://www.informationfreeway.org/api/0.6/* bekommt man nichts von einer Lizenz zu Gesicht. Vielleicht wird auch dadurch teilweise der falsche Eindruck erweckt, die OSM Daten sind völlig frei. In zu Lambertus Karten-Daten kommt dagegen eine ..._license.txt mit, in der auf Lizenz verwiesen wird. -- View this message in context: http://gis.638310.n2.nabble.com/Lizenzverpflichtung-fur-Nutzer-von-OSM-Daten-tp5317860p5317860.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] Fragen zur OSM-Lizenzvererbung
Hallo, fx99 wrote: Wäre es z.B möglich, dass ein Anwender nach einer Lizenzumstellung die alten CC-BY-SA mit den aktuelle, unvollständigen ODbL Daten zusammenfasst und daraus eine Karte erstellt? Ja. Das muesste dann unter CC-BY-SA veroeffentlicht werden, und das gestattet die ODbL auch. Man muss nur ein kleines bisschen vorsichtig sein, dass man nicht bei dem Vorgehen eine abgeleitete Datenbank erstellt, aber das kriegt man hin. Tirkon hat uebrigens recht damit, dass es sein kann, dass ein und dasselbe Resultat je nach Herstellungsverfahren eine Share-Alike-Datenbank nach sich ziehen kann oder nicht. Das ist ein bisschen kurios, aber auch mit der jetzigen Lizenz laesst sich sowas konstruieren. Angenommen, ich male ein Bild, veroeffentliche es PD, und appliziere darauf mit XOR ein OSM-Karten-Tile. Lizenz ist nun, gezwungenermassen, CC-BY-SA. Jemand anders nimmt dieses Kunstwert, XORt das gleiche Karten-Tile an die gleiche Stelle - Lizenz immer noch CC-BY-SA, obwohl im Resultat nichts mehr von OSM drin ist, er haette auch gleich mein PD veroeffentlichtes Bild nehmen koennen. 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] Fragen zur OSM-Lizenzvererbung
Hallo, Am 20. Juli 2010 20:03 schrieb fx99 f...@vollbio.de: Wäre es z.B möglich, dass ein Anwender nach einer Lizenzumstellung die alten CC-BY-SA mit den aktuelle, unvollständigen ODbL Daten zusammenfasst und daraus eine Karte erstellt? Unter welche Lizenz müsste er dieses Werk dann stellen? -- CC-by-SA Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
Am 20.07.2010 20:06, schrieb Sven Geggus: Mit IE8 gibts ein paar kleinere Macken. Wer damit Probleme hat soll patches schicken! Ist eigentlich der IE6 noch in relevanter Zahl in freier Wildbahn vertreten? Ich nehm mal an mit dem gehts eher nicht hab aber keine Möglichkeit mehr damit zu testen. Der IE6 ist in größeren Firmen durchaus noch im Einsatz. Die allermeisten Leute dürften aber eher mit neueren Versionen unterwegs sein. Um den IE6 würde ich mir aber eher keine großen Gedanken mehr machen. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Am 20.07.2010 14:58, schrieb Bernd Wurst: Hmmm, OSM-neu wird also nicht von OSM-alt (der freien Weltkarte) abmalen dürfen lustich. Findest du es genau so lustig, dass TeleAtlas und Navteq nicht bei uns abmalen dürfen? Sind ja auch nur Kartendienste mit anderer Lizenz. Prinzipiell würde ich Karten begrüßen, die das beste aus beiden Welten kombinieren, zB. das bessere Car-Routing und die bessere Abdeckung im ländlichen Bereich der Kommerziellen mit den besseren Daten bei Fuß- und Radwegen bei OSM. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Hallo, Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist: Das Problem der drehenden Wege bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden. Ich sehe da OSM einfach bei einer Grenze angekommen. - Ich verstehe, die Befürworter von Relationen für die Abbildung von Wegeigenschaften, die sich nur auf eine Straßenrichtung beziehen (z.B. maxspeed:forward, parking:lane:right, destination:forward, etc.), da mit Relationen eine Richtung festgelegt werden kann, egal wie der Weg gedreht ist. - Ich verstehe aber auch die Bedenken derer, die das lieber getaggt haben, um zu verhindern, dass irgendwann _alles_, was eine Straßenrichtung betrifft, in Relationen gefasst wird. Ich halte beide Version für unübersichtlich und aufgrund der Komplexität beider Varianten auch fehlerträchtig. - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von Linienbündeln und Fahrspurtagging gelesen. Doch welche Konzepte gibt es bisher? Wie weit sind wir dahin? Steckt OSM da derzeit fest? Warum gehts nicht weiter? -- Ich meine, aufgrund dieser unbefriedigenden Situation gibt es eigentlich immer nur eine Diskussion: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Bei genauerem Hinsehen, kommt immer das gleiche heraus: Uneinigkeit, weil es natürlich für beide Varianten Vor- und Nachteile gibt. Sprich wir treten alle auf der Stelle. Doch die Anforderungen an OSM sind gestiegen und deshalb benötigen wir eine Erweiterung unseres bisherigen Datenmodells (so sagt man das doch?) - Mein Vorschlag ist sicher nicht neu und ich behaupte _nicht_, damit den Stein der Weisen gefunden zu haben! 1. Die bisherige Struktur von Nodes und Ways wird beibehalten und kann bei Bedarf an bestimmten Stellen (hier nur für Straßen!) erweitert werden. 2. Diese Erweiterung für Straßen sollte auf diese Weise einfach (von Anwenderseite gesehen) möglich sein: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Ich würde diese Funkion Gruppierung nennen und könnte durch eine gemeinsame abstrakte Signatur/ID erreicht werden, die von der DB (oder einem Algorithmus aus den way-id's jedes mal neu errechnet wird, wenn ein way dazukommt, oder abgezogen wird) vergeben wird. b) Diese way-Gruppe könnte in JOSM so dargestellt werden, dass jeder way beim Zeichnen automatisch parallel ausgerichtet wird und mit einer gemeinsamen Hintergrundfarbe hinterlegt ist. Das zeigt, das es sich um einen way im bisherigen Sinne ohne bauliche Trennung handelt. c) Festlegen der Richtung beider ways wie bisher auch und ein Schlosssymbol setzen, das verhindert, dass jemand diese Richtung ändern kann, ohne von JOSM rückgefragt zu werden. d) Taggen der entsprechenden Eigenschaften für die jeweilige Richtung. 3. Wenn man auf solch ein way-Gruppierung stößt, dann weiss man in DE, dass Rechtsverkehr herrscht und dann ist klar, in welcher Richtung -also auf welchem der beiden ways was getaggt weden muss, wenn man die Wirklichkeit abbilden möchte. 4. Es könnten mehrere ways für eine Fahrtrichtung in der Gruppe sein. Z.B. zwei zeigen in die eine Richtung, einer zeigt in die andere. Dadurch wäre auch Fahrspurtagging möglich und durch das Schlosssymbol in JOSM und Potlatch(?) wird man vorsichtig beim Ändern der Way-Richtung. 5. Nun muss noch was gegen die Redundanz gemacht werden: Anlegen eines Datenways. a) Eine Straße, die z.B. je eine Fahrspur in jeder Richtung hat, wird mit _drei_ ways gezeichnet. b) Der mittlere way ist der Datenway, auf ihm werden alle Tags untergebracht, die für die _gesamte_ way-Gruppe gelten, wie z.B. highway= secondary, name=Bündelstraße, ref=B 19. als auch die Relationen-Teilnahme, die für alle ways des Bündel gelten. c) auf den ways links und rechts werden nur die tags untergebracht, die für die jeweilige Richtung gelten, z.B. maxspeed=50 und gegenüber auf dem anderen way maxspeed=40 d) Der mittlere way entspricht der derzeitigen Umsetzung für die mittlere Geographische Lage für ways. Er sollte möglichst die Mitte der Straße darstellen. e) was tun bei drei Fahrspuren? Der datenway wird zwischen beide Fahrtrichtungen gelegt und ist dann insgesamt gesehen der vierte way. 6. Nun zum Rendern und der Darstellung in JOSM: a) exisitert nur ein way, wird verfahren, wie bisher auch, um die Abwärtskompatibilität zum aktuellen Datenbestand zu erhalten b) _gleichzeitig mit der Einführung des datenway_ sollte es
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
Tolle Karte, demnächst sollte auch hier etwas auftauchen: http://hausbräu.openstreetmap.de/?zoom=10lat=29.45194lon=-98.36656layers=BT Es wäre schön, wenn man die Aktualisierungszeit sehen könnte. -- View this message in context: http://gis.638310.n2.nabble.com/Announce-Die-Hausbrauereikarte-Open-Brewpub-Map-tp5312552p5318123.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] Radweg oder nicht Radweg?
Manuel Reimer schrieb: Heiko Jacobs wrote: So wie's aussieht, ist's schon recht getaggt... Kleine Inkonsistenz zwischen bicycle=designated und bicycle=yes, würde ich auf letzteres vereinheitlichen. Da wäre ich vorsichtig! Zumindest bicycle=designated heißt in Deutschland wohl Benutzungspflichtiger Radweg und der liegt hier wohl eher nicht vor. Eben. Deswegen letzteres Zudem ist Benutzungspflicht ja/nein bei eigenständigen, also nicht straßenbegleitenden Wegen, gehupft wie gesprungen ... bicycle=yes ist dann wohl sowas wie Radfahrer frei. Also nicht benutzungspflichtig. Entweder das oder einfach kein Schild mit weißem Rad auf blauem Grund weit und breit ... Da man hier mit Schildern Radfahrer aber eher warnen will, ist das wohl auch nicht Radfahrer frei. Wie gesagt: der Versuch schlug fehl, weil dieses Schild in der StVO nicht vorkommt. Hätte die selbe Relevanz als wenn dort stünde Nur für Radfahrer mit roter Hose. Nur zwei Sachen machen einen Weg wirklich eindeutig zum reinen Gehweg: - Ein mit Bordstein von der Fahrbahn abgetrennter Weg - Ein Schild Gehweg mit der typischen weißen Kleinfamilie auf blauem Grund Ohne Schild ist theoretisch jede öffentlich zugängliche Fläche (dann gilt StVO) mit allem benutzbar - wenn nicht Waldgesetze und analoges für Feldwege dagegen sprechen - Wege in Grünanlagen von Orten mit Grünanlagenverordnung, wobei ich da die Tage noch in de.soc.recht.strassenverkehr gerne einen Fall zur Klarstellung durchdiskutieren will ... Rein praktisch sehe ich aber auch einen separat geführten Weg, der in eine andere Straße mündet, nur dann als Radweg an, wenn der Bordstein abgesenkt ist, andernfalls als Gehweg. In meiner Umgebung habe ich da selber schon Radwege umgebaut, um die Benutzungspflicht, wo nicht gegeben, entsprechend rauszunehmen. Als Radfahrer sind oft gerade solche Bereiche interessant, da man da je nach Route entscheiden kann, ob man den nicht benutzungspflichten Radweg nutzen will oder nicht. Das wäre auch mein Wunsch-Zielzustand als Amliebstenfahrbahnradler ;-) Ist hier aber nicht relevant. Laut http://wiki.openstreetmap.org/wiki/Key:access wäre wohl bicycle=unknown denkbar. Ich würde für die fragliche Stelle das bicycle-Tag ganz löschen. Was nicht explizit verboten ist, kann jeder vor Ort für sich entscheiden, ob er es für machbar hält. Das die Unterführung offenbar zum Radverkehrsnetz NRW gehört, ist ein starkes Indiz dafür, dass sie dafür gedacht ist, überregionalen Radverkehr aufzunehmen. Ich vermute stark, dass dort auch eine Radverkehrswegweisung durchweist. Soweit ich weiß, haben die NRWler schon ziemlich flächendeckend beschildert. Dass die Unterführung dafür offenbar nicht umwerfend gut geeignet ist, ist ein anderes Thema, weswegen ich ja empfahl, sich bei der radnetzkoordinierenden Stelle mal nachzuhaken... Ich habe in meinem Gebiet auch fast alle bicycle=no gelöscht, da diese Wege nicht direkt für Fahrräder verboten und mit dem Mountainbike durchaus passierbar waren. Hier und da habe ich stattdessen mtb:scale nachgetragen. verboten und unmöglich wird beim tagging (leider noch?) nicht unterschieden, von daher kann man es bisher für beides verwenden. bicycle=no hebe ich auch auf, wenn es auf befahrbaren Wegen kein Radwegverbot gibt (und für Kraftfahrstr. gibt es ein eigenes tag) no für unmöglich verwende ich äußerst sparsam. - Ein Trampelpfad direkt an einer Abbruchkante eines Baggersees - Ein Trampelpfad haarscharf an einem Zaun entlang, en radgeeigneter anderer Trampelpfad mit derselben Verbindungsfunktion 10 m nebendran - Ein buckeligen Weg über einen historischen Wall neben einem normalen Weg Da muss nun wirklich kein Router über diese drei drüber routen, nur weil diese womöglich wenige Meter kürzer sein mögen. Der dritte wird offenbar sogar von MTBlern genutzt. Den lokalen MTBlern muss ich das nicht mehr zeigen und MTBler von auswärts muss ich nicht auch noch dazu einladen, ein hisorisches Relikt weiter zu erodieren ... (oder wie heißt das Verb zu Erosion?) Für die habe ich eh schon genug tracktype=grade5 smoothness=horrible gemappt ;-) Da ich vom echten Mountain-biking keinen Schimmer habe, lasse ich von mtb:scale meine Finger ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
fx99 f...@vollbio.de wrote: Tolle Karte, demnächst sollte auch hier etwas auftauchen: http://hausbräu.openstreetmap.de/?zoom=10lat=29.45194lon=-98.36656layers=BT Es wäre schön, wenn man die Aktualisierungszeit sehen könnte. Baue ich die tage noch rein das steckt die selbe Datenbank wie bei der Open Link Map dahinter. BTW, das hier finde ich ja cool: http://hausbräu.openstreetmap.de/?zoom=18lat=35.3873lon=133.46704layers=BT Gruss Sven -- Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär, und - dank Knut - insbesondere der Eisbär, deutlich größerer Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
Rainer Knaepper schrieb: Zuständigen Planer teeren + federn und so auf dem Rad da durch jagen ;-) Die dürften im Ruhestand sein, die Anlage ist afaik über 20 Jahre alt. Dann ist's Zeit für eine Generalrenovierung samt radkompatiblen Umbau mir kam auch der Gedanke, wie jemand auf einem Liegerad wohl da durchkommen soll. Auch die Kurven sind sehr eng :-) Pfff... Liegerad ... Peanuts ... Das ist steigerungsfähig: http://heiko-jacobs.de/jacobs/rad/anhaenger3.jpg Leider bishe rnur 1x so unterwegs gewesen und das auch nicht weit ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzverpflichtung für Nutzer von OSM D aten?
fx99 schrieb: In allen mir bekannten Planet Datei (*.osm), ist der geringste Hinweis auf eine Lizenz, wie es z.B. in dem meisten GPL Programm-Texten vorhanden ist. In einer beliebig rausgegriffenen steht janz vorne: osm ... osmxapi:copyright='2008 OpenStreetMap contributors' ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzverpflichtung für Nutzer von OSM D aten?
Der Übeltäter scheint osmosis zu sein: wget http://www.informationfreeway.org/api/0.6/*[bbox=] ?xml version='1.0' encoding='UTF-8'? osm version='0.6' generator='xapi: OSM Extended API 2.0' xmlns:xapi='http://www.informationfreeway.org/xapi/0.6' xapi:uri='/api/0.6/*[bbox=8.845,48.614,8.971,48.663]' xapi:planetDate='20100720' xapi:copyright='2010 OpenStreetMap contributors' xapi:license='Creative commons CC-BY-SA 2.0' xapi:bugs='For assistance or to report bugs contact 80n...@gmail.com' xapi:instance='zappyHyper' node id='283072126' lat='48.6588088' lon='8.8540973' version='1' changeset='35982' user='Moddy' uid='11925' visible='true' timestamp='2008-08-03T12:14:23Z' ist ok. nach Herausschneiden Gemeinde X ?xml version='1.0' encoding='UTF-8'? osm version=0.6 generator=Osmosis 0.35 node id=283072126 version=1 timestamp=2008-08-03T12:14:23Z uid=11925 user=Moddy changeset=35982 lat=48.6588088 lon=8.8540973/ node id=252685607 version=2 timestamp=2009-01-02T13:40:10Z uid=46010 user=Blaubunkt changeset=711021 lat=48.6467865 lon=8.8606897/ aktuell http://download.geofabrik.de/osm/europe/germany/saarland.osm.bz2 ?xml version='1.0' encoding='UTF-8'? osm version=0.6 generator=Osmosis 0.32 bound box=49.10868,6.35017,49.64072,7.40979 origin=http://www.openstreetmap.org/api/0.6/ node id=470552 version=3 timestamp=2008-10-09T17:47:13Z uid=21764 user=The_Moth changeset=194178 lat=49.3413853 lon=7.3014897 tag k=created_by v=JOSM/ tag k=ele v=242.389648438/ /node -- View this message in context: http://gis.638310.n2.nabble.com/Lizenzverpflichtung-fur-Nutzer-von-OSM-Daten-tp5317860p5318350.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
[Talk-de] Deine Stadt an Deinem Ohr
Hallo zusammen, Heute in der Gratiszeitung 20Minuten entdeckt: http://www.20min.ch/life/beauty/story/23381393 bzw. http://fluid-forms.com/ Tolle Idee! :) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und left-rig ht - neues Datenmodell nötig!?
steffterra glaubte zu wissen: Vielen Dank, an alle, die bis hier gelesen haben. Für die anderen: Bevor Ihr urteilt, lest es bitte komplett, da die eine Frage vielleicht schon weiter unten beantwortet wird. Bitte macht mich gerne auf Denkfehler aufmerksam ;-) Das mit dem komplett lesen hättest vielleicht an den Anfang stellen sollen. ;-) Heute les ich mir das nicht mehr durch, Bett schreit schon. flo -- [Kann man gelöschte Dateien wieder herstellen?] Nein: geht nicht--- Linux ist für Männer! [Frank Ronneburg in debian-user-german] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
Heiko Jacobs glaubte zu wissen: Rainer Knaepper schrieb: mir kam auch der Gedanke, wie jemand auf einem Liegerad wohl da durchkommen soll. Auch die Kurven sind sehr eng :-) Pfff... Liegerad ... Peanuts ... Das ist steigerungsfähig: http://heiko-jacobs.de/jacobs/rad/anhaenger3.jpg Leider bishe rnur 1x so unterwegs gewesen und das auch nicht weit ... Ich kann gerade nur http://florian-gross.de/gallery/albums/userpics/10001/trekkingrad_mit_haenger.png bieten. Ich muß morgen doch mal Trike mit Anhänger fotografieren. ;-) flo -- Verbraucherschuetzer? Die geht das erst was an, wenn Office mir eine Faust durch die Mattscheibe reicht, mich an den Ohren zieht und fragt: 'Hast du den Bill heut schon gepriesen?' [Michael Weber in dchc-b] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 20.07.2010 21:18, schrieb steffterra: Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist: Das Problem der drehenden Wege bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden. Du schreibst im Folgenden über das Linienbündel-Problem, nicht wirklich über richtungsabhängige Tags. Es stimmt zwar, dass das Linienbündel-Problem auch einige richtungsabhängige Informationen abdeckt, aber Dinge wie Steigungen oder die Richtung eines Flusses sind davon völlig unabhängige Infos. Freut mich also, wenn du dich der Linienbündel annehmen willst, aber das Thema bitte gedanklich ein wenig von richtungsabhängigen Informationen trennen - damit hat es nur am Rand zu tun. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von Linienbündeln und Fahrspurtagging gelesen. Doch welche Konzepte gibt es bisher? http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group http://wiki.openstreetmap.org/wiki/User:%C3%96mmes/Wayparts http://wiki.openstreetmap.org/wiki/Users:cmuelle8/multiple_way_tagging_on_single_geometry http://wiki.openstreetmap.org/index.php/WikiProject_Germany/Workshops/Linienbündel Gibt noch mehr in verschiedenen Diskussionen etc., aber die gängigen Ideen dürften damit abgedeckt sein... Wie weit sind wir dahin? Es gibt mehrere Konzepte, die theoretisch alle denkbaren Situationen entlang eines Wegs beschreiben könnten. Das ist auch der leichte Teil. Auf einige Details, wie etwa die Darstellung von Kreuzungen, gehen die Konzepte meist nicht ein. Das ist m.E. der gängigste konzeptionelle Mangel. Bei den o.g. Konzepten gibt es außerdem keine fertige Editor-Unterstützung, keine Rendering- oder Routing-Unterstützung, und keine nennenswerte Verbreitung. Das sind die praktischen Mängel. Steckt OSM da derzeit fest? Warum gehts nicht weiter? Weil es viel Arbeit ist, so etwas komplett durchzuziehen. Bisher hat noch jeder nach dem Abliefern der ersten Ideen und halbfertiger Konzepte keine Lust mehr gehabt. Ich übrigens damals auch. ;) So, jetzt aber zu deinem Vorschlag: a) Einzeichnen zusätzlicher paralleler ways, die _nicht_ extra durch eine Relation oder einen Tag als zum gleichen way =ohne bauliche Trennung, gehörig verbunden werden müssen. Das sollte durch eine neue Datenart ermöglicht werden. Wenn ich so die Eigenschaften deiner Ways durchlese, dann sind das durch eine Relation verbundene Ways. Ja, ich weiß: Du willst, dass man sie nicht manuell in eine Relation zusammenfassen muss, der Editor sie automatisch parallel ausrichtet, auf höheren Zoomstufen ausblendet etc. Aber das kann der Editor prinzipiell alles auch mit Ways in einer Relation machen; muss man ihm nur beibringen - das ist nicht schwerer, als die entsprechenden Funktionen für einen neuen Datentyp zu bauen, und ließe sich später leicht anpassen. Vorteil: Um ein Editor-Plugin (und/oder ein Beispiel-Rendering) zu schreiben, das dein Konzept intern mit Relationen nachbaut, musst du niemanden überzeugen. Das kannst du ohne die Zustimmung einer zentralen Autorität veröffentlichen. Das beweist dann, dass deine Idee in der Praxis funktionieren kann, und die Leute werden dein Konzept mit eigenen Händen ausprobieren. Nachteil: Du hast vermutlich mehr oder weniger darauf spekuliert, dass eine API-Änderung dazu führen würde, dass sich jemand anderes um die eigentliche Arbeit, nämlich die Editoren und Renderer, kümmert - und du nur die Ideen liefern musst. So hätte ich jedenfalls gedacht. *g* e) was tun bei drei Fahrspuren? Der datenway wird zwischen beide Fahrtrichtungen gelegt und ist dann insgesamt gesehen der vierte way. Es gibt keine klare Grenze zwischen zwei Fahrtrichtungen - zumindest, wenn wir nicht nur über Autos reden. Beispielsweise kann ein Radweg sowohl nur für eine als auch für beide Richtungen zugelassen sein; er wird sich dennoch ganz klar entweder links oder rechts deines Datenways befinden. Allerdings scheinst du bis jetzt ja wirklich primär an Autofahrspuren gedacht zu haben: 8. Fahrbahnbegleitende Radwege, etc. werden nach wie vor am highway getaggt, nun jedoch auf der jeweiligen Fahrspur für die jeweilige Richtung. 9. Parkstände entlang von Fahrspuren: Auch parking:lane ist nun klar, und muss nicht mehr mit right/ left getaggt werden, sondern einfach auf der Fahrspur, die es betrifft. Einer der Vorzüge eines Linienbündels ist doch, dass man Radwege, Parkstreifen und Gehwege als eigene Spur darstellen kann! Sonst hast du viele der der Probleme, für die sich die Einführung von Linienbündeln lohnen würde, gar nicht gelöst: * ist der Radweg jetzt innerhalb oder außerhalb des Parkstreifens? * wie kann ich bewährte Tags wie surface oder width direkt für einen der Radwege setzen? - jemand müsste das in die DB einbauen und auch stufenweise in die populären
Re: [Talk-de] Sind Relationen komplex? was: Zum 1000. mal - Hausnummern und Straßennamen?
Tobias Knerr glaubte zu wissen: Am 20.07.2010 14:55, schrieb Bernd Wurst: Leider kommt vor dem nüchternen Betrachten und ach, so kompliziert ist das ja gar nicht hier zu oft das kollektive Anti-Relationen-FUD und plötzlich denken alle, Relationen wären etwas komplexes. Hier mein Geständnis: Ich finde den Umgang mit Relationen auch komplex. Wenn ich einen Weg bearbeite, der in einer Relation enthalten ist, fühle ich mich oft unwohl - habe ich wirklich alles richtig gemacht? Evtl. kennst oder findest du den einen oder anderen, den du bei Bedarf bitten kannst, sich nach deiner Änderung die Relationen anzusehen und notfalls wieder zu richten. Oder noch besser dir erklärt, was da warum kaputtgegangen ist und wie du das vermeiden kannst. Wenn es mal klick gemacht hat, sind einige Relationsarten gar nicht mehr so schlimm. Um Dinge wie Bus- oder Bahnlinien mach ich allerdings einen großen Bogen ;-) flo -- [ ] Er weiss, was TTL ist [ ] Er weiss, was DTL ist [X] Er weiss, was RTL ist [Hans Bonfigt in doc] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenverlust
Markus liste12a4...@gmx.de wrote: Die Luftbilder wurden nicht 1:1 importiert. Vielmehr haben die Mapper von Hand aus den Luftbildern abgemalt Richtig. und damit dasselbe getan, was man mit den GPS-Spuren macht. Nicht ganz. GPS-Spuren gehören (meistens) dem Abzeichner selbst. Er darf also entscheiden, wie die Tracks verwendet werden dürfen. Bei den Luftbildern hat das Ministerium entschieden, dass die Produkte für immer frei sind. OSMer, die im Rahmen des Projektes unter diesen Bedingungen Luftbilder abgemalt haben, taten das zu diesen ihnen bekannten Bedingungen. Rechtlich taten sie das in der Rolle des Erfüllungsgehilfen. Nehmen wir an, eine GPS Spur gehört jemand Anderem als demjenigen, der sie abmalt. Dann wäre Letzterer auch nur Erfüllungsgehilfe, wenn man Dein Luftbild Beispiel fortspinnt. Er hätte somit keine Recht, die Lizenz seines Beitrages festzulegen. Folglich hätte das Auswirkungen darauf, was gelöscht wird oder nicht. Man müsste in diesem Falle den Urheber des verwendeten GPS Tracks feststellen und die Löschung an seiner ODBL-Zustimmung/Ablehnung festmachen. Natürlich darf die OSMF die PD-Daten nehmen und unter einer anderen Lizenz veröffentliche. Das ändert aber praktisch nicht: die Daten bleiben unter PD (sie sind halt dann doppelt lizenziert). Die Frage ist, ob die Daten PD sind. Denn sowohl PD, CC by SA (und ODbl) erheben den Anspruch, freie Lizenzen zu sein. Also ist die frei-Bedingung aus | Die zeitlich befristete Nutzung der DOP-Daten beinhaltet | das Recht, die während der Tesphase erhobenen Vektordaten | im OSM-Projekt dauerhaft und frei zu nutzen. mit jeder dieser Lizenzen erfüllt, also auch mit CC by SA. Der Abmaler hat also die Spezifikations-Freiheit, (die ihm von der Luftbild-Überlassung gewährt wird) seine Beiträge unter CC by SA bei OSM einstellen. Und für Beiträge, für die der User nicht PD proklamiert, gilt CC by SA als vereinbart. Ich dachte eigentlich, dass Du bezüglich der freien Lizenzen derselben Auffassung wärest. Denn so hatte ich zunächst den Klammerzusatz in Deinem PD (oder so) im Wiki interpretiert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Hallo, Ich möchte mal ganz wertfrei und ohne Vorbehalte darüber schreiben, was hier zu beobachten ist: Das Problem der drehenden Wege bei Verwendung von backward-forward und left-right für die unterschiedlichsten Zwecke muss irgendwie grundlegend angepackt werden. Da hatte ich vor ewiger Zeit mal mit angefangen, aber dann war ich länger im Ausland,... s.: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left Dimitri ___ 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 20.07.2010 14:55, schrieb Bernd Wurst: Da eine größere Straße in einer größeren Stadt mit hoher Wahrscheinlichkeit einer Busroute, einer Rad-Route oder ähnlichem angehört, kommt man nicht drum herum, irgendwelchen Relationen zu begegnen. Wenn man aber sagt: Wenn ich eine Straße auftrenne, die vorher Teil einer Route war, dann sind nachher eben beide Teile in der Route, dann ist das so trivial, dass JOSM das richtig macht und es ist so trivial, dass man das verstehen kann. Sobald man dann aber z.B. die fehlende bauliche Trennung einer Straße eintragen will (und sei es auch nur ein kurzes Stück für eine Straßenbahnhaltestelle) hört es schlagartig auf trivial zu sein. Da muß man sich auf einmal mit jeder einzelnen Relation auseinandersetzen. Leider kommt vor dem nüchternen Betrachten und ach, so kompliziert ist das ja gar nicht hier zu oft das kollektive Anti-Relationen-FUD und plötzlich denken alle, Relationen wären etwas komplexes. Ich mache dir am Beispiel klar, das es durchaus auch Probleme mit Relationen gibt und du tust das dann als kollektives Anti-Relationen-FUD ab. Wirklich nüchternes Betrachten? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenverlust
Hi ... , GPS-Spuren gehören (meistens) dem Abzeichner selbst. Er darf also entscheiden, wie die Tracks verwendet werden dürfen. Bei den Luftbildern hat das Ministerium entschieden, dass die Produkte für immer frei sind. OSMer, die im Rahmen des Projektes unter diesen Bedingungen Luftbilder abgemalt haben, taten das zu diesen ihnen bekannten Bedingungen. Rechtlich taten sie das in der Rolle des Erfüllungsgehilfen. Nehmen wir an, eine GPS Spur gehört jemand Anderem als demjenigen, der sie abmalt. Dann wäre Letzterer auch nur Erfüllungsgehilfe Das wäre er m.E. nur, wenn der GPS-Spur-Besitzer seine Spur und die Erlaubnis diese zu nutzen ebenfalls und explizit (wie die Bayrische Regierung) an einen Vertrag geknüpft hätte. Implizit hat er das sicher irgendwie. Aber bei den Luftbildern ist es /ausdrücklich/. Das waren die Projektbedingungen. Und jeder der mitgemacht hat wurde darüber ausdrücklich informiert. Wie das bei impliziten Vereinbarungen ist habe ich keine Ahnung. Auch unser CC-by-SA scheint mir manchmal recht implizit (gewesen) zu sein. Mir (und offensichtlich auch den Erfindern?) ist bis heute nicht klar, was das für welche Fälle bedeutet, und warum wir jetzt etwas Neues brauchen sollen. Und auch die neue GDBL erscheint mir reichlich implizit da - wie immer wieder versichert wird - keiner so richtig weiss, was sie denn für den konkreten Fall bedeutet, sondern dass die Lizenz brandneu sei und sich erst mal in der Praxis (und vor den verschiedenen Gerichten in den verschiedenen Ländern bewähren müsste... Mich nervt diese ganze Juristerei. Am liebsten wären mir freie Daten, die jeder frei nutzen darf, und die jeder gern als sind von OpenStreetMap bezeichnet. Und wenn nicht: wen kümmerts: man sieht sowieso, was OpenStreetMap ist :-) Die Frage ist, ob die Daten PD sind. Denn sowohl PD, CC by SA (und ODbl) erheben den Anspruch, freie Lizenzen zu sein. Also ist die frei-Bedingung aus | Die zeitlich befristete Nutzung der DOP-Daten beinhaltet | das Recht, die während der Tesphase erhobenen Vektordaten | im OSM-Projekt dauerhaft und frei zu nutzen. mit jeder dieser Lizenzen erfüllt Im Prinzip ja - aber da im Vertrag nichts von Namensnennung oder so steht, sind sie wirklich frei :-) Ich dachte eigentlich, dass Du bezüglich der freien Lizenzen derselben Auffassung wärest. Denn so hatte ich zunächst den Klammerzusatz in Deinem PD (oder so) im Wiki interpretiert. Das oder so bedeutet, dass ich inzwischen weiss, dass es PD in DE nicht gibt, sondern irgendwie gemeinfrei genannt wird ;-) Wenn da also sowieso keiner mehr durchblicht - wozu dann das ganze Gedöns? Warum nicht einfach *richtig frei* - und gut ist? Denn das wollen wir doch: eine freie Weltkarte! Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dresdner Bank - Commerzbank
Johann H. Addicks wrote: Am 19.07.2010 23:18, schrieb Quietscheentchen: Bevor da ein Rundumschlag gemacht wird, sollten wir noch mindestens ein halbes oder ganzes Jahr warten und bis dahin nur die Filialen ändern, die sich auch tatsächlich geändert haben. Ein dort in der Zentrale tätiger Bekannter meinte, dass diese Umstellung sich vermutlich noch ewig (1 Jahr?) bis zum vollständigen Abschluss hinziehen werde. Es ist also noch kein Stichtag absehbar, zu dem man sagen kann Nur gibt es keine Dresdener-Bank-Filialen mehr, bitte Bot anwerfen. Hi, mir ist da noch eine Idee gekommen, falls das jemand unbedingt komplett angehen möchte. Statt in OSM alles umzubenennen, könnte man nach 1 Jahr+ per Bot bei Openstreetbugs alle Filialen eintragen, mit der Bitte um Überprüfung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen fürs Finden
Daniela Duerbeck wrote: Aber wenn man sich mal den tagwatch so anschaut: http://tagwatch.stoecker.eu/Europe/En/ignored_cuisine.html findet man wirklich eine Menge Blödsinn. cuisine=gutbürgerlich mag ja richtig sein, aber das findet doch niemand. Man braucht ja ein Gerät, das das auch unterstützt.Da wäre german wohl angebracht. Sowas kann man nur von Hand korrigieren. Und viele Restaurants haben gar kein cuisine-tag, obwohl es völlig eindeutig wäre. Wäre es da nicht sinnvoll, mal den Bot aufräumen zu lassen? Also z.B. alle lebanese, lebenese, libanais und Konsorten zu libanese beispielsweise zusammenzufassen? Also einen Bot würde ich nur einsetzten um z.B. bei den Fastfoodketten die Cuisine nachzutragen, bei den Schreibfehlern sollte man lieber von Hand ran gehen. Das sind meistens nicht so viele. Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Frederik Ramm frede...@remote.org wrote: Tirkon hat uebrigens recht damit, dass es sein kann, dass ein und dasselbe Resultat je nach Herstellungsverfahren eine Share-Alike-Datenbank nach sich ziehen kann oder nicht. Das ist ein bisschen kurios, aber auch mit der jetzigen Lizenz laesst sich sowas konstruieren. Angenommen, ich male ein Bild, veroeffentliche es PD, und appliziere darauf mit XOR ein OSM-Karten-Tile. Lizenz ist nun, gezwungenermassen, CC-BY-SA. Jemand anders nimmt dieses Kunstwert, XORt das gleiche Karten-Tile an die gleiche Stelle - Lizenz immer noch CC-BY-SA, obwohl im Resultat nichts mehr von OSM drin ist, er haette auch gleich mein PD veroeffentlichtes Bild nehmen koennen. In diesem Beispiel findet eine tatsächliche Verquickung der Bilder statt. Mir ging es eigentlich auch nicht so um das Technische. Worauf ich eigentlich hinaus wollte, war die OSM Lizenzvererbung - und zwar mit Augenmerk auf die !!freie!! Lizenzvererbung. Der freie Gedanke basiert darauf, dass unter Zuhilfenahme freier Dinge (Geodaten/OSM, Texte/Wikipedia, Bilder und Dateien/Wikimedia Commons, Software) keine unfreien/proprietären sondern nur freie Dinge produziert werden dürfen. Hintergrund dabei ist, dass derjenige, der freie Dinge nutzt, auch die Ergebnisse wieder frei anbieten soll. Ziel ist es, durch freie Dinge andere freie Dinge zu generieren und dass freie Dinge letztendlich nicht in eine proprietäre Sackgasse laufen können. Kurzformel: frei + irgendetwas = frei. Das ist das von Richard Stallmann ursprünglich für Software begründete Prinzip, das auf andere freie Dinge ausgeweitet wurde und hierfür bis heute bestens funktioniert. Die Lizenzen haben sich sich als wasserdicht erwiesen. Platt gesagt: Es ist noch niemand bisher gelungen, freie Dinge zu nehmen ohne zu geben. Nur bei OSM scheint das problematisch zu sein. http://de.wikipedia.org/wiki/Richard_Stallman Wenn es unter der ODBL möglich ist (z.B. über den Umweg von Layern) proprietäres Material (z.B. POIs) unter Zuhilfename von OSM verortbar darzustellen, dann ist hier die Kette frei + irgendetwas = frei unterbrochen. Denn die proprietären POIs sahnen den Nutzen von OSM ab, ohne in dieser Form nachher frei zur Verfügung zu stehen und somit nicht in OSM aufgenommen werden können. Hier wird ein Riesenaufwand betrieben, um den Lizenzwechsel durchzuführen und große Datenverluste hierfür in Kauf genommen. Daher noch einmal die explizite Frage: Ist die obige Szenario unter ODBL möglich oder nicht. Wenn ja, dann würde die neue Lizenz das freie Prinzip nicht garantieren. Dann aber sollte man schleunigst darüber nachdenken, ob sie den Speicherplatz wert ist, in den sie geschrieben wurde. Ich bin mir dabei im Klaren, dass vermutlich auch die jetzige Lizenz dies nicht sicherstellt. Aber wenn eine Umstellung derart aufwendig ist, dann bitte auch wirksam. Ich weiß nicht, was XOR sagen will. Ich nehme einmal an, dass es eine Erweiterung der XOR Funktion (, die ursprunglich nur für die zwei binären Werte 1 und 0 definiert wurde), auf diskrete digitalisierte Analogwerte erweitert und somit eine Form der Bildüberlagerung darstellt, die ebenso wie das binäre Pendant durch zweimalige Anwendung das ursprüngliche Bild wieder herstellt. http://de.wikipedia.org/wiki/XOR-Gatter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Hallo, könnte mal irgendwer im Wiki klar und einfach schreiben was sich durch den Wechsel ändert? Also welche Nutzung die vorher erlaubt ist ist nachher verboten und umgekehrt. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen fürs Finden
Am 17. Juli 2010 01:36 schrieb Daniela Duerbeck daniela.duerb...@gmx.de: Wäre es da nicht sinnvoll, mal den Bot aufräumen zu lassen? Also z.B. alle lebanese, lebenese, libanais und Konsorten zu libanese beispielsweise zusammenzufassen? bitte lieber zu lebanese ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Am 21.07.2010 00:48, schrieb Tirkon: Der freie Gedanke basiert darauf, dass unter Zuhilfenahme freier Dinge (Geodaten/OSM, Texte/Wikipedia, Bilder und Dateien/Wikimedia Commons, Software) keine unfreien/proprietären sondern nur freie Dinge produziert werden dürfen. Ich kann einen Closed-Source-Wikipedia-Reader programmieren. Ich kann ein unfreies Bild in GIMP malen. Ich kann OSM auf der proprietären Garmin-Hardware verwenden. Das Share-Alike gilt nie über die Grenzen der jeweiligen Domäne hinweg. Bilder auf Basis der Bilder aus WM Commons müssen frei sein. Sourcecode auf Basis der Linux-Sourcen muss frei sein. Und: Geodaten auf Basis von der OSM-Geodaten müssen nach ODbL frei sein. Bilder sind hingegen eine andere Domäne. Ich finde insgesamt, dass die ODbL mit ihrer Forderung nach Freigabe der zugrundeliegenden Datenbanken - dem Mittel, um selbst Karten und andere Werke herstellen und diese anpassen zu können - sehr gut dem OpenSource-Gedanken entspricht. Ein Softwarevergleich: Die bisherige Lizenz (von der Wirksamkeit abgesehen) entspricht: Ich darf ein Betriebssystem auf Linux-Basis herstellen und muss die Binaries, nicht aber den Sourcecode freigeben. ODbL entspricht: Ich darf ein Betriebssystem auf Linux-Basis herstellen und muss den Sourcecode freigeben. Ich darf dort aber proprietäre Programme und Desktophintergründe vorinstallieren, die ich nicht freigeben muss. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
Florian Gross schrieb: Heiko Jacobs glaubte zu wissen: Rainer Knaepper schrieb: mir kam auch der Gedanke, wie jemand auf einem Liegerad wohl da durchkommen soll. Auch die Kurven sind sehr eng :-) Pfff... Liegerad ... Peanuts ... Das ist steigerungsfähig: http://heiko-jacobs.de/jacobs/rad/anhaenger3.jpg Leider bishe rnur 1x so unterwegs gewesen und das auch nicht weit ... Ich kann gerade nur http://florian-gross.de/gallery/albums/userpics/10001/trekkingrad_mit_haenger.png bieten. Ich muß morgen doch mal Trike mit Anhänger fotografieren. ;-) Dann komme ich mit unserem kleinen VCD-Fahrrädle ... http://umverka.de/hefte/heft308/windmuehlenberg.jpg Das fahre ich Samstag zum Einsatz. Ich könnte eigentlich noch 'ne Anhängerkupplung dran basteln und den Umweltzentrumsanhänger dranhängen, das macht dann zusammen den richtig guten Eindruck! ;-) Gruß Mein Ferienhaus, meine Yacht, mein Rad ;-) Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Lulu-Ann, Tipp: Immer erst mal im Wiki nachlesen, was es schon gibt. Die Sachen sind da schon diskutiert. Wie Du vielleicht in meiner ersten Mail hierzu gesehen hast, habe ich die Wiki-Seite bereits gelesen. Glücklicherweise haben weder Du noch ich noch eine als 'Proposal' gekennzeichnete Wiki-Seite die Macht darüber zu entscheiden, wann eine Sache 'ausdiskutiert' ist. :) Die Frage des Renderings wird z.B. im Wiki *nicht* angesprochen. Zudem gab es hier einige Wortmeldungen, dass ein Node innerhalb eines grösseren Parkplatzes zur einfacheren Auffindung der Rolli-Parkplätze nicht schlecht wäre.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Hallo, Tirkon wrote: Der freie Gedanke basiert darauf, dass unter Zuhilfenahme freier Dinge (Geodaten/OSM, Texte/Wikipedia, Bilder und Dateien/Wikimedia Commons, Software) keine unfreien/proprietären sondern nur freie Dinge produziert werden dürfen. Das ist in dieser Allgemeinheit falsch. Mit dem freien OpenOffice kann ich ein proprietaeres Buch schreiben. Mit dem freien gcc proprietaeren Code schreiben. Freie Bibliotheken (unter LGPL) in mein Programm einbinden, ohne dies freizugeben. Platt gesagt: Es ist noch niemand bisher gelungen, freie Dinge zu nehmen ohne zu geben. Auch diese Verallgemeinerung ist falsch. Sehr viele Leute nehmen taeglich Linux, Openoffice, oder die OSM-Weltkarte, ohne ein Iota zu geben. Mir ist klar, dass Du das weisst, aber es ist mir wichtig, dieser Rhetorik vom Nehmen-ohne-Geben Einhalt zu gebieten; es klingt immer so, als wuerde eine Share-Alike-Lizenz uns davor schuetzen, dass jemand von unsere Daten profitiert und wir nichts davon abbekommen, aber das ist nicht der Fall. Nehmen-ohne-Geben ist der Standard - wie viele Leute lesen Wikipedia-Artikel, und wie viele Leute tragen aktiv bei? Im Bereich der Software klappt das mit der GPL recht gut, weil man da erstens ganz klar im Bereich des Urheberrechts operiert, und weil zweitens auch der Unterschied ganz klar ist: Habe ich einen neuen Compiler basierend auf dem gcc hergestellt - oder habe ich nur den gcc benutzt, um etwas ganz anderes herzustellen? In unserem Bereich - Geodaten - sind beide Punkte viel waessriger. Wenn es unter der ODBL möglich ist (z.B. über den Umweg von Layern) proprietäres Material (z.B. POIs) unter Zuhilfename von OSM verortbar darzustellen, dann ist hier die Kette frei + irgendetwas = frei unterbrochen. Zunaechst einmal die Anmerkung: Man kann nur Rechte kontrollieren, die man auch (von rechts wegen) hat. Wenn ich mich auf den Marktplatz stelle und HA! rufe, habe ich hieran aller Wahrscheinlichkeit nach keine Rechte, ich kann also auch nicht mein HA! als frei deklarieren und von jedem, der damit irgendwas macht, etwas verlangen. Grundlage jeder frei + irgendwas = frei-Regel, auch share-alike genannt, muss also irgendein Recht oder Gesetz sein, dass (so paradox das klingt) das freie erstmal unfrei macht und seine Nutzung abhaengig von der Zustimmung des Autors oder Rechteinhabers. Denn an etwas, von Natur aus frei ist, kann niemand Bedingungen knuepfen. Leider bin ich mir nicht ganz sicher, was Du mit POIs unter Zuhilfenahme von OSM verortbar darstellen meinst. Ich versuche mich mal an ein paar Szenarien: 1. Angenommen, Du hast eine Adresse eines einzelnen POI und willst den auf einer Karte einzeichnen. Du machst per Nominatim eine Adress-Suche und laesst Dir dann selber eine Karte rendern mit dem Punkt an der richtigen Stelle. In diesem Fall hast Du ein Produced Work geschaffen, das nicht frei sein muss, weil es keine Datenbank ist. ODbL fordert share-alike nur fuer Datenbanken. - Unter der CC-BY-SA haette dieses Werk frei sein muessen, wobei Kritiker natuerlich sagen wuerden, dass eine einzelne Adresse keine Schoepfungshoehe hat und daher die Rechtsgrundlage fehlt. 2. Angenommen, Du betreibst einen Web-Dienst, der das Internet nach Impressum-Seiten absucht und die Adressen davon automatisch mit OSM verortet. Das Resultat (viele hundert oder tausend Adressen) speicherst Du in einer eigenen Datenbank, und Dein Web-Dienst bietet eine Karte an, auf der diese POIs eingezeichnet sind. In diesem Fall hast Du eine Derived Database (die POI-Datenbank) geschaffen und darauf basierend ein Produced Work (die Karte). Die Karte kann lt. ODbL unter einer beliebigen Lizenz sein, aber die Datenbank musst Du unter ODbL freigeben. - Unter der CC-BY-SA waere das genau andersrum gewesen, die Datenbank haettest Du fuer Dich behalten duerfen, aber die Karte haette frei sein muessen. 3. Angenommen, Du hast zu Deinen POIs eh schon die Positionen und willst sie nur auf eine OSM-Karte einzeichnen. Dann kannst Du das in einem Extra-Layer machen und musst weder unter der alten noch unter der neuen Lizenz Deine POIs freigeben. 4. Angenommen, Du machst etwas aehnliches wie in 2., aber in einem ganz kleinen Rahmen, vielleicht nur fuer 20 POIs oder so. In diesem Fall gilt eine Ausnahme, weil Du OSM nicht substantiell benutzt, und Du musst nichts veroeffentlichen. Diese Ausnahme ist im EU-Datenbankrecht begruendet, das es dem Datenbankbetreiber explizit untersagt, dem Nutzer fuer nicht substantielle Nutzung irgendwelche Vorschriften zu machen. - Unter der CC-BY-SA haben wir derzeit den Anspruch, dass wir solche Ausnahmen nicht zulassen, aber das ist nur durchsetzbar, wenn das Urheberrecht auf unsere Daten zutrifft, was viele anzweifeln. Ich bin mir dabei im Klaren, dass vermutlich auch die jetzige Lizenz dies nicht sicherstellt. Aber wenn eine Umstellung derart aufwendig ist, dann bitte auch wirksam. Man muss dabei das Ziel von OSM im Auge
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
steffterra steffte...@me.com wrote: - Ich verstehe, die Befürworter von Relationen für die Abbildung von Wegeigenschaften, die sich nur auf eine Straßenrichtung beziehen (z.B. maxspeed:forward, parking:lane:right, destination:forward, etc.), da mit Relationen eine Richtung festgelegt werden kann, egal wie der Weg gedreht ist. - Ich verstehe aber auch die Bedenken derer, die das lieber getaggt haben, um zu verhindern, dass irgendwann _alles_, was eine Straßenrichtung betrifft, in Relationen gefasst wird. Ich halte beide Version für unübersichtlich und aufgrund der Komplexität beider Varianten auch fehlerträchtig. - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von Linienbündeln und Fahrspurtagging gelesen. Das Auflösen der Fahrspuren in Linienbündel würde den Großteil von richtungsabhängigen Tags und Relationen obsolet machen. Dennoch: Ich halte eine Einführung ohne dazugehörigen grafischen Editor, mit dem man die Linien zusammmenklicken kann, für problematisch, da dann OSM nur noch von wenigen Spezialisten editiert werden kann. Wir brauchen aber die breite Masse der Mapper, wenn man bedenkt, dass wir selbst das Basisangebot anderer Karten auch in Deutschland als meisteditiertem OSM Land in der Fläche nicht erreichen. Doch welche Konzepte gibt es bisher? Wie weit sind wir dahin? Steckt OSM da derzeit fest? Warum gehts nicht weiter? ... Sprich wir treten alle auf der Stelle. Doch die Anforderungen an OSM sind gestiegen und deshalb benötigen wir eine Erweiterung unseres bisherigen Datenmodells (so sagt man das doch?) Der Weg zu den Linienbündeln scheint mir weit. Und es liegt eine Menge Entwicklungsarbeit auf diesem Weg. Wie er aussehen könnte, habe ich ich im Folgenden beschrieben, wenn auch recht grobmaschig. Es gibt die ersten OSM-Erfahrungen mit einem komplexeren Thema - dem Oxomoa Schema. http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema Das Oxomoa Schema hat seine Existenz einem Workshop zu verdanken, bei dem man sich live traf. Nun sind solche Treffen für eine verstreute Community schwierig. Um solche komplexen Themen wie das Linienbündel effektiver bearbeiten zu können, habe ich mir Gedanken gemacht, wie man ohne solche Treffen auskommt. Herausgekommen ist folgendes Online-Werkzeug: Man braucht zunächst einmal einen OSM- Mini Planeten, auf dem man expirimentieren kann und der auch von allen gängigen Anwendungen z.B. Renderern (Mapnik, Osmarender, ÖPNV-Karte), Editoren und Analysewerkzeugen bedient wird. Es muss möglich sein, sich einen Exclusivbereich zu reservieren, damit Beispiele gezeigt werden können, an denen kein Anderer rumpfuschen kann. Denn dieser Gefahr sind alle Beispiele ausgesetzt, die man in der Original Datenbank verlinkt. Gerade das Feature, das man zeigen wollte, ist umeditiert worden. Man kann als Administrator eines reservierten Bereiches anderen Usern, die am gleichen Problem mitarbeiten, Bearbeitungsrecht geben. Schön wäre es zudem, wenn man Mapnik und Osmarender hier triggern könnte, um schnell voranzukommen. Runterladen ist auch aus diesen geschützten Bereichen möglich. Ich bin mir sicher, dass solch ein Wrkzeug auch in vielen anderen Fällen als effektives Kommunikationsmittel dienen und Probleme verdeutlichen kann. Darüber hinaus wäre ein einfaches Online-Zeichenbrett nach demselben Schema nützlich, auf dem man einfache Zeichnungen erstellen und kommunizieren kann. Möglicherweise gibt es so etwas schon. Auch für Schulungen und Demonstrationen vor Publikum wäre der Miniplanet nützlich. Anfänger könnten Gehversuche machen. Illustrierende Beispiele für komplexe Themen im Wiki könnten hier vorgehalten werden, so zum Beispiel für das Oxomoa Schema. Möglicherweise kann man hierzu nicht existierende Koordinaten oder ein Stück der Originalerde für solche Zwecke reservieren. Der Mini Planet wäre zum Beispiel dazu geeignet, sämtliche Vorstellungen, die Du in dem von mir weggeschnibbelten Teil geäußert hast, praktisch darzustellen. Ich denke mal, das wäre viel effektiver und würde mehr Leute dazu animieren, teilzunehmen. Ein Bild sagt eben mehr als tausend Worte. Zur Bearbeitung eines komplexen Themas, wie den Linienbündeln, kann man nun einen Ausschnitt der Originalkarte in den Miniplaneten kopieren und beginnt, Teile davon, nach einem erarbeiteten Konzept zu taggen. Hierbei wird sich zeigen, ob das Konzept Alles meistert und ob es auch in der Lage ist, einen Übergang zu den Straßen zu meistern, die nicht als Linienbündel getaggt sind. Das muss auch an echten Kreuzungen gebündelt/ungebündelt funktionieren. Man kann auch schon ein erstes Mal den Renderer drüber laufen lassen. Nachdem das Konzept (von mehreren) geprüft und optimiert wurde, muss natürlich noch das Editor
Re: [Talk-de] Fragen zur OSM-Lizenzvererbung
Frederik Ramm frede...@remote.org wrote: Leider bin ich mir nicht ganz sicher, was Du mit POIs unter Zuhilfenahme von OSM verortbar darstellen meinst. Zum Beispiel das hier: http://62.154.206.92/mc2.1/index.htm Wenn es nicht funktioniert, dann hier http://www.efa.de/ auf interaktive Karte klicken. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
