Re: [Talk-de] Weiterer Routingfehler Cloudmade
Hi Chris, Am Sun, 23 May 2010 21:16:35 +0200 hat Chris66 chris66...@gmx.de geschrieben: access=delivery wird nicht beachtet: http://maps.cloudmade.com/?lat=52.102386lng=8.71881zoom=17directions=52.103836,8.720355,52.10108,8.717350travel=carstyleId=997opened_tab=1 ...Leider habe ich nicht drauf geachtet wie die Beschilderung an der Stelle (Raststätte Herford) ist, vermutlich Zeichen 250 + Lieferverkehr frei. da steht Zeichen 250 + Anlieferung und Betriebsdienst der Autobahn frei (oder so ähnlich, hab kein Foto zur Hand, bin aber gerade eben dran vorbeigefahren - unten auf der secondary-Straße natürlich und nicht auf dem Service-Way ;) ) - daher erschien mir für diese Stelle access=delivery angemessen. Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM städtisch ausgelegt. Land brauc ht den cyclefootway
Am Sun, 16 May 2010 14:01:28 +0200 hat Florian Gross usenet-spam-genausoguel...@grossing.de geschrieben: Hier in der Gegend scheinen die Blauschilder (auch von der Polizei) eher als Fahrrad frei angesehen zu werden und werden auch so verwendet. genau, wobei ich die als Radfahrer angenehmer finde als Fußweg+Radfahrer frei, dann ist man rechtlich gesehen nicht nur ein Gast ;-) Andererseits verbietet man mit den Fuß-/Radweg-Schildern (im Gegensatz zu gar keinen Schildern) die Nutzung für Mopeds etc., die da sicher auch gerne langfahren würden (bzw. deren Fahrer). Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] source:maxspeed=DE:urban
Hi Tirkon, Am Thu, 13 May 2010 10:10:20 +0200 hat Tirkon tirko...@yahoo.de geschrieben: Dazu habe ich eine Frage: Hat es einen besonderen Sinn, dass man in source:maxspeed=DE:urban ausgerechnet Doppelpunkte verwendet oder hätte man genau so gut source_maxspeed=DE_urban schreiben können? ein Unterstrich dient meistens als Ersatz für das Leerzeichen, z. B. barrier=cycle_barrier oder service=parking_aisle. Durch den Doppelpunkt sollen Namensräume erzeugt/abgebildet werden, d. h. Werte/Schlüssel, die ein Thema bilden (im Beispiel source, also die Quelle der Daten). Da es für mehrere Tags eine Quellenangabe geben kann, wird dann mit dem Doppelpunkt der jeweilige Tag ergänzt und man erhält source:maxspeed oder source:maxheight etc. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wayparts, Linienbündel etc.
Hi! Am Thu, 15 Apr 2010 15:30:39 +0200 hat Gerry Light gerrylight...@googlemail.com geschrieben: Ich hatte was von Wayparts, Linienbündel, Lane bzw. Lanegroups gelesen. hier wäre auch noch der Area-Ansatz [1] von Martin zu nennen, der ebenfalls erst in letzter Zeit erstellt wurde, allerdings von der anderen Seite an die Problematik geht. Wird davon schon was direkt von den Editoren bzw. den Renderern unterstützt? Es gibt ein Wayparts-Plugin zur Visualisierung für eine altejosm-Version (2447), d.h. man muß eine weitere Instanz parallelbetreiben. Das erschwert die Sache zusätzlich. (@Nils: Das ist kein Vorwurf, ich kann mir gut vorstellen, dass die Plugin-Pflege zeitaufwändig ist). vielleicht eine kurze Erklärung dazu: (ich fühle mich keineswegs auf den Schlips getreten oder so :) ) leider wurden kurz nach der ersten (Test-)Version des Plugins einige Änderungen an der internen Datenhaltung von JOSM und den Darstellungssachen geändert. Da hatte ich leider nicht die Zeit, das im Plugin nachzuziehen. Aber im Moment gibt die Zeit wieder etwas mehr her, sodass ich mit etwas Glück wieder daran weitermachen kann; oder auch noch mal ganz neu - das hilft manchmal besser ;) Alles in allem ein Henne-Ei-Problem. Leider. so ist es. Angedacht habe ich auf jeden Fall einen Fahrspur-/Waypart-Editor, mit dem man sich die Spuren zusammenklicken kann. Aber das kann und wird noch dauern... Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Josm plugin wayparts
Hi zusammen! Am Wed, 07 Apr 2010 18:57:13 +0200 hat Sebastian Klein basti...@googlemail.com geschrieben: Das wayparts plugin funktioniert nicht mehr mit der aktuellen Josm Version und wird anscheinend nicht mehr weiterentwickelt. Damit macht es wohl keinen Sinn, es in die offizielle Liste mit aufzunehmen. korrekt, mit der aktuellen Version funktioniert es nicht mehr. Seinerzeit hat es mit der Version 2447 funktioniert, ich hatte die hier noch abgespeichert: http://www.ömmes.de/osm/josm-snapshot-2447.jar Damit sollte das Plugin laufen. Eventuell muss es noch in der preferences-Datei von JOSM bei plugins=... ergänzt werden, damit es geladen wird. Ich habe schon noch vor, das ganze weiterzuentwickeln (oder vielleicht noch mal neu anfangen? *g), allerdings hat die Zeit in den vergangenen Monaten mal wieder einen Strich durch die Rechnung gemacht... Da das ganze bisher eher ein Test war, gibts das Plugin auch (noch) nicht in der offiziellen Liste. Ich freue mich aber auf jeden Fall auf Kommentare jeglicher Art dazu! Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund
Hi! Am Wed, 31 Mar 2010 17:01:37 +0200 hat qbert biker qbe...@gmx.de geschrieben: Dazu nochmal das klassische Gegenbeispiel, bei dem die Linienbuendel nicht wirklich gut funktionieren: Die Doppellinie, die nur von einer Spur zur anderen gequert werden kann. Das laesst sich auf den Graphen nicht abbilden. Mit dem Modell der Wayparts http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts ginge es, wenn man ein Tag festlegt, dass den Divider nicht nur crossable, sondern z.B. outside- crossable (von der beschreibenden Spur weg) bezeichnet. da das ganze Modell bisher ohnehin nur ein Ansatz ist, kann man gerne weitere Dinge dort definieren. Wobei ich mir das für die einseitig gestrichelte Linie so gedacht hatte: | part1 || part2 | |^ | || | v || || part1:divider=line part2:divider=dash oder: | || part1 | part2 | part3 | | ^ || ^ | | | || v | | || | | | part1:divider = line part2:divider = line part2:outer_divider = line part3:divider = dash man definiert also als (outer_)divider nur den Strich, der für die jeweilige Spur gilt und nicht, was /zwischen/ den 2 Spuren ist. Bei einer einfachen Linie reicht da halt die Angabe bei einer Spur. Das ist dann auf die Wayparts abgebildet, aber der Graph ist gnadenlos und interessiert sich nur wenig dafuer. Die Kuerzestwegsuche ueber den Graphen kennt keine Links, ueber deren Laenge ein Austausch, egal ob in eine oder in beide Richtungen, passieren kann. das ist ja das gute: Dem Routing sind die Spuren egal und es kann auf den normalen Ways stattfinden. Ein Fahrspurassistent mit Visualisierung, wo man sich einordnen soll, könnte das aus den Wayparts auslesen. hier nochmal das Beispiel (vielleicht war es schon zu spät am Abend... :-) ) xx k r\ bb k \ -r k \/ \ ppp / / x = normale Fahrbahn r = Rechtsabbiegespur b = Busspur, überqueren nicht erlaubt p = Parkplätze k = Kreuzung das ließe sich dann auch ganz gut mit Wayparts lösen: x ist der normale Way und part1 r ist part3 mit part3:direction_hint=right p ist part2=parking (kann/sollte ggf. auch herkömmlich (Fläche oder Node) als Parkplatz eingetragen sein) b ist part2, part2:access=no;part1:bus=yes (falls die Busspur erst hinter den Parkplätzen anfängt, ansonsten muss man da versch. Nummern vergeben) k ist nur mit x verbunden. Für die einzelnen (way)parts setzt man dann noch die passenden Start- und Endnodes auf den way. Ansonsten zum Thema Straßenläche vs. Linie: Ich sehe es zwar nicht als notwendig an, um alle Straßen eine (zusätzliche!) Fläche zu malen, aber stören würde es mich auch nicht. An signifikanten Stellen kann es durchaus sinvoll sein (nicht fürs Routing, aber ansonsten). Ganz einfaches, wenn auch zu vernachlässigendes Beispiel: http://maps.google.de/?ie=UTF8ll=52.098071,8.672494spn=0.001081,0.00217t=kz=19 Da ist die Straßenfläche erheblich größer als die Fahrspuren. (Die Leute kamen mit so viel Fläche nicht klar, drum steht dort auf der weißen Linie nun zusätzlich so eine Plastikabsperrung ;) Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Wegweiserinfos (Re: Details mappen in Dortmund)
Am Thu, 25 Mar 2010 12:26:51 +0100 hat Ana Luisa Paldos Garcia analuisapaldosgar...@googlemail.com geschrieben: Aber seid schon mal vorgewart, ich musste auch erst lernen, dass die Beschilderung an Autobahnen an der gleichen Ausfahrt je nach Richtung teilweise variieren kann. das kommt wahrscheinlich sogar recht häufig vor: Wenn eine Stadt in der Mitte zwischen 2 (oder mehr) Ausfahrten liegt, nimmst du aus der einen Richtung die eine, aus der anderen die andere, einfach weil es näher ist. Sogar die Schilder wissen das oft ;) und bieten dir je nach Richtung die Stadt nur an der jeweils ersten Ausfahrt an. Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von Wegweiserinfos (Re: Details mappen in Dortmund)
Am Thu, 25 Mar 2010 09:35:07 +0100 hat Bernd Wurst be...@bwurst.org geschrieben: Am Donnerstag 25 März 2010 09:05:08 schrieb Chris-Hein Lunkhusen: destination=Karlsruhe an die Abbiegespur? Wäre eine Möglichkeit. Nutzt das aktuell schon jemand? (Ich kann noch immer nicht glauben, dass bisher niemand diese Information taggen will.) Wenn keine abweichenden Vorschläge kommen, würde ich das probeweise mal umsetzen. Bei meinem Ansatz zur Spurerfassung (als Relation) [1] hatte ich für jede Spur vorgesehen, dass man angeben kann, auf welche andere Spur diese führt (z. B. linke Spur geradeaus, die beiden rechten Spuren zweigen ab auf den zugehörigen motorway_link). Da könnte man natürlich auch ein destination=* an die Spur hängen, hab ich auf der Wiki-Seite gerade ergänzt. [1] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Sun, 21 Mar 2010 20:48:11 +0100 hat Guenther Meyer d@sordidmusic.com geschrieben: Am Sonntag 21 März 2010 17:35:03 schrieb Helder Aguiar: definition: einrichtungen, deren primaerer zweck die lehre ist. key: education +1 den rest muesste man noch ausmachen. meinetwegen kann man dann durchaus education=school fuer die klassischen schulen nehmen... eine genauere klassifizierung wie art des traegers, der finanzierung, anerkennung, moegliche abschluesse, ... macht man dann durch zusatztags. ebenfalls +1 Was aus amenity=school wird, wird wohl die Praxis zeigen. Beziehungsweise, wenn sich education=* durchgesetzen sollte, könnte man es umändern oder auch jetzt schon ergänzen. Jedenfalls geht das alte Tag durch das neue so nicht kaputt. Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Sun, 14 Mar 2010 22:57:56 +0100 hat Florian Gross usenet-spam-genausoguel...@grossing.de geschrieben: Nils Heuermann glaubte zu wissen: amenity=business - bitte nicht wörtlich nehmen. Es ist ein Unternehmen wie auch ein Bäcker. Da gibt es für Geschäfte ein shop=*, weil amenity für (mehr oder weniger) wichtige spezielle Einrichtungen vorgesehen ist. Eine Schule ist in meinen Augen eine wichtige Einrichtung, eine Fahrschule aber nicht. Das ist einfach ein Betrieb, den jemand aufgemacht hat. Was ist mit Privatschulen? je nachdem, was sie anbieten. In der Regel sind es z. B. Gymnasien, also amenity = school Daher finde ich auch amenity=driving_school gar nicht sooo sinnvoll. Man Bräuchte also sowas wie business=* oder wie hier [1] vorgeschlagen service=* Und nachher ist jede Schule unter was anderem eingeordnet? Hauptschule unter school[1], Fahrschule[2] unter business, Tanzschule[3] unter amenity? Zur einen wird man gezwungen, zur nächsten muß man um den Führerschein zu bekommen und die dritte kann richtig Spaß machen. jein, zumindest sollte man die Hauptschule von den anderen beiden trennen. Eine Tanzschule kannste auch als sport=dancing taggen, wenn du Lust hast... Man muss ja nicht für alle ...schulen neue Tags haben. Aber die Unterscheidung zw. allgemeinbildenden Schulen und sonstigen Angeboten, etwas zu lernen, finde ich sehr sinnvoll. Zumal eben schon das Tagging als amenity=school nur für erstere verwendet wird. (Zumindest ist mir das noch nicht anders über den Weg gelaufen.) Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Mon, 15 Mar 2010 08:56:56 +0100 hat Guenther Meyer d@sordidmusic.com geschrieben: Am Montag 15 März 2010 08:07:13 schrieb Norbert Hoffmann: Guenther Meyer wrote: bei den adressen hat's komischerweise funktioniert: da haben sich ein paar leute zusammengesetzt und ein klares schema ausgearbeitet, und es wird benutzt. beim oepnv-schema ist es glaub ich aehnlich... In diesen Fällen haben die Macher auch OSM verstanden und aufgepasst, dass nicht an der Bedeutung von bestehenden Tags herumgeändert wurde. wenn das dein einziges problem ist, nimmt man einfach was ganz neues, wie z.B. education=... das ist ja im Prinzip auch mein Vorschlag :) man hebt nicht die (bisherige) Bedeutung auf und kann sogar zwischen den normalen Schulen und anderen Lehrangeboten unterscheiden. Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Busspuren taggen (war: Straßenbah nen, Straßen, Busse)
Hi! komme in der Woche leider kaum zum Lesen der Liste... aber nun ist ja Wochenende :) Am Thu, 18 Mar 2010 13:00:18 +0100 hat Claudius claudiu...@gmx.de geschrieben: Weil ihr grad so schön im Diskutieren seid: Wie würdet ihr denn seperate Busspuren taggen, die aber in meinen Augen nicht richtig baulich, sondern durch mittels Plaste-Ständern getrennt sind: http://wiki.openstreetmap.org/wiki/File:MalekAbad.JPG http://wiki.openstreetmap.org/wiki/File:Bus_Guaideways.JPG Ein Anwendungsfall für wayparts-Relation [1]? Wie würde Ömmes denn sowas taggen? Mit dem Wayparts-Ansatz würde das auf jeden Fall gehen, dann hätte man den Way ganz normal als highway = primary (etc.) oneway = yes (im Falle der obigen Fotos) und eine Relation mit type = wayparts parts = 3 part3:access = psv (oder part3:access=no, part3:psv=yes) part3:divider = plaste_ständer (wie immer man das auch übersetzt) part3:divider:crossable = foot,bicycle (falls nötig/sinnvoll) Gruß, Nils [1] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Sun, 14 Mar 2010 04:09:10 +0100 hat Florian Gross usenet-spam-genausoguel...@grossing.de geschrieben: Ähnliches gilt auch für Kliniken: eine Tierklinkik ist nun mal kein hospital sonder höchstens ein animal_hospital. Eine Ampel oder ein Stopschild ist auch keine Straße oder ein Weg, warum wird das trotzdem mit highway= getaggt? Eben genau darum, warum amenity=school für *Schulen* ist - es hat sich (anfänglich) so für diesen Zweck durchgesetzt. (Und ist für mich auch die logische Bedeutung, anders als bei highway=traffic_signals). Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Sun, 14 Mar 2010 08:00:49 +0100 hat Florian Gross usenet-spam-genausoguel...@grossing.de geschrieben: Torsten Leistikow glaubte zu wissen: Und genau das ist bei dem aktuellen Vorschlag nicht gegeben. Es gibt hier zwar genug Leute, die argumentieren, dass eine Fahrschule ja auch eine Art Schule sei. Dass das aber zum allgemeinen Verstaendnis von Schule nicht passt, ... Was soll denn eine Fahrschule/Tanzschule usw. denn sein, wenn nicht eine Schule? Ein Hot-Dog- Stand? amenity=business - bitte nicht wörtlich nehmen. Es ist ein Unternehmen wie auch ein Bäcker. Da gibt es für Geschäfte ein shop=*, weil amenity für (mehr oder weniger) wichtige spezielle Einrichtungen vorgesehen ist. Eine Schule ist in meinen Augen eine wichtige Einrichtung, eine Fahrschule aber nicht. Das ist einfach ein Betrieb, den jemand aufgemacht hat. Daher finde ich auch amenity=driving_school gar nicht sooo sinnvoll. Man Bräuchte also sowas wie business=* oder wie hier [1] vorgeschlagen service=* Gruß, Nils [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Service_business ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Sun, 14 Mar 2010 11:23:59 +0100 hat Falk Zscheile falk.zsche...@googlemail.com geschrieben: Am 14. März 2010 10:58 schrieb Torsten Leistikow de_m...@gmx.de: Der entscheidende Punkt ist: Ein Fahrschule ist nicht das, was wir z.Z. mit amenity=school in OSM meinen. Die Frage ist doch, ob der status quo wirklich so gut ist, das er es Wert ist an ihm festzuhalten, obwohl man mittlerweile erkannt hat, das ein hierarchisches Tagging gegenüber dem am Einzelfall orientierten Vorteile bringt. ... Kategoriebildung mit hierarchischem Tagging sollte kein Selbstzweck sein, sondern handfeste Vorteile bieten. Kategorien mit entsprechender Verfeinerung in einem weiteren Tag sind natürlich eine vernünftige Sache. Und funktioniert auch bei Schulen. Nur finde ich, dass eine Fahrschule und eine Grundschule nun mal etwas grundlegend anderes sind. Daher sollte man amenity=school so belassen wie es ist, damit man ggf. Grund-, Realschule etc. ergänzen kann. Und für Gewerbe wie Fahrschulen eben was anderes/neues. Da kann man dann gerne alle *-schulen drunter zusammenfassen. Wie wir festgestelt haben, gibt es auch Grenzfälle; da wird man jedoch sowieso nicht drumrumkommen. Aber für eindeutige Sachen wie Grundschule - Fahrschule ist es doch jedem Mapper möglich, zu entscheiden, ob es amenity=school oder [noch zu definieren]=driving(_school) ist. Ich klink mich jetzt mal aus; die an der Diskussion bereits Beteiligten wissen ja, dass es diese zwei Sichtweisen für Schulen gibt und wir haben nun einige Argumente für das eine und andere gebracht. Wir werden uns nur weiter im Kreis drehen, wenn immer nur die selben Leute antworten :) Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Fri, 12 Mar 2010 23:01:06 +0100 hat Simon Kokolakis simon.kokola...@gmx.de geschrieben: Nils Heuermann schrieb: amenity=school school=driving halte ich für unpassend, da eine Fahrschule nun mal keine Schule im herkömmlichen Sinne ist, auch wenn sie so heißt. Sonst könnte/müsste man auch den Segelclub, bei dem es eine Segelschule gibt, als amenity=school taggen; oder ein Tauchschule, Surfschule, Yogaschule, ... Was definierst du denn als Schule im herkömmlichen Sinne?... Wo soll man deines Erachtens die Grenze setzen? Stichwort Volkshochschule, private Förderschulen, Internate in freier Trägerschaft. Die Grenze ist m.E. fließend. amenity=school sehe ich als allgemeinbildende Schule. Eben alles, wo man fürs Leben lernt: Grundschule, weiterführende Schulen, aber auch Internate (falls es da nicht sowieso einen eigenen Tag gibt) oder private Schulen, die Allgemeinwissen vermitteln. Man muss ja nicht für alles andere ein eigenes amenity=xyz_school machen, sondern könnte da evtl. den Typ extra angeben. Wobei man dann auch Sachen, die überhaupt nichts miteinander zu tun haben - außer dass man irgendwas dort lernen kann -, in einen Topf schmeißt; man muss also den Typ ohnehin auswerten, um was sinnvolles rauszubekommen... Auf jeden Fall - wie Ulf bereits schrieb - einen ziemlich eindeutigen Tag nachträglich zu erweitern, ist ungünstig. Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Sat, 13 Mar 2010 22:23:40 +0100 hat Guenther Meyer d@sordidmusic.com geschrieben: Am Samstag 13 März 2010 21:09:41 schrieb Nils Heuermann: amenity=school sehe ich als allgemeinbildende Schule. Eben alles, wo man fürs Leben lernt: Grundschule, weiterführende Schulen, aber auch Internate (falls es da nicht sowieso einen eigenen Tag gibt) oder private Schulen, die Allgemeinwissen vermitteln. - eine fahrschule kann man auch fuers leben brauchen. - in der volkshochschule gibt's auch allgemeinbildung. - weiterfuehrende schulen: berufsschulen, private lehrinstitute, wo ziehst du die grenze? - was ist mit nachhilfeunterricht? zusätzlich könnte man vielleicht noch als Definition hinzunehmen, dass man regelmäßig und über einen längeren Zeitraum dort hingeht. Ja, das ist bei der Volkshochschule auch so, aber da ist der Kurs i. d. R. mittelfristig beendet. Und eine Schule ist nunmal etwas anderes als ein Verein etc., der Nachhilfeunterricht oder andere Lehrangebote durchführt. Aber ich muss dir hier sicher nicht erzählen, was eine *Schule* ist - das weißt du schließlich selber. Nur kann man halt nicht alles, was mit Schule und Lernern *zu tun hat* als Schule in die Karte^W Datenbank eintragen - zumindest nicht mehr jetzt, wo amenity=school schon belegt ist; da schließe ich mit Torstens Mails an. Würde ich den Schulungsraum, in dem hier der Stenoverein Kurse anbietet, ansonsten auch als school taggen? Da lernt man auch was. Eigentlich lernt man doch überall was :) Aber nicht alles ist amenity=school Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrschule
Am Fri, 12 Mar 2010 18:39:57 +0100 hat Simon Kokolakis simon.kokola...@gmx.de geschrieben: amenity=driving_school ich fände ein amenity=school school=driving besser, damit die Werte für amenity nicht ausufern, und das ganze eine überschaubare Struktur behält. halte ich für unpassend, da eine Fahrschule nun mal keine Schule im herkömmlichen Sinne ist, auch wenn sie so heißt. Sonst könnte/müsste man auch den Segelclub, bei dem es eine Segelschule gibt, als amenity=school taggen; oder ein Tauchschule, Surfschule, Yogaschule, ... Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel / Kreuzungsmapping (wa s: skobbler-Update mit OSM ist live)
Hi, Am Fri, 05 Mar 2010 17:08:33 +0100 hat Mirko Küster webmas...@ts-eastrail.de geschrieben: Das Strippenmodell ist für genaues mappen einfach zu dünn. Das reicht für simple Fälle wie Straße von A nach B, versagt aber schon bei so einfachen Fällen wie 2:1 oder einseitige Überholverbote etc. Und wenn es ganz kompliziert wird gehts rätseln los. Aber wenn ich wirklich das umsetzen will was ich sehe, muss ich das auch so beschreiben und darstellen können. Das passt so irgendwie nicht. Auf der einen Seite hätte man am liebesten jegliche Möglichkeit abgedeckt, hat dafür aber nur den Minimalkonses an Darstellungsmöglichkeit. mit den aktuellen Mitteln lässt sich das wohl nur über Relationen lösen... Grundsätzlich gibt es da 2 Möglichkeiten: Man malt die Spuren als mehrere Ways und fasst sie in einer Relation zur Straße zusammen, oder man malt die Straße als einzelnen Way und setzt die Spuren mittels der Relation um. Für die letztere Möglichkeit habe ich mir vor einiger Zeit ein (sicher nicht perfektes) Schema überlegt: http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts Würde mich freuen, wenn das diese Problematik nach vorne treibt - gerne auch mit einem komplett anderen Ansatz. Aber um das Thema wird man irgendwann nicht mehr drumrumkommen. Schönen Abend noch, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am Sun, 28 Feb 2010 14:29:19 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Nils Heuermann w...@oemmes.net wrote: ... Die wayparts beschreiben den Querschnitt der Straße und ggf. spurabhängige Einschränkungen (z. B. Busspur). Der Name und andere allgemeine Eigenschaften (highway, surface, ...) bleiben weiterhin am ganz normalen Way (letztere könnten allerdings für einzelne Spuren überschrieben werden). Das begreife ich irgendwie nicht. In Deinem ganzen Konstrukt finde ich keine Tags für den ganz normalen way, wie beispielsweise name oder ref der Gesamtstraße: http://wiki.openstreetmap.org/wiki/DE:User:%C3%96mmes/Wayparts Und genau das ist es, was mir derzeit einen Zugang zum Grundverständnis dieses Konstruktes verwehrt. Also als *Voraussetzung* für wayparts braucht man erstmal eine Straße/Way. Den kann jeder ganz normal eintragen mit highway, name, ref, maxspeed usw. Als *Ergänzung* kann man dann diesen Weg in eine wayparts-Relation aufnehmen. Dort kann man z. B. sagen, dass dieser Weg 2 normale Fahrstreifen (mit durchgezogener Mittellinie), und in eine Richtung noch einen Fahrradschutzstreifen und eine Busspur hat. Man hätte in diesem Beispiel dann einen Weg mit: [interne ID = 12348765] highway = residential name = Meine Straße maxspeed = 50 und eine Relation mit den Tags: type = wayparts parts:forward = 3 parts:backward = 1 part1:divider = line part2 = cyclelane part3:access = bus und dem Member way = 12348765 Was nicht für einen einzelnen Part überschrieben wurde, wird vom Way genommen. Also ist part1 automatisch highway=residential, hat maxspeed=50 usw. auch part-1 (der in Gegenrichtung) erbt die Eigenschaften des Ways. Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Hallo zusammen, Am Sat, 27 Feb 2010 18:18:09 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Johann H. Addicks addi...@gmx.net wrote: Das Ganze lässt sich mit der durchgezogene-Mittellinien-Relation darstellen ... Geht die durchgezogene Linie an Straßenknoten (Kreuzungen, Abzweigungen) durch, so läuft auch die Relation durch. Ist die durchgezogenen Linie an Straßenknoten unterbrochen, so endet die Relation dort und eine neue beginnt. Dies ist mit den heutigen Mitteln von OSM zu bewerkstelligen. Ich hatte mir letztes Jahr ebenfalls ein paar Gedanken gemacht, wie man Fahrspuren u.ä. erfassen kann und dabei auch die Trenner berücksichtigt (durchgezogene Linie, gestrichelte Linie, Grünstreifen, ...) Im Wiki zu finden unter http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts Die waypart-Relationen bilden im Prinzip deine Idee ab, indem diese mehrere Ways beinhalten können. Zusätzlich kann man die Relation an einem Node eines Ways enden lassen - so muss man nicht für jede Änderung den eigentlich Way trennen. Möchte man allerdings aus Gründen der Übersichtlichkeit der Relations-Zerstückelung durch an Knotenpunkten unterbrochenen Nittellinien entgegen wirken, bräuchte man ein neues Feature in OSM. Dies wären (durchgehende-Mittelinien-) Relationen, welche Knotenpunkte explizit ausschließen können, nämlich dann, wenn die Mittellinie dort unterbrochen ist. Theoretisch kann man es auch jetzt schon lösen, indem man die jeweiligen Nodes in die Relation mit einer entsprechenden Rolle aufnimmt. Wenn man das genau definiert, können es die Programme auch auswerten. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am Sat, 27 Feb 2010 21:37:37 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Nils Heuermann w...@oemmes.net wrote: Theoretisch kann man es auch jetzt schon lösen, indem man die jeweiligen Nodes in die Relation mit einer entsprechenden Rolle aufnimmt. Wenn man das genau definiert, können es die Programme auch auswerten. Ich habe bisher keine Beschreibung von Rolle finden können und weiß daher auch nicht, was das ist. Könntest Du vielleicht einmal nichttechnisch beschreiben, was der Sinn und Zweck einer Rolle ist? Wenn man einer Relation [1] einen Weg oder Punkt (oder auch eine andere Relation) als Mitglied (member) hinzufügt, kann man dem jeweiligen Objekt eine Rolle (role) [2] zuordnen. Zum Beispiel gibt es bei Abbiegebeschränkungen [3] die Rollen from, to und via, um anzugeben, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Hoffe, das war verständlich :) Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Relations [2] http://wiki.openstreetmap.org/wiki/Roles [3] http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung [4] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts#Mitglieder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am Sun, 28 Feb 2010 02:00:57 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Ist eigentlich das Aussschließen von Knotenpunkten aus einer Relation deswegen nicht möglich, weil die Editoren es nicht bereitstellen, oder weil die Datenbank es nicht speichern kann? wie schon gesagt: man kann es (selber) möglich machen. Eine Relation hat erst mal nichts mit einer Straße/Weg zu tun. Es gibt auch Relationen, die nur aus Punkten/Nodes bestehen (hab zwar gerade kein Beispiel...) oder eine Relation, die ausschließlich andere Relationen enthält. Man kann in/mit der Relation also speichern, was man möchte. Daher kann man Ways und Nodes lustig durcheinander reinspeichern, und wenn man in seinem Auswertungsprogramm Nodes mit einer bestimmten Rolle als Ausschluss-Nodes behandelt, ist es kein Problem. Ich sehe das als Anforderung an die auswertende Anwendung. Wayparts sind allerdings ohne speziellen, nahe an der Kartendarstellung arbeitenden grafikartigen Editor für Otto Normalmapper kaum mehr nachvollziehbar. Das ganze ist auch erst mal nur ein Ansatz. Das hat (wahrscheinlich) noch niemand benutzt, außer ich bei meinem Beispiel ;) Auch kann noch kein Programm damit umgehen. Wird Dein Waypart Plugin da Abhilfe schaffen, indem er einen solchen nahe an der Karte arbeitenden Editor bereitstellt? Damit das System funktioniert (vorausgesetzt, die Logik hat keine Macken), braucht man natürlich einen grafischen Editor, mit dem man sich die einzelnen Spuren usw. auf einfache Weise zusammenklicken kann. Da muss noch etwas Programmierarbeit reingesteckt werden :) Gerade in ländlichen Gebieten steht ein Mapper häufig allein vor einem großen Gebiet, so dass er vor Ort die einfachsten Änderungen z.B. Umbenennung der Straße wegen des Vorhandenseins von Wayparts nicht mehr aktualisieren könnte. Das wäre kein Problem. Die wayparts beschreiben den Querschnitt der Straße und ggf. spurabhängige Einschränkungen (z. B. Busspur). Der Name und andere allgemeine Eigenschaften (highway, surface, ...) bleiben weiterhin am ganz normalen Way (letztere könnten allerdings für einzelne Spuren überschrieben werden). Können eigentlich von Radweg und Straße eingeschlossene Eisenbahnlinien auch mit Waypart in die Linienbündelung eingeschlossen werden? Theoretisch ist das möglich. Man sollte allerdings abwägen, ob es in so einem Fall nicht sinnvoller ist, die Dinge als einzelne Wege zu erfassen. Schönen Sonntag noch! Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenname kurz oder lang?
Hallo hy-soft, da muss ich dir leider widersprechen: Am Tue, 02 Feb 2010 21:03:37 +0100 hat hy-soft hy-s...@sha-mash.de geschrieben: So dass ein Schweizer, der Nach D faehrt und nach einer Strasse sucht nix findet, weil er auf seinem Keyboard keine diakritischen Zeichen hat. das ist dann Sache des Programms (im Navi etc.), das bei der Suche zu berücksichtigen, in dem es entsprechende Buchstaben(kombinationen) vernünftig behandelt. Und allen anderen mit nicht deutschen Tastaturen geht es genau so. Das ist IMHO Murks und peinlich fuer ein internationales Projekt. Du möchtest also alle Äs, Ös, Ès oder sonstige nicht ASCII-Zeichen aus der Datenbank verbannen? Das bringt ein internationales Projekt dann definitiv zum Scheitern. Ansonsten zum Thema: Ich bin für die lange Version. Wenn es sowas wie die Rsbtl. Weide ist, sollte man aber auch die Version vom Schild in einem Tag ablegen, damit auch das zugeordnet werden kann. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] interessanter Bug in Straßenlistenaus wertung
Hallo Jonas, wenn man auf den Link in der Liste klickt, sucht Google Maps anscheinend auch nach POIs/Geschäften und findet Städt. Kindergarten Europaplatz - Frieslandring 5, 53844 Troisdorf und fokussiert darauf (was wohl zufällig mit dem gewünschten Europaplatz übereinstimmt). Bei der interaktiven Anzeige wird das über die API abgefragt, und da Google die Straße nicht direkt kennt, wird der Europaring in St. Augustin als Ergebnis vorgeschlagen. Das bekommt man unter anderem auch, wenn man den Link in der Liste klickt und dann das Suchformular von Google noch mal abschickt: Meinten Sie: Europaring, 53757 Sankt Augustin, Rhein-Sieg-Kreis, NRW Liegt also weder an der Straßenlistenauswertung, noch daran, dass Google OSM nicht mag ;) Google kennt die Straße einfach nicht. Viele Grüße, Nils Am Mon, 25 Jan 2010 01:15:53 +0100 hat Jonas Stein n...@jonasstein.de geschrieben: Wenn man auf http://osm.gt.owl.de/Strassenliste/Troisdorf/Status.html sich in dem Absatz Nicht in OSM den Europaplatz in Google Maps anzeigen laesst wird der 'richtige' nahe dem Rotter See gefunden. klickt man jedoch auf Interaktive Anzeige der fehlenden Straßen und dann Alle Straßen anzeigen erhaelt man .. [x] Europaplatz (gefunden in Sankt Augustin) .. Bemerkt Google die OSM Abfrage und liefert andere Daten, oder ist die Abfrage nicht optimal formuliert? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed=DE:Urban
Am Sun, 10 Jan 2010 15:15:36 +0100 hat Martin Koppenhoefer dieterdre...@gmail.com geschrieben: M.E. ist es am einfachsten und transparentesten, die Zahl explizit zu mappen und mit einem Zusatztag zu erklären, dass es ein implizites Limit ist. +1 Ob man damit dann (oder auch nicht oder nur praktisch, aber nicht semantisch schön) feststellen kann, dass man sich auch innerorts befindet ... ist m.E. nicht soo relevant. das sollte wohl möglich sein. Und auch wenn die Geschwindigkeit dort durch anderes (30-Zone, 70-Schild, ...) geändert ist, sollte man innerorts mittaggen. Aber dass man möglichst alles (relevante) taggen sollte, wenn man ohnehin gerade dabei ist, ist ja auch nichts Neues ;-) Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed=DE:Urban
Am Wed, 06 Jan 2010 21:37:04 +0100 hat Guenther Meyer d@sordidmusic.com geschrieben: Am Mittwoch 06 Januar 2010 21:10:36 schrieb Mirko Küster: Eine geschlossene Ortschaft die ja mit DE:urban getaggt werden soll wo aber nunmal 30 Zonen keine Seltenheit sind, die aber wiederum mit DE:speed:30 getaggt werden sollen, Da geht nur entweder oder, oder ich muss wieder eine Krücke wie DE:urban;DE:speed:30 bauen. wieso ist das eine kruecke? der strichpunkt ist das uebliche trennzeichen, um einem attribut mehrere eigenschaften zuzuweisen. die strasse ist nunmal sowohl innerorts als auch in einer 30-zone. der auswertende nimmt sich das was er braucht. wenn's z.B. um die geschwindigkeit geht, eben die restriktivere, also 30. +1 aber maxspeed=30 sollte man natürlich auch setzen, dafür ist das Zone 30-Schild ja schließlich da... Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung, Update
Hallo Hubert, hab heute noch ein wenig mit dem Programm rumgespielt jetzt hab ichs mir auch angeguckt. Sieht hübsch aus :) Vom Tagging her ist es sehr simpel und nutzt auch keinen neuen Zaubereien. Für tiefgehendere Informationen zu einzelnen Spuren bräuchte man dann natürlich eine ganze Latte an Tags am Way... http://img214.imageshack.us/img214/2618/bosmcrossing2.png Zu beachten wäre noch, dass wenn eine Spur im normalen Straßenverlauf wegfällt, dies i. d. R. die linke ist. Im Beispiel z. B. die von Nordwest kommenden 2 Spuren, die sich auf 1 verringern. Auch dies ist nichts Neues für dich: Auf Straßen mit Gegenverkehr, also die nicht oneway sind, gibt es z. B. die wechselnden 2+1-Straßen oder unterschiedlichste Abbiegespuren an Kreuzungen. Da kanns schnell unübersichtlich werden und nur mit lanes=x kommt man nicht weiter. Hast du dir dazu weitere Gedanken gemacht? Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung, Update
Am Sat, 02 Jan 2010 18:19:08 +0100 hat Martin Koppenhoefer dieterdre...@gmail.com geschrieben: http://img214.imageshack.us/img214/2618/bosmcrossing2.png Etwas merkwürdig der südliche Teil der durchgehenden horizontalen Autobahn: ist da gerade Baustelle, oder warum hat die z.T. nur eine Spur? das ist nur eine Bundesstraße (B 239). Nordwestlich der Autobahn ist sie vor einigen Jahren ausgebaut worden (trunk, autobahnähnlich mit 2 Spuren je Richtung), nach Südosten ist es eine normale 2-spurige Straße (primary, ist im Screenshot nicht mehr zu sehen). Daher kommen in dem Kreuz Spuren hinzu bzw. fallen weg. Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wirtschaftswege - access=no
Guten Morgen! Am Thu, 31 Dec 2009 09:50:34 +0100 hat Frederik Ramm frede...@remote.org geschrieben: Mirko Küster wrote: Fahrradweg aka Cycleway brauchst du garnicht versuchen, das überlebt ohne 237 oder 240 nicht lange. Ich kenne eine ganze Anzahl von highway=cycleway, die ohne diese Beschilderung seit Jahren existieren. Scheint also regional unterschiedlich zu sein. das ist wieder das Problem, dass man mit highway=* nicht mehrere Sachen gleichzeitig ausdrücken kann. Wie bei den Autos gibt es das Problem mit Bedeutung und Beschaffenheit. Einem Radfernweg könnte man von der Bedeutung einen Status wie primary oder secondary zusprechen (für Fahrräder halt); ob das dann ein 3 m breiter asphaltierter Weg oder ein bei Regen zugematschter Pfad ist, ist die andere Sache. Hinzu kommt dann noch das dritte Problem, also sogar noch eins mehr als bei normalen Straßen: Ist der Weg mit o. g. Schildern gekennzeichnet oder nicht? Muss/darf ich ihn also benutzen oder ist es einfach nur ein schöner Weg, auf dem (hauptsächlich) Fahrrad gefahren wird? Und letzteres gibt es oft genug... Man hat natürlich noch die Möglichkeit, für ausgeschilderte Radrouten/Radfernwege eine Relation anzulegen. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM ein Datensammler oder eine Karte f ür jedermann
Hallo Lothar, Am Thu, 24 Dec 2009 11:43:47 +0100 hat Lothar Emmerich l.emmer...@t-online.de geschrieben: Meines Erachtens ist OSM bis dato ein reiner Datensammler. Es gibt auch in Deutschland noch vieles zu sammeln. nicht OSM sammelt die Daten, die Mapper machen es ;) Und wie du schon sagst: langweilig wird uns nicht werden... Bei der Darstellung der Daten mangelt es noch gewaltig. Z.B.: - Wie stelle ich einen Hügel dar und wie benenn ich ihn derart, dass er in div. Zommstufen größengerecht benannt wird. Das ist eher eine Frage der Darstellung als des Einzeichnens/Benennens (wir mappen nicht für die Renderer). Ich weiß jetzt nicht genau, wie das Tagging bei Bergen ist, da gibts i. d. R. den Gipfel [1], der die Höhe und den Namen bekommt. Ob man einen Umriss mappen kann/sollte, kann ich nicht sagen. - Wie werden Wege parallel zu Straßen in OSM dargestellt, ohne dass sie durch die zeichnerische Breite der Darstellung verschluckt werden. hier wäre mal wieder bei der Frage, ob man Radwege an der Straße etc. als einzelne Wege oder Flächen einträgt oder versucht, sie auf einem Weg mit mehreren errechneten Spuren abzubilden. Dazu gibt es verschiedene Ansätze: [2] [3] [4] (weitere Links auf den Seiten) Das waren jetzt 2 spezifische Dinge, die du angesprochen hast... Wenn ich mir die Karten TOP 50, TOP 10 etc. anschaue differenzieren die Details ...allgemein muss man natürlich beachten, dass die Karten, die derzeit aus den OSM-Daten erstellt werden, komplett automatisch generiert werden. Bei normalen Topo-Karten kann man hingegen davon ausgehen, dass diese redaktionell (nach)bearbeitet wurden. Da kann man dann den Namen eines Gebirges so über den Höhenzug legen, dass es vernünftig ist, oder die Straßen etwas zurechtrücken, dass sie passend über- oder nebeneinander liegen. Automatisch ist das eher schwierig. Ferner werden die Daten ja nicht nur für Karten, die man sich ansehen kann, verwendet, sondern z. B. auch für Routing, für das es ganz andere Infos braucht als nur für die Darstellung, die zusätzlich erfasst werden möchten. Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dpeak [2] http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area [3] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts [4] http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienbündel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Video-Tracking als Mapping-Hilfe
Am Sun, 27 Dec 2009 16:30:11 +0100 hat Florian Gross flor...@grossing.de geschrieben: Mit den billigen Action- Cams? Hm, weiß nicht, ob es da welche gibt, bei denen man die Uhrzeit einstellen kann. Die Sache mit der Uhrzeit würde ich nicht als Problem sehen. Man kann ja - wie man es auch i. d. R. beim Mappen mit dem Fotoapparat macht - einmal die Zeit vom GPS-Gerät filmen, wenn man loslegt oder eine neue Aufnahme beginnt. Sofern die Synchronisation mit einem GPX-Track funktioniert, sollte man das recht simpel als Zeitversatz berücksichtigen können. Gruß, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Hi zusammen, komme leider erst heute wieder dazu, mich zu melden... Am Wed, 25 Nov 2009 00:54:05 +0100 hat Martin Koppenhoefer dieterdre...@gmail.com geschrieben: Am 24. November 2009 22:09 schrieb Nils Heuermann w...@oemmes.net: nicht direkt. Ich habe mich schon etwas an den aktuell beworbenen Fahrspurassistenten orientiert bzw. es so angelegt, dass sowas möglich ist. denen sind lagegenaue Wege weniger wichtig? (*erstaunt*) das weiß ich nicht ;) Aktuell scheint es aber so zu sein, dass solche Abbiegehinweise nicht aus einzeln (durchgehend) erfassten Spuren kommen, sondern nur an einem Node die Info mit Spuranzahl, Richtung und Ziel (pro Spur) hängt; also im Prinzip einfach das Autobahn-/Straßenschild als Node drin ist. Das Navi blendet beim Erreichen des Nodes die Info ein. Ob das jetzt wirklich stimmt, weiß ich nicht, es hat aber den Anschein. Beide Ansätze schließen sich auch nicht gegenseitig aus m.E. an derselben Stelle schon. Sonst hätte man die Wege ja doppelt, die Spuren würden sich mit den Multiwegen kreuzen, etc. ja, da hast du natürlich recht. Ich meinte es global; man kann sozusagen 3 Detailstufen daraus machen: 1) Way ohne alles 2) Way mit relativ angegebenen Fahrstreifen (Wayparts) 3) Mehrere Ways für jeden Fahrstreifen bzw. einzelne Flächen (Area) Für viele Benutzer/Mapper oder an vielen Stellen reicht ein einfacher Way. Wayparts sind noch relativ simpel, da sie die zusätzliche Information relativ ;) abbilden; wird aber auch für vieles ausreichen. Areas gehen dann ins Detail, wenn man es genauer haben möchte oder braucht. Da bleibt dann jedem überlassen, wie genau er etwas eintragen möchte. Ich hab - um ehrlich zu sein - z. B. keine Lust, jeden Bordstein im einzelnen aufzumalen, da geb ich lieber an, dass der Bürgersteig rechts neben den 2 Fahrstreifen mit einem Bordstein abgetrennt ist von da bis dort. Ist halt meine persönliche Faulheit, wenn es dann jemand genauer einträgt, seh ich das natürlich gern. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wayparts - Ansatz für Fahrspure n, straßenbegleitende Wege etc.
Hallo zusammen, hatte dieses Thema zuvor im Thread Relationen besser als Tags [1] angesprochen; da es inhaltlich aber doch auf etwas anderes abzielt, jetzt als eigener Thread. Hier eine kurze Einleitung: Ziel ist die Erfassung von Fahrspuren, straßenbegleitenden Wegen (Radweg, Bürgersteig) sowie weiteren Straßenteilen wie Parkstreifen, Grünstreifen usw. Zugeordnet/angelegt werden diese als Relationen, die den Weg (oder mehrere zusammenhängende Wege) sowie jeweils einen Start- und Endnode beinhalten. Den Ansatz habe ich im Wiki erläutert, wo es auch ein (noch unfertiges) JOSM-Plugin zur Visualisierung gibt: http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts Im anderen Thread gab es schon ein paar Antworten, die von Tobias greife ich hier jetzt auf: Am Fri, 20 Nov 2009 22:51:16 +0100 hat Tobias Knerr o...@tobias-knerr.de geschrieben: Konzeptionelles: Du kombinierst hier die Angabe über Tag-Präfixe mit der über Relationen. Ein durchaus gangbares Konzept wäre ja auch die Angabe komplett über Tags, also so etwas wie right4:lane_type=footway right4:surface=cobblestone ... - also das, was du mehr oder weniger auch in der wayparts-Relation verwendest. Nur: Warum dann die mit solchen Präfixen versehenen Tags nicht direkt an den Way packen und auf eine Relation verzichten? Für die Verwendung von Relationen spricht für mich folgendes: - Die Tagliste von Ways wird nicht ellenlang - Man hat Geometrie (Way) von der näheren Beschreibung/dem Querschnitt (Relation) getrennt - Man kann mehrere Ways zusammenfassen, zum Beispiel bei Brücken oder wenn sich nur der Straßenname ändert. Die Fahrspuren führen dennoch weiter und sind zentral definiert (keine Redundanz an mehreren Ways - weniger Fehler, wenn man was am Querschnitt ändert). So könnte man evtl. auch eine abknickende Vorfahrt erfassen. - Umgekehrt kann man einen Way in mehrere Bereiche aufteilen, ohne diesen zerstückeln zu müssen, wenn eine Spur hinzukommt oder wegfällt. Falls es um die Vermeidung des Teilens von Ways geht: Wäre es dann nicht besser, eben doch zunächst einmal Tags zu nehmen und diese dann mit einer Eigenschaftsrelation - wie sie in diesem Thread vorgeschlagen wurde - an den Way zu hängen? Denn für Tags, die den ganzen Way betreffen, wäre eine solche ja ohnehin noch separat nötig. Und wenn man eine Eigenschaftsrelation für name=* anlegen kann, dann doch sicher auch für part4:type=*? Klar, das lässt sich natürlich kombinieren. Allerdings sollte man jetzt nicht erst anfangen, Tags zu verwenden und Ways zu spiltten, um diese später dann doch in Relationen auszulagern. Wenn, dann gleich als Relation (sofern sich das als funktioniernde Lösung herausstellt). Ansonsten noch: Könnte man es irgendwie schaffen, die beiden Relation-Typen zusammenzufassen? Abgesehen davon, dass wayparts, wenn ich das richtig verstehe, für den Kernbestand an Weg-Teilen gedacht sind, ist ein waypart doch mehr oder weniger nur ein wayparts mit parts=1? jein ;) Ausschlaggebend war in der Tat die Angabe der Hauptspuren (Kernbestand) im Gegensatz zu einzelnen Spuren. Die Hauptspuren (wayparts) können (derzeit) nur 1x für einen Abschnitt definiert werden und können durch weitere Spuren (waypart) ergänzt werden - das allerdings mehrfach. Vielleicht ist es auch unnötig, diese Unterscheidung anhand des Relations-Typs zu machen - man könnte auch einfach die Tags auswerten, die vorhanden sind. Dann ließe sich evtl. auch sowas machen wie: Füge 2 Abbiegespuren hinzu, wofür man im Moment 2 waypart-Relationen bräuchte. Ansonsten war es für das Schreiben des Plugins erstmal einfacher, diese Unterscheidung zu verwenden, da aus wayparts automatisch mehrere waypart-Elemente erzeugt werden, ein waypart aber direkt verwendet werden kann. Wahl der Begriffe: Subjektiv empfinde ich waypart als etwas merkwürdige Bezeichnung, bin aber kein Muttersprachler. Bin ich auch nicht, daher mag der Begriff nicht korrekt sein. Da Begriffe wie lane, die mir besser gefallen würden, als zu eng aufgefasst werden könnten, habe ich gerade keinen eindeutig besseren Vorschlag. So ging es mir auch, daher bin ich bei waypart hängengeblieben... Viele Grüße und schönes WE! Nils [1] http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Am Fri, 20 Nov 2009 12:42:00 +0100 hat qbert biker qbe...@gmx.de geschrieben: Wobei ich bei dem einen Ansatz den Fokus darin sehe, dass man die Fragmentierung entlang des Weges in den Griff bekommt und bei deinem Ansatz mehr die Querschnittsbeschreibung. Aber die beiden Dinge sind schon verwandt zueinander. thematisch sind es schon 2 verschiedene Dinge (die sich u. U. direkt ergänzen können); ich hatte meine Aussage eher aufs Prinzip mit Start-/Endnode bezogen, damit die Wege nicht zerstückelt werden. Was vielleicht ein wenig untergeht ist die Sache mit der Bezugslinie. Soweit ich das sehe, gehts du ja davon aus, dass die Basislinie als linke Seite der Richtungsfahrbahn angenommen wird, richtig? Damit 'waechst' die Fahrbahn mit den unterschiedlichen Spuren und Breiten in Fahrtrichtung rechts. genau. Also Vorwärts-Spuren (mit partnum +) sind in der Regel rechts, Rückwärts-Spuren (mit partnum -) links, von der Mitte (ergo dem OSM-Way) aus gesehen. Wobei hier nicht die Richtung des Ways entscheidend ist, sondern die der Relation (Start-/Endnode). Meiner Erfahrung nach ist das auch die einzige Methode, das optisch richtig hinzubekommen. Abgesehen davon, dass die Darstellung vom Plugin noch lange nicht perfekt ist, habe ich vor allem bei Einbahnstraßen überlegt: Wahrscheinlich müsste man dort die Spur (wenn es nur 1 ist) auf die Mitte zeichnen bzw. rechts/links immer gleich viele Spuren. Wird jedoch auch nicht immer passen... Aber das ist nur die Darstellung - mir ist erst mal wichtiger, ob das ganze überhaupt funktionieren kann und was man noch ergänzen muss, wie zum Beispiel: Der kleine Haken dran ist, dass dann beruecksichtigt werden muss, auf welcher Seite gefahren wird. Hast du dein Plugin schon mal in England getestet? noch nicht getestet, aber im Moment wird es dort genauso aussehen wie überall ;) Man hätte dafür ja 2 Möglichkeiten: 1) Zusätzlichen Tag, der Linksverkehr angibt, sodass man direkt Bescheid weiß und die Teile getauscht werden: rechts - links (nicht die Richtung) usw. 2) Kein Tag und beim Rendern die jeweiligen Landesregeln voraussetzen und sich danach richten. Für die Erfassung ist es ja eher unerheblich, da man die Richtung durch Start- und Endnode vorgibt. Ist natürlich nicht nur zum Rendern wichtig, sondern z. B. bei durchgezogener Mittellinie auch für Abbiegebeschränkungen (Rechtsverkehr - kein Linksabbiegen; Linksverkehr - kein Rechtsabbiegen). Ich werde mich auf alle Fealle noch genauer mit deinem Ansatz auseinandersetzen auf weiteres Feedback bin ich sehr gespannt - nicht nur von dir ;-) Gruesse Hubert Bis dann, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Hallo Tirkon, hallo Liste, Am Sat, 07 Nov 2009 14:32:00 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Dieses Posting befasst sich mit der Frage, ob die Eigenschaften von Straßen besser durch Relationen als durch Tags erfasst werden könnten. ... Weitere Begehrlichkeiten, wie das Darstellen der für die Routenplanung unumgänglichen durchgezogenen Mittellinie, welche gleichzeitig eine Wende- und Linksabbiegeverbot implizieren würde, ist derzeit nur aufwendig und realitätsfern möglich. einen prinzipiell fast identischen Ansatz (auch zu segmanted_ways) habe ich mir in letzter Zeit ebenfalls erdacht. Schon interessant, dass dazu auf einmal mehrere unabhängige Ideen entstehen. Meinen Ansatz habe ich im Wiki zusammengefasst: http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts Ich nenne diesen Lösungsversuch Eigenschaftskonzept. Er soll versuchen, möglichst alle oben aufgeführten Fragen mit einem Schlag und dabei mit einem möglichst einfachen Konzept zu bewältigen Wie schon aus der Wiki-Seite ersichtlich, heißt das ganze bei mir Wayparts, da ich mein Konzept zunächst auf Fahrspuren bzw. Wegteile (Radweg, Parkstreifen etc.) bezogen habe. Es funktioniert aber nach dem selben Prinzip: Statt mit Tags werden die Eigenschaften grundsätzlich nur noch per Relation entlang eines Weges von hier bis dort zugeordnet: ... Von hier bis dort ist die Straße Einbahnstraße. ... Von hier bis dort befindet sich eine durchgezogene Mittellinie. Jede Eigenschaftsrelation hat eine Richtung. Beides (Eigenschaften und Fahrstreifen/Wegteile) ließe sich mit dieser Erfassungsmethode ziemlich leicht unter einen Hut bringen. All dies setzt allerdings voraus, dass die Editoren die Eigenschaftsrelationen genau so einfach sichtbar machen, wie bisher die Tags. Das ist die große Aufgabe. Man muss es sich zusammenklicken können, ohne noch einen Relationseditor von Hand befüllen zu müssen. Bezogen auf Fahrstreifen: Klick Start, Klick Ende, hinzufügen Spur 1, gestrichelte Linie wählen, hinzufügen Spur 2, hinzufügen Spur 3, Radweg wählen usw. bis man die Straße zusammen hat. Analog für die Eigenschaften Brücke etc. Für die Wayparts habe ich ein JOSM-Plugin geschrieben, das zwar (noch) nicht die Erfassung ermöglicht, aber visualisiert, was man als Relationen angelegt hat. Auf der Wiki-Seite stehen ein paar mehr Infos. Die Eigenschaftsrelation nimmt normalerweise alle Linien als auch Punkte entlang eines Weges auf, um explizit punktförmige Ausschlüsse z.B. an Abzweigungen (oder Kreuzungen) deutlich zu machen. An Kreuzungen kann der punktförmige Ausschluss der Eigenschaft im Renderer durch Unterbrechung ihrer Darstellung im Kreuzungsbereich (Löschen, wo eine andere Straße überlappt) kenntlich gemacht werden. Das hatte ich bisher noch nicht bedacht, bin daher gerade am überlegen, ob man es ausschließend oder einschließend machen soll. Ich tendiere eher dazu, die Punkte in die Relation aufzunehmen, die die Ausnahme bilden. Also bei einer durchgezogenen Mittellinie den Kreuzungs-Node, an dem man trotzdem links abbiegen darf. Viele Grüße aus OWL, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraßen in Kiel
Hallo Stefan, hallo Liste, Am Tue, 27 Oct 2009 02:18:54 +0100 hat Stephan Wolff s.wo...@web.de geschrieben: In Kiel sind recht viele Fahrradstraßen ausgewiesen. Diese sind nicht nur für Anlieger, sondern für alle Fahrzeuge freigegeben. hier in Herford gibt auch ein paar Einbahnstraßen, da kommt noch hinzu, dass sie teilw. für Autos Einbahnstraßen sind, für Fahrräder natürlich in beide Richtungen freigegeben sind. Oder es ist für Autos die Einfahrt nur von einer Seite zugelassen, aber theoretisch dürften Sie drehen und zurückfahren (unechte Einbahnstraße). Das Ergebnis des Meinungsbilds (inklusiv meiner Stimme) ist, dass fünf Mapper highway=residential mit bicycle=designated bevorzugen, zwei highway=cycleway. Eine Antwort verwies auf das Wiki, wo für Fahrradstraßen mit Zusatz Anlieger frei highway=residential vorgeschlagen wird. (Ist das allgemeiner Konsens?) Die Fahrradstraßen hier hab ich selber mal von residential auf cycleway und dann auf residential+bicycle=designated umgetagged. Im Wiki steht bei German Roads Tagging [1], dass path+bicycle=designated bzw. residential+bicycle=designated verwendet werden soll, bei Road Signs [2] hingegen, dass es offiziell nur ein Radweg ist und daher cycleway empfohlen wird. Da sich eine Mehrheitsmeinung der lokalen Mapper herausbildet hat, werde ich ich die Fahrradstraßen in Kiel einmalig dementsprechend ändern. Ich hoffe, dass dieses halbdemokratische Verfahren einen Editwar vermeidet. Es gibt auch noch ein Proposed Feature für highway=cycleroad [3] + Diskussion [4] (hier gibts noch highway=cyclestreet und highway=(residential|...)+cycleway=cyclestreet). Ich persönlich finde den Vorschlag mit cyclestreet am sinnvollsten. Ob nun als highway-Klasse oder Wert für cycleway, hab ich mich noch nicht entschieden. Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/DE:Germany_roads_tagging#ausgeschilderte_Fahrradstra.C3.9Fe_.28Zeichen_244.29 [2] http://wiki.openstreetmap.org/wiki/DE:Road_Signs [3] http://wiki.openstreetmap.org/wiki/Proposed_features/cycleroad [4] http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/cycleroad#Cyclestreet ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All In One - unclassified straßentyp
Moin, Am Wed, 23 Sep 2009 16:18:10 +0200 hat Florian Lohoff f...@rfc822.org geschrieben: On Wed, Sep 23, 2009 at 03:10:44PM +0200, Chris-Hein Lunkhusen wrote: Florian Lohoff schrieb: D.h. der GPSMap 60Csx schickt mich von der unclassified runter auf einen track auch wenn es kuerzer ist geradeauszufahren - Nur weil er von der Rampe runter moechte. Routing war Fahrrad, Kürzeste Strecke ... Die Einstellung Fahrrad, Kürzeste kann man vergessen. Versuch mal Fahrrad, Schnellste. Manchmal probiere ich auch Fussgänger, Kürzeste, meist kommt man da auch per Radl durch. ;-) Typischerweise sollte Kuerzeste identisch zur Schnellsten sein - Zumindest bei Fußgaengern und Radfahrern. Aber das Ergebniss oben ist WEDER Schnellste NOCH Kuerzeste ... ich hab das Routing-Problem auch mit einer residential, allerdings nur, wenn ich Rad, kürzeste nehme: http://osm.org/go/0GwJgxzrh- Wenn ich von der Werler Straße über die Kampstraße nach Süden fahren will, schickt der mich immer über über die Tracks östlich der Straße und dann wieder über die Stichstraße zurück. Das geht irgendwie kürzer... :) Als Fußgänger oder schnelle Radroute passt es, da darf ich einfach geradeaus fahren. Sieht daher wohl eher nach einem Garmin-Problem aus... Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Quarks Co. berichtet über Op enStreetMap für Rollstuhlfahrer
Hallo, am nächsten Dienstag (15.09., 21:00 Uhr im WDR) wird in der Quarks--Co.-Sendung zum Thema Was Karten verraten und wie sie lügen ein Bericht über OpenStreetMap für Rollstuhlfahrer [1] gezeigt. Der Bericht kann jetzt schon auf der Website vom WDR angesehen werden: http://www.wdr.de/tv/quarks/videos/flashplayer.jsp?mid=82487 Schönen Sonntag noch, Nils [1] http://wiki.openstreetmap.org/wiki/DE:Rollstuhlfahrer-Routing ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationenn im Garmin visualisieren
Hi Sven, Am Thu, 03 Sep 2009 08:32:40 +0200 hat Sven Sommerkamp s_sommerk...@gmx.de geschrieben: Am Mittwoch, 2. September 2009 23:40:14 schrieb Sven Geggus: Radrouten werden ja als Relation in OSM erfasst. Wenn man unterwegs ist (nicht auf mapping tour sondern ganz normal) möchte man diese natürlich gerne auch auf dem GPS sehen. Für Garmin Geräte bietet sich da ein overlay als GPX Track an, vielleicht oder sogar noch besser auch ein zuschaltbarer Kartenlayer. eine GPX-Datei von einer Relation kann man sich über den Relation-Analyzer abspeichern: http://betaplace.emaitie.de/webapps.relation-analyzer/index.jsp Um das als Track aufs Garmin zu bekommen, muss der Track ggf. noch aufgeteilt und vereinfacht werden, da die Trackpunktanzahl ja begrenzt ist. Zum Vereinfachen meine ich, letztes Mal GPSBabel (http://www.gpsbabel.org/) benutzt zu haben, aber vielleicht gibts auch andere Tools. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
'n Abend, Am Fri, 28 Aug 2009 15:29:13 +0200 hat Stefan Schwan stefan.sch...@googlemail.com geschrieben: Wollte man das Problem mit einem Polygon lösen, bräuchte man ein weiteres Multipolygon Implizit 50 mit den Ortschildern als Nodes. Software müsste dann für jede Straße ohne maxspeed prüfen, ob sie innerhalb eines solchen Polygons liegt - im Vergleich zu einem Zusatztag impliziert am maxspeed ist das imho unnötig hoher Aufwand sowohl bei eintragen, als auch bei auswerten. und selbst, wenn es so ein Polygon mit den Ortsschildern als Nodes gäbe, kann es immer noch Bereiche geben, die aus dieser Fläche herausragen, weil die Strecke zwischen den nächstgelegenen Ortsschildern eben direkter ist. Da müsste man also das Polygon noch nach außen erweitern... und zudem ein multipolygon machen, wenn innen ein Bereich/Straße ausgenommen (außerorts) ist. Bisher habe ich zwar maxspeed=50 innerorts getaggt, aber ich bin auch für etwas wie maxspeed=DE:urban. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
