Re: [Talk-de] guidepost
Hallo Stephan, ich bin amüsiert, dass eine solch einfache Frage mehr als 100 zum Teil sehr emotionale Beiträge erzeugt, zumal es sich um ein eher unwichtigen Tag handelt. Einspruch. Es gibt Gebiete (z.B. die Schweiz, soweit ich weiss aber auch in einigen Bundesländern), in denen die Wanderwege ein komplettes Netz aufspannen und nicht nur aus einzelen Routen bestehen. In diesen Gebieten ist es sinnvoll, sich seinen Weg an Hand der Wegweiser-Knotenpunkten zusammenzustellen. Ein Beispiel für eine Karte, welche die Guideposts auswertet, ist die Wanderkarte von Lonvia: http://osm.lonvia.de/hiking.html?zoom=13lat=47.17357lon=8.75569layers=FFBTT Dort kann man die einzelnen Wegweiser anklicken und erfährt dann, wie lange es bis zum nächsten verbundenen Wegweiser dauert, und wieviele Höhenmeter dabei zu überwinden sind. Die Zusatzinformation, ob ein Schild ein Wander- oder Fahrradsymbol oder Autofahrergroßschrift trägt, erhöht den Nutzwert nicht sehr. Wenn ich mit dem Fahrrad unterwegs bin, kann ich auch Wegweiser für Wanderer oder Autofahrer nutzen. Selbst als Wanderer könnte ich mich (wenn ich entlang einer Hauptstraße laufe) an den Kfz-Wegweisern orientieren. Nur geht es Dir beim Wandern eben gerade meistens nicht darum, möglichst schnell von A nach B zu gelangen, sondern der Weg dahin soll möglichst schön sein. (Der Weg ist das Ziel.) Wanderer und Autofahrer haben hier also ziemlich unterschiedliche Bedürfnisse. Gruss, Thomas (Wie bereits in meinem Statistik-Posting beschrieben, bin ich allerdings auch der Meinung, dass die *=no-Diskussion keine 100+ Beiträge wert ist.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
PRINT Denn nur, weil sie im selben Gebäude sind, bedeutet das nicht, dass sie in der Datenbank auch nur durch einen Punkt repräsentiert werden dürfen. :LOOP REPLY AS MIRKO Und jetzt bitte nicht wieder das leidige Semikolon. Das kann funktionieren wenn... REPLY AS THOMAS Zwei verschiedene Dinge benötigen zwei verschiedene Nodes. GOTO LOOP -- View this message in context: http://n2.nabble.com/guidepost-tp4386064p4392472.html Sent from the OpenStreetMap Deutschland mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo Mirko, Denn nur, weil sie im selben Gebäude sind, bedeutet das nicht, dass sie in der Datenbank auch nur durch einen Punkt repräsentiert werden dürfen. Das geht doch teilweise auch nicht anders. Beispiel Postagentur mit Postbank, beides amenity, geht aber nur einmal. Ist das ganze noch im Rathaus untergebracht, hast du gleich drei Konflikte. Dazu kommen vielleicht noch unterschieliche Kontakte, Öffnungszeiten, übliches wie Namen etc. Da fehlt ein tagset oder eine taggroup wo du beliebig viele Keys, eben auch gleiche, als Untereigenschaft zu einem Objekt hinzufügen kannst. Und jetzt bitte nicht wieder das leidige Semikolon. Das kann funktionieren wenn sich wirklich alle peinlichst daran halten das Schlüssel1=Wert1;Wert2;Wert3 immer genau auf Schlüssel2=Wert1;Wert2;Wert3 passt. Unachtsamkeit, ein Flüchtigkeitsfehler, eine Systembedingte sortierung whatever und schon kann folgendes rauskommen Schlüssel1=Wert3;Wert2;Wert1 mit Schlüssel2=Wert2;Wert1;Wert3. Das wird bis auf den Erfasser selbst nie einer merken. Und schon würde beispielsweise bei der Postagentur im Rathaus auf der Postkarte die Telefonzentrale vom Rathaus bei der Postagentur angezeit, oder die Sprechzeiten des Rathauses als Öffnungszeiten. Semikolon ist in dem Fall keine Lösung. Ich bin mir nicht ganz sicher, ob Deine Nachricht als Zustimmung oder als Widerspruch gemeint ist - denn eigentlich sind wir doch gleicher Meinung?! Zusammenfassung *meiner* *Meinung*: Mehrere Objekte mit einem einzigen Node darstellen zu wollen ist sehr kompliziert und unübersichtlich. Es ist daher einfacher, für jedes Objekt einen einzelnen Node zu setzen. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: Nein denn er will ja garnicht erst von bicycle=yes weg sondern alles andere soll sich bitte eine entsprechend neue Definition suchen. Er klebt an seiner Definition, Begründung weil etabliert. *Warum* sollte er denn auch von bicycle=yes weg? Wenn es mal einen Grund gäbe, dann wäre es aber möglich. Natürlich soll sich alles *andere* einen *anderen* Tag suchen. Das verhindert viel sinnloses Gehopse bei der Datenauswertung. Wenn du jetzt aber bicycle=yes mit anderer Bedeutung nutzen willst, dann ist diese Möglichkeit verbaut. Eine Möglichkeit die doch keiner hier in betracht zieht. Wann soll die kommen? Wie geschrieben: bei Bedarf. Der existiert aber nicht wirklich. Wer ein altes key/value-Paar mit einer neuen Bedeutung versehen will, der verwässert die in der DB gespeicherten Informationen. Natürlich gibts da Gegenwind von denen, deren Arbeit da teilentwertet werden würde. Da wird doch nichts verwässert weil beide Tags zusammen einen anderen dokumentierten Kontext ergeben. Deine Forderung an alle Datenauswerter jetzt und zukünftig einen nebulösen Kontext auszuwerten statt eine eindeutige Bedeutung vorzufinden, ist keine Verwässerung? Ein bicycle=yes kann auf einem Guidepost kein access sein. Ergo kannst du Guidepost bei einer Routinganwendung guten gewissens ignorieren. (Und komm' nicht mit abhängig vom Haupttag - was soll das sein?) Schon tausende male geschrieben. Und schon genausooft mit Es gibt bei OSM kein Konzept 'Haupttag'. Dafür wäre es nötig technisch durchzusetzen, dass jedes Element einen und genau einen dieser Tags bekäme. Dem ist nicht so. beantwortet. Gruß, Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On Tue, Jan 12, 2010 at 10:41:55PM +0100, Norbert Hoffmann wrote: Sarah Hoffmann wrote: Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten benutzt wird, während ein Untertag nur in Kombination mit anderen Tags anzutreffen ist. Diese Art von Hierarchie hat sich in OSM sehr wohl etabliert, auch wenn es nicht im Datenbank-Schema festgeschrieben ist. highway=* ist ein Haupttag. tourism=* eines. information=guidepost ist keines und bicycle=* sicherlich auch nicht. Und du schreibst also vor, das je way oder node nur genau einer dieser Haupttags genutzt werden darf? Ich nehme an, du überarbeitest jetzt auch alle Knoten, an denen derzeit z.B. amenity *und* shop vorhanden sind. Das mit der deutschen Sprache ist schon schwer. Es geht mir nicht darum, Regeln vorzuschreiben, sondern zu *interpretieren*, was sich in der Datenbank befindet. Also nochmal: Ein Haupttag sei ein Tag, was allein an einem Weg oder Knoten vorkommen kann, wobei kann hier so zu vestehen ist, dass es in der Datenbank häufiger allein anzutreffen ist. Es muss nicht alleine stehen, es kann mit beliebigen anderen Tags (auch Haupttags) vorkommen, aber es wird eben auch alleine benutzt. Ein Untertag hingegen wird man praktisch nur in Kombination mit anderen Tags in der Datenbank finden. Ein Tag, dass gewöhnlich nur mit anderen Tags vorkommt, sollte ein Datenverarbeiter besser nicht interpretieren, ohne die anderen Tags zu betrachten. Beispiel: ein Router ignoriert gewöhnlich alle Wege, die mit waterway=* getaggt sind, selbst wenn sie ein Tag bicycle=* enthalten. (Ja, diese Kombination gibt es in der Datenbank.) Würde er bedingungslos alle Wege mit bicycle=* ins Routing aufnehmen, würden einige Leute sehr nass werden. Am Ende liegt es natürlich am Datenverarbeiter, was genau er als Haupttag verwenden will und wo er den Kontext (also die anderen Tags am gleichen Knoten/Weg/Relation) interpretiert. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
*Warum* sollte er denn auch von bicycle=yes weg? Wenn es mal einen Grund gäbe, dann wäre es aber möglich. Wenn nicht in dem Fall dann garnicht. Oder aus welchem Grund sollte man es noch ändern? Natürlich soll sich alles *andere* einen *anderen* Tag suchen. Das verhindert viel sinnloses Gehopse bei der Datenauswertung. Wäre in dem Fall für jedes simple Fahrrad=Ja zu jedem Tag ein ein neues Irgendwas:Fahrrad=Ja. Muss auch irgendwie verarbeitet werden. Gehopst wird in jedem Fall. Wie geschrieben: bei Bedarf. Der existiert aber nicht wirklich. Wenn der jetzt nicht vorliegt dann frage ich mich welcher Bedarf da vorliegen soll. Deine Forderung an alle Datenauswerter jetzt und zukünftig einen nebulösen Kontext auszuwerten statt eine eindeutige Bedeutung vorzufinden, ist keine Verwässerung? Nebulös ist da garnichts. In Verbindung mit Guidepost kein access. Ganz einfach. Und schon genausooft mit Es gibt bei OSM kein Konzept 'Haupttag'. Dafür wäre es nötig technisch durchzusetzen, dass jedes Element einen und genau einen dieser Tags bekäme. Dem ist nicht so. beantwortet. Nenne den Fall wie du willst. Ein Access ohne Verbindung mit bestimmten Objekten oder Auslöser kann nicht existieren. Dafür brauchts garkein Konzept, das ergibt sich ganz automatisch. Auch andere Tags lassen sich Theoretisch einzeln setzen, ergeben aber ohne andere Tags einfach keinen Sinn. Du kannst einem Way nur einen Namen verpassen, wird aber erst durch highway=residential zu einer Wohnstraße. Genauso wie du einem Polygon eine Adresse verpassen kannst, erst ein building=yes macht es eindeutig zum Gebäude. Die Liste kann man ewig fortführen. Klar kannst du theoretisch auch einen access alleine auf blanke Nodes und Ways legen. Ohne eine bestimmte Hauptinformation kannst du damit aber nichts anfangen. Haupt- und Zusatzangaben haben sich ohne spezielles Konzept ganz von alleine so ergeben und sind lange Alltag. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: Nebulös ist da garnichts. In Verbindung mit Guidepost kein access. Ganz einfach. Ich glaub' jetzt hast du's ;-) Also: Ab heute müssen alle Auswertungen umgestellt werden, damit sie (wenn gleichzeitig Guidepost vorhanden ist) nicht mehr von der Bedeutung access ausgehen. Ab morgen müssen ... Ab übermorgen müssen ... - sinnloses Gehopse! Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Also: Ab heute müssen alle Auswertungen umgestellt werden, damit sie (wenn gleichzeitig Guidepost vorhanden ist) nicht mehr von der Bedeutung access ausgehen. Ab morgen müssen ... Ab übermorgen müssen ... So wie vorgestern highway=gate zu barrier=gate wurde, vorvorgestern claas=* zu highway=*. Solange dokumentiert und bekannt kann sich jeder wie bei jeder anderen Änderung darauf einstellen. Das Problem liegt jetzt wo? - sinnloses Gehopse! Nö ganze normale Enetwicklung in einem offenem System. Wenn du kein Gehopse willst dann musst du von offen auf verabschiedete Standarts umschwenken. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: So wie vorgestern highway=gate zu barrier=gate wurde, vorvorgestern claas=* zu highway=*. Solange dokumentiert und bekannt kann sich jeder wie bei jeder anderen Änderung darauf einstellen. Das Problem liegt jetzt wo? Darin, dass highway=gate nicht plötzlich eine zusätzliche andere Bedeutung bekommen hat - du aber für bicycle=yes zusätzlich zum bisherigen hier kann man Fahrrad fahren heute auch hier sind Infos für Fahrradfahrer, morgen hier kann man Fahrräder kaufen, übermorgen an diesem Kirchturm hängt ein Fahrrad (gibt's wirklich) usw einführen willst. - sinnloses Gehopse! Nö ganze normale Enetwicklung in einem offenem System. Wenn du kein Gehopse willst dann musst du von offen auf verabschiedete Standarts umschwenken. Lerne Lesen. *sinnloses* Gehopse. offenhohl Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann wrote: Würde er bedingungslos alle Wege mit bicycle=* ins Routing aufnehmen, würden einige Leute sehr nass werden. Vielleicht sollte er eben zusätzlich zum Haupttag bicyle=yes auch die beschreibenden Nebentags z.B. highway= auswerten (schon allein um eine schöne Farbe für den Weg auszusuchen). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Darin, dass highway=gate nicht plötzlich eine zusätzliche andere Bedeutung bekommen hat - du aber für bicycle=yes zusätzlich zum bisherigen hier kann man Fahrrad fahren heute auch hier sind Infos für Fahrradfahrer, morgen hier kann man Fahrräder kaufen, übermorgen an diesem Kirchturm hängt ein Fahrrad (gibt's wirklich) usw einführen willst. Lerne lesen. Ich bevorzuge die Variante bicycle=yes durch access:bicycle=yes zu konkretisieren und das zusammen mit einigen Ergänzungen die man mit dem derzeitigen Modell schlicht nicht darstellen kann und man deswegen so oder so nicht um einige Änderungen herum kommt. Dazu gehören Abhänhigkeiten und Zeiten die derzeit garnicht oder nur einmalig pro Element darstellbar sind, in der Realität aber oft auch mehrmals für unterschiedliche Sachen vergeben werden müssten. Ergänzt man das, könnte man in einem rutsch gleich mit konkretisieren. Das geht warum nicht möglich? Das simple und neutrale bicycle=yes wäre dann für alle anderen Fälle frei, wo man nicht weiter konkretisieren muss. So wie eben beim Guidepost. Und trotzdem ist es noch immer kein Problem. Wenn ein bestimmtes Paar Tags eine eindeutige andere Beschreibung ergibt habe ich kein Problem damit. Sich diesen Kontext zu merken ist genauso schiwerig oder leicht wie wenn man für jeden Fall wieder einen eigenen Tag aufmachen und sich merken müsste. Nur lässt letzteres immer die Tagliste weiter anwachsen. Wenn du für jeden Kleinscheiß einen extra eindeutigen Tag brauchst und dir das auch alles merken kannst, dann bitte. Lerne Lesen. *sinnloses* Gehopse. offenhohl Setz du die Scheuklappen ab. Hier kann jeder nach belieben machen was er will. Gehopst wird ständig. Wenn das allerdings dokumentiert und gut ausgearbeitet wird, ist da überhaupt nichts mit gehopse. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 11. Januar 2010 22:53 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Wenn man sich überlegt, daß gehört neben den Weg von genügend Mappern schlicht nicht beachtet werden wird das ist m.E. kein Grund, die Wegweiser nicht zu mappen, nur weil manche sie evtl. auf den Weg anstatt daneben zeichnen _könnten_. Bushaltestellen wurden vor einiger Zeit auch auf die Wege gezeichnet während mittlerweile die reale Position daneben sich eingespielt zu haben scheint. Gib uns ein bisschen Zeit, und wir werden auch die Wegweiser in den Griff bekommen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 13. Januar 2010 11:26 schrieb Mirko Küster webmas...@ts-eastrail.de: Also: Ab heute müssen alle Auswertungen umgestellt werden, damit sie (wenn gleichzeitig Guidepost vorhanden ist) nicht mehr von der Bedeutung access ausgehen. Ab morgen müssen ... Ab übermorgen müssen ... So wie vorgestern highway=gate zu barrier=gate wurde, vorvorgestern claas=* zu highway=*. Solange dokumentiert und bekannt kann sich jeder wie bei jeder anderen Änderung darauf einstellen. Das Problem liegt jetzt wo? OK, noch mal ganz sachlich und von vorn: Wenn ich mich entscheide statt highway=gate ab jetzt (das bisher nicht vorhandene) barrier=gate zu verwenden, um eine übersichtlichere Gruppierung zu erreichen, bedeutet das kein Problem, richtig. Da gehen wir denke ich alle konform. Wenn ich mich aber heute entscheide, daß das bereits seit Jahren benutzte bicycle=no nun neben hier kein Zugang für Fahrräder auch noch hier keine Routeninformation für Fahrräder heißen soll, dann habe ich ein Problem, weil ich *nachträglich* die Bedeutung eines tags fundamental geändert habe. Und da berühren wir meines Erachtens einen Grundsatz von OSM, der da lautet sei explizit. Es ist kein Problem, bei der Eingabe explizit zu sein und genau zu spezifizieren, was man meint. Umgekehrt ist es aber schwierig, bei der Ausgabe (Generierung von Karten (ja, damit beschäftige ich mich, ich kenne das Problem), Routinggraphen, etc) in schwammigen Daten herum zu interpretieren. Nehmen wir mal ein anderes Beispiel: Ein Gemischtwarenladen mit Touristeninformation. shop=convenience, tourism=information und bicycle=no. Was heißt das? -kein Zugang für Fahrräder(abstellen/anlehnen verboten)? -keine Stellplätze für Fahrräder? -keine touristischen Informationen für Radfahrer? -keine fahrradspezifischen Produkte (Reparaturzeug, Ersatzteile) im Angebot? Eventuell bringt dir das das Problem der Gegenseite ja etwas näher. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo Andre, Dieser Ansatz scheitert kläglich, wenn an einem Knoten mehrere Haupttags hängen. Das ist bislang nicht verboten. Aber die Nachteile wurden hier auch schon häufiger im Zusammenhang mit anderen Haupt-Keys diskutiert. Natürlich kannst Du eine Bushaltestelle (highway=bus_stop) und einen Abfalleimer (amenity=waste_basket) der an der Halte-Tafel montiert ist mit einem Node taggen. Aber sobald Du da einen Unter-Key wie z. B. operator dranhängst, weisst Du bei der Auswertung nicht, ob sich operator auf die Bushaltestelle oder den Abfalleimer bezieht. Sobald man also einen Haupt-Key mit einem Unter-Key erweitern möchte, ist es besser [i.e. einfacher auswertbar], wenn man zwei einzelne Nodes zeichnet. Mit access:bicycle=* oder information:bicycle=* liesse sich das eindeutig trennen. Nur wer bringt das den proposals und Editoren schonungsvoll bei? Dann müsste man das aber für _jeden_ Unter-Key machen, also auch bus_stop:operator und waste_basket:operator... Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo Martin, Nehmen wir mal ein anderes Beispiel: Ein Gemischtwarenladen mit Touristeninformation. shop=convenience, tourism=information und bicycle=no. Was heißt das? -kein Zugang für Fahrräder(abstellen/anlehnen verboten)? -keine Stellplätze für Fahrräder? -keine touristischen Informationen für Radfahrer? -keine fahrradspezifischen Produkte (Reparaturzeug, Ersatzteile) im Angebot? Wie ich gerade weiter oben (unten?) geschrieben habe, hast Du dieses Problem allerdings überall, wo sich ein Unter-Key auf mehrere Haupt-Keys beziehen kann. Z.B. opening_hours, operator, name, etc. Keys die _nicht_ alleine stehen können (wie eben bicycle=no) sollten daher nur verwendet werden, wenn sie sich auf _alle_ 'Haupt-Keys' beziehen. Gruss, Thomas (Mal ganz davon abgesehen, dass es _gar_nie_ vorgesehen war, *=no für Wegweiser oder Karten zu verwenden. Einzig *=yes ist vorgesehen, und da sehe ich für Router keine Probleme.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo Sarah, Also nochmal: Ein Haupttag sei ein Tag, was allein an einem Weg oder Knoten vorkommen kann, wobei kann hier so zu vestehen ist, dass es in der Datenbank häufiger allein anzutreffen ist. Es muss nicht alleine stehen, es kann mit beliebigen anderen Tags (auch Haupttags) vorkommen, aber es wird eben auch alleine benutzt. Ein Untertag hingegen wird man praktisch nur in Kombination mit anderen Tags in der Datenbank finden. Ein Tag, dass gewöhnlich nur mit anderen Tags vorkommt, sollte ein Datenverarbeiter besser nicht interpretieren, ohne die anderen Tags zu betrachten. Beispiel: ein Router ignoriert gewöhnlich alle Wege, die mit waterway=* getaggt sind, selbst wenn sie ein Tag bicycle=* enthalten. (Ja, diese Kombination gibt es in der Datenbank.) Würde er bedingungslos alle Wege mit bicycle=* ins Routing aufnehmen, würden einige Leute sehr nass werden. Genau, die Daten in OSM müssen immer _im_Kontext_ ausgewertet werden. Es liegt doch sowieso im Interesse des Routers, möglichst alle überflüssigen Daten aus der Datenbank zu werfen. Und da ist ein Whitelist-Ansatz (Ich beachte 'bicycle=no' für highways und barriers.) besser als einfach alle bicycle=no auszuwerten. Gerade weil OSM ein offenes System ist, sollte man bei der Auswertung eher restriktiv vorgehen.. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo zusammen, ich sehe immer öfters Wegweiser http://wiki.openstreetmap.org/index.php/Proposed_features/Guidepost die mit bicycle=yes getaggt sind. Noch etwas Statistik am Rande: Aus http://tagwatch.stoecker.eu/Germany/En/tagstats_information_guidepost.html information=guidepost wird in Deutschland total 8300 mal verwendet, davon - 11x mit bicycle=no (0.13%) - 5x mit hiking=no (0.06%) - 4x mit horse=no (0.05%) - 2x mit ski=no - 1x mit mtb=no Insgesammt also (maximal) 23x mit einem *=no. Wenn ich überlege, wie häufig ich schon ein access=no in ein vehicle=no umtaggen musste, weil der Vorgänger das falsch eingetragen hatte, dann wage ich zu behaupten, dass das Guidepost-Problem ein _sehr_ kleines Problemchen ist. Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On 13.01.2010 18:16, Thomas Ineichen wrote: Hallo Martin, Nehmen wir mal ein anderes Beispiel: Ein Gemischtwarenladen mit Touristeninformation. shop=convenience, tourism=information und bicycle=no. Was heißt das? -kein Zugang für Fahrräder(abstellen/anlehnen verboten)? -keine Stellplätze für Fahrräder? -keine touristischen Informationen für Radfahrer? -keine fahrradspezifischen Produkte (Reparaturzeug, Ersatzteile) im Angebot? Wie ich gerade weiter oben (unten?) geschrieben habe, hast Du dieses Problem allerdings überall, wo sich ein Unter-Key auf mehrere Haupt-Keys beziehen kann. Z.B. opening_hours, operator, name, etc. Keys die _nicht_ alleine stehen können (wie eben bicycle=no) sollten daher nur verwendet werden, wenn sie sich auf _alle_ 'Haupt-Keys' beziehen. Ergo wir brauchen nun einmal einen generischen Key der unterschiedliche Bedeutungen haben kann und sich auf alle 'Haupt-Keys' beziehen soll (ohne dass aus der Datenbank ersichtlich ist was ein Hauptkey ist - sprich wenn ich nicht weiß ob tourism=information ein Haupt oder Unterkey ist, dann weiß ich auch nicht ob ich bspw. bicycle=yes verwenden kann und soll), sondern seperate keys fuer die Hauptkeys um im Falle des vorkkommens von mehreren Hauptkeys auch dasselbe ausdruecken zu koennen. Sorry hier verrrent man sich aber gewaltig. Das ganze wird so absolut nicht uebersichtlicher. Besser waehre wir definieren Unterkeys auch im Key selbst, nur so kann man von der Datenbank her auch ohne menschliche Intelligenz Zusammenhaenge ziehen. Also fuer obiges Beispiel etwa: shop=convenience, optional shop:bicycle=no (fuehrt keine fahrradspezifischen Produkte); tourism=information, tourism:bicycle=yes (touristische Informationen fuer Fahrradfahrer vorhanden). Das ganze ist nicht komplizierter, weil ich den Hauptkey (und in dem Falle ist klar wozu eine Eigenschaft existiert) eindeutig zuordnen kann (auch ohne Intelligenz), und auch bestimmen kann ob er ein Hauptkey, Unterkey, oder Unter-unterkey ist. Ausserdem verwaesser ich nicht die Eigenschaft eines Keys. Es ist ja jetzt schon schlimm genug dass man nicht weiß ob bicycle=no auf einem Fußweg bedeutet ich darf hier nicht fahren, oder ich kann hier nicht fahren (was sehr subjektiv ist, und daher in der Bedeutung hier eh nicht her passt). Gruss, Thomas (Mal ganz davon abgesehen, dass es _gar_nie_ vorgesehen war, *=no für Wegweiser oder Karten zu verwenden. Einzig *=yes ist vorgesehen, und da sehe ich für Router keine Probleme.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo Felix, Sorry hier verrrent man sich aber gewaltig. Das ganze wird so absolut nicht uebersichtlicher. Besser waehre wir definieren Unterkeys auch im Key selbst, nur so kann man von der Datenbank her auch ohne menschliche Intelligenz Zusammenhaenge ziehen. Also fuer obiges Beispiel etwa: shop=convenience, optional shop:bicycle=no (fuehrt keine fahrradspezifischen Produkte); tourism=information, tourism:bicycle=yes (touristische Informationen fuer Fahrradfahrer vorhanden). Und zusätzlich shop:access:wheelchair=yes, shop:wheelchair=no (Ist für Rollstuhlfahrer zugänglich, hat aber keine Rollstuhl-spezifischen Artikel. :- ) Die Übersicht geht mit Deinem Schema aber auch schon vorher ziemlich schnell verloren. Meiner Meinung nach ist ganz einfach: Zwei verschiedene Dinge (Gemischtwarenladen Tourismusinformation) benötigen zwei verschiedene Nodes. Denn nur, weil sie im selben Gebäude sind, bedeutet das nicht, dass sie in der Datenbank auch nur durch einen Punkt repräsentiert werden dürfen. Gruss, Thomas (Ich bin ja froh, hat hier noch niemand das Beispiel von einem Wegweiser gebracht, der an einer Barrier befestigt ist.. ) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Denn nur, weil sie im selben Gebäude sind, bedeutet das nicht, dass sie in der Datenbank auch nur durch einen Punkt repräsentiert werden dürfen. Das geht doch teilweise auch nicht anders. Beispiel Postagentur mit Postbank, beides amenity, geht aber nur einmal. Ist das ganze noch im Rathaus untergebracht, hast du gleich drei Konflikte. Dazu kommen vielleicht noch unterschieliche Kontakte, Öffnungszeiten, übliches wie Namen etc. Da fehlt ein tagset oder eine taggroup wo du beliebig viele Keys, eben auch gleiche, als Untereigenschaft zu einem Objekt hinzufügen kannst. Und jetzt bitte nicht wieder das leidige Semikolon. Das kann funktionieren wenn sich wirklich alle peinlichst daran halten das Schlüssel1=Wert1;Wert2;Wert3 immer genau auf Schlüssel2=Wert1;Wert2;Wert3 passt. Unachtsamkeit, ein Flüchtigkeitsfehler, eine Systembedingte sortierung whatever und schon kann folgendes rauskommen Schlüssel1=Wert3;Wert2;Wert1 mit Schlüssel2=Wert2;Wert1;Wert3. Das wird bis auf den Erfasser selbst nie einer merken. Und schon würde beispielsweise bei der Postagentur im Rathaus auf der Postkarte die Telefonzentrale vom Rathaus bei der Postagentur angezeit, oder die Sprechzeiten des Rathauses als Öffnungszeiten. Semikolon ist in dem Fall keine Lösung. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Thomas Ineichen schrieb: (Ich bin ja froh, hat hier noch niemand das Beispiel von einem Wegweiser gebracht, der an einer Barrier befestigt ist.. ) Du irrst: ich schrieb am 24.12.2009: Angenommen auf einer Schranke wo Radfahrer nicht durchkommen ist ein Wegweiser für Radler montiert: barrier=gate bicycle=no tourism=information information=guidepost bicycle=yes (Hoppla Kollision) ;-) Chris - Der sich oft wundert dass das Routing trotz dieses Chaos schon recht gut funktioniert - Hein ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo Chris, Du irrst: Mist! ;-) [barrier mit guidepost] Da ich ja zu den Guidepost-auf-Node-Verfechtern gehöre, würde ich das so taggen: G | B | | | G ist der Guidepost, B die Barrier. Ich hab allerdings auch schon Barriers _auf_ dem Kreuzungspunkt gesehen. So ist natürlich auch ohne Guidpost kein sinnvolles Routing möglich.. :-( Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 21.12.2009 23:42, schrieb Chris-Hein Lunkhusen: Hi, ich sehe immer öfters Wegweiser ... die mit bicycle=yes getaggt sind. Moin, ich bin amüsiert, dass eine solch einfache Frage mehr als 100 zum Teil sehr emotionale Beiträge erzeugt, zumal es sich um ein eher unwichtigen Tag handelt. Wenn man sonst schon alles in der OSM-Datenbank erfasst hat, kann man der Vollständigkeit halber auch guidepost aufnehmen. Ein GPS-Nutzer kennt seine Position und sein Ziel und wird sich kaum für Wegweiser interessieren. Für jemanden, der mit einer ausgedruckten OSM-Karte unterwegs ist, bietet ein Wegweisersymbol evtl. ein Indiz um seine Position auf der Karte zu verifizieren. Diejenigen, die die Wegweiser brauchen, weil sie ohne GPS und ohne Karte unterwegs sind, haben aus anderen Gründen nichts vom Datenbankeintrag. Vielleicht kann man sich per OSM informieren, ob es lohnt, im Urlaubsort eine Wanderkarte für 5 Euro zu kaufen oder ob die Wegweiserdichte ausreicht. Ich würde die Relevanz von Guidepost knapp hinter die der Hundekottütenspender einordnen, bei welchen es immerhin denkbar ist, dass jemand den nächstgelegenen Standort feststellen möchte. Die Zusatzinformation, ob ein Schild ein Wander- oder Fahrradsymbol oder Autofahrergroßschrift trägt, erhöht den Nutzwert nicht sehr. Wenn ich mit dem Fahrrad unterwegs bin, kann ich auch Wegweiser für Wanderer oder Autofahrer nutzen. Selbst als Wanderer könnte ich mich (wenn ich entlang einer Hauptstraße laufe) an den Kfz-Wegweisern orientieren. Die Frage, welchen datenbankinternen Namen (Name ist Schall und Rauch, Goethe, Faust) das unwichtige Zusatztag zum unwichtigen Haupttag tragen sollte, würde ich nach folgenden Kriterien bewerten: - welches Namensschema ist in allen Situationen eindeutig - welcher Name ist kompatibel zu bestehenden Anwendungen - welcher Name ist für Mapper leicht zu lesen und zu merken - wie kann man die Informationen effizient eintragen Grundsätzlich würde ich es bevorzugen, guidepost direkt an die Kreuzung zu hängen. Dann ist bicycle=yes nicht sinnvoll. Ich würde mich für das Schema guidepost=bicycle oder selten guidepost=bicycle;hiking entscheiden. Aber solange man eindeutige Namen verwendet, kann man sich ja auch umentscheiden und die Tags per bot umbenennen. Ich halte übrigens das Problem das Wort bicycle in einer mit Semikolon separierten Liste zu suchen nicht nur für lösbar, sondern sogar für einfacher zu programmieren als die Zuordnung eines separaten guidepost zur nahegelegenen Kreuzung. Gruß, Stephan :-) (heute auch mit Smiley) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 12. Januar 2010 07:28 schrieb Karl Eichwalder k...@gnu.franken.de: (Sorry, alles andere halte ich nach den bisherigen Erfahrungen für eine naive Annahme), ist das ganze Thema für mich weiterhin ne schlechte Idee :-) Und für mich ist es eine gute :) Reale probleme konnte niemand aufzeigen, nur lustig konstruierte fälle. Was, bitte, ist so schwierig daran, für die Beschreibung des Informationsgehaltes eines Wegweisers einfach *nicht* dasselbe Schema zu verwenden, das seit Ewigkeiten für Zugangsbeschränkungen verwendet wird? Information:bicycle=yes und gut. Ich schlage übrigens motorroad=yes vor für Wegweiser und Hinweistafeln, die informationen über Kraftfahrstraßen enthalten und bridge=yes für solche, die Informationen über Brücken enthalten. Ich hoffe eure Ironiedetektoren sind kalibriert. -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 12. Januar 2010 10:42 schrieb Martin Simon grenzde...@gmail.com: Am 12. Januar 2010 07:28 schrieb Karl Eichwalder k...@gnu.franken.de: (Sorry, alles andere halte ich nach den bisherigen Erfahrungen für eine naive Annahme), ist das ganze Thema für mich weiterhin ne schlechte Idee :-) Und für mich ist es eine gute :) Reale probleme konnte niemand aufzeigen, nur lustig konstruierte fälle. Was, bitte, ist so schwierig daran, für die Beschreibung des Informationsgehaltes eines Wegweisers einfach *nicht* dasselbe Schema zu verwenden, das seit Ewigkeiten für Zugangsbeschränkungen verwendet wird? Einig sind wir uns zumindest darüber, dass user Fehler machen und somit auch nodes auf ways landen, die dort nicht hingehören. Unterschiedlich sind die Schlüsse, die daraus gezogen werden. Die einen sagen: Dann wird der Fehler eben vom nächsten, der vorbei kommt korrigiert, die anderen: Wir sollten das Datenschema so anlegen, dass auch fehlerhaftes Tagging nicht zu Konflikten mit anderen eingetragenen Daten führt. Für meinen Teil finde ich die zweite Herangehensweise sinnvoller. 1. Weil wir alle Fehler machen. 2. Weil keiner von uns alle Tags und Attribute überblickt. Erweiterungen des Datenschemas sollten deshalb so erfolgen, dass Konflikte mit anderen Tags von vorn herein ausgeschlossen sind. 3. Weil die Mapperdichte, jedenfalls auf dem Land, nicht so hoch ist, dass Zeitnah mit Korrekturen durch andere Mapper gerechnet werden kann. Der Fall von Konflikten eines information=guidepost bicycle=yes in einem Node auf einem Way mit einem anderen Tag mag konstruiert sein, er kann jedenfalls für diesen Fall nicht ausgeschlossen werden. Viel wichtiger erscheint mir aber daraus Lehren auf einer übergeordneten Ebene zu ziehen und solche Probleme gleich zu vermeiden. Siehe Nr. 1--3. Wer sagt uns, das nicht bald an einer anderen Ecke das gleiche Problem auftaucht. Fakt ist jedenfalls, das der Detailreichung zu einzelnen Tags sich erhöht und damit auch die Gefahr der Bedeutungsüberschneidung mit anderen Tags zunimmt. Man könnte unsere oberste OSM-Regel Jeder Taggt so wie er es für richtig hält wie folgt ergänzen: vermeidet dabei aber Überschneidungen mit Tags, die bereits in einem anderen Kontext verwendet werden. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Was, bitte, ist so schwierig daran, für die Beschreibung des Informationsgehaltes eines Wegweisers einfach *nicht* dasselbe Schema zu verwenden, das seit Ewigkeiten für Zugangsbeschränkungen verwendet wird? Information:bicycle=yes und gut. Kannst du genauso fragen, was so schwierig daran ist, seine Anwendung so zu bauen, das nur die für den Anwendungsfall sinnvollen Elemente ausgewertet werden, statt alles default? Ein Guidepost macht im Routingablauf und insbesondere als access keinen Sinn, warum muss der trotzdem dahingehend ausgewertet werden? Oder warum man den einzigen wichtigen Punkt ansich nicht endlich mal genau definiert access:bicycle=yes, was nur eine Erweiterung wäre und man stattdessen für jeden Anwendungdungsfall wieder einen weiteren Tag erfinden muss, diese eigentliche simple Aussage durch dutzende Tags extrem aufblähen muss, die wiederum Fehler nach sich ziehen. Nur weil das seit Ewigkeiten so ist, muss das noch lange nicht der beste Weg sein, der auch morgen noch ausreicht. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
André Riedel schrieb: Am 11. Januar 2010 21:50 schrieb Chris-Hein Lunkhusen chris66nrw at gmx.de: Chris-Hein Lunkhusen schrieb: Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. So, nun hab ich mich mal schlau gemacht. Also der Trigger für die oben genannte mkgmap Option ist der access-Tag. Nach dem Proposal [1] könnte man die Aussage: Wegweiser enthält Informationen für Alles außer Autos mit access=yes, motorcar=no taggen, und das wäre dann ein Problem für's Routing: http://up.picr.de/3574740.png ;-) Chris [1] http://wiki.openstreetmap.org/wiki/Information Schönes Beispiel, könntest du mir noch den Wegweiser dazu zeigen ;-) Meiner Meinung nach dürften alle im Proposal erwähnten Elemente nicht Teil eines Weges sein. Würde dies so umgesetzt werden, gäbe es dein Problem nie. Außerdem wird mit dieser Vereinfachung eine wichtige Information, der genauen Lage des Wegweisers, einfach unterschlagen. Also Wegweiser, Karte usw. mit neuen Node an genauen Standort neben der Straße eintragen. Es gibt da ein kleines Problem mit der Schweiz. Hier dürften sich geschätze 90-95% der Wegweiser auf der Strasse befinden. Ich muss gestehen, dass das meine Schuld ist. Ich hatte damals, als ich das Proposal für die Schweizer Wanderwege geschreiben hatte, vorgeschlagen, die Wegweiser auf den Wegen zu plazieren, weil sie eben als Knotenpunkte im Wanderwegenetz dienen. Es erschien mir nützlicher, sie im Wanderwege- netz korrekt zu plazieren, als in der Landschaft. Damals hat sich jedenfalls keiner beschwert und die Nutzung hat sich so eingebürgert. Ich persönlich bin auch der Meinung, dass das trotz der neuen *=yes-Tags kein Problem ist, weil a) ein Router das Haupttag immer mitauswerten sollte und b) ein *-no-Tag am Wegweiser nicht wirklich Sinn macht. Wie dem auch sei, die Situation mag zwar nicht ideal sein, wird sich wohl aber auch nicht mehr ändern, es sei denn, jemand macht sich auf und verifiziert die Standorte aller 2361 eingetragenen Schweizer Wegweiser. Es macht also nicht viel Sinn, darüber zu diskutieren, Wegweiser auf Wegen als falsch zu deklarieren und zu verbieten. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann schrieb: Es gibt da ein kleines Problem mit der Schweiz. Hier dürften sich geschätze 90-95% der Wegweiser auf der Strasse befinden. Ich muss gestehen, dass das meine Schuld ist. Ich hatte damals, als ich das Proposal für die Schweizer Wanderwege geschreiben hatte, vorgeschlagen, die Wegweiser auf den Wegen zu plazieren, weil sie eben als Knotenpunkte im Wanderwegenetz dienen. Es erschien mir nützlicher, sie im Wanderwege- netz korrekt zu plazieren, als in der Landschaft. Damals hat sich jedenfalls keiner beschwert und die Nutzung hat sich so eingebürgert. Genauso habe ich das für die Radwegweiser in NRW gemacht, aus ähnlichen Gründen. Zumal Ampeln ja auch munter auf die Wegknoten gelegt werden, und landuse-Grenzen mit Wegen oft genug zusammenliegen :-( Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am Dienstag 12 Januar 2010 13:00:15 schrieb Mirko Küster: Ein Guidepost macht im Routingablauf und insbesondere als access keinen Sinn, warum muss der trotzdem dahingehend ausgewertet werden? Eigentlich steh ich der Sache eher neutral gegenüber, aber das ist Naiv! Immerhin ist bicycle=yes ohne irgwendwelchen kontext etabliert als da dürfen Fahrräder durch. Es gibt keine access-Tags, die *zwingend* wären. Selbst ein späterer Mapper könnte bei einem Node, der Teil eines Weges ist davon ausgehen, dass dieses Tag einfach an dem Weg hätte stehen sollen und korrigiert das dann. Anders sähe es aus, wenn bicycle=yes *immer* ein anderes Tag brauchen würde um Sinn zu machen. Das ist aber nicht so. Gruß, Bernd -- Kann man in geschmolzenem Trockeneis schwimmen, ohne naß zu werden? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Gegenbeispiel für ein schon weit verbreitetes Tag: http://wiki.openstreetmap.org/wiki/DE:Key:crossing Was mache ich, wenn ich ausdrücken will, dass bei einer Kreuzung nur 2 der 4 Übergänge für den Fahrradverkehr freigegeben. Ich trage also die zwei erlaubten Stellen mit bicycle=yes und die anderen mit bicycle=no ein. Passt soweit. Aber heißt das jetzt, dass die Ich die zwei Straßen mit dem Fahrrad nicht benutzen darf? Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Ein Guidepost macht im Routingablauf und insbesondere als access keinen Sinn, warum muss der trotzdem dahingehend ausgewertet werden? Eigentlich steh ich der Sache eher neutral gegenüber, aber das ist Naiv! Immerhin ist bicycle=yes ohne irgwendwelchen kontext etabliert als da dürfen Fahrräder durch. Es gibt keine access-Tags, die *zwingend* wären. Ja, etabliert, weil einst so niedergeschrieben und man kannte es nicht anders. Man hat aber damals noch nicht daran gedacht, dass man ein Fahhrad=Ja (Nicht Fahrrad darf da durch) auch noch anderweitig gebrauchen könnte und so ein neutrale Aussage auf den Anwendungsfall Zugangsbeschränkung festgenagelt. Nun kann man ewig und drei Tage darauf bestehen das bis zum sannkt Nimmerleinstag so stehen zu lassen, oder man reformiert endlich mal aufgrund der Erfahrungen und Visionen von heute. Ich hatte schon einige Besipiele gebracht wo sich mehrere access überschneiden und aufgrund des Umstandes das nur ein Tag geht nicht darstellen lassen. Auch nicht durch Trennung mit Semikolon, weil man damit nicht Tagübergreifend die Verbindung zwischen den Werten aufzeigen kann. Das klappt nur solange wie Schlüssel1=Wert1;Wert2;Wert3 exakt zu Schlüssel2=Wert1;Wert2;Wert3 steht. Ein kleiner Fehler reicht und es käme beispielsweise ein Schlüssel1=Wert3;Wert2;Wert1 exakt zu Schlüssel2=Wert2;Wert1;Wert3 und schon passt es nicht mehr, was aber ausser der Erfasser selbst keiner erkennen kann. Da gab es bisher keine Antwort zu. Ignorieren hilft aber nicht das Problem zu lösen, Hauptsache man muss nichts ändern. Und ich sehe überhaupt keinen Grund eine konkrete Anwendung so zu stricken, das man eben nur routingrelevante Dinge einbezieht, wo ein Guidepost mit bicycle=yes schon in der Vorverarbeitung rausfallen würde. Wer das nicht macht wird bei einem so offenem System wie unserem immer gehörig die Kacke greifen. Überall finden sich irgendwelche Dinge die nirgends dokumentiert sind und bei einer Auswertung über alles mit einbezogen würden. Selbst ein späterer Mapper könnte bei einem Node, der Teil eines Weges ist davon ausgehen, dass dieses Tag einfach an dem Weg hätte stehen sollen und korrigiert das dann. Das ist naiv. Dann hat er die zum Tag gehörende Erklärung nicht gelesen, den Kontext nicht erfasst und durch Unwissenheit murks gemacht. Das passiert weitaus öfters. Promintestes Beispiel ist highway=service vs. highway=services. Das kleine s am Ende entscheidet über Zufahrsstraße oder Raststätte. Wer da blind über Tagwatch oder OSMDOC agiert, bekommt die highway=services oft als Schreibfehler von highway=service präsentiert. Wer dann den Hintergrund nicht kennt, macht fix aus Raststätten Zufahrsstraßen. Anders sähe es aus, wenn bicycle=yes *immer* ein anderes Tag brauchen würde um Sinn zu machen. Das ist aber nicht so. Dem ist aber sowas von so. Ein bicycle=yes / no kommt nicht aus irgendeiner Eingebung sondern muss einen Grund haben. Zusammen mit Highway entspricht das einem Gesetz oder einem Schild vor Ort. Als Punkt beispielsweise zusammen mit einer Barriere. Durch was ist denn ein bicycle=yes ohne alles begründet? Standest du da und eine Stimme sagte zu dir, dass dort Fahhräder lang dürfen? Und ja, es gibt auch unfertig gemapptes. Genau dafür gibts aber Note oder FIXME, oder man kann es anderweitig dokumentieren. Du kannst natürlich auch 3 Punkte als Wegverländerung, Access ohne alles und eine Schüssel mit drei Klösen malen. Da muss ich aber damit rechnen das kaum einer versteht was dahinter stecken soll. Denn das ist nunmal nicht üblich und undokumentiert kanns keiner erahnen. Und in dem Fall ziehts auch nicht. Guidepost mit bicycle=yes ist klar definiert und dokumentiert und soll eben nicht für access stehen. Der Fall ist eigentlich klar. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Und in dem Fall ziehts auch nicht. Guidepost mit bicycle=yes ist klar definiert und dokumentiert und soll eben nicht für access stehen. Der Fall ist eigentlich klar. Gruß Mirko Ich finde es absolut unpassend denselben Tag mit mehreren Bedeutungen zu benutzen. Es ist komplett egal ob dokumentiert oder undokumentiert - gleicher Tag = gleiche Bedeutung. Nur so kann es keine Ueberraschungen durch neue Tags/Keys geben. Und bicycle=yes bedeutet fuer mich logischerweise, Ich darf das Hinweisschild ueberfahren. Das ist nunmal aber Sachbeschaedigung. Also hat bicycle=yes dort nichts zu suchen. Ich tagge ja auch nicht amenity=parking bicycle=yes um darzustellen das hier Fahrraeder parken duerfen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On 12.01.2010 15:12, Sarah Hoffmann wrote: André Riedel schrieb: Am 11. Januar 2010 21:50 schrieb Chris-Hein Lunkhusenchris66nrw at gmx.de: Chris-Hein Lunkhusen schrieb: Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. So, nun hab ich mich mal schlau gemacht. Also der Trigger für die oben genannte mkgmap Option ist der access-Tag. Nach dem Proposal [1] könnte man die Aussage: Wegweiser enthält Informationen für Alles außer Autos mit access=yes, motorcar=no taggen, und das wäre dann ein Problem für's Routing: http://up.picr.de/3574740.png ;-) Chris [1]http://wiki.openstreetmap.org/wiki/Information Schönes Beispiel, könntest du mir noch den Wegweiser dazu zeigen ;-) Meiner Meinung nach dürften alle im Proposal erwähnten Elemente nicht Teil eines Weges sein. Würde dies so umgesetzt werden, gäbe es dein Problem nie. Außerdem wird mit dieser Vereinfachung eine wichtige Information, der genauen Lage des Wegweisers, einfach unterschlagen. Also Wegweiser, Karte usw. mit neuen Node an genauen Standort neben der Straße eintragen. Es gibt da ein kleines Problem mit der Schweiz. Hier dürften sich geschätze 90-95% der Wegweiser auf der Strasse befinden. Ich muss gestehen, dass das meine Schuld ist. Ich hatte damals, als ich das Proposal für die Schweizer Wanderwege geschreiben hatte, vorgeschlagen, die Wegweiser auf den Wegen zu plazieren, weil sie eben als Knotenpunkte im Wanderwegenetz dienen. Es erschien mir nützlicher, sie im Wanderwege- netz korrekt zu plazieren, als in der Landschaft. Damals hat sich jedenfalls keiner beschwert und die Nutzung hat sich so eingebürgert. Ich persönlich bin auch der Meinung, dass das trotz der neuen *=yes-Tags kein Problem ist, weil a) ein Router das Haupttag immer mitauswerten sollte und b) ein *-no-Tag am Wegweiser nicht wirklich Sinn macht. Wer sagt das guidepost oder was auch immer ein Haupttag ist. Es gibt keine Definition was ein Haupttag ist, solange bicycle=yes auch alleine eine Bedeutung hat. In der Datenbank steht bicycle=yes ja nicht als Unterpunkt von XXX=YYY drinnen, sondern als unterpunkt des Nodes. Autoroutingprogramme koennen unmoeglich alle Tagkombinationen auswerten, weil es da Millionen von Kombinationen gibt. Solange es in der Datenbank keine Moeglichkeit gibt, bicycle=yes als Untertag einzutragen, kann man es also auch nicht so betrachten. bicycle=yes als Tag besteht schon viel laenger als information=guidepost. Also kann bicycle=yes schwerlich ein Untertag von information=guidepost sein. Wie dem auch sei, die Situation mag zwar nicht ideal sein, wird sich wohl aber auch nicht mehr ändern, es sei denn, jemand macht sich auf und verifiziert die Standorte aller 2361 eingetragenen Schweizer Wegweiser. Es macht also nicht viel Sinn, darüber zu diskutieren, Wegweiser auf Wegen als falsch zu deklarieren und zu verbieten. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
André Riedel schrieb: Gegenbeispiel für ein schon weit verbreitetes Tag: http://wiki.openstreetmap.org/wiki/DE:Key:crossing Was mache ich, wenn ich ausdrücken will, dass bei einer Kreuzung nur 2 der 4 Übergänge für den Fahrradverkehr freigegeben. Ist kein Gegenbeispiel, da bicycle=no hier ebend auch heisst: Keine Durchfahrt für Fahrräder. Trotzdem natürlich auch problematisch für Router, da es nur in einer Richtung gilt. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Ich finde es absolut unpassend denselben Tag mit mehreren Bedeutungen zu benutzen. Sagt auch keiner. Aber woher kommt die Meinung das bicycle=yes auf ewig nur Zugangsbeschränkung bedeutet und der Weisheit letzter Schluss ist und trotz Problemen nicht angetastet werden darf? Weil es schon immer so war? Kein Argument. Weil eine Reform nunmal mit Arbeit verbunden ist? Auch kein Argument. Denn man wird immer wieder auf Probleme stoßen mit denen man bei Einführung des einen oder anderen Tags nicht gerechnet hat. Entweder wirds optimiert, oder wir sitzen es aus reine Beqeumlichkeit aus und taggen uns an einigen Stellen in eine Sackgasse. Es ist komplett egal ob dokumentiert oder undokumentiert - gleicher Tag = gleiche Bedeutung. Nur so kann es keine Ueberraschungen durch neue Tags/Keys geben. Überrascht ist nur der welcher sich nicht informiert. Nur wird derjenige damit immer Probleme haben. Wir haben keine Standards und da jeder machen kann was er will, wird es immer zu Überraschungen kommen. Wer das nicht einkalkuliert ist hier falsch. Und bicycle=yes bedeutet fuer mich logischerweise, Ich darf das Hinweisschild ueberfahren. Das ist nunmal aber Sachbeschaedigung. Also hat bicycle=yes dort nichts zu suchen. Wenn das deine Logik ist dann hast du erstens nicht gelesen in welchem Kontext das steht, und zweitens wäre das Auto mit den eckigen Rädern fällig. Übersetzt heißt das nichts anderes wie Fahrrad=Ja, das ist neutral und könnte beispielsweise auch in Buslinien stehen. Fahrrad=Ja, weil im Bus auch Fahrräder transportiert werden können. Im Fall von Guidepost eben Fahrrad=Ja, weil dort Informationen für Radler stehen. Der Kontext machts, nicht der Umstand das man irgendwann nicht die Weitsicht hatte das Fahrrad=Ja auch anderweitig Sinn machen könnte und es sich so eingebürgert hat das nun jeder Fahrrad=darf befahren sieht. Aus heutiger Sicht mit heutiger Erfahrung einfach unschön. Ich tagge ja auch nicht amenity=parking bicycle=yes um darzustellen das hier Fahrraeder parken duerfen. Schonmal nachgeschaut ob das andere nicht doch schon tun? Und sicherleich erholst du dich auch nicht im Knast, hoffentlich wenn man deiner Logik folgt, hast aber sicherlich schon Annehmlichkeit=Gefängnis aka amenity=prison getaggt. Eine weitere Fehlbesetzung aus den Anfangstagen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Felix Hartmann schrieb: Wer sagt das guidepost oder was auch immer ein Haupttag ist. Es gibt keine Definition was ein Haupttag ist, solange bicycle=yes auch alleine eine Bedeutung hat. In der Datenbank steht bicycle=yes ja nicht als Unterpunkt von XXX=YYY drinnen, sondern als unterpunkt des Nodes. Autoroutingprogramme koennen unmoeglich alle Tagkombinationen auswerten, weil es da Millionen von Kombinationen gibt. Ich komme mittlerweile zum Schluss, dass die einzige funktionierende Option eine Whitelist ist. access-Tags (einschließlich maxheight, bicycle uvm.) können nur dann routingrelevante Zugangsrechte ausdrücken, wenn auch ein bekannter anderer Tag am gleichen Objekt hängt: highway, barrier, crossing. Wenn sie mit anderen, unbekannten oder ohne jegliche begleitende Tags verwendet werden, werden sie ignoriert. Andere Vorgehensweisen kommen weder mit unkontrolliertem Neuerfinden von Tags, noch mit den bereits jetzt unterschiedlichen Bedeutungen abhängig von den begleitenden Tags (z.B. crossing, parking) zurecht. Auch wenn man guidepost jetzt noch umbiegen könnte, für die anderen existierenden abweichenden Bedeutungen gilt das kaum mehr. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On Tue, Jan 12, 2010 at 06:51:36PM +0100, Felix Hartmann wrote: On 12.01.2010 15:12, Sarah Hoffmann wrote: Ich persönlich bin auch der Meinung, dass das trotz der neuen *=yes-Tags kein Problem ist, weil a) ein Router das Haupttag immer mitauswerten sollte und b) ein *-no-Tag am Wegweiser nicht wirklich Sinn macht. Wer sagt das guidepost oder was auch immer ein Haupttag ist. Es gibt keine Definition was ein Haupttag ist, solange bicycle=yes auch alleine eine Bedeutung hat. In der Datenbank steht bicycle=yes ja nicht als Unterpunkt von XXX=YYY drinnen, sondern als unterpunkt des Nodes. Autoroutingprogramme koennen unmoeglich alle Tagkombinationen auswerten, weil es da Millionen von Kombinationen gibt. Solange es in der Datenbank keine Moeglichkeit gibt, bicycle=yes als Untertag einzutragen, kann man es also auch nicht so betrachten. bicycle=yes als Tag besteht schon viel laenger als information=guidepost. Also kann bicycle=yes schwerlich ein Untertag von information=guidepost sein. Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten benutzt wird, während ein Untertag nur in Kombination mit anderen Tags anzutreffen ist. Diese Art von Hierarchie hat sich in OSM sehr wohl etabliert, auch wenn es nicht im Datenbank-Schema festgeschrieben ist. highway=* ist ein Haupttag. tourism=* eines. information=guidepost ist keines und bicycle=* sicherlich auch nicht. Eben weil das Tagging-Schema bei OSM so in Fluss ist, sollte eine Software nur Elemente auswerten, wo sie die Haupttags kennt. Alles andere wird früher oder später zu Schwierigkeiten führen. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Andre Joost schrieb am 12.01.2010 15:18: Sarah Hoffmann schrieb: Hier dürften sich geschätze 90-95% der Wegweiser auf der Strasse befinden. Genauso habe ich das für die Radwegweiser in NRW gemacht, aus ähnlichen Gründen. Bei den Radwegenetzen, die ich gerade erfasse, lege ich die Wegweiser absichtlich neben die Wege aus folgenden Gruenden: 1. Zum Teil sind die Wegweiser eher versteckt untergebracht. Da kann das durchaus helfen, wenn man auf der Karte sehen kann, wo neben der Strasse der Wegweiser zu suchen ist. 2. Zum Teil werden Strassen ja ueber mehrere ways erfasst (mehrspurige Strassen mit Mittelstreifen) und zum Teil werden ja leider auch die Radwege separat erfasst. Da besteht dann eine Kreuzung aus mehr als einem Knotenpunkt. Welchen sollte man dann fuer den Wegweiser nehmen. 3. In Bremen gibt es an manchen Kreuzungen auch mehrere Radwegweiser, fuer jede Anfahrtrichtung einen. Und um die Sache moeglichst kompliziert zu machen, sind auf den einzelnen Wegweiser nicht immer die selben Richtung ausgeschildert, und selbst wenn, dann stehen da nicht immer die selben ziele drauf. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 12.01.2010 19:13, schrieb Mirko Küster: Ich finde es absolut unpassend denselben Tag mit mehreren Bedeutungen zu benutzen. Sagt auch keiner. Aber woher kommt die Meinung das bicycle=yes auf ewig nur Zugangsbeschränkung bedeutet und der Weisheit letzter Schluss ist und trotz Problemen nicht angetastet werden darf? Weil es schon immer so war? Kein Argument. Weil eine Reform nunmal mit Arbeit verbunden ist? Auch kein Argument. Denn man wird immer wieder auf Probleme stoßen mit denen man bei Einführung des einen oder anderen Tags nicht gerechnet hat. Entweder wirds optimiert, oder wir sitzen es aus reine Beqeumlichkeit aus und taggen uns an einigen Stellen in eine Sackgasse. ... und weil du die Weisheit mit Löffeln gefressen hast, ändern wir jetzt mal überall an den Definitionen rum, bis dann keiner mehr bei irgendwas durchblickt. Toller Plan. Veränderung bedeutet nicht zwangsläufig, das etwas besser wird. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
... und weil du die Weisheit mit Löffeln gefressen hast, ändern wir jetzt mal überall an den Definitionen rum, bis dann keiner mehr bei irgendwas durchblickt. Toller Plan. Hör doch mal diesem persöhnlichem Schwachsinn auf. Ich möchte nur gerne wissen warum sich da nichts ändern darf. Beispiele hatte ich schon gebracht. Nur kriege ich immer nur zu hören das es so ist wie es ist und es sich desshalb nicht ändern kann. Das ist kein Argument. Es geht auch nicht darum dutzende Tags zu ändern sondern einen durchdacht den aktuellen Bedürfnissen anzupassen und zu konkretisieren. Die Konsequenz vom Aussitzen des einen würde wiederum die Einführung dutzender anderer bedeuten, wo ein Fahrrad=ja mehr als ausgereicht hätte. Das ist dann wiederum kein Problem und alle blicken durch? Für jeden Fall wo man ein Fahrrad=ja gebrauchen könnte, müsste jeweils extra ein Irgendwas:Fahrrad=ja erfunden werden, es bleibt ja nicht nur bei information:bicycle=yes. Jetzt möchte ich von dir ein vernünftiges Argument hören warum ein access:bicycle=yes mit Erweiterung von anderen längst fälligen Angaben aus der Praxis und für alle anderen Fälle ein simples bicycle=yes nicht geht während ein unangestastetes bicycle=yes bei Acesss, mit bestehenden kombinationsproblemen und die Erfindung von information:bicycle=yes, puplic_transport:bicycle=yes... usw. absolut kein Problem sind. Kein Argument ist das es irgendwann mal so reingeschrieben wurde, auch nicht das eine Änderung Arbeit bedeutet. Tagumbauten gab es schon immer. Die heutigen barrier=* standen einst mal einzeln unter highway=*, blitzer wurden in enforcement eingeordnet, selbst der hier umstrittene Guidepost war sogar zusammen mit Shops mal unter amenity=* eingeordnet. Das Abendland ging nicht unter, trotz Tag oder Definitionsänderung. Und hier ginge es nichtmal darum das Pferd neu zu satteln, der Tag wird nur erweitert. Veränderung bedeutet nicht zwangsläufig, das etwas besser wird. Kommt drauf an was hinten rauskommt. Ein generelles mauern wegen ist so bringt aber auch nicht weiter. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On 12.01.2010 21:36, Mirko Küster wrote: ... und weil du die Weisheit mit Löffeln gefressen hast, ändern wir jetzt mal überall an den Definitionen rum, bis dann keiner mehr bei irgendwas durchblickt. Toller Plan. Hör doch mal diesem persöhnlichem Schwachsinn auf. Ich möchte nur gerne wissen warum sich da nichts ändern darf. Beispiele hatte ich schon gebracht. Nur kriege ich immer nur zu hören das es so ist wie es ist und es sich desshalb nicht ändern kann. Das ist kein Argument. Dann starte doch ein Proposal im Wiki. Dann wird man ja sehen was die allgemeinheit davon haelt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster wrote: Kommt drauf an was hinten rauskommt. Ein generelles mauern wegen ist so bringt aber auch nicht weiter. Ulf mauert doch nicht. Er hat - wie auch andere - versucht dir klarzumachen, wo das Problem liegt. Das derzeitige bicycle=yes kann (noch!) bei echtem Bedarf einmal zu access:bicycle=yes o.ä. gewandelt werden, denn für genau diesen Fall ist es definiert. Wenn du jetzt aber bicycle=yes mit anderer Bedeutung nutzen willst, dann ist diese Möglichkeit verbaut. Wer ein altes key/value-Paar mit einer neuen Bedeutung versehen will, der verwässert die in der DB gespeicherten Informationen. Natürlich gibts da Gegenwind von denen, deren Arbeit da teilentwertet werden würde. Norbert (Und komm' nicht mit abhängig vom Haupttag - was soll das sein?) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann wrote: Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten benutzt wird, während ein Untertag nur in Kombination mit anderen Tags anzutreffen ist. Diese Art von Hierarchie hat sich in OSM sehr wohl etabliert, auch wenn es nicht im Datenbank-Schema festgeschrieben ist. highway=* ist ein Haupttag. tourism=* eines. information=guidepost ist keines und bicycle=* sicherlich auch nicht. Und du schreibst also vor, das je way oder node nur genau einer dieser Haupttags genutzt werden darf? Ich nehme an, du überarbeitest jetzt auch alle Knoten, an denen derzeit z.B. amenity *und* shop vorhanden sind. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Dann starte doch ein Proposal im Wiki. Dann wird man ja sehen was die allgemeinheit davon haelt. Genau das versuche ich in dem Stadium erst garnicht weil du mit einem Proposal auch nur die Meinung von nicht repräsentativen 0.01% der Community erfährst. Die wahre Abstimmung findet in der DB selber über die tatsächliche Nutzung statt, nicht über die Meinung einiger weniger. Und genau davon erzähle ich die ganze Zeit. Im Wiki stehen Empfehlungen und keine unabänderbaren Naturgesetzte. Übrigends gibts da schon lange verschiedene Gedanken zur kombinierung der Tags, wo sich Probleme wie nur einmalig nutzbare Tags, wo man das ganze aber zweimal oder mehr bräuchte, Lösen. Und das sollte man sich erstmal alles angucken und gegebenfalls etwas ausarbeiten. Des weiteren wichtige Erweiterungen wie Bei Nässe etc. was mit dem derzeitigen Schema ebenfalls nicht geht. Und im gleichem Atemzug kannst du den Access auch gleich mit einem access:foo=bar konkretisieren und die eigentlich neutralen Tags wieder für eine simple Aussage die in vielen Fällen generell passt befreien und so dutzende neue Tags einsparen. http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags Lohnt es sich da wirklich überhaupt nicht mal drüber nachzudenken? Sind alle wirklich mit der jetzigen Situation zufrieden und keiner stand mal vor zwei Sperrzeiten für zwei unterschiedliche Fahrzeugtypen auf ein und derselben Straße, oder anderen Problemen die so jetzt garnicht gehen? Ich würde ja verstehen wenn da wirkliche Argumente kommen würden die aufzeigen das es wirklich problematisch und nicht umzusetzen ist. Aber solange da nur ist so wie es ist kommt, ist das keine befriedigende Antwort. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Ulf mauert doch nicht. Er hat - wie auch andere - versucht dir klarzumachen, wo das Problem liegt. Das derzeitige bicycle=yes kann (noch!) bei echtem Bedarf einmal zu access:bicycle=yes o.ä. gewandelt werden, denn für genau diesen Fall ist es definiert. Nein denn er will ja garnicht erst von bicycle=yes weg sondern alles andere soll sich bitte eine entsprechend neue Definition suchen. Er klebt an seiner Definition, Begründung weil etabliert. Zitiere mir mal die Stelle wo es so rüberkommt wie du schreibst, ich finde sie ehrlich gesagt nicht. Das access:bicycle=yes kam von mir und genau da möchte ich mit einigen anderen Ergänzungen hin. Und wenn jetzt der Bedarf aufkommt das ganze zu konkretisieren, ist es höchste Eisenbahn den Schritt zu gehen. Oder wann soll das passieren? Die echten Abstimmungen finden auf der DB statt und nicht in irgendeinem unrepräsentativen Proposal im Wiki. Du kannst jetzt versuchen eine Verwendung von bicycle=yes für alles andere als access zu verbieten. Es ist nur fraglich ob das so aufzuhalten ist. Wenn du jetzt aber bicycle=yes mit anderer Bedeutung nutzen willst, dann ist diese Möglichkeit verbaut. Eine Möglichkeit die doch keiner hier in betracht zieht. Wann soll die kommen? Wer ein altes key/value-Paar mit einer neuen Bedeutung versehen will, der verwässert die in der DB gespeicherten Informationen. Natürlich gibts da Gegenwind von denen, deren Arbeit da teilentwertet werden würde. Da wird doch nichts verwässert weil beide Tags zusammen einen anderen dokumentierten Kontext ergeben. Ein bicycle=yes kann auf einem Guidepost kein access sein. Ergo kannst du Guidepost bei einer Routinganwendung guten gewissens ignorieren. (Und komm' nicht mit abhängig vom Haupttag - was soll das sein?) Schon tausende male geschrieben. Ein Access hat immer einen Grund und kann nur zusammen mit bekannten Objekten vorkommen. Als Gesetz oder Schild auf einem Way zusammen mit highway, oder als Punkt auf einem Hinderniss, da zusammen mit barrier. Nicht vorhandenes und unfertiges gehört als solches gekennzeichnet. bicycle=yes ohne weiteres auf einem Node kann nicht korrekt sein, weil der Grund dafür fehlt. Du stehst nicht irgendwo und hast die Eingebung das dort Fahrrad erlaubt ist. Das muss einen Grund haben und ist abhängig von einem Objekt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Felix Hartmann extremecar...@googlemail.com writes: Und bicycle=yes bedeutet fuer mich logischerweise, Ich darf das Hinweisschild ueberfahren. Du hättest das haupttag beachten müssen. Ich tagge ja auch nicht amenity=parking bicycle=yes um darzustellen das hier Fahrraeder parken duerfen. Das ist völlig legitimes tagging. Viel besser, als erläuternde info in den tagnamen zu packen -- das skaliert nämlich auf dauer nicht. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann schrieb: Mit Haupttag meinte ich ein Tag, dass ganz alleine an einem Weg oder Knoten benutzt wird, während ein Untertag nur in Kombination mit anderen Tags anzutreffen ist. Dieser Ansatz scheitert kläglich, wenn an einem Knoten mehrere Haupttags hängen. Das ist bislang nicht verboten. Diese Art von Hierarchie hat sich in OSM sehr wohl etabliert, auch wenn es nicht im Datenbank-Schema festgeschrieben ist. highway=* ist ein Haupttag. tourism=* eines. information=guidepost ist keines und bicycle=* sicherlich auch nicht. Eben weil das Tagging-Schema bei OSM so in Fluss ist, sollte eine Software nur Elemente auswerten, wo sie die Haupttags kennt. Alles andere wird früher oder später zu Schwierigkeiten führen. Mit access:bicycle=* oder information:bicycle=* liesse sich das eindeutig trennen. Nur wer bringt das den proposals und Editoren schonungsvoll bei? Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Chris-Hein Lunkhusen schrieb: Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. So, nun hab ich mich mal schlau gemacht. Also der Trigger für die oben genannte mkgmap Option ist der access-Tag. Nach dem Proposal [1] könnte man die Aussage: Wegweiser enthält Informationen für Alles außer Autos mit access=yes, motorcar=no taggen, und das wäre dann ein Problem für's Routing: http://up.picr.de/3574740.png ;-) Chris [1] http://wiki.openstreetmap.org/wiki/Information ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 11. Januar 2010 21:50 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Chris-Hein Lunkhusen schrieb: Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. So, nun hab ich mich mal schlau gemacht. Also der Trigger für die oben genannte mkgmap Option ist der access-Tag. Nach dem Proposal [1] könnte man die Aussage: Wegweiser enthält Informationen für Alles außer Autos mit access=yes, motorcar=no taggen, und das wäre dann ein Problem für's Routing: http://up.picr.de/3574740.png ;-) Chris [1] http://wiki.openstreetmap.org/wiki/Information Schönes Beispiel, könntest du mir noch den Wegweiser dazu zeigen ;-) Meiner Meinung nach dürften alle im Proposal erwähnten Elemente nicht Teil eines Weges sein. Würde dies so umgesetzt werden, gäbe es dein Problem nie. Außerdem wird mit dieser Vereinfachung eine wichtige Information, der genauen Lage des Wegweisers, einfach unterschlagen. Also Wegweiser, Karte usw. mit neuen Node an genauen Standort neben der Straße eintragen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 11.01.2010 22:17, schrieb André Riedel: Am 11. Januar 2010 21:50 schrieb Chris-Hein Lunkhusenchris66...@gmx.de: Chris-Hein Lunkhusen schrieb: Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. So, nun hab ich mich mal schlau gemacht. Also der Trigger für die oben genannte mkgmap Option ist der access-Tag. Nach dem Proposal [1] könnte man die Aussage: Wegweiser enthält Informationen für Alles außer Autos mit access=yes, motorcar=no taggen, und das wäre dann ein Problem für's Routing: http://up.picr.de/3574740.png ;-) Chris [1]http://wiki.openstreetmap.org/wiki/Information Schönes Beispiel, könntest du mir noch den Wegweiser dazu zeigen ;-) Meiner Meinung nach dürften alle im Proposal erwähnten Elemente nicht Teil eines Weges sein. Würde dies so umgesetzt werden, gäbe es dein Problem nie. Außerdem wird mit dieser Vereinfachung eine wichtige Information, der genauen Lage des Wegweisers, einfach unterschlagen. Also Wegweiser, Karte usw. mit neuen Node an genauen Standort neben der Straße eintragen. Chris-Heinz hat doch gezeigt, das es jetzt schon tatsächlich Probleme mit dem Ansatz gibt. Wenn man sich überlegt, daß gehört neben den Weg von genügend Mappern schlicht nicht beachtet werden wird (Sorry, alles andere halte ich nach den bisherigen Erfahrungen für eine naive Annahme), ist das ganze Thema für mich weiterhin ne schlechte Idee :-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 11. Januar 2010 22:53 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Chris-Heinz hat doch gezeigt, das es jetzt schon tatsächlich Probleme mit dem Ansatz gibt. Aber ich kann die theoretischen Probleme nicht unterzeichnen. Ebenso ist mir der zuletzt genannte Wegweiser noch vorgekommen. Wenn man sich überlegt, daß gehört neben den Weg von genügend Mappern schlicht nicht beachtet werden wird (Sorry, alles andere halte ich nach den bisherigen Erfahrungen für eine naive Annahme), ist das ganze Thema für mich weiterhin ne schlechte Idee :-) Wenn es einmal etabliert ist, dass man Wegweiser usw. nicht auf den Weg setzt, sehe ich keine Probleme mehr. Ich habe bisher noch keine Postkästen, Springbrunnen, Hotels, ... direkt auf einer Straße gesehen, also sollte das mit einem Wegweiser doch auch möglich sein? Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Ulf Lamping ulf.lamp...@googlemail.com writes: Wenn man sich überlegt, daß gehört neben den Weg von genügend Mappern schlicht nicht beachtet werden wird Wenn das das einzige wäre, was von mappern nicht beachtet würde... Man wird's eben schlicht berichtigen müssen, wie man auch unverbundene wege verbinden muss, etc. (Sorry, alles andere halte ich nach den bisherigen Erfahrungen für eine naive Annahme), ist das ganze Thema für mich weiterhin ne schlechte Idee :-) Und für mich ist es eine gute :) Reale probleme konnte niemand aufzeigen, nur lustig konstruierte fälle. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Dann hast du wohl das falsche Wort verwendet. Valide heißt gültig/richtig, was du vielleicht meinst ist üblich. Ich verwende aus gutem Grund keine Wischi Waschi Umschreibungen. Wir sind teilweise auf einer Stufe wo undokumentierte Paralelentwicklungen mehr verwaschen und verwirren, die Entwicklung eher behindern als fördern. Deswegen werde ich mich da auch nie hinstellen und zu alles und jedem sagen das es kein Falsch gibt und die Leute noch dazu ermutigen auch teilweise überflüssige Paralelentwicklungen zu verfolgen, die dann undokumentiert nichtmal als solche erkennbar sind. Das hat mit Chaoseinstellung überhaupt nichts zu tun. Das hat was damit zu tun, das vieles von den Problemen wie z.B. die Endlosdiskussionen bei Radwegen genau aus dieser Haltung ich habe recht und du hast Unrecht herkommt. Da war es schlichtes verwaschen. Als man das ganze einführte hat keiner daran gedacht, dass es gefühlte und vorgeschriebene Fahrradwege gibt. Wenn ich das dann noch so lasch verfasse ist klar das alle in eine Soße taggen. Was danach passierte war nicht besser. Man erklräte den Tag als verbrannt und hat den path kurzerhand missbraucht, statt dem eigentlichen Tag gleich einen Zusatz für die jeweilige Richtung zu geben. Danach hat man gleich wieder designated verbrannt und offical erklärt. Das Ergebniss und der Streit ist nur die logische Folge. Nun haben wir 3 Taggingmöglichkeiten für ein und dasselbe. Und das wird sich auch nie ändern, wenn man sich nicht klar zu einem richtig und falsch bekennt. Wenn wir Probleme sehen, sollten wir versuchen diese zu lösen. Das kann aber nicht darin bestehen zu sagen: du siehst das falsch, und du mußt dich anpassen, sondern: ok, da ist ein Problem, was können wir machen um es möglichst schmerzfrei für alle zu lösen. Du hast noch immer kein klares Problem benannt, nur ein mögliches konstruiert. Ich habe hier noch keine Stimme gehört die ein wirkliches existentes Problem benennt. Was sagen die wirklich betroffenen, die Routing Maintainer? Solange keiner erklärt das ein bicycle=yes auf einem Guidepost in der Praxis zu nachvollziehbaren Problemen führt, solange ist es schlicht keines. In den Map Features ist dokumentiert, das bicycle=no bedeutet, daß man da nicht mit dem Fahrrad durchdarf. Es ist dort *nicht* dokumentiert, daß dieses Tag nur in Verbindung mit xy eingesetzt werden muß. Auf welcher Seite? Unvollständige und wiedersprüchliche Angaben sind im Wiki Alltag. Es gebietet aber die pure Logik das ein Verbot nicht aus heiterem Himmel kommt. Entweder steht ein Schild, oder eine Barriere. Ein bicycle=no ohne alles fällt wohl unter göttliche Eingebung, und das ist orakeln. Wenn ich ein Schild tagge, hat das mit Orakeln irgendwie nichts zu tun. Wir taggen bis auf Ausnahmen wie Stopp Schilder keine Schilder ansich, sondern verwerten die Information, welche wir dann mit den richtigen Tags auf das richtige Objekt legen. Ist dir bis heute nicht aufgefallen, daß das durchaus in der Realität auch mal anders aussieht und das Ende-Schild schlicht auch mal vergessen wird? Das ist Richtig. Normal gilt dann bis zu nächsten Einmündung, wo das keine Anwendung findet ist es ein Fehler Straßenbaubehörde, welche ich dann darauf hinweisen kann und was dann vielleicht berichtigt wird. Das ist dann aber nicht mein Problem, was ich dann genauso Fehlerhaft als Krücke umsetzen muss. Fehler sind immer mal drin. Sich gegenseitig ausschließende Verkehrszeichen, die Dr. Barsch Straße, wo einer die B Folie abgekratzt hat, oder wie zuletzt in Halle, wo der braune Abschaum dutzende Straßenschilder mit Rudolf Heß Straße Folien überklebte. Deswegen taggen hier Menschen und keine Drohnen. Wir taggen die Realität, die hat aber auch mal Fehler, die man hinterfragen kann und nicht leidenschaftslos in die DB Prügeln muss. Wenn Mapper A ein Schild einträgt und Mapper B danach mehr Infos hat und die Infos vom Node nimmt und an den passenden Wegabschnitt hängt habe ich damit überhaupt kein Problem. Wenn du jetzt aber kommst und sagst, A hat was falsch gemacht weil er es nicht gleich richtig gemacht hat - damit habe ich ein Problem. Wenn da ein note=FIMXE etc. dranhängt und das so als unvollständige Angabe kennzeichnet, ist das ja noch zu verschmerzen. Ansonsten muss ich davon ausgehen das hier ein Fehler vorliegt, den ich berichtige oder entferne. Die kann man nicht bis zum Sankt Nimmerleinstag so stehen lassen, nur wegen eventuell und vielleicht. Siehe Garrys Checks. Wenn es ans aufräumen geht, hört man nur ein lautes Pfeifen. Die wenigen die sich dem mal annehmen kommen dann nicht mehr hinterher. Die Fälle die mir so unterkamen waren allerdings andere. Ganze Stadtteile wo Verkehrszeichen vollständig getaggt neben den Straßen lagen, die gleichen Informationen teilweise nochmal korrekt auf den Wegen selber. Kannst du wieder unüblich nennen, ich nenne das schlicht falsch. Es gibt da zwei unterschiedliche Vorgehensweisen: a) Ersetzung:
Re: [Talk-de] guidepost
Am 27.12.2009 16:18, schrieb Mirko Küster: Was danach passierte war nicht besser. Man erklräte den Tag als verbrannt und hat den path kurzerhand missbraucht, statt dem eigentlichen Tag gleich einen Zusatz für die jeweilige Richtung zu geben. Danach hat man gleich wieder designated verbrannt und offical erklärt. Das Ergebniss und der Streit ist nur die logische Folge. Nun haben wir 3 Taggingmöglichkeiten für ein und dasselbe. Und das wird sich auch nie ändern, wenn man sich nicht klar zu einem richtig und falsch bekennt. Es hat damals mindestens drei konträre cycleway Parteien gegeben, die sich klar dazu bekannt haben, was aus ihrer Sicht richtig / falsch ist. Die wurden sich dann nicht einig weil sie ja den richtigen Weg bereits wußten. Eine Einigung fand nicht statt. Das ist genau die Grundhaltung, die du hier wiederum an den Tag legst und die damals in den ganzen Ärger überhaupt erst geführt haben. Wenn wir Probleme sehen, sollten wir versuchen diese zu lösen. Das kann aber nicht darin bestehen zu sagen: du siehst das falsch, und du mußt dich anpassen, sondern: ok, da ist ein Problem, was können wir machen um es möglichst schmerzfrei für alle zu lösen. Du hast noch immer kein klares Problem benannt, nur ein mögliches konstruiert. Ich habe hier noch keine Stimme gehört die ein wirkliches existentes Problem benennt. Was sagen die wirklich betroffenen, die Routing Maintainer? Solange keiner erklärt das ein bicycle=yes auf einem Guidepost in der Praxis zu nachvollziehbaren Problemen führt, solange ist es schlicht keines. Weil du kein Problem darin erkennen kannst was dir andere Leute sagen, kann ja keines da sein - bestechende Logik. Entschuldige mal, aber vor zwei Tagen in diesem Thread hatte Martin Simon bemerkt, daß bicycle=no in dieser Bedeutung bei den Mappern nur zu Verwirrungen führen wird. Ich hatte das auch erwähnt und *außerdem* drauf hingewiesen, daß es an Nodes durchaus zu Problemen führen wird. In den Map Features ist dokumentiert, das bicycle=no bedeutet, daß man da nicht mit dem Fahrrad durchdarf. Es ist dort *nicht* dokumentiert, daß dieses Tag nur in Verbindung mit xy eingesetzt werden muß. Auf welcher Seite? Unvollständige und wiedersprüchliche Angaben sind im Wiki Alltag. Was ist an: In den Map Features ist dokumentiert, ... bitte nicht zu verstehen? Die Map Features bestehen aus genau einer Seite. Es gebietet aber die pure Logik das ein Verbot nicht aus heiterem Himmel kommt.Entweder steht ein Schild, oder eine Barriere. Ein bicycle=no ohne alles fällt wohl unter göttliche Eingebung, und das ist orakeln. Ich sehe ein bicycle=no, lese in den Map Features das es sich um eine Zutrittsbeschränkung handelt und weiß dann, das ich dort mit dem Fahrrad nicht lang darf. Wenn du das orakeln nennst, haben wir eine andere Wortbedeutung im Sinn. Wenn ich ein Schild tagge, hat das mit Orakeln irgendwie nichts zu tun. Wir taggen bis auf Ausnahmen wie Stopp Schilder keine Schilder ansich, sondern verwerten die Information, welche wir dann mit den richtigen Tags auf das richtige Objekt legen. Nochmal: Du bist nicht automatisch wir! Es gibt durchaus Leute, die Schilder taggen und ich sehe keinen Grund das verbieten zu wollen. Ist dir bis heute nicht aufgefallen, daß das durchaus in der Realität auch mal anders aussieht und das Ende-Schild schlicht auch mal vergessen wird? Das ist Richtig. Normal gilt dann bis zu nächsten Einmündung, wo das keine Anwendung findet ist es ein Fehler Straßenbaubehörde, welche ich dann darauf hinweisen kann und was dann vielleicht berichtigt wird. Das ist dann aber nicht mein Problem, was ich dann genauso Fehlerhaft als Krücke umsetzen muss. Fehler sind immer mal drin. Sich gegenseitig ausschließende Verkehrszeichen, die Dr. Barsch Straße, wo einer die B Folie abgekratzt hat, oder wie zuletzt in Halle, wo der braune Abschaum dutzende Straßenschilder mit Rudolf Heß Straße Folien überklebte. Deswegen taggen hier Menschen und keine Drohnen. Wir taggen die Realität, die hat aber auch mal Fehler, die man hinterfragen kann und nicht leidenschaftslos in die DB Prügeln muss. Die Realität hat auch mal Fehler - auweia. Wenn Mapper A ein Schild einträgt und Mapper B danach mehr Infos hat und die Infos vom Node nimmt und an den passenden Wegabschnitt hängt habe ich damit überhaupt kein Problem. Wenn du jetzt aber kommst und sagst, A hat was falsch gemacht weil er es nicht gleich richtig gemacht hat - damit habe ich ein Problem. Wenn da ein note=FIMXE etc. dranhängt und das so als unvollständige Angabe kennzeichnet, ist das ja noch zu verschmerzen. Ansonsten muss ich davon ausgehen das hier ein Fehler vorliegt, den ich berichtige oder entferne. Die kann man nicht bis zum Sankt Nimmerleinstag so stehen lassen, nur wegen eventuell und vielleicht. Siehe Garrys Checks. Wenn es ans aufräumen geht, hört man nur ein lautes Pfeifen. Die wenigen die sich dem mal annehmen kommen dann nicht mehr hinterher. Ach so,
Re: [Talk-de] guidepost
Es hat damals mindestens drei konträre cycleway Parteien gegeben, die sich klar dazu bekannt haben, was aus ihrer Sicht richtig / falsch ist. Die wurden sich dann nicht einig weil sie ja den richtigen Weg bereits wußten. Eine Einigung fand nicht statt. Von macht mal, es gibt kein Falsch löst sich das Problem aber auch nicht. Für solche seltenen aber festgefahrenen Situation brauchts einen Entscheider. Wollen einige auch wieder nicht. Es kann doch nich ernsthaft die Lösung sein, das wir auf ewig keinen klaren Tag für so Kleinscheiß wie einen Fahrradweg haben, wir uns desshalb für jegliche professionelle Radrouting Anwendung disquallifizieren, nur weil keiner mal entscheiden mag. Du kannst das im Moment nicht verlässlich auswerten, weil keiner wissen kann, was nun wiederum stimmt. Das ist genau die Grundhaltung, die du hier wiederum an den Tag legst und die damals in den ganzen Ärger überhaupt erst geführt haben. Wie schon geschrieben fiel das Kind schon weit vorher in den Brunnen. Das danach ist eine logische Entwicklung die man bei jedem Projekt mit sovielen Mitstreitern schon millionen male durchgekaut hat. Weil du kein Problem darin erkennen kannst was dir andere Leute sagen, kann ja keines da sein - bestechende Logik. Entschuldige mal, aber vor zwei Tagen in diesem Thread hatte Martin Simon bemerkt, daß bicycle=no in dieser Bedeutung bei den Mappern nur zu Verwirrungen führen wird. Ich hatte das auch erwähnt und *außerdem* drauf hingewiesen, daß es an Nodes durchaus zu Problemen führen wird. Ein Problem wäre wenn z.B. ein Routing Maintainer kommen würde und sagt, passt auf, das kommt in der Praxis bei der Auswertung der Daten zu Missverständnissen ich kann das nicht wegfiltern. Dein zweiter Absatz ist noch immer Käse, weil keiner mit dem Fahrrad auf einen Wegweise rauffährt. Im JOSM Preset steht oben noch extra drüber Dargestellte Routen für:, darunter noch ein Link zum Wiki, da kannst du das ebenfalls nochmal lang und breit ausführen. Wer dann beim Guideposttagging statt auf der zugehörigen Beschreibung auf Seiten sucht die damit garnichts zu tun haben, dann ist demjenigen auch nicht mehr zu helfen. Mit solcherlei Haarsträubenden Behauptungen kann ich dir Probleme ohne Ende zaubern. Was ist an: In den Map Features ist dokumentiert, ... bitte nicht zu verstehen? Die Map Features bestehen aus genau einer Seite. Die wiederum andere Seiten verlinkt, die wiederum mehrfach auf Access eingeht. Wenn du eventuelle Verwirrungen anprangerst dann kannst du beim Wiki anfangen. Ich kann Tags erfinden wie ich will, wenns beschissen bis garnicht dokumentiert ist, geht auch das beste Tagginschema vor die Hunde. Oben verlinkt DE:Germany roads tagging ausgeschilderter Radweg (Zeichen 237) highway=cycleway + bicycle=designated Darunter DE:Howto Map A Fahrradweg nicht Teil einer Auto-Fahrbahnführung highway=cycleway+ surface=paved/unpaved Noch einer runter DE:Road Signs highway=path + bicycle=designated In den Features selbst DE:Tag:highway=cycleway Für ausgewiesene (designated) Fahrradwege Wege die lediglich für Fahrräder erlaubt sind, aber nicht ausgewiesene Fahrradwege sind, sollten mit bicycle=yes eingetragen werden. Gemischte Rad- und Fußwege sollten mit highway=path und entsprechenden access=*-Tags eingetragen werdenZeiche einen Weg und füge die Tags highway=path, bicycle=designated sowie name=(wenn bekannt) hinzu. Benutze den access=* Schlüssel um eventuelle weitere Zugangsberechtigungen zu beschreiben. Weiter runter Beschränkungen. Auf der Hauptseite Schlüssel bicycle, Wert yes / designated / official / private / permissive / dismount / destination / delivery / agricultural / forestry / unknown / no Element Weg , nicht Node. Einzig auf direkt DE:Key:access steht unter Beispiele ganz lapidar bicycle=no - Der Weg ist für Fahrradfahrer gesperrt. Und das ist jetzt deine Rechtfertigung warum das so alleine total in Ordnung ist, auch wenn dass ohne Beschreibung des Ausschlagebenden Objektes keinen Sinn ergibt? Wie hier was getaggt wird, hängt leider mit davon ab, welche Beschreibung man zuerst findet. Im Wiki existiert nichtmal der Ansatz einer klaren Linie. Hier werden die Einstieger gleich mehrfach gerollt. Ich sehe ein bicycle=no, lese in den Map Features das es sich um eine Zutrittsbeschränkung handelt und weiß dann, das ich dort mit dem Fahrrad nicht lang darf. Was aber einen Grund haben muss der auch von dritten nachvollziehbar sein muss. Entweder steht da ein Schild oder eine Barriere. Ohne diese Angabe ist die Geschichte unvollständig. Und damit etweder als unvollständig zu kennzeichnen oder schlicht ein Fehler. Ansonsten kann ich hier mal eben einen hgv=no Node auf den Orstseingang klatschen und behaupten das ist so, ich habe ein Schild getaggt. In Wahrheit wollte ich aber nur die lauten LKW vom Routing ausschließen. Nochmal: Du bist nicht automatisch wir! Es gibt durchaus Leute, die Schilder taggen und ich sehe keinen
Re: [Talk-de] guidepost
Am 27.12.2009 21:03, schrieb Mirko Küster: Und damit gut. Du hast Recht, ich meine Ruhe und die weitere Entwicklung wird sowieso abseits dieser Diskussion mit den Füßen abgestimmt... Du hast deine Meinung und läßt andere Meinungen nicht gelten, weil: unlogisch, Ansatz ist Käse, stark dafür einsetzt dass wir irgendwann schön in Fehlern ersaufen, absurde Erklärung, Evolutionsbremsen, ... Das klingt jetzt alles so, daß du versuchst deine Lösung durchzusetzen, weil ja die anderen sowieso Idioten sind. Wenn ich solche Aussagen von dir wie: das wir auf ewig keinen klaren Tag für so Kleinscheiß wie einen Fahrradweg haben sagt mit inzwischen, das du anscheinend wenig Ahnung von der Komplexität des Themas hast. Du hast recht, eine weitere Diskussion mit dir bringt daher schlicht nichts. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 26.12.2009 05:49, schrieb Karl Eichwalder: Ulf Lampingulf.lamp...@googlemail.com writes: bicycle=no ist (bislang) immer eine routingrelevante Anweisung. Ob das für Nodes relevant ist oder nicht würde ich bestenfalls als ungeklärt deklarieren. Meine Meinung dazu hatte ich ja bereits geäußert. Ja, und? Wenn die routing-software nicht die haupttags gebührend berücksichtigt, ist sie sowieso nicht hinreichend robust. Es ist für *alle* Beteiligten verwirrend, wenn ein bislang seit mehreren Jahren klar definiertes Tag (und davon haben wir schon wenig genug) für etwas völlig anderes wiederverwendet wird. Beispiel: Wenn ein Mapper auf bicycle=no stößt, schaut er in den Map Features nach und sieht dort da darf man mit dem Fahrrad nicht durch oder er weiß einfach diese Bedeutung. Dann schmeißt er das Tag wieder raus weil es ganz offensichtlich nicht stimmt - er weiß nämlich, daß man da mit dem Fahrrad durchdarf. Ziel erreicht, alle verwirrt und genervt. Gruß, ULFL P.S: Hast du eigentlich die ganzen endlosen Diskussionen und Probleme, die eine geänderte Nutzung von etablierten Tags verursacht, schlicht verschlafen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Das ist *deine* Sicht der Dinge. Versuch das bitte auch so (und nicht als das ist so) zu schreiben. Ein access ohne Hauptag gibts schlich nicht. Da gibts nichts zu deuteln. Für jede Accessregelung muss eine übergeordnete Beschreibung vorhanden sein. Zugangsregeln sind Zusatzbeschreibungen die nicht allein stehen können. Das ist nicht meine Sicht sondern schlicht und einfach im Tagging so umgesetzt. Mal davon abgesehen, daß bicycle auf Nodes bereits ~35000 mal existiert. Und? Das kommt schonmal auf so ziemlich jeder Barriere legitim zum Einsatz. Keine Ahnung, wie viele davon z.B. mit barrier=xy und wie viele davon standalone vorliegen. Ist doch auch egal. Weil nur die mit barrier als Hauptbeschreibung valid sind. Wenn du die Daten für ein Routing Grid ziehst dann nimmst du doch nur alles relevante wie highway=*, barrier=* etc. mit. Die bringen ihre access automatisch mit. Nodes mit access allein bleiben da ganz automatsisch liegen. Mit keinem Tool der Welt kannst du dann sowas aus der ferne fixen, weil du nicht mehr weißt was der Mapper mit access=no gemeint hat (bislang ist das für mich noch recht klar). Ein node mit einzig access=no ist in unserem Tagginschema nicht valide, weil das als Zusatzangabe immer einen Haupttag haben muss. Sowas heraus zu filtern kriege sogar ich hin, obwohl ich kein Programmierer bin. Da automatisch wenigstens ein FIXME dranhängen ist kein gordischer Knoten. Im Zweifelsfall kann man diesen klaren Fehler auch einfach löschen. Hier *bewußt* zu sagen: ist ja egal wenn man jetzt schon die Probleme klar benennen kann finde ich ziemlich dürftig. Was benennst du den da klar? Guidepost ist ein Tag der außer bei der Wanderkarte von jedem Routing Grid schon bei der Datenaubfbereitung ignoriert wird. Ansonsten zählt Guidepost nicht zu der Liste der routingrelevanten Objekte, wird also garnicht auf ein mögliches access ausgewertet und hat keinen Einfluss. Der Rest steht schon oben. Bennene doch mal einen konkreten und wirklich realistischen Fall, wo da ein echtes Problem definitiv möglich ist. Bisher sehe ich nur Nebelkerzen. Im übrigen hatte ich schon was dazu geschrieben. fahrrad=ja ist ein neutraler Tag der wunderbar für nicht weiter zu beschreibene Aussagen passt. Man hat es schon bei access versäumt das klar zu bennen. Dort hätte man access:bicycle=yes machen können. Stattdessen ist der neutrale Tag dort schon mit dem ersten Einsatzgebiet festgenagelt und man müsste für jeden Hutzelbutz ein eigenen Tag erfinden. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo, Ulf Lamping wrote: Mal davon abgesehen, daß bicycle auf Nodes bereits ~35000 mal existiert. Keine Ahnung, wie viele davon z.B. mit barrier=xy und wie viele davon standalone vorliegen. In Deutschland gibt es rund 34500x bicycle=* an Nodes, davon rund 30600 (89%) zusammen mit barrier, 1550 (4,5%) zusammen mit tourism und ebenfalls 1550 zusammen mit highway. 194 mal (0,6%) kommt das Tag standalone vor, davon 102 mit no, 62 mit yes, 30 mit designated. Be Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 26.12.2009 13:05, schrieb Mirko Küster: Das ist *deine* Sicht der Dinge. Versuch das bitte auch so (und nicht als das ist so) zu schreiben. Ein access ohne Hauptag gibts schlich nicht. Da gibts nichts zu deuteln. Für jede Accessregelung muss eine übergeordnete Beschreibung vorhanden sein. Zugangsregeln sind Zusatzbeschreibungen die nicht allein stehen können. Das ist nicht meine Sicht sondern schlicht und einfach im Tagging so umgesetzt. Und genau das *ist* deine Sicht der Dinge. Wenn du das bislang in deinem persönlichen Tagging so umgesetzt hast, oder diese Erkenntnis aus den Map Features rausgelesen hast, oder auch diese Definition als einzig logische für dich gewonnen hast, heißt das nicht, daß andere nicht zu völlig anderen Erkenntnissen gekommen sind. Diese Erkenntnis aus den ewigen Diskussionen in der Vergangenheit sollte doch so langsam mal bei allen angekommen sein. Keine Ahnung, wie viele davon z.B. mit barrier=xy und wie viele davon standalone vorliegen. Ist doch auch egal. Weil nur die mit barrier als Hauptbeschreibung valid sind. Wenn du die Daten für ein Routing Grid ziehst dann nimmst du doch nur alles relevante wie highway=*, barrier=* etc. mit. Die bringen ihre access automatisch mit. Nodes mit access allein bleiben da ganz automatsisch liegen. Weil nur die mit barrier als Hauptbeschreibung valid sind. - wenn ich sowas lese muß ich lachen. So etwas wie valid gibt es bei OSM nicht. Wenn einer einen Node mit bicycle=no hinsetzt, ist das genauso valid wie wenn er sowas wie barrier=street_sign dazusetzt. Ist dir eigentlich bewußt, daß es das barrier Tag solange noch garnicht gibt? Ich bestreite nicht, daß es besser ist sowas an den Weg zu setzen. Aber was macht man wenn die Infos nicht vorhanden sind wie weit denn diese Beschränkung geht. Inzwischen könnte man dafür sowas wie barrier=street_sign setzen, aber wie gesagt, so lange gibt es barrier noch nicht. Jetzt alle bisherigen access=xy Nodes damit in ihrer Bedeutung wegzuschmeißen weil man nicht einsehen mag das bisher so getaggt wurde - ist schon kontraproduktiv. Mit keinem Tool der Welt kannst du dann sowas aus der ferne fixen, weil du nicht mehr weißt was der Mapper mit access=no gemeint hat (bislang ist das für mich noch recht klar). Ein node mit einzig access=no ist in unserem Tagginschema nicht valide, weil das als Zusatzangabe immer einen Haupttag haben muss. Diese Aussage ist halt aus meiner Sicht schlicht und ergreifend falsch. Im übrigen hatte ich schon was dazu geschrieben. fahrrad=ja ist ein neutraler Tag der wunderbar für nicht weiter zu beschreibene Aussagen passt. Man hat es schon bei access versäumt das klar zu bennen. Dort hätte man access:bicycle=yes machen können. Stattdessen ist der neutrale Tag dort schon mit dem ersten Einsatzgebiet festgenagelt und man müsste für jeden Hutzelbutz ein eigenen Tag erfinden. Und warum hast du dann nicht vor drei Jahren, wo das Tag eingeführt wurde rumgemault? Es hat sich doch nun schon oft genug gezeigt, daß eine Umwidmung eines besetehenden Tags eine ganz schlechte Idee ist. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Und genau das *ist* deine Sicht der Dinge. Wenn du das bislang in deinem persönlichen Tagging so umgesetzt hast, oder diese Erkenntnis aus den Map Features rausgelesen hast, oder auch diese Definition als einzig logische für dich gewonnen hast, heißt das nicht, daß andere nicht zu völlig anderen Erkenntnissen gekommen sind. Es ist in keinem Taggingschema so vorgessehen, nirgends dokumentiert und kommt in der Praxis nur im Promillebereich vor, wobei es sich größtenteils um pure Taggingfehler handeln fandeln dürfte. Damit kann man mit Recht behaupten das ein access Standalone einfach nicht ist. Nochmal, das ist nicht meine Sicht sondern der einzig logische Schluss den die Praxis aufzeigt. Wenn einer Standalone wirklich begründet nutzt, solle er es bitte dokumentieren oder sich melden. Solange das aber bis dato nichtmal ein einziger Mapper tut, gibts schlich keine andere Erkenntnis. Die existiert einzig nur in deiner Sicht, um aus eine Mikrobe einen Dinosaurier zu machen. Weil nur die mit barrier als Hauptbeschreibung valid sind. - wenn ich sowas lese muß ich lachen. So etwas wie valid gibt es bei OSM nicht. Valide ist alles was einen Konsens findet, auch entsprechend breit genutzt wird und einheitlich ausgewertet werden kann. Nach deiner Definition müsste man OSB, Keeright und Co. abschaffen. Es gibt ja kein Valid. Da muss ich wiederum lachen. Denn mit deiner Chaoseinstellung wird OSM nie nutzbar sein. Ohne eine gewisse Grundhafte Einigung ist ein brauchbares Tagging einfach unmöglich. Wenn einer einen Node mit bicycle=no hinsetzt, ist das genauso valid wie wenn er sowas wie barrier=street_sign dazusetzt. Ist dir eigentlich bewußt, daß es das barrier Tag solange noch garnicht gibt? Ein bicycle=no alleine ist genauso valid wie ein footway=yes alleine auf einem Knoten. Kannst du von mir aus taggen bis du schwarz wirst, findet in der Praxis trotzdem nicht statt. Und solange das nicht dokumentiert ist, wirst du damit rechnen müssen das es fliegt oder einer einen Hauptag dazu setzt. Ja barrier gibts noch nicht lange. Highway war auch nicht der erste. Und ja, so alte Dinger existieren noch in abgelegenen Ecken. Ändert nichts daran das es sich geändert hat und keiner mehr etwas anderes verwendet. Ich bestreite nicht, daß es besser ist sowas an den Weg zu setzen. Aber was macht man wenn die Infos nicht vorhanden sind wie weit denn diese Beschränkung geht. Wenn ich unzureichende Informationen habe kann ich es nicht taggen oder muss mir diese Infromationen beschaffen. Wir bilden die Realität ab und orakeln uns diese nicht. Oder ich tagge es so halb vermerkte aber das es so nicht vollständig ist. Dafür wurde note erfunden. Wobei ich ersteres bevorzuge. Daten erst in die DB wenn alles geklärt ist. Im Zweifel gucke ich nochmal nach. 30er Zonen tagge ich z.B. erst dann, wenn ich alle Zufahrten abgefahren habe und mir sicher sein kann, dass wirklich alle diese Straßen in der Zone liegen. Inzwischen könnte man dafür sowas wie barrier=street_sign setzen, aber wie gesagt, so lange gibt es barrier noch nicht. Für was brauchst du ein barrier=street_sign? Ein Verbot gilt immer für den Weg hinter dem Schild, bis es aufgehoben ist. Also taggt man logischerweise den Wegabschnitt den es betrifft. Ein Sign kannst du nicht gebrauchen. Das gilt für den Punkt, man kann daraus aber nichtmal ersehen in welche Richtung des Weges das gilt und vor allem wo das ganze dann aufgehoben ist. Hindernisse gelten immer nur für einen Punkt und haben meist kein Schild, macht da auch keinen Sinn. Jetzt alle bisherigen access=xy Nodes damit in ihrer Bedeutung wegzuschmeißen weil man nicht einsehen mag das bisher so getaggt wurde - ist schon kontraproduktiv. Das ist einfach nur der Lauf der Dinge. Ein standalone access ist nirgends dokumentiert oder begründet, wenn nichtmal ein note dranhängt, muss man von einem Fehler ausgehen, der dann von jemanden der darauf stößt auch korrigiert wird. Logische Konsequenz. Wenn ich sowas absichtlich mache dann muss ich das auch irgendwie mitteilen. Wir können doch nicht sämtliche Dinge in der DB lassen, die nach Fehler brüllen, aber vielleicht eventuell begründet so sind wie sie sind. Wenn das überhand nimmt, wer soll das fixen und vor allem wie will man solch chaotische Daten auswerten? Mit dem Ansatz bewegen wir uns in eine häßliche Sackgasse. Diese Aussage ist halt aus meiner Sicht schlicht und ergreifend falsch. Deine Sicht, ich orentiere mich immer an der Praxis und sieht das bis dato nicht vor. Und warum hast du dann nicht vor drei Jahren, wo das Tag eingeführt wurde rumgemault? Weil das anderthalb Jahre vor meiner Zeit war... Es hat sich doch nun schon oft genug gezeigt, daß eine Umwidmung eines besetehenden Tags eine ganz schlechte Idee ist. Beispiele wie Class/Highway zeigen auch das Gegenteil. Manchmal kommt man um eine Reform sowieso nicht herum. Siehe maxspeed. Als das erfunden wurde hatte keiner daran gedacht, das es da
Re: [Talk-de] guidepost
Am 26.12.2009 15:18, schrieb Mirko Küster: Valide ist alles was einen Konsens findet, auch entsprechend breit genutzt wird und einheitlich ausgewertet werden kann. Dann hast du wohl das falsche Wort verwendet. Valide heißt gültig/richtig, was du vielleicht meinst ist üblich. Denn mit deiner Chaoseinstellung wird OSM nie nutzbar sein. Ohne eine gewisse Grundhafte Einigung ist ein brauchbares Tagging einfach unmöglich. Das hat mit Chaoseinstellung überhaupt nichts zu tun. Das hat was damit zu tun, das vieles von den Problemen wie z.B. die Endlosdiskussionen bei Radwegen genau aus dieser Haltung ich habe recht und du hast Unrecht herkommt. Wenn wir Probleme sehen, sollten wir versuchen diese zu lösen. Das kann aber nicht darin bestehen zu sagen: du siehst das falsch, und du mußt dich anpassen, sondern: ok, da ist ein Problem, was können wir machen um es möglichst schmerzfrei für alle zu lösen. Ein bicycle=no alleine ist genauso valid wie ein footway=yes alleine auf einem Knoten. Kannst du von mir aus taggen bis du schwarz wirst, findet in der Praxis trotzdem nicht statt. Und solange das nicht dokumentiert ist, wirst du damit rechnen müssen das es fliegt oder einer einen Hauptag dazu setzt. In den Map Features ist dokumentiert, das bicycle=no bedeutet, daß man da nicht mit dem Fahrrad durchdarf. Es ist dort *nicht* dokumentiert, daß dieses Tag nur in Verbindung mit xy eingesetzt werden muß. Wenn ich unzureichende Informationen habe kann ich es nicht taggen oder muss mir diese Infromationen beschaffen. Wir bilden die Realität ab und orakeln uns diese nicht. Wenn ich ein Schild tagge, hat das mit Orakeln irgendwie nichts zu tun. Für was brauchst du ein barrier=street_sign? Ein Verbot gilt immer für den Weg hinter dem Schild, bis es aufgehoben ist. Ist dir bis heute nicht aufgefallen, daß das durchaus in der Realität auch mal anders aussieht und das Ende-Schild schlicht auch mal vergessen wird? oder begründet, wenn nichtmal ein note dranhängt, muss man von einem Fehler ausgehen, der dann von jemanden der darauf stößt auch korrigiert wird. Logische Konsequenz. Wenn ich sowas absichtlich mache dann muss ich das auch irgendwie mitteilen. Wir können doch nicht sämtliche Dinge in der DB lassen, die nach Fehler brüllen, aber vielleicht eventuell begründet so sind wie sie sind. Wenn das überhand nimmt, wer soll das fixen und vor allem wie will man solch chaotische Daten auswerten? Mit dem Ansatz bewegen wir uns in eine häßliche Sackgasse. Wenn Mapper A ein Schild einträgt und Mapper B danach mehr Infos hat und die Infos vom Node nimmt und an den passenden Wegabschnitt hängt habe ich damit überhaupt kein Problem. Wenn du jetzt aber kommst und sagst, A hat was falsch gemacht weil er es nicht gleich richtig gemacht hat - damit habe ich ein Problem. Es hat sich doch nun schon oft genug gezeigt, daß eine Umwidmung eines besetehenden Tags eine ganz schlechte Idee ist. Beispiele wie Class/Highway zeigen auch das Gegenteil. Manchmal kommt man um eine Reform sowieso nicht herum. Siehe maxspeed. Als das erfunden wurde hatte keiner daran gedacht, das es da z.B. Abhängigkeiten gibt. Zum Beispiel eine Straße wo 80 gilt und bei Nässe 60. Zugangsbeschränkungen beim Gesamtgewicht, Zeiten... etc. Alles Dinge die man zu Anfang nicht vorgesehen hat, welche man aber in der Praxis benötigt. Desshalb müssen Tags auch mal eine Evolution durchlaufen, wenn es nicht geht auch mal verworfen werden. Wenn wir nicht im Stillstand enden möchten, kommt man um die eine oder andere Änderung nicht herum. Es gibt da zwei unterschiedliche Vorgehensweisen: a) Ersetzung: class weg, highway hin - klappt meist ohne größere Probleme, ist halt Arbeit und dauert ein bisschen b) Umwidmung: bisherige Definition umdefinieren, erweitern, einschränken, Defaults ändern, ... - gibt meist einen ziemlichen und langanhaltenden Ärger Ich habe überhaupt nichts dagegen, wenn wir das Tagging ändern wenn etwas nicht paßt. Aber es so zu ändern das man schon gleich wieder wissentlich in den nächsten Ärger reinläuft - da hab ich was gegen. Daher halte ich es für ungeschickt, ein Tag mit einer spezifischen und etablierten Bedeutung wie bicycle=yes/no auf einmal für etwas anderes wiederzuverwenden. Das fällt nämlich klar unter Kategorie b). Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster schrieb: Guidepost ist nicht Routingrelevant. Da wird ein Problem gesehen wo eigentlich keines ist. Ich schrieb ja bereits, dass es zur Zeit in der Praxis damit wohl kein Problem gibt. Ich halte es nur für sehr schlechtes Design wenn hier für's Routing wichtige Tags missbraucht werden um Eigenschaften von Wegweisern zu bezeichnen. Sollte das Proposal in dieser Form zur Abstimmung kommen, ist eine Nein-Stimme bereits sicher ;-) Frohe Weihnachten weiterhin, Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Chris-Hein Lunkhusen chris66...@gmx.de writes: Ich schrieb ja bereits, dass es zur Zeit in der Praxis damit wohl kein Problem gibt. Ich halte es nur für sehr schlechtes Design wenn hier für's Routing wichtige Tags missbraucht werden um Eigenschaften von Wegweisern zu bezeichnen. Du hast eine eigenartige sicht der dinge. Ein weg (path), der fürs radfahren geeignet oder gedacht ist, bekommt ein bicycle=yes und ein wegweiser, der fürs radfahren gedacht ist, bekommt auch ein bicycle=yes. Ich sehe da überhaupt kein problem und keinerlei verwechslungsgefahr. Das eine ist ein highway und das andere tourism/amenity. Sollte das Proposal in dieser Form zur Abstimmung kommen, ist eine Nein-Stimme bereits sicher ;-) Wir stimmen hier sowieso mit den füßen ab. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 25.12.2009 22:18, schrieb Karl Eichwalder: Chris-Hein Lunkhusenchris66...@gmx.de writes: Ich schrieb ja bereits, dass es zur Zeit in der Praxis damit wohl kein Problem gibt. Ich halte es nur für sehr schlechtes Design wenn hier für's Routing wichtige Tags missbraucht werden um Eigenschaften von Wegweisern zu bezeichnen. Du hast eine eigenartige sicht der dinge. Ein weg (path), der fürs radfahren geeignet oder gedacht ist, bekommt ein bicycle=yes und ein wegweiser, der fürs radfahren gedacht ist, bekommt auch ein bicycle=yes. Ich sehe da überhaupt kein problem und keinerlei verwechslungsgefahr. Das eine ist ein highway und das andere tourism/amenity. Du siehst keinerlei Verwechselungsgefahr, wenn man ein bestehendes Tag mit einer definierten Bedeutung für eine andere Bedeutung wiederverwendet?!? Ein Tag, der je nach Kontext eine andere Bedeutung hat ist eigentlich immer eine schlechte Idee und führt regelmäßig zu Verwirrungen. Wenn jemand einen Node auf den Weg setzt, dem einen bicycle=no verpaßt (und damit eigentlich das Schild meint) hat er - nach meinem Verständnis - damit effektiv den Weg für Fahrräder gesperrt. Ich halte die Gefahr der Verwechselung daher für sehr hoch ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Du hast eine eigenartige sicht der dinge. Ein weg (path), der fürs radfahren geeignet oder gedacht ist, bekommt ein bicycle=yes und ein wegweiser, der fürs radfahren gedacht ist, bekommt auch ein bicycle=yes. Eben. Der Tag sagt nur komplett neutral Fahrrad ja/nein und kann sehr wohl universell für alles mögliche genutzt werden. Wenn man es so eng sieht dann hat man das eher schon bei den access Regeln selbst versaut. Dort hätte man präzisieren müssen, beispielsweise access:bicycle=yes. So wurden die eigentlich neutralen Werte auf die Zugangsbeschränkungen festgenagelt. Unschön, aber soweit hat man damals wohl noch nicht gedacht. So hat man die umgekehrte Variante. Der neutrale Wert ist verbrannt und für alles andere, wo der neutrale Wert gepasst hätte, hätte man im Überschneidungsfall einen extra Tag kreieren müssen. Für Guideposts guidepost:bicycle=yes, meinetwegen als Zusatzangabe zwecks Bevörderung für Buslinien bus:bicycle=yes. Zum Glück gibts den Überschneidungsfall noch nicht. Und Guidepost spielt dabei garkeine Rolle. Wir stimmen hier sowieso mit den füßen ab. Auch richtig. Proposals sehe ich nur als eine art Vorabstimmung im winzig kleinen unrepräsentativen Kreis. Die eigentliche Abstimmung ist die Praxis auf der Datenbank selbst. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 25. Dezember 2009 23:10 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Am 25.12.2009 22:18, schrieb Karl Eichwalder: Chris-Hein Lunkhusenchris66...@gmx.de writes: Ich schrieb ja bereits, dass es zur Zeit in der Praxis damit wohl kein Problem gibt. Ich halte es nur für sehr schlechtes Design wenn hier für's Routing wichtige Tags missbraucht werden um Eigenschaften von Wegweisern zu bezeichnen. Du hast eine eigenartige sicht der dinge. Ein weg (path), der fürs radfahren geeignet oder gedacht ist, bekommt ein bicycle=yes und ein wegweiser, der fürs radfahren gedacht ist, bekommt auch ein bicycle=yes. Ich sehe da überhaupt kein problem und keinerlei verwechslungsgefahr. Das eine ist ein highway und das andere tourism/amenity. Du siehst keinerlei Verwechselungsgefahr, wenn man ein bestehendes Tag mit einer definierten Bedeutung für eine andere Bedeutung wiederverwendet?!? Ein Tag, der je nach Kontext eine andere Bedeutung hat ist eigentlich immer eine schlechte Idee und führt regelmäßig zu Verwirrungen. Wenn jemand einen Node auf den Weg setzt, dem einen bicycle=no verpaßt (und damit eigentlich das Schild meint) hat er - nach meinem Verständnis - damit effektiv den Weg für Fahrräder gesperrt. Ich halte die Gefahr der Verwechselung daher für sehr hoch ... Ich schlage vor, daß Wegweiser, die auch den Weg zu gebäuden Weisen, mit building=yes getaggt werden, da das tag etabliert ist und eine Verwechselungsgefahr niemals nicht bestehen kann. ;-) Meine Güte, es ist schon schwierig genug, den Leuten begreiflich zu machen, daß bicycle=yes die Erlaubnis ausdrückt, nicht die Eignung. Warum wird das ganze Theater nun auf Wegweiser ausgedehnt? Wieso nicht einfach guidepost:bicycle=yes, anstatt etwas anderes zu mißbrauchen? Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Wenn jemand einen Node auf den Weg setzt, dem einen bicycle=no verpaßt (und damit eigentlich das Schild meint) hat er - nach meinem Verständnis - damit effektiv den Weg für Fahrräder gesperrt. Ohne Haupttag ist es Datenmüll der garnicht ausgewertet werden dürfte. Mit Guidepost etc. als Haupttag müsste das ganze bei der Verarbeitung rausfliegen, da es kein Routingrelevantes Objekt ist. Beides dürfte schon beim Datenimport fürs Routing Grid links liegen bleiben. Auch wenn es überall klemmt, für so schlau halte ich die Router und ihre Maintainer schon. Im übrigen ist das schlicht ein Tagginfehler, den wir schon dutzendfach in der DB haben. maxspeed, livingstreet... als Node neben statt auf dem Weg. Mit dem Weg vernknüpfte Dinge, weil es sich ja angeblich so schön verschieben lässt (Selektieren meherer Objekte kennt man nicht...), in der Praxis aber mehr nervt. Fehler passieren. Da muss man eben mal im Wiki dazu schreiben das der Guidepost neben statt auf den Weg gehört, Probölem zum Teil gelöst. Einen gewissen Bodensatz an Fehlern wird man ohnehin immer haben. Kommt Zeit kommen auch Tools die sowas aufspüren und fixen. Bis dahin gibts die entsprechenden Bugseiten. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 25.12.2009 23:50, schrieb Mirko Küster: Wenn jemand einen Node auf den Weg setzt, dem einen bicycle=no verpaßt (und damit eigentlich das Schild meint) hat er - nach meinem Verständnis - damit effektiv den Weg für Fahrräder gesperrt. Ohne Haupttag ist es Datenmüll der garnicht ausgewertet werden dürfte. Das ist *deine* Sicht der Dinge. Versuch das bitte auch so (und nicht als das ist so) zu schreiben. Mal davon abgesehen, daß bicycle auf Nodes bereits ~35000 mal existiert. http://osmdoc.com/en/tag/bicycle/#values Keine Ahnung, wie viele davon z.B. mit barrier=xy und wie viele davon standalone vorliegen. Mit Guidepost etc. als Haupttag müsste das ganze bei der Verarbeitung rausfliegen, da es kein Routingrelevantes Objekt ist. bicycle=no ist (bislang) immer eine routingrelevante Anweisung. Ob das für Nodes relevant ist oder nicht würde ich bestenfalls als ungeklärt deklarieren. Meine Meinung dazu hatte ich ja bereits geäußert. Beides dürfte schon beim Datenimport fürs Routing Grid links liegen bleiben. Auch wenn es überall klemmt, für so schlau halte ich die Router und ihre Maintainer schon. Im übrigen ist das schlicht ein Tagginfehler, den wir schon dutzendfach in der DB haben. maxspeed, livingstreet... als Node neben statt auf dem Weg. Mit dem Weg vernknüpfte Dinge, weil es sich ja angeblich so schön verschieben lässt (Selektieren meherer Objekte kennt man nicht...), Kannst du bitte mal deine Attitüde ablegen, daß hier mehr oder weniger nur Idioten rumlaufen und du der einzige echte Mapper auf der Welt bist? So kommt es zumindest bei mir rüber. in der Praxis aber mehr nervt. Fehler passieren. Da muss man eben mal im Wiki dazu schreiben das der Guidepost neben statt auf den Weg gehört, Probölem zum Teil gelöst. Einen gewissen Bodensatz an Fehlern wird man ohnehin immer haben. Kommt Zeit kommen auch Tools die sowas aufspüren und fixen. Bis dahin gibts die entsprechenden Bugseiten. Mit keinem Tool der Welt kannst du dann sowas aus der ferne fixen, weil du nicht mehr weißt was der Mapper mit access=no gemeint hat (bislang ist das für mich noch recht klar). Hier *bewußt* zu sagen: ist ja egal wenn man jetzt schon die Probleme klar benennen kann finde ich ziemlich dürftig. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Mirko Küster webmas...@ts-eastrail.de writes: Wenn jemand einen Node auf den Weg setzt, dem einen bicycle=no verpaßt (und damit eigentlich das Schild meint) hat er - nach meinem Verständnis - damit effektiv den Weg für Fahrräder gesperrt. Ohne Haupttag ist es Datenmüll der garnicht ausgewertet werden dürfte. Mit Guidepost etc. als Haupttag müsste das ganze bei der Verarbeitung rausfliegen, da es kein Routingrelevantes Objekt ist. Eben. Nur bei barrier oder highway als haupttag ist bicycle=(no,yes) routing-relevant. Im übrigen ist das schlicht ein Tagginfehler, den wir schon dutzendfach in der DB haben. maxspeed, livingstreet... als Node neben statt auf dem Weg. Geanu so ist es. Mit dem Weg vernknüpfte Dinge, weil es sich ja angeblich so schön verschieben lässt (Selektieren meherer Objekte kennt man nicht...), in der Praxis aber mehr nervt. Ja, es ist oftmals oder eigentlich immer sehr ärgerlich, wenn alle möglichen dinge (landuse, bus_stop, postbox, ...) auf die wege gepackt werden :-( So etwas ist einfach für diese residence-rumpfuscher, aber schwer für die zu handhaben, die die daten im detail verbessern wollen. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Ulf Lamping ulf.lamp...@googlemail.com writes: Das ist *deine* Sicht der Dinge. Versuch das bitte auch so (und nicht als das ist so) zu schreiben. Mal davon abgesehen, daß bicycle auf Nodes bereits ~35000 mal existiert. Das sagt gar nichts. http://osmdoc.com/en/tag/bicycle/#values Keine Ahnung, wie viele davon z.B. mit barrier=xy und wie viele davon standalone vorliegen. [...] bicycle=no ist (bislang) immer eine routingrelevante Anweisung. Ob das für Nodes relevant ist oder nicht würde ich bestenfalls als ungeklärt deklarieren. Meine Meinung dazu hatte ich ja bereits geäußert. Ja, und? Wenn die routing-software nicht die haupttags gebührend berücksichtigt, ist sie sowieso nicht hinreichend robust. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Ticket wurde geschlossen mit dem Hinweis dass das Tag konform mit dem Proposal ist. http://wiki.openstreetmap.org/wiki/Proposed_features/information Access-keys to describe a guidepost or map closer Na toll, wer hat sich das nur ausgedacht. Noch ein Beispiel: Angenommen auf einer Schranke wo Radfahrer nicht durchkommen ist ein Wegweiser für Radler montiert: barrier=gate bicycle=no tourism=information information=guidepost bicycle=yes (Hoppla Kollision) Jaja, ich weiss, dass man das besser mit zwei Nodes taggen sollte, war ja nur ein Beispiel. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Jaja, ich weiss, dass man das besser mit zwei Nodes taggen sollte, war ja nur ein Beispiel. ;-) Deine Schranke muss sowieso auf die Straße und Guideposts stehen logischerweise immer daneben, wesshalb das nie kollidieren kann. Die Dinger stehen manchmal so beschissen und sind teilweise verwittert oder kaputt, da ist der Node auf dem richtigen Fleck Gold wert. Vorsorglich habe ich auch immer alle Ziele mit destination:nummerierung=ziel erfasst und hochgeladen. Die entsprechende Auswertung kann kommen. Es kollidiert auch nicht in der Datenauswertung. Oder in welchem Fall macht es Sinn, einen Wegweiser auf Zugangsrechte abzufragen? Macht doch ehrlich gesagt keiner. Das macht es auch dann nicht, wenn der Wegweiser fälschlicherweise auf einen Straßennode gelegt wurde. Guidepost ist nicht Routingrelevant. Da wird ein Problem gesehen wo eigentlich keines ist. Das würde erst eines werden wenn es ein Objekt betrifft was auch Routingrelevant ist und damit wirklich auch ein access gemeint sein könnte. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 24.12.2009 13:08, schrieb Mirko Küster: Deine Schranke muss sowieso auf die Straße und Guideposts stehen logischerweise immer daneben, wesshalb das nie kollidieren kann. Die Dinger stehen manchmal so beschissen und sind teilweise verwittert oder kaputt, da ist der Node auf dem richtigen Fleck Gold wert. Vorsorglich habe ich auch immer alle Ziele mit destination:nummerierung=ziel erfasst und hochgeladen. Die entsprechende Auswertung kann kommen. Dann sei mir mal die lästerliche Frage gestattet, wozu es die Dinger überhaupt noch braucht, wenn doch bald jeder einen entsprechend aufbereiteten OSM-Auszug in seiner Tasche mit sich trägt? O.k. vieleicht zu inventarisierungszwecken. Aber um zu sehen, wo welcher Fernradweg langführt oder wo es zum Aussichtsturm geht, dafür braucht man mit einer OSM-Karte doch hoffentlich keine physikalischen Wegweiser mehr, zumal wenn diese -wie oben beschrieben- nur mithilfe einer OSM-Karte überhaupt lokalisierbar sind... -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 13:20 schrieb Wolfgang Wienke wo_wie...@gmx.net: Bitte die guideposts aber nicht vermischen mit dem Rad-Knotenpunktsystem in den Niederlande, Belgien und den deutschen Kreisen Aachen, Düren, Heinsberg in NRW, siehe http://wiki.openstreetmap.org/wiki/Radverkehrsnetz_NRW#Knotenpunktsystem_in_den_Kreises_Aachen_und_Heinsberg Das sind doch auch nur Fahrrad-Routen-Wegweiser, welche aber zusätzlich eine Nummer haben. Das zeigt auch das Beispiel. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 21. Dezember 2009 23:42 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Hi, ich sehe immer öfters Wegweiser http://wiki.openstreetmap.org/index.php/Proposed_features/Guidepost die mit bicycle=yes getaggt sind. Im Proposal kann ich da nichts zu finden, wieso ist das in JOSM als Option eingebaut (Dargestellte Routen für Radfahrer) ? Hier kannst du die Sachen finden: http://wiki.openstreetmap.org/wiki/Proposed_features/information Bei Tags die eigentlich für access-Rights etabliert sind, halte ich diese Umdeutung für suboptimal. Gerade weil sie schon etabliert sind und niemand auf die Idee kommt, dass ein Wegweiser nur von Fahrradfahreren angeschaut werden darf. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On Tue, Dec 22, 2009 at 07:34:15AM +0100, Andre Joost wrote: Chris-Hein Lunkhusen schrieb: Hi, ich sehe immer öfters Wegweiser http://wiki.openstreetmap.org/index.php/Proposed_features/Guidepost die mit bicycle=yes getaggt sind. könnten glatt von mir sein ;-) Im Proposal kann ich da nichts zu finden, wieso ist das in JOSM als Option eingebaut (Dargestellte Routen für Radfahrer) ? Ich trage die Wegweiser des Radverkehrssystems NRW in osm ein, weil die guideposts in osmarender Stufe 17 und lonvias Hiking Map in Zoomstufe 14 bis 16 dargestellt werden. In der Cyclemap werden sie noch nicht dargestellt, aber was nicht ist kann ja noch werden... Auf der Wanderkarte ist das aber ein Bug und kein Feature. ;) Die Art, wie bicycle=yes die Semantik des guidepost verändert, ist für die Auswertung halt ein wenig ungünstig, weil hier ein zusätzliches Tag, die Bedeutung nicht einfach einschränkt, sondern verändert: ohne *=yes-Tags ist es Wanderwegweiser (ursprüngliche Bedeutung), mit bicycle=yes ist es eben keiner mehr, sondern es ist ein Radwegweiser. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
André Riedel schrieb: Am 21. Dezember 2009 23:42 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Hi, ich sehe immer öfters Wegweiser http://wiki.openstreetmap.org/index.php/Proposed_features/Guidepost die mit bicycle=yes getaggt sind. Im Proposal kann ich da nichts zu finden, wieso ist das in JOSM als Option eingebaut (Dargestellte Routen für Radfahrer) ? Hier kannst du die Sachen finden: http://wiki.openstreetmap.org/wiki/Proposed_features/information Auf der Diskussionsseite http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Guidepost wurde type=bicycle und route_type=bicycle vorgeschlagen, aber nicht auf die Seite übernommen. Dann ist das Zusatztag wohl ein Alleingang von josm? Bei Tags die eigentlich für access-Rights etabliert sind, halte ich diese Umdeutung für suboptimal. Gerade weil sie schon etabliert sind und niemand auf die Idee kommt, dass ein Wegweiser nur von Fahrradfahreren angeschaut werden darf. Andersrum gefragt: tut das bicycle=yes denn irgendwo weh? Oder gibt es eine elegantere Art, den Fahrradbezug für den Wegweiser darzustellen? Solange josm das bicycle-tag so anbietet, werde ich das auch der Einfachheit halber nutzen. Die Informationen auf den Wegweisern habe ich mir bislang gespart, sind aber alle offline vorhanden. Die zehnstellige Pfostennummer lasse ich aussen vor, weil sie in der Darstellung der Cyclemap ziemlich unübersichtlich lang ist. Hier hatte sich der Netzwolf mal was zum Wegweiser ausgedacht: http://www.openstreetmap.org/browse/node/298632375 Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann schrieb: On Tue, Dec 22, 2009 at 07:34:15AM +0100, Andre Joost wrote: Ich trage die Wegweiser des Radverkehrssystems NRW in osm ein, weil die guideposts in osmarender Stufe 17 und lonvias Hiking Map in Zoomstufe 14 bis 16 dargestellt werden. In der Cyclemap werden sie noch nicht dargestellt, aber was nicht ist kann ja noch werden... Auf der Wanderkarte ist das aber ein Bug und kein Feature. ;) Für mich ist es ein Feature. Ich pappe nämlich die Tiles der Cyclemap mit deinen transparenten Overlays zu einer Rad- und Wanderkarte für meinen PDA zusammen. Da ist es dann egal, dass die *eigentlich* zur anderen Fraktion gehören. Also bitte drinlassen ;-) Könntest du auf deiner Seite die CycleMap ohne großen Aufwand als Alternative zu mapnik anwählbar machen? Die Art, wie bicycle=yes die Semantik des guidepost verändert, ist für die Auswertung halt ein wenig ungünstig, weil hier ein zusätzliches Tag, die Bedeutung nicht einfach einschränkt, sondern verändert: ohne *=yes-Tags ist es Wanderwegweiser (ursprüngliche Bedeutung), mit bicycle=yes ist es eben keiner mehr, sondern es ist ein Radwegweiser. Und was ist mit Mountenbikern, die sich nicht zwischen Rad- und Wanderrouten entscheiden können? Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 09:47 schrieb Sarah Hoffmann lon...@denofr.de: On Tue, Dec 22, 2009 at 07:34:15AM +0100, Andre Joost wrote: Ich trage die Wegweiser des Radverkehrssystems NRW in osm ein, weil die guideposts in osmarender Stufe 17 und lonvias Hiking Map in Zoomstufe 14 bis 16 dargestellt werden. In der Cyclemap werden sie noch nicht dargestellt, aber was nicht ist kann ja noch werden... Auf der Wanderkarte ist das aber ein Bug und kein Feature. ;) Die Art, wie bicycle=yes die Semantik des guidepost verändert, ist für die Auswertung halt ein wenig ungünstig, weil hier ein zusätzliches Tag, die Bedeutung nicht einfach einschränkt, sondern verändert: ohne *=yes-Tags ist es Wanderwegweiser (ursprüngliche Bedeutung), mit bicycle=yes ist es eben keiner mehr, sondern es ist ein Radwegweiser. information=guidepost heißt in erster Hinsicht, dass es ein Wegweiser ist und dich unterstützen soll, den Weg zu deinem Ziel zu finden oder auf der Route zu bleiben. Orientieren kannst du dich an allen, als Wanderer wirst du dich aber vornehmlich an den hiking=yes Wegweisern orientieren, als Fahrradfahrer vornehmlich an bicycle=yes und als Mountainbiker an allen beiden. Wenn ein Wegweiser beides anzeigt um so besser. Das gleiche gilt auch bei Karten. Alle Karten dienen dir zur Orientierung, aber als Wanderer wirst du die Karten bevorzugen welche mit hiking=yes eingetragen sind. Gerade bei den Karten gab es am Anfang des proposals für jede Fortbewegunsart verschiedene tags wie hikingmap und bicyclemap. Dies würde aber irgendwann in viele verschiedenen Kartennamen enden und sehr unübersichtlich werden. Du würdest damit auch die Möglichkeit der Orientierung an einer für den Auswerter unbekannten Karte verlieren. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Andre Joost schrieb: Andersrum gefragt: tut das bicycle=yes denn irgendwo weh? Oder gibt es eine elegantere Art, den Fahrradbezug für den Wegweiser darzustellen? Solange josm das bicycle-tag so anbietet, werde ich das auch der Einfachheit halber nutzen. Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. Mein Vorschlag wäre ein Tagging ähnlich wie bei den Recyclingcontainern: information:bicycle=yes information:hiking=no information:beach=yes http://www.bilder-space.de/show.php?file=22.12D54sGCaW48Z7usI.jpg Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Chris-Hein Lunkhusen schrieb: Andre Joost schrieb: Andersrum gefragt: tut das bicycle=yes denn irgendwo weh? Oder gibt es eine elegantere Art, den Fahrradbezug für den Wegweiser darzustellen? Solange josm das bicycle-tag so anbietet, werde ich das auch der Einfachheit halber nutzen. Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. Diese no-Option ist bei josm derzeit nicht vorgesehen, also keine Gefahr. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. Das mache ich allerdings nicht. Ich setzte die Tags an den Abzweigknoten, damit der Wegweiser direkt mit geladen wird, wenn ich eine der betreffenden Routenrelationen (oder die Relation des zuständigen Landkreises) komplett lade. Genauso wie Ampeln zumeist an die Kreuzungsknoten getackert werden. Falls es irgendwann mal ein neues Guidepost-feature geben sollte, kann ich so über die Netzwerk-Relation des Radverkehrsnetzes ziemlich schnell sämtliche meiner Guideposts aus der Datenbank holen. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 10:30 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Andre Joost schrieb: Andersrum gefragt: tut das bicycle=yes denn irgendwo weh? Oder gibt es eine elegantere Art, den Fahrradbezug für den Wegweiser darzustellen? Solange josm das bicycle-tag so anbietet, werde ich das auch der Einfachheit halber nutzen. Naja, wenn jemand auf die Idee kommt Wegweiser ohne Radlerinfo mit bicycle=no zu taggen könnte es bei den Garmin Maps zu Überschneidung mit der --link-pois-to-roads Option kommen. In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. Mein Vorschlag wäre ein Tagging ähnlich wie bei den Recyclingcontainern: information:bicycle=yes information:hiking=no information:beach=yes Oder man folgt einem anderen Schema und verwendet information=guidepost guidepost=bicycle bzw. guidepost=hiking Beide Schemen haben im Vergleich zu key=yes den Vorteil, das sie einem Kontext immer präzise zugeordnet werden könne. Das gleich Problem ist meiner Meinung nach latent auch bei type=value vorhanden. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Falk Zscheile schrieb: Mein Vorschlag wäre ein Tagging ähnlich wie bei den Recyclingcontainern: information:bicycle=yes information:hiking=no information:beach=yes Oder man folgt einem anderen Schema und verwendet information=guidepost guidepost=bicycle bzw. guidepost=hiking Die Diskussion mit der Semikolonsyntax (guidepost=hiking;bicycle) hatten wir ja schon. Ist halt Geschmacksache. ;-) Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 11:16 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Falk Zscheile schrieb: Oder man folgt einem anderen Schema und verwendet information=guidepost guidepost=bicycle bzw. guidepost=hiking Die Diskussion mit der Semikolonsyntax (guidepost=hiking;bicycle) hatten wir ja schon. Ist halt Geschmacksache. ;-) Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Gibt es bei JOSM die Möglichkeit seine Lieblingsvariante für die Vorlage lokal auf dem Rechner abzuspeichern. Anders formuliert: Es wäre ein schönes feature wenn man den Zusatzkey selbst lokal für die Eingabemaske definieren könnte. So kann dann jeder mit seiner Version glücklich werden und die Arbeitserleichterung der Eingabemaske bleibt in vollem Umfang erhalten. Darüber, dass information=guidepost einer näheren Bestimmung bedarf, scheint ja immerhin Einigkeit zu bestehen. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 11:16 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Falk Zscheile schrieb: Mein Vorschlag wäre ein Tagging ähnlich wie bei den Recyclingcontainern: information:bicycle=yes information:hiking=no information:beach=yes Oder man folgt einem anderen Schema und verwendet information=guidepost guidepost=bicycle bzw. guidepost=hiking Die Diskussion mit der Semikolonsyntax (guidepost=hiking;bicycle) hatten wir ja schon. Ist halt Geschmacksache. ;-) Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Im Moment geht es aber dakor mit dem Proposal, also sollten wir zu nächst dies ändern oder diskutieren. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 10:48 schrieb Andre Joost andre+jo...@nurfuerspam.de: In der Praxis führt es hoffentlich zur Zeit noch zu keinen Routingproblemen, da Wegweiser vorwiegend als separate Nodes getaggt sind. Das mache ich allerdings nicht. Ich setzte die Tags an den Abzweigknoten, damit der Wegweiser direkt mit geladen wird, wenn ich eine der betreffenden Routenrelationen (oder die Relation des zuständigen Landkreises) komplett lade. Genauso wie Ampeln zumeist an die Kreuzungsknoten getackert werden. Falls es irgendwann mal ein neues Guidepost-feature geben sollte, kann ich so über die Netzwerk-Relation des Radverkehrsnetzes ziemlich schnell sämtliche meiner Guideposts aus der Datenbank holen. Dies halte ich für falsch und würde zu den schon genannten Problemen führen, dass ein Router dich bei getaggten bicycle=no immer um die Kreuzung leitet. Du kannst übrigens mit der Xapi oder osmosis alle information=guidepost auslesen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
André Riedel schrieb: Am 22. Dezember 2009 11:16 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Im Moment geht es aber dakor mit dem Proposal, also sollten wir zu nächst dies ändern oder diskutieren. Das bicycle=yes steht aber nun mal nicht in dem proposal. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On Tue, Dec 22, 2009 at 10:24:14AM +0100, André Riedel wrote: Am 22. Dezember 2009 09:47 schrieb Sarah Hoffmann lon...@denofr.de: On Tue, Dec 22, 2009 at 07:34:15AM +0100, Andre Joost wrote: Ich trage die Wegweiser des Radverkehrssystems NRW in osm ein, weil die guideposts in osmarender Stufe 17 und lonvias Hiking Map in Zoomstufe 14 bis 16 dargestellt werden. In der Cyclemap werden sie noch nicht dargestellt, aber was nicht ist kann ja noch werden... Auf der Wanderkarte ist das aber ein Bug und kein Feature. ;) Die Art, wie bicycle=yes die Semantik des guidepost verändert, ist für die Auswertung halt ein wenig ungünstig, weil hier ein zusätzliches Tag, die Bedeutung nicht einfach einschränkt, sondern verändert: ohne *=yes-Tags ist es Wanderwegweiser (ursprüngliche Bedeutung), mit bicycle=yes ist es eben keiner mehr, sondern es ist ein Radwegweiser. information=guidepost heißt in erster Hinsicht, dass es ein Wegweiser ist und dich unterstützen soll, den Weg zu deinem Ziel zu finden oder auf der Route zu bleiben. Orientieren kannst du dich an allen, als Wanderer wirst du dich aber vornehmlich an den hiking=yes Wegweisern orientieren, als Fahrradfahrer vornehmlich an bicycle=yes und als Mountainbiker an allen beiden. Wenn ein Wegweiser beides anzeigt um so besser. Ja, so ist das logisch, aber eben nicht die Praxis. Zumindest in der Schweiz wurden bis zum Auftauchen der Unterklassifizierungen in JOSM praktisch nur Wanderwegweiser eingetragen, eben weil das ursprüngliche Proposal nur auf Wanderwegweiser abziehlte. Deshalb kann man wirklich davon ausgehen, dass Wegweiser ohne genaue Klassifizierung Wanderweg- weiser sind. Ich gehe davon aus, dass das in Deutschland ähnlich ist. Das ist nicht weiter tragisch, muss man aber eben beim Kartenzeichnen beachten, denn da interessiert der Ist-Zustand. Mit der Zeit wird sich das sicherlich so entwickeln, dass die meisten Wegweiser eine Unterklassifizierung haben werden und das Problem hat sich erledigt. Insofern würde ich die Option im JOSM jetzt auch einfach drin lassen. Jetzt noch eine zweite Variante für die Unterklassifizierung einzuführen, würde das Chaos perfekt machen. Gerade bei den Karten gab es am Anfang des proposals für jede Fortbewegunsart verschiedene tags wie hikingmap und bicyclemap. Dies würde aber irgendwann in viele verschiedenen Kartennamen enden und sehr unübersichtlich werden. Du würdest damit auch die Möglichkeit der Orientierung an einer für den Auswerter unbekannten Karte verlieren. Und wo ist da der Unterschied zu beliebig erweiterbaren *=yes-Tags? Auch da muss man mit unbekannten Schlüsselwerten klarkommen. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 12:13 schrieb Sarah Hoffmann lon...@denofr.de: On Tue, Dec 22, 2009 at 10:24:14AM +0100, André Riedel wrote: Das ist nicht weiter tragisch, muss man aber eben beim Kartenzeichnen beachten, denn da interessiert der Ist-Zustand. Mit der Zeit wird sich das sicherlich so entwickeln, dass die meisten Wegweiser eine Unterklassifizierung haben werden und das Problem hat sich erledigt. Insofern würde ich die Option im JOSM jetzt auch einfach drin lassen. Jetzt noch eine zweite Variante für die Unterklassifizierung einzuführen, würde das Chaos perfekt machen. Würde ich auch bevorzugen, aber wenn hier so große Unstimmigkeiten gibt, sollte man das auch im Proposal ändern können und dann den offiziellen Voting-Prozess starten. Gerade bei den Karten gab es am Anfang des proposals für jede Fortbewegunsart verschiedene tags wie hikingmap und bicyclemap. Dies würde aber irgendwann in viele verschiedenen Kartennamen enden und sehr unübersichtlich werden. Du würdest damit auch die Möglichkeit der Orientierung an einer für den Auswerter unbekannten Karte verlieren. Und wo ist da der Unterschied zu beliebig erweiterbaren *=yes-Tags? Auch da muss man mit unbekannten Schlüsselwerten klarkommen. Naja wenn dein Programm information=map kennt, kann er auch anderen Karten anzeigen. Bsp: [1] information=map nordic_walking=yes Für eine Karte mit spezizellen Nordic Walking-Routen. Als Wanderer wird die diese Karte trotzdem zur Orientierung helfen. Wenn die Karte aber mit information=nordic_walking_map eingetragen wäre, würdest du nichts auf der Karte sehen. [1] http://nordic-walking.oederan.de/walkingrouten.htm Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 12:07 schrieb Andre Joost andre+jo...@nurfuerspam.de: André Riedel schrieb: Am 22. Dezember 2009 11:16 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Im Moment geht es aber dakor mit dem Proposal, also sollten wir zu nächst dies ändern oder diskutieren. Das bicycle=yes steht aber nun mal nicht in dem proposal. Gruß, André Joost Dann nimm dir das Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/information zur Hand. Leider ist es wohl vergessen wurden, dies in die Unterseite information=guidepost aufzunehmen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
On Tue, Dec 22, 2009 at 12:07:37PM +0100, Andre Joost wrote: André Riedel schrieb: Am 22. Dezember 2009 11:16 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Im Moment geht es aber dakor mit dem Proposal, also sollten wir zu nächst dies ändern oder diskutieren. Das bicycle=yes steht aber nun mal nicht in dem proposal. Aber es ist schon Realität: planet= select bicycle,count(*) from planet_osm_point where tourism='information' and information='guidepost' group by bicycle; bicycle | count +--- | 13698 designated | 1 no |19 yes| 1511 permissive | 3 (5 rows) Das heisst etwa 10% der Wegweiser sind bereits entsprechend getaggt. Leider kann ich gerade nicht die Zahlen für hiking=* liefern. Ich frage mich nur, was ein 'permissive' Radwegweiser ist. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Sarah Hoffmann schrieb: On Tue, Dec 22, 2009 at 12:07:37PM +0100, Andre Joost wrote: Das bicycle=yes steht aber nun mal nicht in dem proposal. Aber es ist schon Realität: planet= select bicycle,count(*) from planet_osm_point where tourism='information' and information='guidepost' group by bicycle; bicycle | count +--- | 13698 designated | 1 no |19 yes| 1511 permissive | 3 (5 rows) Das heisst etwa 10% der Wegweiser sind bereits entsprechend getaggt. Leider kann ich gerade nicht die Zahlen für hiking=* liefern. Da siehste mal, wie fleissig ich bin ;-) Liegt aber eben nur daran, dass josm das Ankreuzfeld eben genau so auswertet. Die no un dpermissive sind von Hnad gesetzt, oder jemand hat Wege-tags auf die Knoten gestülpt. Sinnlose Landstraßen-ref-tags hab ich schon desöfteren von Knoten entfernt (das waren keine Kilometersteine oder ähnliches). Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Hallo! André Riedel schrieb: Am 21. Dezember 2009 23:42 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Hi, ich sehe immer öfters Wegweiser http://wiki.openstreetmap.org/index.php/Proposed_features/Guidepost die mit bicycle=yes getaggt sind. Im Proposal kann ich da nichts zu finden, wieso ist das in JOSM als Option eingebaut (Dargestellte Routen für Radfahrer) ? Hier kannst du die Sachen finden: http://wiki.openstreetmap.org/wiki/Proposed_features/information Bei Tags die eigentlich für access-Rights etabliert sind, halte ich diese Umdeutung für suboptimal. Gerade weil sie schon etabliert sind und niemand auf die Idee kommt, dass ein Wegweiser nur von Fahrradfahreren angeschaut werden darf. Bitte die guideposts aber nicht vermischen mit dem Rad-Knotenpunktsystem in den Niederlande, Belgien und den deutschen Kreisen Aachen, Düren, Heinsberg in NRW, siehe http://wiki.openstreetmap.org/wiki/Radverkehrsnetz_NRW#Knotenpunktsystem_in_den_Kreises_Aachen_und_Heinsberg -- Mit freundlichen Gruessen wonk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 22. Dezember 2009 11:26 schrieb Falk Zscheile falk.zsche...@googlemail.com: Gibt es bei JOSM die Möglichkeit seine Lieblingsvariante für die Vorlage lokal auf dem Rechner abzuspeichern. ja, gibt es. (Musst mal im Wiki nachsehen, wie genau). Wenn Du den Eindruck hast, Deine Lieblingsvariante wäre für andere Mapper auch sinnvoll, am Besten im Trac ein Ticket erstellen. Gru0 Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Das mit dem bicycle=yes werde ich mal als JOSM-Bug eintracen. Ticket ist drin und die Wegweiser in meiner Umgebung habe ich auf guidepost=bicycle umgetaggt. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Am 21.12.2009 23:42, schrieb Chris-Hein Lunkhusen: ich sehe immer öfters Wegweiser die mit bicycle=yes getaggt sind. Zumal es nicht immer so eindeutig ist, siehe z.B. dieses übersichtliche Exemplar: http://www.addicks.net/gallery/osm/DSCF7393 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] guidepost
Chris-Hein Lunkhusen schrieb: Hi, ich sehe immer öfters Wegweiser http://wiki.openstreetmap.org/index.php/Proposed_features/Guidepost die mit bicycle=yes getaggt sind. könnten glatt von mir sein ;-) Im Proposal kann ich da nichts zu finden, wieso ist das in JOSM als Option eingebaut (Dargestellte Routen für Radfahrer) ? Ich trage die Wegweiser des Radverkehrssystems NRW in osm ein, weil die guideposts in osmarender Stufe 17 und lonvias Hiking Map in Zoomstufe 14 bis 16 dargestellt werden. In der Cyclemap werden sie noch nicht dargestellt, aber was nicht ist kann ja noch werden... Das bicycle=yes oder hiking=yes wird bislang noch nicht ausgewertet. Natürlich dürfen auch Autofahrer und Fußgänger die Wegweiser beachten. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
