Re: [Talk-de] das Problem mit backward-forward und left-rig ht - neues Datenmodell nötig!?
Am 25.07.2010 um 03:51 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c om: Am 21. Juli 2010 04:37 schrieb Tirkon tirko...@yahoo.de: 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. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways u nd Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. +1 steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz-Die Lösung
Am 25.07.2010 um 03:15 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c om: Am 20. Juli 2010 10:38 schrieb Martin Simon grenzde...@gmail.com: 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. ;-) warum als Nodes? Das sind doch klar Flächen. Ich wäre auch für ein Tag für einzelne Parkplätze (Stellplätze), bzw. zur Markierung der Parkbereiche auf größeren Parkplätzen. Und wie wird die dann in die Area gezeichnet? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutschen
Am 25.07.2010 um 03:00 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c om: Am 24. Juli 2010 15:29 schrieb steffterra steffte...@me.com: Wäre doch toll, oder? naja, deutlich toller wäre es, direkt zu einem freien und kostenlosen Parkplatz in der Nähe geleitet zu werden, oder? Das stimmt allerdings ;-) *träum* steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hilfe, Elemente einer Relation versehe ntlich gelöscht, wie zurückrollen
Hallo, ich wollte eigentlich nur eine kleine Änderung an einer Relation vornehmen, da ein Teilstück einer Straße nicht mehr zur Route Ilseradweg gehört, wollte ich die Straße teilen und das Überbleibsel rausnehmen. Irgendwie habe ich es aber fertigbekommen, daß die gesammte Relation nun keine Pfade mehr enthält. Wie kann man den originalzustand der Relation Ilseradweg (405648) ref = Ilse wieder herstellen? Vielen Dank Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe, Elemente einer Relation versehe ntlich gelöscht, wie zurückrollen
Am 25. Juli 2010 09:43 schrieb Andreas Tille andr...@an3as.eu: Hallo, ich wollte eigentlich nur eine kleine Änderung an einer Relation vornehmen, da ein Teilstück einer Straße nicht mehr zur Route Ilseradweg gehört, wollte ich die Straße teilen und das Überbleibsel rausnehmen. Irgendwie habe ich es aber fertigbekommen, daß die gesammte Relation nun keine Pfade mehr enthält. Wie kann man den originalzustand der Relation Ilseradweg (405648) ref = Ilse wieder herstellen? http://wiki.openstreetmap.org/wiki/DE:JOSM/Werkzeuge#Gel.C3.B6schte_Relationen_wieder_herstellen Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM V 3376
Hallo! Auch in dieser JOSM-Version heißem die Busrouten-Line-Relationen im deutschen immer noch Freileitung (Starkstrom). Kann das nicht jemand ändern? -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V 3376
Am 25.07.2010 10:54, schrieb Wolfgang Wienke: Auch in dieser JOSM-Version heißem die Busrouten-Line-Relationen im deutschen immer noch Freileitung (Starkstrom). Kann das nicht jemand ändern? Moin, woher soll JOSM wissen, wann er 'line' mit Stromleitung und wann mit Buslinie übersetzen soll ? Warum das ÖPNV-Schema line=bus und nicht route=bus verwendet entzieht sich meiner Kenntnis. http://wiki.openstreetmap.org/wiki/Relation:route http://wiki.openstreetmap.org/wiki/%C3%96PNV_Schema Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Doppelte Tags - rausnehmen
Moin! immer wieder finde ich Objekte die durch ein Node und ein Area beschrieben werden. Beispiel http://www.openstreetmap.org/browse/node/314512234 und http://www.openstreetmap.org/browse/way/28617230 Jetzt stellt sich die Frage - eines davon gnadenlos rausnehmen ? Tendiere dann zum Node ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelte Tags - rausnehmen
Am 25.07.2010 11:22, schrieb Jan Tappenbeck: Jetzt stellt sich die Frage - eines davon gnadenlos rausnehmen ? Tendiere dann zum Node ! Ja, würde ich auch so machen. Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelte Tags - rausnehmen
Am 25. Juli 2010 11:25 schrieb Peter Körner osm-li...@mazdermind.de: Am 25.07.2010 11:22, schrieb Jan Tappenbeck: Jetzt stellt sich die Frage - eines davon gnadenlos rausnehmen ? Tendiere dann zum Node ! ja, klar, wobei man den Einzel-Node mit einem Node aus dem Umriss mergen kann (sollte?), dann die Tags entfernen. Zumindest, wenn der Node älter ist als der Umriss. So bleibt die History des Nodes erhalten. Ist eine Idee von Frederik und wurde hier schon öfters mal vorgeschlagen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: Hi, ich möchte damit weder provozieren, noch die 'alte Diskussion wieder hochkochen lassen. Erlaubt mir aber dennoch folgende Frage: Warum weiss jeder in Deutschland, dass - ein Behindertenparkplatz kein großer Parkplatz für Behinderte ist (in der Größe von amenity=parking) - ein Frauenparkplatz kein goßer Parkplatz für Frauen ist - ein Elternparkplatz kein großer Parkplatz für Eltern mit Kindern ist - ein Motorrardparkplatz kein großer Parkplatz für Motorräder ist All diese Parkplätze sind eigentlich Parkstände/Stellplätze, wie ich hier lernen konnte. Doch warum in Gottes Namen heissen sie Parkplätze, wenn sie doch, im Sinne von dem was laut Wiki amenity=parking bedeutet, gar nicht sind? jetzt ist es also ein sprachliches Problem... es ist eigentlich ganz einfach: amenity = parking bedeutet ausgewiesene Parkmoeglichkeit, nicht mehr und nicht weniger. Umgangssprachlich wird sowas halt Parkplatz genannt. Ob es sich dabei um einem Parkplatz oder einen Stellplatz oder was auch immer im offiziellen Sinne handelt, ist absolut egal. Genauso wie man mit jedem Papiertaschentuch zufrieden ist, wenn man nach einem Tempo verlangt. Bitte klärt mich mal auf, wie sich das mit der derzeitigen Philosophie hinter amenity=parking=großer Parkplatz verträgt Die Angabe kleine Parkmoeglichkeiten taggen wir nicht steht von Anfang an auf der Wikiseite. Ich kann mir nur vorstellen, dass damals damit verhindert werden sollte, dass alles mit Parkplaetzen zugekleistert wird. Das wird auch dadurch bestaetigt, dass damals kein separates Tag fuer diese Stellplaetze dokumentiert wurde. Aber heutzutage, wo jeder Baum und Kanaldeckel getaggt wird, und die Mapper und auch Renderer wesentlich differenzierter arbeiten, halte ich so eine Begruendung fuer obsolet. und wie man das am besten Neuusern verklickert, die geneigt sind aus obigem Grund natürlich überall ein amenity=parking hinzubauen und einen Key für die Art des Parkplatzes (disabled, women, parent, motorbike) hinbauen. in dem man den Wikitext entsprechend anpasst. Was soll denn bitteschoen kaputtgehen? Ich habe mal spontan ein paar Leute gefragt, die nichts mit OSM am Hut haben, die mir alle sagten: klar sind das alles im deutschen Sprachgebrauch Einzel-Parkplätze, aber natürlicherweise sagt jeder Parkplatz. Wenn man auf Parkplatzsuche geht, würde man ja auch nicht ausschließlich nach einen großen Parkplatz suchen, sondern einen Einzelplatz, wo man sein Auto/Motorrad parken kann. +1 Ich bin trotz vorangegangener Diskussion deshalb immer noch der Meinung, dass hier irgendwas schief läuft. Da ist doch ein grundlegender Denkfehler im System. Versteht Ihr, was ich meine? Wie kann man das ausmerzen? Durch Einzeltags für alle oben aufgeführten Parkplatzarten (und allen die mir jetzt nicht einfielen), ist es doch nicht getan, oder? ich kann vor allem nicht nachvollziehen, was durch Einzeltags besser werden wuerde... 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] Doppelte Tags - rausnehmen
On Sun, Jul 25, 2010 at 11:22:02AM +0200, Jan Tappenbeck wrote: Moin! immer wieder finde ich Objekte die durch ein Node und ein Area beschrieben werden. Beispiel http://www.openstreetmap.org/browse/node/314512234 und http://www.openstreetmap.org/browse/way/28617230 Jetzt stellt sich die Frage - eines davon gnadenlos rausnehmen ? Tendiere dann zum Node ! Nur wenn die tags wirklich 100% identisch sind - Ich erlebe es leider viel zu haeufig das Leute die Umrisse der DTAG Gebaeude eintragen und dann den MDF/Hauptverteiler Node einfach loeschen und die tags kopieren. Leider ist das mitnichten immer richtig. Das Gebaeude ist teilweise riesen gross und der Hvt nur in einem Fluegel mit seperatem Eingang und hat teilweise auch eine andere Adresse ... Also - ganz trivial ist das nicht ... Flo -- Florian Lohoff f...@zz.de Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz ( OSM-WN Nr. 1 ) 17.7-23.7.2010
Am 24.07.2010 22:42, schrieb Peter Körner: Am 23.07.2010 22:25, schrieb fx99: Der Text war richtig, aber der dahintersteckende Link falsch! hier klicken sollte jetzt passen: http://www.openstreetmap.org/user/osm%20dortmund/diary/11315 Sehr gute Zusammenfassung. Lg Ich würde es gut finden - besser wäre es noch wenn diese Zusammenfassung über einen Newsletterdienst gezogen werden könnte. Ich selber lese zwar viel in den ML quer - aber andere könnten dann autom. auf dem laufenden gehalten werden. Vielleicht finden sich noch andere mitstreiter die andere ML beobachten. Es gab ja auch schon die Überlegung einer Zeitschrift oder wie man das auch immer bezeichnen will. Das wäre ein Schritt dahin - aber vermutlich einfacher zu administrieren. Gruß jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe, Elemente einer Relation versehe ntlich gelöscht, wie zurückrollen
On Sun, Jul 25, 2010 at 09:49:53AM +0200, Falk Zscheile wrote: nun keine Pfade mehr enthält. Wie kann man den originalzustand der Relation Ilseradweg (405648) ref = Ilse wieder herstellen? http://wiki.openstreetmap.org/wiki/DE:JOSM/Werkzeuge#Gel.C3.B6schte_Relationen_wieder_herstellen Hmmm, so ganz verstehe ich die Anleitung nicht. Ich soll in Punkt 4. http://api.openstreetmap.org/api/0.6/relation/405648/5309248 aufrufen - aber im Browser bekomme ich eine Leere Seite und in JOSM bei Datei - Adresse herunterladen kommt eine Fehlermeldung, daß das Object nicht existiert. In http://www.openstreetmap.org/browse/relation/405648/history kann ich es aber sehen. Kann jemand weiterhelfen? Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Übernahme von Grenzen aus dem Wiki
HI ! wenn ich es richtig sehe dann dürfte man doch die Grenzen aus den Übersichtskarten aus Wikipedia [1], [2] versuchen als Grenzverlauf in OSM zu übernehmen. Das Einpassen dieser Bilder in JOSM etc gestaltet sich auf Grund der Auflösung relativ mühsam und schwierig. Hat das schon einmal einer von Euch gemacht - gibt es einen Tipp oder gar bessere Alternativen ?? Gruß Jan :-) [1] http://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Amt_Lauenburgische_Seen_in_RZ.svg/2000px-Amt_Lauenburgische_Seen_in_RZ.svg.png [2] http://de.wikipedia.org/wiki/Datei:Amt_Lauenburgische_Seen_in_RZ.svg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Bauchscmerzen
Am 22. Juli 2010 09:05 schrieb Frederik Ramm frede...@remote.org: Ist das realistisch? Wie viele brauchbare Kartendatensaetze gibt es - Navteq, Teleatlas, OSM, und sonst? Wenn nun irgendwer mit einem tollen Produkt auf den Markt kommt, wie lang dauert es, bis ein eifriger Journalist rausgefunden hat, dass die Daten aus OSM stammen muessen und den Hersteller drauf anspricht? es gibt sehr viele Datensätze, nur sind die halt nicht global. Und es gibt und wird noch viel mehr lokale Anwendungen geben, die ihre Daten sonst wo her haben können. Für globale Navigationslösungen gebe ich Dir Recht, da wird zumindest der Insider und Interessierte schnell herausbekommen, wo das herkommt, aber die ganzen kleinen Anwendungen hat doch niemand auf dem Schirm. Wenn dort jeweils OSM genannt werden müsste (ggf. mit dem Hinweis, dass wir die Daten für jedermann kostenlos zur freien Verwendung anbieten), dann wäre das eine gute Werbung, die sonst eben nicht stattfindet. Wer nicht tief in der Materie steckt wird von OSM in vielen Ländern nichts mitbekommen (Deutschland mal ausgenommen, aber auch da ist in meinem Bekanntenkreis kaum jemand, der abgesehen über mich schonmal was von OSM gehört hat). Je mehr wir wachsen, und je besser die Daten und Abdeckung werden, um so weniger ist das zugegebenermaßen relevant, aber zum derzeitigen Stand ist OSM m.E. noch kein Selbstläufer, der auch mit einer beliebigen Lizenz keine Gefahr läuft, doch noch von einer proprietären Crowdsource-Lösung geschluckt zu werden (z.B. Facebook könnte auch an Karten interessiert sein). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe, Elemente einer Relation versehe ntlich gelöscht, wie zurückrollen
Hallo Andreas, http://wiki.openstreetmap.org/wiki/DE:JOSM/Werkzeuge#Gel.C3.B6schte_Relationen_wieder_herstellen Hmmm, so ganz verstehe ich die Anleitung nicht. Ich soll in Punkt 4. http://api.openstreetmap.org/api/0.6/relation/405648/5309248 aufrufen - aber im Browser bekomme ich eine Leere Seite und in JOSM bei Datei - Adresse herunterladen kommt eine Fehlermeldung, daß das Object nicht existiert. In http://www.openstreetmap.org/browse/relation/405648/history kann ich es aber sehen. Kann jemand weiterhelfen? Probier's mit der Version, nicht mit der Changeset-ID, dann sollte es klappen.. ;-) http://www.openstreetmap.org/api/0.6/relation/405648/11 Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.07.2010 12:41, schrieb Guenther Meyer: Die Angabe kleine Parkmoeglichkeiten taggen wir nicht steht von Anfang an auf der Wikiseite. Ich kann mir nur vorstellen, dass damals damit verhindert werden sollte, dass alles mit Parkplaetzen zugekleistert wird. Das wird auch dadurch bestaetigt, dass damals kein separates Tag fuer diese Stellplaetze dokumentiert wurde. Aber heutzutage, wo jeder Baum und Kanaldeckel getaggt wird, und die Mapper und auch Renderer wesentlich differenzierter arbeiten, halte ich so eine Begruendung fuer obsolet. +1 Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: und wie man das am besten Neuusern verklickert, die geneigt sind aus obigem Grund natürlich überall ein amenity=parking hinzubauen und einen Key für die Art des Parkplatzes (disabled, women, parent, motorbike) hinbauen. in dem man den Wikitext entsprechend anpasst. Was soll denn bitteschoen kaputtgehen? +1 Ich kann schon nachvollziehen, daß es Unklarheit schafft, wenn jetzt einzelne Stellplätze ohne Zusatztags als amenity=parking bezeichnet werden. Um das zu vermeiden, würde ich im Wiki dokumentieren, daß einzelne Stellplätze oder Parkplätze mit geringer Kapazität immer ein capacity-Tag haben sollen. Das könnte auch von Editor-Presets unterstützt werden. Bei Parkplätzen, die nach der bisherigen Beschreibung im Wiki keine ausreichende Größe haben, kann man nicht argumentieren, daß die Erfassung (Schätzung) der Kapazität nicht praktikabel oder zu aufwändig wäre. Bei Parkplätzen ohne capacity können wir annehmen, daß es sich entsprechend der alten Beschreibung um größere Parkplätze handelt. (Andernfalls ist es ein Fehler im Tagging.) Dann müßte man bei Bedarf nur noch den Renderern beibringen, ab irgendeiner Kapazitätsgrenze eine Unterscheidung zu machen. Insoweit sehe ich da auch kein wirkliches Problem. Allerdings wird mit diesem Vorschlag nicht die Frage beantwortet, wie man auf einem großen Parkplatz mit mehreren Stellplätzen/Parkständen die Bereiche kennzeichnet, die bestimmten Fahrzeugen oder Fahrzeugnutzern vorbehalten sind. Möglicherweise kann man das mit parking:lane lösen. Falls das zu kompliziert ist, braucht man eben (wie bereits gesagt) geeignete Presets. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxMKGoACgkQnMz9fgzDSqcpBACfTQFdvjjlJOaSOD3K5+oUtTzG h5oAn0OL9zlfCsCV7vAyaKigpiPxVTdm =dPcG -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] sächsischer Jakobsweg¹
Am 23. Juli 2010 10:11 schrieb Jan Tappenbeck o...@tappenbeck.net: Wenn sich jemand findet und dann eine neue Relation erstellt - dann bitte mir mitteilen damit ich das in [1] einbauen kann. Gruß Jan :-) [1] http://www.tappenbeck.net/osm/maps/deu/maps4osm.php?id=22 Ein Anfang ist hier zu finden: http://www.openstreetmap.org/browse/relation/1087074 André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Abbiegerelation bei Auffahrten
Wie sollte man eine Abbiegerelation bei einer Auffahrt (link) zu einer Bundesstraße gestalten? Ich habe unterschiedliche Arten in der OSM-Karte gefunden: * nicht links abbiegen (no_left_turn) * nur geradeaus fahren (only_straight_on) * nur rechts abbiegen (only_right_turn) Mit der ersten Variante kommt Skobbler nicht zurecht. Bei Variante 2 und 3 bin ich mir nicht sicher, wie man das Auffahren von einer Auffahrt auf eine Bundesstraße verkehrstechnisch überhaupt sieht: Ist es ein Rechts-abbiegen oder ein Einfädeln und damit Geradeausfahren? Habe im Netz keine Hinweise auf diesen Fall gefunden. Wie seht Ihr das? Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Am 25. Juli 2010 14:08 schrieb Thomas thomas.ebe...@t-online.de: Wie sollte man eine Abbiegerelation bei einer Auffahrt (link) zu einer Bundesstraße gestalten? Ich habe unterschiedliche Arten in der OSM-Karte gefunden: * nicht links abbiegen (no_left_turn) * nur geradeaus fahren (only_straight_on) * nur rechts abbiegen (only_right_turn) Mit der ersten Variante kommt Skobbler nicht zurecht. Mit Hilfe von http://osm.virtuelle-loipe.de/restrictions/ kannst du Testen ob die Abbiegebeschränkung korrekt eingetragen ist. Bei Variante 2 und 3 bin ich mir nicht sicher, wie man das Auffahren von einer Auffahrt auf eine Bundesstraße verkehrstechnisch überhaupt sieht: Ist es ein Rechts-abbiegen oder ein Einfädeln und damit Geradeausfahren? Dem Router sollte die Art egal sein, sollange er weiß welche Strecke er benutzen darf (bspw. wenn er von A kommt, darf er nicht nach B sondern nur nach C oder D fahren). Ob Variante 2 oder 3 ist bauliche Ausführung und Kreuzungsgeometrie entscheidend. Dies sollte aber wie gesagt keinen Einfluss auf das Routingergebnis haben. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenverlust
M∡rtin Koppenhoefer glaubte zu wissen: Am 25. Juli 2010 01:09 schrieb Florian Gross usenet- Das heißt, wenn ich einen Track von einer Radroute nehme, der unter CC-by-SA freigegeben wurde und mit dessen Hilfe noch ein paar fehlende Wege eintrage und die Relation erstelle, müßte ich die nach einem Lizenzwechsel löschen? Zumindest wenn ich keine Freigabe zur Nutzung in OSM bekomme? Halte ich ebenfalls für hypothetisch und unrealistisch: ohne Detail-Kenntnis der Lage vor Ort kannst Du m.E. nur mit einer GPS-Spur als Quelle keine fehlenden Wege nachtragen z.B. als highway=road mit fixme oder einen Eintrag bei OpenStreetBugs. Wenn mal was da ist, steigt die Chance, daß es von jemandem berichtigt wird. Soviel weiß ich, daß die Route über wenig befahrene Straßen, asphaltierte oder gut geschotterte Feldwege verläuft. Die fehlenden Wege befinden sich an recht steilen Hängen mit Weinbergen, Feldern, Wiesen und Wäldern. Weit und breit keine Ortschaft. In der Haupsache gibt es dort Feldwege, vielleicht noch eine unclassified und das wars. oder eine Radweg-Relation erstellen. Und eine kleine Abweichung am Anfang sehe ich auch nicht so wild, auch die werden behoben werden. Ich werd die Strecke auch mal abfahren, aber bei 120km mit um die 2700hm noch nebenbei mappen dauert etwas länger... Darum geht es mir aber gar nicht: Das gpx ist mit CC-BY-SA versehen. Was passiert, wenn ich mir das gpx in JOSM lade, die fehlenden Wege einmale, die Relation erstelle und dann kommt der Lizenzwechsel? Muß ich die Relation und die auf Basis des gpx- Files eingetragenen Wege wieder löschen? Solange das unklar ist, trag ich nichts dazu ein. flo -- Stefan Hertrich wrote: nüscht Stramme Leistung - und das glatte 13mal in 3 Minuten [Ellen Fink in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Hallo Thomas, Wie sollte man eine Abbiegerelation bei einer Auffahrt (link) zu einer Bundesstraße gestalten? Ich habe unterschiedliche Arten in der OSM-Karte gefunden: * nicht links abbiegen (no_left_turn) * nur geradeaus fahren (only_straight_on) * nur rechts abbiegen (only_right_turn) Mit der ersten Variante kommt Skobbler nicht zurecht. Bei Variante 2 und 3 bin ich mir nicht sicher, wie man das Auffahren von einer Auffahrt auf eine Bundesstraße verkehrstechnisch überhaupt sieht: Ist es ein Rechts-abbiegen oder ein Einfädeln und damit Geradeausfahren? Der Router sollte eigentlich nur auf no oder only achten, der Rest ist für die graphische Darstellung und die einfachere Verständlichkeit für uns Menschen. Daher überrascht es mich, dass die erste Variante mit Skobbler nicht funktionieren soll - ich vermute da eher einen Fehler in der Relation. Hast Du einen Link zur entsprechenden Auffahrt? 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 lef t-right - neues Datenmodell nötig!?
M?rtin Koppenhoefer dieterdre...@gmail.com wrote: 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. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways und Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. Hmm, von diesem Konzept habe ich noch nichts gelesen. Gibt es da was im Wiki? Wenn ich Dich richtig verstehe, habe ich zumindest die Einzelspurführung beispielhaft in Ansätzen an dieser Kreuzung versucht: http://sautter.com/map/?zoom=18lat=51.20167lon=6.90545layers=00B000TTFF Meinst Du so etwas? Wenn ja, ist das erst einmal reichlich mühsam. So wie ich jetzt abschätze, mühsamer als wenn man Spuren zusammenklicken könnte, z.B. weil die Tags zigmal gemappt werden müssen. Da müsste der Editor dann kräftig mithelfen - zum Beispiel Taggruppen applizieren durch Mausklick auf Weg. Anzeige der Tags und Relationen durch Maus-Drüberhalten. Und es wirft neue Probleme auf - beispielsweise beim Rendering. Bei Spurtrennung - egal bei welchem Vefahren - reicht der nicht ausreichende Zoom von Online-Mapnik (Osmarender erst recht), um das zu kontrollieren. Wenn jede Spur individuell und nicht als Bündel geführt ist, muss die Auflösung noch höher sein. Außerdem müssen die Renderer erheblich intelligenter werden. Im Augenblick bekommen die es nicht einmal gebacken, eine Radspur oder Eisenbahn neben der Straße nicht zu verdecken. Ein anderes Problem ist, dass beim Einzelspurmapping die Information darüber verloren geht, welche Spuren zu einer Straße gehören. So etwas kann dann an Kreuzungen oder Abzweigungen Routenanweisungen produzieren, wie: Abbiegen von A-Straße auf A-Straße, 2 Meter. Abbiegen von A-Straße auf A-Straße, 1 Meter. Abbiegen von A-Straße auf A-Straße, 3 Meter. Abbiegen von A-Straße auf A-Straße, 1 Meter. Abbiegen von A-Straße auf A-Straße, 2 Meter. In anderen Fällen fehlt eine Abbiegeanweisung, obwohl sie notwendig wäre. Sie fehlt, weil offensichtlich durch das Zeichnen der Abbiegung im Bogen ein Geradeaus-Lauf vermutet wird. Bisher konnte dies offensichtlich über den Abbiegewinkel festgestellt werden. Muss man dann Relationen verwenden, um das Auseinderdividierte wieder zusammen zu bringen bzw. um in der Praxis vorhandene Geradeausführung und Abbiegung deutlich zu machen? Brauchen wir Einsammel-Relationen für Straßen zur Darstellung der funktionellen Zusammenhänge dann nicht nur für Referenzstraßen, sondern für jede spurgeteilte Straße? Sollen gestrichelte und durchgehende Linien auch als einzelne Spur oder als links/rechts gemappt werden? Sind solche und weitere Probleme dabei schon bis zu Ende gedacht? Ich nehme an, mit Areas meinst Du das, was derzeit bei großen Flüssen gemacht wird. Richtig? Ich weiß, eine Menge Fragen. Aber sie drängen sich auf. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Hallo Guenther, Es gibt im grossen und ganzen nur zwei Moeglichkeiten: Man entwickelt was total eigenes, unabhaengig und parallel zum bestehenden Schema, oder man versucht das bestehende zu erweitern. Letzteres mag zwar Konflikte verursachen, aber letztendlich sehe ich da eine wesentlich hoehere Wahrscheinlichkeit, dass es auch angenommen wird. Chaos wird's (in einer Uebergangsphase) immer geben. Nein. Am Anfang war amenity=parking. Dann kam das Proposal für Entlang von Strassen parken. Solange das neue Konzept nicht versucht das Alte zu ersetzen muss dies auch nicht zu einem Chaos führen. Genau so wäre es bei der Einführung eines Taggings für einzelne Parkstände. naja, es bringt ja nix, wenn man das tollste Schema hat, und es nur von drei Leuten benutzt wird ;-) die alte Problematik existiert ja immer noch: getaggt wird bevorzugt, was auch gerendert wird, aber gerendert wird das was oft genug vorkommt. Inzwischen hat man übrigens herausgefunden, dass die Henne vor dem Ei da war: http://de.news.yahoo.com/34/20100715/tsc-huhn-oder-ei-forscher-finden-antwort-98fda55.html ;-) 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!?
Am 25. Juli 2010 14:54 schrieb Tirkon tirko...@yahoo.de: 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. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways und Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. Meinst Du so etwas? Wenn ja, ist das erst einmal reichlich mühsam. So wie ich jetzt abschätze, mühsamer als wenn man Spuren zusammenklicken könnte, z.B. weil die Tags zigmal gemappt werden müssen. Da müsste der Editor dann kräftig mithelfen - zum Beispiel Taggruppen applizieren durch Mausklick auf Weg. Anzeige der Tags und Relationen durch Maus-Drüberhalten. ... ja klar, mühsamer ist es, aber nicht komplizierter. Darum gings Dir doch: man kann erst anfangen damit, wenn es einen bequemen Editor gibt, sonst sei es so kompliziert, dass man OSM studiert haben muss, um etwas editieren zu können. Das glaube ich aber nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] natural=tree und village_green
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 24.07.2010 13:24, schrieb p...@wuzel.de: Ich habe die Diskussion nicht verfolgt, aber der Feldmochinger Anger ist keine Grünfläche oder so was ähnliches, sondern ein Ortsteil. Vielleicht ist ja das gemeint? http://www.lbv-muenchen.de/Arbeitskreise/Biotope/biotop.aussen2/feldmoch.anger.htm Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxMXdIACgkQnMz9fgzDSqcYyACgoNgj/2fE7IHl5o7wJ+3eg7K/ RPQAmwUf3KLjE4IBGYVLdIqodk4Nt39M =JJPZ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutschen
Am 25.07.2010 um 12:41 schrieb Guenther Meyer d@sordidmusic.com: Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: Hi, ich möchte damit weder provozieren, noch die 'alte Diskussion wi eder hochkochen lassen. Erlaubt mir aber dennoch folgende Frage: Warum weiss jeder in Deutschland, dass - ein Behindertenparkplatz kein großer Parkplatz für Behinderte ist (in der Größe von amenity=parking) - ein Frauenparkplatz kein goßer Parkplatz für Frauen ist - ein Elternparkplatz kein großer Parkplatz für Eltern mit Kindern ist - ein Motorrardparkplatz kein großer Parkplatz für Motorräder ist All diese Parkplätze sind eigentlich Parkstände/Stellplätze, wie ich hier lernen konnte. Doch warum in Gottes Namen heissen sie Parkplä tze, wenn sie doch, im Sinne von dem was laut Wiki amenity=parking bedeutet, gar nicht sind? jetzt ist es also ein sprachliches Problem... Zumindest in DE scheint es so zu sein, dass daher die Diskussionen rühren. Ich verstehe allerdings auch fürs Englische nicht, dass wenn man schon nur große Parkplätze meint, den Tag parking genannt hat, anstatt car_park oder parking_area... Viel schlimmer ist aber dad Ergebnis meiner Diskusionsgrundlage hier. Dabei kam ja leider heraus, dass man parking auf keinen Fall verallgemeinern darf, weil es schon gefühlte 3 Milliarden mal so getaggt wurde. Aber das kann man in dem anderen Thread weiter diskutieren... es ist eigentlich ganz einfach: amenity = parking bedeutet ausgewiesene Parkmoeglichkeit, nicht mehr und nicht weniger. Nein, sonst könnten ja auch Einzelparkplätze mit parking getaggt werden, da auch diese ein P auf dem Schild haben (siehe andere Diskussion). Das Problem ist, dass es eben nicht so interpretiert wird, wie Du schreibst, sondern total absolut: amenitiy=parking=großer Parkplatz mit eigenen Wegen zwischen den Parkständen. Man sagt hier relativ übereinstimmend, dass Einzelparkplätze deshalb eben nicht genauso getaggt werden dürfen, sondern eigene Tags benötigen würden, weil sie als solche als Einzel-nodes auch auf einem großen Parkplatz z.B. einen Behindertenparkplatz kennzeichnen können. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutschen
Am 25.07.2010 um 14:04 schrieb Bodo Meissner b...@bodo-m.de: Am 25.07.2010 12:41, schrieb Guenther Meyer: Die Angabe kleine Parkmoeglichkeiten taggen wir nicht steht von Anfang an auf der Wikiseite. Ich kann mir nur vorstellen, dass damals damit verhindert werden sollte, dass alles mit Parkplaetzen zugekleistert wird. Das wird auch dadurch bestaetigt, dass damals kein separates Tag fuer diese Stellplaetze dokumentiert wurde. Aber heutzutage, wo jeder Baum und Kanaldeckel getaggt wird, und die Mapper und auch Renderer wesentlich differenzierter arbeiten, halte ich so eine Begruendung fuer obsolet. +1 + 1 Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: und wie man das am besten Neuusern verklickert, die geneigt sind aus obigem Grund natürlich überall ein amenity=parking hinzubauen und einen Key f ür die Art des Parkplatzes (disabled, women, parent, motorbike) hinbauen. in dem man den Wikitext entsprechend anpasst. Was soll denn bitteschoen kaputtgehen? +1 + 1 Ich kann schon nachvollziehen, daß es Unklarheit schafft, wenn jetzt einzelne Stellplätze ohne Zusatztags als amenity=parking bezeichnet werden. Um das zu vermeiden, würde ich im Wiki dokumentieren, daß einzelne S tellplätze oder Parkplätze mit geringer Kapazität immer ein capacity-Tag haben sollen. Das könnte auch von Editor-Presets unters tützt werden. Bei Parkplätzen, die nach der bisherigen Beschreibung im Wiki keine ausreichende Größe haben, kann man nicht argumentieren , daß die Erfassung (Schätzung) der Kapazität nicht praktikabel oder zu aufwändig wäre. Bei Parkplätzen ohne capacity können wir annehmen, daß es sich entsprechend der alten Beschreibung um größere Parkplätze handelt. (Andernfalls ist es ein Fehler im Tagging.) Dann müßte man bei Bedarf nur noch den Renderern beibringen, ab irge ndeiner Kapazitätsgrenze eine Unterscheidung zu machen. Insoweit sehe ich da auch kein wirkliches Problem. + 1 Allerdings wird mit diesem Vorschlag nicht die Frage beantwortet, wie man auf einem großen Parkplatz mit mehreren Stellplätzen/ Parkständen die Bereiche kennzeichnet, die bestimmten Fahrzeugen ode r Fahrzeugnutzern vorbehalten sind. Möglicherweise kann man das mit parking:lane lösen. Falls das zu kom pliziert ist, braucht man eben (wie bereits gesagt) geeignete Presets. Angenau diesem Punkt scheiden sich eben die Geister. Ein einzelner Node ist halt einfacher auf einer Fläche zu taggen. Mein Gedanke ist derzeit, so vorzugehen: 1.Area mit normalen Parkständen: amenity=parking capacity:standard=360 2.Area mit Parkständen für Behinderte: amenity=parking capacity:disabled=2 3. Area mit Parkständen für Eltern: amenity=parking capacity:parents=18 4. Area mit Parkständen für Frauen: amenity=parking capacity:women=20 Alle 4 Areas in eine Relation für den gesamten Parkplatz, um zu zeigen, dass alle Areas zusammen gehören: amenity=parking capacity=40 Damit wäre erreicht: 1. Die Spezialparkplätze sind eindeutig zu lokalisieren. 2. Da es sich faktisch um Flächen handelt, ist area nicht falsch. 3. Durch die Relation ist klar, dass alles zu einem Parkplatz gehört. Das setzt natürlich voraus, dass parking als Überbegriff für ausgewiesene Parkplätze anerkannt wird! Alternative: 1. Gesamtparkplatz in eine Area mit allen Zufahrtswegen, etc. Und das multipolygon als inner taggen. 2. Alle Spezialparkstände und auch die Fläche der normalen Parkstände jeweils als outer vom mulipolygon mit obigen tags versehen. Auch dann ist alles zusammengefasst und dennoch sind die einzelnen Bereiche gleichwertig nebeneinander getaggt. Beide Varianten funktionieren natürlich auch mit jeweils eigenen tags, dad capacity sollte aber dennoch nicht fehlen. Deshalb wären alle Varianten gleich aufwändig. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Abbiegerelation bei Auffahrten
Die Relation 530.958 beispielsweise wird von Skobbler offenbar falsch erkannt. (Skobbler hat mich hier übrigens entgegen der Einbahnstraße über die benachbarte Abfahrt geschickt.) Ich würde diese Relation auch mit only_straight_on versehen. Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Am 25. Juli 2010 18:33 schrieb Thomas thomas.ebe...@t-online.de: Die Relation 530.958 beispielsweise wird von Skobbler offenbar falsch erkannt. (Skobbler hat mich hier übrigens entgegen der Einbahnstraße über die benachbarte Abfahrt geschickt.) Ich würde diese Relation auch mit only_straight_on versehen. http://www.openstreetmap.org/browse/relation/530958 Das Problem an diesem Beispiel ist, dass bei no_-Restriktionen der Zielweg, welcher nicht befahren werden darf, als to in die Relation aufgenommen werden muss. In deinem Beispiel ist der Weg nach Süden also verboten und Skobbler leitet dich entsprechend der Daten. http://osm.virtuelle-loipe.de/restrictions/?lat=50.371356lon=7.694508zoom=18layers=M Zeigt übrigens den genannten Fehler. Ein only_straight_on oder besser ein only_right_turn wären die einfachste Lösungen. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Die beiden Abbiegebeschränkungen im Süden sind auf Grund der Einbahnstraßenregelung obsolet und können gelöscht werden. http://osm.virtuelle-loipe.de/restrictions/?lat=50.36921lon=7.69431zoom=18layers=B00TT André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutschen
Am Sonntag 25 Juli 2010, 17:57:06 schrieb steffterra: Am 25.07.2010 um 12:41 schrieb Guenther Meyer d@sordidmusic.com: Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: Hi, ich möchte damit weder provozieren, noch die 'alte Diskussion wi eder hochkochen lassen. Erlaubt mir aber dennoch folgende Frage: Warum weiss jeder in Deutschland, dass - ein Behindertenparkplatz kein großer Parkplatz für Behinderte ist (in der Größe von amenity=parking) - ein Frauenparkplatz kein goßer Parkplatz für Frauen ist - ein Elternparkplatz kein großer Parkplatz für Eltern mit Kindern ist - ein Motorrardparkplatz kein großer Parkplatz für Motorräder ist All diese Parkplätze sind eigentlich Parkstände/Stellplätze, wie ich hier lernen konnte. Doch warum in Gottes Namen heissen sie Parkplä tze, wenn sie doch, im Sinne von dem was laut Wiki amenity=parking bedeutet, gar nicht sind? jetzt ist es also ein sprachliches Problem... Zumindest in DE scheint es so zu sein, dass daher die Diskussionen rühren. Ich verstehe allerdings auch fürs Englische nicht, dass wenn man schon nur große Parkplätze meint, den Tag parking genannt hat, anstatt car_park oder parking_area... Viel schlimmer ist aber dad Ergebnis meiner Diskusionsgrundlage hier. Dabei kam ja leider heraus, dass man parking auf keinen Fall verallgemeinern darf, weil es schon gefühlte 3 Milliarden mal so getaggt wurde. Aber das kann man in dem anderen Thread weiter diskutieren... es ist eigentlich ganz einfach: amenity = parking bedeutet ausgewiesene Parkmoeglichkeit, nicht mehr und nicht weniger. Nein, sonst könnten ja auch Einzelparkplätze mit parking getaggt werden, da auch diese ein P auf dem Schild haben (siehe andere Diskussion). genau darauf will ich hinaus. Die Unterscheidung bereits im Haupttag zu machen, bringt keinerlei Vorteile. Das Problem ist, dass es eben nicht so interpretiert wird, wie Du schreibst, sondern total absolut: amenitiy=parking=großer Parkplatz mit eigenen Wegen zwischen den Parkständen. das ist deine Meinung. Eine Parkmoeglichkeit wird ueblicherweise als Parkplatz bezeichnet, womit auch das Tag wieder passt ;-) Man sagt hier relativ übereinstimmend, dass Einzelparkplätze deshalb eben nicht genauso getaggt werden dürfen, sondern eigene Tags benötigen würden, man? zwei Leute...?! weil sie als solche als Einzel-nodes auch auf einem großen Parkplatz z.B. einen Behindertenparkplatz kennzeichnen können. der groesste Teil der POI-Tags kann sowohl fuer Flaechen als auch fuer Punkte verwendet werden, OHNE dass man dafuer ein anderes Tag braucht. Warum sollte das bei Parkmoeglichkeiten ploetzlich nicht gehen? 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] Sprachverständis Parkplatz im Deutsche n
Hallo steffterra ! Ich denke mir, Du machst Dir da zu große Sorgen. Parkplatz ist ein Platz zum Parken, wie groß der ist, ergibt sich aus dem Kontext. Und ja, am Hofer-(Aldi-)Parkplatz gibt es auch Behindertenparkplätze und Parkplätze für Eltern mit Kinderwagen usw. Was jetzt das Tagging angeht, so sehe ich amenity=parking am ehesten dort richtig, wo auch ein blaues P das als Parkplatz (im Sinne von Kundenparkplatz vor'm Aldi oder ParkRide Parkplatz vor der S-Bahn usw.) ausweist. Damit wissen dann auch die Renderer, daß sie dort ein blaues P hinmachen sollen und die Router wissen, daß sie dort hinrouten, wenn Du mit dem Auto zum Aldi willst usw. Daß man auf sehr, sehr vielen highway=residential (mal links, mal rechts, mal beidseitig) parken darf, gehört irgendwie gemeinsam mit den ganzen Wegebündeln/Fahrbahnen/Gehsteigen/Radwegen/Parkstreifen gelöst. Und wichtige Einzelparkplätze (wie der Behindertenparkplatz) gehören separat gelöst, hier ist ein Behindertenparkplatz für n Fahrzeuge. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übernahme von Grenzen aus dem Wiki
Am 25.07.2010 13:32, schrieb Jan Tappenbeck:
Das Einpassen dieser Bilder in JOSM etc gestaltet sich auf Grund der
Auflösung relativ mühsam und schwierig.
Hat das schon einmal einer von Euch gemacht - gibt es einen Tipp oder
gar bessere Alternativen ??
Hallo Jan,
Ja, ich hab vor einiger Zeit für Rheinland-Pfalz die Gemeindegrenzen
aus der zugehörigen SVG-Datei in ein Linien-Netz im OSM-Format
übertragen. Das zugehörige (Anfänger-) Perl-Skript habe ich mal angehängt.
Für das Eintragen der Grenzen habe ich in JOSM dann stets per Hand die
entsprechenden Linien aus dem Netz kopiert und in die bestehenden
Grenzen eingepasst. Bzw. mache ich das zur Zeit immer noch. ;)
Alternativ könnte man auch mit dem Pic-Layer-Plugin für JOSM arbeiten.
Beste Grüße,
Rainer
#!/usr/local/bin/perl -w
use strict;
use XML::Simple;
use Data::Dumper;
# Datei für die Ausgabe
my $datei;
if ($ARGV[0] =~ /(.*)\..*/) { # Dem Namen der Quelldatei...
$datei = $1..osm;}# wird '.osm' angehängt
my $xml_file = $ARGV[0];# übergebene Quelldatei
my $svg = XMLin($xml_file,KeyAttr = [ 'id' ]);#, ForceArray = 1 ,KeyAttr = [
'id' ]);# Hash-Ref-Präsentation der Quelldatei einlesen
#print Dumper($svg);
my $counter = -1; # Counter für IDs; neue Objekte bekommen negative ID
my %points; # Hash für die einzelnen Punkte
my %ways; # Array für die Wege
my $bound = 9; # Toleranz-Bereich für das Zusammenfassen von einzelnen Punkten
my $Xt0 = 6.1123607;
my $Xtmax = 8.5081187;
my $Yt0 = 48.9664903;
my $Ytmax = 50.9423256;
my $op = 0.1;
# my $xoffset = ($svg - {'metadata'} - {'sfw'} - {'sliceSourceBounds'} -
{'height'});
# my $yoffset = ($svg - {'metadata'} - {'sfw'} - {'sliceSourceBounds'} -
{'width'});
my $xoffset = 0;#(split(/p/,($svg - {'height'})))[0] * 1000;
my $yoffset = 0;#(split(/p/,($svg - {'width'})))[0] * 1000;
my $xmove = $Xt0;#6.0598186363180273655729182125389;
my $ymove = $Yt0;#48.96675;
my $xscale = 1;#0.22094002495090722302913205119244;
my $yscale = 1;#0.14253259328335299271675824592552;
# {Node id=323674752 version=1 V lat=50.9399869,lon=7,7863774}
# {Node id=-892413 version=0 V lat=13,84411,lon=7,7336}-1,9527
#1,9732369 -0,4135326
#{Node id=323819272 version=2 V lat=50.2192956,lon=6,166803}
{Node id=660910430 version=1 V lat=49.7678655,lon=8,4744133} 2,3076103
#{Node id=-1004791 version=0 V lat=8,84328,lon=0,44394}
{Node id=-1002671 version=0 V lat=5.62563,lon=10,88845}10,44451
# {Node id=323465585 version=1 V lat=50.9403419,lon=7.8132735}
# {Node id=-879087 version=0 V lat=13.84454,lon=7.81777}
#print $xoffset,, ,$yoffset,\n;
#my @borders = (@{$svg - {'switch'} - {'g'} - {'g'} - {'Gemeinden_1_'} -
{'polygon'}});# die Gemeindeumrisse aus der Quelldatei in Array einlesen
my @borders = (@{$svg - {'g'} - {'Gemeinden_1_'} - {'polygon'}});
#Ortsgemeinden RLP
# my @borders = (@{$svg - {'switch'} - {'g'} - {'g'}});
# foreach my $hashref (@borders){
# if ($$hashref{'id'} eq 'Gemeinden_1_'){
# @borders = (@{$hashref - {'polygon'}});
# last;
# }
# }
# @{$svg - {'switch'} - {'g'} - {'g'} -
{'Kreise_Borders'} - {'polygon'}});
# Gemeindegrenzen einlesen
print Punkte Wege einlesen\n;
my %roughpoints;
my %simpleways;
my %pointcount;
foreach my $polygon (@borders){ # aktuelle Grenze
my $points = $$polygon{'points'}; # String mit Grenzpunkten
einlesen
my @points = split(/\s+/,$points); # Punkte an den Leerzeichen
aufteilen
push (@points,$points[0]); # ersten Eintrag
wiederholen um Grenzeverlauf zu schlieÃen
# Punkte Wege einlesen
for(my $i = 0;$i @points;$i++){
#Eng beieinander liegende Punkte zusammen fassen
my @tp = split(/,/,$points[$i]);
# aktuellen Punkt in Koordinaten aufteilen
# temporäre Variable für Punktereferenz
for (0,1) {$tp[$_] = $tp[$_] * 1000;}
if ($tp[0] $xoffset) {$xoffset = $tp[0];}
if ($tp[1] $yoffset) {$yoffset = $tp[1];}
my @compare = @tp;
push (@compare,($tp[0] + $bound,
$tp[1] + $bound,
$tp[0] - $bound,
$tp[1] - $bound));
foreach my $tp (@compare){chop $tp;}
#print $points[$i],\n;
#print \t,@compare,\n;
my $tp = undef;
for my $k1 (0,2,4){
for my $k2 (1,3,5){
my $pkey = ($compare[$k1]).($compare[$k2]);
Re: [Talk-de] Abbiegerelation bei Auffahrten
Am 25.07.2010 um 14:08 schrieb Thomas thomas.ebe...@t-online.de: Wie sollte man eine Abbiegerelation bei einer Auffahrt (link) zu einer Bundesstraße gestalten? Ich habe unterschiedliche Arten in der OSM-Karte gefunden: * nicht links abbiegen (no_left_turn) * nur geradeaus fahren (only_straight_on) * nur rechts abbiegen (only_right_turn) Mit der ersten Variante kommt Skobbler nicht zurecht. Was sagt/macht Skobbler denn? Je nachdem gibt es dazu mehrere Fakten. Ein Fakt ist, dass cloudmade noch nicht mit allen Abbiegerelationen in jeder Situation klar kommt. Das hat aber nichts mit Abbiegeansagen zu tun, da diese nicht aus den Abbiegerelationen generiert werden, sondern aus den Winkeln der beteiligten ways. Bei Variante 2 und 3 bin ich mir nicht sicher, wie man das Auffahren von einer Auffahrt auf eine Bundesstraße verkehrstechnisch überhaupt sieht: Ist es ein Rechts-abbiegen oder ein Einfädeln und damit Ge radeausfahren? Hast du eine echte Kreuzung, ist es ein Abbiegen. Existiert eine Auffahrtsspur ist es ein Einfädeln nach links, aber weder ein Abbiegen nach links (man fährt ja nicht nach links weiter, wie bei einer Kreuzung, sondern in die gleiche Richtung, wie die Auffahrtsspur, also nach dem Einfädelvorgang geradeaus), noch ein Abbiegen nach rechts. Habe im Netz keine Hinweise auf diesen Fall gefunden. Wie seht Ihr das? Du musst hier zwei Dinge trennen: 1. Die Abbiegerelationen, die nur sagen, wie man abbiegen darf, und damit, wie der Router seinen Weg nehmen darf. Diese haben aber nichts mit der Anweisungsgenerierung ala Jetzt leicht nach rechts abbiegen zu tun. 2. Der Winkel, in dem sich treffende ways am gemeinsamen Knoten treffen. Nur aus diesen Winkeln wird die Ansage generiert Jetzt leicht nach rechts abbiegen. Es wäre super, wenn Du die Auffahrt bitte auf maps.cloudmade.com nachvollziehen könntest und uns den permlink hier postest. Dann kann man Dein Problem nochmal schön nachstellen. Danke. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Am 25.07.2010 um 18:33 schrieb Thomas: Die Relation 530.958 beispielsweise wird von Skobbler offenbar falsch erkannt. (Skobbler hat mich hier übrigens entgegen der Einbahnstraße über die benachbarte Abfahrt geschickt.) Ich würde diese Relation auch mit only_straight_on versehen. Sei bitte so freundlich und vollziehe das nochmal auf maps.cloudmade.com nach und poste den permlink. Danke :-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: MapPaint-Stil verloren? Alles in blau
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, Ich weiß nicht wie ich es verbrochen habe, aber seit gestern zeigt mir JOSM die Map nur noch in Blautönen an. [1] Zwar gibt es einzelne Variationen bei den ways, die POI sind aber durchgängig hellblau, keine Icons, nichts. Hat jemand eine Idee, was hier mit dem MapPaint-Stil passiert ist und wie man das wieder beheben könnte? Beste Grüße, Rainer [1] http://osm.bundesrainer.de/osm/josminblau.jpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJMTH7HAAoJEPT/XJzV1tNztRsIAKW4ifa/7biiXIm0fM0fGQJ8 L065Wcu9+FF4fd501aZOmgCYPVUE2KMQlLQyG0mMA/ESZCn3YWFmbF8HMSAp/Ir3 V3euX85mOClhE7bVor1mOOA0t2HbcYPVrtVLhQGX1sGL2JBkKqmGi8D8vq9dmMi/ le8RDjHo2EQYSsVAfifk7/30Es3n7+O8qSnp7Gu+JzN1NSiBbojSSSF7fzDQW5v+ wUmHDOMKOKVozHhHzEFDLpttWWFtPeuN8NRoGsfJ7yZV6/KVzIaD9NOponRvfupV idhmT+ebugVSRY4pMCickeJMrzvatC4Uc7FdugEKbWBwW5kKx0rUKo8vk/bUG0o= =hpe7 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Am 25.07.2010 um 18:59 schrieb Guenther Meyer: Das Problem ist, dass es eben nicht so interpretiert wird, wie Du schreibst, sondern total absolut: amenitiy=parking=großer Parkplatz mit eigenen Wegen zwischen den Parkständen. das ist deine Meinung. Eine Parkmoeglichkeit wird ueblicherweise als Parkplatz bezeichnet, womit auch das Tag wieder passt ;-) Nein es ist nicht meine Meinung ;-) Ich habe dir nur geschrieben, was hier bisher diskutiert wurde. Ich empfehle Dir, die vorangegangene Diskussion noch nachzulesen und dann auf dieser Basis wieder in die Diskussion einzusteigen. Denn dann wirst Du sehen, dass ich ganz Deiner Meinung bin, den amenity-tag für parking als Oberbegriff für alle Parkarten umzustellen. Dazu habe ich auch diverse Vorschläge für die Umsetzung gemacht, welchen aber bisher aufs heftigste widersprochen wurde. Man sagt hier relativ übereinstimmend, dass Einzelparkplätze deshalb eben nicht genauso getaggt werden dürfen, sondern eigene Tags benötigen würden, man? zwei Leute...?! Nunja. Finde es heraus. Mache ein gutes Proposal, das alle Sonderfälle und Kritikpunkte berücksichtigt und stelle es offiziell zur Abstimmung im Wiki. Auch solltest Du dafür die anderen Proposals für parking:lane und more-capacity-keys mitberücksichtigen Ich helfe Dir gerne dabei. weil sie als solche als Einzel-nodes auch auf einem großen Parkplatz z.B. einen Behindertenparkplatz kennzeichnen können. der groesste Teil der POI-Tags kann sowohl fuer Flaechen als auch fuer Punkte verwendet werden, OHNE dass man dafuer ein anderes Tag braucht. Warum sollte das bei Parkmoeglichkeiten ploetzlich nicht gehen? Es geht um das taggen von flächen auf flächen mit dem selben tag. Das sollte in der Tat nciht sein. Deshalb meine beiden Vorschläge, aus dem anderen Posting: Möglichkeit a) Alle areas der Parkarten in je einem outer-Multipolygon des umgebenden Gesamparkplatz multipolygon (inner) Möglichkeit b) Einzel-Areas, die über eine Relation zum Gesamtparkplatz zusammengefasst werden. Bei beiden Varianten wären zusätzliche Einzeltags überflüssig, sofern man diese Unterscheidung im capacity-tag unterbringt (z.B. capacity:disabled=2) und amenity=parking als Überbegriff akzeptiert. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übernahme von Grenzen aus dem Wiki
hi jan, schau dir den thread postleitzahlen-import an. da bekommst du die grenzen alle plz-gebiete. und die sind fast immer identisch mit den gemeindegrenzen, wenn du die größeren staedte mit mehreren plz-nummern draussen vor läßt. die grenzen stimmen zwar nicht 100%, sollen hier aber verbessert werden. gruss walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/Ubernahme-von-Grenzen-aus-dem-Wiki-tp5334800p5335592.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] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 25.07.2010 um 14:54 schrieb Tirkon: Ich weiß, eine Menge Fragen. Aber sie drängen sich auf. Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Am 25.07.2010 um 19:27 schrieb Andreas Labres: Hallo steffterra ! Ich denke mir, Du machst Dir da zu große Sorgen. Nein ich sehe es genauso. Auch ich bin dafür, dass amenity=parking zum Überbegriff für Parkplätze und Parkstände wird und eben _nicht mehr_ so ausgelegt wird, wie es traditionell mal vorgesehen war und es im wiki auch dokumentiert ist. Ich halte den Wikieintrag für überholt. Aber das habe ich auch alles schon geschrieben. Ich habe lediglich den Gesamteindruck wieder gegeben, der sich mir durch den heftigen Widerstand in der bisherigen Diskussion erlebt habe. Parkplatz ist ein Platz zum Parken, wie groß der ist, ergibt sich aus dem Kontext. Und ja, am Hofer-(Aldi-)Parkplatz gibt es auch Behindertenparkplätze und Parkplätze für Eltern mit Kinderwagen usw. +1 Was jetzt das Tagging angeht, so sehe ich amenity=parking am ehesten dort richtig, wo auch ein blaues P das als Parkplatz (im Sinne von Kundenparkplatz vor'm Aldi oder ParkRide Parkplatz vor der S-Bahn usw.) ausweist. +1 Damit wissen dann auch die Renderer, daß sie dort ein blaues P hinmachen sollen und die Router wissen, daß sie dort hinrouten, wenn Du mit dem Auto zum Aldi willst usw. und durch die keys weiss man auch welche Art Parkplatz es ist. Daß man auf sehr, sehr vielen highway=residential (mal links, mal rechts, mal beidseitig) parken darf, gehört irgendwie gemeinsam mit den ganzen Wegebündeln/Fahrbahnen/Gehsteigen/Radwegen/Parkstreifen gelöst. ohne Weg-/Linienbeündel/Gruppierung, ist es derzeit im Proposal parking:lane sehr gut formuliert und berücksichtigt wirklich nahezu jedes mir bekannte Zusatzschild an Parkständen/Plätzen. Das für ein Linienbündelähnliches Modell umzusetzen ist ein leichtes, da man auf left/right verzichten müsster und es einfach an der entsprechenden Spur taggen könnte. Und wichtige Einzelparkplätze (wie der Behindertenparkplatz) gehören separat gelöst, hier ist ein Behindertenparkplatz für n Fahrzeuge. +1 zwei Vorschläge, wie das für Areas gelöst werden könnte, habe ich heute bereits gepostet. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: MapPaint-Stil verloren? Alles in blau
bundesrainer schrieb: Ich weiß nicht wie ich es verbrochen habe, aber seit gestern zeigt mir JOSM die Map nur noch in Blautönen an. [1] Zwar gibt es einzelne Variationen bei den ways, die POI sind aber durchgängig hellblau, keine Icons, nichts. Hat jemand eine Idee, was hier mit dem MapPaint-Stil passiert ist und wie man das wieder beheben könnte? STRG+W ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, Ich möchte nochmal ganz wertfrei und ohne Vorbehalte darüber schreiben, was bei diesem Thema 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
Re: [Talk-de] JOSM: MapPaint-Stil verloren? Alles in blau
ctlw (Strgw für die Jüngeren unter uns) hast du probiert, oder? -fri- ___ 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 25.07.2010 um 03:51 schrieb M∡rtin Koppenhoefer: Am 21. Juli 2010 04:37 schrieb Tirkon tirko...@yahoo.de: 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. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways und Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. volle Zustimmung +10 ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: MapPaint-Stil verloren? Alles in blau
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.07.2010 20:43, schrieb Friedhelm Schmidt: ctlw (Strgw für die Jüngeren unter uns) hast du probiert, oder? Doh! Jetzt wird mir einiges Klar. :) Danke euch beiden. Beste Grüße, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJMTI6uAAoJEPT/XJzV1tNzX9wH/1AqDFSHsSSgrCPtIasTriuq F9GrdOwcATpdvxjMhpCHtMvXur2zjgHYr57bev8lv2W9MsAYlnTTARh/s7UDljYq R3EgHSIhZfoUSUd1dnAJa3kVaqOPetm0stJhQrlR210Fzk3szRA4Nlo5opDnJ8+d oyeGst1g1zmDHwv5WbDBesTAPKZhLP7Rj24Bc3p6QMrY7g0ByHRLvZ4rfOCx03fU BvwzjCzV27H7n8wOKEyF4HVsmkBeku38lZPua0TFFRGnQaO5M3lDVS/efTgjqtio DJR0Tm5E1uHcvJHaxZ62LyjIHZ74WUcsyy/pJYLEMjhEXuOqRDvucOvn2mwAeyY= =exXu -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO EUROPA -schon wieder futsch??
Hallo Sven, Die letzten beiden updates (21 und 23. Juli) der AIO Europa laufen wieder nicht auf meinem etrex Legend Cx. Die Karte vom Mittwoch läuft _definitiv_ auf meinem GPSMap 60CSx. Die von gestern hab ich nicht ausprobiert, aber der Prozess ist eigentlich sauber durchgelaufen. Das wundert mich. Bei Bayern ist zum Beispiel keine neue gmappsupp.img.zip vorhanden. Die letzte ist vom 19.7. Da scheint dann doch was abgebrochen, oder? Gruß Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
moin On 22.07.2010, at 15:47, Sven Geggus wrote: AssetBurned openstreet...@assetburned.de wrote: also die idee einen allgemeinen brewery=* zu machen find ich besser. Wie würdest Du denn dann einen ganz normalen industriellen Brauereikomplex taggen wollen? brewery=macro oder brewery=company ? nur mal so als zwei ideen. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Announce: Die Hausbrauereikarte - Open Brewpub Map
moin On 23.07.2010, at 15:46, Peter Körner wrote: Am 22.07.2010 16:47, schrieb Sven Geggus: Wie würdest Du denn dann einen ganz normalen industriellen Brauereikomplex taggen wollen? Nur ne Idee: man_made=works brewery=yes naja falsch ist das sicher nicht, nur wenn es unterhalb von brewery noch klassifikationen für verschiedene typen von brauerreien gibt... tja dann würde es erstmal nur bedeuten das es eine brauerrei ist, aber noch nix über die grösse aussagen. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ 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!?
steffterra steffte...@me.com wrote: Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Zumindest für meinen Teil ist es nicht untergegangen. Ich hatte auch schon dazu gepostet, dass man das Konzept durchgängig in vielen Situationen gemappt sehen muss. Leider in der OSM karte nicht machbar, da die Gefahr durch Veränderungen Anderer gegeben ist. Und rein aus der Textwüste ist so etwas nicht beurteilbar. Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) Bin schon öfter nach solchen Ankündigungen gespannt gewesen. Mal sehen, ob trotz der von mir oben schon ausführlich beschriebenen Widrigkeiten und insbesondere ohne Versuchs-Miniplanet diesmal was kommt. ___ 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 25.07.2010 um 22:09 schrieb Tirkon: steffterra steffte...@me.com wrote: Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Zumindest für meinen Teil ist es nicht untergegangen. Ich hatte auch schon dazu gepostet, dass man das Konzept durchgängig in vielen Situationen gemappt sehen muss. Da ich auch in anderen Projekten gut eingespannt bin, habe ich derzeit nicht die Ressourcen, das in Bildbeispielen/Screenshots zu erläutern. In einem entsprechenden Proposal würden solche Beispiele aber unerlässlich und sehr zum Verständnis beitragen. Deshalb habe ich das auf jeden Fall im ToDo. Leider in der OSM karte nicht machbar, da die Gefahr durch Veränderungen Anderer gegeben ist. Und rein aus der Textwüste ist so etwas nicht beurteilbar. +1 Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) Bin schon öfter nach solchen Ankündigungen gespannt gewesen. Mal sehen, ob trotz der von mir oben schon ausführlich beschriebenen Widrigkeiten und insbesondere ohne Versuchs-Miniplanet diesmal was kommt. Ich möchte vorher noch Stimmen dazu sammeln, dass ich sie in einem zukünftigen Proposal einfliessen lassen kann. Ich möchte vorerst nicht den Anspruch auf Vollständigkeit erheben und alles gut durchgekaut wissen, bevor ich da weitere Arbeit investiere ;-) Doch wie denkst Du im Einzelnen zu den Facetten des Konzepts. Wenn Du die Zeit dazu hast, würde ich mich sehr freuen, wenn Du dort noch einmal genauer darauf eingehst. Deine grundsätzliche Sorge teile ich. (s.o.) Gruß, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO EUROPA -schon wieder futsch??
Elchtreiber elchtrei...@gmx.net wrote: Die Karte vom Mittwoch läuft _definitiv_ auf meinem GPSMap 60CSx. Die von gestern hab ich nicht ausprobiert, aber der Prozess ist eigentlich sauber durchgelaufen. Das wundert mich. Bei Bayern ist zum Beispiel keine neue gmappsupp.img.zip vorhanden. Die letzte ist vom 19.7. Da scheint dann doch was abgebrochen, oder? Frag mich nicht warum das so ist. Christophs Makefile ist nicht so sehr übersichtlich. Ich habe gmapsupp_europe.img.zip vom Mittwoch verwendet und das läuft definitiv. Gruss Sven -- Den Rechtsstaat macht aus, dass Unschuldige wieder frei kommen (Wolfgang Schäuble) /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] Abbiegerelation bei Auffahrten
Ich würde gerne einen Permalink schicken, aber das Routing bei Cloudmade funktioniert bei mir heute nicht (Nach dem Setzen von from here und to here erscheint endlos die Meldung Loading). Das Problem mit der Abbiegerelation war aber wohl, dass bei einer no_left_turn-Restriction das to falsch gesetzt war. Ich habe die Relation jetzt korrigiert. Mir erscheint bei einer Auffahrt auf eine Straße die only_straight_on-Restriction (mit from = Auffahrt (link), via = gemeinsamer Knoten und to = Bundesstraße) an sinnvollsten. Denn das Einfädeln ist ja kein Abbiegen nach rechts. Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, steffterra wrote: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mal ganz platt gesagt, wenn auf einer Seite der Strasse ein Spielplatz ist, wird auch niemand auf die Idee kommen, sowas wie playground=right zu taggen. Ebenso waere eine Parkspur im Osten der Strasse nichts, was tatsaechlich irgendetwas mit der Richtung der Strasse zu tun hat - da gibt es eine Parkspur, aber in welcher Richtung der Verkehr auf der Strasse fliesst oder in welcher Richtung die Strasse in OSM eingezeichnet ist, hat mit der Parkspur nichts, aber auch gar nichts zu tun. Es waere also toericht, hier - egal, ob man nun Relationen oder Tags oder sonst was benutzt - in irgendeiner Form einen Bezug zur Richtung der Strasse herzustellen; man erzeugt damit voellig unnoetige Probleme. 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] Abbiegerelation bei Auffahrten
Am 25.07.2010 um 23:02 schrieb Thomas: Ich würde gerne einen Permalink schicken, aber das Routing bei Cloudmade funktioniert bei mir heute nicht (Nach dem Setzen von from here und to here erscheint endlos die Meldung Loading). Das Problem mit der Abbiegerelation war aber wohl, dass bei einer no_left_turn-Restriction das to falsch gesetzt war. Ich habe die Relation jetzt korrigiert. Ich meine, only_right_turn wäre besser, oder? Deine Variante impliziert, dass man nicht nur rechts, sondern auch gerade-aus fahren dürfe, wenn man könne. Aber davon abgesehen: als ich mir die alte Relation in OSM heute mittag angesehen hatte, file mir auf, dass die Abbiegeregelung per Relation dort ja gar nicht nötig ist, da sie schon über Einbahnstraßen ausreichend abgebildet wird. Kann das sein? Mir erscheint bei einer Auffahrt auf eine Straße die only_straight_on-Restriction (mit from = Auffahrt (link), via = gemeinsamer Knoten und to = Bundesstraße) an sinnvollsten. Denn das Einfädeln ist ja kein Abbiegen nach rechts. s.o. Trifft das zu? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Lizenzwechsel ist real und nicht bloss angeblich
Moin Frederik Ramm schrieb: Heiko Jacobs wrote: Hatte schon versucht, das vor paar Tagen auf legal-talk zu diskutieren, ging aber wohl in diesem thread unter: Es gibt eine gewisse Wahrscheinlichkeit, dass diese Dinge alle in den vergangen drei Jahren schon auf legal-talk diskutiert wurden. Dann findet sich hoffentlich jemand, der mich darauf hinweist, nicht umsonst habe ich meinen Verdacht möglichst weit gestreut. In den Kondensaten zum Lizenzwechsel fand ich nix dazu. Da es derzeit nicht unbedingt so ausieht, als hätte sich schon jemand betriebsbereite Verfahren zum Aussortieren nicht relizenierbarer Daten ausgedacht, von einer Abschätzung der möglichen Konsequenzen ganz zu schweigen, halte ich es aber auch für etwas verwegen, einfach davon auszugehen, man hätte auch meine Fragestellung schon abschließend geprüft ... Ich finde die Wahl Deines Betreffs unpassend. Ich habe immerhin ein Fragezeichen drin untergebracht ... Auf deutsch formuliert: Es wird ja immer gesagt, es gäbe keinen Datenverlust, weil der alte Planet.osm ja immer noch unter CC komplett erhalten bleibe. Stimmt. Die nicht relizensierten Daten werden kuenftig nicht mehr in der aktiv von OSMF betriebenen Datenbank gepflegt, aber verschwunden sind sie deswegen nicht. Sie sind dem aktiven Mapping in OSM entzogen. DAS ist für mich DAS relevante. Aber ich gehe mal weiter und behaupte, dass auch der neue planet.osm, von den behauptet wird, er stünde -- leider ein wenig zerfleddert -- nun unter ODBL, dass dieser weiterhin unter CC steht und das einzig und alleine. Nein, denn in Absatz 2 des Contributor Agreements bevollmaechtigst Du die OSMF, mit Deinen Daten alles zu machen, was sie will. In Absatz 3 verpflichtet sich die OSMF ihrerseits, die Daten unter ODbL und (das ist wichtig) DbCL 1.0 for the individual contents of the database zu veroeffentlichen. Ja, sie erhält einen 2/3-Freibrief für Lizenzänderungen. Kann sie gerne haben von mir. Bloß um die Lizenz hin- und herzuändern, muss das AUCH die Lizenz hergeben und das tut CC m.E. nicht wie ausgeführt. Damit ist diese Klausel relativ wertlos, wenn meine Vermutung stimmt, und sollte, wenn die vermutung stimmt, nochmal überdacht werden, denn jedes Wiederlizenzieren mit CC stößt das Problem ja vermutlich wieder an. Von dieser DbCL - Database Content License - spricht normal niemand, sie ist nur eine Formsache, und bedeutet praktisch so viel wie dass an den Einzeldaten als solchen keine Lizenz haengt. Auxh das funktioniert erst, wenn die Daten korrekt CC hinter sich gelassen haben, was m.E. so wie angedacht (oder auch anders) nicht geht. Die jetzige CC ist da relevant: Nein, nachdem Du das Contributor Agreement unterzeichnet hast, ist die jetzige CC nicht mehr relevant, denn Du hast Deine Daten relizensiert. Dito. Es ist voellig zulaessig, dass Du irgendjemandem Daten unter einer Lizenz A gibst und, sofern Du der Rechteinhaber bist, ihm spaeter zusaetzlich die Nutzung unter einer anderen Lizenz gestattest; auch ohne ihm die Daten dann erneut zuzuschicken. DAS bezweifle ich eben. Ich lese aus der CC nur raus, dass der Urheber SEINE Arbeit jederzeit von sich ausgehend unter neuer Lizenz zu verteilen. Und ich lese aus der CC raus, dass einmal unter CC stehende Datenkopien für immer unter CC stehen und jede Kopie DAVON ebenfalls CC sein muss. Für Deine Behauptung fehlt mir der Beleg in der CC. Da sehe ich nur, dass der Zweckoptimsmus und Wunsch vorhanden ist, es wäre so ... Beim Urheberrecht - und auf diesem beruht die CC-BY-SA - geht es nicht um Physik. Es geht um das Werk als (ideelle) Schoepfung, nicht um einen konkreten Fotoabzug oder um die konkreten Bits und Bytes auf der Platte eines Servers in England. Eben, es geht um das geschaffene Werk. Wenn ich als Bildhauer ein Unikat erschaffe und unter CC veräußer, dann ist es futsch und der neue Eigentümer hat auf ewig, das Recht, es als CC zu nutzen, und die Pflicht, es ggfs. unter CC weiterzugeben. Da kann laut CC der Urheber nix mehr dran ändern. Nur wenn er zwei identische Skulpturen schuf, hat er die Chance, die Nr. 2 später unter anderer Lizenz in die Welt rauszulassen. Bei OSM ist das Werk bspw. der GPS-Track zusammen mit Notizen, worum es sich dabei handelt, und der Idee, wie das in tags und nodes umzusetzen ist. Schon beim eintragen in OSM wird es in die existierenden Daten eingepasst und verschmilzt mit den alten Daten zu einer Einheit und jeder Mapper, der nachfolgend an den Daten was ändert, rückt es ein Stück weiter vom ursprünglichen Werk ab. Nur über das unveränderte Original hat aber der Autor ein Verfügungsrecht, es ein zweites Mal zu relizenzieren. EInmal in OSM drin, geht es eine Symbiose mit anderen Daten ein, die nicht mehr auflösbar ist, wie die ganze Diskussion über den Umgang mit Daten nicht mehr erreichbarer Mapper zeigt. Es liegt bisher kein belastbarer Weg vor, wie das gehen soll. Vielmehr entsteht das angebliche ODBL-OSM rein praktisch betrachtet als Auszug aus dem
Re: [Talk-de] Abbiegerelation bei Auffahrten
Hallo zusammen, Das Relations-Problem ist ja inzwischen gelöst.. :) http://www.openstreetmap.org/browse/relation/530958 Was mich mehr interessiert ist die Stelle etwas nordöstlich davon: http://www.openstreetmap.org/?lat=50.3743lon=7.69686zoom=17layers=M Eine Strasse, die erst mehrere Meter *nach* der Auffahrt bzw. *vor* der Ausfahrt den Typ wechselt? Laut 'note' ist das Zwischenstück keine Schnellstrasse, aber dann müssten doch die Auf-/Ausfahrt im Norden sowie die Ausfahrt im Süden auch Primary sein? So jedenfalls scheint mir das Tagging unlogisch.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, steffterra wrote: 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. Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. Was ich nicht so recht verstehe, ist: Wieso meinst Du, dass eine neue Art von Objekt erforderlich ist? Die Editoren muessen eh angepasst werden, um Dein Konzept zu verstehen, also koennte man sie auch derart anpassen, dass statt Deiner neuartigen Way-Gruppierung eine ganz gewoehnliche Relation eingesetzt werden kann - in einer fuer den Benutzer nicht unterscheidbaren Art und Weise. Die Latte fuer neuen Objekttyp in der zentralen Datenbank einfuehren haengt wesentlich hoeher als die fuer neue Art von Relationsnutzung erfinden und Editor-Support dafuer entwickeln. Fuer das erstgenannte musst Du wesentlich mehr Leute davon ueberzeugen, dass das, was Du vorhast, gut ist. Das wiederum fuehrt zu meiner einleitenden Anmerkung zurueck - solange 99% der Leute im Projekt das Problem, das Du loesen moechtest, noch gar nicht selber hatten, werden sie vermutlich mit einem gewissen Unverstaendnis reagieren. Vielleicht ist das in 2-3 Jahren anders. Ich sehe auch noch eine gewisse Schwaeche bei der Frage, wie man Ways aufsplittet und verbindet - da muessen ja dann alle Teil-Ways immer mitgesplittet werden, aber wo? Die Bearbeitung von Kreuzungen stelle ich mir sehr schwierig vor, aber vielleicht ist das nur eine Frage des Benutzerinterfaces. Ausserdem muss man natuerlich immer damit rechnen, dass es Software und Benutzer gibt, die das ganze nicht verstehen. Wir haben in OSM keine Software-Zertifizierungsstelle, die entscheidet, welche Software auf unsere Daten losgelassen werden darf und welche nicht (und mit Benutzern ist es ebenso). Leute werden den Datenway aufsplitten und die Spur-Ways unveraendert lassen, oder umgekehrt; Leute werden einen Name-Tag an einen Spur-Way anfuegen, sie werden Kreuzungen zwischen Objekten einbauen, die sich nicht kreuzen sollten, undsoweiter. Es ist extrem unwahrscheinlich, dass die API so geaendert wuerde, dass sie solche logisch ungueltigen Edits zurueckweist. Ich frage mich, ob unter solchen Bedingungen nicht manchmal mehr Redundanz besser ist; dann hat man wenigstens eine Chance, rauszufinden, wenn irgendwas nicht passt. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: Hallo, steffterra wrote: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mal ganz platt gesagt, wenn auf einer Seite der Strasse ein Spielplatz ist, wird auch niemand auf die Idee kommen, sowas wie playground=right zu taggen. ein Spielplatz ist auch von der Strasse total unabhaengig. Ebenso waere eine Parkspur im Osten der Strasse nichts, was tatsaechlich irgendetwas mit der Richtung der Strasse zu tun hat - da gibt es eine Parkspur, aber in welcher Richtung der Verkehr auf der Strasse fliesst oder in welcher Richtung die Strasse in OSM eingezeichnet ist, hat mit der Parkspur nichts, aber auch gar nichts zu tun. richtig, die Fahrtrichtung hat nichts mit der Parkspur zu tun. Doch die Parkspur ist ein Attribut eines Teils der Strasse (wenn man mal so ein Modell vorraussetzt), und damit muss irgendwie bezeichnet werden, auf welcher Seite sie sich befindet. Dafuer braucht man nunmal irgendeine Art der Richtungsangabe. Nur sehe ich die hierfuer notwendige Richtung als total abstrakt an, z.B. angelegt wie die Strasse gezeichnet wurde. Danach hat diese Richtung den User nicht mehr zu interessieren, sie braucht auch gar nicht mehr angezeigt werden. Benoetigt wird sie nur, damit der Editor bzw. die entsprechende Software die Attribute zuordnen und entsprechend auswerten kann. Deshalb gibt es auch keinen Grund, diese Richtung irgendwann zu aendern. Es waere also toericht, hier - egal, ob man nun Relationen oder Tags oder sonst was benutzt - in irgendeiner Form einen Bezug zur Richtung der Strasse herzustellen; man erzeugt damit voellig unnoetige Probleme. Bye Frederik 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 25 Juli 2010, 23:39:29 schrieb Frederik Ramm: Hallo, steffterra wrote: 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. Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. sorry, wenn ich dir da widersprechen muss. Wenn ich mir anschaue, was heutzutage schon mit Relationen veranstaltet wird, dann ist die Komplexitaet fuer viele bereits zu hoch. Was her muss (ganz egal welches Modell darunterliegt) ist eine Abstraktion der Userebene. Als Anwender (der der gemeine Mapper ebenso ist) will ich mich nicht mit Tags und Relationen rumschlagen muessen. Die Presets sind hier ein guter Anfang, aber das muss noch viel weiter gehen... Was ich nicht so recht verstehe, ist: Wieso meinst Du, dass eine neue Art von Objekt erforderlich ist? Die Editoren muessen eh angepasst werden, um Dein Konzept zu verstehen, also koennte man sie auch derart anpassen, dass statt Deiner neuartigen Way-Gruppierung eine ganz gewoehnliche Relation eingesetzt werden kann - in einer fuer den Benutzer nicht unterscheidbaren Art und Weise. +1 ob jetzt darunter neue Objekte liegen oder nicht ist relativ egal, hauptsache das ganze ist konsistent und einigermassen klar definiert. 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] Der Lizenzwechsel ist real und nicht bloss angeblich
Hallo, Heiko Jacobs wrote: Es ist voellig zulaessig, dass Du irgendjemandem Daten unter einer Lizenz A gibst und, sofern Du der Rechteinhaber bist, ihm spaeter zusaetzlich die Nutzung unter einer anderen Lizenz gestattest; auch ohne ihm die Daten dann erneut zuzuschicken. DAS bezweifle ich eben. Ich lese aus der CC nur raus, dass der Urheber SEINE Arbeit jederzeit von sich ausgehend unter neuer Lizenz zu verteilen. Was in der CC steht, ist absolut irrelevant. Nach dem Urheberrecht kannst Du die Rechte an Deinem Werk niemals veraeussern, Du kannst anderen nur eine Nutzung gestatten. Dadurch, dass Deine Daten in eine CC-BY-SA-lizensierte Datenbank einfliessen, aendert sich nichts an Deinem Recht, diese Daten jederzeit unter einer anderen Lizenz zu veroeffentlichen, und zwar unabhaengig vom physischen Kanal. Das ist eine Tatsache, die unabhaengig von der Lizenz ist, und daher wirst Du in der Lizenz auch nichts dazu finden. Auf der englischen Liste habe ich das Beispiel von dual lizensierter GPL-Software gebracht. Da gibt es eine Webseite mit einem Download-Link fuer Software. Darunter steht: Nutzung entweder unter GPL oder unter einer kommerziellen Lizenz, die Sie von uns fuer X Euro kaufen koennen. Wenn Du vom Anbieter nun die Lizenz kaufst, erhaeltst Du das Recht, die runtergeladene Software ausserhalb der GPL zu benutzen. Deswegen gibt es aber nicht einen Extra-Downloadlink (fuer GPL klicken Sie hier, fuer nicht-GPL klicken Sie hier). Du kannst auch die Software erst unter GPL runterladen und spaeter noch die Lizenz kaufen. Wenn ich als Bildhauer ein Unikat erschaffe und unter CC veräußer, dann ist es futsch und der neue Eigentümer hat auf ewig, das Recht, es als CC zu nutzen, und die Pflicht, es ggfs. unter CC weiterzugeben. Da kann laut CC der Urheber nix mehr dran ändern. Er kann die Rechte des neuen Eigentuemers nicht nachtraeglich reduzieren, aber er kann selbstverstaendlich dem neuen Eigentuemer einen Brief schreiben, in dem steht: Zusaetzlich zu den bereits erteilten Nutzungsrechten erlaube ich Ihnen kuenftig ausserdem, Abguesse meiner Skulptur zu erstellen und unter einer beliebigen Lizenz zu verkaufen. Selbstverstaendlich muss der Bildhauer dafuer *nicht* erst nochmal ein identisches Werk schaffen und dem Kaeufer zuschicken. Das Beispiel hinkt zwar, weil es hier doch wieder um ein physisches, nicht beliebig kopierbares Objekt geht, aber trotzdem ist offensichtlich, dass Du da einem Irrtum aufsitzt. - Nimm ein beliebiges Buch aus Deinem Regal, darin steht sowas wie: Jede Art von Vervielfaeltigung bedarf der ausdruecklichen Genehmigung des Verlags. Das heisst: So, wie das Buch da bei Dir steht, naemlich ohne Genehmigung, ist die Vervielfaeltigung verboten; die Dir erteilte Nutzungslizenz deckt das nicht ab. Wenn Du nun aber vom Verlag eine Genehmigung einholst, erhaeltst Du damit ein erweitertes Nutzungsrecht - OHNE dass der Verlag Dir dazu das Buch erneut zuschickt. Und: Dies ist sogar dann zutreffend, wenn in dem Buch ueberhaupt nichts zu dieser Frage drinsteht. Nur über das unveränderte Original hat aber der Autor ein Verfügungsrecht, Es geht hier, und das habe ich in meiner vorherigen Mail schon geschrieben, nicht um physikalische Objekte. Wer irgendwas wie oft kopiert und wieviele Kopien von irgendwas zu einem bestimmten Zeitpunkt im Umlauf sind und auf welchem Wege die in Umlauf gekommen sind, hat rein gar nichts damit zu tun, wem das geistige Eigentum an all diesen Kopien zusteht. Einmal in OSM drin, geht es eine Symbiose mit anderen Daten ein, die nicht mehr auflösbar ist Selbstverstaendlich. Ich kann heute noch ganz exakt herausfinden, worin genau Dein Beitrag zu OSM bestanden hat, was genau Du wann hochgeladen hast. Und nur genau das kannst Du auch relizensieren, das ist klar. Ich sehe da keine Spitzfindigkeit, weil es genau so ablaufen wird. Basis für ein als ODBL-OSM deklariertes OSM ist auf jeden Fall ein CC-OSM. Damit ist es CC-infiziert nach CC-Lizenz. Nein, weil es nicht auf den physikalischen Weg ankommt. Lizenzbeschraenkungen koennen unabhaengig vom physikalischen Weg aufgehoben werden. Ein anderes Beispiel: Angenommen, ich schreibe ein Buch und lizensiere es CC-BY-SA und Du stellst Dir ein Exemplar in den Schrank. 70 Jahre nach meinem Tod wird das Urheberrecht daran erloeschen, und in dem Moment wird auch die Kopie, die sich dann im Buecherschrank Deiner Enkel befindet, frei von jeder Lizenzbeschraenkung - die CC-BY-SA gilt nicht mehr, auch ohne dass Deine Enkel das Buch neu erwerben muessen. Eben nicht, weil er nur sein eigenes Werk relizenzieren kann, nicht eins, was schon mit einer CC-Lizenz seinen EInwirkungsbereich verlassen hat. Vielleicht verwechselst Du einfach die Richtung. Natuerlich kann ich irgenwas, was ich einmal unter CC rausgegeben habe, nicht im Nachhinein zurueckholen und die Nutzung einschraenken. Umgekehrt aber - zusaetzliche Nutzungen zulassen - ist das kein Problem.
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 25.07.2010 um 23:39 schrieb Frederik Ramm: Hallo, steffterra wrote: 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. Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. Was ich nicht so recht verstehe, ist: Wieso meinst Du, dass eine neue Art von Objekt erforderlich ist? Die Editoren muessen eh angepasst werden, um Dein Konzept zu verstehen, also koennte man sie auch derart anpassen, dass statt Deiner neuartigen Way-Gruppierung eine ganz gewoehnliche Relation eingesetzt werden kann - in einer fuer den Benutzer nicht unterscheidbaren Art und Weise. Ich glaube zu verstehen, was Du meinst. Die Gruppierung in einer ID wäre wesentlich flexibler als vom User manuell zu setzende Relationen. Ich denke auch, dass Relationen ein guten Mittel für verschiedene Zwecke sein kann. Aber hier Relationen einzusetzen wäre overkill. Zumal auch mehr kb anfallen würden, als wenn jeder way, der zu einer Gruppe gehört die gleiche Gruppen-ID hätte. Es wäre schon deshalb felxibler, weil das im Hintergrund passieren könnte, also ohne dass sich der User darum kümmern muss, ausser die ways zu markieren und dann im Menü Gruppieren zu klicken. Dann schaltet JOSM die gemeinsame Hintergrundfarbe für diese Gruppe und es ist auch von der Wahrnehmung her zu einer Straße geworden. Im Hintergrund hat JOSM die ID vergeben und FRenderer können diese nutzen, um die ways entsprechend darzustellen. Die Latte fuer neuen Objekttyp in der zentralen Datenbank einfuehren haengt wesentlich hoeher als die fuer neue Art von Relationsnutzung erfinden und Editor-Support dafuer entwickeln. Fuer das erstgenannte musst Du wesentlich mehr Leute davon ueberzeugen, dass das, was Du vorhast, gut ist. Das wiederum fuehrt zu meiner einleitenden Anmerkung zurueck - solange 99% der Leute im Projekt das Problem, das Du loesen moechtest, noch gar nicht selber hatten, werden sie vermutlich mit einem gewissen Unverstaendnis reagieren. Vielleicht ist das in 2-3 Jahren anders. das Problem mit foreward/backward besteht jetzt bereits. Dort wo kein Bedarf besteht, dass dies eingesetzt würde, muss man ja nicht gruppieren. Das ist ja der Vorteil des Konzepts. Es ist abwärtskompatibel, weil eben nciht alles darauf umgestellt werden muss. Man kann es nur dort einsetzen, wo es das taggen vereinfacht oder Fahrspurtagging sinnvoll wäre. Ich sehe auch noch eine gewisse Schwaeche bei der Frage, wie man Ways aufsplittet und verbindet - da muessen ja dann alle Teil-Ways immer mitgesplittet werden, aber wo? Die Tags müssten natürlich genauso kopiert werden, wie bisher auch, alles die gleichen Regeln. Das Teilen/Splitten selbst kann durch mehrfachmarlkieren aller Nodes auf allen an der Gruppe beteiligten ways geschehen. So viele sind das ja meist nicht. Denn 8-spuriges Autobahntaggen ist ja nicht nötig ;-) Es kann ja auch jeder way einer Gruppe nach wie vor mit lanes=4 getaggt werden. Kein Problem. Das ist ja das schöne an der Felxibilität. Also einfach alle drei ways (beide Fahrrichtungsways und der datenway) mit nodes versehen, an denen man die Straße aufteilen möchte und den Befehl anwenden. Es sollte aber aus Sicherheitsgründen eine Nachfrage kommen, falls man einen node auf einem way nicht mitmarkiert hat. Könnte aber auch noch nachgeholt werden, falls man den way doch nicht abzweigen lassen möchte - z.B. als abzweigende Fahrspur. Die Bearbeitung von Kreuzungen stelle ich mir sehr schwierig vor, aber vielleicht ist das nur eine Frage des Benutzerinterfaces. Kreuzung werden sogar einfacher, das man nur die Schnittstellen mit gemeinsamen Nodes versieht, wo tatsächlich eine Kreuzung vorhanden ist. Abbiegespuren, die z.B. gar nicht kreuzen sidn so noch einfacher umzusetzen. Ansonsten gilt für jeden Richtugnsway/Abbiegespur die ganz normalen Abbiege-Relationen. Es bleiben ja ways mit nodes, auf diese man die Relationen anwenden kann. Absolut abwärtskompatibel. Ausserdem muss man natuerlich immer damit rechnen, dass es Software und Benutzer gibt, die das ganze nicht verstehen. Dazu könnte man eine sehr schöne Anleitung/HOWTO schreiben mit Bildbeispielen, wie ich sie mir auch für das Proposal vorstelle und für absolut nötig halte. In der heutigen Zeit könnte man auch einen Screencast erstellen, der erklärt, wie es funktioniert. Wir haben in OSM keine Software-Zertifizierungsstelle, die entscheidet, welche Software auf unsere Daten losgelassen werden darf und welche nicht (und mit Benutzern ist es ebenso). Leute werden den Datenway aufsplitten und die Spur-Ways unveraendert lassen,
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 25.07.2010 um 23:47 schrieb Guenther Meyer: Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: Hallo, steffterra wrote: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mal ganz platt gesagt, wenn auf einer Seite der Strasse ein Spielplatz ist, wird auch niemand auf die Idee kommen, sowas wie playground=right zu taggen. ein Spielplatz ist auch von der Strasse total unabhaengig. +1 Die Lage ergibt sich aus den Koordinaten, diese zusätzliche Angabe komplett unnötig. Ebenso waere eine Parkspur im Osten der Strasse nichts, was tatsaechlich irgendetwas mit der Richtung der Strasse zu tun hat - da gibt es eine Parkspur, aber in welcher Richtung der Verkehr auf der Strasse fliesst oder in welcher Richtung die Strasse in OSM eingezeichnet ist, hat mit der Parkspur nichts, aber auch gar nichts zu tun. richtig, die Fahrtrichtung hat nichts mit der Parkspur zu tun. - sondern mit der Seite auf der sie vorhanden ist. Und das gilt es ja anzugeben (bisher mit forward/backward/right) Doch die Parkspur ist ein Attribut eines Teils der Strasse (wenn man mal so ein Modell vorraussetzt), und damit muss irgendwie bezeichnet werden, auf welcher Seite sie sich befindet. +1 Die Fahrspur könnte z.b. nur in einer Fahrtrichtung vorhanden sein. Doch auf welcher? Das tagt man halt auf dem way der Richtugnsfahrspur, zwischen den nodes wo er vorhanden ist: parking:lane capacity:disabled:2 Dafuer braucht man nunmal irgendeine Art der Richtungsangabe. Nur sehe ich die hierfuer notwendige Richtung als total abstrakt an, z.B. angelegt wie die Strasse gezeichnet wurde. Die Richtung wohin die Fahrspur führt, ist tatsächlich egal für die Parkpsur. Doch man legt am way der Seite der Straße den tag an, wo die Parkspur tatsächlich vorhanden ist. Danach hat diese Richtung den User nicht mehr zu interessieren, sie braucht auch gar nicht mehr angezeigt werden. Benoetigt wird sie nur, damit der Editor bzw. die entsprechende Software die Attribute zuordnen und entsprechend auswerten kann. Deshalb gibt es auch keinen Grund, diese Richtung irgendwann zu aendern. Mit der Einführung der Gruppierung sind sie bis auf oneway obsolet fürs tagging. Da man dort hin-taggen kann, wo es ist: an dem way der Straßenseite, wo es in Wirklichkeit vorhanden ist. Es waere also toericht, hier - egal, ob man nun Relationen oder Tags oder sonst was benutzt - in irgendeiner Form einen Bezug zur Richtung der Strasse herzustellen; man erzeugt damit voellig unnoetige Probleme. Genau diese Probleme will die Gruppierung ja verhindern, weil so genau festgelegt wird, an welchem way, also auf welcher Straßenseite welche Dinge vorhanden sind. Wie z.b. Radweg, usw. (Das ist übrigens der Unterschied zum wesentlich komplizierter zu zeichnenden Linienbündel, da wir ausreichend tags haben, um alle Arten von Radwegen, Parkständen, etc. am way zu taggen. Das einzige Problem hierbei ist aber durch die Gruppierung nicht mehr vorhanden und damit das Ziel derer errreicht: die richtugnsabhängigen Unterschiede liegen nun auf den einzelnen ways der Straßenseite, wo in Wirklichkeit vorhanden sind. Danke fürs Feedback, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Segelfluggellände
Am 19.05.2010 09:57, schrieb Friedhelm Schmidt: Am 19.05.2010 09:19, schrieb Friedhelm Schmidt: Am 19.05.2010 02:00, schrieb Ulf Möller: access=glider wäre denkbar, aber ein eigenes Tag für Segelfluggelände wäre wohl besser... +1 Als Tag würde ich aeroway = glider_airfield für das Gelände und aeroway = airstrip für das Start/Landefeld vorschlagen. Dann kann man sich noch Gedanken über die Startarten (Windenstart, F-Schlepp, ...) machen. Eine Landebahn ist eine Landebahn - aeroway=runway. Deren Oberflächenbeschaffenheit, Nutzungsart etc. sind hinreichend mit Zusatztags erfassbar. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Lizenzwechsel ist real und nicht bloss angeblich
Hallo, am 26.07.2010 00:23 schrieb Frederik Ramm: Nach dem Urheberrecht kannst Du die Rechte an Deinem Werk niemals veraeussern, Du kannst anderen nur eine Nutzung gestatten. Dadurch, dass Deine Daten in eine CC-BY-SA-lizensierte Datenbank einfliessen, aendert sich nichts an Deinem Recht, diese Daten jederzeit unter einer anderen Lizenz zu veroeffentlichen, und zwar unabhaengig vom physischen Kanal. Das kann in den falschen Hals kommen. Die Möglichkeit diese Daten jederzeit unter einer anderen Lizenz zu veroeffentlichen haben OSM-Autoren nur, weil sie per CC-BY-SA nur ein einfaches, kein ausschließliches Nutzungsrecht einräumen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Frederik Ramm frede...@remote.org wrote: Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. Bloß ist das Vorausdenken etwas schwierig, wenn einem das notwendige gemeinsam nutzbare Reißbrett dazu fehlt. Textwüsten sind nicht immer hilfreich, wenn es hier um ein Projekt geht, dass seine Produkte im Wesentlichen grafisch editiert und darstellt. Daher würde ich mich freuen, wenn jemand meinen Vorschlag für das Online-Werkzeug Miniplanet http://wiki.openstreetmap.org/wiki/User:Tirkon/Miniplanet umsetzen könnte. Ich bin mir relativ sicher, dass das Werkzeug nach einiger Zeit des Bekanntwerdens zunehmend genutzt wird. Insbesondere denke ich, dass da bald viele Tüftler am Werk sein werden, die den von Dir genannten Punkt schon überschritten haben und neue Konzepte ausprobieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Segelfluggellände
Am 26.07.2010 01:02, schrieb Garry: Eine Landebahn ist eine Landebahn - aeroway=runway. Deren Oberflächenbeschaffenheit, Nutzungsart etc. sind hinreichend mit Zusatztags erfassbar. Gibt's auch soetwas wie disused runway, analog zur railway? Ich habe in einem konkreten Fall daraus jetzt eine Betonfläche (highway=track/tracktype=grade1/surface=concrete/area=yes) gemacht. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Frederik Ramm frede...@remote.org wrote: Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mir ist derzeit nicht klar, welche Du damit meinst. Könntest Du da konkrete Beispiele nennen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Lizenzwechsel ist real und nicht bloss angeblich
Hallo, Norbert Kück wrote: Das kann in den falschen Hals kommen. Die Möglichkeit diese Daten jederzeit unter einer anderen Lizenz zu veroeffentlichen haben OSM-Autoren nur, weil sie per CC-BY-SA nur ein einfaches, kein ausschließliches Nutzungsrecht einräumen. Da hast Du recht. Aber ein *ausschliessliches* Nutzungsrecht kann es ja nur in Form einer vertraglichen Vereinbarung zwischen bekannten Parteien geben, und nicht in Form einer Lizenz, die sich an jeden, der kommt richtet, oder? Bei einer Verletzung der Ausschliesslichkeit wuerde ja denen, denen Ausschliesslichkeit zugesichert wurde, ein Schaden entstehen. Aber wenn ich mich jetzt hinstellte und meine Daten unter einer hypothetischen CC-BY-SA-exclusive in die Welt schickte, wer waere dann der Geschaedigte, falls ich spaeter gegen die Exklusivitaet verstiesse? 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] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, Tirkon wrote: Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mir ist derzeit nicht klar, welche Du damit meinst. Könntest Du da konkrete Beispiele nennen? Die folgten doch direkt auf diesen Satz in meiner Mail. Nicht richtungsabhaengig ist fuer mich alles, was separat existiert und bei dem die Position mehr oder minder nur aus Bequemlichkeit im Verhaeltnis zur Strasse angegeben wird. Darunter fallen fuer mich fast alle left/right-Sachen. Wenn ich angeben will, auf welcher Seite einer Strasse sich eine Mauer oder eine Baumreihe oder ein Parkstreifen befindet, dann ist ein left/right dafuer nicht geeignet, genauso wie ich auch zu niemandem sagen wuerde: Auf der linken Seite der Talstrasse ist ein Fahrradweg. Diese Information reicht nicht. Ich muss entweder sagen wenn Du von X nach Y faehrst, ist auf der linken Seite der Talstrasse ein Fahrradweg, oder ich muss sagen auf der Nordseite der Talstrasse ist ein Fahrradweg. Wenn man in OSM genauso verfahren wuerde, statt sich auf das Kunstgebilde der Way-Richtung zu verlassen, gaebe es 95% der Probleme mit backward, forward, left, right nicht. Die sind alle hausgemacht. 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] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Hallo, Tirkon wrote: Bloß ist das Vorausdenken etwas schwierig, wenn einem das notwendige gemeinsam nutzbare Reißbrett dazu fehlt. Textwüsten sind nicht immer hilfreich, wenn es hier um ein Projekt geht, dass seine Produkte im Wesentlichen grafisch editiert und darstellt. Daher würde ich mich freuen, wenn jemand meinen Vorschlag für das Online-Werkzeug Miniplanet http://wiki.openstreetmap.org/wiki/User:Tirkon/Miniplanet umsetzen könnte. Gute Idee, aber sehr viel Arbeit, das alles zu entwickeln und einzurichten - es muessem ja auch Editoren und Renderer dazu passen, dann hast Du das Permission-System, dann willst Du, dass es persistent ist, dann brauchst Du Import/Export-Tools (denn viele werden nicht auf der gruenen Wiese anfangen wollen, sondern eine bestehende Stadt importieren oder so), und was ist, wenn jemand tatsaechlich Aenderungen am API-Code braucht, um seine Sache zu demonstrieren? Ausserdem ist so ein Miniplanet beileibe kein Wundermittel - der Vorschlag, der hier von steffterra als, wie Du sagst, Textwueste unterbreitet wurde, wuerde mit oder ohne Miniplanet Wochen konzentrierter Arbeit brauchen, um ihn zur Demonstrationsreife zu bringen (Aenderungen an Renderern und Editoren!). Jemand, der *das* kann, der kann auch schnell noch eine Rails-API gemaess Wiki-Anleitung aufsetzen, der braucht keinen Miniplanet. Meiner Ansicht nach wuerde ein Miniplanet die Gefahr mit sich bringen, dass Leute ausprobieren, wie bestimmte Sachen im Rendering aussehen, und dann ihre Tagging-Entscheidungen danach richten... 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Am 26.07.2010 um 03:51 schrieb Frederik Ramm frede...@remote.org: Hallo, Tirkon wrote: Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mir ist derzeit nicht klar, welche Du damit meinst. Könntest Du da konkrete Beispiele nennen? Die folgten doch direkt auf diesen Satz in meiner Mail. Nicht richtungsabhaengig ist fuer mich alles, was separat existiert und bei dem die Position mehr oder minder nur aus Bequemlichkeit im Verhaeltnis zur Strasse angegeben wird. Darunter fallen fuer mich fast alle left/right-Sachen. Wenn ich angeben will, auf welcher Seite einer Strasse sich eine Mauer oder eine Baumreihe oder ein Parkstreifen befindet, dann ist ein left/right dafuer nicht geeignet, genauso wie ich auch zu niemandem sagen wuerde: Auf der linken Seite der Talstrasse ist ein Fahrradweg. Diese Information reicht nicht. Ich muss entweder sagen wenn Du von X nach Y faehrst, ist auf der linken Seite der Talstrasse ein Fahrradweg, oder ich muss sagen auf der Nordseite der Talstrasse ist ein Fahrradweg. Wenn man in OSM genauso verfahren wuerde, statt sich auf das Kunstgebilde der Way-Richtung zu verlassen, gaebe es 95% der Probleme mit backward, forward, left, right nicht. Die sind alle hausgemacht. Das ist doch meine Argumentation für dieses Konzept! ;-) Durch die Gruppierung hättest Du das Problem doch gelöst, da darin je ein way für beide Fahrtrichtungen enthalten ist. Beispielsweise könntest so dem nördlichen Way die Info des Radweges mitgeben. Dann ist klar auf welcher Strassenseite dieser verläuft. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Am 26.07.2010 um 01:49 schrieb Tirkon tirko...@yahoo.de: Frederik Ramm frede...@remote.org wrote: Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. Bloß ist das Vorausdenken etwas schwierig, wenn einem das notwendige gemeinsam nutzbare Reißbrett dazu fehlt. Textwüsten sind nicht immer hilfreich, wenn es hier um ein Projekt geht, dass seine Produkte im Wesentlichen grafisch editiert und darstellt. Daher würde ich mich freuen, wenn jemand meinen Vorschlag für das Online-Werkzeug Miniplanet http://wiki.openstreetmap.org/wiki/User:Tirkon/Miniplanet umsetzen könnte. Ich bin mir relativ sicher, dass das Werkzeug nach einiger Zeit des Bekanntwerdens zunehmend genutzt wird. Insbesondere denke ich, dass da bald viele Tüftler am Werk sein werden, die den von Dir genannten Punkt schon überschritten haben und neue Konzepte ausprobieren. Ich werde das Gruppierungskomzept nach dieser Diskussion in einem Proposal durch ausführliche Bebilderung illustrieren, um die Vorstellung zu vereinfachen, von was die Rede ist. Das muss ersteinmal genügen. Kleiner Tip: zeichne doch einfach mal auf einem Blatt Papier auf, wie ich es umsetzen möchte. Dann sieht man es auch schonmal und erkennt auch eigene Verständnisfehler (oder auch einen Denkfehler meinerseits). Nun bitte ich aber nicht weiter darüber zu diskutieren, wie und dass mein Text illustriert werden muss, sondern bitte vor allem über den Inhalt und das Konzept selbst. Wäre super! Danke :-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Lizenzwechsel ist real und nicht bloss angeblich
Am 25.07.2010 23:24, schrieb Heiko Jacobs: Ich verharre dann nicht in einer Starre, sondern bohre weiter, tauche tiefer in das Thema ein, was dann natürlich neue Erkenntnisse Danke. Damit sich die Karre nicht weiter in die falsche Richtung bewegt, sollte man sie erst mal bremsen, blockieren und gegen den falschen Weg protestieren, ja. Manchmal muss man halt etwas ungemütlicher werden, wenn leise Bedenken ignoriert wird. Ich erinnere bei der Gelegenheit daran, dass ich in Forum und talk-de nicht der Starter des Themas war. Dann mache ich mal den Versuch eine Brücke zu bauen. - Was spricht dagegen, bereits heute möglichst viele Mapper zu gewinnen, zusätzlich der neuen Lizenz zuzustimmen? - In der Datenbank wird zu jedem einzelnen Tag ein Lizenzstatus mitgespeichert - nach einer gewissen Zeit (3 Monate, 1 Jahr, 2 Jahre ?) kann man schauen wie stark sich die alte Lizenz auswächst und man kann genau analysieren wie groß der Schaden sein wird. Bevor ein harter Lizenzwechsel erfolgt erwarte ich eine Analyse anhand von Beispielregionen wie groß die Kollateralschaden sein werden. Zudem erwarte ich einen respektvollen Umgang mit dem Werk der Mapper die der neuen Lizenz nicht zustimmen wollen oder können. Ein wir sind eine Dynamische Community, das haben wir schnell wieder raus ist mir deutlich zu wenig. Da stecken Mannjahre an Arbeit drin, die häufig unter Aufopferung erbracht wurden. Das möchte ich nicht mit einem lapidaren Satz abtun um es anschließend aus dem Projekt zu löschen. Erst wenn die Tools zur Analyse und zum Sezieren mindestens in einer alpha-Version vorliegen und sich herausgestellt hat, daß der Schaden wirklich gering ist (weil er sich rausgewachsen hat) kann die harte Lizenzumstellung erfolgen. Dieser Weg sollte so schnell wie möglich eingeschlagen werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Lizenzwechsel ist real und nicht bloss angeblich
Am 26.07.2010 00:23, schrieb Frederik Ramm: Also entweder Heiko Jacobs stimmt dem Lizenzwechsel nicht zu, dann werden seine Daten nie unter der ODbL verbreitet. Oder er stimmt zu, dann koennte, wenn deine Argumentation stimmen wuerde, der urspruengliche Autor (Heiko Jacobs) den fiesen Relizensierer (Heiko Jacobs) verklagen. Da wäre ich mir nicht so sicher. Was passiert mit Nodes deren Historie durch Verbinden verloren geht. Und was passiert wenn ein Mapper Daten löscht und als seine eigenen wieder einfügt? Das von Fredrik beschriebene Verhalten kann angestrebt, aber m. E. nicht vollständig garantiert werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übernahme von Grenzen aus dem Wiki
Am Sonntag 25 Juli 2010, 20:26:54 schrieb Walter Nordmann: und die sind fast immer identisch mit den gemeindegrenzen Nein, das ist nicht fast immer so. Es stimmt oft, aber man darf sich definitiv nicht darauf verlassen. Grade auf dem Land wurden an manchen Stellen einzelne Gehöfte zu anderen PLZ zugewiesen, weil die Post von dort aus viel einfacher hin kommt. Bei unserer Gemeinde gibt es alleine zwei Gehöfte, die unsere PLZ haben aber zur Nachbargemeinde (sogar Nachbarkreis!) gehören. Gruß, Bernd -- Frauen begnügen sich nicht mehr mit der Hälfte des Himmels, sie wollen die Hälfte der Welt. - Alice Schwarzer 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] JOSM V 3376
Am 25.07.10 11:11, schrieb Chris66: Am 25.07.2010 10:54, schrieb Wolfgang Wienke: Auch in dieser JOSM-Version heißem die Busrouten-Line-Relationen im deutschen immer noch Freileitung (Starkstrom). Kann das nicht jemand ändern? Ticket ist ja drin, aber andere scheinen wohl wichtiger zu sein. woher soll JOSM wissen, wann er 'line' mit Stromleitung und wann mit Buslinie übersetzen soll ? Warum das ÖPNV-Schema line=bus und nicht route=bus verwendet entzieht sich meiner Kenntnis. Soweit ich das überblicken kann, wird für Stromleitungen in DE nur route=power benutzt. Da sollte es kein Missverständnis geben. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelte Tags - rausnehmen
Am 25.07.10 11:22, schrieb Jan Tappenbeck: Moin! immer wieder finde ich Objekte die durch ein Node und ein Area beschrieben werden. Beispiel http://www.openstreetmap.org/browse/node/314512234 und http://www.openstreetmap.org/browse/way/28617230 Jetzt stellt sich die Frage - eines davon gnadenlos rausnehmen ? Tendiere dann zum Node ! Aber bitte dann auch richtig schreiben: http://de.wikipedia.org/wiki/Johann_Heinrich_Pestalozzi Da ist der Flächeneintrag klar im Vorteil ;-) Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
