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 Montag 26 Juli 2010, 00:39:36 schrieb steffterra: Am 25.07.2010 um 23:47 schrieb Guenther Meyer: Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: 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. Das erfordert aber wieder dieses Linienchaos, das doch so unuebersichtlich 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. was genau willst du eigentlich? So wie ich das verstehe, willst du, dass jeder Teil (Strasse, Fussweg, Fahrradweg) separat als way eingezeichnet wird, um diese dann irgendwie zusammenzufassen. Ich praeferiere eher den Ansatz, dass eine Strasse prinzipiell nur aus einem way besteht, der die zusaetzlichen Wege - genauso wie die Anzahl der Fahrspuren - als Attribute bekommt. Gemeinsam ist beiden Ansaetzen, dass die komplette Strasse inkl. Zubehoer in einem Objekt vereint wird. 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 Montag 26 Juli 2010, 03:51:55 schrieb Frederik Ramm: 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. eben nicht. Das Problem ist, dass die Richtung je nach Geschmack gedreht wird, egal, ob davon noch andere Dinge abhaengen. Die Richtung sollte ein Hilfsmittel rein zur Beschreibung von richtungsabhaengigen Tags sein, nicht mehr und nicht weniger. Sobald ein Weg erstellt wurde, hat dieser eine Richtung, die so fix bleibt (und wie gesagt, dem User im besten Fall gar nicht erst gezeigt wird). 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] Postleitzahlen-Import
Moin, Frederik Ramm schrieb: Ich wuerde in Deinem Fall nur ein postal_code=... an die Gemeindegrenze setzen. in diesem Zusammenhang noch eine Frage: Ich habe oft den Fall, dass ein PLZ-Gebiet mehrere Gemeinden umfasst, aber ansonsten mit deren Grenzen deckungsgleich ist. Bisher habe ich nur den Gemeindegrenzrelationen den jeweiligen (identischen) postal_code zugewiesen. Gibt es einen Grund, da jetzt zusätzlich noch eine PLZ-Relation des Gesamtumfangs anlegen zu müssen/sollen? Ich denke, alle Informationen sind bereits so enthalten und auswertbar - oder? Gruß Georg ___ 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, Thomas Reincke wrote: - Was spricht dagegen, bereits heute möglichst viele Mapper zu gewinnen, zusätzlich der neuen Lizenz zuzustimmen? Neue Mapper werden bereits gezwungen, zuzustimmen. - In der Datenbank wird zu jedem einzelnen Tag ein Lizenzstatus mitgespeichert Dieses Flag gibt es schon. - 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. Genauso ist es auch geplant. Irgendwann demnaechst - wenn Contributor Terms usw. endgueltig festgeklopft sind, denn danach kann man das nicht mehr aendern - werden alle per Mail gebeten, der Lizenz zuzustimmen. Zu dem Zeitpunkt wird das noch optional sein. Irgendwann spaeter - wie lange spaeter, ist nicht genau festgelegt - wird dann umgeschaltet: Leute, die nicht zugestimmt haben, koennen nicht mehr weiter editieren (um zu verhindern, dass *noch mehr* Daten dazukommen, die spaeter nicht relizensiert werden) - aber die Datenbank ist immer noch CC-BY-SA, nichts wird entfernt. Irgendwann *noch* spaeter erfolgt dann der tatsaechliche Wechsel, bei dem Dinge, die nicht relizensiert werden, entfernt werden. Bevor ein harter Lizenzwechsel erfolgt erwarte ich eine Analyse anhand von Beispielregionen wie groß die Kollateralschaden sein werden. Die OSMF/LWG wird solche Analysen ganz bestimmt machen, um ihre Entscheidung darauf zu gruenden. Ich gehe davon aus, dass man die dann auch in den relevanten Protokollen findet. Eine Abstimmung nach Art von liebe Mapper, so sieht's aus, sollen wir's machen oder nicht? ist derzeit nicht vorgesehen, aber es koennte durchaus sein, dass die LWG (um die Verantwortung loszuwerden) tatsaechlich eine Abstimmung unter aktiven Mappern macht. Verpflichtet ist sie dazu natuerlich nicht. Ich hoffe, dass die OSMF/LWG uns staendig aktuellen Zugang zu diesem Lizenz-Flag gibt, damit wir sehen koennen, wer schon zugestimmt hat und wer nicht, und damit jeder solche Analysen fuer die ihn interessierende Region selber machen kann. Ich hoffe, dass es nicht zu irgendwelchen Datenschutzbedenken kommt (dass irgendwelche Nutzer verlangen, die OSMF solle anderen *nicht* verraten, wie sie zur Lizenz stehen), denn das wuerde solche Analysen torpedieren. 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. Wenn einer der neuen Lizenz nicht zustimmen *will*, dann besteht der Respekt darin, die Daten wie gewuenscht zu loeschen und ihn ziehen zu lassen. Daten, die von Leuten beigetragen wurden, die selbst der neuen Lizenz zustimmen, die aber auf der Arbeit anderer beruhten, sollten soweit es irgend geht gerettet werden, indem man sie von den nicht uebernehmbaren Bestandtteilen trennt und wieder einpflegbar macht. Ansonsten ist eine gewisse Respektlosigkeit aber durchaus normal bei OSM. Schon seit Jahren gibt es den Spruch we have unlimited free labour - wir haben unbegrenzte kostenlose Arbeitskraft. Die wesentliche Arbeit derer, die bisher bei OSM dabei waren, ist, OSM zu einer bekannten Groesse in der Branche zu machen; das ist unabhaengig von den konkret beigetragenen Daten. Die Daten sind, Aufopferung hin oder her, leicht ersetzbar. 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. Ich sehe die OSMF da nicht in der Bringschuld, was solche Tools betrifft. Die Analysen, die wir wollen, muessen wir uns vermutlich schon selber programmieren. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postleitzahlen-Import
Hallo, Georg Feddern wrote: Ich habe oft den Fall, dass ein PLZ-Gebiet mehrere Gemeinden umfasst, aber ansonsten mit deren Grenzen deckungsgleich ist. Bisher habe ich nur den Gemeindegrenzrelationen den jeweiligen (identischen) postal_code zugewiesen. Gibt es einen Grund, da jetzt zusätzlich noch eine PLZ-Relation des Gesamtumfangs anlegen zu müssen/sollen? Ich denke, alle Informationen sind bereits so enthalten und auswertbar - oder? In einer einfach so gezeichneten PLZ-Karte wuerden auf diese Weise natuerlich mehrere umrandete Gebiete entstehen, die alle die gleiche PLZ tragen, anstatt nur ein grosses. Aber das kann der Auswertende ja dann berichtigen, indem er Gebiete mit gleicher PLZ zusammenfasst. Also ich denke, wenn wir erreichen, dass jeder Punkt in Deutschland in genau einer mit postal_code=... getaggten Relation liegt, egal ob das eine Gemeindegrenzenrelation oder eine spezielle PLZ-Relation ist, dann ist das schonmal das wichtigste. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] PLZ-Import, Widersprüche
Hallo, mir sind zwei Widersprüche begegnet, die ich nicht einordnen kann: - 1. - [1] sagt: postal_code, postal_code_level [2] enthält: postcode, postcode_level - 2. [1] sagt: Sollte die Grenze des PLZ-Gebietes identisch sein mit einer bereits vorhandenen Grenze einer Stadt oder Gemeinde, so können die für PLZ-Gebiete relevanten Tags an die Grenzrelation angeheftet werden. Es ist hier nicht zwingend notwendig, eine eigene separate PLZ-Relation zu erstellen. Diese Relationen sollen existierende Grenz-Ways mitbenutzen, wo sie gemeinsam verlaufen [3] sagt: Postleitzahlen sollten nicht mit in die Gemeinderelationen genommen werden. Zwar überdeckt sich in ländlichen Gebieten die Gemeindegrenze sehr häufig mit der PLZ-Grenze, in manchen Gebieten (besonders in Städten) ist dies jedoch nicht der Fall. Um hier ein einheitliches System zu gewährleisten, wird stattdessen empfohlen, eigene Postleitzahlrelationen Relation:postal_code zu verwenden. Natürlich können diese die Ways des Grenznetzes mitverwenden. -- Gruß nk [1] http://wiki.openstreetmap.org/wiki/Import/Catalogue/Postleitzahlen_Deutschland_2010 [2] http://download.geofabrik.de/plz/ [3] http://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze ___ 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 02:42 schrieb Frederik Ramm: 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? Korrekt! Mein Zwischenruf war allein auf die m.E. zu allgemeine Formulierung der Unveräußerlichkeit der Urheberrechte gerichtet. CC-BY-SA beinhaltet eindeutig einfaches Recht. Häufigster Fall von ausschließlichem Recht sind Verträge zwischen Autor und Verlag, wobei auch dort z.T. nur einfache Nutzungsrechte eingeräumt werden. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Hallo, Norbert Kück wrote: mir sind zwei Widersprüche begegnet, die ich nicht einordnen kann: - 1. - [1] sagt: postal_code, postal_code_level [2] enthält: postcode, postcode_level Da ist [2] falsch, ich repariere das. [1] sagt: Sollte die Grenze des PLZ-Gebietes identisch sein mit einer bereits vorhandenen Grenze einer Stadt oder Gemeinde, so können die für PLZ-Gebiete relevanten Tags an die Grenzrelation angeheftet werden. Es ist hier nicht zwingend notwendig, eine eigene separate PLZ-Relation zu erstellen. Diese Relationen sollen existierende Grenz-Ways mitbenutzen, wo sie gemeinsam verlaufen [3] sagt: Postleitzahlen sollten nicht mit in die Gemeinderelationen genommen werden. Zwar überdeckt sich in ländlichen Gebieten die Gemeindegrenze sehr häufig mit der PLZ-Grenze, in manchen Gebieten (besonders in Städten) ist dies jedoch nicht der Fall. Um hier ein einheitliches System zu gewährleisten, wird stattdessen empfohlen, eigene Postleitzahlrelationen Relation:postal_code zu verwenden. Natürlich können diese die Ways des Grenznetzes mitverwenden. Ich denke, da werde ich [3] mal etwas abschwaechen. Grundsaetzlich ist es natuerlich schoen, wenn wir fuer jede PLZ eine PLZ-Relation haben, aber der Mehraufwand fuer derlei Kosmetik in Gebieten, bei denen beide Grenzen identisch sind, rechtfertigt das m.E. nicht. Danke fuer die Hinweise. Bye Frederik ___ 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 Thomas und alle, die ebenfalls Schaden an der Community vermeiden wollen, bereits heute möglichst viele Mapper zu gewinnen, zusätzlich der neuen Lizenz zuzustimmen zu jedem einzelnen Tag ein Lizenzstatus mitspeichern Analyse anhand von Beispielregionen wie groß die Kollateralschaden sein werden. respektvollen Umgang mit dem Werk der Mapper die der neuen Lizenz nicht zustimmen wollen oder können. 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. +1 Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Frederik Ramm schrieb: Grundsaetzlich ist es natuerlich schoen, wenn wir fuer jede PLZ eine PLZ-Relation haben, aber der Mehraufwand fuer derlei Kosmetik in Gebieten, bei denen beide Grenzen identisch sind, rechtfertigt das m.E. nicht. Man muss dann nur bei Änderungen der Gemeindegrenzen (Eingemeindung, Grundstückstausch, etc.) auch auf die PLZ achten, die sich ja dadurch nicht zwangsläufig ebenso ändern muss, oder? Sobald die Gemeindegrenze nicht mehr 1:1 mit dem PLZ-Gebiet übereinstimmt muss dann trotzdem eine eigene PLZ-Relation erstellt werden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Übernahme von Grenzen aus dem Wiki
kennst du die bedeutung des worte fast ? walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/Ubernahme-von-Grenzen-aus-dem-Wiki-tp5334800p5336977.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] Der Lizenzwechsel ist real und nicht bloss angeblich
Hallo Frederik, Neue Mapper werden bereits gezwungen, zuzustimmen. Besser fände ich, wenn bei Neuanmeldung auch PD angeboten wird. - In der Datenbank wird zu jedem einzelnen Tag ein Lizenzstatus mitgespeichert Dieses Flag gibt es schon. Besser fände ich, wenn für jeden Edit auch PD angeboten, und die Etscheidung des OSMers dann eingetragen wird. Eine Abstimmung nach Art von liebe Mapper, so sieht's aus, sollen wir's machen oder nicht? ist derzeit nicht vorgesehen Wäre aber höchst sinnvoll! (um nicht die Katze im Sack kaufen zu müssen) Wenn einer der neuen Lizenz nicht zustimmen *will*, dann besteht der Respekt darin, die Daten wie gewuenscht zu loeschen und ihn ziehen zu lassen. Das wäre nicht respektvoll. Partnerschaftlichkeit und Konsens wären m.E. das Ziel. Das bedingt aber umfassende und verständliche Information über die Auswirkungen (was wiederum eine Analyse der Szenarien voraussetzt). Ich sehe die OSMF da nicht in der Bringschuld, was solche Tools betrifft. Die Analysen, die wir wollen, muessen wir uns vermutlich schon selber programmieren. Entscheidung über Lizenz und Entwicklung von Analysen und Tools gehören zusammen. Wenn man/wir das eine will, muss man/wir das andere leisten. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelte Tags - rausnehmen
Florian Lohoff-2 wrote: Das Gebaeude ist teilweise riesen gross und der Hvt nur in einem Fluegel mit seperatem Eingang und hat teilweise auch eine andere Adresse ... hi, kann man in diesem fall nicht einfach einen entrance am building erstellen? nach der devise: hier geht's zum xxx. mach ich jedenfalls bei manchen shops so; die sind zwar alle im gleichen haus, haben aber fast immer ne eigene tür. eventuell auch mit anderer adresse addr:* gruss walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/Doppelte-Tags-rausnehmen-tp5334614p5337005.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] Postleitzahlen-Import
moin, wenn die teilstücke des plz-gebietes schon SAUBER vorhanden sind, würde ich EINE neue relation des gesamtgebietes zusammenstellen - sind doch nur ein paar klicks und dauert ne minute. wenn die grenzen noch unsauber sind, bräuchte man eigentlich nur die aussenkontur zurechtzubiegen; (wie's drinnen aussieht ...) - spart auch zeit. bei der ganz einfachen lösung lass es so, ist der renderer gefragt. gruss walter, der relativ sauer ist, weil sein kaputter logger ihm zwei tage feldarbeit versaut hat ;( p.s. ich tendiere zu verfahren 2. - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/Postleitzahlen-Import-tp5308160p5337050.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] Behindertenparkplatz-Die Lösung
Moin, steffterra schrieb: Und wie wird die dann in die Area gezeichnet? dafür gäbe es zwei Möglichkeiten: Entweder als Site-Relation - alle Stellplatz-Nutzer-Arten-Flächen getrennt und die Relation ergibt 'den Parkplatz'. Oder dito als Multipolygon-Relation. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Stefan Dettenhofer (StefanDausR) wrote: Man muss dann nur bei Änderungen der Gemeindegrenzen (Eingemeindung, Grundstückstausch, etc.) auch auf die PLZ achten, die sich ja dadurch nicht zwangsläufig ebenso ändern muss, oder? Sobald die Gemeindegrenze nicht mehr 1:1 mit dem PLZ-Gebiet übereinstimmt muss dann trotzdem eine eigene PLZ-Relation erstellt werden. hi stefan: das ist wie bei radio eriwan im prinzip richtig, aber... ich sehe das hier - für mich! - nicht so eng. man soillte sich immer wieder bei osm fragen, für WEN (zielgruppe) wir sachen eintragen. wenn da irgend eine hundehütte am stadtrand auf einmal umzieht, werden die immer noch ihre post bekommen, da der briefträger wohl der letzte ist, der sich da nicht auskennt. eventuell dauert es einen tag länger, wenn die hütte auf einmal zu einem anderen verteilzentrum gehört - computer können ja nicht denken. die post ist hier definitiv nicht unsere zielgruppe. genausowenig rettungspunkte für notfallhelfer oder hydranten für die feuerwehr. die haben - zumindest theoretisch - eigene daten. gruss walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-Widerspruche-tp5336892p5337093.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] Karten für NaviPOWM auf dem Dev-Server
Hallo zusammen, ich habe am Devserver wieder neue NaviPOWM-Karten aus dem kompletten planetfile erstellt! NEU: Es werden die MAP-Dateien nur noch aus dem planetfile generiert. Dafür gibt es jetzt extra Verzeichnisse für ALLE Länder der Welt mit den entsprechend verlinkten Daten! Die bisherigen Verzeichnisse für die Kontinente (und D-A-CH) existieren weiterhin und enthalten ebenso nur noch Links zu den relevanten Dateien im Planet-Verzeichnis. Übersicht: http://dev.openstreetmap.de/navipowmmaps/ Direkter Planet-Download: http://dev.openstreetmap.de/navipowmmaps/navipowm/planet/ Alle Länder der Welt: http://dev.openstreetmap.de/navipowmmaps/navipowm/world/ Datenquelle: planet.osm vom 22.07.2010 (komplett) Anzahl: 20458 Dateien entpackte Größe (Mapfiles): 22 GB gepackte Größe (7z-Files): 4,9 GB MAP-Version: V0.2.4 (=V0.2.5 dev) Falls Kacheln in Ländern fehlen sollten (oder Ländergrenzen falsch sind, ...), dann die Änderungen mir bitte mitteilen. Die Zuordnung zwischen Kachelnummern und Land findet man hier in TXT-Datein für alle Kontinente, Länder und teilweise Bundesstaaten: http://dev.openstreetmap.de/navipowmmaps/navipowm/countries/ Fehlt sonst noch was? Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelte Tags - rausnehmen
Am 26.07.2010 10:09, schrieb Walter Nordmann: nach der devise: hier geht's zum xxx. mach ich jedenfalls bei manchen shops so; die sind zwar alle im gleichen haus, haben aber fast immer ne eigene tür. eventuell auch mit anderer adresse addr:* Wenn es verschiedene Shops im selben Gebäude sind, dann mach ein ein building drum rum und darein dann shop-nodes oder -areas. So gibt es trotzdem kein Gescäft 2x. http://www.openstreetmap.org/?lat=49.747882lon=8.136621zoom=18layers=M Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO EUROPA -schon wieder futsch??
Am 25.07.2010 22:38, schrieb Sven Geggus: 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. Jup stimmt. Ist leider etwas chaotisch. Das Problem an Bayern war, dass keepright nicht geklappt hat und der dann keine gesamt-gmapsupp hinbekommen hat. Müsste ich noch nen Fehlerabfang einbauen, dass der dann wenigstens das zusammenpackt, was geklappt hat. Ich habe gmapsupp_europe.img.zip vom Mittwoch verwendet und das läuft definitiv. Und ich die europa vom Montag und die läuft bei mir auch. Hat denn noch jemand das Problem, dass da was nicht geht? Grüße Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Hallo, Stefan Dettenhofer (StefanDausR) wrote: Man muss dann nur bei Änderungen der Gemeindegrenzen (Eingemeindung, Grundstückstausch, etc.) auch auf die PLZ achten, die sich ja dadurch nicht zwangsläufig ebenso ändern muss, oder? Sobald die Gemeindegrenze nicht mehr 1:1 mit dem PLZ-Gebiet übereinstimmt muss dann trotzdem eine eigene PLZ-Relation erstellt werden. Das stimmt. Aber im Augenblick duerften die allermeisten Aenderungen an Gemeindegrenzen bei uns nicht deswegen vollzogen werden, weil sich eine Gemeindegrenze geaendert hat, sondern weil man feststellte, dass die Gemeindegrenze bisher ungenau war ;) Bye Frederik ___ 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
Frederik Ramm schrieb: 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. Und diese Gestattung der Nutzung sieht nach CC-Liznz eben so aus, dass sie für ewig (x+70 genauer gesagt) unter CC bleibt. CC ist absolut relevant. 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. GPL ist nicht CC. Habe jetzt keine Lust, auch noch in die GPL einzutauchen, ob die sowas einfacher macht. Wesentlicher dürfte hier aber sein, dass das Programm und somit das urheberrechtlich geschützte Werk vemutlich von Anfang an doppelt lizenziert war. Damit gab es keine Probleme, das hinterher zu relizenzieren. nachträgliche Versuche solcher Doppellizenzierungen dürften Probleme bereiten. Aber, wie Richard auf legal-talk schrieb, nehmen wir mal einen Augenblick lang an, dass Du recht haettest, und dass beim Umlizensieren in ODbL die CC-By-SA verletzt wuerde. Dann koennte der Urheber der Daten denjenigen verklagen, der die Umlizensierung vorgenommen hat, weil letzterer sich nicht an die von ersterem festgelegte Lizenz gehalten hat. In unserem konkreten Fall sind aber der Urheber und der Umlizensierer identisch. 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. ... oder der fiese ursprüngliche Autor und Relizensierer verklagt die OSMF, dass der planet.osm nicht unter CC steht oder der fiese Datennutzer nutzt die OSM-Daten in einer Art und Weise, die nach CC zulässig wäre, nach ODBL nicht, und die OSMF oder irgendein Mapper kann ihn nix anhaben ... Gruß Mueck ___ 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
Frederik Ramm schrieb: Ansonsten ist eine gewisse Respektlosigkeit aber durchaus normal bei OSM. Schon seit Jahren gibt es den Spruch we have unlimited free labour - wir haben unbegrenzte kostenlose Arbeitskraft. Die wesentliche Arbeit derer, die bisher bei OSM dabei waren, ist, OSM zu einer bekannten Groesse in der Branche zu machen; das ist unabhaengig von den konkret beigetragenen Daten. Die Daten sind, Aufopferung hin oder her, leicht ersetzbar. Und bei einer solchen Einstellung gegenüber der Aufopferung in vielen Mannstunden wunderst Du Dich noch über Widerstand? Frederik Ramm schrieb: ich sehe nur bremsen, protestieren, schmollen, stoeren, blockieren. Zu Recht angesichts der Spaßgesellschaft einiger ... Frederik Ramm schrieb: Als *Mapper* kann ich mir vorstellen, dass ich sogar einen gewissen Spass daran haben werde, die Luecken zu schliessen, die moeglicherweise durch den Lizenzwechsel entstanden sind. ___ 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
Heiko, Heiko Jacobs wrote: Frederik Ramm schrieb: 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. Und diese Gestattung der Nutzung sieht nach CC-Liznz eben so aus, dass sie für ewig (x+70 genauer gesagt) unter CC bleibt. CC ist absolut relevant. Ich weigere mich, weiter auf diesem nein-doch-nein-doch Zug mitzufahren. Ich habe Dir erklaert, dass die Einraeumung zusaetzlicher Nutzungsrechte an der CC vorbei moeglich ist. Daher ist es voellig egal, was in der CC selbst drin steht; die Zusatzrechte werden auf einer anderen Ebene eingeraeumt. Wenn Du mir das nicht glaubst, dann hat es auch keinen Sinn fuer mich, das hier weiter zu beteuern. Frage doch einfach jemanden, der sich mit sowas auskennt, und dem Du dann auch glaubst. Du kannst auch die Software erst unter GPL runterladen und spaeter noch die Lizenz kaufen. GPL ist nicht CC. Habe jetzt keine Lust, auch noch in die GPL einzutauchen, ob die sowas einfacher macht. Es geht nicht um die konkrete Lizenz; die GPL wird dazu genau so wenig sagen wie die CC oder irgendeine andere, weil die Zusatzlizensierung an diesem Text vorbei und nicht durch ihn durch geht. Wesentlicher dürfte hier aber sein, dass das Programm und somit das urheberrechtlich geschützte Werk vemutlich von Anfang an doppelt lizenziert war. Nein. Damit gab es keine Probleme, das hinterher zu relizenzieren. nachträgliche Versuche solcher Doppellizenzierungen dürften Probleme bereiten. Nein. ... oder der fiese ursprüngliche Autor und Relizensierer verklagt die OSMF, dass der planet.osm nicht unter CC steht ... weil die OSMF genau das gemacht hat, was der Autor ihr aufgetragen hat zu tun? Das wird doch mit jedem Posting absurder. Bye Frederik ___ 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: Ansonsten ist eine gewisse Respektlosigkeit aber durchaus normal bei OSM. Schon seit Jahren gibt es den Spruch we have unlimited free labour - wir haben unbegrenzte kostenlose Arbeitskraft. Die wesentliche Arbeit derer, die bisher bei OSM dabei waren, ist, OSM zu einer bekannten Groesse in der Branche zu machen; das ist unabhaengig von den konkret beigetragenen Daten. Die Daten sind, Aufopferung hin oder her, leicht ersetzbar. Und bei einer solchen Einstellung gegenüber der Aufopferung in vielen Mannstunden wunderst Du Dich noch über Widerstand? OSM ist ein Ameisenhaufen. Jeder einzelne von uns ist eine Ameise. Die Ansicht, dass die *Daten* das wesentliche oder wichtige an OSM seien, halte ich fuer sehr gefaehrlich, sie birgt den Keim endloser Auseinandersetzungen in sich. Diejenigen, die vor 5 Jahren zu OSM beigetragen haben, sind sehr wichtig fuer das Projekt gewesen, und ich habe grossen Respekt vor ihrer Arbeit. Wenn ich heute alle Daten loesche, die vor 5 Jahren in OSM waren, fuege ich dem Projekt trotzdem einen minimalen Schaden zu, der innerhalb weniger Tage behoben waere. Das ist kein Widerspruch - der Beitrag der Leute war gut und wichtig, aber als Daten ist der Beitrag heute unbedeutend geworden. Frederik Ramm schrieb: ich sehe nur bremsen, protestieren, schmollen, stoeren, blockieren. Zu Recht angesichts der Spaßgesellschaft einiger ... Frederik Ramm schrieb: Als *Mapper* kann ich mir vorstellen, dass ich sogar einen gewissen Spass daran haben werde, die Luecken zu schliessen, die moeglicherweise durch den Lizenzwechsel entstanden sind. Ich mache halt das beste draus. Der Lizenzwechsel ist unvermeidbar, bzw. ihn zu vermeiden wuerde dem Projekt groesseren Schaden zufuegen als ihn mitzutragen. Natuerlich wuerde ich niemals aus Spass Daten loeschen, bloss weil man sie dann neu anlegen kann, aber Daten, die nicht relizensiert wurden, *muessen* halt irgendwann raus aus dem System. Und dann doch lieber mit Spass eine Lueckenfueller-Mappinparty gemacht als sich hingesetzt und geschmollt. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Probleme mit Seen und Inseln
Hallo, ich habe ein Problem mit dem Siljan-See in Schweden; auf der schwedischen Mailingliste konnte mir keiner helfen. Es geht um den See Siljan http://www.openstreetmap.org/browse/relation/5336 Der benachbarte See Orsasjön könnte als Vergleich dienen, denn dort funktioniert alles http://www.openstreetmap.org/browse/relation/15073 Das Problem: Während bei mapnik und osmarender alles korrekt dargestellt wird, verschwinden bei einigen Renderern die Inseln und/oder das Wasser. Zum Beispiel: 1) http://www.opencyclemap.org/?zoom=11lat=60.94lon=14.52454layers=B000 Hier verschwinden Wasser und Inseln. 2) http://maps.cloudmade.com/?lat=60.872329lng=14.799957zoom=10styleId=2400opened_tab=0 Hier werden die Inseln nicht angezeigt. 3) http://hikebikemap.de/?zoom=14lat=60.91006lon=14.58866layers=BT Hier verschwinden die Inseln bei bestimmten Zoom-Leveln. 4) Wenn ich das Gebiet in Kosmos lade, wird bei bestimmten Rendering-Rules gar keine Karte angezeigt und bei den Standard-Rules alles normal (sobald der Siljan in den Daten enthalten ist. Kann mir irgendjemand weiterhelfen? Oder bin ich nur auf ein Problem unterschiedlicher Datenbestände gestoßen (die opencyclemap hat ja nicht immer den aktuellsten Datenbestand)? Oder auf was kommt es bei den Rendering-Rules an? Ich kann einfach keinen Unterschied im Datenbestand zwischen den beiden Seen sehen. Vielen Dank schon mal, Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM V3376 Filter
Hallo! Laut Anzeige JOSM ist bei mir bei angezeigtem Filterdialog immer 1 Element versteckt. Es ist aber gar kein Filter eingetragen!??? -- Mit freundlichen Gruessen Wolfgang Wienke ___ 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 12:26, Frederik Ramm: OSM ist ein Ameisenhaufen. Jeder einzelne von uns ist eine Ameise. Die Ansicht, dass die *Daten* das wesentliche oder wichtige an OSM seien, halte ich fuer sehr gefaehrlich, sie birgt den Keim endloser Auseinandersetzungen in sich. Sehe ich ganz genau so. Es geht mir weniger um die Achtung der Arbeit, die ist unabhängig vorhanden. Es geht einfach um den bindenden Charakter der Lizenzierung, die die damals Beitragenden gewählt haben. Da diese Lizenz keine Weiternutzung der Daten gestattet *müssen* sie gelöscht werden. Ich mache halt das beste draus. Der Lizenzwechsel ist unvermeidbar, bzw. ihn zu vermeiden wuerde dem Projekt groesseren Schaden zufuegen als ihn mitzutragen. Auch hier meine Zustimmung. Das Ziel einer freien Geodatenbank ist mein Ziel, CC vs. ODbL ist für mich da als Beitragender nur ein Detail. Claudius ___ 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. Juli 2010 11:41 schrieb Heiko Jacobs heiko.jac...@gmx.de: Frederik Ramm schrieb: 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. Und diese Gestattung der Nutzung sieht nach CC-Liznz eben so aus, dass sie für ewig (x+70 genauer gesagt) unter CC bleibt. CC ist absolut relevant. Du sprichst vom Nutzungsrecht, Frederik vom Urheberrecht. Die Nutzungsrechte die du Anderen mittels der Freigabe unter CC-by-SA einräumst, beschränken dich nicht der Ausübung deines Urheberrechts (genauer: Das Verwertungsrecht festzulegen). Wenn du dein Werk einmal unter CC-by-SA freigeben hast, kann du das nicht mehr rückgängig machen - du kannst es aber sehr wohl zusätzlich unter anderen Lizenzen so verwerten wie du möchtest (mit der Ausnahme das eine exklusive Nutzung nicht mehr möglich ist). 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. GPL ist nicht CC. Habe jetzt keine Lust, auch noch in die GPL einzutauchen, ob die sowas einfacher macht. Wesentlicher dürfte hier aber sein, dass das Programm und somit das urheberrechtlich geschützte Werk vemutlich von Anfang an doppelt lizenziert war. Damit gab es keine Probleme, das hinterher zu relizenzieren. nachträgliche Versuche solcher Doppellizenzierungen dürften Probleme bereiten. Nein, der Zeitpunkt der Lizenzierung spielt keine Rolle. Du kannst dein Werk heute unter Alle Rechte vorbehalten, morgen unter GPL und nächste Woche als Beerware veröffentlichen - austauschen musst du (oder dein Lizenznehmer) nur den Lizenzhinweis. Der gilt dann nur für diese Kopie, die anderen Kopien betrifft das nicht, die stehen unter der Lizenz die jeweils mitgeliefert wird. Aber, wie Richard auf legal-talk schrieb, nehmen wir mal einen Augenblick lang an, dass Du recht haettest, und dass beim Umlizensieren in ODbL die CC-By-SA verletzt wuerde. Dann koennte der Urheber der Daten denjenigen verklagen, der die Umlizensierung vorgenommen hat, weil letzterer sich nicht an die von ersterem festgelegte Lizenz gehalten hat. In unserem konkreten Fall sind aber der Urheber und der Umlizensierer identisch. 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. ... oder der fiese ursprüngliche Autor und Relizensierer verklagt die OSMF, dass der planet.osm nicht unter CC steht oder der fiese Datennutzer nutzt die OSM-Daten in einer Art und Weise, die nach CC zulässig wäre, nach ODBL nicht, und die OSMF oder irgendein Mapper kann ihn nix anhaben ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Seen und Inseln
Am 26.07.10 12:52, schrieb Christoph Matthei: Hallo, ich habe ein Problem mit dem Siljan-See in Schweden; auf der schwedischen Mailingliste konnte mir keiner helfen. Es geht um den See Siljan http://www.openstreetmap.org/browse/relation/5336 Der benachbarte See Orsasjön könnte als Vergleich dienen, denn dort funktioniert alles http://www.openstreetmap.org/browse/relation/15073 Das Problem: Während bei mapnik und osmarender alles korrekt dargestellt wird, verschwinden bei einigen Renderern die Inseln und/oder das Wasser. Zum Beispiel: 1) http://www.opencyclemap.org/?zoom=11lat=60.94lon=14.52454layers=B000 Hier verschwinden Wasser und Inseln. Die CycleMap hat ein bekanntes Problem mit Multipolygonen. Angeblich soll das in den nächsten Wochen behoben sein. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V3376 Filter
Wolfgang Wienke wrote: Laut Anzeige JOSM ist bei mir bei angezeigtem Filterdialog immer 1 Element versteckt. Es ist aber gar kein Filter eingetragen!??? schick doch bitte mal nen screenshot rüber gruss walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/JOSM-V3376-Filter-tp5337506p5337582.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] Probleme mit Seen und Inseln
Hejsan, ich habe ein Problem mit dem Siljan-See in Schweden; auf der schwedischen Mailingliste konnte mir keiner helfen. Es geht um den See Siljan http://www.openstreetmap.org/browse/relation/5336 Ich würde als erstes beim Outer-Weg natural=water löschen (ist ja bei der Relation selbst bereits getagged) und auch layer=-1 (wenn alles korrekt ist, ist der Layer überflüssig). Vielleicht hilft das bereits. 3) http://hikebikemap.de/?zoom=14lat=60.91006lon=14.58866layers=BT Hier verschwinden die Inseln bei bestimmten Zoom-Leveln. Bei der dieser Karte liegt es daran, dass die Tiles auf dem Toolserver kein 'Ablaufdatum' haben, d. h. man muss ein Löschen und Neu-Rendern explizit per /dirty anfordern. Ich habe das soeben bei ein paar Tiles gemacht und wie Du siehst geht die Insel nun auch bei den anderen Zoom-Levels unter.. Zu den anderen Karten kann ich leider nichts sagen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V3376 Filter
Am 26.07.2010 13:06, schrieb Wolfgang Wienke: Hallo! Laut Anzeige JOSM ist bei mir bei angezeigtem Filterdialog immer 1 Element versteckt. Es ist aber gar kein Filter eingetragen!??? Versuch mal latest. Es gab da einen Bug: josm.openstreetmap.de/ticket/5255 wodurch anscheinend falsche Filter-Informationen angezeigt wurden. oder einfach ignorieren. Gruß Colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V3376 Filter
fly high wrote: Versuch mal latest. Es gab da einen Bug: josm.openstreetmap.de/ticket/5255 wodurch anscheinend falsche Filter-Informationen angezeigt wurden. ohh, thanks gerade gestern hab ich mit dem filter zu ersten mal so richtig beschäftigt und wurde das gefühl nicht los, daß der spinnt. gruss walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/JOSM-V3376-Filter-tp5337506p5337656.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] AIO EUROPA -schon wieder futsch??
So ich hab die Karte gmapsup.img vom 23.07 20.37 Uhr gerade noch einmal geladen - Erfolg ist weiterhin, dass sie in meinem GARMIN etrex Legend Cx nach 88% Ladevorgang abbricht. Mit mir haben auch andere das Problem am etrex VISTA HCx: http://www.geocaching-franken.de/forum/thread-4268-post-9919.html#pid9919 ( OSCAR ) Für mich ist die letzte noch funktionsfähige AIOEuropa Karte vom 16.07.2010 geladen von ftp://ftp5.gwdg.de/pub/misc/openstreetmap/download.openstreetmap.de/aio/regions/europe/ Gruß UMAX974 Am 26.07.2010 um 11:06 schrieb Christoph Wagner: Am 25.07.2010 22:38, schrieb Sven Geggus: 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. Jup stimmt. Ist leider etwas chaotisch. Das Problem an Bayern war, dass keepright nicht geklappt hat und der dann keine gesamt-gmapsupp hinbekommen hat. Müsste ich noch nen Fehlerabfang einbauen, dass der dann wenigstens das zusammenpackt, was geklappt hat. Ich habe gmapsupp_europe.img.zip vom Mittwoch verwendet und das läuft definitiv. Und ich die europa vom Montag und die läuft bei mir auch. Hat denn noch jemand das Problem, dass da was nicht geht? Grüße Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Hi, ich war gestern in einem Dorf, in dem es eine Straße gibt, die auf der linken Straßeseite Amtshof und auf der rechten Straßenseite Am Schmiedeteich heißt. Die Straßenschilder sind echt so vorhanden (Fotos verfügbar) und eine Kollegin wohnt auch in dieser Straße (auf der rechten Seite, also Am Schmiedeteich ;-)) und hat meine Beobachtung inhaltlich bestätigt. Bisher kannte ich immer nur Straßen, die in der Länge unterschiedliche Namen hat und nicht auf unterschiedlichen Straßenseiten. Es handelt sich um eine ganz gewöhnliche Dorfstraße ohne jegliche Trennung in der Mitte. Kann man diese Situation irgendwie geeignet abbilden? In diesem Zusammenhang vielleicht ganz witzig: GMaps erfindet hier gleich eine Straße durch die anliegenden Gärten: http://maps.google.de/?ie=UTF8ll=51.890996,10.765185spn=0.001468,0.004085t=hz=18 :-) Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO EUROPA -schon wieder futsch??
ich ergänze hier noch, da die Diskussion um die etrex Firmware war: ich hab Firmware 3.40 laufe und eine 4GB Pansonic C8 Karte drin. Am 26.07.2010 um 14:13 schrieb UMAX974: So ich hab die Karte gmapsup.img vom 23.07 20.37 Uhr gerade noch einmal geladen - Erfolg ist weiterhin, dass sie in meinem GARMIN etrex Legend Cx nach 88% Ladevorgang abbricht. Mit mir haben auch andere das Problem am etrex VISTA HCx: http://www.geocaching-franken.de/forum/thread-4268-post-9919.html#pid9919 ( OSCAR ) Für mich ist die letzte noch funktionsfähige AIOEuropa Karte vom 16.07.2010 geladen von ftp://ftp5.gwdg.de/pub/misc/openstreetmap/download.openstreetmap.de/aio/regions/europe/ Gruß UMAX974 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Andreas Tille schrieb: in dem es eine Straße gibt, die auf der linken Straßeseite Amtshof und auf der rechten Straßenseite Am Schmiedeteich heißt. Ich würde es so wie hier vorgeschlagen machen: http://lists.openstreetmap.org/pipermail/talk-de/2010-February/062881.html oder alternativ statt name:left= und name:right= besser sogar so mane:forward= und name:backward= Zusätzlich könnte man ja noch in name= beide Namen mit Semikolon getrennt angeben. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und?linker Seite
Andreas Tille andr...@an3as.eu wrote: Kann man diese Situation irgendwie geeignet abbilden? Zweimal Straßen über die selben Nodes eventuell oneway? Gerendert wird dann natürlich Unfug. Gruss Sven -- Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär, und - dank Knut - insbesondere der Eisbär, deutlich größerer Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Frederik Ramm frede...@remote.org wrote: Das stimmt. Aber im Augenblick duerften die allermeisten Aenderungen an Gemeindegrenzen bei uns nicht deswegen vollzogen werden, weil sich eine Gemeindegrenze geaendert hat, sondern weil man feststellte, dass die Gemeindegrenze bisher ungenau war ;) Apropos Genauigkeit: Ich kann im hiesigen Gebiet das Ganze mit den Daten der german administration vergleichen. Zumindest hier sind die jetzt schon vorhandenen Kreisgrenzen aus 2005 in OSM erheblich genauer als die PLZ. Selbst wenn man den PLZ Import deckungsgleich hinzippelt, sind Abweichungen von 100 Metern oder mehr keine Seltenheit, während die Kreisgrenzen schon im Rahmen der Messungenauigkeit von GPS liegen. Auch die Auflösung ist bei den PLZ wesentlich schlechter. Wenn davon auszugehen ist, dass die Qualität über ganz Deutschland so hoch ist, dann könnte man im Wiki vielleicht empfehlen, die Kreisgrenzen in jedem Falle zu belassen und im Zweifel die PLZ anzugleichen. So habe ich es zumindest gehalten, als ich hier erstmals Grenzen von Kommunen und Ortsteilen anhand von geografischen Merkmalen und Ortskenntnissen abgeschätzt habe. By the way: Liegt eigentlich die Kreisgrenzenimport in der Originalform auf einem WMS Server? Kreisgrenzenimport 2005: http://wiki.openstreetmap.org/wiki/Import/Catalogue/Kreisgrenzen_Deutschland_2005 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und?linker Seite
On Mon, Jul 26, 2010 at 01:06:10PM +, Sven Geggus wrote: Andreas Tille andr...@an3as.eu wrote: Kann man diese Situation irgendwie geeignet abbilden? Zweimal Straßen über die selben Nodes eventuell oneway? Gerendert wird dann natürlich Unfug. das ist auch Unfug, denn es SIND keine zwei Strassen. signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
On Mon, Jul 26, 2010 at 02:57:48PM +0200, Stefan Dettenhofer (StefanDausR) wrote: Andreas Tille schrieb: in dem es eine Straße gibt, die auf der linken Straßeseite Amtshof und auf der rechten Straßenseite Am Schmiedeteich heißt. Ich würde es so wie hier vorgeschlagen machen: http://lists.openstreetmap.org/pipermail/talk-de/2010-February/062881.html oder alternativ statt name:left= und name:right= besser sogar so mane:forward= und name:backward= +1 was wieder interessant bzgl. der Linienbuendel/Strassenrichtungsdiskussion ist... ;-) signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Am 26.07.2010 14:57, schrieb Stefan Dettenhofer (StefanDausR): Andreas Tille schrieb: in dem es eine Straße gibt, die auf der linken Straßeseite Amtshof und auf der rechten Straßenseite Am Schmiedeteich heißt. Ich würde es so wie hier vorgeschlagen machen: http://lists.openstreetmap.org/pipermail/talk-de/2010-February/062881.html oder alternativ statt name:left= und name:right= besser sogar so mane:forward= und name:backward= Ich würde name:left= und name:right= verwenden. Was hat das denn mit forward und backward zu tun? Wenn ich mich auf dem Bürgersteig umdrehe, ändert das den Namen meiner Straßenseite? Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Andreas Tille andr...@an3as.eu wrote: ich war gestern in einem Dorf, in dem es eine Straße gibt, die auf der linken Straßeseite Amtshof und auf der rechten Straßenseite Am Schmiedeteich heißt. vielleicht name=Amtshof; Am Schmiedeteich und dann mit der Interpolationslösung die Adressen auf beiden Seiten mit den unterschiedlichen Straßennamen eintragen. http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Mehrere_H.C3.A4user_an_einer_Stra.C3.9Fe_.28Interpolation.29 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Tobias Knerr schrieb: Ich würde name:left= und name:right= verwenden. Was hat das denn mit forward und backward zu tun? Wenn ich mich auf dem Bürgersteig umdrehe, ändert das den Namen meiner Straßenseite? Hm, da hast Du auch wieder recht! Also bis es eine vernünftige Lösung per Linienbündel gibt, ist wohl name:left= und name:right= die passende Wahl! Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische R ichtungsfunktion in OSM?
Am 22. Juli 2010 10:32 schrieb Georg Feddern ne...@bavarianmallet.de: tag k='maxspeed' v='70' / nd ref='-1' / nd ref='-2' / nd ref='-4' / tag k='maxspeed' v='50' / nd ref='-4' / nd ref='-2' / nd ref='-1' / ... prinzipiell machbar (mit kleinen formalen Änderungen ;-) ). Du machst allerdings nichts anderes, als den öffentlichen Textzusatz :forward in einen internen versteckten Bereich zu verschieben - da könnte man dann z.B. genauso bei einem internen versteckten forward bleiben. Denn der Editor muss bei dieser Variante jetzt eh: - Dem Nutzer bei jedem richtungsbezogenen-Tag die Richtung 'visualisieren', damit der weiß, worauf sich der Tag bezieht, z.B. durch forward/backward? ;-) - und er muss eine entsprechende Eingabemöglichkeit anbieten. Zudem müsste er aber bei Deiner Version bei jeder Weg-Änderung (entfernen, hinzufügen, teilen, verbinden)alle entsprechenden Node-Referenzen bearbeiten - da kann er auch bei jeder Richtungsänderung die internen Tags anpassen, fragt sich, was einfacher ist bzw. öfter vorkommt ... Möglicherweise lässt sich das auch soweit eindampfen, dass man nur den ersten und den letzten Node angibt. Es könnte aber Gründe geben, warum man dies beim Way nicht getan hat. Dieselben Gründe könnten auch dagegen sprechen, beim Tag ebenso zu verfahren. Ein Way führt nunmal über alle Nodes (wo z.B. ja auch andere Wege abgehen können), daher müssen ja auch alle Nodes enthalten sein. Für die Richtung würden zwar die End-Notes ausreichen, dann muss aber bei jeder Node-Änderung entsprechender Zusatz-Aufwand betrieben werden - Alternative s. o.. Hat man damit viel gewonnen? unter Umständen schon: man müsste die Ways nämlich nicht mehr wegen jeder Geschwindigkeitsbeschränkung oder Änderung des Fahrbahnbelags oder sonst was teilen, sondern könnte die Eigenschaften auch nur Teil-ways mitgeben. Solche Vorschläge gabs schon - würde natürlich einen ziemlichen Aufwand beim Umstellen sämtlicher Programme bedeuten, aber auch einiges bringen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V3376 Filter
Am 26.07.2010 14:01, schrieb Walter Nordmann: fly high wrote: Versuch mal latest. Es gab da einen Bug: josm.openstreetmap.de/ticket/5255 wodurch anscheinend falsche Filter-Informationen angezeigt wurden. Bug ist noch nicht behoben. gerade gestern hab ich mit dem filter zu ersten mal so richtig beschäftigt und wurde das gefühl nicht los, daß der spinnt. Ist ein schönes Tool. Ist nur die Anzeige falsch oder wird auch falsch gefiltert ? Gruß colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM V3376 Filter
auf einmal - so mittendrin beim arbeiten/scrollen- sind dann z.b. alles hausnummern und alle pois wieder zu sehen. ich mache mit den postleitzahlen rum und hab ein filter auf admin-bourdaries gesetz und dann noch auf highway=residential. damit möchte ich nur die grenzen und wichtige straßen sehen. und huch, auf einmal ist der schirm wieder bunt. mfg walter - Ich bin root, ich darf das. -- View this message in context: http://gis.638310.n2.nabble.com/JOSM-V3376-Filter-tp5337506p5338172.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] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Frederik Ramm frede...@remote.org wrote: 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. In einer ersten Phase geht es erst einmal darum, einfach dasselbe vorzufinden, was man auch auf der Originalkarte hat. Das würde für viele Zwecke schon reichen. z.B. Anfänger, Schulung, Demonstrationen, Wiki-Illustrierung etc. - oder z.B. für den derzeitigen PLZ-Import üben, ohne das man Gefahr läuft, etwas zu beschädigen. Die tatsächliche Änderung von Apis, Renderern oder Ahnlichem zu testen, wäre dann schon sehr advanced fortgesponnen und erst in einem Stadium denkbar, wenn sich die einfache Version etabliert hat. Dann kann man immer noch weiter sehen. Und auch auf der einfachen Oberfläche kann man gemeinschaftlich ein neues System ausprobieren, ohne dass es anders als normal gerendert wird. Wenn man dort beginnt, verschiedene Situationen durchzumappen, merkt man auch ohne neuen Renderer, dass es noch hier und dort kneift und die Textwüste noche einer Änderung bedarf. Z.B. kann jemand hier ein Beispiel hinterlassen, wo es eben kneift und den anderen dort zeigen. Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. 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... Wenn es um Tagging Entscheidungen geht, dann geht es auch um etwas real Existierendes. Und das künnte man auch in normalen Karte mappen und ausprobieren. Damit könnten also die Außerirdischen vom Miniplaneten die Erde nicht überfallen. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mehrere Tagging fragen:
Moin, ich hab da mal ein paar Fragen, die schlicht in der Vergangenheit sich aufgestaut haben. 1. In Ilmenau wurde der Homburger Platz[1] saniert. Jetzt steht hier ein Bushäuschen (nur in die eine Richtung) mit drauf. An die Glasflächen desselben wird an die Städtepartnerschaft Homburg-Ilmenau gedacht. Ist das nun schon ein memorial? Oder ist dass dann der Platz? Oder sollte die Info nur als note an den Platz gehängt werden? 2. Beim Wandern hab ich immer wieder eine Furt für Fußgänger[2] entdeckt. Sprich es gibt eine Stelle, wo der Wanderweg durch Gewässer geht (meist nur Abwasser- oder Bachgraben). Diese sind dann nach stärkeren Regen nicht mehr trockenen Fußes überquerbar. Bisher habe ich für diese Stellen immer highway=ford verwendet. Jedoch sieht das spätestens auf der Karte etwas seltsam aus. Daher die Frage, ob es so richtig ist, oder ob der Tag nur für Furte für Fahrzeuge gedacht ist... 3. Kreuzung Verkehrsberuhigter Bereich vs. Normalo-Straße. Wenn eine living_street eine normale Straße kreuzt, wird die Livingstreet durch ein Aufhebungszeichen davor beendet und mit einem neuen Spielstraßen-Zeichen danach wieder begonnen[3]. Für mich war das ganze ein sinnloser Aufwand, weshalb ich in der Karte die living_street einfach durchgezogen habe. Nun war ich an der Kreuzung Schwanenstraße-Graben-Topfmarkt[4]. Hier ist es so ausgeschildet, das die living_street sich auch auf die Kreuzung ausdehnt, Graben und Schwanenstraße, dann aber als normale Straßen (mit Aufhebungszeichen am Straßenbeginn) weiterlaufen. Die Kreuzung Topfmarkt-Pfortenstraße (etwas nördlich von [4]) war da etwas deutlicher, da der Verkehrsberuhigte Bereich erst weit in der Pfortenstraße drin aufgehoben wird. Muss man nun Graben und Schwanenstraße noch auftrennen und etwas living_street draus machen? Oder kann man diese Ausschilderung einfach ignorieren? 4.1 wheelchair=yes/no an Eingängen sinnvoll? Bisher habe ich wheelchair nur als no getagt, wenn der Weg sichtbar nicht rollstuhlfähig war oder als yes, wenn er extra für Rollis gebaut wurde. Nun kenne ich bei mir an der Uni einige Gebäude mit vielen Eingängen, wovon jedoch nur ein oder zwei überhaupt für Rollifahrer zugänglich sind. Wäre hier ein wheelchair-Tag sinnvoll? Kann man irgendwie noch symbolisieren hinter welchen Eingang sich ein Fahrstuhl versteckt? 4.2 Behindertenfreundliche Seminarräume? Unsere Uni hat an jedem Seminarraum und Hörsaal einen riesigen Aufkleber gepappt, die Rot, Gelb und Grün sind. Rot steht für Nicht-Behinderten-Gerecht, Gelb für Teilweise-Roli-Gerecht und Grün für voll-Roli-Gerecht[5]. Kann man sowas irgendwie taggen, zumal sich die Aufkleber augenscheinlich ausschließlich auf Rollifahrer beziehen, auch wenn von Behindertengerecht gesprochen wird? ... Hoffe mir kann irgendwer helfen ... und hoffe ich hab mich verständlich ausgedrück :-D MfG Andreas [1] http://www.openstreetmap.org/?lat=50.682652lon=10.912916zoom=18 [2] http://www.openstreetmap.org/?lat=50.700925lon=10.946862zoom=18 [3] http://www.openstreetmap.org/?lat=50.677271lon=10.920169zoom=18 [4] http://www.openstreetmap.org/?lat=50.68653lon=10.913732zoom=18 [5] Das beste ist das neuste Hörsaalgebäude. Man hat extra im dort eingebauten Audimax Rollstuhl-Arbeitsplätze am Rand eingerichtet. Im zweiten Hörsaal in dem Gebäude jedoch wurden die vollkommen vergessen, so dass der Rollifahrer noch vor der ersten Reihe stehen darf... Dumm nur, dass sich die Hörsaalverteilung nicht nach den Rollifahrern, sondern nach den Teilnehmerzahlen der Vorlesungen richtet :-P -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ 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 b ei =?iso-8859-1?q?_forward/backward?=)
Am 26. Jul 2010 um 08:19 schrieb Guenther Meyer d@sordidmusic.com:Am Montag 26 Juli 2010, 00:39:36 schrieb steffterra: Am 25.07.2010 um 23:47 schrieb Guenther Meyer: Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: 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. Das erfordert aber wieder dieses Linienchaos, das doch so unuebersichtlich ist...Was meinst du mit "Linien"-Chaos - Es sind doch nur drei Linien in JOSM (und eine Linie im Renderer):1. Linie (way): die eine Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist.2. Linie (way: der daten-way: hier wird alles draufgetaggt, was _nicht_ richtungsabhängig ist, wie z.b. name + ref-Tag3. Linie (way): die entgegen gesetzte Fahrtrichtung:hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist.Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur.Doch es ist nicht grundsätzlich gedacht, dass man Fahrspuren taggt, wo es vom Tagging her gar nicht nötig wäre. Und vom Tagging her ist es nur dann nötig, wenn Tags nur in einer Richtung gelten, oder sie sich Tag für die gleiche Richtung unterscheiden. (Beispiel: innere Spur der einen Richtung maxspeed=50, äußere Spur der gleichen Richtung maxsped=40, Gegernrichtung beide Spuren: maxspeed=80, also dort nur ein way und lanes=2) 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. was genau willst du eigentlich? So wie ich das verstehe, willst du, dass jeder Teil (Strasse, Fussweg, Fahrradweg) separat als way eingezeichnet wird, um diese dann irgendwie zusammenzufassen.Sorry, aber lies meine erste Mail zu dem Thema nochmal in Ruhe durch. Dann weisst Du, was ich möchte. Danke vielmals für die Aufmerksamkeit ;-) Ich denke mir shcon die ganze Zeit, dass Du es komplett nicht verstanden hast, was die Gruppierung möchte.Gerne erkläre ich es dfir aber auch mal seperat per email, dass wir den Thread nciht unnötig zumüllen, weil es andere längst verstanden haben. Kann ja vorkommen, kein Problem, aber dann nicht hier nochmal alles von vorne durchkauen bitte, wenn man es im ersten Post nachlesen kann.Ich praeferiere eher den Ansatz, dass eine Strasse prinzipiell nur aus einem way besteht, der die zusaetzlichen Wege - genauso wie die Anzahl der Fahrspuren - als Attribute bekommt.Dann hats Du wieder das Problem, weshalb ich ja eben nciht alles auf einem way haben möchte: bei Fahrtrichtungsabhängigen Tags (weisst Du überhaupt was damit gemeint ist? Also z.b. ein maxspeed gilt nur in einer richtung udn in der andreren eine andere maxseed, oder ein Radweg ist nur in einer Richtung, sprich auf einer Straßenseite, oder er ist auf beiden seiten da und nur auf einer ist er mit den Fußgängern zusammen, etc.)Deshalb ja die Gruppierung der einzelnen ways (s.o.), dass man weiss, dass alles zu einer Straße zusammen gehört. Es sollte ja im Editor auch farblich zusammengelget werden, dass die Wahrnehmung nciht leidet wie im jetzigen Editor, wenn Fahrspuren einzeln gezeichnet würden (was man derzeit nicht soll) aber ich wiederhole mich. Bitte lies mein erstes Post dazu. Danke.Bitte nimm Dir die Zeit, sonst fehlt Dir jede Diskussionsgrundlage und wir drehen uns hier im Kreis.steffterraP.S. Es wäre sehr schade, wenn das Thema zerredet würde. Bitte lest
Re: [Talk-de] PLZ-Import, Widersprüche
Hallo, Tirkon wrote: By the way: Liegt eigentlich die Kreisgrenzenimport in der Originalform auf einem WMS Server? Ja, der OSM Inspector hat das noch drin. Irgendwann wollten wir das allerdings mal wegtun: http://tools.geofabrik.de/osmi/?view=kreisgrenzenlon=10.30911lat=50.54939zoom=10overlays=boundaries_from_infas_geodaten Bye Frederik ___ 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: Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. Das ist in der Vergangenheit immer scharf kritisiert worden, wenn Leute das gemacht haben. Es gibt natuerlich api06.dev.openstreetmap.org, wo man sich leicht einen Account holen und herumspielen kann. Man kann da auch mal eben ein kleines Dorf selber hochladen zum Spielen, aber dazu muss man natuerlich ein bisschen mit dem Editor tricksen. Vielleicht sollte man mal ganz klein anfangen und eine Webseite machen, mit der man einen kleinen Datenbereich vom echten Server auswaehlen und auf api06.dev einspielen kann... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 14:26 schrieb Andreas Tille andr...@an3as.eu:Hi, ich war gestern in einem Dorf, in dem es eine Straße gibt, die auf der linken Straßeseite "Amtshof" und auf der rechten Straßenseite "Am Schmiedeteich" heißt. Die Straßenschilder sind echt so vorhanden (Fotos verfügbar) und eine Kollegin wohnt auch in dieser Straße (auf der rechten Seite, also "Am Schmiedeteich" ;-)) und hat meine Beobachtung inhaltlich bestätigt. Bisher kannte ich immer nur Straßen, die in der Länge unterschiedliche Namen hat und nicht auf unterschiedlichen Straßenseiten. Es handelt sich um eine ganz gewöhnliche Dorfstraße ohne jegliche Trennung in der Mitte. Kann man diese Situation irgendwie geeignet abbilden? In diesem Zusammenhang vielleicht ganz witzig: GMaps erfindet hier gleich eine Straße durch die anliegenden Gärten: http://maps.google.de/?ie=UTF8ll=51.890996,10.765185spn=0.001468,0.004085t=hz=18 :-) Wie jeden fahrtrichtungsabhängigen Tag am Straßenway: derzeit mit backward/forward (in Bezug auf die Einzeichnungsrichtung im Editor) oder left/right (ebenfalls dazu bezugnehmend). Da beides keine wirklich gute Lösung darstellt (der way könnte sehr leicht im Editor gedreht werden mit fatalen Auswirkungen), könnte man für jede Fahrtrichtung eine Relation erstellen, die dann den name-Tag jeweils passend für jede Richtung enthält. Aber auch das ist eigentlich keine _sehr_ gute Lösung. Ich bevorzuge dennoch _derzeit_ die erste, weil leichter nachzuvollziehen und eine Relation durch Umbaumaßnahmen am way deutlich schneller kaputt geht, als tags, die automatisch bei Trennung am Node in den neuen way kopiert werden.Derzeit wird das Einzeichnen von ways für jede Fahrtrichtung und anschließender Zusammenfassung zu einer Gruppe (dann in Gesamtheit als _eine_ Straße erkennbar) diskutiert. Dann wäre es möglich je einen way für jede Fahrspur der beiden Richtungen zu zeichnen und an den einen way der einen Richtung den einen Name-tag zu schreiben und in der Gegenrichtung am anderen way den anderen Namen. Aber das ist derzeit noch nicht möglich, da die Gruppierungsmöglichkeit im Editor und der Datenbank fehlt.Frage: besteht eine bauliche Trennung für jede Seite der Straße? Dann dürftest Du sowieso für jede Richtung einen eigenen way zeichnen, den Du dann einfach mit dem entsprechenden Namen versiehst.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und?linker Seite
Am 26. Jul 2010 um 15:06 schrieb Sven Geggus li...@fuchsschwanzdomain.de:Andreas Tille andr...@an3as.eu wrote: Kann man diese Situation irgendwie geeignet abbilden? Zweimal Straßen über die selben Nodes eventuell oneway? Gerendert wird dann natürlich Unfug. Unabhängig vom Renderer (für den wir es ja nicht machen ;-) ist das keine gute Idee, da schlecht erkennbar, geschgweige denn gescheit auswählbar. Widerspricht allem, was man mal als OSM-Anfänger gelernt hat ;-)steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 15:42 schrieb Tobias Knerr o...@tobias-knerr.de:Am 26.07.2010 14:57, schrieb Stefan Dettenhofer (StefanDausR): Andreas Tille schrieb: in dem es eine Straße gibt, die auf der linken Straßeseite "Amtshof" und auf der rechten Straßenseite "Am Schmiedeteich" heißt. Ich würde es so wie hier vorgeschlagen machen: http://lists.openstreetmap.org/pipermail/talk-de/2010-February/062881.html oder alternativ statt name:left= und name:right= besser sogar so mane:forward= und name:backward= Ich würde name:left= und name:right= verwenden. Was hat das denn mit forward und backward zu tun? Wenn ich mich auf dem Bürgersteig umdrehe, ändert das den Namen meiner Straßenseite?backward/forward ist in Bezug auf die Einzeichenrichtung in JOSM gemeint. So wie left/right ja auch, denn von wo aus ist denn Dein Links, das jemand anderes sieht, der aus der anderen Richtung kommt. richtig: rechts? Und woher will der, der die OSM-Daten ausliest nun wissen, aus welcher richtung kommend rechts rechts ist und links links? Verstehst Du das Problem? Beide Tagvarianten beziehen sich _immer_ auf die richntung, wie der way in JOSM angezeigt wird/gezeichnet wurde.Deshalb ways mit dieses Tag niemals drehen Oder man weiss was man tut und hat gute Ortskenntnisse das im Zweifelsfall wieder hinzubekomnmen, wenn man falsch gedreht hat ;-)steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 15:47 schrieb Tirkon tirko...@yahoo.de:Andreas Tille andr...@an3as.eu wrote: ich war gestern in einem Dorf, in dem es eine Straße gibt, die auf der linken Straßeseite "Amtshof" und auf der rechten Straßenseite "Am Schmiedeteich" heißt. vielleicht name=Amtshof; Am SchmiedeteichDas ist dei einfachste Möglichkeit, wobei hier nicht abgebildet wird, auf welcher Straßenseite welcher Straßenname der beiden gilt.Das versuchst Du indirekt im zweiten Schritt:und dann mit der Interpolationslösung die Adressen auf beiden Seiten mit den unterschiedlichen Straßennamen eintragen. http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Mehrere_H.C3.A4user_an_einer_Stra.C3.9Fe_.28Interpolation.29Das Problem ist aber auch hier: wenn man die Adressen nicht beachten sollte (egal ob als Relation, als Interpolation oder an einzelnen Häusernodes mit allen addr:Tags voll eingetragen), dann weiss man vom way her gesehen nur, dass er beide Namen trägt, nicht aber welche Straßenseite welchen Namen hat.Da man aber im Allgemeinen nicht nach der richtigen Straßenseite direkt sucht, sondern eine Adresse sucht und dann schaut, auf welcher Straßenseite sich diese befindet, ist es durch die Adressen auch ausrewichend plausibel, oder?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)
Könntet Ihr das Thema "Miniplanet" bitte in einem eigene mail-Thread besprechen? Das hat nur weit am Rande etwas mit dem Thema der Gruppierung von Ways zu tun. Danke fürs Verständnis!steffterraAm 26. Jul 2010 um 16:46 schrieb Tirkon tirko...@yahoo.de:Frederik Ramm frede...@remote.org wrote: 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". In einer ersten Phase geht es erst einmal darum, einfach dasselbe vorzufinden, was man auch auf der Originalkarte hat. Das würde für viele Zwecke schon reichen. z.B. Anfänger, Schulung, Demonstrationen, Wiki-Illustrierung etc. - oder z.B. für den derzeitigen PLZ-Import üben, ohne das man Gefahr läuft, etwas zu beschädigen. Die tatsächliche Änderung von Apis, Renderern oder Ahnlichem zu testen, wäre dann schon sehr advanced fortgesponnen und erst in einem Stadium denkbar, wenn sich die "einfache" Version etabliert hat. Dann kann man immer noch weiter sehen. Und auch auf der einfachen Oberfläche kann man gemeinschaftlich ein neues System ausprobieren, ohne dass es anders als normal gerendert wird. Wenn man dort beginnt, verschiedene Situationen durchzumappen, merkt man auch ohne neuen Renderer, dass es noch hier und dort kneift und die Textwüste noche einer Änderung bedarf. Z.B. kann jemand hier ein Beispiel hinterlassen, wo es eben kneift und den anderen dort zeigen. Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. 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... Wenn es um Tagging Entscheidungen geht, dann geht es auch um etwas real Existierendes. Und das künnte man auch in normalen Karte mappen und ausprobieren. Damit könnten also die Außerirdischen vom Miniplaneten die Erde nicht überfallen. ;-) ___ 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)
Wie schon an anderer Stelle bemerkt würde ich mich freuen, wenn ihr das Thema "Minioplanet" ein einem eigenen Thementhread forsetzen könntet. Danke vielmals. cutpaste fürs Zitieren hilft ;-)steffterraAm 26. Jul 2010 um 17:43 schrieb Frederik Ramm frede...@remote.org:Hallo, Tirkon wrote: Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. Das ist in der Vergangenheit immer scharf kritisiert worden, wenn Leute das gemacht haben. Es gibt natuerlich api06.dev.openstreetmap.org, wo man sich leicht einen Account holen und herumspielen kann. Man kann da auch mal eben ein kleines Dorf selber hochladen zum Spielen, aber dazu muss man natuerlich ein bisschen mit dem Editor tricksen. Vielleicht sollte man mal ganz klein anfangen und eine Webseite machen, mit der man einen kleinen Datenbereich vom echten Server auswaehlen und auf api06.dev einspielen kann... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26.07.2010 17:53, schrieb steffterra: Ich würde name:left= und name:right= verwenden. Was hat das denn mit forward und backward zu tun? Wenn ich mich auf dem Bürgersteig umdrehe, ändert das den Namen meiner Straßenseite? backward/forward ist in Bezug auf die Einzeichenrichtung in JOSM gemeint. Das ist mir klar. name:forward/backward heißt: Wenn ich mich in Wegrichtung bewege, dann hat die Straße (insgesamt!) den Namen aus dem Tag name:forward, wenn ich mich in Gegenrichtung bewege, hat sie den Namen aus name:backward. Das ist aber, wenn man mit der Situation in der Realität vergleicht, Unsinn. name:left/right heißt: Wenn ich mich in Wegrichtung bewege, dann hat die linke Straßenseite den Namen aus name:left, die rechte Straßenseite den Namen aus name:right. Und das ist genau das, was ich ausdrücken will. Tobias Knerr ___ 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 way s bei forward/backward)
Am Montag 26 Juli 2010, 17:29:22 schrieb steffterra: Was meinst du mit Linien-Chaos - Es sind doch nur drei Linien in JOSM (und eine Linie im Renderer): 1. Linie (way): die eine Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist. 2. Linie (way: der daten-way: hier wird alles draufgetaggt, was _nicht_ richtungsabhängig ist, wie z.b. name + ref-Tag 3. Linie (way): die entgegen gesetzte Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist. ok, so kannst du dir natuerlich die Richtung sparen. Nur hast du damit im Editor durch die drei ways auch automatisch eine Ausdehnung, die nicht unbedingt der Realitaet enspricht (tut sie sowieso nicht, aber eine schmale Strasse bringst du dann evtl nicht mehr zwischen den angrenzenden Haeusern/POIs durch. Aber man koennte sich doch die drei ways sparen, und das ganze genau so auf einem way abbilden. Klar braucht man da eine Richtung, und drehen muss die auch keiner. Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur. muss man nicht. Ausserdem hast du dann wieder eine Mischloesung... Doch es ist nicht grundsätzlich gedacht, dass man Fahrspuren taggt, wo es vom Tagging her gar nicht nötig wäre. Und vom Tagging her ist es nur dann nötig, wenn Tags nur in einer Richtung gelten, oder sie sich Tag für die gleiche Richtung unterscheiden. (Beispiel: innere Spur der einen Richtung maxspeed=50, äußere Spur der gleichen Richtung maxsped=40, Gegernrichtung beide Spuren: maxspeed=80, also dort nur ein way und lanes=2) laesst sich alles als Attribut auf einem way abbilden. Aber egal wie man das auf der Datenbasis modelliert, letztendlich bleibt es sowieso am Editor haengen, das entsprechen editierbar darzustellen. Rendern laesst sich sowas vielleicht noch, aber spaetestens bei der Graphenbildung fuer's Routing wird's komplex wuerde ich vermuten... 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. nur wenn man damit rumspielt, und das muss ja ein Editor nicht anbieten. und dass jemand solche Konstrukte direkt auf Tagbasis bearbeitet, wuerde ich jetzt eher weniger vermuten. 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. Besser als die urspruengliche Idee des Linienbuendels ist dein Vorschlag allemal ;-) Sorry, aber lies meine erste Mail zu dem Thema nochmal in Ruhe durch. Dann weisst Du, was ich möchte. Danke vielmals für die Aufmerksamkeit ;-) Ich denke mir shcon die ganze Zeit, dass Du es komplett nicht verstanden hast, was die Gruppierung möchte. Gerne erkläre ich es dfir aber auch mal seperat per email, dass wir den Thread nciht unnötig zumüllen, weil es andere längst verstanden haben. Kann ja vorkommen, kein Problem, aber dann nicht hier nochmal alles von vorne durchkauen bitte, wenn man es im ersten Post nachlesen kann. Eigentlich macht die Mail es relativ klar. Ich ging halt beim Begriff Linienbuendel von was anderem aus. Genauso wie manche Leute einen Stellplatz nicht als Parkplatz nutzen wuerden ;-) Ich praeferiere eher den Ansatz, dass eine Strasse prinzipiell nur aus einem way besteht, der die zusaetzlichen Wege - genauso wie die Anzahl der Fahrspuren - als Attribute bekommt. Dann hats Du wieder das Problem, weshalb ich ja eben nciht alles auf einem way haben möchte: bei Fahrtrichtungsabhängigen Tags (weisst Du überhaupt was damit gemeint ist? Also z.b. ein maxspeed gilt nur in einer richtung udn in der andreren eine andere maxseed, oder ein Radweg ist nur in einer Richtung, sprich auf einer Straßenseite, oder er ist auf beiden seiten da und nur auf einer ist er mit den Fußgängern zusammen, etc.) DAS ist mir schon klar... Wie waer's wenn du mal ein Beispiel anhand einer typischen Strasse einfach mal modellierst und als OSM-Datei zur Verfuegung stellst? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am Montag 26 Juli 2010, 18:17:46 schrieb Tobias Knerr: Am 26.07.2010 17:53, schrieb steffterra: Ich würde name:left= und name:right= verwenden. Was hat das denn mit forward und backward zu tun? Wenn ich mich auf dem Bürgersteig umdrehe, ändert das den Namen meiner Straßenseite? backward/forward ist in Bezug auf die Einzeichenrichtung in JOSM gemeint. Das ist mir klar. name:forward/backward heißt: Wenn ich mich in Wegrichtung bewege, dann hat die Straße (insgesamt!) den Namen aus dem Tag name:forward, wenn ich mich in Gegenrichtung bewege, hat sie den Namen aus name:backward. Das ist aber, wenn man mit der Situation in der Realität vergleicht, Unsinn. name:left/right heißt: Wenn ich mich in Wegrichtung bewege, dann hat die linke Straßenseite den Namen aus name:left, die rechte Straßenseite den Namen aus name:right. Und das ist genau das, was ich ausdrücken will. +1 left/right waere generell besser verwendbar als forward/backward, einfach weil es eindeutiger und universeller verwendbar ist. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweg oder nicht Radweg?
Moin, Diesen Fall hatte ich heute: http://www.openstreetmap.org/?lat=51.92061lon=7.69835zoom=17layers=M Ein Fußweg über den mehrere Radrouten (u.A. der Werseradweg) führen. In OSM ist er zusätzlich zum hw=footway mit cycleway=yes getaggt. Nun frage ich mich, sollte ich hier lieber die Stadt Münster anschreiben, dass sie ein Radfahrer-frei Schild dort anpappen mögen, oder die Verantwortlichen für die Radrouten, dass sie den Weg umlegen sollen? ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
steffterra steffte...@me.com wrote: vielleicht name=Amtshof; Am Schmiedeteich Das ist dei einfachste Möglichkeit, wobei hier nicht abgebildet wird, auf welcher Straßenseite welcher Straßenname der beiden gilt. Das versuchst Du indirekt im zweiten Schritt: und dann mit der Interpolationslösung die Adressen auf beiden Seiten mit den unterschiedlichen Straßennamen eintragen. http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Mehrere_H.C3.A4user_an_einer_Stra.C3.9Fe_.28Interpolation.29 Das Problem ist aber auch hier: wenn man die Adressen nicht beachten sollte (egal ob als Relation, als Interpolation oder an einzelnen Häusernodes mit allen addr:Tags voll eingetragen), dann weiss man vom way her gesehen nur, dass er beide Namen trägt, nicht aber welche Straßenseite welchen Namen hat. Da man aber im Allgemeinen nicht nach der richtigen Straßenseite direkt sucht, sondern eine Adresse sucht und dann schaut, auf welcher Straßenseite sich diese befindet, ist es durch die Adressen auch ausrewichend plausibel, oder? Für das Mappen der Adressen gibt es eigentlich keine Alternative: Straße + Hausnummer. Bleibt nur noch der Straßenname zu diskutieren. Der Straßenkörper in seiner Gesamtbreite - und nicht eine irgendwie geartete Hälfte davon - ist Zuwegung für die Adressen mit beiden Straßennamen. Ich fahre durchaus auch rechts, um die linke Seite zu erreichen und umgekehrt. Daher ist die Zuteilung beider Namen gerechtfertigt. Möglicherweise waren es in der Vergangenheit wirklich zwei Wege, die zu einer Straße vereinigt wurden. Dann wäre das sogar durch die Historie gestützt. Was links oder rechts von der Straße passiert, mappe ich dort, nicht auf der Straße. Funktioniert auch für Routenplaner. Biegen sie ab in Amtshof; Am Schmiedeteich. Es stehen beide Straßenschilder an der Straße, perfekt. Fahren Sie 100 Meter. Sie sind an Ziel Amtshof 10 angekommen. Ähnliche Situation, wenn die Häuser an der A-Straße bis an die B-Straße reichen. Dann schreibe ich auch nicht an die B-Straße name:rechts=A-Straße, obwohl es durchaus passieren kann, dass vereinzelte Häuser dann dort ihre einzige Einfahrt haben können. P.S.: Irgendwie hat Dein Client Probleme mit dem Zeilenumbruch. Meiner muss den ständig nachträglich einfügen. Die Antwortlevel muss ich sogar von Hand einfügen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Guenther Meyer d@sordidmusic.com wrote: left/right waere generell besser verwendbar als forward/backward, einfach weil es eindeutiger und universeller verwendbar ist. IMHO weder left/right noch forward/backward. Was neben der Straße passiert, mappe ich neben der Straße und nicht auf ihr. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Am Montag 26 Juli 2010, 20:45:46 schrieb Tirkon: Guenther Meyer d@sordidmusic.com wrote: left/right waere generell besser verwendbar als forward/backward, einfach weil es eindeutiger und universeller verwendbar ist. IMHO weder left/right noch forward/backward. Was neben der Straße passiert, mappe ich neben der Straße und nicht auf ihr. natuerlich, aber es geht ja hier um die Strasse selbst. 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 b ei forward/backward)
Am 26. Jul 2010 um 20:25 schrieb Guenther Meyer d@sordidmusic.com:Am Montag 26 Juli 2010, 17:29:22 schrieb steffterra: Was meinst du mit "Linien"-Chaos - Es sind doch nur drei Linien in JOSM (und eine Linie im Renderer): 1. Linie (way): die eine Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist. 2. Linie (way: der daten-way: hier wird alles draufgetaggt, was _nicht_ richtungsabhängig ist, wie z.b. name + ref-Tag 3. Linie (way): die entgegen gesetzte Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist. ok, so kannst du dir natuerlich die Richtung sparen. Nur hast du damit im Editor durch die drei ways auch automatisch eine Ausdehnung, die nicht unbedingt der Realitaet enspricht (tut sie sowieso nicht, aber eine schmale Strasse bringst du dann evtl nicht mehr zwischen den angrenzenden Haeusern/POIs durch.Daran habe ich auch gedacht. In JOSM sollte erstmal nur der Datenway zuu sehen sein. Und nur, wenn man auf ihn klickt, dann gehen die beiden ways links und rechts davon "auf". Wenn man wieder woanders hinklickt, geht es wieder "zu" bzw. zurück. Da es nur für Straßen gedacht ist, diue richtungsabhängige Tags benötigen (und das ist sicher nicht die Masse), könnte man auf diese Weise an die Stellen "hineinschauen", die einen interessieren.Aber man koennte sich doch die drei ways sparen, und das ganze genau so auf einem way abbilden. Klar braucht man da eine Richtung, und drehen muss die auch keiner.Dann hast Du das jetzige OSM. Was willst Du mir damit sagen? Das man einfach die Tags drehen kann, das ist ja das Problem. Sie aber zu sperren in irgendeiner Form ist eben aber auch keine Lösung, das hat der Thread auch gezeigt. Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur. muss man nicht. Ausserdem hast du dann wieder eine Mischloesung...Nein, was ist denn gemischt? richtungsabhängige tags gibt es dann offiziell nicht mehr, weil dann die Gruppierten ways für die Richtungsabbildung zuständig ist, die das viel besser maschinen- udn menschenlesbar abbildet. Doch es ist nicht grundsätzlich gedacht, dass man Fahrspuren taggt, wo es vom Tagging her gar nicht nötig wäre. Und vom Tagging her ist es nur dann nötig, wenn Tags nur in einer Richtung gelten, oder sie sich Tag für die gleiche Richtung unterscheiden. (Beispiel: innere Spur der einen Richtung maxspeed=50, äußere Spur der gleichen Richtung maxsped=40, Gegernrichtung beide Spuren: maxspeed=80, also dort nur ein way und lanes=2) laesst sich alles als Attribut auf einem way abbilden.Ja, aber das Grundproblem, warum ich dieses konzept entwickelt habe ist dennoch vorhanden: jemand dreht den way und jemand tagg danach nochmal was richtugnsabhängiges ... Da ist mehr Chaos vorprogrammiert, als wenn alles sauber auf seiner Fahrspur als normaler tag angelegt ist. Denn dann ist es egal, wie der way (respektive die Way-Gruppe) gedreht ist. Denn der tag ist auf der Spur, die es betrifft. fertig - ohne Zusatztag für die Richtung, weil das ja dann hinfälllig ist, verstehst Du?Aber davon abgesehen, was wäre denn Deine Lösung, oder ist Deine Diskussionsgrundlage, dass es nichts zu diskutieren gibt, weil du mit backward/forward und left/right keine Probleme siehst wie ich?Aber egal wie man das auf der Datenbasis modelliert, letztendlich bleibt es sowieso am Editor haengen, das entsprechen editierbar darzustellen.es muss in geeigneter Weise umgesetzt werden um auch Deinem berechtigten Kritikpunkt der Wahrnehmung der Ausdehnung der Straße genüge zu tun Deshalb ja mein obiger Vorschlag zur Umsetzung im Editor.Rendern laesst sich sowas vielleicht noch, aber spaetestens bei der Graphenbildung fuer's Routing wird's komplex wuerde ich vermuten...Schön, dass Du aufs Routing zu sprechen kommst. Routing kann diese Datenbsasis ideal zum fahrspurgenauen Routen zB. an neuraligschen Stellen nutzen. Das ist ein sehr postitiver Nebeneffekt und keineswegs ein Nachteil. Ganz im Gegenteil! 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. Besser als die urspruengliche Idee des Linienbuendels ist dein Vorschlag allemal ;-)Na Danke. Das ist doch mal ne Ansage. Sorry, aber lies meine
Re: [Talk-de] Radweg oder nicht Radweg?
Am 26. Jul 2010 um 20:34 schrieb Chris66 chris66...@gmx.de:Moin, Diesen Fall hatte ich heute: http://www.openstreetmap.org/?lat=51.92061lon=7.69835zoom=17layers=Mgt; Ein Fußweg über den mehrere Radrouten (u.A. der Werseradweg) führen. In OSM ist er zusätzlich zum hw=footway mit cycleway=yes getaggt. Nun frage ich mich, sollte ich hier lieber die Stadt Münster anschreiben, dass sie ein Radfahrer-frei Schild dort anpappen mögen, oder die Verantwortlichen für die Radrouten, dass sie den Weg umlegen sollen? ;-)LOL. Also ich würde es Fahrradfahrerfreundlich machen und die Stadt bitten, das zu Schild dranzupappen, da es ja schließlich ein viel genutzer offizieller Weg für Radwege zu sein scheint.Fals das auf Widerstand stösst, erfähjrst Du ja vlt. auch gleich, warum Radfahgrer da eigentlich verboten sind und kannst auf die Radfahrer mit einer Unterschriftensammlung zugehen.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 20:39 schrieb Tirkon tirko...@yahoo.de:steffterra steffte...@me.com wrote: vielleicht name=Amtshof; Am Schmiedeteich Das ist dei einfachste Möglichkeit, wobei hier nicht abgebildet wird, auf welcher Straßenseite welcher Straßenname der beiden gilt. Das versuchst Du indirekt im zweiten Schritt: und dann mit der Interpolationslösung die Adressen auf beiden Seiten mit den unterschiedlichen Straßennamen eintragen. http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Mehrere_H.C3.A4user_an_einer_Stra.C3.9Fe_.28Interpolation.29 Das Problem ist aber auch hier: wenn man die Adressen nicht beachten sollte (egal ob als Relation, als Interpolation oder an einzelnen Häusernodes mit allen addr:Tags voll eingetragen), dann weiss man vom way her gesehen nur, dass er beide Namen trägt, nicht aber welche Straßenseite welchen Namen hat. Da man aber im Allgemeinen nicht nach der richtigen Straßenseite direkt sucht, sondern eine Adresse sucht und dann schaut, auf welcher Straßenseite sich diese befindet, ist es durch die Adressen auch ausrewichend plausibel, oder? Für das Mappen der Adressen gibt es eigentlich keine Alternative: Straße + Hausnummer. Bleibt nur noch der Straßenname zu diskutieren. Der Straßenkörper in seiner Gesamtbreite - und nicht eine irgendwie geartete Hälfte davon - ist Zuwegung für die Adressen mit beiden Straßennamen. Ich fahre durchaus auch rechts, um die linke Seite zu erreichen und umgekehrt. Daher ist die Zuteilung beider Namen gerechtfertigt. Möglicherweise waren es in der Vergangenheit wirklich zwei Wege, die zu einer Straße vereinigt wurden. Dann wäre das sogar durch die Historie gestützt. Was links oder rechts von der Straße passiert, mappe ich dort, nicht auf der Straße. Funktioniert auch für Routenplaner. "Biegen sie ab in Amtshof; Am Schmiedeteich". Es stehen beide Straßenschilder an der Straße, perfekt. "Fahren Sie 100 Meter. Sie sind an Ziel Amtshof 10 angekommen." Ähnliche Situation, wenn die Häuser an der A-Straße bis an die B-Straße reichen. Dann schreibe ich auch nicht an die B-Straße name:rechts=A-Straße, obwohl es durchaus passieren kann, dass vereinzelte Häuser dann dort ihre einzige Einfahrt haben können.+1 zu allem obigenP.S.: Irgendwie hat Dein Client Probleme mit dem Zeilenumbruch. Meiner muss den ständig nachträglich einfügen. Die Antwortlevel muss ich sogar von Hand einfügen. Und mich stören diese manuellen Umbrüche, weil ich dann voregegeben bekomme, das ich nicht die gesamte Breite meines Fensters zujm Lesen nutzen kann. Wenn Dein Client Deine Umbrüche mitten im Satz automatisch reinmacht, macht er es auch bei dem, was Du von mir zitierst. Doch Dein Client sollte zumn Lesen schon auch fähig sein dynamisch (sprich je nach Fensterbreite) am rechten Fensterrand umzubrechen, oder so einzustellen sein. Und ich dachte, solche Probleme gibtds ja seit UUCP und dem Usenet nicht mehr. Da konnte - hmm wie hies der DOS-Reader doch gleich - das alles sehr schön darstellen - wie man wollte.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Guenther Meyer d@sordidmusic.com wrote: Am Montag 26 Juli 2010, 20:45:46 schrieb Tirkon: Guenther Meyer d@sordidmusic.com wrote: left/right waere generell besser verwendbar als forward/backward, einfach weil es eindeutiger und universeller verwendbar ist. IMHO weder left/right noch forward/backward. Was neben der Straße passiert, mappe ich neben der Straße und nicht auf ihr. natuerlich, aber es geht ja hier um die Strasse selbst. Und die Straße ist in ihrer Gesamtbreite - und nicht eine irgendwie geartete Seite oder Hälfte - Zuwegung zu den Addressen mit beiden Straßennamen. Ich fahre auch links, um eine Adresse auf der rechten Seite zu erreichen und ugekehrt. Es gibt also auf der Straße selbst keinen Unterschied zwischen rechts und links - nur daneben. Mehr Begründung weiter unten im Thread. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
steffterra steffte...@me.com wrote: P.S.: Irgendwie hat Dein Client Probleme mit dem Zeilenumbruch. Meiner muss den ständig nachträglich einfügen. Die Antwortlevel muss ich sogar von Hand einfügen. Und mich stören diese manuellen Umbrüche, weil ich dann voregegeben bekomme, das ich nicht die gesamte Breite meines Fensters zujm Lesen nutzen kann. Wenn Dein Client Deine Umbrüche mitten im Satz automatisch reinmacht, macht er es auch bei dem, was Du von mir zitierst Doch Dein Client sollte zumn Lesen schon auch fähig sein dynamisch (sprich je nach Fensterbreite) am rechten Fensterrand umzubrechen, oder so einzustellen sein. Und ich dachte, solche Probleme gibtds ja seit UUCP und dem Usenet nicht mehr. Da konnte - hmm wie hies der DOS-Reader doch gleich - das alles sehr schön darstellen - wie man wollte. O.K. Ich kann damit leben. Ich wollte nur einmal darauf hinweisen, dass es bei Dir anders ist, als bei allen Anderen, die in den OSM Gruppen mitposten. Ich habe diesmal auch keine Antwort Level eingefügt. ___ 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 way s bei =?iso-8859-15?q?_forward/backward?= )
Am Montag 26 Juli 2010, 21:03:23 schrieb steffterra: ok, so kannst du dir natuerlich die Richtung sparen. Nur hast du damit im Editor durch die drei ways auch automatisch eine Ausdehnung, die nicht unbedingt der Realitaet enspricht (tut sie sowieso nicht, aber eine schmale Strasse bringst du dann evtl nicht mehr zwischen den angrenzenden Haeusern/POIs durch. Daran habe ich auch gedacht. In JOSM sollte erstmal nur der Datenway zuu sehen sein. Und nur, wenn man auf ihn klickt, dann gehen die beiden ways links und rechts davon auf. Wenn man wieder woanders hinklickt, geht es wieder zu bzw. zurück. Da es nur für Straßen gedacht ist, diue richtungsabhängige Tags benötigen (und das ist sicher nicht die Masse), könnte man auf diese Weise an die Stellen hineinschauen, die einen interessieren. spaetestens wenn du Fahrspuren mit abbilden willst, hast du zumindest in groesseren Staedten staendig richtungsabhaengige Attribute. Dasselbe gilt fuer viele Landstrassen (Ueberholverbote, Geschwindigkeitsbeschraenkungen, ...). Aber prinzipiell ein guter Ansatz. Man koennte sich auch durchaus verschiedene Ansichten vorstellen, je nachdem was einen interessiert, bis hin zum fotorealistischen Rendern. Aber man koennte sich doch die drei ways sparen, und das ganze genau so auf einem way abbilden. Klar braucht man da eine Richtung, und drehen muss die auch keiner. Dann hast Du das jetzige OSM. Was willst Du mir damit sagen? Das man einfach die Tags drehen kann, das ist ja das Problem. Sie aber zu sperren in irgendeiner Form ist eben aber auch keine Lösung, das hat der Thread auch gezeigt. natuerlich kann man das drehen nicht sperren. Aber man muss es in der Software auch nicht anbieten, nicht mal anzeigen. Denn es gibt keinen Grund, die Richtung ueberhaupt zu drehen. Das Problem entsteht doch nur dadurch, weil die Richtung einerseits als Referenz fuer diverse Tags genutzt wird, andererseits aber auch direkt z.B. die Richtung einer Einbahnstrasse darstellt. Und genau letzteres muss getrennt werden. Ich sehe die Richtung als Referenzeigenschaft des ways, genauso wie du das durch drei getrennte ways darzustellen versuchst. Um beim Beispiel Einbahnstrasse zu bleiben: Wenn die Fahrtrichtung aus irgendwelchen Gruenden gedreht werden muss, dann wird nur das entsprechende oneway-Attribut gedreht, sonst nichts. Einfacher geht's doch kaum... Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur. muss man nicht. Ausserdem hast du dann wieder eine Mischloesung... Nein, was ist denn gemischt? richtungsabhängige tags gibt es dann offiziell nicht mehr, weil dann die Gruppierten ways für die Richtungsabbildung zuständig ist, die das viel besser maschinen- udn menschenlesbar abbildet. du hast dann einerseits deinen Wegtripel, andererseits im schlimmsten Fall noch mehrere ways, die die einzelnen Fahrspuren kennzeichnen, wenn ich dich richtig verstanden habe. Hmm, jetzt faellt mir noch was ein: Eigentlich wuerden in deinem Modell zwei ways fuer die beiden Seiten reichen. Da diese sowieso in einem uebergeordneten Objekt zusammengefasst werden muessen, kann man doch die allgemeingueltigen Tags gleich da dran haengen; das Einzeichnen des Mittelweges kann man sich dann sparen... Doch es ist nicht grundsätzlich gedacht, dass man Fahrspuren taggt, wo es vom Tagging her gar nicht nötig wäre. Und vom Tagging her ist es nur dann nötig, wenn Tags nur in einer Richtung gelten, oder sie sich Tag für die gleiche Richtung unterscheiden. (Beispiel: innere Spur der einen Richtung maxspeed=50, äußere Spur der gleichen Richtung maxsped=40, Gegernrichtung beide Spuren: maxspeed=80, also dort nur ein way und lanes=2) laesst sich alles als Attribut auf einem way abbilden. Ja, aber das Grundproblem, warum ich dieses konzept entwickelt habe ist dennoch vorhanden: jemand dreht den way und jemand tagg danach nochmal was richtugnsabhängiges ... Da ist mehr Chaos vorprogrammiert, als wenn alles sauber auf seiner Fahrspur als normaler tag angelegt ist. Denn dann ist es egal, wie der way (respektive die Way-Gruppe) gedreht ist. Denn der tag ist auf der Spur, die es betrifft. fertig - ohne Zusatztag für die Richtung, weil das ja dann hinfälllig ist, verstehst Du? schon klar. Im Prinzip laeuft alles auf das fehlerhafte Drehen eines ways zurueck. Aber warum was neues gross und aufwendig ausarbeiten, wenn man genausogut die Ursache des Uebels anpacken kann? Aber davon abgesehen, was wäre denn Deine Lösung, oder ist Deine Diskussionsgrundlage, dass es nichts zu diskutieren gibt, weil du mit backward/forward und left/right keine Probleme siehst wie ich? wie bereits gesagt: ein way bekommt beim Anlegen eine Richtung, und die bleibt unveraenderlich
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Am Montag 26 Juli 2010, 21:17:28 schrieb Tirkon: Guenther Meyer d@sordidmusic.com wrote: Am Montag 26 Juli 2010, 20:45:46 schrieb Tirkon: Guenther Meyer d@sordidmusic.com wrote: left/right waere generell besser verwendbar als forward/backward, einfach weil es eindeutiger und universeller verwendbar ist. IMHO weder left/right noch forward/backward. Was neben der Straße passiert, mappe ich neben der Straße und nicht auf ihr. natuerlich, aber es geht ja hier um die Strasse selbst. Und die Straße ist in ihrer Gesamtbreite - und nicht eine irgendwie geartete Seite oder Hälfte - Zuwegung zu den Addressen mit beiden Straßennamen. Ich fahre auch links, um eine Adresse auf der rechten Seite zu erreichen und ugekehrt. Es gibt also auf der Straße selbst keinen Unterschied zwischen rechts und links - nur daneben. Mehr Begründung weiter unten im Thread. das ist sicher Ansichtssache. Ein Router sollte damit umgehen koennen. Spaetestens beim Rendern wirst du aber Probleme haben, die beiden Namen richtig unterzubringen. Und mich wuerde nicht wundern, wenn die beiden Strassenhaelften verwaltungstechnisch auch getrennt gehandhabt wuerden.. .;-) 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] Talk-de Digest, Vol 48, Issue 208
Frederik Ramm schrieb: Hallo, ich halte die Variante postcode für korrekter, da auch bei einer Adresse addr:postcode verwendet wird. So produziert man nur eine potentielle Fehlerquelle. Mit freundlichen Grüßen Georg V. Date: Mon, 26 Jul 2010 09:44:20 +0200 From: Frederik Ramm frede...@remote.org To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: Re: [Talk-de] PLZ-Import, Widerspr?che Message-ID: 4c4d3cd4.7000...@remote.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Hallo, Norbert K?ck wrote: mir sind zwei Widerspr?che begegnet, die ich nicht einordnen kann: - 1. - [1] sagt: postal_code, postal_code_level [2] enth?lt: postcode, postcode_level Da ist [2] falsch, ich repariere das. ..gelöscht.. Danke fuer die Hinweise. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wie amenity=parking richtig mappen/verbinden?
Hi, habe mir die letzten Tage unterschiedlich gemappte Parkplätze (amenity=parking) angeschaut. Dabei sind mir immer wieder etwas unterschiedliche Vorgehensweisen aufgefallen Manche verbinden den Zufahrtsweg mit dem Außenring der Parkfläche, siehe: http://osm.org/go/0Den6M5qV-- Andere zeichnen wiederum einen Weg auf die Parkplatzfläche ohne das aber wiederum ein gemeinsame Node zwischen Weg und Fläche vorhanden ist: http://osm.org/go/0dep...@e-- Und eine weitere Variante wäre das Einzeichnen aller möglichen Wege auf dem Parkplatz: http://osm.org/go/0DepD4hLW-- Für ein mögliches Routing vom oder evtl. auch auf den Parkplatz wäre es schon gut wenn die Fläche irgendwie mit dem Weg, der von der Fläche weg geht, auch verbunden oder sonst irgendwie an das restliche Straßennetz angebunden wäre, oder wie seht ihr das? viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Import, Widersprüche
Frederik Ramm frede...@remote.org wrote: By the way: Liegt eigentlich die Kreisgrenzenimport in der Originalform auf einem WMS Server? Ja, der OSM Inspector hat das noch drin. Irgendwann wollten wir das allerdings mal wegtun: Ist verständlich. Aber es ist trotz des Alters offensichtlich die mit Abstand beste Grenzreferenz, die wir derzeit deutschlandweit haben. Ohne WMS wären Edit Unfälle kaum mehr zurückzustellbar. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Guenther Meyer d@sordidmusic.com wrote: Spaetestens beim Rendern wirst du aber Probleme haben, die beiden Namen richtig unterzubringen. Nö, in zweisprachigen Gebieten - z.B. in Belgien - ist das sogar die Regel: http://www.openstreetmap.org/?lat=50.75274lon=4.38042zoom=16layers=M Damit haben jetzt die Flamen und Wallonen ihren OSM Editwar. Mal steht der französische Name vorn und mal der holländische. ;-) Bei Straßen, die gleichzeitig zwei Bundeswidmungen haben, funktioniert auch ein Doppel-ref. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und linker Seite
Am Montag 26 Juli 2010, 22:42:22 schrieb Tirkon: Guenther Meyer d@sordidmusic.com wrote: Spaetestens beim Rendern wirst du aber Probleme haben, die beiden Namen richtig unterzubringen. Nö, in zweisprachigen Gebieten - z.B. in Belgien - ist das sogar die Regel: http://www.openstreetmap.org/?lat=50.75274lon=4.38042zoom=16layers=M Damit haben jetzt die Flamen und Wallonen ihren OSM Editwar. Mal steht der französische Name vorn und mal der holländische. ;-) jeder braucht so seine Beschaeftigung... ;-) Nur in dem Fall sind es zwei verschiedensprachige Bezeichnungen fuer dieselbe Strasse, und keine zwei Bezeichnungen fuer die Strassenseiten... aber ist auch egal. 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] Wie amenity=parking richtig mappen/verbinden?
Am 26.07.2010 21:48, schrieb Pascal Neis: Manche verbinden den Zufahrtsweg mit dem Außenring der Parkfläche Andere zeichnen wiederum einen Weg auf die Parkplatzfläche ohne das aber wiederum ein gemeinsame Node zwischen Weg und Fläche vorhanden ist Beides ist mMn. ok, denn normalerweise sollte der Router nach dem nächsten routbaren Weg in der Nähe des Startpunktes. Egal ob die eigentliche Parkplatzfläche nun routbar ist oder nicht, sollte der Router den nächsten Weg finden. Und eine weitere Variante wäre das Einzeichnen aller möglichen Wege auf dem Parkplatz: http://osm.org/go/0DepD4hLW-- Das ist natürlich optimal, gerade auf Parkplätzen mit getrennten Ein- und Ausfahrten, Einbahnstraßen oder Kreiseln. Lg ___ 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 b ei =?iso-8859-15?q?_forward/backward?=)
Am 26. Jul 2010 um 21:33 schrieb Guenther Meyer d@sordidmusic.com:Am Montag 26 Juli 2010, 21:03:23 schrieb steffterra: ok, so kannst du dir natuerlich die Richtung sparen. Nur hast du damit im Editor durch die drei ways auch automatisch eine Ausdehnung, die nicht unbedingt der Realitaet enspricht (tut sie sowieso nicht, aber eine schmale Strasse bringst du dann evtl nicht mehr zwischen den angrenzenden Haeusern/POIs durch. Daran habe ich auch gedacht. In JOSM sollte erstmal nur der Datenway zuu sehen sein. Und nur, wenn man auf ihn klickt, dann gehen die beiden ways links und rechts davon "auf". Wenn man wieder woanders hinklickt, geht es wieder "zu" bzw. zurück. Da es nur für Straßen gedacht ist, diue richtungsabhängige Tags benötigen (und das ist sicher nicht die Masse), könnte man auf diese Weise an die Stellen "hineinschauen", die einen interessieren. spaetestens wenn du Fahrspuren mit abbilden willst, hast du zumindest in groesseren Staedten staendig richtungsabhaengige Attribute. Dasselbe gilt fuer viele Landstrassen (Ueberholverbote, Geschwindigkeitsbeschraenkungen, ...).Die habe ich auch so, nur das ich sie dann an der Spur taggen kann , die es betriff und muss es nicht über ein kompliziertes Tagging-Schema an den einen way hängen.Aber prinzipiell ein guter Ansatz. Man koennte sich auch durchaus verschiedene Ansichten vorstellen, je nachdem was einen interessiert, bis hin zum "fotorealistischen Rendern".Rendern ist aber Rendern und meint nicht die Darstellung im Editor, die ich oben beschrieb.'Für die Renderer habe ich mir ja auch etwas ausgedacht, wie z.b. für Kreuzungen. So eine Art Lupenfunktion, aber keinen weiteren Zoomlevel für dei ganze Seite. Also eher einen Zoomlevel für ein definiertes Rechteck, das dann daneben noch einmal groß gerendert wird. natuerlich kann man das drehen nicht sperren. Aber man muss es in der Software auch nicht anbieten, nicht mal anzeigen. Denn es gibt keinen Grund, die Richtung ueberhaupt zu drehen. Das Problem entsteht doch nur dadurch, weil die Richtung einerseits als Referenz fuer diverse Tags genutzt wird, andererseits aber auch direkt z.B. die Richtung einer Einbahnstrasse darstellt. Und genau letzteres muss getrennt werden. Ich sehe die Richtung als Referenzeigenschaft des ways, genauso wie du das durch drei getrennte ways darzustellen versuchst.ja, ich verstehe es "ausserhalb meines Models" auch so.Um beim Beispiel Einbahnstrasse zu bleiben: Wenn die Fahrtrichtung aus irgendwelchen Gruenden gedreht werden muss, dann wird nur das entsprechende oneway-Attribut gedreht, sonst nichts. Einfacher geht's doch kaum... Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur. muss man nicht. Ausserdem hast du dann wieder eine Mischloesung... Nein, was ist denn gemischt? richtungsabhängige tags gibt es dann offiziell nicht mehr, weil dann die Gruppierten ways für die Richtungsabbildung zuständig ist, die das viel besser maschinen- udn menschenlesbar abbildet. du hast dann einerseits deinen Wegtripel, andererseits im schlimmsten Fall noch mehrere ways, die die einzelnen Fahrspuren kennzeichnen, wenn ich dich richtig verstanden habe.Nunja. Sehe es es. Man kann den way flexibel einsetzen. Entwedera) so wie jetzt auch mit einem way (für die Strecken ohne richtungsabhängige tagsb) mein Model, das zwei ways für jede Fahrtrichtung vorsieht und einen daten-way dazwischen, der von einem neuen Renderer nicht gerendert wird, aber von einem älteren Renderer genutzt wird, weil dieser die anderen Fahrrichtungsways nicht nutzen kann.Bei mehreren Fahrspuren pro Richtung könnte dann auch da der lanes-tag eingesetzt werdenc) mein Model mit genmutzter Möglichkeit neben dem daten-way links und rechts davon mehrere Fahrspuren-ways zu zeichnen, wenn es denn nötig ist, wie z.b. an komplizierten Kreuzungen, oder wenn es verschiedene maxspeed-tags auf jeder Fahrspur gibt, etc. Dann gibt es da halt kein lanes=2, sondern eben zwei ways, die dann zusammen mit dem Rest in einer Gruppe die Straße im gesamten darstellen.Der Vorteil ist die Flexibilität ohne dabei neue Redundanz zu bilden, gleichzeitig ist das ganze abwärtskompatibel. Das ist sogar der wichtigste Punkt an der ganzen Geschichte.Hmm, jetzt faellt mir noch was ein: Eigentlich wuerden in deinem Modell zwei ways fuer die beiden Seiten reichen. eigentlich ja - doch ich wollte vermeiden, dass z.B. der name-tag an beiden ways getaggt wird, was wieder zu unnötiger Redundanz führen würde, so wie im Linienbündel-Model, das ich nicht so mag.Da diese sowieso in einem uebergeordneten Objekt zusammengefasst werden muessen, kann man doch die allgemeingueltigen Tags gleich da dran haengen; das Einzeichnen des Mittelweges kann man sich dann sparen...Das "da dran hängen" ist
Re: [Talk-de] Behindertenparkplatz-Die Lösung
Am 26. Juli 2010 10:35 schrieb Georg Feddern ne...@bavarianmallet.de: steffterra schrieb: Und wie wird die dann in die Area gezeichnet? ich werde JOSM benutzen. dafür gäbe es zwei Möglichkeiten: Entweder als Site-Relation - alle Stellplatz-Nutzer-Arten-Flächen getrennt und die Relation ergibt 'den Parkplatz'. Oder dito als Multipolygon-Relation. M.E. keine Relationen. EInfach einzeichnen und gut is. Alles andere ist totaler overkill und bringt überhaupt keine Mehrinformation. Multipolygon ist dazuhin m.E. falsch, weil es die Flächen ja ausnehmen würde. Man muss sich nur auf einen Tag verständigen und kann loslegen. Gruß Martin ___ 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: dass es mir um die unzerfledderte Integrität des gesamten OSM-Datenbestands geht. Was ich nicht verstehe ist die Vorstellung, OSM würde Daten verlieren. Das stimmt doch garnicht! Nach einer Relizensierung gibt es zwei OSMs eines unter ODBL und eines unter CC-BY-SA -- es hat sich nur noch keiner gefunden, der letzteres betreuen will. Lg ___ 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 way s bei forward/backward)
Am Montag 26 Juli 2010, 23:02:27 schrieb steffterra: spaetestens wenn du Fahrspuren mit abbilden willst, hast du zumindest in groesseren Staedten staendig richtungsabhaengige Attribute. Dasselbe gilt fuer viele Landstrassen (Ueberholverbote, Geschwindigkeitsbeschraenkungen, ...). Die habe ich auch so, nur das ich sie dann an der Spur taggen kann , die es betriff und muss es nicht über ein kompliziertes Tagging-Schema an den einen way hängen. komplizierter ist das auch nicht, nur anders. Aber prinzipiell ein guter Ansatz. Man koennte sich auch durchaus verschiedene Ansichten vorstellen, je nachdem was einen interessiert, bis hin zum fotorealistischen Rendern. Rendern ist aber Rendern und meint nicht die Darstellung im Editor, die ich oben beschrieb. 'Für die Renderer habe ich mir ja auch etwas ausgedacht, wie z.b. für Kreuzungen. So eine Art Lupenfunktion, aber keinen weiteren Zoomlevel für dei ganze Seite. Also eher einen Zoomlevel für ein definiertes Rechteck, das dann daneben noch einmal groß gerendert wird. Ich dachte auch eher an eine Darstellung im Editor, die eher wie eine Draufsicht einer echten Strasse aussieht, um's den Mappern einfacher zu machen. Auch ein Editor muss seine Ansicht irgendwie rendern. Bei Merkaartor z.B. wuerde ich die Darstellung durchau so nennen. du hast dann einerseits deinen Wegtripel, andererseits im schlimmsten Fall noch mehrere ways, die die einzelnen Fahrspuren kennzeichnen, wenn ich dich richtig verstanden habe. Nunja. Sehe es es. Man kann den way flexibel einsetzen. Entweder a) so wie jetzt auch mit einem way (für die Strecken ohne richtungsabhängige tags b) mein Model, das zwei ways für jede Fahrtrichtung vorsieht und einen daten-way dazwischen, der von einem neuen Renderer nicht gerendert wird, aber von einem älteren Renderer genutzt wird, weil dieser die anderen Fahrrichtungsways nicht nutzen kann. Bei mehreren Fahrspuren pro Richtung könnte dann auch da der lanes-tag eingesetzt werden c) mein Model mit genmutzter Möglichkeit neben dem daten-way links und rechts davon mehrere Fahrspuren-ways zu zeichnen, wenn es denn nötig ist, wie z.b. an komplizierten Kreuzungen, oder wenn es verschiedene maxspeed-tags auf jeder Fahrspur gibt, etc. Dann gibt es da halt kein lanes=2, sondern eben zwei ways, die dann zusammen mit dem Rest in einer Gruppe die Straße im gesamten darstellen. Der Vorteil ist die Flexibilität ohne dabei neue Redundanz zu bilden, gleichzeitig ist das ganze abwärtskompatibel. Das ist sogar der wichtigste Punkt an der ganzen Geschichte. viele verschiedene Moeglichkeiten, die dann auch jeder Renderer und Editor beruecksichtigen muesste. DAS wird komplex. gut, auf a) kann man erst mal wegen der abwaertskompatibilitaet nicht verzichten, aber c) wuerde ich vermeiden... Hmm, jetzt faellt mir noch was ein: Eigentlich wuerden in deinem Modell zwei ways fuer die beiden Seiten reichen. eigentlich ja - doch ich wollte vermeiden, dass z.B. der name-tag an beiden ways getaggt wird, was wieder zu unnötiger Redundanz führen würde, so wie im Linienbündel-Model, das ich nicht so mag. wer sagt dir, dass die Tags nicht an alle drei ways gehaengt werden? Da diese sowieso in einem uebergeordneten Objekt zusammengefasst werden muessen, kann man doch die allgemeingueltigen Tags gleich da dran haengen; das Einzeichnen des Mittelweges kann man sich dann sparen... Das da dran hängen ist ein Problem, das Du wie lösen würdest? Ich bin gespannt, da ich gerne auf den daten-way verzichten würde. Aber bitte führe jetzt nicht die Relation als Lösung an, den die wollte ich vermeiden. Sonst könnte man gleich beide Fahrtrichtungen mit Relationen erfassen und alle richtungsabhängigen tags da dran pappen. im Prinzip ist das Ganze sowieso nichts anderes als eine Art von Relation. Du hast ein Hauptelement, das fuer das Strassenobjekt selbst steht und sowohl die allgemeinen Tags enthaelt, als auch die ways miteinander verbindet. Dieses Element jetzt auch noch als way separat in die Mitte reinzumalen, ist total ueberfluessig. ... schon klar. Im Prinzip laeuft alles auf das fehlerhafte Drehen eines ways zurueck. Aber warum was neues gross und aufwendig ausarbeiten, wenn man genausogut die Ursache des Uebels anpacken kann? Und wie? wie bereits gesagt: ein way bekommt beim Anlegen eine Richtung, und die bleibt unveraenderlich so wie sie ist. Wenn die Editoren diese Referenzrichtung und das Drehen des Weges gar nicht erst anzeigen/anbieten, dreht die auch keiner. Und wenn sich die Richtung einer Einbahnstraße ändert, oder man überhaupt erst eine taggen möchten, owowohl es vorher keine war? ganz einfach, indem man in der Darstellung der Strasse im Editor diese selektiert, die Eigenschaft Einbahnstrasse waehlt, und dann die Richtung von hier nach da angibt. Der Editor setzt dann automatisch das richtige Tag (irgendwas mit oneway:forward oder oneway:backward, je nachdem wie
Re: [Talk-de] JOSM V3376 Filter
Walter Nordmann schrieb: auf einmal - so mittendrin beim arbeiten/scrollen- sind dann z.b. alles hausnummern und alle pois wieder zu sehen. ich mache mit den postleitzahlen rum und hab ein filter auf admin-bourdaries gesetz und dann noch auf highway=residential. damit möchte ich nur die grenzen und wichtige straßen sehen. und huch, auf einmal ist der schirm wieder bunt. Sowas habe ich bisser nicht gehabt. Ist wohl auch ein schwerwiegenderer Bug als bloß eine falsche Info. Da solltest Du ein Ticket bei JOSM aufmachen ! bis bald colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnikstyle Germanica
Mal am Rande bemerkt: ich finde die Wortwahl Germanica nicht so gelungen. Klingt ein bisschen martialisch finde ich, jedenfalls weckt dieser Betreff bei mir immer unterschwellig den Verdacht, dass ich Nazipropaganda im Emaileingang habe, bis ich sehe, dass das OSM ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapquest OSM Karte
Am 09.07.2010 14:25, schrieb Sven Geggus: die Mapquest OSM Karte gefällt mir eigentlich ganz gut (mal abgesehen vond en fehlenden tracks): http://open.mapquest.co.uk/ Naja, bei mir findet er gar nix, weder Adressen noch Routen. Der Maßstab wird nur aktualisiert, wenn man über die Buttons zoomt, nicht aber wenn man das mittlere Mausrad dazu nutzt. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnikstyle Germanica
Am 27.07.2010 00:21, schrieb M∡rtin Koppenhoefer: Mal am Rande bemerkt: ich finde die Wortwahl Germanica nicht so gelungen. Klingt ein bisschen martialisch finde ich, jedenfalls weckt dieser Betreff bei mir immer unterschwellig den Verdacht, dass ich Nazipropaganda im Emaileingang habe, bis ich sehe, dass das OSM ist. Sorry, aber da musst Du Dich bei den Kartographen bei der Firma Palmtop beschwerden, die kamen mit den Begriffen wie Belgica, Brittanica, Germanica und Deuteranopia um die Ecke. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Travelling salesman-Router auf OSM-Datenbasis
Gibt's da was? Oder bekommt man OSM-Daten in Microsoft MapPoint? Das beherrscht das schließlich... -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrere Tagging fragen:
Andreas Neumann glaubte zu wissen: 2. Beim Wandern hab ich immer wieder eine Furt für Fußgänger[2] entdeckt. Sprich es gibt eine Stelle, wo der Wanderweg durch Gewässer geht (meist nur Abwasser- oder Bachgraben). Diese sind dann nach stärkeren Regen nicht mehr trockenen Fußes überquerbar. Bisher habe ich für diese Stellen immer highway=ford verwendet. Jedoch sieht das spätestens auf der Karte etwas seltsam aus. Daher die Frage, ob es so richtig ist, oder ob der Tag nur für Furte für Fahrzeuge gedacht ist... Du kannst die Breite dazuschreiben. Generell gibt es aber keinen Grund, etwas anders als vorgesehen zu taggen, nur weil es auf *einer* Karte seltsam aussieht. Es gibt viele Karten, die von verschiedenen Renderern mit verschiedenen Regeln erstellt werden. Wenn die Daten richtig in der Datenbank sind, gibt es auch später mal die Chance, daß es mehrere Karten richtig anzeigen. flo -- Wokopostings sind O.K. Sparen Morgens den Kaffee. [WoKo in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Deutschlandviewer auf onmaps.de
Moin, ich wollte einmal auf den Deutschlandviewer der Firma geoGLIS oHG hinweisen. Er ist unter der URL http://onmaps.de/st/deutschland.php erreichbar. Die Karten auf ATKIS-Basis enthalten das Straßennetz bis zu Feld- und Fußwegen, Höhenlinien, Gemeindegrenzen, Wassergräben und Knicks. Natürlich darf man die Daten nicht für OSM übernehmen, aber um zu schauen, wo uns noch Wege fehlen, oder um zu verifizieren, dass eine Gemeindegrenze mit dem Bachverlauf übereinstimmt, ist der Viewer recht nützlich. Die Daten sind allerdings etwas veraltet. Ich schätze, dass Veränderungen der letzten zwei Jahre fehlen. Bei Feldwegen kann man nicht zwischen unserem grade1 und einer zugewachsenen Waldschneise unterscheiden. Militär- und andere Sperrgebiete sind nicht dargestellt. Einige kleine Fehler, die auf mangelnder Ortskenntnis der Datenerfasser beruhen, habe ich auch schon gefunden. :-) Gruß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Probleme mit Seen und Inseln
Hallo Christoph, beim Ansehen der Seen sind mir mögliche Fehlerquellen aufgefallen. Da der outer-Ring an sich nichts darstellt, sollte er keine Tags haben. natural=water gehört an das Multipolygon, da dieses die Wasserfläche (outer minus alle inner) darstellt (http://wiki.openstreetmap.org/wiki/Relation:multipolygon#Usage). Dies ist auch bei Orsasjön der Fall. Die inner sind doppelt getaggt mit natural=land und place=island. Beim Orsasjön sind die Inseln gar nicht oder nur mit naturland=land markiert. Ich bevorzuge place, da es island und islet gibt. Viel Spaß beim Kartografieren Willi -Original Message- From: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] On Behalf Of Christoph Matthei Sent: Montag, 26. Juli 2010 17:52 To: Talk-de@openstreetmap.org Subject: [Talk-de] Probleme mit Seen und Inseln Hallo, ich habe ein Problem mit dem Siljan-See in Schweden; auf der schwedischen Mailingliste konnte mir keiner helfen. Es geht um den See Siljan http://www.openstreetmap.org/browse/relation/5336 Der benachbarte See Orsasjön könnte als Vergleich dienen, denn dort funktioniert alles http://www.openstreetmap.org/browse/relation/15073 Das Problem: Während bei mapnik und osmarender alles korrekt dargestellt wird, verschwinden bei einigen Renderern die Inseln und/oder das Wasser. Zum Beispiel: 1) http://www.opencyclemap.org/?zoom=11lat=60.94lon=14.52454layers=B000 Hier verschwinden Wasser und Inseln. 2) http://maps.cloudmade.com/?lat=60.872329lng=14.799957zoom=10styleId=2400; opened_tab=0 Hier werden die Inseln nicht angezeigt. 3) http://hikebikemap.de/?zoom=14lat=60.91006lon=14.58866layers=BT Hier verschwinden die Inseln bei bestimmten Zoom-Leveln. 4) Wenn ich das Gebiet in Kosmos lade, wird bei bestimmten Rendering-Rules gar keine Karte angezeigt und bei den Standard-Rules alles normal (sobald der Siljan in den Daten enthalten ist. Kann mir irgendjemand weiterhelfen? Oder bin ich nur auf ein Problem unterschiedlicher Datenbestände gestoßen (die opencyclemap hat ja nicht immer den aktuellsten Datenbestand)? Oder auf was kommt es bei den Rendering-Rules an? Ich kann einfach keinen Unterschied im Datenbestand zwischen den beiden Seen sehen. Vielen Dank schon mal, Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie amenity=parking richtig mappen/verbinden?
Wo Weg und Fläche sich kreuzen ist meines Erachtens wie bei pedestrian-area ein gemeinsamer Knoten zu zeichnen: Be sure to connect the pedestrian-area at all intersections with the streets. http://wiki.openstreetmap.org/wiki/Key:area. Willi -Original Message- From: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] On Behalf Of Pascal Neis Sent: Dienstag, 27. Juli 2010 02:49 To: Openstreetmap allgemeines in Deutsch Subject: [Talk-de] Wie amenity=parking richtig mappen/verbinden? Hi, habe mir die letzten Tage unterschiedlich gemappte Parkplätze (amenity=parking) angeschaut. Dabei sind mir immer wieder etwas unterschiedliche Vorgehensweisen aufgefallen Manche verbinden den Zufahrtsweg mit dem Außenring der Parkfläche, siehe: http://osm.org/go/0Den6M5qV-- Andere zeichnen wiederum einen Weg auf die Parkplatzfläche ohne das aber wiederum ein gemeinsame Node zwischen Weg und Fläche vorhanden ist: http://osm.org/go/0dep...@e-- Und eine weitere Variante wäre das Einzeichnen aller möglichen Wege auf dem Parkplatz: http://osm.org/go/0DepD4hLW-- Für ein mögliches Routing vom oder evtl. auch auf den Parkplatz wäre es schon gut wenn die Fläche irgendwie mit dem Weg, der von der Fläche weg geht, auch verbunden oder sonst irgendwie an das restliche Straßennetz angebunden wäre, oder wie seht ihr das? viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenverzeichnis Raum Segeberg - Ka ltenkirchen - Noderstedt
Moin ! für den Norden gibt es wieder etwas zu tun - über 70 Straßenverzeichnisse konnten mit Hilfe von SvenA (Danke dafür) bereitgestellt werden. http://wiki.openstreetmap.org/wiki/Kreis_Segeberg/Stra%C3%9Fen Anmerkung: bei einigen kleinen Orten kann es etwas schwierig mit der Zuordnung sein - weitere Infos werde ich die nächsten Tage noch im Wiki ergänzen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Travelling salesman-Router auf OSM-Datenbasis
Johann H. Addicks schrieb: [subject Travelling salesman-Router auf OSM-Datenbasis] Gibt's da was? Die Frage ist eigenartig formuliert. Oder bekommt man OSM-Daten in Microsoft MapPoint? Das beherrscht das schließlich... Das Programm gibts, OSM-Daten gibts. Einen Wiki-Eintrag gibt es auch: http://wiki.openstreetmap.org/wiki/Traveling_salesman hth malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
