Re: [Talk-de] Umgang mit Proposals
Hi, Am Fri, 9 Aug 2013 08:04:22 +0200 (CEST) schrieb Roland Olbricht roland.olbri...@gmx.de: Wenn nicht innerhalb von 30 Tagen zu einem Proposal 25% der Wiki-Account-Inhaber geäußert haben, wird das Proposal in den Zustand Not Relevant versetzt... Wäre es da nicht einfacher zu sagen Proposals brauchen wir nicht? ... und stattdessen die vorhandenen Stile beim Mappen dokumentiert. Das erlaubt, die wichtigen von den unwichtigen Proposals zu unterscheiden. Und es wertet tatsächliches Mappen höher als unerprobte Konzepte und Geschäftsordnungsdebatten. So in der folgenden Art? Unter name trägt man bei Haltestellen den Namen der Haltestelle oder die Nummer des daneben liegendes Gleises oder die Nummer des Bussteigs oder mehrere davon ein, wobei man noch einige Satzzeichen und Strings wie Gleis, Bahnsteig oder Läge dazwischen verteilt. Warum sollte man bei sowas Konzepte vor dem Mappen machen... Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon
Am Fri, 9 Aug 2013 01:51:21 -0700 (PDT) schrieb Kai Krueger kakrue...@gmail.com: Das zweite Problem ist moeglicherweise Bug #4525 ( https://trac.openstreetmap.org/ticket/4525 ). Wenn man ein Polygon das zuvor Teil eines Multipolygon war aus dem Multipolygon heraus nimmt ohne den einzelnen Weg zu aendern dann stolpert der diff code von osm2pgsql darueber und das Polygon wird nicht korrekt in die rendering Datenbank eingefuegt. Ich sieht so aus, als ob das der Grund gewesen wäre. Der angesprochene Fehler geht auf Code zurück, der nur wegen der Sonderfall-Multipolygone gebraucht wird, die die Tags nicht im MP haben. Wir sollten diese Dinger irgendwann loswerden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon
Am Fri, 09 Aug 2013 15:20:27 +0200 schrieb tumsi tu...@gmx.de: Mir sind auch schon MPs untergekommen (z.B. Seen), bei denen die Tags nachträglich wieder an das Umrisspolygon gepappt wurden, obwohl diese Tags bereits im MP enthalten waren. Vielleicht sollte JOSM an dieser Stelle auch mal Warnungen aussprechen... Das wäre gut, denn es ist ein klarer Fehler. Sobald das Multipolygon Tags hat, gelten die Tags des Mp für das MP und die Tags der Member für die Member. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon
Am Tue, 06 Aug 2013 21:58:34 +0200 schrieb tumsi tu...@gmx.de: Danke für eure Antworten. Ich scheine also keinen grundsätzlichen Fehler gemacht zu haben. Ich habe jetzt einen überschaubaren Teil vom Multipolygon abgetrennt und habe so die betreffenden Polygone separat. Jetzt wird es richtig interessant. Es (Way 94507617) wird immer noch nicht dargestellt, obwohl es ein einfaches Polygon ist. Kein Punkt ist doppelt. Keine Selbstüberschneidungen. Keine lustigen Codes in den Tags. Was kann das sein? Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Umgang mit Proposals
Hi, ich schlage eine andere Vorgehensweise bei Proposals vor: Stati Draft und Proposed: nur der Autor/ die Autorin kann das Proposal ändern. Wenn jemand etwas anderes für besser hält, dann soll er/sie den Autor/die Autorin überzeugen oder einen eigenes Proposal machen. Stati Voting, Approved und Rejected: niemand (auch nicht der Autor/die Autorin) kann das Proposal ändern. Nur die Votes werden angehängt. Auch grammatische Korrekturen und Klarstellungen können nur woanders (und ohne eine besondere Rolle des Autors/der Autorin) erfolgen. Beim Übergang zum Status Approved erhält das Proposal eine laufende Nummer. Die kann vom Mapper als Tag osm_proposal=n genutzt werden. Es wird als Fehler (sprich: als sozial akzeptabler Grund zur Korrektur durch andere Mapper) betrachtet, wenn jemand Änderungen im Widerspruch zum Proposal durchführt ohne dabei dieses Tag zu entfernen oder anders zu belegen. Wilhelm (Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon
Am Thu, 8 Aug 2013 14:23:31 +0200 schrieb Wilhelm Spickermann o...@spickermann-d.de: Was kann das sein? In einigen Maßstäben sieht man noch wahrscheinlich ältere Umrisse obwohl die Kacheln neuer sind als die Änderungen. Evtl. gibt es Probleme mit den Updates der Daten vor dem Rendern. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon
Am Tue, 06 Aug 2013 15:11:06 +0200 schrieb tumsi tu...@gmx.de: Ich kann auch bei mehrmaligem Überprüfen keinen Fehler meinerseits finden. Weiß jemand Rat? Beim Way 94507617 ist es vielleicht ein Folgefehler: Der Way 42759990 müsste auch noch inner der Waldfläche sein. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenstil wird nicht mehr gerendert nach Hinzufügen als inner zu Multipolygon
Am Tue, 6 Aug 2013 15:35:15 +0200 schrieb Wilhelm Spickermann o...@spickermann-d.de: Am Tue, 06 Aug 2013 15:11:06 +0200 schrieb tumsi tu...@gmx.de: Ich kann auch bei mehrmaligem Überprüfen keinen Fehler meinerseits finden. Weiß jemand Rat? Beim Way 94507617 ist es vielleicht ein Folgefehler: Der Way 42759990 müsste auch noch inner der Waldfläche sein. Wenn man die willkürliche Grenze (Way 97112506) zwischen den beiden gleich getaggten Multipolygonen verschiebt, dann könnte man diesen ganzen zusammenhängenden Inner-Pulk zwischen die Multipolygone bekommen und sie hätten nichts mehr damit zu tun, das Ganze wäre übersichtlicher und die Renderer hätten weniger Fehlerchancen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderung von accepted Proposals
Am Sun, 4 Aug 2013 09:32:11 +0200 schrieb Falk Zscheile falk.zsche...@gmail.com: ... gibt es keine Wiki-Seite zu dem im Proposal angenommenen Vorschlag ... Doch, einige. Es geht um das Public Transport Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport Wilhelm PS: Nachträglich eingefügt wurde der Fahrzeugtyp light_rail=yes/no unter stop_position. Das ist eine Veränderung der Bedeutung von train=yes/no, da im Original Halte für solche Fahrzeuge mit train=yes markiert worden wären. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderung von accepted Proposals
Am Sun, 04 Aug 2013 07:31:07 +0200 schrieb Henning Scholland o...@aighes.de: Ansonsten sollte das zumindest auf @tagging diskutiert bzw. via @tagging auf die Diskussion aufmerksam gemacht werden. Hmm, es geht ja eigentlich nicht um das Tagging... Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderung von accepted Proposals
Am Sun, 04 Aug 2013 12:28:39 +0200 schrieb Frederik Ramm frede...@remote.org: ... aber oft wird das abgestimmte Proposal halt zur Tag-Seite umgewandelt und unterliegt dann natuerlich der ganz normalen Evolution. Das kann man machen. Aber dann muss man es auch wirklich umwandeln und alles rauswerfen, was mit accepted und proposal und Abstimmungsergebnissen zu tun hat. Jetzt steht da Das war der Vorschlag und XY hat dafür oder dagegen gestimmt und das ist schlicht und einfach falsch. Da diese umgewandelte Fassung auch nicht mehr in http://wiki.openstreetmap.org/wiki/Proposed_features/ gehört, wäre es doch am einfachsten, dort das Original (mit grammatischen Korrekturen) liegen zu lassen. :-) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging-System der Firma Mentz Datenverarbeitung GmbH
Am Sat, 03 Aug 2013 19:30:39 +0200 schrieb fly lowfligh...@googlemail.com: * Area=yes ist bei Platformen unnötig ! Hmm, also ich kenne die Regel so, dass area nicht erforderlich ist, wenn der Datentyp nicht linienförmig sein kann. Danach wäre area=yes erforderlich. Ich finde es auch sehr wichtig, dass Fehler beim Schließen einer Linie auch noch automatisch zu finden sind. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Änderung von accepted Proposals
Hi, ich habe versucht, ein inhaltliche Änderung eines bereits akzeptierten Proposals wieder zu entfernen. Das wurde sofort reverted und der Dialog mit dem Betreffenden zeigte die Auffassung, dass aktuelle Üblichkeiten da eingearbeitet werden sollten. Ich finde es dagegen völlig selbstverständlich, es nicht inhaltlich verändert werden darf. Ist das tatsächlich strittig? Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Proposal
Ich schätze die Lage nach den Diskussionen im Forum jetzt so ein: Die Chancen, dass der Vorschlag durchkäme und sich dann durchsetzen würde, sind gering. Es ist aber kein sinnvolles Ziel, noch ein Schema neben die anderen zu stellen und die Taggingarten weiter aufzusplitten. Ich ziehe den Vorschlag daher zurück und werde ihn nächste Tage wieder von der User-Seite entfernen -- falls jemand daran weiterarbeiten will, müsste er/sie rechtzeitig kopieren. Wilhelm (Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Sat, 27 Jul 2013 19:57:59 +0200 schrieb Martin Koppenhoefer dieterdre...@gmail.com: railway=station auf einer area, die das gesamte (geschätzte soweit man keine genaueren Informationen hat) Bahnhofsgelände umfasst, also nicht nur Gebäude sondern auch Gleise und Bahnsteige, ggf. auch Parkplätze, Kneipe und andere Nebengebäude etc. Ja, sehe ich ein, da habe ich zu allgemein formuliert. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Tue, 23 Jul 2013 11:40:51 +0200 schrieb Tracy Kasperczyk kasperc...@mentzdv.de: Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Ich würde da eher mehrere Punkte nehmen, nämlich die Punkte, an denen man den Bahnsteig verlassen kann. Diese haben zwar oft beträchtlichen Abstand voneinander, aber die Passagiere steigen auch dort in der Nähe ein und erfahrene Nutzer dort in der Nähe aus. Das bedeutet, das das Routing das Optimum dieser Punkte suchen muss und dass bei mehr als zwei Zugangsmöglichkeiten kein einzelner noch so geschickt gewählter Punkt dieselben Ergebnisse liefern kann. Beispiel Hilden Süd, Umsteigemöglichkeiten zwischen dem Bus 785 und der S1: In vielen Fällen wird die Nutzung der Bushaltestelle Talstraße/Hilden Süd (westliches Ende der Bahnsteige) trotz Vorteilen gegenüber der östlichen Bushaltestelle Hilden Süd S-Bahnhof nicht angeboten. Nachteilig wäre allerdings, dass nicht jeder Routingalgorithmus damit klar kommt, dass der Abstand des Bahnsteiges zu A plus dem Abstand des Bahnsteiges zu B kleiner ist als der kürzeste Weg von A nach B. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Tue, 23 Jul 2013 11:40:51 +0200 schrieb Tracy Kasperczyk kasperc...@mentzdv.de: Weitere Datenelemente die wir brauchen, sind die oben erwähnten Haltepunkte auf den Schienen oder die Haltepunkte der Busse vor dem Bahnhof. Dies Punkte brauchen wir um einen Weg auf die Karte zeichnen zu können. Dort ist Anfang oder Ende des Wegs im Fahrzeug und der Übergang auf den Fußweg. Das sind bekannte OSM Objekte ( http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position) Nicht unbedingt. Die stop_positions sind stets Teil des angegebenen Fahrwegs und damit geometrisch oft von der Einstiegsstelle entfernt. Nicht baulich von der Straße getrennte Haltebuchten werden nicht als getrennte Wege eingezeichnet. Als Endpunkte des Fußroutings kommen stop_positions m.E. nicht in Frage. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Tue, 23 Jul 2013 11:40:51 +0200 schrieb Tracy Kasperczyk kasperc...@mentzdv.de: Schienen werden von uns nicht angefasst. Das einzige was wir machen, wenn zu wenig Schienen eingezeichnet sind, wie es bei U-Bahnlinien der Fall ist, dann erweiteren wir diese möglichst nach der genauen Lage. Das bedeutet aber, dass die bisher in einem Way mit mehreren Tracks gemappten Linien nun richtig auf die einzelnen Ways verteilt werden müssen. Das gilt auch für diejenigen Linien, zu deren Betreiber ihr keine Geschäftsbeziehung habt. Das kann in seltenen Fällen eine vor-Ort-Recherche erzwingen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Tue, 23 Jul 2013 11:40:51 +0200 schrieb Tracy Kasperczyk kasperc...@mentzdv.de: Objekt: Haltepunkt (Type: Node auf dem Way Schiene) - railway = stop (vorher haben wir station getaggt, es war uns nicht ganz klar was der unterschied zwischen Station und Stop in diesem Fall ist) Station und stop stammen meines Wissens aus der Zeit, als einzelne Gleise noch nicht gemappt wurden. Es waren kleine und große Bahnhöfe, die einfach als Punkt in den Way gesetzt wurden. Als dann Gleise einzeln gemappt wurden, haben viele Leute die Punkte verdoppelt (falsch, da dort nicht mehrere Bahnhöfe sind) oder auf einem der Gleise gelassen (falsch, da der Bahnhof zu beiden Gleisen gehört). Das Problem liegt m.W. ungelöst rum und wurde durch das Tagging per Public Transport Proposal gelöst. - ref = 1 (Gleisnummer) - name = Ostbahnhof München ref bezieht sich meines Wissens auf den Bahnhof. Es ist aber sehr üblich, dort die Bahnsteignummer unterzubringen. - name = Untertürkheim, Bahnsteig 1 - public_transport = platform Der Name sollte hier Untertürkheim sein. Das ergibt sich aus den Angaben im Public Transport Proposal (Stichwort optional, wenn). Das steht aber sogar im Wiki falsch. - train = yes ... ist nur für stop_positions vorgesehen. In den vorhandenen Daten sind Bahnsteige aus Routinggründen häufig zweigeteilt. Die Routinggründe sehe ich noch nicht. Wenn es sie gibt, dann ist das ein echtes Problem. Man kann einen Bahnsteig zweiteilen um Daten hinzuzufügen -- z.B. die Flächen über den Treppen heraus zu nehmen. Wenn aber jetzt jemand dort schon ein Multipolygon angelegt hat und die Fläche richtig dargestellt ist, dann ist es eigentlich gegen die guten Sitten, dort ohne Diskussion mit dem Ersteller etwas zu ändern. Man muss auch noch trotz weiterer Unterteilungen Routing betreiben können; diese Unterteilungen ergeben sich oft, wenn Steige teilweise auf Brücken liegen. Um diese wieder zu vereinigen, werden sie durch eine Relation zusammengefasst. Wir benutzen die Relation stop_area. Falls dies nicht gewünscht wird könnten wir auch eine eigene Relation anlegen. stop_area ist der Gesamt-Bahnhof und passt damit nicht. Ich sehe keinen Grund, eine extra Relation anzulegen. Objekt: Aufzug (Type: way) - highway = elevator Ways sollte man laut Wiki für Schrägaufzüge nehmen. Normale Aufzüge gehen mit einem Punkt. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Mon, 22 Jul 2013 16:43:25 +0200 schrieb fly lowfligh...@googlemail.com: Hat sich das denn jetzt aufgeklärt oder geht das weiter ? taoxue hat vorhin mit mir Kontakt aufgenommen und ich habe dazu geraten, die Sache hier in der Liste zu besprechen. Ich denke, dass wir akzeptable Lösungen finden können, aber die Sachen müssen jetzt in der Liste geklärt werden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki Nicht-Streitpunkt public_transport name/ref
Am Mon, 22 Jul 2013 02:20:25 +0200 schrieb Tirkon tirko...@yahoo.de: Bei Bahnsteigen mit Gleisen auf beiden Seiten wird nicht klar, auf welcher Seite der Fahrgast seine Bahn zu erwarten hat. In der betreffenden Variante unbenutzte Steige kommen ja nicht in die Relation. Die Values für Komplettheit müssten noch einen Wert für fraglich zulassen, möglicherweise ?. Das ist der Default. Aber vielleicht sollte ich einen expliziten Wert vorsehen. To be able to map platform nodes with unknown properties, the tag public_transport=any_platform is added to the set of values. This tag corresponds to highway=bus_stop and alike even in the case of nodes. For ways and areas it's the same as public_transport=platform. Verstehe ich nicht. Was sagt public_transport=any_platform aus? Und zu welcher Menge von Werten wird das hinzugefügt. (eventuell Beispiel) Der Key public_transport kann doch nur einen Wert haben. Und wann wird stattdessen highway=bus_stop oder public_transport=platform getaggt. Was passiert dann mit der erwähnten Menge von Werten? Es sollen nicht mehrere Werte zum Key angegeben werden -- es gibt einen zusätzlichen Wert. Zur Menge der zulässigen Werte (platform, stop_position) wird also einer hinzugefügt. Dann haben wir (any_platform, platform, stop_position). Der Unterschied zwischen platform und any_platform ist, dass any_platform nichts über die Art des Steigs aussagt. Platform besagt ja laut Public Transport Proposal bei einem Node, dass dort kein Steig vorhanden ist. Man kann also zur Zeit die ganzen alten highway=bus_stop Nodes neben der Fahrbahn nicht durch ein public_transport=irgendwas ergänzen, da keine der bisherigen Möglichkeiten passt. Dann können die verarbeitenden Programme aber auch nicht umgestellt werden. pt2_subname A name as found on the splot ... Die Bedeutung der Vokabel splot konnte ich nicht ergründen. vor Ort. Man soll sich da nichts ausdenken, sondern nur nehmen was da vor Ort angegeben ist. pt2_subname=? value is unknown, but there is one pt2_subname omitted: unknown Wo ist der Unterschied zwischen den beiden Alternativen? Weiß ich beim der zweiten weder den Wert, noch dass ein Wert existiert? Genau. vehicle The vehicle kind(s) used. Vehicle macht mir etwas Bauchschmerzen, weil es von der Acess Wikiseite stammt, die ihrerseits inkonsistent ist. Geht aber vermutlich. Man könnte es umbenennen. Aber eigentlich definiert der Relationstyp die Bedeutung seiner Tags und was woanders ist, beißt sich damit nicht. Das ist eigentlich nicht anders als bei name. Da definiert der Objekttyp ja auch, was da benannt wird. *_exit_only and role : *_entry_only are not really useful as first and last stop markers and for intermediate stops they are not needed as time table routing doesn't use them. Hmm, man sollte aber schon wissen, dass man an einer Haltestelle nicht einsteigen kann - insbesondere wenn es nicht die letzte ist. Ja, da gibt es drei Fälle. 1.: Anfang und Ende der Linie. Das wird von vielen Mappern weggelassen, ist aber relevant bei Folgelinien Sie können sitzen bleiben, wir fahren weiter als 456. Das habe ich in follow_up_ref gesteckt. 2.: Reine Ausstiegshaltestellen. Da sollte es an der Haltestelle vermerkt sein. 3.: Restriktionen der Tickets. Bei Schlafwagen gilt oft die Regel, dass nur Übernachtungspassiere zugelassen sind. Bei allen Abend-Haltestellen darf man nur einsteigen und bei allen Morgenhaltestellen nur aussteigen. Das sind aber eigentlich Bestandteile des Fahrplans/Ticketverkaufs. Variants - Member roles haltvar bis part+ sind Rollen von ways der Route, halt sowie +halt sind Rollen von nodes der Haltestellen. Ist das richtig? Wenn ja, könnte das im Text - eventuell durch Überschriften - noch verdeutlichst werden. Also die Überschrift Member Roles ist ja da. Ich wollte die einzelnen Roles eigentlich deutlicher markieren (und in meinem LaTeX-Original hab ich das auch) durch glossarartige Einrückungen. Ich habe es aber nicht hinbekommen, dass da auch weitere Absätze mit eingerückt werden. Wenn mir da jemand sagen kann, wie das geht, dann mach ich das sofort. Ich fasse das Ganze für eine einfache Standard-Buslinie ohne Varianten in Kurzform zusammen. Wir packen die Haltestellen und die Route pro Fahrtrichtung in dieser Reihenfolge und in Fahrtrichtung sortiert in jeweils eine Relation: type=pt2, pt2=variant. Die beiden sich ergebenden Relationen kommen wieder in eine Elternrelation: type=pt2, pt2=master. Richtig? Ja. Was mir unklar bleibt: Wie weiß man jetzt, wo ein Umsteigepunkt zu einer ebenso einfach gestrickten Linie besteht, wenn Du die stop_area abschaffst? Die stop_area existiert nach wie vor, an der hat sich nichts geändert. Sie wird aber nicht mehr von der Routen direkt gebraucht -- z.B. um Haltestellennamen zu ermitteln. Zuletzt: Was mir die größten Bauchschmerzen bereitet, ist das parallele Existieren derselben Linien in zwei Relationsmodellen. Das könnte für die Mapper
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Mon, 22 Jul 2013 16:43:25 +0200 schrieb fly lowfligh...@googlemail.com: Am 18. Juli 2013 16:23 schrieb Wilhelm Spickermann o...@spickermann-d.de: Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden. Darüber müsste man erstmal diskutieren, Hat sich das denn jetzt aufgeklärt oder geht das weiter ? Ich dachte, es hätte aufgehört, aber gerade kam die Änderungsmeldung zum Bahnhof Düsseldorf Flughafen rein. - die Bahnsteige wurden gesplittet. Darüber kann man streiten. - je zwei Hälften wurden zu stop_areas zusammengefasst. Das ist falsch. - der Name der Haltestelle Düsseldorf Flughafen wurde durch Bahnsteig n ersetzt. Ist falsch, steht aber so im Wiki. - Die einzige bisher von mir geprüfte Zuglinie hält jetzt an zwei Bahnsteighälften. Das ist falsch. Aber vielleicht kommt ja noch eine Änderung. Wilhelm PS: Ich habe zwei von den Leuten am Anfang (vor der ersten Mail hier) geholfen, das Splitting bzw. das Neuanlegen von Bahnsteigen richtig zu machen (obwohl ich eigentlich nichts vom Splitting halte). In einem Fall war das ziemlich viel Arbeit. Die Dialoge hatten eine angenehme Atmosphäre -- keiner hat aber was von dem Vorhaben verlauten lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Proposal
Hi, nach einer Diskussion im Forum (http://forum.openstreetmap.org/viewtopic.php?id=21908) habe ich die ursprünglich gestrichenen Segment-Relationen wieder eingebaut. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen
Am Mon, 22 Jul 2013 02:19:11 +0200 schrieb Michael Kugelmann michaelk_...@gmx.de: Am 19.07.2013 19:49, schrieb Wilhelm Spickermann: Würdest Du bitte weniger irreführend zitieren? Was ist bitte daran irreführend zitiert? Nichts! Wenn mein Name oben drüber steht und dann nur Text kommt, der nicht von mir ist, dann ist das irreführend. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen
Am Fri, 19 Jul 2013 19:24:42 +0200 schrieb Stephan Knauss o...@stephans-server.de: Stephan Wolff writes: Am 19.07.2013 17:01, schrieb Wilhelm Spickermann: [...] Könnte ein Berechtigter diesen User temporär sperren, um weitere Schäden zu verhindern? Diese ganze Diskussion ist ja erbärmlich. Würdest Du bitte weniger irreführend zitieren? Danke Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hi, Am Thu, 11 Jul 2013 12:21:45 +0200 schrieb Tracy Kasperczyk kasperc...@mentzdv.de: Tracy (taoxue) i.A. Mentz Datenverabeitung GmbH Ich sehe zur Zeit eine ziemliche Aktivität unter mehreren Benutzernamen, bei der Bahnsteige der Länge nach gespalten werden. Darüber müsste man erstmal diskutieren, denn eigentlich ist es ein Bahnsteig an dem zwei Gleise liegen. Vermutlich soll eine eindeutige Zuordnung von Gleis und Bahnsteig erreicht werden. Häufig wird dabei aber nicht einmal Name und Ref ebenfalls angepasst, was die Frage nach der Motivation aufkommen lässt. Seid Ihr das und ist das ein Versuch, OSM dem Datenmodell anzupassen? MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Thu, 18 Jul 2013 19:42:36 +0200 schrieb Dirk Sohler s...@0x7be.de: ... müssen wir denen ... Langsam, wir wissen noch garnichts. Ich hab absichtlich nur gefragt. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hi, Am Thu, 18 Jul 2013 20:30:01 +0200 schrieb Henning Scholland o...@aighes.de: Ich bin jetzt nicht der ÖPNV-Mapper und habe mich daher auch nicht näher mit den aufgekommenden Schemata befasst. Wenn ich mich aber an die alten Zeiten zurück erinnere, dann war es durchaus zumindest in meiner Region nicht unüblich, die Bahnsteige zu trennen. Wie gesagt, wenn es in einem der Schemata verboten wurde, mag es problematisch sein, ansonsten sehe ich kein Problem darin, die Bahnsteige zu trennen. Es ist in keinem verboten und es ist in keinem auch nur problematisch. In der Regel könnte man bei den ganzen Schildern, Sitzgelegenheiten etc. auch von einer baulichen Trennung zwischen den Bahnsteigen sprechen. Ja, das stört mich auch nicht so sehr. Die dabei gemachten Fehler und die nicht ausreichende Pflege der betroffenen Relationen sind viel störender. Bedenken hätte ich -- wenn es denn tatsächlich so sein sollte -- wenn die Datenstrukturen der Firma solche Trennungen zwingend machen, weil das Konzept auf eine Gleisnummer pro Bahnsteig beschränkt ist und das jetzt einfach ohne Abstimmung durchgezogen würde. Noch mehr Bedenken hätte ich -- wenn das alles denn tatsächlich so sein sollte -- wenn Detaillierung ohne die nötigen Arbeiten vor Ort gemacht würde. Wenn man aus einer einfachen Linie mit einem Knoten als Bahnhof mehrere Gleise mit mehreren Bahnsteigen macht, dann muss man auch ermitteln, an welchem dieser Bahnsteige welche bereits vorhandene Linie hält. Mann kann sie nicht einfach alle an Bahnsteig 1 halten lassen. (Das ist nicht erfunden sondern passiert, aber es könnten auch alles Zufälle sein) MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Thu, 18 Jul 2013 20:23:28 +0200 schrieb Stephan Knauss o...@stephans-server.de: Mit Bushaltestellen habe ich es definitiv schon gesehen dass an einem langen Bahnsteig zwei verschiedene Linien gehalten haben. Eine vorne und eine Hinten. Tram Hauptbahnhof, Bus Studentenstadt. Bei genauerem Überlegen ist das sogar ziemlich häufig. Ja. Nur ist Bussteig 5 der Name eines Bussteigs und es ist völlig normal, dass zwei Bussteige an einer Straße hintereinander liegen. Gleis 5 ist dagegen der Name eines Gleises und nicht der Name des Bahnsteigs. Der Bahnsteig wird dann -- nach den da liegenden Gleisen -- meist Bahnsteig 3,4 (Langfassung: Bahnsteig an Gleis 3 und 4) genannt. Genug der Haarspalterei: Ein Streit darum, ob man Bahnsteige spalten kann oder nicht ist nicht übermäßig wichtig. Problematisch wäre es nur, ein System einzuführen, das nur mit gespaltenen Bahnsteigen funktioniert, denn niemand hat diese Angelegenheiten bisher entschieden. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiki Nicht-Streitpunkt public_transport name/ref
Hi zusammen, im Wiki zu public_transport=platform steht in der englischen und deutschen Fassung m.E. Unsinn zum Key name und zum key ref. Das Problem: Das Wiki sagt klar, dass hier die Bahn-/Busteignummer stehen soll. Im Proposal ist nicht ganz klar formuliert, worauf sich name und ref beziehen. Aus der Recommendation im Proposal (steht auch im Wiki) geht aber klar hervor, dass es sich auf den Bahnhofsnamen und nicht den Gleis- oder Steignamen beziehen soll: Die Angabe soll gemacht werden, wenn es keine stop_area für die Station gibt, ansonsten ist sie optional. (In der stop_area steht der Bahnhofs-/Haltestellenname.) Das macht überhaupt keinen Sinn, wenn hier eine Bahn-/Bussteignummer erwartet wird. Die Angabe der Gleisnummer soll laut Wiki optional sein, wenn der Bahnhofsname schon in der stop_area steht; wenn dort aber kein Bahnhofsname steht, dann soll man die Gleisnummer schreiben ... (der Bahnhofsname steht dann nirgendwo mehr). Sinn ergibt es dagegen zu sagen: wenn der Bahnhofsname nicht in Form einer stop_area angegeben ist, dann soll man ihn schreiben; sonst kann man es auch sein lassen. Das Ganze hat eine praktische Bedeutung, den bei immer mehr Zuglinien kann man nicht mehr durch Draufsehen Fehler in der Bahnhofsreihenfolge entdecken, da steht jetzt nur das er nach Duisburg Hbf erst an Gleis 5 und dann an Bahnsteig 7 und 8 hält. Wie kann man da jetzt vorgehen? Auf der Diskussionsseite was eintragen führt augenscheinlich nicht zu Diskussionen. frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hintergrundkarte für Zeitungen
Am Sat, 13 Jul 2013 23:06:55 +0200 schrieb Volker aeon...@gmx.de: Die Thüringer Allgemeine nimmt zum Beispiel STEP MAP Das liefert ja schon so einiges an Komfort. Ich dachte jetzt eher an etwas wie die Exportfunktion auf www.openstreetmap.org -- nur mit einer eher detailarmen Karte. Die Redaktion könnte dann mit ihrem Lieblingsmalprogramm drübermalen. Danke und frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hintergrundkarte für Zeitungen
Am Sun, 14 Jul 2013 13:47:45 +0200 schrieb Frederik Ramm frede...@remote.org: Maperitive + Overpass-Download + eingebauter Google Maps-Style liefert eigentlich auch ganz gute Resultate, vor allem kommt da dann Illustrator-kompatibles SVG raus, und damit koennen die meisten ganz gut weiterarbeiten. Danke und frohes Mappen, Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Kamera synchronisiert keine Zeit
Am Mon, 15 Jul 2013 00:04:10 +0200 schrieb Stephan Knauss o...@stephans-server.de: Für eine Kamera die mit einem GPS Empfänger eigentlich eine sehr genaue Zeitbasis hat ein Armutszeugnis. Gerade wenn man die Uhr jederzeit auf einen korrekten Wert stellen kann, braucht man eigentlich keine genau gehende Uhr und der Hersteller kann hier sparen. Dass dann später die Software die Uhr fast nie stellt, habe ich auch schon auf einem Smartphone gesehen -- egal ob das GPS sowieso schon läuft oder nicht. Softwarefehler. Dieser Effekt zieht sich durch die Technikgeschichte. Ich hatte mal einen DCF77-Zeitsignal-Empfänger, der ausschließlich beim Einschalten (und um Mitternacht oder so) seinen Empfänger eingeschaltet hat -- ansonsten lief da eine sehr ungenaue Uhr. bis dann Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hintergrundkarte für Zeitungen
Hi, gibt es eigentlich irgendwelche Kartenquellen, die man Lokalredaktionen oder anderen kleinen Redaktionen (als Einstieg) empfehlen kann. So eine reduzierte Hintergrundkarte, fertig mit Lizenzhinweis zum Draufrummalen für Bauarbeiten, Schützenfeste, neue Busstrecken etc.? So was wäre dann ja auch was zum Ausdrucken und verteilen, wenn es Straßensperrungen bei Straßenfesten, Gemeindefesten u.ä. gibt. frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Am Fri, 12 Jul 2013 11:35:17 +0200 schrieb Thorsten Alge m...@thorsten-alge.de: Weiter wäre ein bereits angesprochenes Belohnungssystem mit Badges, wie vielleicht von Foursquare, Diablo III oder WoW bekannt, eine coole Sache die sicher den einen oder anderen Mapper bei Laune hält. Hier könnten Badges in drei Stufen... Tja, aber wollen wir Leute, die man damit bei Laune kann, bei Laune halten? Mit gefällt die jetzige Zusammensetzung der Mapperschaft -- lauter Leute, die ohne Badges und Postkarten mitmachen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Hi, Am Sat, 06 Jul 2013 19:20:45 +0200 schrieb Peter Wendorff wendo...@uni-paderborn.de: Geschwindigkeitsbegrenzungen: keine Ahnung, ob die Straßenbahnen da andere haben, aber zumindest wär das Blödsinn, da der Verkehrsfluss der gleiche ist. Doch, haben sie manchmal (z.B. nachts in Kurven in Wohngebieten damit es nicht so sehr quietscht). Und was sehr viel häufiger vorkommt: Die Höchstgeschwindigkeit ist unbekannt -- wie soll man das dann angeben? Wenn jetzt jemand maxspeed:tram sagt, dann schlage ich vor, statt dessen für Autos maxspeed:autos zu nehmen -- natürlich nur, wenn da Straßenbahnen oder Züge fahren. :-) frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hi, Am Sun, 7 Jul 2013 08:19:17 +0200 schrieb Tracy Kasperczyk kasperc...@mentzdv.de: ... soll globale_id_pt = * (IFOPT Nummer) heißen. Ich würde es eher ifopt_ref nennen. Jede Suchmaschine liefert dann passende Ergebnisse für den verwirrten Mapper. Zum Konzept: Falls ihr dabei Bahnsteige braucht, die nur zu einem Gleis gehören -- man die Bahnsteige also längs spalten müsste -- dann habt Ihr ein Problem. OSM könnte sich gegen längsgesplittete Bahnsteige entscheiden. Falls Ihr mit Bahnsteigen in mehreren Teilen nicht klar kommt. OSM hat sie wegen der Regelung mit Brücken. Der Mainzer Hauptbahnhof hat z.B. sowas auf Gleis 5: Eine Brücke mitten im Bahnsteig sorgt für eine Quer-Aufteilung des Bahnsteigs. Auch in Mainz kann man doppelte Benennungen von Bahnsteigen sehen, die so auch in den Fahrplänen auftauchen. Es gibt sowohl ein Gleis 3 als auch Gleise 3a und 3b, obwohl das Ganze nur eine Bahnsteigsseite ist. Dann gibt es noch Halte, bei denen gleichzeitig an zwei Bahnsteigen gehalten wird. Das findet man z.B. bei der wie-auch-immer-sie-gerade-heißt-Arena in Düsseldorf. Was ist mit Ersatzhaltestellen bei Baustellen. Bei längerfristigen Baustellen nehmen wir die eine gern aus den Linienrelationen raus und die Ersatzhaltestelle kommt rein. Was sollte dann mit der Nummer passieren? Ihr braucht vermutlich die einzelnen Bahnsteige. Wo die nicht gemappt sind, könnt Ihr sie natürlich eintragen, wenn das mit der Lizenz hinkommt. Aber dabei müssen alle benutzenden Relationen angepasst werden. Man muss also plötzlich Bahnsteig- oder Bussteignummern aller Linien wissen und eintragen dürfen. Das gilt dann auch für die Fahrzeuge von Nicht-Auftraggebern! (Zum Beispiel in den Überlappungsgebieten von Verkehrsverbünden.) Ist das Problem wirklich lösbar? MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Am Sun, 07 Jul 2013 14:22:48 +0200 schrieb fly lowfligh...@googlemail.com: Dies kann man in eine Linie packen. Wenn ich nun die Schiene separat zeichne sind sie neben der Straße. Es ist völlig in Ordnung, Objekte wie die Straße als Linie (also mit der zeichnerischen Breite Null) darzustellen -- aber es hat Konsequenzen und mit denen muss man sich abfinden. Dann ist neben der Straße nun mal etwas anderes als neben der Linie, die die Straße darstellt. Die Wiese liegt vielleicht direkt neben der Straße, hat ja dann aber gewöhnlich mehrere Meter Abstand zur Linie, die die Straße darstellt. Das ist doch völlig OK (solange das niemand innerhalb eines Wald-Multipolygons macht und so unbeabsichtigt äußerst längliche Wälder erfindet). frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Am Sat, 06 Jul 2013 15:43:18 +0200 schrieb fly lowfligh...@googlemail.com: Eigentlich sollte es möglich sein mit zB switch:direction=left/right die Richtung anzugeben. Mensch kann dann zwar immer noch nur einen Punkt für zwei Weichen verwenden, aber funktional wäre es. Somit braucht es nur noch eine neue Kategory für die Weichenbezeichnung: switch:???=yes Für den Verlauf auf der Straße kann analog zu lanes auch tracks verwendt werden. tracks:placement=* käme also in Frage. Einziges Problem an der Sache sind nur noch die Renderer welche bis heute mit tracks=* nichts anfangen können. Die meisten Schienen laufen nicht auf Straßen und im Schienenverkehr gilt eigentlich wie im Autoverkehr, dass baulich getrennte Wege getrennt erfasst werden. Im Schienenverkehr zählt dabei natürlich die bauliche Trennung für Schienenfahrzeuge. Soll man da jetzt ein total anderes Konzept benutzen, nur weil die Schienen auch mal auf einer Straße laufen können? Die Schienenwege haben außerdem auch andere Wegenamen, Geschwindigkeitsbegrenzungen, Einbahnregelungen, Ampeln, Vorfahrtsregeln, Abbiegeverbote usw. Ich denke, dass die Schienen weiterhin außer in einfachen Fällen als ganz getrennte Wege erfasst werden sollten. Wenn die Spuren des Asphaltverkehrs wegen der Schienen für Radfahrer problematisch sind, dann sollte das bei den Spuren als Gefahrenquelle völlig unabhängig vermerkt werden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM-Darstellung beeinflussen
Hi, kann man die Darstellung von Relationen in JOSM beeinflussen? Es geht um Texte wie etwa 'Öffentlicher Nahverkehr(xyz...', die ja auf einer Erkennung der entsprechenden Tags beruhen. Ist das in JOSM Teil des Programms oder der Konfiguration? Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Darstellung beeinflussen
Am Fri, 5 Jul 2013 21:10:14 +0200 schrieb Jo winfi...@gmail.com: Kann dies dir weiterhelfen: http://josm.openstreetmap.de/wiki/NameTemplate Ich seh es mir mal genauer an. Danke Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Darstellung beeinflussen
Am Fri, 5 Jul 2013 21:10:14 +0200 schrieb Jo winfi...@gmail.com: Kann dies dir weiterhelfen: http://josm.openstreetmap.de/wiki/NameTemplate Ja, funktioniert. Genau das, worauf ich gehofft hatte. (Ich teste ein Public Transport Proposal und würde gern wissen, ob die Relationen im JOSM übersichtlich sind und wo ich noch dran drehen muss) Danke Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am Thu, 4 Jul 2013 12:54:30 +0200 schrieb jotpe jotpe@gmail.com: Ich schreibe immer eine Mail an talk-de mit dem gleichen Betreff. Der Betreff ist dafür nicht wichtig. Nimm bei der Mail auf die Du antworten willst den Antworten-Knopf statt eine neue Mail zu schreiben. Anders rum ist es genauso wichtig: Nicht den Antworten-Knopf nehmen, wenn es eine neue Mail sein soll. frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pseudonamen
Hi, Am Sun, 30 Jun 2013 12:50:38 +0200 schrieb Stephan Wolff s.wo...@web.de: Spricht etwas dagegen, solche Texte von name nach description zu verschieben? Ja, so global schon (sprich: Nein, außer...) Für die Relationen legt die Beschreibung der Relationen die Bedeutung der Relationstags fest. So ist im Public Traffic Proposal für den Namen von Linienvarianten angegeben: verkehrsmittel nr doppelpunkt from doppelpfeil to also z.B. Bus 17: Paris = Pelkum Das sollte man nicht ändern, obwohl es ziemlich sicher so nicht woanders benutzt wird. Aber ansonsten bin ich sehr dafür. frohes Mappen Wilhelm (Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pseudonamen
Am Sun, 30 Jun 2013 19:29:41 +0200 schrieb Stephan Wolff s.wo...@web.de: Ja, ÖPNV und Bahnanlagen bieten eine große Vielfalt an Taggingvarianten. Gibt es schon einen Konsens, wie Bahnsteignummern zu erfassen sind (Gleis X/Bahnsteig X/X als name oder ref an Gleis oder Bahnsteig)? Absolut nicht. Wir haben da alle Varianten und deren Mixturen. Wenn man das Public Traffic Proposal genau liest, dann ergibt sich m.E. dass Haltestellenname und Haltestellen-ref an den Bus-/Bahnsteig gehören. Im Wiki steht zur Zeit jedoch, dass man da die Bahnsteignummer eintragen soll (was die daneben stehende Recommendation völlig sinnlos macht). Ich hab auf dem Gebiet kapituliert. Retten kann man das Ganze höchstens, wenn man getrennte Namen definiert: 1. Der Name der Haltestelle, wie er auf den Schildern zu finden ist. (etwa PT_name) 2. Der Name/Nummer des Bus-/Bahnsteigs (etwa PT_subname) (ohne Zusätze wie Bussteig, bei zweien mit ;) 3. Der ortsübliche Name der Gesamthaltestelle (etwa PT_supername), wenn mehrere Namen existieren. Z.B. unter Punkt 1 Hilden Süd für die Bahn, Hilden Süd S für die Bushaltestelle am einen Ende des Bahnsteigs und Hilden Süd S/Talstraße für die Bushaltestelle am anderen Ende. Da könnte man vielleicht einen Gesamthaltestellennamen wie Hilden Süd brauchen. 4. Suchnamen für Fahrplanauskünfte gibt es schon.Eine Haltestelle wie Nordfriedhof kann man nur mit Hilfe von ref_name=Nordfriedhof, Wesel finden. MfG Wilhelm (Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Outdoor Androide von Garmin!
Hi, Am Tue, 25 Jun 2013 16:49:08 +0200 schrieb Benjamin Lebsanft benja...@lebsanft.org: ...endlich auf nem Gerät mit ... gutem GPS ... Bei einer Wanderung habe ich ein Garmin eTrex30, ein Mobistel Cynus F3 und ein Sony-Ericsson Xperia pro aufzeichnen lassen. Die Smartphones liefen mit GPS dauernd an und alle Geräte bekamen einige Minuten Vorlaufzeit ohne Bewegung. Ich hatte mit erheblichen Qualitätsunterschieden in den Tracks gerechnet und die waren nicht da. Der Problempunkt lag eher darin, dass ich nach schätzungsweise 6-7 Stunden mit den Smartphones genauso gut hätte telefonieren können wie mit dem Garmin. Wilhelm(Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine OSM Flusskarte? - OpenSeaMap?
Am Sat, 15 Jun 2013 15:47:09 +0200 schrieb Tirkon tirko...@yahoo.de: Habe ich da etwas übersehen? http://tools.geofabrik.de/osmi/?view=water Die Karte hat zwar eigentlich einen anderen Sinn, aber ist evtl. dafür brauchbar. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hi, Am Wed, 29 May 2013 08:33:11 +0200 schrieb Peter Wendorff wendo...@uni-paderborn.de: ...oder sehe ich irgendeine Anwendung der genau korrekten offiziellen Farbcodes nicht? in der Praxis wäre das völlig ausreichend. Das sehe ich auch so. Die offiziellen Farben einer Buslinie, die mit colour getaggt werden sollen, haben nichts mit offiziell festgelegten Farbcodes für die Linienpläne zu tun. colour ist gemacht für Städte wie Jönköping. Dort sagt man im Alltag nehmen sie die Linie Rot. Dass das die Linie 1 ist, wissen die meisten vermutlich garnicht. Nur die aus der Stadt heraus führenden Busse werden dort im Alltag mit Nummern bezeichnet. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bug? Key:colour gleich trotz Unterschieden in offizieller CMYK-Definition
Hi, Am Wed, 29 May 2013 14:51:23 +0200 schrieb Tobias Conradi mail.2...@tobiasconradi.com: colour ist gemacht für Städte wie Jönköping. Dort sagt man im Alltag nehmen sie die Linie Rot. Dass das die Linie 1 ist, wissen die meisten vermutlich garnicht. Nur die aus der Stadt heraus führenden Busse werden dort im Alltag mit Nummern bezeichnet. Wo ist das definiert? Ich finde nur: http://wiki.openstreetmap.org/wiki/Key:colour The value should be: an RGB color code (hex triplet) Bei http://wiki.openstreetmap.org/wiki/Relation:route findet man bei den Straßenbahnen (woanders ist die Formulierung weniger klar): The tram, subways and buses might have official colour identifiers in some cities. Es geht also um colour identifiers wie z.B. Rote Linie. Offiziell verstehe ich so, dass die Benennung mit Farben statt Nummern nicht nur eine Gewohnheit der Bevölkerung ist, sondern auch der Verkehrsbetriebe. Aber eigentlich ist es Quatsch, was ich hier rede. colour ist massiv im Gebrauch und die einzig jetzt noch vernünftige Frage ist: Was weiß man, wenn man colour=... vorfindet?. Zumindest für den ÖPNV neige ich zur Antwort gar nichts. Meist wollte der Mapper einfach gern diese Farbe in einer der ÖPNV-Karten sehen. Das Tag ist verbrannt. Bitte ignoriert, was ich zur Definition geschrieben habe. Trotzdem frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aldi Navi mit vorinstallierten OpenStreetMap-Karten rechtens?
Hi, Am Wed, 29 May 2013 18:29:25 +0200 schrieb Peter Wendorff wendo...@uni-paderborn.de: Warum die Ansicht auf lists.openstreetmap.org da anders funktioniert, kann ich so auf die Schnelle nicht sehen; würde mich aber interessieren, wie(so) das da so angezeigt wird. Weil es so viele Leute falsch machen. Darauf wird Rücksicht genommen und das führt leider dazu, dass die Leute darin bestätigt werden. Wenn ein neuer Thread mit einem alten Betreff eröffnet wird, dann ist das gewöhnlich der Irrtum des Schreibers, dass Threads sich aus dem Betreff ergeben würden. Es wird in der Anzeige einfach automatisch korrigiert. Ich halte nichts davon. Aber ich muss zugeben, dass manche Listen ohne sowas unlesbar wären. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Route von Garmin wieder löschen?
Hi, Am Tue, 28 May 2013 16:48:30 +0200 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Wenn es mit gpsbabel nicht gehen sollte,... Man kann die Ideen kombinieren: Rausholen aus dem Gerät mit: gpsbabel -i garmin -f usb: -o gpx -F xxx.gpx Editieren mit emacs oder vi (je nach Ideologie) und dann (nach Löschen aller Waypoints im Gerät?) zurückschieben: gpsbabel -i gpx -f xxx_reduced.gpx -o garmin -F usb: Evtl. braucht man da noch irgendwo -c latin1. Wohl nur, wenn man in eine Datei ohne Umlaute beim Editieren welche reinmacht. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Route von Garmin wieder löschen?
Hi, Am Tue, 28 May 2013 17:11:41 +0200 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: ... GPX zur Route unwandeln ... das ist etwas irreführend. Tracks zu Routen umwandeln passt. In einem GPX können Tracks, Routen, Waypointlisten, ... stehen. GPX ist eher ein Containerformat. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Route von Garmin wieder löschen?
Hi, Am Tue, 28 May 2013 17:11:05 +0200 schrieb fly lowfligh...@googlemail.com: Ja, das geht durchaus. Nur scheint der Datenträger nichts mit den Tracks im Gerät zu tun zu haben. Ich habe es zumindest nicht geschafft ein GPX direkt vom Datenträger auf die Karte zu bekommen. Ich musste die Daten via USB (serielles Protokoll) in den Gerätespeicher spielen. Verstehe ich nicht, kenne aber die eTrex Serie nicht gut. Beim Vista kommt man -- wenn ich mich da recht erinnere -- nicht an die internen Dateien ran. Der stellt also keine USB-Platte mit internen Daten bereit; es wird nur die eingelegte Speicherkarte als Platte angeboten. Man kann mit dem Gerät nur im Garmin-Protokoll reden und Daten hoch- oder runterladen. Das kann z.B. gpsbabel. Neuere Geräte -- auch eTrex -- machen das anders. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Route von Garmin wieder löschen?
Hi, Am Tue, 28 May 2013 17:48:49 +0200 schrieb Toni Erdmann toni.erdm...@web.de: Das kommt beim Legend auch an die internen Daten ran, wenn man den entspr. Treiber mit installiert. Ja, genau. Man kommt bei den älteren Geräten an Daten, aber nicht an Dateien. Die Daten werden anders als bei den moderneren Geräten nicht als Dateien einer USB-Platte bereitgestellt. Daher braucht man ein Programm (Treiber, Modul), dass das Garmin-Protokoll beherrscht. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Genauigkeit des etrex VISTA HCx
Hi, Am Sun, 19 May 2013 10:57:10 +0200 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Der erste Eindruck ist aber, dass die Genauigkeit recht übel zu sein scheint. Und das obwohl das etrex VISTA HCx doch einen MTK2-Chip haben sollte. Kann das wer bestätigen oder hat mein Gerät eventuell doch einen Defekt? Ich habe keine schlechten Erfahrungen gemacht. Wenn so ein Gerät lange unbenutzt war, dann sucht er anhand der uralten Bahndaten nach Satelliten, die derzeit garnicht sichtbar sind. Wenn die Daten nicht ganz so alt sind, dann ist nur die Genauigkeit beeinträchtigt, weil er ohne aktuelle Daten nicht richtig rechnen kann. Wenn er 16 Minuten ununterbrochenen Empfang irgendeines Satelliten hat, dann sind sicher alle Bahndaten aktuell. (Jeder Sat. sendet alle 30s einen Satz Bahndaten und ist also nach 16 Minuten mit allen Satelliten durch. Bei zwei Satelliten sind es aber nicht 8 Minuten, da die Daten versetzt gesendet werden und einer irgendwann nur Sachen sendet, die man schon vom anderen bekommen hatte. Neue Daten gibt es übrigens jeden Sonntag.) Danach müsste das Ding anständig funktionieren. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie neue Firmware für etrex VISTA HCx finden und aufspielen?
Am Fri, 17 May 2013 17:56:42 +0200 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Und wenn es wirklich schlimm wird, dann kann man sowas wohl durchaus reparieren: http://rubysrudel.de/2009/11/01/gummirand-beim-garmin-etrex-vista-hcx/#comment-133 Wenn sich das Gummi löst, dann ist der Kleber wieder zähflüssig geworden. Aus den Ecken geht er auf die Finger und dann auf das Glas. Man bekommt es wieder weg, aber das ist das eigentlich Störende an der Sache. Ich habe -- da ich nicht gut darin bin, Sachen auf Anhieb an die richtige Stelle zu bekommen -- einen gut korrigierbaren dauerhaft elastischen Kleber genommen (von Uhu: Kleben, Montieren, Dichten) und das Ergebnis ist gut. Den alten Kleber hab ich mit einem Schraubenzieher abgeschabt und danach Isopropanol zum Reinigen benutzt. Die Plastikfolie bleibt dabei drin! In der Nähe der Aussparungen ist man mit dem Kleber sparsam und überall woanders kann man rausquellendes ohne Hektik bequem entfernen. Zudem bin ich relativ günstig an das Ding gekommen. Nach ein paar erfolglosen Geboten hatte ich es endlich für unter 100 EUR inklusive Versand. Geht erstaunlicherweise nach wie vor sehr teuer raus. Das Ding ist auch einfach gut -- bis auf den Gummikleber. Die POIs mache ich nur noch per Digitalkamera, weil das auch während der Fahrt geht. Die Kamera muss nicht viel können. Vor oder während der Tour fotografiert man einmal die Uhrzeit auf dem GPS-Gerät und hat so die genaue Zeitabweichung der Kamerauhr. JOSM unterstützt diese Art der Kalibrierung gut. frohes Mappen Wilhelm (Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 09:56:57 +0200 schrieb Simon Poole si...@poole.ch: cliff:left=up Sollte das nicht besser high/low sein? Mapper A: Von links gesehen ist es eine Aufwärtskante. Mapper B: Nach links geht es aufwärts. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 09:56:57 +0200 schrieb Simon Poole si...@poole.ch: Wurde schon vorgeschlagen, aber halt nochmals: man könnte die (jetzt ohne waterway) 7 Tags mit :right und/oder :left Tags ergänzen. Wenn ich richtig gesehen habe wäre es sinnvoll: jeweils up, down, high,low oder inside, outside als Wertpaare zu verwenden. Natürlich ist eigentlich nur jeweils ein Zusatztag wirklich nötig. Mit Zusatztags, die die Bedeutung von Tags verändern, machen aber alte Programme Ärger, da sie die Richtungstags ignorieren werden. Das bringt die Mapper dazu, lustige Taggingideen auszuprobieren. Außerdem sollten die Zusatztags ja immer vorhanden sein, damit die Sache für die Mapper klarer wird. Aus Kompatibilitätsgründen müsste man aber den jetzigen Zustand zum Default erklären. Dann werden ihn aber viele weglassen. Das Problem könnte man aber mit einem Stichtag und einem Bot lösen. Auch wenn es hässlich ist: ein natural=cliff2 mit cliff2:left=high würde Probleme vermeiden. Na ja, vielleicht wäre natural=edge oder natural=slope oder noch was anderes besser. (Bei coastline hätte man die Gelegenheit, endlich das Wort ocean im Tag unterzubringen -- das würde viele Reparaturarbeiten in Seen und Flüssen einsparen.) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 12:43:30 +0200 schrieb Henning Scholland o...@aighes.de: für Objekte ohne Zusatztag werden die Auswerter und Editoren sich schon an dem bisherigen Default orientieren. Wenn dann in Zukunft ein solcher Weg ungedreht wird, wird der Editor also bspw. dann das entsprechende Zusatztag setzen. Ich dachte mehr an die Probleme danach. Noch nicht umgestellte mkgmap Eingabedateien würden falsche Karten produzieren. Ein noch nicht umgestellter OSMI würde falsche Fehlermeldungen erzeugen. Noch nicht umgestellte Renderer würden Mapper zu unsinnigen Änderungen anregen. Die Probleme sind in diesem Fall nicht sooo gravierend. Aber sie sind ein Beispiel für die Probleme beim Umdefinieren von Tags. Jedes Umdefinieren von Tags entwertet die Tags oder bisher geleistete Arbeit in Programmen, Konfigurationsdateien oder beim Mappen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 16 May 2013 13:37:12 +0200 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Das ist der Preis der Flexibilität, wir könnten ja nichts mehr hinzufügen oder anpassen, wenn wir diesem Argument folgen würden. Ich sage nicht, dass das völlig von der Hand zu weisen ist, aber es ist eine Abwägung, der status quo hat halt auch Probleme, die man vorher nicht vorhergesehen hatte. Doch, sowas kann man machen. Dazu braucht man die Möglichkeit anzugeben, auf welche Definition sich das Tagging bezieht (Normen). Etwa so: Nach Abstimmung eines Proposals wird dieses eingefroren (unveränderlich gemacht) und ihm wird zentral eine Nummer gegeben. Der Mapper kann (nicht: muss!) mit z.B. OSM_NORM=4711 darauf Bezug nehmen. Wird später ein Nachfolger verabschiedet, so erhält er eine neue Nummer. Man kann nun den alten Datensätzen ihre Bedeutung noch vollständig ansehen und sie auf die neue Form umstellen (oder sie so lassen). Man könnte auch alte Normen als deprecated deklarieren und damit zur Umstellung durch Bots oder Mapper auffordern. Verarbeitende Programme wüssten dann, was sie verarbeiten können und was nicht. Für die Editoren/Inspektoren könnte das die Prüfung auf Fehler enorm verbessern, da sie einen ganze Sätze von Prüfungen anhand der Nummern in OSM_NORM=x;y;z aktivieren könnten und nicht auf die kleinsten gemeinsamen Eigenschaften beschränkt wären. Ich denke, dass solche Normen große Vorteile mit sich bringen würden. Allerdings auch die Möglichkeit, dass Verbesserungen immer nur als zusätzliche Möglichkeiten aufgefasst würden. Da müssten wir überlegen, mit welchen sozialverträglichen Vorgehensweisen man Ausufern verhindern kann. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am Thu, 16 May 2013 14:53:16 +0200 schrieb Michael Buege mich...@buegehome.de: Etwa so: Nach Abstimmung eines Proposals wird dieses eingefroren (unveränderlich gemacht) und ihm wird zentral eine Nummer gegeben. [...] Abstimmungen über Proposals haben keine bindende Wirkung und werden diese auch nicht erlangen. Daran würde sich durch den Vorschlag auch nichts ändern. Es würde nur eine Nummer vergeben, die sich dann verbindlich auf diesen Vorschlag bezieht ... nicht mehr. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Tue, 14 May 2013 08:42:42 +0200 schrieb Henning Scholland o...@aighes.de: Bspw. wenn ich einen Teil des Umrisses eines Waldes parallel verschieben möchte, um es als Fluss etc. zu nutzen. Dann trenne ich den Wald auf, mache die Operationen und dann schließe ich den Wald wieder. Da ist das Erzeugen des MP überflüssig. OK. Hmmm. Ist hab's nicht ausprobiert: vielleicht verschwindet das MP sogar automatisch wieder, wenn es nur noch ein Element hat? Ich finde aber, dass die Vorteile überwiegen. Vermutlich aber wohl deshalb, weil ich viele solche kaputtgesplitteten Flächen repariere. :-) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ferienhaussiedlung
Hi, Am Tue, 14 May 2013 09:44:32 +0200 schrieb tumsi tu...@gmx.de: Die tourism-Tags finde ich unpassend, weil es sich nur in mäßigem Rahmen an Touristen richtet, wie z.B. im Fall von CenterParks u.ä.. Auch einzelne Häuschen, die vielleicht ein paar Wochen im Jahr vermietet und nicht privat genutzt werden, entsprechend zu taggen, finde ich auch nicht richtig. Zudem würde es sehr mühselig werden, diese Informationen zu recherchieren. Die Abgrenzung ist da wirklich schwierig. Es gibt ja vom Campingplatz mit vielen Häuschen bis zum hier sind ja ein paar Häuschen-Gebiet alles. Zumindest bei den dichteren Stugbys mit einheitlicher Adresse ist wohl tourism=camp_site üblich. landuse ist oft ganz unpassend, weil die Häuschen so locker stehen, dass es immer noch im Wesentlichen Wald ist. Wenn es einen Namen gibt, dann könnte man vielleicht place=locality und name=xy Stugby nehmen. Ist nicht schön, aber evtl. hilfreich. Das Problem ist vermutlich genauso unlösbar wie das mit den schwedischen Badeplätzen, für die es ja auch nichts wirklich passendes gibt. Grüß mir Schweden, ich komme erst nächstes Jahr wieder hin. Med vänliga Hälsningar Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Tue, 14 May 2013 10:22:59 +0200 schrieb Henning Scholland o...@aighes.de: Hallo, das hört sich sinnvoll an. Hast du das den josm-devvs schon vorgeschlagen? Henning Nein. Ein Vollautomatik würde vielleicht auch nicht zum JOSM passen. Ich bin da unsicher. Vielleicht eher in Form von Rückfragen: beim Splitten: Der aufzutrennende Weg beschreibt eine Fläche. Was soll mit ihr geschehen? a) Fläche beibehalten durch Erzeugen eines Multipolygons. b) Fläche löschen c) nur die Linie auftrennen. und beim Combine: Die Fläche könnte jetzt auch ohne ein Multipolygon formuliert werden. a) Ja, die Fläche ohne Multipolygon formulieren. b) Nein. Nur die Linien verbinden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradrouting Straßenbahnschienen
Am Mon, 13 May 2013 19:24:17 +0200 schrieb mf mfa...@uni-bremen.de: Ist das eine Ausnahme zur Regel, dass es physischer Trennung bedarf, um bei OSM einzelne ways zu zeichnen? Ja. Die meisten Schienen laufen nicht auf Straßen und die meisten Straßen haben keine Schienen. Da ist das Risiko groß, dass man bei Tags -- insbesondere bei der Diskussion neuer Tags -- sowohl bei den Straßen- als auch bei den Schienenfreaks den Sonderfall Schiene-auf-Straße übersieht und missverständliche Tags baut. (Man hat auch schon einige doppelte oder missverständliche wie usage, maxspeed, oneway, ref, ...) Deshalb sollten es getrennte Wege über dieselben Knoten sein. OSMI klassifiziert es ebenfalls als Fehler, wenn die Tags in einem Way gemischt werden. Aber natürlich ist auch das alles nicht unumstritten. Es ist aber meines Wissens unstrittig, dass die von den Schienen ausgehenden Gefahren für Radfahrer auf den Straßen/Spuren irgendwie vermerkt werden sollten, so dass Rad-Programme nicht auch noch Schienennetze untersuchen müssen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Am Fri, 10 May 2013 07:08:32 +0200 schrieb Wilhelm Spickermann o...@spickermann-d.de: Es gibt mehrere Splittingprobleme ... Ich habe den iD vorhin erstmalig benutzt und war von der Behandlung des Splittings angenehm überrascht. Anders als bei Potlatch und genauso wie im JOSM werden die Routen beim Splitten gewöhnlich nicht kaputt gemacht; das Einfügen der beiden Wegteile erfolgt gewöhnlich in der für die jeweilige Relation richtigen Reihenfolge an der richtigen Stelle: also insbesondere in den verschiedenen betroffenen Relationen mit i. A. verschiedener Reihenfolge. Wie beim JOSM funktioniert dies leider nicht, wenn die Vorgänger-/Nachfolgerwege nicht geladen sind. Beim JOSM kann man zur Vermeidung dieses Problems eine beliebig kleine Umgebung der Endpunkte vor dem Splitten laden. Vermutlich reicht es beim iD, die Endpunkte vor dem Splitten mal ins Bild zu bringen; das habe ich aber nicht ausprobiert. Zumindest in dieser Hinsicht ist der iD ein großer Fortschritt gegenüber Potlatch. Ich rechne da auf jeden Fall mit weniger Reparaturarbeiten an Relationen als bisher. Wilhelm PS: Eine zufällig betroffene Abbiegerelation sah bei den Tests auch gut aus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Ergänzung: Beim Splitten in sich geschlossener Linien mit Flächentag wird beim Splitten völlig richtig ein Multipolygon erzeugt und die Fläche bleibt erhalten. Das ist deutlich besser als beim JOSM. Wow. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hallo Eckhart, Am Sat, 11 May 2013 15:40:32 +0200 schrieb Eckhart Wörner ewoer...@kde.org: Wenn an Kreisverkehren von Anfang an für Routen richtig gesplittet wird, sind auch nachträgliche Splits kein Problem mehr. Ich glaube nicht, dass nur gesplittete Kreisverkehre richtig sind. Es ist etablierte Praxis, Kreisverkehre komplett anzugeben obwohl sie nicht komplett umlaufen werden und schon garnicht komplett vom Anfangs- zum Endpunkt. Wenn man das jetzt noch ändern wollte, dann müsste man eine große Abstimmung machen und dann einen Bot über die Welt laufen lassen wie beim Lizenzwechsel. Ich hatte nur einen einzigen Fall, in dem ich einen Kreisverkehr splitten musste. Da war in Frankreich eine Bushaltestelle so in den Kreisverkehr gelegt, dass der Bus eine zusätzliche Runde drehen musste. Soll man jetzt nur wegen exotischer Fälle alle Kreisverkehre splitten? Außerdem: wenn alle Kreisverkehre bereits gesplittet wären, dann wäre das Splitten dort immer noch ein Problem, nämlich das in Punkt zwei erwähnte. Nicht einmal JOSM macht das immer richtig. Es entfallen dann nur die zusätzlichen Splits -- die hat man dann schon vorher gemacht. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Sat, 11 May 2013 17:42:32 +0200 schrieb Eckhart Wörner ewoer...@kde.org: Ich bestreite nicht, dass ein Mapper das so handhaben, aber sicher nicht die Mehrheit. Ja. Manche machen es so und manche machen es anders. Wenn es dabei auf Mehrheiten ankommt, dann nur auf die Mehrheit bei einer Abstimmung zur Frage, ob man eine Praxis für falsch erklären soll. Wenn jemand einen Kreisverkehr splittet, dann füge ich ihn nicht wieder zusammen, sondern repariere statt dessen mühevoll die Relationen. Die Gründe, weswegen Kreisverkehre von vielen nicht gesplittet werden: a) JOSM hat dann früher Kreisverkehre als Flächen behandelt und ausgefüllt gezeichnet b) JOSM zeigt dann ein Kreisverkehr-Icon in Relationen an c) JOSM kann immer noch nicht mehrere Ways im Kreis anordnen Also für mich hat noch nie irgendeiner dieser Gründe eine Rolle gespielt. Interessanterweise beginnen alle diese Punkte mit JOSM… (wahrscheinlich gibt es auch ein paar Punkte, die mit Potlatch… oder iD… beginnen). Also an einem Editor-War möchte ich mich nicht beteiligen. Es gibt keinen stichhaltigen Grund, warum Kreisverkehre so besonders sind. Doch sicher. Bei Relationen, bei denen sich die Gebrauchsrichtung aus der Abfolge der Member ergibt, ist der benutzte Teil des Kreisverkehrs auch ohne Splitting eindeutig identifizierbar. Das ist eine Besonderheit. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Sun, 12 May 2013 00:10:09 +0200 schrieb Eckhart Wörner ewoer...@kde.org: Das Argument lässt sich genauso auf eine Route A - B - C anwenden, bei der nur eine Teilstrecke von B verwendet wird. Auch wenn ich weiß, welches Teilstück von B verwendet wird, sollte ich B trotzdem passend auftrennen. Genau die gleiche Situation. Ja, das sehe ich ein. Allerdings würde -- da man das Argument auch auf A und C anwenden könnte -- das Ganze hinterher sehr unübersichtlich und fehleranfällig. Aber ich muss Dir zustimmen, dass diese Praxis eher historisch gewachsen als gut begründet ist. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 9 May 2013 17:52:36 +0200 schrieb Jo winfi...@gmail.com: Ich habe auch mal versucht ein Memberway der zu 2 route Relationen gehört zu löschen und das ist tatsäglich möglich, und sogar ohne Botschaft das etwas kaputgemacht wird. Dann auch mal mit PL2 versucht und der macht dasselbe Na ja, wenn der Weg nicht mehr da ist, dann ist in der Route auch in der Realität ein Loch ... darüber könnte man noch diskutieren. Klar wäre der Fall, wenn es nach dem Löschen eines Weges z.B. zweielementige Abbiegerelationen gäbe. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Thu, 09 May 2013 23:12:36 +0200 schrieb Tirkon tirko...@yahoo.de: Zudem wurde hier noch das Splitting genannt. Wo da genau das Problem mit ID bzw. Potlatch liegt, habe ich allerdings noch nicht ergründet. Möglicherweise wäre eine Kontaktaufnahme der ID-Programmierer mit denen von JOSM sinnvoll. Denn Letztere haben die Juckelpunkte um Relationen schon erkannt und behoben bzw. sprechen entsprechende Warnungen aus. Es gibt mehrere Splittingprobleme und man findet sie teilweise auch im JOSM. Ein im JOSM m.W. gelöstes Splittingproblem gibt es bei den Abbiegerelationen. Nur einer der beiden Teile des aufgeteilten Weges sollte in der Relation bleiben. Ein weiteres Splittingproblem haben wir bei den Relationen mit bedeutungsvoller Reihenfolge, also z.B. bei Routen nach dem Public Traffic Proposal. Hier wird die Durchfahrtrichtung nicht mit forward oder backward oder (=bidirektional) angegeben, sondern durch die Reihenfolge der Mitglieder in jeder Variante. Hier tritt z.B. in der einen Relation die Wegreihenfolge A,B,C auf und in einer anderen C,B,A. Spaltet man B auf, dann kann man es nicht einfach überall durch B1,B2 ersetzen, denn wenn A,B1,B2,C richtig ist, dann ist C,B1,B2,A falsch. Da muss dann C,B2,B1,A hin. Das macht der Potlatch falsch und der JOSM macht es nur dann richtig, wenn er die Elemente A und/oder C geladen hat. (Gewöhnt man sich als JOSM-Benutzer an, vor dem Splitten immer eine beliebig kleine Umgebung der Endpunkte des zu splittenden Weges zu laden, dann gibt es keine Probleme.) Ein drittes Splittingproblem gibt es bei den Kreisverkehren. Wenn ein Kreisverkehr Element einer Route ist, dann ist damit nur benötigte Teil des Kreisverkehrs gemeint. Splittet man ihn auf, dann gilt diese Sonderregel nicht mehr und man muss nicht zugehörige Teile wegwerfen und die anderen Teile sinnvoll umsortieren. Noch schlimmer: man muss alle anderen betroffenen Relation ebenso laden, den Kreisverkehr ggf. weiter splitten und bei allen nachkorrigieren. Das unterstützt keiner der Editoren. (Ich halte es meist für Quatsch Kreisverkehre zu splitten, aber es gibt andere Ansichten/Situationen und wenn man da splittet, dann gibt es dieses Problem.) Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.
Hi, Am Fri, 10 May 2013 07:08:32 +0200 schrieb Wilhelm Spickermann o...@spickermann-d.de: Ein drittes Splittingproblem... Ich hab noch eines vergessen: Ein viertes Splittingproblem haben wir bei in sich geschlossenen Wegen mit einem Flächentag. Wenn man hier hier aufspaltet, braucht man ein Multipolygon. Da unterstützt m.W. kein Editor. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturtrails in OpenStreetBugs
Hi, ich denke, dass es bei oft benutzten Tags wie highway=footway oder highway=cycleway nur noch eine relevante Frage gibt: Was weiß ich eigentlich, wenn ich diesen Eintrag in einem Datensatz von OSM finde? Je mehr verschiedene Auffassungen -- und sei jede einzelne noch so klar -- es in der Vergangenheit gab, desto geringer ist der Informationsgehalt. Da noch weitere Auffassungen hinzuzufügen, kann den Informationsgehalt nur weiter vermindern. Wenn die Bedeutungen zu unklar sind, dann kann man nur mit neuen Tags Klarheit schaffen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aktuelle AllinOne mit veralteten Daten
Hallo Mechtilde, Gibt es schon ne Lösung? nimm die von Thorsten Kukuk http://osm.thkukuk.de/ Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Hi, Am Sat, 20 Apr 2013 07:17:37 +0200 schrieb RainerU ra...@sfr.fr: ...proposed=bicycle anstelle von route=bicycle? In einer Relation mit type=route sollte auf jeden Fall route=* vorkommen. Das proposed müsste man also ggf. woanders unterbringen type=route, route=bicycle_proposed oder type=proposed_route, proposed_route=bicycle. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rechtschreibung und Zeichensetzung in den Karten
Am Sun, 14 Apr 2013 22:44:17 +0200 schrieb Hans Schmidt z0idb...@gmx.de: Wieso ist in diesem Fall eine Anpassung richtig, obwohl es etwas anderes als auf dem Straßenschild ist? Wieso ist aber eine Anpassung von fehlenden Leerzeichen falsch? Weil die Straße in jedem Falle Bahnhofstraße heißt. Wenn man den Namen in Fraktur setzt, dann wird ein anderes s gesetzt; der Name ändert sich dadurch nicht. Gestaltungseigenschaften des Schildes wie Schriftfarbe oder Fraktursatz sind nicht Bestandteil des Namens. Wenn dagegen der Stadtrat eine Straße Kurzestraße nennt, dann heißt sie eben so und OSM sollte diesen Namen wiedergeben. Natürlich kann man die Stadt auf den Irrtum hinweisen (in Aachen würde ich darüber aber nochmal nachdenken. Die hatten mal einen Oberstadtdirektor Kurze.) frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM2World
Hi, Am Mon, 15 Apr 2013 16:19:07 +0200 schrieb chris66 chris66...@gmx.de: Am 15.04.2013 15:47, schrieb Andreas Hubel: Ich weiß allerdings nicht ob O2W auch mit negativen IDs (wenn du neue Nodes/Ways noch nicht hochgeladen hast) zurecht kommt... Jepp, geht. Das zweite Problem mit OSM-Zwischenständen (also vor dem Hochladen) sind gelöschte Objekte. Werden sie dargestellt? Die sind ja noch in der Datei drin und könnten zum Problem werden -- in mkgmap hatte ich das Problem mal. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rechtschreibung und Zeichensetzung in den Karten
Hallo, man muss allerdings auch noch bedenken, dass bei Karten die richtige Wiedergabe des Namens von Bedeutung ist und dass dies nicht unbedingt der Rechtschreibung entspricht. Wenn der Stadtrat den Namen Passauerstraße vergibt, dann heißt die Straße so und sollte auch so in OSM auftauchen. Es spielt für OSM keine Rolle, ob es eine Benennung nach dem Herrn Passauer (dann wäre die Schreibweise richtig) oder eine Benennung nach der Stadt Passau (dann wäre die Schreibweise falsch) war. frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ich kann angezeigten Fehler in OSM beim Mappen im Raum Eschede nicht auflösen
Hi, Am Wed, 10 Apr 2013 12:37:19 +0200 schrieb Andreas Schmidt schmidt-postf...@freenet.de: Wenn ich es lernen kann, würde ich gern selbst sowas lösen können, aber ich weiss nicht, wie ich vorgehen soll. Es liegt m.E. nicht an Dir. Ich habe gerade mit JOSM 5836 in einer ganz anderen Gegend ein Rechteck gezeichnet, in zwei Linien gesplittet, ein MP mit den beiden Linien gemacht, building=yes und zwei outer ergänzt und bekam dieselbe Fehlermeldung Gebäude im Gebäude. Wilhelm (Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ich kann angezeigten Fehler in OSM beim Mappen im Raum Eschede nicht auflösen
Am Wed, 10 Apr 2013 13:45:06 +0200 schrieb Wilhelm Spickermann o...@spickermann-d.de: Ich habe gerade mit JOSM 5836 in einer ganz anderen Gegend ein Rechteck gezeichnet, in zwei Linien gesplittet, ein MP mit den beiden Linien gemacht, building=yes und zwei outer ergänzt und bekam dieselbe Fehlermeldung Gebäude im Gebäude. Es wird immer sonderbarer: bei einem Viereck, dass ich mit der Punktreihenfolge links oben, rechts oben, rechts unten, links unten gemacht habe, tritt der Effekt beim Splitten von links oben und rechts unten auf, während er beim Splitten an links unten und rechts oben nicht auftritt. Kann das jemand bestätigen? Wir sollten ggf. eine Fehlermeldung machen. Wilhelm (Weide) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie tagt man Tram-Haltestellen richtig?
Am Sun, 17 Mar 2013 22:52:48 +0100 schrieb Andreas Hubel a...@saerdnaer.de: Ist es sinnvoll die Namen da doppelt und dreifach zu pflegten? Eigentlich nicht. PT legt fest, dass sie in der stop_area genannt werden sollen und bei fehlender stop_area an den Objekten. Die Pflege der Linienrelationen ist aber sehr umständlich, wenn die Namen nicht an den Objekten stehen. Ich würde einfach die falschen Namen korrigieren. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naviagtion mit OSM-Karten unter Android
Am Mon, 18 Mar 2013 09:51:42 +0100 schrieb Peter Wendorff wendo...@uni-paderborn.de: - selbst erstellte Routen oder Tracks darstellen können: wenn ich [2] richtig verstehe, müsste das auch gehen; aber auch das: nie probiert. Eigentliche Routen wie in GPS-Geräten habe ich nicht gefunden. Aber Track GPX-Dateien kann man als Routen benutzen. In den Dateien angegebene benannte Waypoints zählen (Erfreulicherweise erst nach dem Aktivieren!) als Favoriten. Die GPX-Dateien kommen auf die SD-Karte, Speicherplatz ist also wohl kein Problem. Per Menü kann man eine GPX-Datei dann unterwegs aktivieren. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Nachrichtensammlung, Band 80, Eintrag 21
Hi, Am Mon, 18 Mar 2013 08:45:49 +0100 schrieb Wolfgang Wienke wo_wie...@gmx.net: Genau darum geht es mir. Man liest oft Erfahrungsberichte EINES users, die nowendigerweise sehr relativ sind. ich hoffte jemand zu finden, der Übersicht über MEHRERE solcher Produkte hat. Damit kann ich nicht dienen, aber vielleicht helfen auch ein paar Punkte zur Einschätzung der Erfahrungsberichte. Die Meldungen über Abstürze scheinen mir eher gerätespezifisch zu sein. Manche Leute haben ja augenscheinlich dauernd Abstürze, ich hatte noch nie einen. Probleme beim Fußgängerrouting sind nicht selten. Oft gehen sie auf fehlende oder fehlerhafte Einträge in OSM selbst zurück. Oft gehen sie aber auch darauf zurück, dass das Routing linienorientiert arbeitet und mit Flächen (z.B. Marktplätze) nichts anfangen kann. Da wird man dann immer entlang des Randes gelotst und diese Wege sind oft sehr lang im Vergleich zum wirklichen Weg quer rüber und werden dann als zu weit verworfen. Den Effekt findet man aber m.E. quer durch alle Programme und Navis. Zur Online/Offline-Kritik: Es ist nicht so, dass das Programm einen Online- und einen Offline-Modus hätte wie etwa Email-Programme. Man kann zusätzlich Länder oder Bundesländer auf die SD-Karte laden und diese Daten hat man dann auch ohne Datenverbindung. Da kann man sich dann bis zur Hausnummer runter durch die Menüs hangeln -- wenn in OSM diese Hausnummern erfasst wurden. Keine Datenverbindung hat man evtl. mitten im Wald oder im Ausland, wenn das Gerät auf bloß kein teures Datenroaming steht. Eine allgemeine Suche nach geographischen Namen geht auch ohne Offline-Daten. Es ist aber ja kein Problem, sich vor einer Fahrt ins Ausland mal eben den Datensatz zu holen oder ihn upzudaten. Ortsbestimmung manchmal unheimlich langsam: Meist holen sich Geräte die aktuellen Sat-Daten aus dem Internet. Ohne solche Daten geht GPS nicht oder schlecht. Wenn man keine Online-Verbindung hat, dann müssen die Daten von den Sats geholt werden. Wenn der GPS-Empfänger erst mitten im Wald eingeschaltet wird, nur einen Sat sieht (den aber dauernd), dann kann das 16Min. dauern. Diese Daten sind dann etwa eine Woche gültig. Vermeidung: Wenn man das Programm vor der Tour bei gutem Empfang einige Minuten an hat, dann kann das nicht passieren. Der Ort springt hin- und her: Das passiert, wenn die Orientierung nach WLANs und per GPS verschiedene Orte liefern -- z.B. weil der Besitzer des WLAN umgezogen ist. Ist selten, aber dann sehr unangenehm. Da kann man in den Einstellungen die Ortsbestimmung per WLAN ausschalten. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Hi, Am Sat, 16 Mar 2013 11:02:25 +0100 schrieb Norbert Wenzel norbert.wenzel.li...@gmail.com: Ich dachte dabei mehr daran, dass jemand die Ways räumlich trennt und zwei Schienen zeichnet (für jede Fahrtrichtung eine) Ah, jetzt verstehe ich es besser. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Hi, Am Fri, 15 Mar 2013 12:30:27 +0100 schrieb Martin Vonwald imagic@gmail.com: Außerdem gebe ich bei ref zu bedenken, dass idR eine route-Relation für die Straßenbahn existiert - dort wäre ref sogar noch besser aufgehoben, vor allem wenn Straßenbahnen verschiedener Linien die selben Gleisabschnitte benutzen. Die Streckennummern sind Eigenschaften der Gleisstrecken und nicht der Linien. Außerdem haben die Linien schon refs, nämlich die Liniennummern. Oder meintest Du die irrtümlich als name oder ref an die Strecken geschriebenen Liniennummern? MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Hi, Am Fri, 15 Mar 2013 15:18:19 +0100 schrieb Norbert Wenzel norbert.wenzel.li...@gmail.com: Ja kann man, macht aber imo keinen Sinn es umzudrehen. Wir stehen doch nicht vor dem Problem, ein Tagging für Straßenbahnen erfinden zu müssen. Es gibt eine Lösung, diese Lösung ist schon so benutzt worden als es noch kein Spurmapping gab und die auswertenden Programme sind darauf ausgerichtet. Das sollte man nur ändern, wenn es schwerwiegende Kompatibilitätsprobleme gibt. Wenn die jetzige Art Straßenbahnen zu taggen mit dem Spurmapping inkompatibel wäre, dann müsste ein Konzept zur Diskussion gestellt und abgestimmt werden. Das sehe ich aber nicht. Ich halte es für sehr sinnvoll, Straßenbahnschienen als zusätzliches Risiko für Radfahrer im Rahmen des Spurmapping zusätzlich taggen und die Straßenbahnen wie gehabt als eigene Ways an demselben Ort taggen -- das drückt ausreichend aus, dass es sich um dasselbe Objekt in der Realität handelt und da braucht man keine zusätzlichen Relationen. Dass dabei mehrere OSM-Ways ein Objekt beschreiben ist doch kein Problem -- das haben wir andauernd: Bei jeder Änderung der Höchstgeschwindigkeit, bei jeder abbiegenden Buslinie und bei jeder zusätzlichen Spur wird gesplittet. Bei vielen Grenzen zwischen Wald und Wiese liegen zwei Linien übereinander und es stört niemand. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Hi, Soweit mir bekannt ist, sollen Schienenwege sowieso als eigener OSM-Way angelegt werden, da ansonsten unklar ist worauf sich Tags wie z.B. ref, name usw. beziehen. Wenn es keinen eigenen Gleiskörper gibt, müsste man also einen neuen OSM-Way durch dieselben Punkte legen. Ich versuche gerade das Gegenteil zu erreichen. Bei Schienen ohne eigenen Gleiskörper ist ja gerade das Problem, dass ich hier nichts separates habe sondern nur eine Straße. Wieso sollte ich das dann separat einzeichnen. Weil sonst unklar ist, worauf sich z.B. ref bezieht. Wenn man einen neuen Weg durch dieselben Punkte legt, dann sind beide an demselben Ort und man hat sie nicht in der Realität separiert. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Hi, Das wir mehrere refs für ein Objekt haben ist nicht so selten. In meiner Gegend wurden einfach nach alter Regel ein Semikolon verwendet und beide Werte eingetragen. Ja, aber die Zuordnung ist dann unklar. Besser ist vielleicht ein ref:highway bzw. ref:railway. Analog bei name=*, wobei ich mir nicht sicher bin ob solche Schienenstränge eigene Namen haben. Das wäre für Menschen problemlos lesbar. Aber warum sollen Programme geändert werden, wenn es schon eine funktionierende Lösung für das Problem gibt? MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Hi, Ich finde ja das *:lanes Konzept soweit ganz gut, aber leider scheitert es bisher bei Straßen mit Straßenbahnschienen ohne eigenen Gleiskörper. Soweit mir bekannt ist, sollen Schienenwege sowieso als eigener OSM-Way angelegt werden, da ansonsten unklar ist worauf sich Tags wie z.B. ref, name usw. beziehen. Wenn es keinen eigenen Gleiskörper gibt, müsste man also einen neuen OSM-Way durch dieselben Punkte legen. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM streikt, API-URL falsch?
Hi, Am Mon, 25 Feb 2013 16:34:05 +0100 schrieb christian.pietz...@googlemail.com christian.pietz...@gmail.com: Ich dachte ich hätte das Problem gelöst, aber obwohl es jetzt auf der Blacklist sitzt, muss ich Avira noch ausschalten blacklist? Ich nehme mal whitelist an. Ich habe Zugriffe auf tile.openstreetmap.org, api.openstreetmap.org und fume.openstreetmap.org gesehen, evtl. müssen die auch angegeben werden. MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
