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] Die Mailing Liste ist ein Forum
Also ehrlich gesagt Leute, was ich hier beobachte finde ich eher traurig. Zuerst war da ein Crossposting, in dem ein paar technische Fragen gestellt wurden. Worauf die technischen Fragen ignoriert wurden und eine Diskussion über eine Geschmacksfrage ML vs. Forum entbrannt ist. Dann gab es einen Hinweis darauf, daß man sich nicht über entweder/oder streiten müßte, weil es eine technische Lösung gibt, die beides vereint. Darauf wird die Geschmacksfrage eher emotionaler weitergeführt, nicht ohne die eigenen Vorlieben und Vorkenntnisse als Maßstab für Andere zu setzen und ein paar persönliche Spitzen unterzubringen. Das fällt bei mir jetzt nicht unbedingt in die Kategorie effizient sondern eher in den Bereich zwischen sachlich überflüssig und in konstruktiven Gesprächen zu vermeiden. :-( Von daher werde ich jetzt auch nicht verraten, ob ich Mailing Listen oder Foren besser finde. Bin gespannt was für einen Vorwurf mir das einbringt. :-) bye Nop -- View this message in context: http://n3.nabble.com/Die-Mailing-Liste-ist-ein-Forum-tp116560p117790.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
[Talk-de] Vereinsstätte
Hallo zusammen, hat schonmal jemand eine Vereinsstätte getaggt? Habe dazu im Wiki unter DE:Map_Features nichts gefunden. Danke schonmal, Chris.. ___ 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] Vereinsstätte
Hi Chris, Christian Knorr schrieb: hat schonmal jemand eine Vereinsstätte getaggt? Habe dazu im Wiki unter DE:Map_Features nichts gefunden. Ich habe sowas schonmal mit amenity=club_house building=yes name=Vereinsheim Freunde der Steinlaus e.V. getaggt. Gruß, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgrenzung highway=service und residential
Am 12.01.2010 02:02, Stefan Hirschmann: Hi! Aufgrund einer aktuellen Diskussion möchte ich mal fragen, wie folgender Sachverhalt am besten getaggt werden soll: Von einer Gemeindestraße mit eigenem Straßennamen X geht eine Stichstraße weg, welche keinen eigenen Namen hat. Die Häuser an der Stichstraße haben eine Hausnummer in der Form X 4, sind also nach der Hauptstraße benannt. Sieht ca. so aus: |--- (Senkrecht die Hauptstraße und waagrecht die Stichstraße, welche eine Sackgasse ist). Auf der Stichstraße liegen mehrere Häuser. Ist die Stichstraße jetzt als Namenloser Service zu taggen (ev. Karlsruher Schema addr:street), oder doch als residential ohne Namen. Oder sagen wir Wir wollen eine Adressverortung und das kommt in den Name, auch wenn die Straße nicht so heißt? Wenn die Straße Zufahrtscharakter zu den paar (3-5 Häusern) hat würde ich es als service taggen. Ein Kommentar noch zum Karlsruhe-Schema: Die Adressinformation kommt doch an den/die Hausknoten und nicht an den Zufahrtsweg. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wiki-Inhaltsverzeichnis als Abgleichliste
Moin ! für manche Städte gibt es ausführliche Beiträge in Wiki. Sollte etwas dagegen sprechen daraus Listen für die Vollständigkeitsprüfung in OSM abzuleiten ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki-Inhaltsverzeichnis als Abgleichliste
Am 12.01.2010 14:23, Jan Tappenbeck: Moin ! für manche Städte gibt es ausführliche Beiträge in Wiki. Sollte etwas dagegen sprechen daraus Listen für die Vollständigkeitsprüfung in OSM abzuleiten ? Gruß Jan :-) Welches Wiki meinst du? Wikipedia.org oder wiki.openstreetmap.org ? Welche Daten aus den Beiträgen willst du mit den OSM-Daten zur Vollständigkeitsprüfung abgleichen? Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki-Inhaltsverzeichnis als Abgleichliste
Am 12.01.2010 14:39, schrieb Claudius: Am 12.01.2010 14:23, Jan Tappenbeck: Moin ! für manche Städte gibt es ausführliche Beiträge in Wiki. Sollte etwas dagegen sprechen daraus Listen für die Vollständigkeitsprüfung in OSM abzuleiten ? Gruß Jan :-) Welches Wiki meinst du? Wikipedia.org oder wiki.openstreetmap.org ? Welche Daten aus den Beiträgen willst du mit den OSM-Daten zur Vollständigkeitsprüfung abgleichen? Claudius Hi ! Datenquelle sollte Wikipedia.org sein und ich hatte an soetwas wie http://de.wikipedia.org/wiki/Skulpturen_und_Objekte_in_L%C3%BCbeck gedacht - Inhaltsverzeichnis davon... Gruß Jan :-) ___ 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] Abgrenzung highway=service und residential
Claudius schrieb: Ein Kommentar noch zum Karlsruhe-Schema: Die Adressinformation kommt doch an den/die Hausknoten und nicht an den Zufahrtsweg. Ja. Das wäre die saubere Lösung. Die Adressinformation an den Weg zu haften war die Kompromisslösung, bis jemand wirklich vor Ort die genaue Adressverortung macht. Der Weg selber hat keinen Name, als wäre setzen des name Attributes falsch. Aber ganz verwerfen sollte man den Namen der angrenzenden Häuser auch nicht. Lg Stefan Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frage zum ÖPVN-Tag-Schema
Moin ! ich habe gerade Lübecker ÖPNV-Schema vor und ein Problem den verschiedenen Verästellungen. Als Beispiel sei die Linie 7 genannt - http://www.stadtverkehr-luebeck.de/index.php?seid=9824 Wie würdet Ihr FROM und TO definieren. Einige der Busse bis Oberbüssauer Weg und andere von dort in verschiedene Richtung Moorgarten bzw. Klein Wesenberg. Und bekommen die Wegeabschnitte zu den Verästellungen irgendetwas besonderes zugewiesen ??? Gruß Jan .-) ___ 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] Frage zum ÖPVN-Tag-Schema
Hallo! Jan Tappenbeck (OSM) schrieb: Moin ! ich habe gerade Lübecker ÖPNV-Schema vor und ein Problem den verschiedenen Verästellungen. Als Beispiel sei die Linie 7 genannt - http://www.stadtverkehr-luebeck.de/index.php?seid=9824 Wie würdet Ihr FROM und TO definieren. Einige der Busse bis Oberbüssauer Weg und andere von dort in verschiedene Richtung Moorgarten bzw. Klein Wesenberg. Und bekommen die Wegeabschnitte zu den Verästellungen irgendetwas besonderes zugewiesen ??? Ich habe mich grundsätzlich bei FROM und TO immer an die Bezeichnungen des ÖPNV-Unternehmens gehalten. Wenn es Verästellungen gibt, die oft auch noch nur zu bestimmten Zeiten bedient werden, gibt es nach dem erweiterten Schema natürlich die Möglichkeit, für jede Verästellung eine eigene Route zu defnieren (jeweils für forward und backward) und diese in einer line zusammenzubinden (schau mal Relation 338255 und http://www.öpnvkarte.de/?lat=50.81103lon=6.04212zoom=14layers=BT Linie 27). Allerdings wird so etwas von den bisherigem ÖPNV-Renderer und auch dem OSM-Browser ÖPNV-Overlay nicht optisch unterstützt. Das düfte auf der Karte auch schiewrig sein, die Karte unseres ÖPNV-Unternehmens kann das auch nicht. Es ließe sich wohl nur über zusätzlich aufrufbare popups o.ä. machen. -- Mit freundlichen Gruessen Wolfgang Wienke ___ 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
[Talk-de] Kulturhauptstadt 2010 - was ist daraus geworden ?
Moin ! was ist eigentlich aus http://wiki.openstreetmap.org/wiki/WikiProject_Kulturhauptstadt_2010 geworden ?? Gruß jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM an der VHS
Hallo Markus, vielen Dank für Deine umfangreiche Antwort. Sie hat mir gefallen. Dein Stil hat mir gefallen!! Also habe ich JOSM durch Versuch und Irrtum ergründet. Mühselig und langwierig. Aber immer wenn ich etwas verstanden habe, habe ich das gleich ins Wiki geschrieben: http://wiki.openstreetmap.org/wiki/DE:JOSM/Werkzeuge Mir ging's genau so. Habe mich als Autodidakt betätigt. Als ich auf die Mailingliste aufmerksam wurde, habe ich mich sofort eingetragen. Die Inhalte der Artikel, die Wortwahl, die vielen mir nicht bekannten Abkürzungen haben mich nur denken lassen: Oh mein Gott. Ich kam mir so hilflos vor. Es hat lange gedauert, bis ich mich traute, auch einen Artikel zu schreiben. Für ein Re auf einen Artikel traue ich mich jetzt noch kaum. Und ich war auf der Entwicklerkonferenz und habe versucht, den Profis zu beschreiben, wie schwierig für uns Anfänger der Einstieg und die Arbeit mit OSM ist, und Ideen eingebracht, was uns helfen könnte. Kann leider nicht so durch die Welt fahren. Inzwischen ist viel geschehen: Zunehmend werden Erkenntnisse aus der Mailingliste ins Wiki geschrieben. Wikitexte werden in deutscher Sprache verfasst (oder übersetzt). In JOSM gibt es für vieles Vorlagen, mit denen man die Eigenschaften der Objekte benutzergeführt erfassen kann. Für Windows-Nutzer gibt es automatische Installationssoftware. Und für viele Programme und Anwendungen gibt es verständliche und nachvollziehbare Beschreibungen in deutscher Sprache. In der Tat. JOSM hat sich gewaltig weiterentwickelt. Trotzdem vermisse ich eine bessere und auch besser strukturierte Hilfe. Z.B. beim Briefkasten: Die in JOSM integrierte Tag-Auswahl plus mögliche zusätzliche Tags wie collection_times. Woher weiß ich als einfacher Anwender, was noch alles angeboten wird. Und jedesmal das ganze Wiki durchsuchen - nein. Beispiel: Gestern suchte ich nach einem Eintrag für einen Hubschrauberlandeplatz an einem Krankenhaus. Schon wieder in der Wiki nachschauen - keine Lust. Habe also eingetragen: amenity=helicoper_landing_site. Sicherlich falsch. Bin nach der Suche hier gelandet: http://wiki.openstreetmap.org/wiki/Tagwatch/Descriptions/de Nach einiger Suche habe ich gefunden: aeroway=helipad. Ich bin mir sicher: das ist nicht der vollständige Eintrag. landuse=aeroway : Ist das die richtige Ergänzung? Wie Du lesen kannst, bin ich ganz schön am schwitzen. Bin auch nach einiger Zeit darauf gekommen dass sämtliche Automaten zuerst mit amenity=vending_machine getaggt werde. Ich denke, vielen geht es ähnlich. Ich wünsche mir diesbezüglich eine bessere Hilfe bzw. eine Verlinkung in eine Datenbank. Bei OpenSeaMap versuchen wir, mit einem intelligenten Editor dem Nutzer eine grafische Eingabeoberfläche zu bieten, damit er sich nicht mehr durch die vielen Attributierungsvarianten kämpfen muss. Grafisch - schön. JOSM hat sich wirklich gut weiter entwickelt. Aber .. siehe oben Biete meiner Hilfe gerne an Danke für Dein Angebot - nehme ich gerne an! Wir könnten beispielsweise eine Einführung in OSM machen, als Powerpoint-Präsentation und Life-Demo, z.B. für einen VHS-Abend. Oder einen Halbtages-Workshop Kartografieren mit JOSM. Biete wirklich meine Hilfe an. Texte schreiben, bei der Struktuierung helfen. Didaktisch und methodisch (Sch... Leherdeusch) Kapitel aufbauen und Texte struktuieren. Kann auch Fotos beisteuern. Habe kein Powerpoint aber das Pendant in Openoffice. PS: kennst Du ein Werkzeug, mit dem man eine solche Teamarbeit virtuell organisieren und gemeinsam an einer Präsentation arbeiten kann? Nein, kann mich aber mal schlau machen. Viele Grüße Lothar ___ 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] Frage zum ÖPVN-Tag-Schema
Hallo Jan, der User Thomas Reinke ist in dem Bereich sehr aktiv und kennt sich aus. Er hat hier im AL auch schon einiges geschrieben. Wende Dich doch mal an ihn. Wie würdet Ihr FROM und TO definieren. Einige der Busse bis Oberbüssauer Weg und andere von dort in verschiedene Richtung Moorgarten bzw. Klein Wesenberg. Und bekommen die Wegeabschnitte zu den Verästellungen irgendetwas besonderes zugewiesen ??? Als Beispiel nehme mal die route Bus 237 im Bereich Aachen-Köln. Hier hat Thomas einiges reingeschrieben. Übrigens: Ist die Mail mit der Präsentation als Anhang angekommen? Viele Grüße Lothar ___ 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
[Talk-de] Hallennummern
Hallo, ich bin gerade durch Zufall darauf gestoßen, dass Sporthallen wohl eine Hallennummer besitzen. Hier findet sich eine (zufällig ausgewählte) Liste: http://www.bsc-handball.de/Hallen/hallever.htm Ich hab leider auch nach längerer Suche nicht herausfinden können, ob die Nummer bundesweit gilt und von offiziellen Stellen vergeben wird oder ob sich da jeder Sportverband seine eigene Suppe kocht. Weiß jemand genaueres? Gruß, Markus ___ 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
[Talk-de] Karte mit Marker im Wiki - ist das mö glich
Moin ! wir suchen eine Möglichkeit um im Wiki eine Karte mit Marker, ähnlich wie dieses mit [1] möglich ist zu realisieren. Kann uns einer weiterhelfen?? ... wenn ich die Anforderung noch weiter ausbauen würde, dann wäre die Einblendung von Relationen im Wiki (z.B. für Grenzen) noch ganz hilfreich. Gruß Jan :-) [1] http://dev.openstreetmap.de/staticmap/wizzard/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC Validator
Hallo zusammen, ich hab' mal ne Frage zu der Angabe der Gegend (inner- / außerorts). Bedeutet innerorts, dass der Punkt innerhalb des Orts (also nach dem Ortsschild) liegt oder das der Punkt im bewohnten Gebiet liegt (z.B. Industriegebiet = außerorts)? Grüße, Michi signature.asc Description: OpenPGP digital signature ___ 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] Karte mit Marker im Wiki - ist das mö glich
Am 12.01.2010 22:07, schrieb Jan Tappenbeck: wir suchen eine Möglichkeit um im Wiki eine Karte mit Marker, ähnlich wie dieses mit [1] möglich ist zu realisieren. Hätte ich auch gern! Gruss, Markus ___ 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] OSM an der VHS
Am Di Januar 12 2010 glaubte Lothar Emmerich zu wissen: Ich wünsche mir diesbezüglich eine bessere Hilfe bzw. eine Verlinkung in eine Datenbank. Ja, das Wiki ist teilweise eine Katastrophe, wenn man etwas bestimmtes sucht. flo -- Dein blöder PATSCH Hatt eines meiner Augen getroffen. Wenn du das noch mal machst, dann kuck Ich dich nicht mehr an . Ach was, Du hast doch sicher noch genug Augen. [WoKo und Michael Hoffmann in dag°] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM an der VHS
Hallo zusammen, Am 12.01.10 00:49, schrieb Markus: . PS: kennst Du ein Werkzeug, mit dem man eine solche Teamarbeit virtuell organisieren und gemeinsam an einer Präsentation arbeiten kann? Man könnte es mal mit dem neuen Spielzeug von Google versuchen: https://wave.google.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC Validator - Innerorts/Außerorts
2010/1/12 Michael Bemmerl osm-t...@mx-server.de: Hallo zusammen, ich hab' mal ne Frage zu der Angabe der Gegend (inner- / außerorts). Bedeutet innerorts, dass der Punkt innerhalb des Orts (also nach dem Ortsschild) liegt oder das der Punkt im bewohnten Gebiet liegt (z.B. Industriegebiet = außerorts)? Was genau hat das jetzt mit TMC zu tun? Für TMC ist Innerorts/Außerorts egal. Glasseis/Strassensperre/Stau/... sind es in beiden Fällen. Allgemein wäre für den Verkehr innerorts nach dem Ortsschild. Für Adressen und erst Recht für Verwaltungs-Regionen kann es anders sein. Bitte macht die Frage doch unter einem anderen Betreff auf, damit sie nicht übersehen wird. Marcus ___ 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
