Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 31.07.2010 um 23:55 schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1, da es auch webclients gibt, die plaintext _leider_ nicht können. Wäre super und es gäbe keine Diskussionen darum mehr, weil man sich einfach nicht mehr darum kümmern muss. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 01.08.2010 um 00:08 schrieb Johann H. Addicks: Am 31.07.2010 23:55, schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1 +1 Und bitte Abfilterung von Beiträgen mit 70% Quoteanteil. -1 schwierig, auch wenn ich grundsätzlich Deiner Meinung bin. Manchmal muss man Zusammenhänge aus mehreren mails zusammenquoten, dass man auch mal auf Grundlage dieser quotes einen neuen Thread beginnen kann. Gut. Wer macht das schon... Aber wo zieht man die Grenze? 70%? . k.A. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 31.07.2010 um 21:39 schrieb Tobias Knerr: Am 27.07.2010 17:56, schrieb steffterra: Am 27.07.2010 um 15:09 schrieb Tobias Knerr: Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell * eine Fahrtrichtung oder * eine Fahrspur bzw. Gruppe von Fahrspuren Das Modell kann beides. Diese Eigenschaft macht es m.E. etwas verwirrend. Ein zusätzlicher Way repräsentiert eine Fahrspur wäre beispielsweise deutlich einfacher zu erklären (und im Editor darzustellen) als ein kommt darauf an. Aus dem Zusammenhang heraus gesehen stimme ich Dir zu. Doch wenn man es aus sicht des Bedarf siehst: Wenn man richtungsabhängige Tags nicht nötig wären auf _einem_ way, wozu dann Fahrspuren für jede Richtung erstellen? Einfache Logik, oder? Ebenso grundsätzlich zur Fahrspur. Wenn die Fahrspuren sich nicht unterscheiden, wozu diese dann zeichnen, wenn ein lanes=2 es auch tun würde? Auch einfache Logik, oder? Diese Beurteilung meinerseits liegt natürlich auch daran, dass ich bekanntlich :forward/:backward nicht als echtes Problem sehe, so dass die Fahrspurdarstellung aus meiner Sicht der einzige gute Grund für die Einführung eines Linienbündel-Modells ist. ;) Sehr gute Selbsteinschätzung :-) Beispiel 1: in der Wirklichkeit sieht unsere Beispielstraße so aus: ganz normale Straße mit zwei Fahrspuren (pro Richtung eine Fahrspur) ohne Unterschiede, egal aus welcher Richtung man kommt. Geschwindigkeitsbegrenzung: 50km/h. [...] Beispiel 2: die gleiche Straße bekommt eine Geschwindigkeitsbeschränkung von 60 km/hverpasst, die nur in einer Richtung (z.B. in Richtung Süden) gilt. Eingezeichnet ist der way in JOSM von Nord nach Süd. Ausserdem werden Schilder für die Fahrrichtung aufgestellt, da es eine neuralgische Verbindugnsstraße wird. Die Süd-Nord-Richtung führt nach Hamburg, die Nord-Süd-Richtung nach München und ist auch so ausgeschildert (Es ist ein Beispiel ;-) [...] -way (Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd-Nord): maxspeed=50, destination=Hamburg Beispiel 2a: Dasselbe, aber die Straße hat keine getrennten Fahrspuren - ist also einspurig. Wird das dennoch mit zwei Zusatzways dargestellt? Wie jetzt - eine Spur? Dann muss es ja eine Einbahnstraße sein, oder meinst Du jetzt einen Feldweg? Ich bitte doch davon abzusehen, richtungsabhängige Tags an Feldwegen zu plazieren. Scherz beiseite. Aus Spaß wurde Ernst: Welche Straßentypen meist du - Wo hat man denn nur eine Fahrspur, auf der es Gegenverkehr gibt, die gleichzeitig richtungsabhängige Tags benötigt? Welche richtungsabhängigen Tags wären dass beispielsweise? Bitte beachte, dass nicht jede Straße, die _keine_ Mitellinien-Strichelchen besitzt automatisch einspurig ist. Darauf können selbstverständlich 2 Fahrzeuge, die sich entgegenkommen nebeneinander fahren, ohne dass einer davon zur Hälfte in den Graben ausweichen muss. Und selbst wenn so eine Straße dann von einem Radweg auf einer Seite begleitet wird, dann ist dieser baulich getrennt, weil sonst dies immer als Ausweichmöglichkeit bei Gegenverkehr genutzt würde Ich bin gespannt auf Dein Beispiel. Beispiel 3: die gleiche Straße wird um eine Fahrspur in Richtung Norden-Süden erweitert, auf der anderen Seite jedoch nicht [...] Beispiel 4: die gleiche Straße bekommt auf der äußersten Fahrspur der Richtung Nord-Süd zusätzlich zur Fahrspur aus Beispiel 3 noch einen Radweg verpasst, weil diese Straßenseite so gefährlich wurde. [...] - in meinem Modell: -way (außen eingezeichnet Nord-Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated -way (innen eingezeichnet Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd-Nord): maxspeed=50 Beispiel 4a: Nehmen wir weiter an, die äußere Fahrspur Nord-Süd ist 3m breit, der Radweg daneben 1,5m. Außerdem möchte ich die Oberfläche des Radwegs per surface/smoothness-Tags beschreiben. Wie werden diese diese Informationen ergänzt? So, wie man es an _einem_ way auch machen würde. Nur dass Du das _jedesmal_ dann nötige :forward weglassen kannst, weil ja schon klar ist, auf welchem Richtungsway Du das taggst. Beispiel 4b: Nehmen wir an, es gibt einen Parkstreifen zwischen dem Radweg und der Fahrbahn. Wie sieht die entsprechende Ergänzung aus? Du meinst nicht Fahrbahn, sondern Fahrspur. Denn die Fahrbahn ist das ganze, sofern keine bauliche Trennung zwischen der Radfahrspur, dem Parkstreifen oder ähnlichem vorliegt. Also kommt es darauf an, ob eine bauliche Trennung (z.b. durch Bäume zwischen den Parkständen) vorliegt oder nicht. _Wenn bauliche Trennung_ , ist es klar, wie bisher auch: dann hat der Radweg eine eigenen way verdient und dessen tags dran, parking:lane an den Richtungsway. Doch dann darf der Radweg nicht mit in die Gruppe, da er ja durch die bauliche Trennung kein Teil der Fahrbahn mehr ist. Beispiel 4c: Anders als
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 21:14 schrieb steffterra: Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Ich muss mich selbst korrigieren: Natürlich ist es quatsch, durch den Editor noch forward/backward am Richtungsway zu taggen. Da hast Du mcih jetzt echt aufs Glatteis geführt. Nochmal zum Versatändnis: du schlägst einerseits vor, dass der Editor per popup-Fenster und Pfeil zum betroffenen way, an dem man das Tagging durchführt einfach die Keys einträgt, die für diesen richtugnsway gelten. Das geht aber auch so wie jetzt auch, da ja an so einem Richtugsway _keine_ richtungsabhängigen Tags nötig sind! Wenn Du Dein vorgehen an normalen ways machen möchtest, ist es dem Editor eben nicht möglich selbst zu entscheiden, was der user gerade eingibt, da eben nciht klar ist, wie er forward/backward/left/right vergeben soll, da es ja nur ein way ist. Bei senkrechten und waagrechten ways könnte man diese automatische Vergabe der richtungsanhängigen Tags noch ermöglichen, doch bei ways, die in 45° Winkel verlaufen, weiss der Renderer nicht von was Du ausgehst. Ist links jetzt die westliche Fahrbahnteil gemeint, oder der nördlich gelegene? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 01.08.2010 um 10:59 schrieb Christian Knorr: Am Sonntag 01 August 2010 10:27:07 schrieb steffterra: +1, da es auch webclients gibt, die plaintext _leider_ nicht können. ?? Steh' ich jetzt auf'm Schlauch oder hast Du Dich verschrieben? hmm, nochmal: +1 für den automatischen plain-text durch _den Verteiler_, da es web-mail-clients gibt, bei denen man eben _kein_ plain-text einstellen kann und die immer html verschicken. Dann wandelt der mailingliste-Verteiler-Server diese html-mails automatisch in plain-text um, und alle sind glücklich. Alles klar? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2
Am 01.08.2010 um 09:37 schrieb Stefan Sandrock: Am 01.08.2010 08:51, schrieb Gehling Marc: ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 finde ich gut - die zusammenstellung. Super Engagement! Danke - nicht aufhören!!! :-) Vorschlag: Große laufende Diskussionen, an denen man sich vlt. beteiligen möchte, könnten ebenso Berücksichtigung finden. (Ich denke an nichts spezielles, sehe nur keine aufgenommen) steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-1?q?_forward/backward?=)
Am 01.08.2010 um 14:37 schrieb Guenther Meyer d@sordidmusic.com: das Popup kam von dir ;-) Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Was meinst Du dann mit graphischer Eingabe? Ich dachte Du meinst ein Eingabefenster, das an der Graphik zeigt, wo die tags angegeben werden. Mein Fehler, vergessen wir das ganze. Wie sollte Deiner Meinung nach eine graphische Eingabe aussehen??? konkret muss man schauen, was die beste Methode ist, das darzustellen. Ich gehe einen Schritt weiter. Ich will nicht, dass der User (ausser er arbeitet in einem speziellen Expertmode) ueberhaupt mit Tags zu tun hat. Damit stellst Du aber alles in Frage und schlägst ein System wie Potlatch oder Mapzen vor, bei denen Du nur Checkboxen, die die Tags tepräsentieren, anhakst, um die Eifenschaften eines ways abzubilden. Wie willst Du nun richtungsabhängige Informationen mithilfe dieser Art der Eingabe realisieren? Wenn Du Dein vorgehen an normalen ways machen möchtest, ist es dem Editor eben nicht möglich selbst zu entscheiden, was der user gerade eing ibt, da eben nciht klar ist, wie er forward/backward/left/right vergeben soll, da es ja nur ein way ist. das wuerde ganz genau so funktionieren, denn auch ein way hat eine Richtung. Diese Richtung des ways ist aber nicht definiert, noch weiss man, ob er beim Vorhandensein von richtungsabhängigen Tags noch in die richtige Richtung zeigt. Das ist ja das Motiv für eigene ways für richtungsabhängige Eigenschaften! Außerdem sind wir schon wieder bei der Diskussion, dass man eben nicht automatisiert dem Editor (dem Programm) überlassen kann, welche Richtung der user nun meinte. Der Editor kennt zwar die Richtung des eingezeichneten Way, aber nicht automatisch, was der user in welcher Richtung hinraggen möchte. Das erfährt der Editor vom user und da passieren die Fehler. Um da Fehler erkennen zu können, müsste der Edtor das aber validieren können, dazu fehlt ihm aber die Information, weil er sich auf den User verlassen muss. Verstehst Du? Auch ein graphischer Editor kann das nicht leisten, außer der User sagt ihm von welchem Node zu welchem Node das gelten soll. Und auch da darf der user nicht die nodes andersherum anklicken, sonst ist es die Gegenrichtung. Es bleibt also dabei: es hängt am User. Und diese menschliche Fehlerquelle kann man IMHO nur durch einen eigenen way minimieren. steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 um 17:20 schrieb Jan Tappenbeck: Hi ! wenn man flächendefiniert dann bin ich der Auffassung das diese bis dicht an die Ways gezogen werden sollen - wenn man diese nicht gar zusammenführt. Vielfach sieht man das die Flächen bis auf 1/2 Straßenbreite an die Ways herangezogen werden. Sicherlich mappen wir nicht für die Renderer aber dort sind dann immer kleine Leerstreifen was mehr als unschön aussieht. Ich kann mir auch nicht vorstellen das Renderer diese Entscheidung - bis wo Flächen gehen in Zukunft ausgleichen werden. Wie denkt Ihr darüber bzw. wie macht Ihr das ??? Das Problem der Rednerer liegt nicht bei den Flächen sondern bei den ways. Straßen werden nicht mit ihrer reellen kompletten Fahrbahnbreite über alle Spur-Arten hinweg zusammen gerendert (eine Linie für alles, auch wenn es eigene Parkstreifen, Fußgängerwege und Radwege gibt, einseitig oder beidseits) und alles ohne bauliche Trennung. Dennoch muss der way dort gezeichnet werden, was die Mitte mehrerer GPS-Spuren ist, da das die wahrschienlichste Mitte der Fahrbahn darstellt und GPS-Ausreisser ausgleicht. Und nicht der Schönheit halber an die Flächen heranziehen. Denn falls später einmal ein populärer Renderer sich dazu entschließen sollte, das Fahrspuren und Radwege, Gehwege, etc. in ihrer realen oder wahrscheinlichen Breite gerendert würden, wäre der way nicht mehr in der Mitte der realen Fahrbahn und der Rednerer würde Fahrspuren in die Fläche hineinzeichnen. Aus diesem Grunde schon: niemals für die Renderer die Lage von ways falsch zeichnen, wie Du auch schon sagst. Die Fläche dahin zeichnen, wo sie nunmal ist (wird ja auch so gerendert) und den way auf die wahrscheinliche Mitte der _gesamten_ Fahrbahnbreite inkl. Sonderspuren bis zur nächsten baulichen Trennung zeichnen, dann ist die Lage des way auch noch in Zukunft nutzbar und muss nicht korrigiert werden, wenn die Renderer endlich die Fahrbahnbreite/Fahrspurenangaben z.B. (lanes=4) unterstützen. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 um 18:02 schrieb Klaus Hanauer: Am 01.08.2010 schrieb Steffterra: Denn falls später einmal ein populärer Renderer sich dazu entschließen sollte, das Fahrspuren und Radwege, Gehwege, etc. in ihrer realen oder wahrscheinlichen Breite gerendert würden, wäre der way nicht mehr in der Mitte der realen Fahrbahn und der Rednerer würde Fahrspuren in die Fläche hineinzeichnen. Solange wir keine flächenhaften Wege haben fallen für mich der linke Rand des Weges, die Mitte des Weges und der rechte Rand zusammen. zusammen in die gemittelten GPS-Spuren, in der einen Linie des einen way - richtig. Aus diesem Grunde schon: niemals für die Renderer die Lage von ways falsch zeichnen, wie Du auch schon sagst. Die Fläche dahin zeichnen, wo sie nunmal ist (wird ja auch so gerendert) und den way auf die wahrscheinliche Mitte der _gesamten_ Fahrbahnbreite inkl. Sonderspuren bis zur nächsten baulichen Trennung zeichnen, dann ist die Lage des way auch noch in Zukunft nutzbar und muss nicht korrigiert werden, wenn die Renderer endlich die Fahrbahnbreite/Fahrspurenangaben z.B. (lanes=4) unterstützen. Es kann doch für die zukünftigen Renderer kein Problem sein, die an die Fahrbahn direkt angrenzenden landuse Bereiche entsprechend der realen und gezeichneten Fahrbahnbreite wieder automatisch zurückzudrängen. Wenn der way aber nicht in der Mitte liegt, wie er eigentlich gezeichnet werden sollte, dann liegt die gesamte Fahrbahn verschoben - dann in realer Breite, aber verschoben auf der real gezeichneten Fläche. Woher soll der Renderer denn wissen, ob die Fläche verschoben eingezeichnet ist oder der way an die Fläche geschoben wurde? Ich sehe als Kompromiss eher: den way der Straße, wie gesagt mittig auf die reale Straße zu zeichnen und die Fläche bis zu dieser zu ziehen. Denn schon jetzt wird im Renderer der way die Fläche optisch überlagern und so die Fläche mit seiner Straßenbreite übermalen. steffterrs ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2
Am 01.08.2010 um 18:17 schrieb Jonas Krückel: Wir planen die Wochennotiz zusammen mit weiteren Inhalten in Zukunft in einem eigenem Blog unterzubringen. super Idee! steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 01.08.2010 um 20:57 schrieb Guenther Meyer: Es bleibt also dabei: es hängt am User. Und diese menschliche Fehlerquelle kann man IMHO nur durch einen eigenen way minimieren. den Menschen kannst du gar nicht eliminieren, weil der der einzige ist, der weiss, wa wohin gehoert. Der Editor ist der, der ihm das Eingeben seines Wissens so einfach machen muss wie moeglich. jetzt gebe ich diesen Zweig der Diskussion auf. Du willst mich missverstehen? Nein, aber wir kommen auch nicht weiter. Wir drehen uns im Kreis. Aber Dein Vorschlag mit der grafischen Umsetzung des Taggings ist dennoch eine gute Möglichkeit, wie ich finde, die mein Modell unnötig machen würde. Das fände ich ja auch gut. Bringe es zu einem Proposal und ich werde dafür stimmen. Bis dann, hole Dir ein paar Entwickler ins Boot und ich wünsche Dir viel Erfolg beim Erstellen des Proposal. Das meine ich ernst. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 01.08.2010 um 03:46 schrieb Rainer Knaepper: addi...@gmx.net (Johann H. Addicks) am 01.08.10: Am 31.07.2010 23:55, schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1 Und bitte Abfilterung von Beiträgen mit 70% Quoteanteil. .oO(XP meckert das doch an vor dem Versenden, bieten andere Programme etwa solchen Service nicht?) LOL, XP - Crosspoint -richtig? so hiess das tolle UUCP-DOS-Programm. Ich liebte es. Es gab nie etwas vergleichbares um Mailinglisten und Newsgroups adäquat sortiert und zu lesen zu bekommen. Heutige moderne eMail-Programme können viel, aber nicht XP ersetzen. Doch es gibt modernere und effektivere Methoden vielschichtige Sachverhalte mit vielen Leuten zu diskutieren, ohne sich ständig im Kreis zu drehen: z.B. Foren mit guter Moderation. Mit diversen Ansätzen zu ein paar Diskussionen in der letzten Zeit (durchgezogene Mittellinie, Gruppierung von ways, u.v.a.m.) konnte ich bemerken, wie schwierig es hier ist - und anstrengend und letztendlich ohne outcome, ausser reinem Meinungsaustausch, der häufig darauf beruhte, dass eben nicht alles gelesen wurde. Somit gebe ich hier großflächig auf und überlege mir auch das Gruppierungs-Proposal weiter zu verfolgen. Auch das ist ein Outcome der Diskussionfähigkeit dieses Mediums. Grüße und machts gut, möglichst effektiv ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 30.07.2010 um 08:17 schrieb Guenther Meyer: Am Donnerstag 29 Juli 2010, 23:44:33 schrieb steffterra: Nunja. da gehts ja um die aktuell etablierten Autobahnspuren, die bei jeder baulichen Trennung ja auch so gezeichnet werden sollten. Oder habe ich etwas übersehen? inklusive Fahrspurtagging. tagging ja - zeichnen nein. Nur die Fahrbahnen der beiden Richtungen (die je aus mind. 2 Fahrspuren bestehen können) werden einzeln gezeichnet, da es ja eine bauliche Trennung für die Fahrbahnen der beiden Richtungen gibt. Einzelne Fahrspuren einer Fahrbahn sind darin nicht umgesetzt worden, da sie nicht baulich getrennt sind. Das Prinzip möchte ich ja in meinem Modell beibehalten, nur dass dann angepassten Editoren die ways als zu einer Fahrbahn gehörig dargestellen können (durch die gleiche Hintergrundfarbe). Insofern wird zwar aufgehoben: ein way pro Fahrbahn, doch das gilt immernoch ausserhalb der gemeinsamen Hintergrundfarbe. Alte Editoren zeigen es halt wie jetzt auch an, mit den einzelnen ways pro Fahrspur, die aber nicht als baulich verbunden gezeigt werden (da die gemeinsame Hintergrundfarbe fehlt.) Ausserdem sind die ways ohne Straßenklassifizierung, weil das ja am datenway liegt. Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar nicht gerendert, da der highway-tag fehlt. Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet es entsprechend. Da Konzept sollte wohl auch fuer andere Strassen erweitert werden, leider kamm dann erstmal nix mehr... weil die bauliche Nicht-Trennung dagegen stand. Aber dann unterstütze nicht indirekt das den derzeit festgefahrenen Karren ;-) Indem Du sagts, dass man die wayrichtung in ruhe lassen sollte, udn dann gehe das tagging schon klar. Ich denke vielmehr, dass egal sein sollte, die Wayrichtung zu ändern. Und das wäre es bei meinem Modell. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. Ich hänge mich nicht zu sehr an der Richtung auf, sondern ich versuche mit meinem Modell das Problem mit der Richtung zu beheben. Irgendwie musst du die Gruppierung ja in der Datenbank speichern. Das naheliegendste ist da natuerlich eine einfache Relation. Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu taggen (wahrscheinlich sogar die bessere). ich dachte an eine ID die durch einen einfachen Algorithmus aus den beteiligten ways automatisch errechnet wird. Ist das bei Relationen genauso? Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. Ja eben, wie errechnet sich denn die ID einer Relation? Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ sinnvoll), die dieses Model bietet. wie jetzt, dein Modell? Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen Spezialfälle umsetzbar? Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts Gruppe selbst. Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die Spezialfälle der Gruppierung mittels Relationen darstellst. Also die Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die Gruppierung ncihts anderes als eine Relation wäre. da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm). Ich schau's mir an, und versuche dann mal, dasselbe auf meine Weise zu relaisieren... Da müsst Ihr Euch leider noch etwas gedulden. Aus beruflichen Gründen bin ich massiver eingespannt, als ich dachte und bin froh, diesem Thread weiter verfolgen zu können. mir geht's da leider aehnlich... Aber hey, wenn am Ende was brauchbares rauskommt, kommt's auf ein paar Tage mehr auch nicht an ;-) Sorry, muss weiter vertrösten. Aber ich stehe hinter meinem Modell und werde es hoffentlich bald mal machen können. Bis denn und danke, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 30.07.2010 um 08:27 schrieb Guenther Meyer: Für die Umsetzung müssen natürlich alle an einem Strang ziehen. +1 Abwärtskompatibilität bleibt ja dennoch erhalten. lassen wir uns ueberraschen. ich denke das koennte bei deinem Modell interessant werden. Man muesste mal ausprobieren, was ein heutiger Renderer aus deinem Modell machen wuerde (kann ich gerne machen, sobald was getaggtes vorliegt)... Das wäre cool. Leider habe ich dazu jetzt in der anderen mail geantwortet... :-/ wie das gerendert würde. Aber visualisiert ist es natürlich noch einfacher zu verstehen. Besonders der Richtugnsway, der nach meinem Modell keinen eigenen highway-tag hat, sollte eigentlich nicht gerendert werden, der datenway schon. Da die richtungsabhängigen Tags dann auf den ways liegen wird man diese Trennung auch bei der Software berücksichtigen müssen. Doch da helfen nur note-tags, dass das nicht zerlegt wird und stattdessen die Software das neue Modell unterstützt. (z.B. Navi-software, etc.) Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... doch woher soll das frontend wissen, wo backward usw. in der Realität ist? ist das so schwer?! ja schon. Wenn das automatisch gehen soll schon. der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. Wenn man mit Himmelsrichtungen für die Straßenseite arbeitest, dann hast Du das Problem, dassw man bei schräg verlaufenden Straßen nicht weiss, ob das nun nördlich ist (wie bei einer horizontalen Straße), oder schon westlich (wie bei einer senkrechten Straße) ... verstehst Du? Da müssten dann wieder Regeln eingeführt werden, ab wieviel ° was gilt. Aber es wäre durch Regeln umsetzbar. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 13:53 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:25:54 schrieb steffterra: Beim Renderer ist es so: der alte Renderer zeigt nur den datenway, da dieser eine Straßenklassifizierung hat. Die Richtungsways werden gar nicht gerendert, da der highway-tag fehlt. wenn ich dich richtig verstehe, koennen die zusaetzlichen ways u.a. auch Rad- und Fussgaengerwege sein, getrennte Ein/Ausfaedel- und Abbiegespuren sind genau so moeglich. Bisher werden diese ueber ein Highway-Tag gekennzeichnet, willst du dieses auch verwerfen und was neues einfuehren? Wenn Du mein Eingangsposting noch einmal in Ruhe liest, wird Dir auffallen, dass Radwege, etc. keine eigenen ways bekommen. sie werden einfach am richtigen Richtigungsway getaggt. Das ist einer der Unterscheide zum Linienbündel, das alles aufgedröselt hat. Ich möchte _nur_ die richtugnsabhängigen Tags in eigene ways packen und Fahrspuren auch _nicht generell_ sondern nur da, wo es der Plausibilität und besseren Abbildung der Wirklichkeit _nötig_ ist. Ein neuer Renderer erkennt aber, dass das Fahrspuren sind und zeichnet es entsprechend. eben, deshalb halte ich das Radwegtagging am auf der Seite des entsprechenden Richtungsway völlig ausreichend. In einem anderen Posting (es dürften 8-10 Postings/Mails vor diesem gewesen sein, schau mal ein wenig durch) habe ich 5 Beispiele verglichen, wie es nach dem jetzigen System und wie nach meinem Modell getaggt würde. Da siehst du den Radweg und andere Dinge entsprechend im Vergleich getaggt. Es sind halt zwei verschiedene Ansaetze. Du haengst dich zu sehr an der Richtung auf. Ich versuche normalerweise erst mal, Probleme schnell und einfach am Ursprung zu loesen, bevor ich alles neu schreibe. Ich hänge mich nicht zu sehr an der Richtung auf, dafuer erwaehnst du das Thema zu oft ;-) Es _ist_ das Thema ;-) Siehe Betreff. sondern ich versuche mit meinem Modell das Problem mit der Richtung zu beheben. das sei dir ja gegoennt. Alles weitere dazu hatte ich bereits geschrieben. Das war nur die Antwort darauf, warum ich es von richtungsabhängigen Tag abhängig mache. Es ist das Thema, es ist der Hauptgrund (mit allen positiven Nebeneffekten die ich gerne mitnehmen), dass ich mir das Modell überhaupt überlegt habe. Also ist klar, dass ich darauf auch besonders eingehe, oder? Dass ich deshalb die Nebeneffekte (positive und negative gleichermaßen) deshalb noch lange nicht ausser Acht lasse, kann man in meinen Mails dieses Threads nachlesen. Irgendwie musst du die Gruppierung ja in der Datenbank speichern. Das naheliegendste ist da natuerlich eine einfache Relation. Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu taggen (wahrscheinlich sogar die bessere). ich dachte an eine ID die durch einen einfachen Algorithmus aus den beteiligten ways automatisch errechnet wird. Ist das bei Relationen genauso? Das hat nichts miteinander zu tun. Eine Relation ist ein Basisobjekt genau wie ein Node oder ein Way. Wie du die nutzt, steht dir im Prinzip total frei. Es geht hier nur um die technische Abbildung deiner Gruppierung bzw. ID. Ja eben, wie errechnet sich denn die ID einer Relation? keine Ahnung. Ich wuerde vermuten, dass die erst von der API beim comitten vergeben wird. Der lokale Editor kann ja nicht wissen, welche IDs frei sind. Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ sinnvoll), die dieses Model bietet. wie jetzt, dein Modell? Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen Spezialfälle umsetzbar? Ich glaube, da liegt ein Verstaendnisproblem vor: Das einzige, wozu ich eine Relation benutzt haette, waere die Abbildung des Objekts Gruppe selbst. Nein ;-) Ich meinte, Du solltest bitte mal zeigen, wie Du die Spezialfälle der Gruppierung mittels Relationen darstellst. Also die Gruppierungen selbst, nicht das ganze Modell. Du sagtest ja, dass die Gruppierung ncihts anderes als eine Relation wäre. im Sinne von zusammenfassen von Objekten, also in diesem Falle der Ways. Konkret: Relation XY sagt aus, dass Way 12, Way 34 und Way 56 zusammengehoeren und eine 'Gruppe' bilden. Verstaendnisproblem. Müsste sie auch noch aussagen, welcher way welche Rolle hat, oder ergibt sich das aus dem tagging? Dann könnte man auch sehr einfach eine Brücke in einer Relation zusammenfassen, schließlich ist das ja auch eine Fahrbahn mit unterscheidlichen Elementen. Hmm das ist eine interessante Geschichte. Denn sobald man richtugnsways, datenway, tram und anderes mit auf einer Brücke hat müsste man zunächst die Fahrbahnen ohne Tram zu einer Gruppe zusammenfassen und dann diese Gruppe und die Tram-Line in eine Relation für die Brücke zusammenfassen. Da bin ich aber eher dagegen, da es das unnötig verkomplizieren würde. Trams sind oft Fahrbahnbegleitend oder sogar gemeinschaftlich
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Gut, also keine Gruppierung mehr nötig? Hätte ich kein Problem, mit wenn man das vermeiden könnte. Wer baut die grafische Tagging-Funktion in JOSM und Potlatch? (hier sind doch ein paar Entwickler unterwegs, oder?) Nicht dass für die Gruppierung keine Entwickler nötig wären... ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-15?q?_forward/backward?=)
Am 29.07.2010 um 21:09 schrieb Tobias Knerr: Am 29.07.2010 16:59, schrieb steffterra: Am 28.07.2010 um 23:38 schrieb Tobias Knerr: Wenn ich zwei der Richtungsways verbinde und diese widersprüchliche Tags haben, welche Widersprü+che meinst du denn? forward-backward kann es ja nicht sein, da diese attribute ja nicht mehr nötig sind. Wie du später selber sagst, so etwas wie maxspeed=50 und maxspeed=60 für dieselbe Fahrtrichtung. Nach der Vereinigung kann nur eines davon zutreffen, Nein, es kann auch zutreffen, dass ab dem Verbindungsnode die neue Geschwindigkeit gilt. Aber es ist dann keine Unterscheidung mehr, zwischen zwei maxspeed:backward-Tags sondern zwischen zwei maxspeed-tags, bei denen klar ist, auf welcher Straßenseite es gitl. Beim backward-key weiss man das nicht, da der way ja falsch gedreht worden sein könnte. Letzteres gibt es aber nicht in meinem Gruppierungs-Modell. und welches das ist kann nur der Mapper entscheiden. Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der Unsicherheitsfaktoren. Wenn die Tags *nicht* widersprüchlich sind, könnte das der Editor das jetzt auch schon erledigen. (Beispiel wären zwei Ways mit entgegengesetzter Richtung, einer mit maxspeed:forward=60 und einer mit maxspeed:backward=60.) Ich glaube Du hast es wirklich falsch verstanden, oder das Eingangsposting nicht richtig gelesen. In der 3-letzten mail von mir standen auch 5 Beispiele, wie im Gruppierungs-Modfell getaggt wird. Nun, ich glaube, dass du *mich* falsch verstehst. ;-) Lies mein Posting doch einfach mal unter der Annahme, dass ich dich im Großen und Ganzen verstanden habe, und dass ich Formulierungen wie jetzt auch schon bewusst verwende. :-) Habe ich. Ich versuche immer unvoreingenommen zu sein. Des weiteren bin ich durchaus fähig selbstkritisch mit meinem Modell umzugehen und wäre schon zufrieden, wenn ein anderer Vorschlag daraus entstünde, der die Problematik effektiver und schneller lösen könnte. Ich kämpfe ja hier nicht und schon gar nicht um jeden Preis mit einem Brett vor dem Kopf :-) Ich rede im zitierten Absatz nämlich nicht über dein Modell, sondern das aktuelle mit :forward/:backward-Suffix. Ich weiss :-) Also: Vereinigungen erfordern nur bei widersprüchlichen Angaben an den Teilen manuelle Eingriffe, und diese manuellen Eingriffe sind bei jedem Modell notwendig. Bei diesem eben nicht, was ja einer der Vorteile ist. ;-) Widersprüchliche Angaben bei der Vereinigung von Richtugnsways aus meinem Modell könnten höchstens sein, dass die zu vereinenden Richtungsways unterschiedliche Werte ihrer Tags haben, Also z.b. maxspeed=50 und der andere maxspeed=60 (nochmal zur Erinnerung: beide auf der gleichen Seite der Straße). Dann kann man vereinigen, sollte aber überprüfen, was die Wirklichkeit sagt. Aber das gilt auch jetzt schon bei einem way, ohne richtungsabhängige Unterschiede. Eben: Die Fälle, wo der Mapper in deinem Modell bei Vereinigungen selber entscheiden muss, gibt es auch jetzt schon. Aber das gilt auch umgekehrt: Was in deinem Modell automatisch möglich wäre, ginge auch jetzt schon automatisch. Nein, da die unsicherheit besteht, dass der way zwischenzeitlich einmal aus Versehen gedreht wurde und die JOSM-Warnmeldung mangels Kenntnis missachtet wurde. Die Unsicherheit im generellen Umgang mit left/right und forward/backward erlebt man ja schon, wenn man die Argumente hier teilweise (nicht Deine) hier liest. Teilweise wurde nicht verstanden, dass backward/forward nicht das gleiche wie links/rechts ist, etc... Das zeigt, dasss das System im Grunde schon recht schwierig für manche ist. Dann kommt noch die Komponente dazu, dass der way aus den verschiedensten Gründen auch durch andere Editoren gedreht werden könnte, die keine Warnung oder ein automatischen Drehen der Tags ermöglichen. Wenn man aber einen way für jede Richtung einer Straße hat, dann passiert das erst gar nicht. Wenn du das anders siehst, nenne doch mal ein Beispiel, bei dem Vereinigungen beim :forward/:backward-Modell zwangsläufig (also nicht nur aufgrund von Unzulänglicheiten aktueller Editoren) einen manuellen Eingriff erfordern, der durch dein Modell überflüssig würde. Alleine durch die Tatsache, dass durch die Lage der ways klar wird, welche Fahrbahnseite gemeint ist, werden viele Fehlerquellen ausgeschlossen. Ausserdem ist es eine natürlichere Abbildung der Wirklichkeit, als die Abstraktion durch die Tags, die auch noch von einem anderen Faktor (Richtung des ways ansich) abhängig sind, was sich zudem auch noch ändern kann. In meinem Modell ist der way da, wo er ist. Eindeutig durch die Koordinaten festgelegt. Ein Beispiel ist natürlich das Drehen der way-Richtung, das ich als Hauptursache
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 29.07.2010 um 23:15 schrieb Guenther Meyer: Am Mittwoch 28 Juli 2010, 15:23:35 schrieb steffterra: Am 28.07.2010 um 08:05 schrieb Guenther Meyer d@sordidmusic.com: ich weiss nicht, ob ich's sschon mal erwaehnt hatte, aber fuer Fahrspurtagging gab's schon mal ein Konzept, dass ohne separate ways auskommt... Das ist also nichts neues. Die seperaten ways helfen hier aber auch bei dem Problem der richtungsanhängigen ways und eben nicht nur bei der Abbildung von Fahrspuren! Aber da Du es erwähnst: hättest Fu bitte einen Link für uns? Danke. nagel mich nicht drauf fest, aber ich glaub das war das hier: http://www.mail-archive.com/talk-de@openstreetmap.org/msg59559.html Nunja. da gehts ja um die aktuell etablierten Autobahnspuren, die bei jeder baulichen Trennung ja auch so gezeichnet werden sollten. Oder habe ich etwas übersehen? Das mag für Dich gelten, ich kenne hier aber keine Diskussion des letzten Monats, das es zu irgendeinem Konsens brachte. an das wirst du dich bei OSM gewoehnen muessen ;-) Nein das meinte ich nicht. Iss schon klar ;-) Ich hatte aus Deinen Worten gelesen, dass alles geklärt sei und dass das tagging, wie es ist doch ausreicht. Zumal das Thema ja immer wieder aufs neue aufs Tapet gebracht wird ;-) Du meinst es gibt kein Problem mit richtungsanhängigen tags, andere denken schon. Aus diesem Grund entstand mein Engagement für dieses Thema mit der Gruppierung von ways wie im Eingangsposting ausführlich geschildert. Fuer mich ist das Problem hausgemacht. Hat aber auch wieder mal mit gewachsener Struktur zu tun: Nunja, Du klangst schon, als ob es kein Problem gäbe, oder schlimmer, dass der Karren so festgefahren ist, dass sich das für Dich somit erledigt hat und das aktuelle Tagging in Deinen Augen ausreichen _muss_. wenn es nur darum geht, das Richtungsproblem zu loesen, finde ich deinen Vorschlag absoluten Overkill. Nein ich führe ja auch andere Vorteile auf, wie z.b. die Möglichkeit der Fahrspuren-Nutzuzng für Navis, exaktere Abbildung von komplizierten Kreuzungen, etc. Nichtsdestotrotz ist es ein interessantes Konzept, das denke ich, mehr bringen kann als die Losloesung von der Richtung. Das sehe ich auch so. Danke. Wenn Du diese Diskussion positiv beeinflussen möchtest, bitte ich Dich, etwas konstruktiv dazu beizutragen, anstatt hier groß zu erklären, dass doch alles in Butter ist. Mache bitte gerne _diskussionslos_ so weiter wie bisher, denn im Moment gibt es eh keine andere Möglichkeit. Aber bitte demotiviere nicht andere, neue, evtl. bessere Lösungsansätze zu verfolgen. Dann hast du mich vielleicht falsch verstanden. Leute demotivieren ist das letzte was ich vorhabe. Nur bin ich auch so realistisch, dass ich weiss, dass es nicht so einfach ist, technisch durchdachte Dinge und vor allem Veraenderungen dem OSM-Volk nahezubringen. Das beste Konzept nutzt nunmal nichts, wenn es keiner benutzt... Aber dann unterstütze nicht indirekt das den derzeit festgefahrenen Karren ;-) Indem Du sagts, dass man die wayrichtung in ruhe lassen sollte, udn dann gehe das tagging schon klar. Ich denke vielmehr, dass egal sein sollte, die Wayrichtung zu ändern. Und das wäre es bei meinem Modell. Ich habe uebrigens nie behauptet, das alles in Butter ist. Ganz im Gegenteil, bei OSM gibt es jede Menge an Dingen, die verbessert werden koennten und auch muessten. Nur ist mein Weg eher der, auf Basis des vorhandenen die einfachste Loesung zu finden. Und ich denke, die gibt es fuer viele Dinge durchaus. Das finde ich auch, wenn das denn möglich ist. Wenn jetzt jemand ein völlig anderes Konzept hätte, das Relationen/Gruppierung oder ähnliches und gleichzeitig die richtungsabhängigen tags unnötig machen würde, wäre ich der erste, der es unterstützt und sein eigenes Modell fallen lässt. Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache Relation. Die automatische Erstellung durch den Editor aendert daran genau nichts. Woher weißt Du dass es nichts anderes ist? Wäre das technisch die Lösung, das gewollte so umzusetzen? Irgendwie musst du die Gruppierung ja in der Datenbank speichern. Das naheliegendste ist da natuerlich eine einfache Relation. Eine andere Moeglichkeit waere, die Information an den mittleren Weg zu taggen (wahrscheinlich sogar die bessere). ich dachte an eine ID die durch einen einfachen Algorithmus aus den beteiligten ways automatisch errechnet wird. Ist das bei Relationen genauso? Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ sinnvoll), die dieses Model bietet. wie jetzt, dein Modell? Ja meines. Wie wäre mein Modell mit Relationen für alle angesprochenen Spezialfälle umsetzbar? da warte ich noch auf dein versprochenes Beispiel (realisiert z.B. mit josm). Ich schau's mir an, und versuche dann mal, dasselbe auf meine Weise zu relaisieren... Da müsst Ihr
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?utf-8?q?_forward/backward?=)
Am 29.07.2010 um 23:26 schrieb Guenther Meyer: Am Donnerstag 29 Juli 2010, 21:09:47 schrieb Tobias Knerr: Am 29.07.2010 16:59, schrieb steffterra: Am 28.07.2010 um 23:38 schrieb Tobias Knerr: Wenn ich zwei der Richtungsways verbinde und diese widersprüchliche Tags haben, welche Widersprü+che meinst du denn? forward-backward kann es ja nicht sein, da diese attribute ja nicht mehr nötig sind. Wie du später selber sagst, so etwas wie maxspeed=50 und maxspeed=60 für dieselbe Fahrtrichtung. Nach der Vereinigung kann nur eines davon zutreffen, und welches das ist kann nur der Mapper entscheiden. Irgendwie komm ich da grad nicht mit: Es gibt tatsaechlich ways, die uebereinanderliegen, und im selben Bereich unterschiedliche (Geschwindigkeits-) Tags haben? Ansonsten wuerde ich unter Vereinigung eher sowas verstehen: aus dem: *--way1--*--way2--* soll das werden: *wayneu-* wenn die beiden ways unterschiedliche Geschwindigkeitstags in derselben Richtung haben, dann kann das durchaus richtig sein. Eine Vereinigung ist dann sowieso nicht sinnvoll. +1 Es war aber sicher der Fall gemeint, dass einer der beiden tags falsch war, da man den node von woanders hergezogen hat und dann bei der Vereinigung entwscheiden muss, was jetzt stimmt. aber völlig irrelevant. denn das problem hat man jetzt auch und sollte leicht zu lösen sein. Keine Diskussiongrundlage, wie ich meine. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 29.07.2010 um 23:34 schrieb Guenther Meyer: Am Donnerstag 29 Juli 2010, 23:15:07 schrieb steffterra: Er kann es aber leichter entscheiden, wenn er davon ausgehen kann, dass die Richtigkeit der Tags nicht von einem potentiell falsch gedrehten way wieder zunichte gemacht werden könnte. Er kann sich einfach sicher sein, dass auf der richtigen Seite getaggt wurde. Also eine Minimierung der Unsicherheitsfaktoren. einen Unsicherheitsfaktor hast du immer. Nachher kommt ein Mapper, sieht deine drei ways und denkt sich so ein Schmarrn, das ist doch nur ein Strasse, und zerlegt dir das Ganze wieder... ;-) Dafür gibts wikis und den Editro, der das ganze entsprechend rüberbringt. Note-tags gibts auch noch. Für die Umsetzung müssen natürlich alle an einem Strang ziehen. Abwärtskompatibilität bleibt ja dennoch erhalten. Letztendlich bleibt es dann doch wieder am Frontend haengen. Der User sollte nicht wissen muessen, ob er left, right, forward, backward taggen muss, oder ob er jetzt lieber ein Tag oder einen neuen way dranbasteln soll... doch woher soll das frontend wissen, wo backward usw. in der Realität ist? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und?linker Seite
Am 28.07.2010 um 07:42 schrieb Tirkon tirko...@yahoo.de: Tobias Knerr o...@tobias-knerr.de wrote: Das geht aber nicht: Die beiden Begriffspaare bezeichnen völlig unterschiedliche Konzepte, sie sind nicht austauschbar. In Fällen, wo man forward/backward verwendet, kann man ohne Bedeutungsunterschied nicht left/right verwenden - und umgekehrt. Das Treppengeländer ist nun mal rechts, nicht vorwärts. Das Laufband bewegt sich vorwärts, nicht links oder rechts. Beide Angaben nehmen Bezug auf die Richtung des OSM-Ways, aber sind inhaltlich unterschiedlich. Genau! forward/backwards ist eine Richtungsangabe entlang des Weges, forward in Richtung des Weges, backward entgegengesetzt. left/right ist eine Seitenangabe, die sich ergibt, wenn man in Richtung des Weges schaut. Wendet man sich von Straßen ab und nimmt zum Beispiel eine Mauer, auf der es keinen Richtungsverkehr gibt, deren Weg auf OSM dennoch eine Richtung hat. Diese kann auf der rechten Seite rot und links schwarz sein. Spätestens hier kann man mit forward/backward keinen Blumentopf mehr gewinnen. Aber auch mit Straßen kann man verdeutlichende Beispiele basteln. Nehmen wir zum Beispiel eine Einbahnstraße mit zwei Fahrspuren: Düsseldorf Köln West Wegrichtung --- Ost forward --- backward--- === ---rechts--- - - - - - - - - - - - - - - - - - - - - ---links --- === Regenrinne Hier gibt es keine Fahrspur in Richtung Köln. Dennoch liegt Köln in Richtung backward aber nicht links. Die Regenrinne ist links und nicht backward. Zur Illustration jetzt noch dieselbe Einbahnstraße in die entgegengesetzte Richtung: Düsseldorf Köln West Wegrichtung --- Ost forward --- backward--- === ---links--- - - - - - - - - - - - - - - - - - - - - ---rechts --- === Regenrinne Jetzt liegt Köln in Richtung forward, Düsseldorf backward und die Regenrinne ist rechts. +111 :-) Wenn Du das jetzt noch jeweils bei diesen keys ins Wiki schreiben würdest, wäre das ne runde Sache und die Diskussion war nicht umsonst! Danke! Ich helfe gerne beim Fragen zum Wiki, falls nötig. Zu mehr habe ich leider keine Zeit und mit einem Proposal genug Arbeit das menschengetecht aufzuarbeiten :-) Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-1?q?_forward/backward?=)
Am 28.07.2010 um 08:05 schrieb Guenther Meyer d@sordidmusic.com: ich weiss nicht, ob ich's sschon mal erwaehnt hatte, aber fuer Fahrspurtagging gab's schon mal ein Konzept, dass ohne separate ways auskommt... Das ist also nichts neues. Die seperaten ways helfen hier aber auch bei dem Problem der richtungsanhängigen ways und eben nicht nur bei der Abbildung von Fahrspuren! Aber da Du es erwähnst: hättest Fu bitte einen Link für uns? Danke. sehe ich im Moment nicht wirklich Vorteile - und wesentlich einfacher wird's auch nicht. Wenn man alle Aspektev mit einbezieht eben schon. Vergleiche einfach mal die nötigen Tags in den Beispielen. Ist doch wesentlich klarer als die Latte an einem way, der dann ncoh die Gefahr birgt durch ein einfaches Drehen des way komplett über den Haufen geschmissen zu werden. Abe r das wurde auch alles schon einmal besprochen. die Drehproblematik ist wirklich hinreichend behandelt; ebenso dass es keines neuen Schemas bedarf, um *diese* in den Griff zu kriegen. Das mag für Dich gelten, ich kenne hier aber keine Diskussion des letzten Monats, das es zu irgendeinem Konsens brachte. Zumal das Thema ja immer wieder aufs neue aufs Tapet gebracht wird ;-) Du meinst es gibt kein Problem mit richtungsanhängigen tags, andere denken schon. Aus diesem Grund entstand mein Engagement für dieses Thema mit der Gruppierung von ways wie im Eingangsposting ausführlich geschildert. Wenn Du diese Diskussion positiv beeinflussen möchtest, bitte ich Dich, etwas konstruktiv dazu beizutragen, anstatt hier groß zu erklären, dass doch alles in Butter ist. Mache bitte gerne _diskussionslos_ so weiter wie bisher, denn im Moment gibt es eh keine andere Möglichkeit. Aber bitte demotiviere nicht andere, neue, evtl. bessere Lösungsansätze zu verfolgen. Danke für Dein Verständnis! In JOSM werden alle drei ways zu einer Gruppe zusammengefasst und mit einer Farbe hinterlegt, dass dies auch optisch für die Wahrnehmung eine Straße bleibt. Und woher weiss JOSM, dass die drei ways eigentlich ein Objekt bilden? Relation? Es steht doch da: sie werden zu einer Gruppe zusammengefasst. Diese Gruppierungsfunktion durch eine gemeinsame ID (_ähnlich_ wie bei Relationen, ist aber bei weitem nicht so aufwändig, da automatisie rt durch den Editor) die sich aus den beteiligten ways durch einen einfachen Algorithmus errechnen liese, habe ich auch schon ausführlich in me inem Startposting beschrieben. Auch wenn du es Gruppe nennst, ist es nichts anderes als eine einfache Relation. Die automatische Erstellung durch den Editor aendert daran genau nichts. Woher weißt Du dass es nichts anderes ist? Wäre das technisch die Lösung, das gewollte so umzusetzen? Dann mache doch mal einen Vorschlag, wie das auch für Spezialfälle _dieses Modells_ incl. der Möglichkeit des Fahrspurtaggings (wo nötig/ sinnvoll), die dieses Model bietet. Warum willst du was neues erfinden, wenn es genau das, was du brauchst, bereits gibt? Hmm dann nenne es eine _neue_ Relation, wenn mein Modell mit der Gruppierung technisch dasselbe wäre. Doch sollte sie so umgesetzt Erden, wie es in meinem Eingangsposting steht: benutzerfreundlich. Wie es benutzerfreundlich wäre, steht auch dort. Hmm kann ja doch noch konstruktiv werden. Hängt ein wenig von Deiner Antwort ab. Freue mich auf Deinen Vorschlag zur technischen Umsetzung _dieses_ Modells mit einer Relation, die in allen Situationen funktioniert. Für den Anfang würde mir schon reichen, wenn Du dies anhand der Beispiele zeigst, die ich in meinem (vor?)letzten Posting dazu beschrieben habe, als ich das bisherige und das tagging im neuen Modell erklärt habe. Vielen Dank im Voraus! (keine Ironie!) Gruss, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 28.07.2010 um 16:38 schrieb Simon Kokolakis: Am 25.07.2010 20:43, schrieb steffterra: - Manche versuchen das Problem zu umgehen, indem sie zwei ways für jede Fahrrichtung zeichnen, was aber nur bei baulicher Trennung korrekt wäre, und deshalb falsch ist. Das kommt auf die Interpretation des Objektes way an. Daran scheitern sich die Geister. Es scheint aber einen weltweiten Konsens darüber zu geben, dass ein way in osm eine Straße repräsentiert und eben nicht eine Fahrspur. Das ist sicher geschichtlich zu sehen, daß man froh war, dass überhaupt eine Straße eingezeichnet wurde. Daß das immer noch so gesehen wird, konnte ich in vielen persönlichen Gesprächen in unserer lokalen OSM-Gruppe und auch hier recherchieren. Hauptgrund dafür ist die visuelle Wahrnehmung des Objekts im Editor. Gestützt wird diese These auch dadurch, dass viele meinen, dass es völig ausreichend ist, alles mit tags und Relationen an _einem_ way abzubilden. Warum ist es falsch die einzelnen Elemente einer Straße als eigene oneways darszustellen? Ich erweitere obige Begründung mit dem (für mich am verständlichsten) Argument der baulichen Trennung. Im Wik ist z.B. definiert, dass bei baulicher Trennung der Fahrspuren einer Straße auch je ein way pro Fahrtrichtung gezeichnet werden _muß_. Das heisst im Umkehrschluss: Ohne bauliche Trennung: ein way. Die baulichte Trennung teilt beide Fahrrichtungen so vn einander, dass man die Trennung in der Wirklichkeit auch sehen kann, da es nicht eine durchgehende Fahrbahndecke ist, sondern ein Grünstreifen oder andere bauliche Maßnahmen vorhanden sind. Da diese Trennung der Fahrbahnen auch Verkehrsregelungen automatisch nach sich zieht (man darf und kann halt nicht mehr wenden, etc.). Wenn man nun Deiner Meinung nach grundsätzlich zwei ways zeichnen würde, dann impliziert das nicht nur die optische Wahrnehmung der baulichen Trennung, sondern erstellt nebenbei auch die Verkehrsregeln, wie wenn baulich getrennt wäre, dem aber nicht so ist, da durchgehende Fahrbahndecke. Die Folge ist, dass bei Abzweigungen und ähnlichem künstliche Verbindungen zwischen beiden Fahrspuren geschaffen werden müssten, die in der Realität so gar nicht vorhanden sind. Deshalb ein way für eine geschlossene Fahrbahndecke. Da es auch selten bauliche Trennungen zu Gehwegen und Radwegen gibt, wird hier ebenso verfahren: alles wird an dem einen way getaggt, ausser es ist ein Grünstreifen zwischen der Straße und dem Gehweg. Dann kann der Gehweg auch einzeln eingezeichnet und entsprechend getaggt werden. Im Prinzip ist dein vorgeschlagenes Modell ja nichts anderes als eine Gruppierung von einzelnen (one)ways.. Deshalb heisst mein Vorschlag ja auch so. Um aber deutlich zu machen, dass es eben keine bauliche Trennung gibt, sollte alles nicht zu per Relation oder wie auch immer in einer Gruppe zusammengefasst werden, sondern dies auch visuell im Editor für die optische Wahrnehmung mit einer gemeinsamen Hintergrundfarbe kenntlich gemacht werden. Zudem ist auch im Modell enthalten, dass zunächst immer nur der datenway sichtbar ist, da auf ihm auch die richtungsunabhängigen Tags wie die der Straßenart und des Namens liegen, was die Straße eindeutig identifiziert. Erst wenn man auf den datenway klickt gehen die anderen ways/Fahrspuren auf und man kann detaillierter bis zur Fahrspur wenn nötig fein säuberlich getrennt taggen und ist dabei völlig flexibel, da so auf einfache Weise alles abgebildet werden kann, was nötig ist. Der Editor und später auch der Renderer tragen jedoch maßgeblich dazu bei, dass eine Gruppe von ways als eine Straße und nicht als mehrere verschiedene Parallelstraßen interpretiert wird. Gegenvorschlag: Einzeichnen aller Straßenuntereinheiten (Fahrbahn, Fahrspur, Fahrradspur, Parkplätze, je nach dem wie detailliert man es will) als oneways. Wenn man unbedingt mitgeben will dass diese Elemente zusammengehören und eine (baulich ungetrennte) Straße darstellen dann gruppiert man sie in einer Relation. associatedStreet wäre da eine Möglichkeit. kann es sein, dass Du damit das Proposal der Linienbündel wiedergibst? Während dieses Threads bin ich mehrfach auf die Unterschiede meines Gruppierungs-Modells zum Linienbündel-Modell eingegangen, denn es hat auch Gründe, warum sich dieses nicht durchgesetzt hat. Und dass sind nicht der Editor und der Rednerer alleine. Danke für Dein Feedback, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz-Die Lösung
Am 26. Jul 2010 um 23:26 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com:Am 26. Juli 2010 10:35 schrieb Georg Feddern ne...@bavarianmallet.de: steffterra schrieb: Und wie wird die dann in die Area gezeichnet? ich werde JOSM benutzen.LOL, sehr schöne Antwort. Doch gemeint war nicht das Hilfsmittel noch das Gerät, sondern die Art und Weise. dafür gäbe es zwei Möglichkeiten: Entweder als Site-Relation - alle Stellplatz-Nutzer-Arten-Flächen getrennt und die Relation ergibt 'den Parkplatz'. Oder dito als Multipolygon-Relation. M.E. keine Relationen. EInfach einzeichnen und gut is. Alles andere ist totaler overkill und bringt überhaupt keine Mehrinformation. Multipolygon ist dazuhin m.E. falsch, weil es die Flächen ja ausnehmen würde. Man muss sich nur auf einen Tag verständigen und kann loslegen.Ich schlug es ja zuvor schon vor, einfach mehrere Areas für die einzelnen Parkarten zu erstellen, doch das widersprach der Meinung einiger hier, dass das die Wirklichkeit nicht richtig abbildet, da es ja _ein_ Parkplatz sei und nciht mehrere Flächen nebeneinander ... *Augenroll* Vielleicht wurde das Argument auch nur "vorgeschoben", um die Einzelnode-Tags für den Behinderten/Frauen/Eltern-parkplatz zu rechtferigen. Ich bin der Meinung, dass eng aneinander grenzende/gezeichnete Areas die Wirklich besser abbilden, als eine Area mit ungenauen Einzelnodes für die Repräsentation der Spezialparkplatz-Flächen darauf.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei forward/backward)
Am 26. Jul 2010 um 23:43 schrieb Guenther Meyer d@sordidmusic.com: Der Vorteil ist die Flexibilität ohne dabei neue Redundanz zu bilden, gleichzeitig ist das ganze abwärtskompatibel. Das ist sogar der wichtigste Punkt an der ganzen Geschichte. viele verschiedene Moeglichkeiten, die dann auch jeder Renderer und Editor beruecksichtigen muesste. DAS wird komplex.Nein, es sind ja nicht verschiedene Möglichkeiten für die gleiche Sache, denn man nutzt diejenige, für die entsprechende Anforderung. gut, auf a) kann man erst mal wegen der abwaertskompatibilitaet nicht verzichten, aber c) wuerde ich vermeiden...warum ist c) zu vermeiden (c)=Fahrspuren einer Richtung extra zeichnen, wenn die einzelnen fahrspuren jeweils eigeen richtungsabhängige z.B. maxspeed-Tags benötigen). Wenn die Fahrspuren einer richtung ebenso eigene Unterscheidungen benötigen, dann muss es so gemacht werden, so ist die Katz' wieder auf alten Füßen - nur dann halt in einer Fahrbahnrichtung. Beispiel unterschiedliche Geschwindigkeitsregelung auf einzelnen Fahrspuren der gleichen richtung, oder ein Radweg (es gibt sicher bessere Beispiele?) befindet sich zwischen zwei Fahrspuren der gleichen Richtung, etc. Hmm, jetzt faellt mir noch was ein: Eigentlich wuerden in deinem Modell zwei ways fuer die beiden Seiten reichen. eigentlich ja - doch ich wollte vermeiden, dass z.B. der name-tag an beiden ways getaggt wird, was wieder zu unnötiger Redundanz führen würde, so wie im Linienbündel-Model, das ich nicht so mag. wer sagt dir, dass die Tags nicht an alle drei ways gehaengt werden?so wie im gesamten OSM-Tagging Redundanz vermeiden sollte, so sollte das auch hier beachtet werden. Doppeltagging ist nciht nötig, schadet aber ausser in Bezug auf die Folgen der Redundanz auch nicht. Da diese sowieso in einem uebergeordneten Objekt zusammengefasst werden muessen, kann man doch die allgemeingueltigen Tags gleich da dran haengen; das Einzeichnen des Mittelweges kann man sich dann sparen... Das "da dran hängen" ist ein Problem, das Du wie lösen würdest? Ich bin gespannt, da ich gerne auf den daten-way verzichten würde. Aber bitte führe jetzt nicht die Relation als Lösung an, den die wollte ich vermeiden. Sonst könnte man gleich beide Fahrtrichtungen mit Relationen erfassen und alle richtungsabhängigen tags da dran pappen im Prinzip ist das Ganze sowieso nichts anderes als eine Art von Relation. Du hast ein Hauptelement, das fuer das Strassenobjekt selbst steht und sowohl die allgemeinen Tags enthaelt, als auch die ways miteinander verbindet. Dieses Element jetzt auch noch als way separat in die Mitte reinzumalen, ist total ueberfluessig.wie gesagt, ich würde auch gerne darauf verzichten. doch das ist eine Lösung, mit der man echt gut leben könnte. Außerdem wollten wir Relationen vermeiden, sonst könnte man gleich alle Richtungsabhängigen Tags in Relationen unterbringen. Dann bräujchten wir das einfachere Tagging-Konzept nicht. ... schon klar. Im Prinzip laeuft alles auf das fehlerhafte Drehen eines ways zurueck. Aber warum was neues gross und aufwendig ausarbeiten, wenn man genausogut die Ursache des Uebels anpacken kann? Und wie? wie bereits gesagt: ein way bekommt beim Anlegen eine Richtung, und die bleibt unveraenderlich so wie sie ist. Wenn die Editoren diese Referenzrichtung und das Drehen des Weges gar nicht erst anzeigen/anbieten, dreht die auch keiner. Und wenn sich die Richtung einer Einbahnstraße ändert, oder man überhaupt erst eine taggen möchten, owowohl es vorher keine war? ganz einfach, indem man in der Darstellung der Strasse im Editor diese selektiert, die Eigenschaft "Einbahnstrasse" waehlt, und dann die Richtung "von hier nach da" angibt. Der Editor setzt dann automatisch das richtige Tag (irgendwas mit oneway:forward oder oneway:backward, je nachdem wie die Referenzrichtung ist). Was letztendlich getaggt wird, kann dem User egal sein, er sieht ja in der Darstellung, in welche Richtung es geht. Wie waer's wenn du mal ein Beispiel anhand einer typischen Strasse einfach mal modellierst und als OSM-Datei zur Verfuegung stellst? Kann ich machen Komme aber erst gegen Mitte der Woche dazu. Danke für den Vorschlag sehr schoen. ich bin gespannt... Mal sehen, wie ich das machen kann, Sachen abzubilden, die es noch nicht gibt. Ich versuche auch die kritischen Dinge wie Kreuzungen und Kreisverkehre hinzubekommen. Aber ganz ohne manuellem Zeichnen wird es nicht gehen. Mal sehen ich denke mit josm laesst sich das recht gut machen. noch was: ist es eigentlich Absicht, dass dein Mailclient kein Quoting macht? Das macht deine Posts stellenweise etwas schwer lesbar...natürlich quotet mein Client. Warum siehst Du es nicht? Ich denke eher, dass Dein client nur Deine Quotes kennt, denn wenn Du rezitierst, wird mein Quoting auch rausgelöscht. Schick mir mal bitte einen Screnshot per email. Danke.___ Talk-de mailing list
Re: [Talk-de] Radweg oder nicht Radweg?
Am 27. Jul 2010 um 10:16 schrieb Chris66 chris66...@gmx.de:Am 26.07.2010 21:06, schrieb steffterra: Ein Fußweg über den mehrere Radrouten (u.A. der Werseradweg) führen. LOL. Also ich würde es Fahrradfahrerfreundlich machen und die Stadt bitten, das zu Schild dranzupappen, Done. Da der Weg durch einen dunklen Tunnel führt wäre die Umleitung über das Wohngebiert aber nicht unbedingt als radlerunfreundlich zu bezeichnen. ;-)Ich sagte ja, auch er solle es fahrradfahrerfreundlich machen deshalb war die Version ja auch nicht gemeint. ;-)steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 27. Jul 2010 um 10:30 schrieb Falk Zscheile falk.zsche...@googlemail.com:Am 26. Juli 2010 20:30 schrieb Guenther Meyer d@sordidmusic.com: left/right waere generell besser verwendbar als forward/backward, einfach weil es eindeutiger und universeller verwendbar ist. Das sehe ich genau anders herum: forward/backward bezieht sich direkt auf die vom Element vorgegebene Richtung. Bei left/right muss man zuerst nach der Richtung des Weges schauen und erst darauf kann man dann rechts/links beziehen. Es ist also ein zusätzlicher Gedankenschritt nötig, ohne dass ich einen Vorteil von diesem erkennen kann.Ich sehe das auch so, aber egal. Wegen all dieser Probleme habe ich derzeit eine diskussion um ein alternatives Modell zum Taggen von richtungsabhängigen Tags in folgendem Threrad vorgestellt:"Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)"Pro-Tip: Am besten erst das Eingangsposting in Ruhe durchlessen - hat sich bewährt. Würde mich über Teilnahme an der Diskussion freuen. steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 27. Jul 2010 um 13:59 schrieb Guenther Meyer d@sordidmusic.com:On Tue, Jul 27, 2010 at 10:30:08AM +0200, Falk Zscheile wrote: Am 26. Juli 2010 20:30 schrieb Guenther Meyer d@sordidmusic.com: left/right waere generell besser verwendbar als forward/backward, einfach weil es eindeutiger und universeller verwendbar ist. Das sehe ich genau anders herum: forward/backward bezieht sich direkt auf die vom Element vorgegebene Richtung. Bei left/right muss man zuerst nach der Richtung des Weges schauen und erst darauf kann man dann rechts/links beziehen. Es ist also ein zusätzlicher Gedankenschritt nötig, ohne dass ich einen Vorteil von diesem erkennen kann. Beispiel: ein way verlaeuft von Sueden nach Norden, also der Einfachheit halber von unten nach oben. left ist die linke Seite, also auf der westlichen Seite. right ist die rechte Seite, also auf der oestlichen Seite. Soweit so gut.Nein, nichts ist gut. Es ist nur rechts, wenn du von unten nach oben gehst ;-) Wenn du aber von oben nach unten gehst, ist rechts auf der anderen Straßenseite. Kann ich dasselbe mit forward/backward ausdruecken? Mal schaun: forward ist hier die rechte, oestliche Seite. backward ist hier die linke, westliche Seite. auch ok. Aber was, wenn jetzt ein Brite dieses Tagging auswerten will? Dann ist forward ploetzlich die linke, und backward die rechte Seite... Links und rechts dagegen bleibt links und rechts.und backward ist in GB genauso backward, wie in de ;-)Das GB-Argument hinkt, weil Du ja kein backward daran festmachst, auf welcher Straßenseite man fährt. left/right sagt aus, dass es rechts auf der Straße ist, wenn man die gleiche Richtung nimmt, wie die way-Richtung eingezeichnet ist.Das hat doch nixhts damit uzu tun, auf welcher Straßenseite man fährt ;-)Und forward heisst letztendlich das gleiche: es beduetet, wenn man sich in die gleiche richtung fortbewegt, wie die, in die der way eingezeichnet ist. backward geht entgegen dieser Richtung.Ich habe es immer so verstanden: - left/right sagt aus, auf welcher Straßenseite sich etwas auf der Straße befindet- forward/backward sagt aus, in welcher Richtung etwas liegt. Also in Einzeichenrichtung des ways und entgegen der Einzeichenbrichtung des ways.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 27. Jul 2010 um 14:33 schrieb Falk Zscheile falk.zsche...@googlemail.com:Am 27. Juli 2010 14:24 schrieb steffterra steffte...@me.com: Ich habe es immer so verstanden: - left/right sagt aus, auf welcher Straßenseite sich etwas auf der Straße befindet - forward/backward sagt aus, in welcher Richtung etwas liegt. Also in Einzeichenrichtung des ways und entgegen der Einzeichenbrichtung des ways. Ah, jetzt verstehe ich den Hintergrund der Differenzierung. left/right ist gibt die Lage von Elementen neben der Straße an und forward/backward von Dingen auf der Straße. Beides in Bezug auf die Richtung, welche die Straße in den Daten hat.Nein ;-) Ich schrieb _auf_ der Straße. Das erste sagt wo es _auf_ der Straße ist (linke oder rechts Seite darauf, nicht daneben, denn es ist ja ein Tag der Straße und nicht von dem was daneben ist.)das zweite sagt, in welcher richtung es liegt - in Richtung der Straße oder in der Gegenrichtung der Straße...*grumml* :-)steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
!) - in meinem Modell: -way (außen eingezeichnet Nord-Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated -way (innen eingezeichnet Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd-Nord): maxspeed=50 Beispiel 5: die gleiche Straße bekommt in Süd-Nord-Richtung eine zweite Spur auf die gesamte Länge (Also _keine_ Abbiegespur, sondern eine normale Spur!) der Beispielstraße, die aber nach einer bestimmten Strecke in einem großen Bogen auf die Bahnhofstraße als neue Fahrspur dort einmündet. Ein Stück vor der baulichen Trennung beginnt bereits auf der Beispielstraße eine Geschwindigkeitsreduzierung auf 40 km/h. - bisher würde ab dem node, wo der Bogen beginnt (als ab dem Punkt, wo sich die Spur von der Straße baulich trennt) eine neuer way gezeichnet werden, der Die Verbindung zu der anderen Straße herstellt. Doch man kann weder aus dem tagging, noch aus dem eingezeichneten way erkennen, - Das tagging würde _derzeit_ wegen der zusätzlichen Fahrspur so aussehen: highway=secondary name=Beispielstraße maxspeed:forward=60 maxspeed:backward=50 destination:forward=München destination:backward=Hamburg lanes=4 (oder auch lanes:forward=2, lanes:backward=2) cycleway:right=lane bicycle=designated - ab dem node, wo die Geschwindigkeitsbegrenzung der äußeren Fahrspur beginnt würde _derzeit_ es so aussehen: highway=secondary name=Beispielstraße maxspeed:forward=60;40 -- da ist das Problem, für das es noch keine Lösung gibt ;-) maxspeed:backward=50 destination:forward=München destination:backward=Hamburg lanes=4 (oder auch lanes:forward=2, lanes:backward=2) cycleway:right=lane bicycle=designated - in meinem Modell könnte es so aussehen: bis zu dem Punkt, wo die Fahrspur eine eigene Geschwindigkeitsbegrenzung bekommt: -way (außen eingezeichnet Nord-Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated -way (innen eingezeichnet Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (innen eingezeichnet Süd-Nord): maxspeed=50, destination=Hamburg -way (außen eingezeichnet Süd-Nord): maxspeed=50,destination=Bahnhof (man könnte auch überlegen bis hierher noch mit einem way in Süd-Nordrichtung zu arbeiten und mit tag lanes=2, verzichtet dann aber auf den u.U. sinnvollen frühen Hinweis der Bahnhofsrichtung) ab dem Punkt der Geschwindigkeitsbegrenzung: -way (außen eingezeichnet Nord-Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated -way (innen eingezeichnet Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (innen eingezeichnet Süd-Nord): maxspeed=50, destination=Hamburg -way (außen eingezeichnet Süd-Nord): maxspeed=40, destination=Bahnhof ab dem Punkt, wo die bauliche Trennung des äußeren way der Süd-Nord-Richtung beginnt (der äußere way wird weiter gezeichnet, aber ab diesem node aus der Gruppierung genommen: -way (außen eingezeichnet Nord-Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated -way (innen eingezeichnet Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd-Nord): maxspeed=50, destination=Hamburg nach der baulichen Trennung, also außerhalb der Gruppe wird die ehemalige Fahrspur der Beispielstraße zu einer eigenständigen (Einbahn-)Straße als einzelner JOSM-way wie in Beispiel 1.: highway=secondary oneway=yes destination_ref=Bahnhofstraße maxspeed=40 destination=Bahnhof - Puh ... Ich hoffe, ich habe keinen Zahlendreher oder sowas drin und glaube auch dass alle Standard-tags stimmen. Ich glaube dass diese Beispiele gut zeigen können, was das Modell leisten kann und dass nun auch klar wird, wann die ways einer Gruppe (also sprich einer Straße) nur die Fahrtrichtungen repräsentieren und ab wann sie als einzelne Fahrspuren genutzt werden dürfen, können und dann auch müssen. Auch hier bitte ich Euch, das noch einmal in Ruhe auf Euch wirken zu lassen und dann nochmal in ruhe durchzulesen, und es auch evtl. auf einem Blatt Papier mal nachzeichnet. Ich arbeite bereits an den Graphiken, die auch andere Beispiel wie Kreuzungen enthalten, weiß aber nicht, ob ich es bis zur Wochenmitte schon fertig bekomme, Danke vielmals für Eure Geduld mit meinen manchmal argen Tippfehlern. :-) Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 27.07.2010 um 23:27 schrieb Guenther Meyer: [..viele Beispiele...] ich muss mir das Ganze nochmal genauer anschauen, aber abgesehen von der Losloesung von der Richtungsabhaengigkeit was aus meiner Sicht ein rieeesen Vorteil ist. Die anderen sind die Abwärtskompatibilität und vor allem die Ermöglichung von Fahrspurtagging, was für kommende OSM-Anwendungen enorm wichtig werden wird, wenn man zu den großen und kommerziellen konkurrenzfähig sein möchte. Vor allem im Navigationsbereich wären diese Vorteile sehr wünschenswert und eine sicherere Methode mit weniger Fehlerquellen. sehe ich im Moment nicht wirklich Vorteile - und wesentlich einfacher wird's auch nicht. Wenn man alle Aspektev mit einbezieht eben schon. Vergleiche einfach mal die nötigen Tags in den Beispielen. Ist doch wesentlich klarer als die Latte an einem way, der dann ncoh die Gefahr birgt durch ein einfaches Drehen des way komplett über den Haufen geschmissen zu werden. Aber das wurde auch alles schon einmal besprochen. In JOSM werden alle drei ways zu einer Gruppe zusammengefasst und mit einer Farbe hinterlegt, dass dies auch optisch für die Wahrnehmung eine Straße bleibt. Und woher weiss JOSM, dass die drei ways eigentlich ein Objekt bilden? Relation? Es steht doch da: sie werden zu einer Gruppe zusammengefasst. Diese Gruppierungsfunktion durch eine gemeinsame ID (_ähnlich_ wie bei Relationen, ist aber bei weitem nicht so aufwändig, da automatisiert durch den Editor) die sich aus den beteiligten ways durch einen einfachen Algorithmus errechnen liese, habe ich auch schon ausführlich in meinem Startposting beschrieben. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf rechter und?linker Seite
Am 27.07.2010 um 16:51 schrieb Tobias Knerr: Am 27.07.2010 16:25, schrieb Guenther Meyer: Ich sage, vergesst forward/backward und benutzt nur noch left/right, das ist eindeutig, und v.a. einfacher. Das geht aber nicht: Die beiden Begriffspaare bezeichnen völlig unterschiedliche Konzepte, sie sind nicht austauschbar. In Fällen, wo man forward/backward verwendet, kann man ohne Bedeutungsunterschied nicht left/right verwenden - und umgekehrt. Das Treppengeländer ist nun mal rechts, nicht vorwärts. Das Laufband bewegt sich vorwärts, nicht links oder rechts. Beide Angaben nehmen Bezug auf die Richtung des OSM-Ways, aber sind inhaltlich unterschiedlich. +1 steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-1?q?_forward/backward?=)
Am 26. Jul 2010 um 08:19 schrieb Guenther Meyer d@sordidmusic.com:Am Montag 26 Juli 2010, 00:39:36 schrieb steffterra: Am 25.07.2010 um 23:47 schrieb Guenther Meyer: Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: Doch die Parkspur ist ein Attribut eines Teils der Strasse (wenn man mal so ein Modell vorraussetzt), und damit muss irgendwie bezeichnet werden, auf welcher Seite sie sich befindet. +1 Die Fahrspur könnte z.b. nur in einer Fahrtrichtung vorhanden sein. Doch auf welcher? Das tagt man halt auf dem way der Richtugnsfahrspur, zwischen den nodes wo er vorhanden ist: parking:lane capacity:disabled:2 Dafuer braucht man nunmal irgendeine Art der Richtungsangabe. Nur sehe ich die hierfuer notwendige Richtung als total abstrakt an, z.B. angelegt wie die Strasse gezeichnet wurde. Die Richtung wohin die Fahrspur führt, ist tatsächlich egal für die Parkpsur. Doch man legt am way der Seite der Straße den tag an, wo die Parkspur tatsächlich vorhanden ist. Das erfordert aber wieder dieses Linienchaos, das doch so unuebersichtlich ist...Was meinst du mit "Linien"-Chaos - Es sind doch nur drei Linien in JOSM (und eine Linie im Renderer):1. Linie (way): die eine Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist.2. Linie (way: der daten-way: hier wird alles draufgetaggt, was _nicht_ richtungsabhängig ist, wie z.b. name + ref-Tag3. Linie (way): die entgegen gesetzte Fahrtrichtung:hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist.Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur.Doch es ist nicht grundsätzlich gedacht, dass man Fahrspuren taggt, wo es vom Tagging her gar nicht nötig wäre. Und vom Tagging her ist es nur dann nötig, wenn Tags nur in einer Richtung gelten, oder sie sich Tag für die gleiche Richtung unterscheiden. (Beispiel: innere Spur der einen Richtung maxspeed=50, äußere Spur der gleichen Richtung maxsped=40, Gegernrichtung beide Spuren: maxspeed=80, also dort nur ein way und lanes=2) Es waere also toericht, hier - egal, ob man nun Relationen oder Tags oder sonst was benutzt - in irgendeiner Form einen Bezug zur Richtung der Strasse herzustellen; man erzeugt damit voellig unnoetige Probleme. Genau diese Probleme will die Gruppierung ja verhindern, weil so genau festgelegt wird, an welchem way, also auf welcher Straßenseite welche Dinge vorhanden sind. Wie z.b. Radweg, usw. (Das ist übrigens der Unterschied zum wesentlich komplizierter zu zeichnenden Linienbündel, da wir ausreichend tags haben, um alle Arten von Radwegen, Parkständen, etc. am way zu taggen. Das einzige Problem hierbei ist aber durch die Gruppierung nicht mehr vorhanden und damit das Ziel derer errreicht: die richtugnsabhängigen Unterschiede liegen nun auf den einzelnen ways der Straßenseite, wo in Wirklichkeit vorhanden sind. was genau willst du eigentlich? So wie ich das verstehe, willst du, dass jeder Teil (Strasse, Fussweg, Fahrradweg) separat als way eingezeichnet wird, um diese dann irgendwie zusammenzufassen.Sorry, aber lies meine erste Mail zu dem Thema nochmal in Ruhe durch. Dann weisst Du, was ich möchte. Danke vielmals für die Aufmerksamkeit ;-) Ich denke mir shcon die ganze Zeit, dass Du es komplett nicht verstanden hast, was die Gruppierung möchte.Gerne erkläre ich es dfir aber auch mal seperat per email, dass wir den Thread nciht unnötig zumüllen, weil es andere längst verstanden haben. Kann ja vorkommen, kein Problem, aber dann nicht hier nochmal alles von vorne durchkauen bitte, wenn man es im ersten Post nachlesen kann.Ich praeferiere eher den Ansatz, dass eine Strasse prinzipiell nur aus einem way besteht, der die zusaetzlichen Wege - genauso wie die Anzahl der Fahrspuren - als Attribute bekommt.Dann hats Du wieder das Problem, weshalb ich ja eben nciht alles auf einem way haben möchte: bei Fahrtrichtungsabhängigen Tags (weisst Du überhaupt was damit gemeint ist? Also z.b. ein maxspeed gilt nur in einer richtung udn in der andreren eine andere maxseed, oder ein Radweg ist nur in einer Richtung, sprich auf einer Straßenseite, oder er ist auf beiden seiten da und nur auf einer ist er mit den Fußgängern zusammen, etc.)Deshalb ja die Gruppierung der einzelnen ways (s.o.), dass man weiss, dass alles zu einer Straße zusammen gehört. Es sollte ja im Editor auch farblich zusammengelget werden, dass die Wahrnehmung nciht leidet wie im jetzigen Editor, wenn Fahrspuren einzeln gezeichnet würden (was man derzeit nicht soll) aber ich wiederhole mich. Bitte lies mein erstes Post dazu. Danke.Bitte nimm Dir die Zeit, sonst fehlt Dir jede Diskussionsgrundlage und wir drehen uns hier im Kreis.steffterraP.S. Es wäre sehr schade, wenn das Thema zerredet würde.
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 14:26 schrieb Andreas Tille andr...@an3as.eu:Hi, ich war gestern in einem Dorf, in dem es eine Straße gibt, die auf der linken Straßeseite "Amtshof" und auf der rechten Straßenseite "Am Schmiedeteich" heißt. Die Straßenschilder sind echt so vorhanden (Fotos verfügbar) und eine Kollegin wohnt auch in dieser Straße (auf der rechten Seite, also "Am Schmiedeteich" ;-)) und hat meine Beobachtung inhaltlich bestätigt. Bisher kannte ich immer nur Straßen, die in der Länge unterschiedliche Namen hat und nicht auf unterschiedlichen Straßenseiten. Es handelt sich um eine ganz gewöhnliche Dorfstraße ohne jegliche Trennung in der Mitte. Kann man diese Situation irgendwie geeignet abbilden? In diesem Zusammenhang vielleicht ganz witzig: GMaps erfindet hier gleich eine Straße durch die anliegenden Gärten: http://maps.google.de/?ie=UTF8ll=51.890996,10.765185spn=0.001468,0.004085t=hz=18 :-) Wie jeden fahrtrichtungsabhängigen Tag am Straßenway: derzeit mit backward/forward (in Bezug auf die Einzeichnungsrichtung im Editor) oder left/right (ebenfalls dazu bezugnehmend). Da beides keine wirklich gute Lösung darstellt (der way könnte sehr leicht im Editor gedreht werden mit fatalen Auswirkungen), könnte man für jede Fahrtrichtung eine Relation erstellen, die dann den name-Tag jeweils passend für jede Richtung enthält. Aber auch das ist eigentlich keine _sehr_ gute Lösung. Ich bevorzuge dennoch _derzeit_ die erste, weil leichter nachzuvollziehen und eine Relation durch Umbaumaßnahmen am way deutlich schneller kaputt geht, als tags, die automatisch bei Trennung am Node in den neuen way kopiert werden.Derzeit wird das Einzeichnen von ways für jede Fahrtrichtung und anschließender Zusammenfassung zu einer Gruppe (dann in Gesamtheit als _eine_ Straße erkennbar) diskutiert. Dann wäre es möglich je einen way für jede Fahrspur der beiden Richtungen zu zeichnen und an den einen way der einen Richtung den einen Name-tag zu schreiben und in der Gegenrichtung am anderen way den anderen Namen. Aber das ist derzeit noch nicht möglich, da die Gruppierungsmöglichkeit im Editor und der Datenbank fehlt.Frage: besteht eine bauliche Trennung für jede Seite der Straße? Dann dürftest Du sowieso für jede Richtung einen eigenen way zeichnen, den Du dann einfach mit dem entsprechenden Namen versiehst.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und?linker Seite
Am 26. Jul 2010 um 15:06 schrieb Sven Geggus li...@fuchsschwanzdomain.de:Andreas Tille andr...@an3as.eu wrote: Kann man diese Situation irgendwie geeignet abbilden? Zweimal Straßen über die selben Nodes eventuell oneway? Gerendert wird dann natürlich Unfug. Unabhängig vom Renderer (für den wir es ja nicht machen ;-) ist das keine gute Idee, da schlecht erkennbar, geschgweige denn gescheit auswählbar. Widerspricht allem, was man mal als OSM-Anfänger gelernt hat ;-)steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 15:42 schrieb Tobias Knerr o...@tobias-knerr.de:Am 26.07.2010 14:57, schrieb Stefan Dettenhofer (StefanDausR): Andreas Tille schrieb: in dem es eine Straße gibt, die auf der linken Straßeseite "Amtshof" und auf der rechten Straßenseite "Am Schmiedeteich" heißt. Ich würde es so wie hier vorgeschlagen machen: http://lists.openstreetmap.org/pipermail/talk-de/2010-February/062881.html oder alternativ statt name:left= und name:right= besser sogar so mane:forward= und name:backward= Ich würde name:left= und name:right= verwenden. Was hat das denn mit forward und backward zu tun? Wenn ich mich auf dem Bürgersteig umdrehe, ändert das den Namen meiner Straßenseite?backward/forward ist in Bezug auf die Einzeichenrichtung in JOSM gemeint. So wie left/right ja auch, denn von wo aus ist denn Dein Links, das jemand anderes sieht, der aus der anderen Richtung kommt. richtig: rechts? Und woher will der, der die OSM-Daten ausliest nun wissen, aus welcher richtung kommend rechts rechts ist und links links? Verstehst Du das Problem? Beide Tagvarianten beziehen sich _immer_ auf die richntung, wie der way in JOSM angezeigt wird/gezeichnet wurde.Deshalb ways mit dieses Tag niemals drehen Oder man weiss was man tut und hat gute Ortskenntnisse das im Zweifelsfall wieder hinzubekomnmen, wenn man falsch gedreht hat ;-)steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 15:47 schrieb Tirkon tirko...@yahoo.de:Andreas Tille andr...@an3as.eu wrote: ich war gestern in einem Dorf, in dem es eine Straße gibt, die auf der linken Straßeseite "Amtshof" und auf der rechten Straßenseite "Am Schmiedeteich" heißt. vielleicht name=Amtshof; Am SchmiedeteichDas ist dei einfachste Möglichkeit, wobei hier nicht abgebildet wird, auf welcher Straßenseite welcher Straßenname der beiden gilt.Das versuchst Du indirekt im zweiten Schritt:und dann mit der Interpolationslösung die Adressen auf beiden Seiten mit den unterschiedlichen Straßennamen eintragen. http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Mehrere_H.C3.A4user_an_einer_Stra.C3.9Fe_.28Interpolation.29Das Problem ist aber auch hier: wenn man die Adressen nicht beachten sollte (egal ob als Relation, als Interpolation oder an einzelnen Häusernodes mit allen addr:Tags voll eingetragen), dann weiss man vom way her gesehen nur, dass er beide Namen trägt, nicht aber welche Straßenseite welchen Namen hat.Da man aber im Allgemeinen nicht nach der richtigen Straßenseite direkt sucht, sondern eine Adresse sucht und dann schaut, auf welcher Straßenseite sich diese befindet, ist es durch die Adressen auch ausrewichend plausibel, oder?steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Könntet Ihr das Thema "Miniplanet" bitte in einem eigene mail-Thread besprechen? Das hat nur weit am Rande etwas mit dem Thema der Gruppierung von Ways zu tun. Danke fürs Verständnis!steffterraAm 26. Jul 2010 um 16:46 schrieb Tirkon tirko...@yahoo.de:Frederik Ramm frede...@remote.org wrote: Ausserdem ist so ein "Miniplanet" beileibe kein Wundermittel - der Vorschlag, der hier von "steffterra" als, wie Du sagst, "Textwueste" unterbreitet wurde, wuerde mit oder ohne Miniplanet Wochen konzentrierter Arbeit brauchen, um ihn zur Demonstrationsreife zu bringen (Aenderungen an Renderern und Editoren!). Jemand, der *das* kann, der kann auch schnell noch eine Rails-API gemaess Wiki-Anleitung aufsetzen, der braucht keinen "Miniplanet". In einer ersten Phase geht es erst einmal darum, einfach dasselbe vorzufinden, was man auch auf der Originalkarte hat. Das würde für viele Zwecke schon reichen. z.B. Anfänger, Schulung, Demonstrationen, Wiki-Illustrierung etc. - oder z.B. für den derzeitigen PLZ-Import üben, ohne das man Gefahr läuft, etwas zu beschädigen. Die tatsächliche Änderung von Apis, Renderern oder Ahnlichem zu testen, wäre dann schon sehr advanced fortgesponnen und erst in einem Stadium denkbar, wenn sich die "einfache" Version etabliert hat. Dann kann man immer noch weiter sehen. Und auch auf der einfachen Oberfläche kann man gemeinschaftlich ein neues System ausprobieren, ohne dass es anders als normal gerendert wird. Wenn man dort beginnt, verschiedene Situationen durchzumappen, merkt man auch ohne neuen Renderer, dass es noch hier und dort kneift und die Textwüste noche einer Änderung bedarf. Z.B. kann jemand hier ein Beispiel hinterlassen, wo es eben kneift und den anderen dort zeigen. Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. Meiner Ansicht nach wuerde ein "Miniplanet" die Gefahr mit sich bringen, dass Leute ausprobieren, wie bestimmte Sachen im Rendering aussehen, und dann ihre Tagging-Entscheidungen danach richten... Wenn es um Tagging Entscheidungen geht, dann geht es auch um etwas real Existierendes. Und das künnte man auch in normalen Karte mappen und ausprobieren. Damit könnten also die Außerirdischen vom Miniplaneten die Erde nicht überfallen. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Wie schon an anderer Stelle bemerkt würde ich mich freuen, wenn ihr das Thema "Minioplanet" ein einem eigenen Thementhread forsetzen könntet. Danke vielmals. cutpaste fürs Zitieren hilft ;-)steffterraAm 26. Jul 2010 um 17:43 schrieb Frederik Ramm frede...@remote.org:Hallo, Tirkon wrote: Ich denke mal, dass es unmöglich ist, auf der Originalkarte dafür einen verlassenes Plätzchen zu bekommen, oder? Das würde nämlich Einiges vereinfachen. Das ist in der Vergangenheit immer scharf kritisiert worden, wenn Leute das gemacht haben. Es gibt natuerlich api06.dev.openstreetmap.org, wo man sich leicht einen Account holen und herumspielen kann. Man kann da auch mal eben ein kleines Dorf selber hochladen zum Spielen, aber dazu muss man natuerlich ein bisschen mit dem Editor tricksen. Vielleicht sollte man mal ganz klein anfangen und eine Webseite machen, mit der man einen kleinen Datenbereich vom echten Server auswaehlen und auf api06.dev einspielen kann... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei forward/backward)
Am 26. Jul 2010 um 20:25 schrieb Guenther Meyer d@sordidmusic.com:Am Montag 26 Juli 2010, 17:29:22 schrieb steffterra: Was meinst du mit "Linien"-Chaos - Es sind doch nur drei Linien in JOSM (und eine Linie im Renderer): 1. Linie (way): die eine Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist. 2. Linie (way: der daten-way: hier wird alles draufgetaggt, was _nicht_ richtungsabhängig ist, wie z.b. name + ref-Tag 3. Linie (way): die entgegen gesetzte Fahrtrichtung: hier wird alles draufgetaggt, was _nur in dieser Fahrtrichtung_ vorhanden ist. ok, so kannst du dir natuerlich die Richtung sparen. Nur hast du damit im Editor durch die drei ways auch automatisch eine Ausdehnung, die nicht unbedingt der Realitaet enspricht (tut sie sowieso nicht, aber eine schmale Strasse bringst du dann evtl nicht mehr zwischen den angrenzenden Haeusern/POIs durch.Daran habe ich auch gedacht. In JOSM sollte erstmal nur der Datenway zuu sehen sein. Und nur, wenn man auf ihn klickt, dann gehen die beiden ways links und rechts davon "auf". Wenn man wieder woanders hinklickt, geht es wieder "zu" bzw. zurück. Da es nur für Straßen gedacht ist, diue richtungsabhängige Tags benötigen (und das ist sicher nicht die Masse), könnte man auf diese Weise an die Stellen "hineinschauen", die einen interessieren.Aber man koennte sich doch die drei ways sparen, und das ganze genau so auf einem way abbilden. Klar braucht man da eine Richtung, und drehen muss die auch keiner.Dann hast Du das jetzige OSM. Was willst Du mir damit sagen? Das man einfach die Tags drehen kann, das ist ja das Problem. Sie aber zu sperren in irgendeiner Form ist eben aber auch keine Lösung, das hat der Thread auch gezeigt. Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur. muss man nicht. Ausserdem hast du dann wieder eine Mischloesung...Nein, was ist denn gemischt? richtungsabhängige tags gibt es dann offiziell nicht mehr, weil dann die Gruppierten ways für die Richtungsabbildung zuständig ist, die das viel besser maschinen- udn menschenlesbar abbildet. Doch es ist nicht grundsätzlich gedacht, dass man Fahrspuren taggt, wo es vom Tagging her gar nicht nötig wäre. Und vom Tagging her ist es nur dann nötig, wenn Tags nur in einer Richtung gelten, oder sie sich Tag für die gleiche Richtung unterscheiden. (Beispiel: innere Spur der einen Richtung maxspeed=50, äußere Spur der gleichen Richtung maxsped=40, Gegernrichtung beide Spuren: maxspeed=80, also dort nur ein way und lanes=2) laesst sich alles als Attribut auf einem way abbilden.Ja, aber das Grundproblem, warum ich dieses konzept entwickelt habe ist dennoch vorhanden: jemand dreht den way und jemand tagg danach nochmal was richtugnsabhängiges ... Da ist mehr Chaos vorprogrammiert, als wenn alles sauber auf seiner Fahrspur als normaler tag angelegt ist. Denn dann ist es egal, wie der way (respektive die Way-Gruppe) gedreht ist. Denn der tag ist auf der Spur, die es betrifft. fertig - ohne Zusatztag für die Richtung, weil das ja dann hinfälllig ist, verstehst Du?Aber davon abgesehen, was wäre denn Deine Lösung, oder ist Deine Diskussionsgrundlage, dass es nichts zu diskutieren gibt, weil du mit backward/forward und left/right keine Probleme siehst wie ich?Aber egal wie man das auf der Datenbasis modelliert, letztendlich bleibt es sowieso am Editor haengen, das entsprechen editierbar darzustellen.es muss in geeigneter Weise umgesetzt werden um auch Deinem berechtigten Kritikpunkt der Wahrnehmung der Ausdehnung der Straße genüge zu tun Deshalb ja mein obiger Vorschlag zur Umsetzung im Editor.Rendern laesst sich sowas vielleicht noch, aber spaetestens bei der Graphenbildung fuer's Routing wird's komplex wuerde ich vermuten...Schön, dass Du aufs Routing zu sprechen kommst. Routing kann diese Datenbsasis ideal zum fahrspurgenauen Routen zB. an neuraligschen Stellen nutzen. Das ist ein sehr postitiver Nebeneffekt und keineswegs ein Nachteil. Ganz im Gegenteil! Genau diese Probleme will die Gruppierung ja verhindern, weil so genau festgelegt wird, an welchem way, also auf welcher Straßenseite welche Dinge vorhanden sind. Wie z.b. Radweg, usw. (Das ist übrigens der Unterschied zum wesentlich komplizierter zu zeichnenden Linienbündel, da wir ausreichend tags haben, um alle Arten von Radwegen, Parkständen, etc. am way zu taggen. Das einzige Problem hierbei ist aber durch die Gruppierung nicht mehr vorhanden und damit das Ziel derer errreicht: die richtugnsabhängigen Unterschiede liegen nun auf den einzelnen ways der Straßenseite, wo in Wirklichkeit vorhanden sind. Besser als die urspruengliche Idee des Linienbuendels ist dein Vorschlag allemal ;-)Na Danke. Das ist do
Re: [Talk-de] Radweg oder nicht Radweg?
Am 26. Jul 2010 um 20:34 schrieb Chris66 chris66...@gmx.de:Moin, Diesen Fall hatte ich heute: http://www.openstreetmap.org/?lat=51.92061lon=7.69835zoom=17layers=Mgt; Ein Fußweg über den mehrere Radrouten (u.A. der Werseradweg) führen. In OSM ist er zusätzlich zum hw=footway mit cycleway=yes getaggt. Nun frage ich mich, sollte ich hier lieber die Stadt Münster anschreiben, dass sie ein Radfahrer-frei Schild dort anpappen mögen, oder die Verantwortlichen für die Radrouten, dass sie den Weg umlegen sollen? ;-)LOL. Also ich würde es Fahrradfahrerfreundlich machen und die Stadt bitten, das zu Schild dranzupappen, da es ja schließlich ein viel genutzer offizieller Weg für Radwege zu sein scheint.Fals das auf Widerstand stösst, erfähjrst Du ja vlt. auch gleich, warum Radfahgrer da eigentlich verboten sind und kannst auf die Radfahrer mit einer Unterschriftensammlung zugehen.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straße mit unterschiedlichen Namen auf r echter und linker Seite
Am 26. Jul 2010 um 20:39 schrieb Tirkon tirko...@yahoo.de:steffterra steffte...@me.com wrote: vielleicht name=Amtshof; Am Schmiedeteich Das ist dei einfachste Möglichkeit, wobei hier nicht abgebildet wird, auf welcher Straßenseite welcher Straßenname der beiden gilt. Das versuchst Du indirekt im zweiten Schritt: und dann mit der Interpolationslösung die Adressen auf beiden Seiten mit den unterschiedlichen Straßennamen eintragen. http://wiki.openstreetmap.org/wiki/Proposed_features/De:Hausnummern#Mehrere_H.C3.A4user_an_einer_Stra.C3.9Fe_.28Interpolation.29 Das Problem ist aber auch hier: wenn man die Adressen nicht beachten sollte (egal ob als Relation, als Interpolation oder an einzelnen Häusernodes mit allen addr:Tags voll eingetragen), dann weiss man vom way her gesehen nur, dass er beide Namen trägt, nicht aber welche Straßenseite welchen Namen hat. Da man aber im Allgemeinen nicht nach der richtigen Straßenseite direkt sucht, sondern eine Adresse sucht und dann schaut, auf welcher Straßenseite sich diese befindet, ist es durch die Adressen auch ausrewichend plausibel, oder? Für das Mappen der Adressen gibt es eigentlich keine Alternative: Straße + Hausnummer. Bleibt nur noch der Straßenname zu diskutieren. Der Straßenkörper in seiner Gesamtbreite - und nicht eine irgendwie geartete Hälfte davon - ist Zuwegung für die Adressen mit beiden Straßennamen. Ich fahre durchaus auch rechts, um die linke Seite zu erreichen und umgekehrt. Daher ist die Zuteilung beider Namen gerechtfertigt. Möglicherweise waren es in der Vergangenheit wirklich zwei Wege, die zu einer Straße vereinigt wurden. Dann wäre das sogar durch die Historie gestützt. Was links oder rechts von der Straße passiert, mappe ich dort, nicht auf der Straße. Funktioniert auch für Routenplaner. "Biegen sie ab in Amtshof; Am Schmiedeteich". Es stehen beide Straßenschilder an der Straße, perfekt. "Fahren Sie 100 Meter. Sie sind an Ziel Amtshof 10 angekommen." Ähnliche Situation, wenn die Häuser an der A-Straße bis an die B-Straße reichen. Dann schreibe ich auch nicht an die B-Straße name:rechts=A-Straße, obwohl es durchaus passieren kann, dass vereinzelte Häuser dann dort ihre einzige Einfahrt haben können.+1 zu allem obigenP.S.: Irgendwie hat Dein Client Probleme mit dem Zeilenumbruch. Meiner muss den ständig nachträglich einfügen. Die Antwortlevel muss ich sogar von Hand einfügen. Und mich stören diese manuellen Umbrüche, weil ich dann voregegeben bekomme, das ich nicht die gesamte Breite meines Fensters zujm Lesen nutzen kann. Wenn Dein Client Deine Umbrüche mitten im Satz automatisch reinmacht, macht er es auch bei dem, was Du von mir zitierst. Doch Dein Client sollte zumn Lesen schon auch fähig sein dynamisch (sprich je nach Fensterbreite) am rechten Fensterrand umzubrechen, oder so einzustellen sein. Und ich dachte, solche Probleme gibtds ja seit UUCP und dem Usenet nicht mehr. Da konnte - hmm wie hies der DOS-Reader doch gleich - das alles sehr schön darstellen - wie man wollte.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-15?q?_forward/backward?=)
Am 26. Jul 2010 um 21:33 schrieb Guenther Meyer d@sordidmusic.com:Am Montag 26 Juli 2010, 21:03:23 schrieb steffterra: ok, so kannst du dir natuerlich die Richtung sparen. Nur hast du damit im Editor durch die drei ways auch automatisch eine Ausdehnung, die nicht unbedingt der Realitaet enspricht (tut sie sowieso nicht, aber eine schmale Strasse bringst du dann evtl nicht mehr zwischen den angrenzenden Haeusern/POIs durch. Daran habe ich auch gedacht. In JOSM sollte erstmal nur der Datenway zuu sehen sein. Und nur, wenn man auf ihn klickt, dann gehen die beiden ways links und rechts davon "auf". Wenn man wieder woanders hinklickt, geht es wieder "zu" bzw. zurück. Da es nur für Straßen gedacht ist, diue richtungsabhängige Tags benötigen (und das ist sicher nicht die Masse), könnte man auf diese Weise an die Stellen "hineinschauen", die einen interessieren. spaetestens wenn du Fahrspuren mit abbilden willst, hast du zumindest in groesseren Staedten staendig richtungsabhaengige Attribute. Dasselbe gilt fuer viele Landstrassen (Ueberholverbote, Geschwindigkeitsbeschraenkungen, ...).Die habe ich auch so, nur das ich sie dann an der Spur taggen kann , die es betriff und muss es nicht über ein kompliziertes Tagging-Schema an den einen way hängen.Aber prinzipiell ein guter Ansatz. Man koennte sich auch durchaus verschiedene Ansichten vorstellen, je nachdem was einen interessiert, bis hin zum "fotorealistischen Rendern".Rendern ist aber Rendern und meint nicht die Darstellung im Editor, die ich oben beschrieb.'Für die Renderer habe ich mir ja auch etwas ausgedacht, wie z.b. für Kreuzungen. So eine Art Lupenfunktion, aber keinen weiteren Zoomlevel für dei ganze Seite. Also eher einen Zoomlevel für ein definiertes Rechteck, das dann daneben noch einmal groß gerendert wird. natuerlich kann man das drehen nicht sperren. Aber man muss es in der Software auch nicht anbieten, nicht mal anzeigen. Denn es gibt keinen Grund, die Richtung ueberhaupt zu drehen. Das Problem entsteht doch nur dadurch, weil die Richtung einerseits als Referenz fuer diverse Tags genutzt wird, andererseits aber auch direkt z.B. die Richtung einer Einbahnstrasse darstellt. Und genau letzteres muss getrennt werden. Ich sehe die Richtung als Referenzeigenschaft des ways, genauso wie du das durch drei getrennte ways darzustellen versuchst.ja, ich verstehe es "ausserhalb meines Models" auch so.Um beim Beispiel Einbahnstrasse zu bleiben: Wenn die Fahrtrichtung aus irgendwelchen Gruenden gedreht werden muss, dann wird nur das entsprechende oneway-Attribut gedreht, sonst nichts. Einfacher geht's doch kaum... Wo ist Dein Problem? Man muss ja nicht jede Fahrspur abbilden, man könnte es aber, falls nötig. Nötig wäre es nur, wenn sich die Fahrspuren _einer Richtung_ vom tagging her unterscheiden, z.B. bei einer abbiegenden äußeren Fahrspur udn der gerade aus weiter führenden Fahrspur. muss man nicht. Ausserdem hast du dann wieder eine Mischloesung... Nein, was ist denn gemischt? richtungsabhängige tags gibt es dann offiziell nicht mehr, weil dann die Gruppierten ways für die Richtungsabbildung zuständig ist, die das viel besser maschinen- udn menschenlesbar abbildet. du hast dann einerseits deinen Wegtripel, andererseits im schlimmsten Fall noch mehrere ways, die die einzelnen Fahrspuren kennzeichnen, wenn ich dich richtig verstanden habe.Nunja. Sehe es es. Man kann den way flexibel einsetzen. Entwedera) so wie jetzt auch mit einem way (für die Strecken ohne richtungsabhängige tagsb) mein Model, das zwei ways für jede Fahrtrichtung vorsieht und einen daten-way dazwischen, der von einem neuen Renderer nicht gerendert wird, aber von einem älteren Renderer genutzt wird, weil dieser die anderen Fahrrichtungsways nicht nutzen kann.Bei mehreren Fahrspuren pro Richtung könnte dann auch da der lanes-tag eingesetzt werdenc) mein Model mit genmutzter Möglichkeit neben dem daten-way links und rechts davon mehrere Fahrspuren-ways zu zeichnen, wenn es denn nötig ist, wie z.b. an komplizierten Kreuzungen, oder wenn es verschiedene maxspeed-tags auf jeder Fahrspur gibt, etc. Dann gibt es da halt kein lanes=2, sondern eben zwei ways, die dann zusammen mit dem Rest in einer Gruppe die Straße im gesamten darstellen.Der Vorteil ist die Flexibilität ohne dabei neue Redundanz zu bilden, gleichzeitig ist das ganze abwärtskompatibel. Das ist sogar der wichtigste Punkt an der ganzen Geschichte.Hmm, jetzt faellt mir noch was ein: Eigentlich wuerden in deinem Modell zwei ways fuer die beiden Seiten reichen. eigentlich ja - doch ich wollte vermeiden, dass z.B. der name-tag an beiden ways getaggt wird, was wieder zu unnötiger Redundanz führen würde, so wie im Linienbündel-Model, das ich nicht so mag.Da diese sowieso in einem uebergeordneten Objekt zusammengefasst werden muessen, kann man doch die allgemeingueltigen Tags gleich da dran haengen; das Einzeichnen des Mittelweges ka
Re: [Talk-de] das Problem mit backward-forward und left-rig ht - neues Datenmodell nötig!?
Am 25.07.2010 um 03:51 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c om: Am 21. Juli 2010 04:37 schrieb Tirkon tirko...@yahoo.de: Das Auflösen der Fahrspuren in Linienbündel würde den Großteil von richtungsabhängigen Tags und Relationen obsolet machen. Dennoch: Ich halte eine Einführung ohne dazugehörigen grafischen Editor, mit dem man die Linien zusammmenklicken kann, für problematisch, da dann OSM nur noch von wenigen Spezialisten editiert werden kann. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways u nd Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. +1 steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz-Die Lösung
Am 25.07.2010 um 03:15 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c om: Am 20. Juli 2010 10:38 schrieb Martin Simon grenzde...@gmail.com: Für mich ists auch ok, ich hätte abe auch nichts gegen ein tag für einzelne Parkstände als node einzuwenden, wenn es nicht amenity=parking heißt. ;-) warum als Nodes? Das sind doch klar Flächen. Ich wäre auch für ein Tag für einzelne Parkplätze (Stellplätze), bzw. zur Markierung der Parkbereiche auf größeren Parkplätzen. Und wie wird die dann in die Area gezeichnet? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutschen
Am 25.07.2010 um 03:00 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.c om: Am 24. Juli 2010 15:29 schrieb steffterra steffte...@me.com: Wäre doch toll, oder? naja, deutlich toller wäre es, direkt zu einem freien und kostenlosen Parkplatz in der Nähe geleitet zu werden, oder? Das stimmt allerdings ;-) *träum* steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutschen
Am 25.07.2010 um 12:41 schrieb Guenther Meyer d@sordidmusic.com: Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: Hi, ich möchte damit weder provozieren, noch die 'alte Diskussion wi eder hochkochen lassen. Erlaubt mir aber dennoch folgende Frage: Warum weiss jeder in Deutschland, dass - ein Behindertenparkplatz kein großer Parkplatz für Behinderte ist (in der Größe von amenity=parking) - ein Frauenparkplatz kein goßer Parkplatz für Frauen ist - ein Elternparkplatz kein großer Parkplatz für Eltern mit Kindern ist - ein Motorrardparkplatz kein großer Parkplatz für Motorräder ist All diese Parkplätze sind eigentlich Parkstände/Stellplätze, wie ich hier lernen konnte. Doch warum in Gottes Namen heissen sie Parkplä tze, wenn sie doch, im Sinne von dem was laut Wiki amenity=parking bedeutet, gar nicht sind? jetzt ist es also ein sprachliches Problem... Zumindest in DE scheint es so zu sein, dass daher die Diskussionen rühren. Ich verstehe allerdings auch fürs Englische nicht, dass wenn man schon nur große Parkplätze meint, den Tag parking genannt hat, anstatt car_park oder parking_area... Viel schlimmer ist aber dad Ergebnis meiner Diskusionsgrundlage hier. Dabei kam ja leider heraus, dass man parking auf keinen Fall verallgemeinern darf, weil es schon gefühlte 3 Milliarden mal so getaggt wurde. Aber das kann man in dem anderen Thread weiter diskutieren... es ist eigentlich ganz einfach: amenity = parking bedeutet ausgewiesene Parkmoeglichkeit, nicht mehr und nicht weniger. Nein, sonst könnten ja auch Einzelparkplätze mit parking getaggt werden, da auch diese ein P auf dem Schild haben (siehe andere Diskussion). Das Problem ist, dass es eben nicht so interpretiert wird, wie Du schreibst, sondern total absolut: amenitiy=parking=großer Parkplatz mit eigenen Wegen zwischen den Parkständen. Man sagt hier relativ übereinstimmend, dass Einzelparkplätze deshalb eben nicht genauso getaggt werden dürfen, sondern eigene Tags benötigen würden, weil sie als solche als Einzel-nodes auch auf einem großen Parkplatz z.B. einen Behindertenparkplatz kennzeichnen können. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutschen
Am 25.07.2010 um 14:04 schrieb Bodo Meissner b...@bodo-m.de: Am 25.07.2010 12:41, schrieb Guenther Meyer: Die Angabe kleine Parkmoeglichkeiten taggen wir nicht steht von Anfang an auf der Wikiseite. Ich kann mir nur vorstellen, dass damals damit verhindert werden sollte, dass alles mit Parkplaetzen zugekleistert wird. Das wird auch dadurch bestaetigt, dass damals kein separates Tag fuer diese Stellplaetze dokumentiert wurde. Aber heutzutage, wo jeder Baum und Kanaldeckel getaggt wird, und die Mapper und auch Renderer wesentlich differenzierter arbeiten, halte ich so eine Begruendung fuer obsolet. +1 + 1 Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: und wie man das am besten Neuusern verklickert, die geneigt sind aus obigem Grund natürlich überall ein amenity=parking hinzubauen und einen Key f ür die Art des Parkplatzes (disabled, women, parent, motorbike) hinbauen. in dem man den Wikitext entsprechend anpasst. Was soll denn bitteschoen kaputtgehen? +1 + 1 Ich kann schon nachvollziehen, daß es Unklarheit schafft, wenn jetzt einzelne Stellplätze ohne Zusatztags als amenity=parking bezeichnet werden. Um das zu vermeiden, würde ich im Wiki dokumentieren, daß einzelne S tellplätze oder Parkplätze mit geringer Kapazität immer ein capacity-Tag haben sollen. Das könnte auch von Editor-Presets unters tützt werden. Bei Parkplätzen, die nach der bisherigen Beschreibung im Wiki keine ausreichende Größe haben, kann man nicht argumentieren , daß die Erfassung (Schätzung) der Kapazität nicht praktikabel oder zu aufwändig wäre. Bei Parkplätzen ohne capacity können wir annehmen, daß es sich entsprechend der alten Beschreibung um größere Parkplätze handelt. (Andernfalls ist es ein Fehler im Tagging.) Dann müßte man bei Bedarf nur noch den Renderern beibringen, ab irge ndeiner Kapazitätsgrenze eine Unterscheidung zu machen. Insoweit sehe ich da auch kein wirkliches Problem. + 1 Allerdings wird mit diesem Vorschlag nicht die Frage beantwortet, wie man auf einem großen Parkplatz mit mehreren Stellplätzen/ Parkständen die Bereiche kennzeichnet, die bestimmten Fahrzeugen ode r Fahrzeugnutzern vorbehalten sind. Möglicherweise kann man das mit parking:lane lösen. Falls das zu kom pliziert ist, braucht man eben (wie bereits gesagt) geeignete Presets. Angenau diesem Punkt scheiden sich eben die Geister. Ein einzelner Node ist halt einfacher auf einer Fläche zu taggen. Mein Gedanke ist derzeit, so vorzugehen: 1.Area mit normalen Parkständen: amenity=parking capacity:standard=360 2.Area mit Parkständen für Behinderte: amenity=parking capacity:disabled=2 3. Area mit Parkständen für Eltern: amenity=parking capacity:parents=18 4. Area mit Parkständen für Frauen: amenity=parking capacity:women=20 Alle 4 Areas in eine Relation für den gesamten Parkplatz, um zu zeigen, dass alle Areas zusammen gehören: amenity=parking capacity=40 Damit wäre erreicht: 1. Die Spezialparkplätze sind eindeutig zu lokalisieren. 2. Da es sich faktisch um Flächen handelt, ist area nicht falsch. 3. Durch die Relation ist klar, dass alles zu einem Parkplatz gehört. Das setzt natürlich voraus, dass parking als Überbegriff für ausgewiesene Parkplätze anerkannt wird! Alternative: 1. Gesamtparkplatz in eine Area mit allen Zufahrtswegen, etc. Und das multipolygon als inner taggen. 2. Alle Spezialparkstände und auch die Fläche der normalen Parkstände jeweils als outer vom mulipolygon mit obigen tags versehen. Auch dann ist alles zusammengefasst und dennoch sind die einzelnen Bereiche gleichwertig nebeneinander getaggt. Beide Varianten funktionieren natürlich auch mit jeweils eigenen tags, dad capacity sollte aber dennoch nicht fehlen. Deshalb wären alle Varianten gleich aufwändig. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Am 25.07.2010 um 14:08 schrieb Thomas thomas.ebe...@t-online.de: Wie sollte man eine Abbiegerelation bei einer Auffahrt (link) zu einer Bundesstraße gestalten? Ich habe unterschiedliche Arten in der OSM-Karte gefunden: * nicht links abbiegen (no_left_turn) * nur geradeaus fahren (only_straight_on) * nur rechts abbiegen (only_right_turn) Mit der ersten Variante kommt Skobbler nicht zurecht. Was sagt/macht Skobbler denn? Je nachdem gibt es dazu mehrere Fakten. Ein Fakt ist, dass cloudmade noch nicht mit allen Abbiegerelationen in jeder Situation klar kommt. Das hat aber nichts mit Abbiegeansagen zu tun, da diese nicht aus den Abbiegerelationen generiert werden, sondern aus den Winkeln der beteiligten ways. Bei Variante 2 und 3 bin ich mir nicht sicher, wie man das Auffahren von einer Auffahrt auf eine Bundesstraße verkehrstechnisch überhaupt sieht: Ist es ein Rechts-abbiegen oder ein Einfädeln und damit Ge radeausfahren? Hast du eine echte Kreuzung, ist es ein Abbiegen. Existiert eine Auffahrtsspur ist es ein Einfädeln nach links, aber weder ein Abbiegen nach links (man fährt ja nicht nach links weiter, wie bei einer Kreuzung, sondern in die gleiche Richtung, wie die Auffahrtsspur, also nach dem Einfädelvorgang geradeaus), noch ein Abbiegen nach rechts. Habe im Netz keine Hinweise auf diesen Fall gefunden. Wie seht Ihr das? Du musst hier zwei Dinge trennen: 1. Die Abbiegerelationen, die nur sagen, wie man abbiegen darf, und damit, wie der Router seinen Weg nehmen darf. Diese haben aber nichts mit der Anweisungsgenerierung ala Jetzt leicht nach rechts abbiegen zu tun. 2. Der Winkel, in dem sich treffende ways am gemeinsamen Knoten treffen. Nur aus diesen Winkeln wird die Ansage generiert Jetzt leicht nach rechts abbiegen. Es wäre super, wenn Du die Auffahrt bitte auf maps.cloudmade.com nachvollziehen könntest und uns den permlink hier postest. Dann kann man Dein Problem nochmal schön nachstellen. Danke. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Am 25.07.2010 um 18:33 schrieb Thomas: Die Relation 530.958 beispielsweise wird von Skobbler offenbar falsch erkannt. (Skobbler hat mich hier übrigens entgegen der Einbahnstraße über die benachbarte Abfahrt geschickt.) Ich würde diese Relation auch mit only_straight_on versehen. Sei bitte so freundlich und vollziehe das nochmal auf maps.cloudmade.com nach und poste den permlink. Danke :-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Am 25.07.2010 um 18:59 schrieb Guenther Meyer: Das Problem ist, dass es eben nicht so interpretiert wird, wie Du schreibst, sondern total absolut: amenitiy=parking=großer Parkplatz mit eigenen Wegen zwischen den Parkständen. das ist deine Meinung. Eine Parkmoeglichkeit wird ueblicherweise als Parkplatz bezeichnet, womit auch das Tag wieder passt ;-) Nein es ist nicht meine Meinung ;-) Ich habe dir nur geschrieben, was hier bisher diskutiert wurde. Ich empfehle Dir, die vorangegangene Diskussion noch nachzulesen und dann auf dieser Basis wieder in die Diskussion einzusteigen. Denn dann wirst Du sehen, dass ich ganz Deiner Meinung bin, den amenity-tag für parking als Oberbegriff für alle Parkarten umzustellen. Dazu habe ich auch diverse Vorschläge für die Umsetzung gemacht, welchen aber bisher aufs heftigste widersprochen wurde. Man sagt hier relativ übereinstimmend, dass Einzelparkplätze deshalb eben nicht genauso getaggt werden dürfen, sondern eigene Tags benötigen würden, man? zwei Leute...?! Nunja. Finde es heraus. Mache ein gutes Proposal, das alle Sonderfälle und Kritikpunkte berücksichtigt und stelle es offiziell zur Abstimmung im Wiki. Auch solltest Du dafür die anderen Proposals für parking:lane und more-capacity-keys mitberücksichtigen Ich helfe Dir gerne dabei. weil sie als solche als Einzel-nodes auch auf einem großen Parkplatz z.B. einen Behindertenparkplatz kennzeichnen können. der groesste Teil der POI-Tags kann sowohl fuer Flaechen als auch fuer Punkte verwendet werden, OHNE dass man dafuer ein anderes Tag braucht. Warum sollte das bei Parkmoeglichkeiten ploetzlich nicht gehen? Es geht um das taggen von flächen auf flächen mit dem selben tag. Das sollte in der Tat nciht sein. Deshalb meine beiden Vorschläge, aus dem anderen Posting: Möglichkeit a) Alle areas der Parkarten in je einem outer-Multipolygon des umgebenden Gesamparkplatz multipolygon (inner) Möglichkeit b) Einzel-Areas, die über eine Relation zum Gesamtparkplatz zusammengefasst werden. Bei beiden Varianten wären zusätzliche Einzeltags überflüssig, sofern man diese Unterscheidung im capacity-tag unterbringt (z.B. capacity:disabled=2) und amenity=parking als Überbegriff akzeptiert. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 25.07.2010 um 14:54 schrieb Tirkon: Ich weiß, eine Menge Fragen. Aber sie drängen sich auf. Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Am 25.07.2010 um 19:27 schrieb Andreas Labres: Hallo steffterra ! Ich denke mir, Du machst Dir da zu große Sorgen. Nein ich sehe es genauso. Auch ich bin dafür, dass amenity=parking zum Überbegriff für Parkplätze und Parkstände wird und eben _nicht mehr_ so ausgelegt wird, wie es traditionell mal vorgesehen war und es im wiki auch dokumentiert ist. Ich halte den Wikieintrag für überholt. Aber das habe ich auch alles schon geschrieben. Ich habe lediglich den Gesamteindruck wieder gegeben, der sich mir durch den heftigen Widerstand in der bisherigen Diskussion erlebt habe. Parkplatz ist ein Platz zum Parken, wie groß der ist, ergibt sich aus dem Kontext. Und ja, am Hofer-(Aldi-)Parkplatz gibt es auch Behindertenparkplätze und Parkplätze für Eltern mit Kinderwagen usw. +1 Was jetzt das Tagging angeht, so sehe ich amenity=parking am ehesten dort richtig, wo auch ein blaues P das als Parkplatz (im Sinne von Kundenparkplatz vor'm Aldi oder ParkRide Parkplatz vor der S-Bahn usw.) ausweist. +1 Damit wissen dann auch die Renderer, daß sie dort ein blaues P hinmachen sollen und die Router wissen, daß sie dort hinrouten, wenn Du mit dem Auto zum Aldi willst usw. und durch die keys weiss man auch welche Art Parkplatz es ist. Daß man auf sehr, sehr vielen highway=residential (mal links, mal rechts, mal beidseitig) parken darf, gehört irgendwie gemeinsam mit den ganzen Wegebündeln/Fahrbahnen/Gehsteigen/Radwegen/Parkstreifen gelöst. ohne Weg-/Linienbeündel/Gruppierung, ist es derzeit im Proposal parking:lane sehr gut formuliert und berücksichtigt wirklich nahezu jedes mir bekannte Zusatzschild an Parkständen/Plätzen. Das für ein Linienbündelähnliches Modell umzusetzen ist ein leichtes, da man auf left/right verzichten müsster und es einfach an der entsprechenden Spur taggen könnte. Und wichtige Einzelparkplätze (wie der Behindertenparkplatz) gehören separat gelöst, hier ist ein Behindertenparkplatz für n Fahrzeuge. +1 zwei Vorschläge, wie das für Areas gelöst werden könnte, habe ich heute bereits gepostet. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
aber in sich logisch und so dürfte die Einarbeitungszeit ungleich kürzer sein, als bisher. - Fahrspurentagging möglich wo nötig, aber nicht zwingend erforderlich. - Router könnten out-of-the-box einen Fahrspurassistenten bieten. - es wäre automatisch klar, wo man Ampel-nodes unterbringen kann, Überquerungen aller Art, Haltestellen zwischen Fahrspuren - Erleichterung für die Fußgänger-, Fahrradfahrer- und barrierefreien und Blinden-Navigation, da auch andere Wegarten eigene Fahrspuren bekommen könnten und so getrennt getaggt werden könnten - usw. Nachteile: - - sicher gibt es welche, wie z.B. das erhöhte Datenaufkommen - jemand müsste das in die DB einbauen und auch stufenweise in die populären Editoren. - schon einzelne Tags führen zu Tagelangen Diskussionen. Meint ihr, wir die OSM-Community könnten dennoch sowas umsetzen? - Das Wiki müsste nach und nach an die neue Situation angepasst werden. - usw. Beachtet, dass das Konzept nicht vorsieht, andere Wegarten zu gruppieren, sondern nur jeweils Fahrspuren innerhalb einer Wegart. Es kann also kein cycleway-Spur zusammen mit den highway-Fahrspuren gruppiert werden. Radwege werden nach wie vor an der äußersten Fahrspur getaggt, wie bisher auch - nur ohne dann unnötige Richtungsangabe. Vielen Dank, an alle, die bis hier gelesen haben. Für die anderen: Bevor Ihr urteilt, lest es bitte komplett, da die eine Frage vielleicht schon weiter unten beantwortet wird. Bitte macht mich gerne auf Denkfehler aufmerksam ;-) Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 25.07.2010 um 03:51 schrieb M∡rtin Koppenhoefer: Am 21. Juli 2010 04:37 schrieb Tirkon tirko...@yahoo.de: Das Auflösen der Fahrspuren in Linienbündel würde den Großteil von richtungsabhängigen Tags und Relationen obsolet machen. Dennoch: Ich halte eine Einführung ohne dazugehörigen grafischen Editor, mit dem man die Linien zusammmenklicken kann, für problematisch, da dann OSM nur noch von wenigen Spezialisten editiert werden kann. Das halte ich für ein Gerücht. Vieles würde durch explizite Ways und Areas für Spuren und Flächen einfacher, transparenter und übersichtlicher werden. Auch Anfänger würden davon profitieren. volle Zustimmung +10 ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
Am 25.07.2010 um 22:09 schrieb Tirkon: steffterra steffte...@me.com wrote: Ich poste noch einmal mein Konzept, wie ich mir meine Version vom Linienbündel vorstelle, da es etwas unterging. Es würde die Probleme des forward/backward, left/right komplett beheben, das Tagging insgesamt damit auch für Neuuser transparenter und gleichzeitig Fahrspurzeichnen und -tagging ermöglichen. Das Ganze _bei gleichzeitiger Abwärtskompatibiliät_ und es müsste nur eine weitere Datenart für die Gruppierung der ways hinzukommen. Zumindest für meinen Teil ist es nicht untergegangen. Ich hatte auch schon dazu gepostet, dass man das Konzept durchgängig in vielen Situationen gemappt sehen muss. Da ich auch in anderen Projekten gut eingespannt bin, habe ich derzeit nicht die Ressourcen, das in Bildbeispielen/Screenshots zu erläutern. In einem entsprechenden Proposal würden solche Beispiele aber unerlässlich und sehr zum Verständnis beitragen. Deshalb habe ich das auf jeden Fall im ToDo. Leider in der OSM karte nicht machbar, da die Gefahr durch Veränderungen Anderer gegeben ist. Und rein aus der Textwüste ist so etwas nicht beurteilbar. +1 Betreff des Themas: Konzept für die Gruppierung von ways (ähnlich Linienbündel) stay tuned ;-) Bin schon öfter nach solchen Ankündigungen gespannt gewesen. Mal sehen, ob trotz der von mir oben schon ausführlich beschriebenen Widrigkeiten und insbesondere ohne Versuchs-Miniplanet diesmal was kommt. Ich möchte vorher noch Stimmen dazu sammeln, dass ich sie in einem zukünftigen Proposal einfliessen lassen kann. Ich möchte vorerst nicht den Anspruch auf Vollständigkeit erheben und alles gut durchgekaut wissen, bevor ich da weitere Arbeit investiere ;-) Doch wie denkst Du im Einzelnen zu den Facetten des Konzepts. Wenn Du die Zeit dazu hast, würde ich mich sehr freuen, wenn Du dort noch einmal genauer darauf eingehst. Deine grundsätzliche Sorge teile ich. (s.o.) Gruß, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegerelation bei Auffahrten
Am 25.07.2010 um 23:02 schrieb Thomas: Ich würde gerne einen Permalink schicken, aber das Routing bei Cloudmade funktioniert bei mir heute nicht (Nach dem Setzen von from here und to here erscheint endlos die Meldung Loading). Das Problem mit der Abbiegerelation war aber wohl, dass bei einer no_left_turn-Restriction das to falsch gesetzt war. Ich habe die Relation jetzt korrigiert. Ich meine, only_right_turn wäre besser, oder? Deine Variante impliziert, dass man nicht nur rechts, sondern auch gerade-aus fahren dürfe, wenn man könne. Aber davon abgesehen: als ich mir die alte Relation in OSM heute mittag angesehen hatte, file mir auf, dass die Abbiegeregelung per Relation dort ja gar nicht nötig ist, da sie schon über Einbahnstraßen ausreichend abgebildet wird. Kann das sein? Mir erscheint bei einer Auffahrt auf eine Straße die only_straight_on-Restriction (mit from = Auffahrt (link), via = gemeinsamer Knoten und to = Bundesstraße) an sinnvollsten. Denn das Einfädeln ist ja kein Abbiegen nach rechts. s.o. Trifft das zu? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 25.07.2010 um 23:39 schrieb Frederik Ramm: Hallo, steffterra wrote: Wieso dann nicht die Argumente in einem neuen Datenmodell vereinen? Sicher bin ich nicht der erste, dem das einfällt. Ich habe hier schon des öfteren von Linienbündeln und Fahrspurtagging gelesen. Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. Was ich nicht so recht verstehe, ist: Wieso meinst Du, dass eine neue Art von Objekt erforderlich ist? Die Editoren muessen eh angepasst werden, um Dein Konzept zu verstehen, also koennte man sie auch derart anpassen, dass statt Deiner neuartigen Way-Gruppierung eine ganz gewoehnliche Relation eingesetzt werden kann - in einer fuer den Benutzer nicht unterscheidbaren Art und Weise. Ich glaube zu verstehen, was Du meinst. Die Gruppierung in einer ID wäre wesentlich flexibler als vom User manuell zu setzende Relationen. Ich denke auch, dass Relationen ein guten Mittel für verschiedene Zwecke sein kann. Aber hier Relationen einzusetzen wäre overkill. Zumal auch mehr kb anfallen würden, als wenn jeder way, der zu einer Gruppe gehört die gleiche Gruppen-ID hätte. Es wäre schon deshalb felxibler, weil das im Hintergrund passieren könnte, also ohne dass sich der User darum kümmern muss, ausser die ways zu markieren und dann im Menü Gruppieren zu klicken. Dann schaltet JOSM die gemeinsame Hintergrundfarbe für diese Gruppe und es ist auch von der Wahrnehmung her zu einer Straße geworden. Im Hintergrund hat JOSM die ID vergeben und FRenderer können diese nutzen, um die ways entsprechend darzustellen. Die Latte fuer neuen Objekttyp in der zentralen Datenbank einfuehren haengt wesentlich hoeher als die fuer neue Art von Relationsnutzung erfinden und Editor-Support dafuer entwickeln. Fuer das erstgenannte musst Du wesentlich mehr Leute davon ueberzeugen, dass das, was Du vorhast, gut ist. Das wiederum fuehrt zu meiner einleitenden Anmerkung zurueck - solange 99% der Leute im Projekt das Problem, das Du loesen moechtest, noch gar nicht selber hatten, werden sie vermutlich mit einem gewissen Unverstaendnis reagieren. Vielleicht ist das in 2-3 Jahren anders. das Problem mit foreward/backward besteht jetzt bereits. Dort wo kein Bedarf besteht, dass dies eingesetzt würde, muss man ja nicht gruppieren. Das ist ja der Vorteil des Konzepts. Es ist abwärtskompatibel, weil eben nciht alles darauf umgestellt werden muss. Man kann es nur dort einsetzen, wo es das taggen vereinfacht oder Fahrspurtagging sinnvoll wäre. Ich sehe auch noch eine gewisse Schwaeche bei der Frage, wie man Ways aufsplittet und verbindet - da muessen ja dann alle Teil-Ways immer mitgesplittet werden, aber wo? Die Tags müssten natürlich genauso kopiert werden, wie bisher auch, alles die gleichen Regeln. Das Teilen/Splitten selbst kann durch mehrfachmarlkieren aller Nodes auf allen an der Gruppe beteiligten ways geschehen. So viele sind das ja meist nicht. Denn 8-spuriges Autobahntaggen ist ja nicht nötig ;-) Es kann ja auch jeder way einer Gruppe nach wie vor mit lanes=4 getaggt werden. Kein Problem. Das ist ja das schöne an der Felxibilität. Also einfach alle drei ways (beide Fahrrichtungsways und der datenway) mit nodes versehen, an denen man die Straße aufteilen möchte und den Befehl anwenden. Es sollte aber aus Sicherheitsgründen eine Nachfrage kommen, falls man einen node auf einem way nicht mitmarkiert hat. Könnte aber auch noch nachgeholt werden, falls man den way doch nicht abzweigen lassen möchte - z.B. als abzweigende Fahrspur. Die Bearbeitung von Kreuzungen stelle ich mir sehr schwierig vor, aber vielleicht ist das nur eine Frage des Benutzerinterfaces. Kreuzung werden sogar einfacher, das man nur die Schnittstellen mit gemeinsamen Nodes versieht, wo tatsächlich eine Kreuzung vorhanden ist. Abbiegespuren, die z.B. gar nicht kreuzen sidn so noch einfacher umzusetzen. Ansonsten gilt für jeden Richtugnsway/Abbiegespur die ganz normalen Abbiege-Relationen. Es bleiben ja ways mit nodes, auf diese man die Relationen anwenden kann. Absolut abwärtskompatibel. Ausserdem muss man natuerlich immer damit rechnen, dass es Software und Benutzer gibt, die das ganze nicht verstehen. Dazu könnte man eine sehr schöne Anleitung/HOWTO schreiben mit Bildbeispielen, wie ich sie mir auch für das Proposal vorstelle und für absolut nötig halte. In der heutigen Zeit könnte man auch einen Screencast erstellen, der erklärt, wie es funktioniert. Wir haben in OSM keine Software-Zertifizierungsstelle, die entscheidet, welche Software auf unsere Daten losgelassen werden darf und welche nicht (und mit Benutzern ist es ebenso). Leute werden den Datenway aufsplitten und die Spur-Ways unveraendert lassen
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 25.07.2010 um 23:47 schrieb Guenther Meyer: Am Sonntag 25 Juli 2010, 23:08:21 schrieb Frederik Ramm: Hallo, steffterra wrote: Bringt man richtungsabhängige Informationen in Relationen oder Tags am besten unter? Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mal ganz platt gesagt, wenn auf einer Seite der Strasse ein Spielplatz ist, wird auch niemand auf die Idee kommen, sowas wie playground=right zu taggen. ein Spielplatz ist auch von der Strasse total unabhaengig. +1 Die Lage ergibt sich aus den Koordinaten, diese zusätzliche Angabe komplett unnötig. Ebenso waere eine Parkspur im Osten der Strasse nichts, was tatsaechlich irgendetwas mit der Richtung der Strasse zu tun hat - da gibt es eine Parkspur, aber in welcher Richtung der Verkehr auf der Strasse fliesst oder in welcher Richtung die Strasse in OSM eingezeichnet ist, hat mit der Parkspur nichts, aber auch gar nichts zu tun. richtig, die Fahrtrichtung hat nichts mit der Parkspur zu tun. - sondern mit der Seite auf der sie vorhanden ist. Und das gilt es ja anzugeben (bisher mit forward/backward/right) Doch die Parkspur ist ein Attribut eines Teils der Strasse (wenn man mal so ein Modell vorraussetzt), und damit muss irgendwie bezeichnet werden, auf welcher Seite sie sich befindet. +1 Die Fahrspur könnte z.b. nur in einer Fahrtrichtung vorhanden sein. Doch auf welcher? Das tagt man halt auf dem way der Richtugnsfahrspur, zwischen den nodes wo er vorhanden ist: parking:lane capacity:disabled:2 Dafuer braucht man nunmal irgendeine Art der Richtungsangabe. Nur sehe ich die hierfuer notwendige Richtung als total abstrakt an, z.B. angelegt wie die Strasse gezeichnet wurde. Die Richtung wohin die Fahrspur führt, ist tatsächlich egal für die Parkpsur. Doch man legt am way der Seite der Straße den tag an, wo die Parkspur tatsächlich vorhanden ist. Danach hat diese Richtung den User nicht mehr zu interessieren, sie braucht auch gar nicht mehr angezeigt werden. Benoetigt wird sie nur, damit der Editor bzw. die entsprechende Software die Attribute zuordnen und entsprechend auswerten kann. Deshalb gibt es auch keinen Grund, diese Richtung irgendwann zu aendern. Mit der Einführung der Gruppierung sind sie bis auf oneway obsolet fürs tagging. Da man dort hin-taggen kann, wo es ist: an dem way der Straßenseite, wo es in Wirklichkeit vorhanden ist. Es waere also toericht, hier - egal, ob man nun Relationen oder Tags oder sonst was benutzt - in irgendeiner Form einen Bezug zur Richtung der Strasse herzustellen; man erzeugt damit voellig unnoetige Probleme. Genau diese Probleme will die Gruppierung ja verhindern, weil so genau festgelegt wird, an welchem way, also auf welcher Straßenseite welche Dinge vorhanden sind. Wie z.b. Radweg, usw. (Das ist übrigens der Unterschied zum wesentlich komplizierter zu zeichnenden Linienbündel, da wir ausreichend tags haben, um alle Arten von Radwegen, Parkständen, etc. am way zu taggen. Das einzige Problem hierbei ist aber durch die Gruppierung nicht mehr vorhanden und damit das Ziel derer errreicht: die richtugnsabhängigen Unterschiede liegen nun auf den einzelnen ways der Straßenseite, wo in Wirklichkeit vorhanden sind. Danke fürs Feedback, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Am 26.07.2010 um 03:51 schrieb Frederik Ramm frede...@remote.org: Hallo, Tirkon wrote: Ein grosser Schritt vorwaerts waere es schonmal, nicht *unnoetig* richtungsabhaengige Informationen zu produzieren. Mir ist derzeit nicht klar, welche Du damit meinst. Könntest Du da konkrete Beispiele nennen? Die folgten doch direkt auf diesen Satz in meiner Mail. Nicht richtungsabhaengig ist fuer mich alles, was separat existiert und bei dem die Position mehr oder minder nur aus Bequemlichkeit im Verhaeltnis zur Strasse angegeben wird. Darunter fallen fuer mich fast alle left/right-Sachen. Wenn ich angeben will, auf welcher Seite einer Strasse sich eine Mauer oder eine Baumreihe oder ein Parkstreifen befindet, dann ist ein left/right dafuer nicht geeignet, genauso wie ich auch zu niemandem sagen wuerde: Auf der linken Seite der Talstrasse ist ein Fahrradweg. Diese Information reicht nicht. Ich muss entweder sagen wenn Du von X nach Y faehrst, ist auf der linken Seite der Talstrasse ein Fahrradweg, oder ich muss sagen auf der Nordseite der Talstrasse ist ein Fahrradweg. Wenn man in OSM genauso verfahren wuerde, statt sich auf das Kunstgebilde der Way-Richtung zu verlassen, gaebe es 95% der Probleme mit backward, forward, left, right nicht. Die sind alle hausgemacht. Das ist doch meine Argumentation für dieses Konzept! ;-) Durch die Gruppierung hättest Du das Problem doch gelöst, da darin je ein way für beide Fahrtrichtungen enthalten ist. Beispielsweise könntest so dem nördlichen Way die Info des Radweges mitgeben. Dann ist klar auf welcher Strassenseite dieser verläuft. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways be i forward/backward)
Am 26.07.2010 um 01:49 schrieb Tirkon tirko...@yahoo.de: Frederik Ramm frede...@remote.org wrote: Ich habe Deinen Vorschlag gelesen. Meine persoenliche Meinung ist, dass es zu frueh ist, solche Komplexitaet in OSM einzubauen; die allermeisten im Projekt sind noch lange nicht an dem Punkt, wo sie sich um solche Dinge Sorgen machen. Andrerseits kann es natuerlich nie schaden, mal ein bisschen vorauszudenken. Bloß ist das Vorausdenken etwas schwierig, wenn einem das notwendige gemeinsam nutzbare Reißbrett dazu fehlt. Textwüsten sind nicht immer hilfreich, wenn es hier um ein Projekt geht, dass seine Produkte im Wesentlichen grafisch editiert und darstellt. Daher würde ich mich freuen, wenn jemand meinen Vorschlag für das Online-Werkzeug Miniplanet http://wiki.openstreetmap.org/wiki/User:Tirkon/Miniplanet umsetzen könnte. Ich bin mir relativ sicher, dass das Werkzeug nach einiger Zeit des Bekanntwerdens zunehmend genutzt wird. Insbesondere denke ich, dass da bald viele Tüftler am Werk sein werden, die den von Dir genannten Punkt schon überschritten haben und neue Konzepte ausprobieren. Ich werde das Gruppierungskomzept nach dieser Diskussion in einem Proposal durch ausführliche Bebilderung illustrieren, um die Vorstellung zu vereinfachen, von was die Rede ist. Das muss ersteinmal genügen. Kleiner Tip: zeichne doch einfach mal auf einem Blatt Papier auf, wie ich es umsetzen möchte. Dann sieht man es auch schonmal und erkennt auch eigene Verständnisfehler (oder auch einen Denkfehler meinerseits). Nun bitte ich aber nicht weiter darüber zu diskutieren, wie und dass mein Text illustriert werden muss, sondern bitte vor allem über den Inhalt und das Konzept selbst. Wäre super! Danke :-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Tanzschule taggen?
Am 23.07.2010 um 22:47 schrieb Thomas Ineichen: Hallo steffterra, Genau, blos nicht alles, was mit Schulen und Lehren/Lernen zu tun hat unter dem Überbegriff Schule zusammenfassen. Keine Ski-Schule, Box-Schule, Sprach-Schule, Volkshochschule, etc. Das ist genauso unpraktisch wie bei Parkplätzen/Parkständen/Stellplätzen ... Einzeltags sind viel besser, weil man dann in einem großen Schulhaus mehrere Schul-Arten durch ihre Einzeltags als Nodes eintragen kann. Hast Du's endlich verstanden oder habe ich bloss die Ironie übersehen? :- Also verstanden hatte ich es immer, nur nicht eingesehen und deshalb wars natürlich ironisch, aber nicht böse gemeint ;-) Aber ich gebe mich geschlagen, dass es wohl nicht anders geht. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bei öff. Einrichtungen - Gebäude o der Grundstück?
Am 24.07.2010 um 13:49 schrieb Tobias Knerr: Am 24.07.2010 10:01, schrieb p.pri...@gmx.de: wie taggt man eigentlich richtig bspw. ein Schul-Gebäude, welches ja auch auf einem Grundstück steht?? Das Gebäude oder das Grundstück?? In Fällen mit mehreren Gebäuden auf einem Grundstück würde ich eindeutig das Grundstück empfehlen: Man erhält durch das Polygon eine korrekte Gruppierung ganz ohne Site-Relation. Dazu kommen weitere Vorzüge - etwa, dass die einzelnen Gebäude oft eigene Namen haben, die sich dann leicht eintragen lassen. Das ist sicher nicht verkehrt, was den amenity-tag angeht. Bei der Adresse jedoch kommt halt darauf an, wie man die Adresse desjenigen dort am besten abbildet. Wenn z.b. für jedes Gebäude eine andere Adresse (wegen anderer Hausnummer) gilt, dann sollte das Gebäude die Adresse und damit die Hausnummer bekommen. Ich gehe da gedanklich immer davon aus, wie ich eine Lieferung zustellen würde und bilde das möglichst genau ab. So kann ein Institut auf einem Grundstück alleine vertreten sein, aber aus mehreren Gebäuden bestehen. Was nun? Ich würde die Adresse an dem Gebäude taggen, wo der Briefkasten hägt. Den gibt es ja immer. Wenn ich jedoch das gesamte Grundstück mit der Adresse taggen würde, dann würde ich nicht wissen, zu welchem Gebäude ich bei dieser Adresse, die in in Nominatim gefunden habe, gehen müsste. Bei einem einzigen Gebäude hängt es m.E. davon ab, ob sich die Grundstücksfläche nennenswert vom Gebäude unterscheidet. Wenn zur Anlage auch noch der Pausenhof, ein Sportgelände, oder andere größere Einrichtungen gehören, dann würde sich auch hier empfehlen, das ganze Grundstück mit dem amenity=school zu versehen. Das amenity-tag würde ich auch am Grundstück taggen in dem von Dir beschriebenen Fall. Doch die Adresse würde ich am Hauptgebäude taggen, wo auch der Briefkasten hängt bzw. wo sich der Haupteingang befindet (und diesen am besten auch gleich als entrance taggen). Btw, da wir ja von öffentlichen Einrichtungen sprechen. Im Falle einer Universität könnte das Gelände mit dem Namen des Uni-Campus getaggt werden, die einzelnen Gebäude mit dem der Institute und die Adressen jeweils an dem Gebäude, zu dem die Adresse gehört. Wenn alle Institut- Gebäude des Campus-Grundstückes jedoch eine gemeinsame Hausnummer haben, dann würde ich in diesem Fall das Grunstück mit der Adresse taggen, da sie ja für alle Gebäude des Grundstücks gilt. Dadurch spare ich mir eine Adressrelation für die Gebäude des Grundstücks. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bei öff. Einrichtungen - Gebäude o der Grundstück?
Am 24.07.2010 um 14:08 schrieb fx99: Im Vergleich zu Schulen und sonstigen Einrichtungen sind bei Privatgeländen die Grenzen schwieriger zu erfassen, ich hab es noch nicht gesehen, dass so etwas in Wohngebieten gemappt wird. Das Hauptproblem liegt wohl auch daran, dass GPS nicht so hoch auföst, um Zäune auf Privatgrund zu mappen, wenn man keine Karte abzeichen darf. Selbst wenn man das dürfte/könnte, wäre es egal, ob man das eingezeichnete Gebäude oder das Grundstück mit der Adresse taggt. Die Adresse wird von der Gemeinde für das Grundstück vergeben. Wenn man nun ein Haus darauf baut, muss dieses die Adresse des Grundstückes bekommen. Es gibt auch den Fall, dass für ein großesGrundstück zwei Bauplätze ausgewiesen sind. Dann wird einem Grundstück zwei Hausnummern zugeordnet. In diesem Fall ist IMHO jedes Haus (wenn es dann steht) mit der Hausnummer zu versehen, das man sich vom Grundstück ausgesucht hat (nach den Vorgaben der Gemeinde versteht sich). Es ist also nicht immer automatisch so, dass das Grundstück nur eine Adresse haben kann, wenn z.B. nur ein Haus von zweien gebaut wurde. Ich hielte es aber für unnötig/übertrieben bzw. sogar schädlich, - selbst wenn man es wüsste- eine Hausnummer/Adresse auf dem Grundstück zu taggen, die noch frei ist und die belegte Hausnummer am bereits gebauten Haus. Ich würde die Adresse des Hauses am Gebäude taggen und die andere Adresse gar nicht taggen, weil man dort auch nichts zustellen muß/kann. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Am 23.07.2010 um 21:10 schrieb Thomas Ineichen: [Deine ersten Ausführungen] o.k. verstehe schon, dass es geschichtlich so entstanden ist. Ich lege jedoch keine falsche Logik an, sondern habe nur vom deutschen Sprachgebrauch gesprochen. Nun gut. Ich verstehe ja auch, dass man - egal welche Sprache man zugrunde legt- da immer in Schwierigkeiten geraten kann. Das trifft sicher nicht nur fürs Deutsche zu. Ich wage übrigens zu bezweifeln dass amenity=disabled_parking kompli- zierter ist als amenity=parking, capacity=1, capacity:disabled=1. Das habe ich auch nicht behauptet. Ich sagte nur, dass es für Anwendungen leichter ist, alle unter einem gemeinsamen amenity-tag zu findenden keys zu finden, als verschiedene unabhängig von einander benannte Einzeltags. Schon wegen der Vollständigkeit. Eine software die z.b. eine Datenbank aller Parkplatzarten erstellen möchte, muss bei Einzeltags halt in allen OSM-amenity-Tags nach dem vorkommen von parking im Wort suchen. Nur so kann es alle parking- Möglichkeiten heruasfinden. Wenn alles unter einem Oberbegriff für die die keys gemacht würde, wäre es einfacher. Aber gut, das Thema ist ja durch und da gibts halt in OSM kein Rütteln dran. Ist ein tag erstmal etabliert, gibts kein zurück mehr. Auch _wenn_ sich nach Jahren herausstellen sollte, dass es damals vielleicht die richtige Entscheidung war, heute aber eher Käse wäre und man sich heute wohl anders entscheiden hätte. Damit muss ich mich abfinden und so isses halt. (ich schireb bewusst äre, da es hier auch andere Meinungen gibt, die den tag immernoch als sehr gut so betrachten) Ich habe mal spontan ein paar Leute gefragt, die nichts mit OSM am Hut haben, die mir alle sagten: klar sind das alles im deutschen Sprachgebrauch Einzel-Parkplätze, aber natürlicherweise sagt jeder Parkplatz. Wenn man auf Parkplatzsuche geht, würde man ja auch nicht ausschließlich nach einen großen Parkplatz suchen, sondern einen Einzelplatz, wo man sein Auto/Motorrad parken kann. Wenn ich Dich frage: Wo parke ich am besten, wenn ich in Berlin zum Brandenburger Tor möchte? Was wäre dann Deine Antwort? Ich kenne da einen Parkstand in der Dorotheenstrasse. Wenn dieser einzelne Platz schon besetzt ist, dann fahr halt in die Scheidemann- strasse, da ist noch ein anderer Parkstand oder doch eher Fahr ins Parkhaus beim Sony-Center, da findest Du eigentlich immer einen Platz. Ich freue mich auch, wenn ich erfahre, dass es _in der Nähe_ eine Straße gibt, die solche Parkstände am Seitenstreifen bietet. Man sollte nicht von sich auf andere schließen - auch nicht beim Parkverhalten ;-) Ich bin trotz vorangegangener Diskussion deshalb immer noch der Meinung, dass hier irgendwas schief läuft. Da ist doch ein grundlegender Denkfehler im System. Versteht Ihr, was ich meine? Wie kann man das ausmerzen? Durch Einzeltags für alle oben aufgeführten Parkplatzarten (und allen die mir jetzt nicht einfielen), ist es doch nicht getan, oder? Die zweite, sehr viel aufwändigere Lösung wurde hier bereits vorge- schlagen. welche meinst Du? Und warum siehst Du diese als_Lösung_ an, wie Du schriebst? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 23.07.2010 um 21:33 schrieb Rainer Knaepper: osm.mailingl...@t-i.ch (Thomas Ineichen) am 21.07.10: Wenn ich in einer fremden Stadt nach einem Parkplatz suche, dann möchte ich in ein Parkhaus/zu einem grossen Parkplatz geleitet werden und nicht von Stellplatz zu Stellplatz. Wenn ich in einer fremden Stadt nach enem Parkplatz suche, dann möchte ich zu einer Parkmöglichkeit in der Nähe meines Ziels geführt werden. +1 Und dann möchte zuallererst ich wissen, ob der Stellplatz: - frei oder gebührenpflichtig ist, - parkzeitdauerlich, höhen-, breiten- oder gewichtsbeschränkt ist, - Einschränkungen bei der Öffnungszeit hat, - Plätze für besodere Benutzergruppen vorhanden sind, - ein Dach drüber ist. Dafür gibts ein herrvorragendes Proposal: parking:lane Wie groß, wie lang, wie breit, wieviele Stellplätze dort sind, ist einklich völlig wurscht, im Zweifel ist auch der größte Parkplatz zu 100 % belegt und die beiden Plätze für Rollifahrer sind auch besetzt, gerne von Leuten, die nur ehm schnell eine Kleinigkeit einkaufen. Ein Stündchen lang. Es gibt auch Menschen mit Parkhausphobie, die wollen genau von Stellplatz zu Stellplatz geleitet werden und keinesfalls in einem Autosilo landen. +1 steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
Am 23.07.2010 um 19:52 schrieb Fabian Schmidt: Hi, Am 23.07.10 schrieb steffterra: All diese Parkplätze sind eigentlich Parkstände/Stellplätze, wie ich hier lernen konnte. Doch warum in Gottes Namen heissen sie Parkplätze, wenn sie doch, im Sinne von dem was laut Wiki amenity=parking bedeutet, gar nicht sind? Sprache ist nicht logisch, sondern praktisch. Und dass man von der deutschen Sprache nicht auf andere schliessen sollte versteht sich fast schon von selbst. Stimmt. Wenn man auf Parkplatzsuche geht, würde man ja auch nicht ausschließlich nach einen großen Parkplatz suchen, sondern einen Einzelplatz, wo man sein Auto/Motorrad parken kann. Wie stellst Du Dir das mit einem Navi vor? Wenn in OSM entsprechende Daten über _alle_ Parkplatzmöglichkeiten mit allen ihren Unterschieden getaggt wären, dann könnte man auch danach im Umkreis eines Ziels suchen. Das Routing könnte alle Parkplätze/ Stände um das Ziel in geeigneter Weise entsprechend eines Parkpprofils auswählen und danach eine Parkplatzsuchen-Route erstellen. Das Parkwunschprofil könnte z.B. so ausshen: - in erster Priorität kostenlos und für max. 2 Stunden parken. In zweiter Priorität würde ich dann auch Parkhäuser und gebührenpflichtige Parkplätze anfahren. Also sucht das Navi die Parkplätze/Stände in entsprechender Reihenfolge zusammen und ich fahre sie ab und sehe dann vor Ort, ob was frei ist, oder nicht und kann mich dann immernoch für das Parkhaus entscheiden. Wenn ich natürlich vorher schon weiss, dass ich in ein Parkhaus möchte, weil mich die restliche Suche zu viel Zeit kostet, dann lasse ich mich halt zu diesem nächstgelegenen Parkhaus routen. Wäre doch toll, oder? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Sprachverständis Parkplatz im Deutsche n
Hi, ich möchte damit weder provozieren, noch die 'alte Diskussion wieder hochkochen lassen. Erlaubt mir aber dennoch folgende Frage: Warum weiss jeder in Deutschland, dass - ein Behindertenparkplatz kein großer Parkplatz für Behinderte ist (in der Größe von amenity=parking) - ein Frauenparkplatz kein goßer Parkplatz für Frauen ist - ein Elternparkplatz kein großer Parkplatz für Eltern mit Kindern ist - ein Motorrardparkplatz kein großer Parkplatz für Motorräder ist All diese Parkplätze sind eigentlich Parkstände/Stellplätze, wie ich hier lernen konnte. Doch warum in Gottes Namen heissen sie Parkplätze, wenn sie doch, im Sinne von dem was laut Wiki amenity=parking bedeutet, gar nicht sind? Bitte klärt mich mal auf, wie sich das mit der derzeitigen Philosophie hinter amenity=parking=großer Parkplatz verträgt und wie man das am besten Neuusern verklickert, die geneigt sind aus obigem Grund natürlich überall ein amenity=parking hinzubauen und einen Key für die Art des Parkplatzes (disabled, women, parent, motorbike) hinbauen. Ich habe mal spontan ein paar Leute gefragt, die nichts mit OSM am Hut haben, die mir alle sagten: klar sind das alles im deutschen Sprachgebrauch Einzel-Parkplätze, aber natürlicherweise sagt jeder Parkplatz. Wenn man auf Parkplatzsuche geht, würde man ja auch nicht ausschließlich nach einen großen Parkplatz suchen, sondern einen Einzelplatz, wo man sein Auto/Motorrad parken kann. Ich bin trotz vorangegangener Diskussion deshalb immer noch der Meinung, dass hier irgendwas schief läuft. Da ist doch ein grundlegender Denkfehler im System. Versteht Ihr, was ich meine? Wie kann man das ausmerzen? Durch Einzeltags für alle oben aufgeführten Parkplatzarten (und allen die mir jetzt nicht einfielen), ist es doch nicht getan, oder? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 22.07.2010 um 10:36 schrieb Tobias Knerr: Am 22.07.2010 02:50, schrieb steffterra: Wenn ich eine Software zur Suche von Parkplätzen bauen müsste, dann würde ich diesen, so lange so interpretierten, Tag auch so interpretieren, wie er mal war. Das versteht sich von selbst. Wenn dann jemand einen kley dranbaut, der was anderes sagt, ist klar, dass es vorher falsch getaggt war, weil es ein Parkstand war... Wenn du diese Software bereits gebaut hättest, müsstest du sie dann natürlich umbauen, damit die Software beim Vorliegen eines solchen Zusatztags das für ihre Zwecke irrelevante Objekt auch tatsächlich ignoriert. Automatisch geht das nicht. Warum müsste ich die Software umbauen, wenn ein tag immernoch so interpretiert werden soll, wie er ist. Ich müsste lediglich eien Bedingung einfügen: wenn kein Zusatztag/Key vorhanden ist - alte Interpretation. Und wenn Key parking_area vorhadnen, gleiche interpretatioen - Parkplatz mit ways. Dass ich natürlich für die Unterstützung der keys auch deren Nichtnennung mit programmieren muss, ist klar. Das ist Teil der Erweiterung auf die keys, die sagen, um welche Parkmöglichkeit es sich handelt. Doch dass ohne key das gleiche gilt, wie mit parking_area-key ist nicht die große Kunst. Selbst wenn die keys später mal etabliert wären und jemand vergisst einen anzuhängen, ist es immerhin erst mal ein Parkplatz alter Bedeutung - sofern man dann noch die alte Interpretation nicht irgendwann mal abgeschafft hat. Wir würden uns nicht streiten, wenn es nicht darum ginge einen tag zu einem Überbegriff zu machen. Wenn amenity=parking schon ein überbegriff mit keys wäre, wäre es ein Kinderspiel, einfach einen neuen key einzuführen. amenity=parking ist bereits ein Überbegriff mit einem Key parking für Unterkategorien: Da stehen dann solche Dinge wie surface, multi-storey und underground drin, also die /Bauart/ der Parkmöglichkeit. Ja, aber diese bestehenden Unterkategorien parking:underground, parking:multi_storey, etc. fügen sich nahtlos in das system der neuen keys ein: parking:parking_area, parking:parking_space, etc.) Wo ist das Problem? Das bitte beim Erfinden neuer Unterkategorien berücksichtigen, damit es nicht auch noch Konflikte mit der Bauartbeschreibung gibt. Habe ich. s.o. ;-) Angst! Arbeit! .. oder wie? Wenn man hier zusammenhalten würde und sich nicht jeder als Einzelkämpfer (der für seine Art zutaggen kämpfen würde) sondern vielmehr gemeinsamen nach _guten_ Lösungen (mit freiem Kopf!) gesucht würde, dann könnte man das auch stark gemeinsam flächendeckend umsetzen. Wenn ich deine Lösung gut und den Aufwand wert fände, würde ich sie gerne auch flächendeckend mit umsetzen. Ich behaupte nicht das Ei des Columbus gefunden zu haben, sondern den Kopf frei zu machen, von bisherigen OSM-Beschränkungen, aus denen man nicht herauskommt, wenn man sich bei seinen Argumenten immer wieder darauf bezieht. Und letzteres nur deshalb tut, weil man weiss, selbt wenn mal jemand eine guten Vorschlag macht, hängt man eh alleine dran es umzusetzen. Es gibt hier aber nur endlich viel Arbeitskraft. Die kann man jetzt entweder in immer wieder neue Umbenennungen, Modifikationen und Ergänzungen existierender Tags stecken (mit fast keiner anderen Wirkung als einer subjektiv schöneren Sortierung). Nein, es geht nicht um schön oder hässlich, sondern um praktisch zu mappen, einfach zu verstehen, Neueinsteigereinfachheit, und letzendlich leichteres Auswerten. Leider hast Du den Absatz nicht zitiert: Eine Parkplatz/Parkstand/Stellplatz-Datenbank ist viel leichter aufzuziehen, wenn man nicht darauf achten muss, wieviele unterschiedliche Tags es fürs Parken gibt. Einfach den amenity nehmen, auslesen, welche keys dazu gemappt wurden und gut ist. Aber das wäre wohl zu fortschrittlich gedacht. Es ist einfacher, 1 bis 5 neue Tags für ähnliche Dinge einzuführen. Eben weil sich das in der Community leichter durchsetzen und umsetzen lässt, als etwas, was zwar besser wäre, aber mal richtig Arbeit verursachen würde. Oder man kümmert sich um Dinge, die bislang noch *überhaupt nicht* vernünftig eintragbar sind. Wie eben die Linienbündel, die du ja auch ansprichst. Oder verbessert die Software. Und so weiter. Linienbündel nach den Proposals fände ich gut, doch schwieriger umsetzbar als meinen Vorschlag mit der Gruppierung, da sie mit der aktuellen DB erreicht werden kann und nur um eine Datenart für die Gruppierung ergänzt werren muss. Es muss laos nichts neues erfunden werden, und man muss nicht wieder auf Relationen zurückgreifen, die wieder Einarbeitungszeit benötigen und abstrakter sind ,als das, was JOSM mit entsprechender Erweiterung dann kann. Und das wichtigste: Es wäre abwärtskompatibel. Man müsste nicht alles umtaggen, sondern _könnte_ es dort tun, wo es sinnvoll wäre. Wenn ich die Linienbündel richtig verstanden habe, treffen mehrere Punkte davon aber leider zu. Ich bevorzuge Themen und Tätigkeiten der letzteren
Re: [Talk-de] Behindertenparkplatz
Am 22.07.2010 um 12:50 schrieb Guenther Meyer: On Thu, Jul 22, 2010 at 12:02:27PM +0200, Thomas Ineichen wrote: Guten Tag steffterra, Ganz klares Versagen der Software in Kombination mit fehlenden keys oder eigenen Tags für unterschiedliche Parkmöglickeitsarten. Ganz klares Versagen der Entscheider dieses Tag auch für einzelne Parkplätze zu nutzen in Kombination mit fehlender Rückwärtskompatibi- lität. So oder so ähnlich könnte man das *auch* sehen.. :- ERST braucht man ein sauberes, definiertes Datenmodell, DANN eine Anwendung die die Spezifikation entsprechend nutzt. Bei OSM hat man in den meisten Bereichen weder das eine noch das andere. Stimmt. Und jeder Versuch daran etwas zu ändert, krankt daran, dass man lieber schnelle Ergebnisse beim Einführen neuer Tagging-Methoden hat, auch wenn diese dann eine schlechtere Umsetzung bedeuten. Aber da es trotzdem irgendwie funktioniert, kann man ja so weiterwurschteln wie bisher... +1 meine volle Zustimmung! Danke! stefferra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 22.07.2010 um 13:23 schrieb Thomas Ineichen: Hallo Guenther, ERST braucht man ein sauberes, definiertes Datenmodell, DANN eine Anwendung die die Spezifikation entsprechend nutzt. So kann man aber nur vorgehen, wenn man etwas völlig neues erfindet, z.B. das Tagging von Parkständen entlang der Strasse. Bei amenity=parking ist das Kind aber nun mal bereits in den Brunnen gefallen.. Gar nichts ist in den Brunnen gefallen. Wenn man amenity=parking vom großen Parkplatz mit Wegen umdefiniert zu Parkmöglichkeit im allgemeinen und für den großen Parkplatz eine Key parking:parkin_area einführt, dann kann jede Software sehr einfach zur Erweiterung auf die anderen keys auch filtern: ohne key = mit key parking_area = großer Parkplatz, zumindest für eine Übergangszeit, bis der key parking_area (z.b. laut tagwatch) gut etabliert ist. Ein Jahr darf da gerne vergehen, kein Problem. Bei OSM hat man in den meisten Bereichen weder das eine noch das andere. So ist OSM eben. Inkl. den postitiven und negativen Auswirkungen. Man könnte daran etwas ändern, sogar so, dass es abwärtskompatibel ist (z.B. durch meinen Gruppierungsvorschlag für Fahrspuren-ways, aber beim Behindertenparkplatz offtopic). Aber das ist natürlich schwieriger in der Community zu bewerben als ein paar neue Tags. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 22.07.2010 um 13:28 schrieb Thomas Ineichen: Hallo steffterra, Wenn du diese Software bereits gebaut hättest, müsstest du sie dann natürlich umbauen, damit die Software beim Vorliegen eines solchen Zusatztags das für ihre Zwecke irrelevante Objekt auch tatsächlich ignoriert. Automatisch geht das nicht. Warum müsste ich die Software umbauen, wenn ein tag immernoch so interpretiert werden soll, wie er ist. Ich müsste lediglich eien Bedingung einfügen: wenn kein Zusatztag/Key vorhanden ist - alte Interpretation. Und wenn Key parking_area vorhadnen, gleiche interpretatioen - Parkplatz mit ways. Das *IST* bereits ein Umbauen der Funktion. Das alte Programm kann mit 'Deinem' Schema nicht mehr benutzt werden, weil es den capacity-Key nicht kennt. Eine _alte_ Software würde einen neuen Key genauso interpretieren, wie wenn er nicht da wäre, weil die alte Software den key nicht kennt - sie würde ihn ignorieren. Wo ist das Problem? Ausserdem ging es um den parking:parking_area/parking:parking_space-Key ... macht aber nix, ist ja nur ein Beispiel. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 22.07.2010 um 14:04 schrieb Thomas Ineichen: Die 'alte' Software sucht nach amenity=parking und interpretiert dies als 'grosser PP'. Problem nun erkannt? Die ganze Zeitz, nur die Argumente fand ich nicht ausreichend, dass man es deshalb nicht machen sollte. Das soll die alte Software doch auch es als großen PP interpretieren. Solange die keys nicht etabliert sind, ist das ja auch korrekt, weil die Millionen von amenity=parking auch große Parkplätze sind, aber eben viele kleine auch, was genauso falsch ist. Irgendwann muss man halt jede Software auch anpassen. Ich verstehe was Du meinst, sehe es aber nicht als Problem, da es dem Fortschritt dient, genauso wie neue Tags in einer alten Software nicht vorhanden sind. Gut, dann wird zumindest ein alter Tag nicht falsch interpretiert. Aber dafür wird es ja auch dokumentiert. Und wenn man seine Software für einProjekt wie OSM, das ständigem Wandel unterlegen ist, geschrieben hat, dann weiss man, dass man ab und zu mal Anpassungen vornehmen sollte. Ich wäre dann als Softwareentwickler froh, nun einfach nach den Unterkategorien sortieren zu können, anstatt mir die tags zusammensuchen zu müssen. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Tanzschule taggen?
Am 22.07.2010 um 21:49 schrieb Johannes Huesing: Chris66 chris66...@gmx.de [Wed, Jul 21, 2010 at 09:41:26PM CEST]: Am 21.07.2010 21:32, schrieb Andreas Tille: das Subject sagt's schon: Wie taggt man eine Tanzschule? amenity=dance_school ? Laut tagwatch immerhin 8-mal in DE verwendet. Es gab hier eine längere Diskussion, ob man sie als Unterbegriff von school fassen soll, die Mehrheit war aber eher dagegen. Genau, blos nicht alles, was mit Schulen und Lehren/Lernen zu tun hat unter dem Überbegriff Schule zusammenfassen. Keine Ski-Schule, Box-Schule, Sprach-Schule, Volkshochschule, etc. Das ist genauso unpraktisch wie bei Parkplätzen/Parkständen/Stellplätzen ... Einzeltags sind viel besser, weil man dann in einem großen Schulhaus mehrere Schul-Arten durch ihre Einzeltags als Nodes eintragen kann. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 21. Jul 2010 um 08:11 schrieb Guenther Meyer d@sordidmusic.com:Am Dienstag 20 Juli 2010, 14:38:40 schrieb lulu-...@gmx.de: Hier ist die Lösung, die sauber funktioniert:http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces Es wird getaggt: amenity=parking capacity=1 capacity:disabled=1 und optional: capacity:standard=0 So funktioniert es sauber und widerspruchsfrei.+1zum Thema Parkplatz vs. Parkstand:sorry, fuer mich ist das jeweils ein Ort, wo ich mein Fahrzeug abstellen kann,der Zweck ist exakt derselbe. Weder der Anwender noch die StVO-Beschilderungmacht da einen Unterschied. Deshalb sehe ich auch keinen Sinn drin, das in OSMzu unterscheiden.+1Eben, warum für jede Unterart einer Parkmöglichkeit ein eigener Tag, wenhn es auch mit keys ginge???Und wo wir gerade dabei sind. "Parking heisst zwar übersetzt "auch" Parkplatz. Gibt man aber "Parkplatz" bei leo ein, ist das nicht gerade der Top-Score:http://dict.leo.org/ende?lp=endelang=desearchLoc=0cmpType=relaxedsectHdr=onspellToler=search=ParkplatzDennParking wird im allgemeinen (nicht OSM derzeit ;-) mit "einer Parkmöglichkeit im allgemeinen" übersetzt. Das heisst, auch Stellplätze/Parkstände werden so benannt, wenn man sie nicht direkt übersetzt, sie fallen halt darunter, genauso wie der große Parkplatz auch.Der große Parkplatz heisst direkt übersetzt"car_park" oder was ich fast "schöner" finde: "parking_area". Ein einzelner Stellplatz direkt wird als "parking_space" übersetzt. Wieso könnt ihr damit in den keys nicht leben? Also auch der große Parkplatz bekommt einen Key.Durch Keys lassen sich alle Unterarten darstellen. Um einen bestimmten Bereich innerhalb eines großen Parkplatzes als besonderen Parkstand wie zb den Behinderten-, Eltern-, Frauenparkplatz, etc. kann man diesen doch zusätzlich dort taggen, z.B. in einem node. Wo ist das Problem, das wolltet ihr doch auch als ihr einen eigenen Tag angestrebt habt. Dass der Rednerer dann 4x ein" P" draufmacht? Sorry, dann mauss er halt 4x ein anderes P draufmachen...Deshalb _würde_ ich einen großen Parkplatz so taggen und das Wiki am besten auch gleich umschreiben, denn das ist überaltet und stammt aus der Zeit, wo man froh war, wenn wenigstens die großen Parkplätze getaggt wären.:amenity=parkingparking:parking_areacapacity:standard:500capacity:disabled:2capacity:women:10capacity:parents:10wenn man nun an einer bestimmten Stelle den disabled hinstellen möchte dann an dem Node (oder zwischen zwei nodes des service):- am node:amenity=parkingparking:parking_spacecapacity:disabled=2und weil parking in dieser mail als Überbegriff für Parkmöglickeit ist, ist dafür auch ein extra tag überflüssig, da der key aussagt, um welche Parkmöglichkeit es sich hier handelt- wem der Node zu ungenau ist, kann es auch gemäß Proposal service zwischen zwei nodes taggen:service=paring_aisleparking:parking_spacecapacity:disabled=2oder wenn man die Seite des sevice noch angeben möchte, dann gemäß Proposal:service=parking_aisleparking:lane:leftcapacity:disbled=2Aber ja- ich vergaß, was lange in OSM so drin ist (parking=grßer Parkplatz mit Wegen dazwischen) darf auch nie, nie nie mehr geändert werden aber dass es gar nciht so schlimm wäre, wenn der große Parkplatz nur am Key erkennbarv wäre, weil alle bisher gezeichneten Parkplätze serh leicht mit dem Key versehen werden könnten. Und solange ist es ja auch nciht falsch, wsenn man weiss, dass das eine Parkmöglichkeit ist, die laut capacity 500 Plätze hat. Dann weiss man - bis jemand den key nachliefert - auch aus dem Hirnschmalz heruas, dass das ein grßer, groooßer Parkplatz ist.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 21. Jul 2010 um 08:55 schrieb Markus liste12a4...@gmx.de:Hallo Tilmann, Ist es ok, mit Relationen eine relationale DB-Struktur zu simulieren? Also Objekte zu Klassen zusammenzufassen? Siehe http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Also Relations sind keine Sammlungen von Daten mit den selben Eigenschaften. Dazu entgegen habe ich folgendes gefunden: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults (aber mangels Übersetzung nicht genau verstanden) Ist das eine "gute" Relation? Und wenn ja: wofür genau?Dir sei das ans Herz gelegt:http://wiki.openstreetmap.org/wiki/DE:Relations/Relations_are_not_Categoriesund natürlichhttp://wiki.openstreetmap.org/wiki/Relationensteffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 21. Jul 2010 um 09:49 schrieb Ulf Lamping ulf.lamp...@googlemail.com:Am 21.07.2010 09:35, schrieb Bernd Wurst: Am Mittwoch 21 Juli 2010, 09:06:25 schrieb Ulf Lamping: In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben, einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit Jahren im Wiki. Was ist für den Nutzer der Unterschied zwischen einem Parkplatz und einem Parkstand? Abgesehen von der Wahrscheinlichkeit, einen freien Platz zu finden. Das ist bereits einer der Gründe. "Hinterm Parkplatz links rein" als "Webbeschreibung" kann man vergessen, wenn auf der Karte überall Parkplätze drinstehen.Wenn das Deine Art ist Wege zu beschreiben, wie kommst Du dann mit den vielen Straßen zurecht? Nix für ungut.Und dass es vieel Parkplätze gibt, liegt an den vielen Autos und die Straßen, ja die kommen auch daher ...Und dass Du sie nicht gescheit auf eienr OSM-Karte von einander unterscheiden kannst, um daraus eine Wegbeschriebung machen zu können, liegt nur am Renderer - einzig und alleine daran. Denn taggen kann man vielens, mit eigenem Tag oder als key - dargestellt werden muss beides sauber.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische R ichtungsfunktion in OSM?
Am 21. Jul 2010 um 10:16 schrieb Peter Körner osm-li...@mazdermind.de: Am 19.07.2010 23:58, schrieb Tirkon: Wie ich schon schrieb: Linienbündel könnten auch in diesem Fall helfen Nur mal aus Interesse (bitte nicht als Kritik missverstehen): würdest du auch solche Feldwege mit zwei Linien abbilden? Fahren kann man ja in beiden Richtungen drauf..nana, siehst Du da zwei Fahrspuren? Ich meine nicht Fahrrinnen von den Rädern ;-)Wie steht es mit kleinen Landstraßen, die keine Mittellinie haben, und solchen, deren Mittellinie schon abgefahren ist?Dort wo Fahrzeuge sich so begegnen können, ohne dass einer dabei halb in eine Straßengraben fahren muss hat zwei Fahrspuren, oder?Es ist hier schwer die Grenze zu ziehen, denke ich.Das ist zwar richtig, aber zum Glück haben wir alle eine Kopf zum denken.wäre ein definiertes Taggingschema für Richtungsabhängige Tags, z.B. durch vier Namensräume in den Tags: right, left, forward, backward. Die Tags könnten dann so aussehen:Das gibts in diverser Praxis und Proposals ja auch schon. Das problem ist nur, dass es an der Richtung des eingezeichneten way liegt und wehe einer dreht was. Unmd ja, JOSM warnt, aber ein Problem bleibt es dochforward:maxspeed=30 right:parking=yes es ist dann klar, dass bei einer Richtungsänderung aus allem was mit forward: getaggt ist ein backward werden muss. Leider ist "forward:maxspeed" weiter von "maxspeed" entfernt als "maxspeed:forward", weshalb das letztere häufige verwendet wurde. Generell wäre es möglich die definition von right, left, forward und backward von der Wegrichtung zu lösen: Wenn ein Tag "direction" vorhanden ist, wird der statt der eigentlichen Weg-Richtung verwendet. Was "direction" jetzt genau enthält bleibt zu Diskutieren: Eine Himmelsrichtung, eine Node-Nummer, einen Ortsnamen - sexy wäre das schon:viel zu kompliziertes Regelwerk.Ein Linienbündel würde die Tags vereinfachen, doch solange ein Steve Coast Co. das bisherige Schema nciht erweitern wird es die Community nicht von selbst regeln. Dax gibts zuviele Diskussionen, bei denen man alle viertel Jahr immer wieder genau über dieses Thema redet. Ich glaube auch, dass wir deutschen zu viel wollen. Ich glaube die Engländer sind froh, dass überhaupt ne Straße getaggt wurde udn gehen lange nicht so ins Detail. Wir korrekten Deutschen halt wieder... ;-)Die Anwendungen werden es aber nötig machen und wenn sich da nix tut, weils keiner durchzieht, werden wir noch in Jahren darüber diskutieren, ob Relationen, forward oder rechts getaggt werden muss, um eine Reichtung zu beschreiben.Das mit der destination war mir neu (nicht der tag, sondern dass man daran die richtung festmacht). Das ist komplett unmöglich, weil Du dann ein Problem in Wohjngebieten hast. Oder machst Du dann destination "Zahnarztpraxis sowieso" rein? Nene, das geht nicht am destination-tag Der ist für sowas auch gar nciht gedacht und geeignet, da er die richtung zu einer Stadt (Autobahnauffahrt/Autobahn/Abfahrt) oder besonderer Einrichtung (Stadion, Bahnhof, etc.) und nicht um daran forward festzumachensteffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 21. Jul 2010 um 11:39 schrieb yzemaze yzem...@gmx.net:On 21.07.2010 09:35, Bernd Wurst wrote: Am Mittwoch 21 Juli 2010, 09:06:25 schrieb Ulf Lamping: In OSM wurde amenity=parking bislang explizit als Parkplatz beschrieben, einzelne Parkstände wurden nicht gemappt - so stand es zumindest seit Jahren im Wiki. Was ist für den Nutzer der Unterschied zwischen einem Parkplatz und einem Parkstand? Abgesehen von der Wahrscheinlichkeit, einen freien Platz zu finden. Gruß, Bernd e. g. Kollateralschäden: http://gis.638310.n2.nabble.com/forum/PostLink.jtp?post=5320106 On 21.07.2010 10:15, Chris66 wrote: Ich hatte vorgestern in Lingen mit meiner Garmin OSM Karte den Bahnhof Lingen gesucht, aber nicht gefunden, weil ja in dem Untermenü "Finde Transport" jeder Parkplatz, jede Bushaltestelle (teilweise doppelt) usw. drin ist.Ganz klares Versagen der Software in Kombination mit fehlenden keys oder eigenen Tags für unterschiedliche Parkmöglickeitsarten.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 21. Jul 2010 um 22:20 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: Zusammenfassend meine Sicht: Es ist sinnvoll, zwischen den folgenden 3 Fällen zu unterscheiden: a) 'grosse' Parkplätze/Parkhäuser b) Parkmöglichkeiten entlang von Strassen c) einzelner, isolierter Parkplatz (für 1, 2 Autos) bzw. "Ausnahme- Gruppen" innerhalb von grösseren Parkplätzen Bei gezielter Einführung von c) kann die ganze Gruppe ein gemeinsames 'amenity'-Tag erhalten, welches mit den bekannten capacity:* erweitert wird.+1sieeh meine mail diesbezüglich, dass parking n ciht parkplatz, sondern "ein Ort, wo man parken kann" heisst. und dann der große Parkplatz den key "parking_area" und der Parkstand/Stellplatz den key "parking_space" bekommt. Ich sehe da keien Probleme - auch nciht ,wenn man letzteres auf dem ersteren auf einem node unterbringen möchte.steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 22. Jul 2010 um 01:23 schrieb Ulf Lamping ulf.lamp...@googlemail.com:Am 22.07.2010 00:18, schrieb steffterra: Aber ja- ich vergaß, was lange in OSM so drin ist (parking=grßer Parkplatz mit Wegen dazwischen) darf auch nie, nie nie mehr geändert werden aber dass es gar nciht so schlimm wäre, wenn der große Parkplatz nur am Key erkennbarv wäre, weil alle bisher gezeichneten Parkplätze serh leicht mit dem Key versehen werden könnten. Und solange ist es ja auch nciht falsch, wsenn man weiss, dass das eine Parkmöglichkeit ist, die laut capacity 500 Plätze hat. Was kannst du denn dann *nach* dieser Umdefinition aus einem amenity=parking herauslesen? Ein irgendwie gearteter Platz wo ich irgendwas drauf parken kann.Die Zeit wird es brignen und dann hat es jeder mitbekommen, dass OSM fortschrittlicher wurde.Bislang konnte ich draus lesen, das dort wohl eine (größere) Fläche ist, auf der man Autos parken kann. Irgendwie ist da alleine für 30 Einträge in Europa dann einiges an Informationen verloren gegangen.Schaltet ihr alle Euren Kopf aus, wenn sich was ändert im wiki? (nicht böse gemeint und schon gar nicht persönlich) Natürlich muss man amenity=parking so interpretieren, wie es bisher war, bis jemand einen Zusatzkey dranmacht ist es immer noch der gute alte große Parkplatz. *kopfschüttel*Wenn ich eine Software zur Suche von Parkplätzen bauen müsste, dann würde ich diesen, so lange so interpretierten, Tag auch so interpretieren, wie er mal war. Das versteht sich von selbst. Wenn dann jemand einen kley dranbaut, der was anderes sagt, ist klar, dass es vorher falsch getaggt war, weil es ein Parkstand war... Wenn jemand "parking_area" dran baut, ist es eine Bestätigung. Wo um himmels wilen ist euer Problem?Mann, geht mal an die frische Luft. Ich will ja hier keinen beleidigen, aber das ist der Grund, warum sich nichts bewegt.Also kein tag - alte Interpretationkey dran - Interpretation nach keyWo ist das Problem? Kann man doch auch im Wiki so festhalten. Dann weiss es jeder, dass amenity=parking ohne Zusatztag/key ein großer Parkplatz ist - ist das denn so abwägig?Ja, wenn dir nicht bewußt (oder es dir egal) ist, was eine Umdefinition eines Tags an Konsequenzen bedeutet ist das alles auch überhaupt kein Problem.Es ist eben eine Frage dessen, ob man sein Hirn ausschaltet, wenn der Tag neu interpretiert wird, oder nicht. s.o.Wenn man sich aber überlegt, was notwendig ist um das ganze konsistent in die OSM Welt zu bringen:Genau deshalb wird nichts in die Welt gebracht. Genau wegen solcher Argumente. Natürlich hist es einfacher, etwas schnell schlecht umzusetzen, als groß aufziehen zu müssen und dafür eine geordnete Tagging-Struktur zu bekommen.Tausende von Einzeltags sind _nicht_ besser als ein Überbegriff und darin den passenden key suchen. Letzteres ist wesentlich flexibler, aber letzeres ist "besser" in der Einzelkämpfer-Marnier hier durchzusetzen.Wir würden uns nicht "streiten", wenn es nicht darum ginge einen tag zu einem Überbegriff zu machen. Wenn amenity=parking schon ein überbegriff mit keys wäre, wäre es ein Kinderspiel, einfach einen neuen key einzuführen. Aber man muss ja nicht an die Zukunft denken... Lieber immer wieder neu einen Tag durchboxen.Eine Parkplatz/Parkstand/Stellplatz-Datenbank ist viel leichter aufzuziehen, wenn man nicht darauf achten muss, wieviele unterschiedliche Tags es fürs Parken gibt. Einfach den amenity nehmen, auslesen, welche keys dazu gemappt wurden und gut ist. Aber das wäre wohl zu fortschrittlich gedacht. Es ist einfacher, 1 bis 5 neue Tags für ähnliche Dinge einzuführen.Wer bespricht diese semantische Änderung auf der englischen talk Liste (bislang habe ich dort kein Wort über diese Diskussion gesehen)? Wer bespricht diese Änderung auf allen anderssprachigen Mailinglisten? Wer kümmert sich darum, das diese Änderung im Wiki *konsistent* (über alle Sprachen) geändert wird? Wer kümmert sich darum, das alle relevanten Kartenrenderer diese Änderung mitbekommen? Wer kümmert sich darum, daß Editoren ihre Presets entsprechend anpassen? ... und ich hab mit Sicherheit noch so einiges vergessen.Angst! Arbeit! .. oder wie? Wenn man hier zusammenhalten würde und sich nicht jeder als Einzelkämpfer (der für "seine Art zutaggen" kämpfen würde) sondern vielmehr gemeinsamen nach _guten_ Lösungen (mit freiem Kopf!) gesucht würde, dann könnte man das auch stark gemeinsam flächendeckend umsetzen.Wenn man natürlich weiterhin weiss, hier eh auf sich alleine gestellt zu sein ... Na danke...Hier auf der Liste tolle Vorschläge zu machen ist recht einfach.Irgendwo muss man ja mal anfangen, sich andere Meinungen anzuhören. Nur so langsam merke auch ich, dass hier viele eben nicht an das denken, was aus osm werden könnte, sondern, wie man am besten alles in das derzeitige Schema presst. Man merkt das es bei richtungsabhängigen Sachen eigentlich immer konfuser wird, weil tagging-ketten keine bessere Lösung als Relationen sind,
Re: [Talk-de] unechte Einbahnstraße
Am 19.07.2010 um 21:56 schrieb M∡rtin Koppenhoefer: An einer Kreuzung sind _alle_ Schilder ein Stueck weit von der Kreuzung entfernt plaziert. ... ja eben Das Stueck weit resultiert aber aus rein praktischen Gesichtspunkten, da man eben schlecht das Teil direkt auf die Kreuzung plazieren kann ... +1 Was mich an dieser Diskussion stört ist, dass man dazu neigt, alle Schilder in einen Sack zu schmeissen. Schilder, die die Vorfahrt an einer Kreuzung regeln gelten selbstverständlich an der Kreuzung an der sie stehen und nicht erst am dem Punkt, wo man sie hingestellt hat Wir reden hier aber die ganze Zeit über das Einfahrtverbotsschild. Und das gilt halt nunmal da, wo es steht, bzw dort, in 50m wenn es das Zusatzschild sagt. Dann gibts noch Schilder, die so lange gelten, bis wieder ein Einmündung folgt (z.B. Vorfahtsstraßenschild), sie gelten aber ab da, wo sie stehen, nämlich nach der vorherigen Einmüdung. sie stehen niemals vor der Einmündung. Bei Kreuzungen ist das anderes. Da stehen die Vorfahrtsregelnden Schilder , wo auch die Ampel steht. Aber solche Feinheiten werden in der Fahrschule anscheinend nicht mehr gelehrt. Also bitte jedes Schild so interpretieren, wie es in der Wirklichkeit seine Gültigkeit hat und nicht alles in einen Sack schmeissen, nur um es als Argumentation verwenden zu können. Danke. keineswegs. Bei dem Schild handelt es sich um Verbot der Einfahrt, und das kann überall stehen, mit Kreuzungen hat das nichts zu tun. Man darf das Schild nicht in Richtung des Schildes passieren. +1 s.o. Ein Schild, das am Beginn einer Strasse steht, steht genau da: am Beginn der Strasse. Da die Strasse am Kreuzungsknoten beginnt, gilt es daher ab dem Kreuzungsknoten. nope -1 Erbsenzaehlen tue ich gerne da, wo es auch notwendig und sinnvoll ist, wo ich also wirklich ausdruecken will, dass es wichtig ist, dass ein kleines Stueck Weg andere Eigenschaften hat. Ansonsten muesste ich auch alle Speed-Bumps, Zebrastreifen etc. nicht mit einem einfachen Knoten, sondern mit einem Mini-Stueck Weg modellieren, da ja alles eine gewisse Ausdehnung aufweist. kommt drauf an, Ausdehnungen in die Breite sind m.E. eigentlich erst sinnvoll, wenn Du die Straßenfläche auch drin hast. In der Länge würde ich dagegen durchaus auf Präzision achten. +1 Du siehst das deutlich eingeschraenkter, wobei mir beispielsweise nicht klar wird, wo die Strasse nun bei einer Kreuzung fuer dich nun anfaengt (bzgl. des Schildes oder allgemein): - am Kreuzungsmittelpunkt, - am Schnittpunkt der verlaengerten Fahrbahnbegrenzungen der Querstrasse mit der Mittellinie der Strasse, - am Ende der Eckausrundung, Was hat diese Diskussion mit dem Thema des Threads zu tun? das spielt für die Frage hier keine Rolle, +1 steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
Am 19.07.2010 um 23:04 schrieb Tirkon: Mitunter ist es offenbar absichtlich ein paar Meter in die Straße hinein gestellt, z.B. um es wahrnehmen zu können und das Wenden zu ermöglichen, Eben und genau aus dem Grunde gilt das Einfahrtverbotsschild ja auch erst ab da, wo es steht. Sonst dürfte man ja nicht bis dahin fahren, um überhaupt ans Wenden denken zu können ;-) um vorne liegende Ziele noch erreichen zu können oder dort abseits einer stark befahrenen Straße als Nothaltebucht zu nutzen. Insofern würde ich es da mappen, wo es steht. +1 eben. Etwas anders wäre beispielsweise das Geisterfahren falsch herum in eine Abfahrt hinein, Ich bin mir fast sicher, dass die StVO sagt, dass die Einfahrt _an dieser Stelle_ nicht erst ab dem Schild gilt. Es wäre auch zu gefährlich. sofern dies nicht ohnehin per durchgezogener Mittellinie angezeigt ist. Da sollte man auch die möglichen Meter nicht nutzen. Aber da taggen wir der Einfachheit und Übersichtlichkeit wegen ebenso wie einige andere Kartendienste ohnehin mit Einbahnstraßen. Auch weil es faktisch welche sind. Autobahnen und ähnlich ausgebaute Straßen müssen nur nicht extra dafür mit Einbahnstraße ausgeschildert sein, da die Verkehrsregelung für Autobahnen dies aussagt, dass man hier nur in einer Richtung fahren darf. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 20.07.2010 um 14:38 schrieb lulu-...@gmx.de: Hallo Liste, hallo Thomas, hallo Dietmar! Wie sollen diese Parkplätze getagged werden? Gegen amenity=parking capacity=1 capacity:disabled=1 sprechen meiner Meinung nach vorallem zwei Dinge: - Häufig stehen diese Parkplätze einzeln, z.B. direkt neben einem Eingang. Laut Wiki sollen mit amenity=parking aber nur grössere Parkplätze gekennzeichnet werden und nicht einzelne. - Auch wenn es nirgends explizit festgehalten ist, so verstehen sowohl die Renderer als auch die Router unter 'amenity=parking' einen Park- platz für 'normale' Autos. Ein Parkplatz für Fahrräder wird daher auch nicht mit als 'parking' mit 'capacity:bicycle=*' getagged sondern als 'amenity=bicycle_parking'. Hier ist die Lösung, die sauber funktioniert: http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces Es wird getaggt: amenity=parking capacity=1 capacity:disabled=1 und optional: capacity:standard=0 So funktioniert es sauber und widerspruchsfrei. Daher: Irgendwelche Einwände gegen amenity=disabled_parking capacity=1 Ja. Mit dem bestehenden Tagging ist alles möglich, was Du machen willst. Ja, da hab ich auch was dagegen. Tipp: Immer erst mal im Wiki nachlesen, was es schon gibt. Die Sachen sind da schon diskutiert. Hallo Lulu-Ann, vlt. konntest Du diese Diskussion nicht vollständig verfolgen. Ich erlaube mir, Dich mal auf den aktuellen Stand zu bringen, auch wenn ich voll Deiner Meinung bin. 1. Das Problem ist , dass hier manche sagen, ein Behindertenparkplatz sei, trotz seines Namens und dem Schild, das auch Parkplatz heisst, gar kein Parkplatz (deshalb sei amenity=parking, siehe wiki, falsch), sondern ein Parkstand. Sie möchten für Parkstände einen eigenen Tag. 2. Parkstände für Motorräder sollten auch einen eigenen Tag bekommen, weil sie nicht in die gleiche Kategorie wie Frauenparkplatz und Elternparkplatz fallen, die ja eigentlich für 4-rädrige KFZ sind ... 3. Ich bin genervt, da es für Parkstände (Definition siehe wikipedia bitte) aber schon ein Proposal gibt, das das per Tag für parking:lane regelt. Ich bin mittlerweile der Meinung, dass man die Defintion für amenity=parking auf Parkstände erweitern sollte, dann wäre es alles einfach zu taggen. Sowohl einzelne, als auch gemischte Parkplätze/Stände. Doch auch dies scheitert an zwei Tatsachen: 1. Wenn es eigene Tags für Frauenparkplatz, Elternparkplatz, Motorradparkplatz, Behindertenparkplatz usw. gäbe, dann könnte man diese auch per Node auf einem großen Parkplatz als POI eintragen, dass man auf der Karte auch sieht, wo sich diese jeweils auf diesem befinden. Eine Unterteilung des großen Polygon in kleinere (oder mit inner und outer-polygonen) mit entsprechendem Tagging für diese Spezialparkplätze, sei auch nicht in Ordnung, da es ja dann mehrere Parkplätze wären ,diese aber auf einem großen amenity=parking vereinigt sind und nur Parkstände innerhalb des amenity=parking sind. 2. Mein Vorschlag per parking:lane die Lokalisation des Behindertenparkplatzes auf dem amenity=parking zwischen zwei Knoten des service per parking:lane anzugeben scheiterte hier an dem Argument, dass das zu kompliziert zu taggen sein, wenn man eben mal ein paar Behindertenparkplätze eintragen möchte. Ich bin am Ende, denn es wird hier keine Lösung gefunden werden. Schon diskutiert, oder auch nicht, denn wenn amenity=parking nur explizit für Parkplätze mit parking_aisles gelten darf, wie dessen Exklusivität derzeit im wiki interpretiert wird. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] das Problem mit backward-forward und lef t-right - neues Datenmodell nötig!?
logisch und so dürfte die Einarbeitungszeit ungleich kürzer sein, als bisher. - Fahrspurentagging möglich wo nötig, aber nicht zwingend erforderlich. - Router könnten out-of-the-box einen Fahrspurassistenten bieten. - es wäre automatisch klar, wo man Ampel-nodes unterbringen kann, Überquerungen aller Art, Haltestellen zwischen Fahrspuren - Erleichterung für die Fußgänger-, Fahrradfahrer- und barrierefreien und Blinden-Navigation, da auch andere Wegarten eigene Fahrspuren bekommen könnten und so getrennt getaggt werden könnten - usw. Nachteile: - - sicher gibt es welche, wie z.B. das erhöhte Datenaufkommen - jemand müsste das in die DB einbauen und auch stufenweise in die populären Editoren. - schon einzelne Tags führen zu Tagelangen Diskussionen. Meint ihr, wir die OSM-Community könnten dennoch sowas umsetzen? - Das Wiki müsste nach und nach an die neue Situation angepasst werden. - usw. Beachtet, dass das Konzept nicht vorsieht, andere Wegarten zu gruppieren, sondern nur jeweils Fahrspuren innerhalb einer Wegart. Es kann also kein cycleway-Spur zusammen mit den highway-Fahrspuren gruppiert werden. Radwege werden nach wie vor an der äußersten Fahrspur getaggt, wie bisher auch - nur ohne dann unnötige Richtungsangabe. Vielen Dank, an alle, die bis hier gelesen haben. Für die anderen: Bevor Ihr urteilt, lest es bitte komplett, da die eine Frage vielleicht schon weiter unten beantwortet wird. Bitte macht mich gerne auf Denkfehler aufmerksam ;-) Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 19.07.2010 um 07:53 schrieb Martin Simon grenzde...@gmail.com: (auch ich bin der Meinung, daß man für Parkstände/Stellplätze ein eigenes tag benötigt..) Auch wenn diese Parkstände auf öffentlichem Grund mit einem Parkschild (evtl. sogar mit Parkscheiben-Zusatzschild) als Parkplatz gekennzeichnet ist? Und noch eine Frage: Was unterscheidet denn Deiner Meinung nach ein so ausgeschilderter Parkplatz von einem Parkstand auf öffentlichem Raum? Und noch eine: Waeum benötigst Du dazu unter diesen Umständen einen eigenen Tag? Würde da nicht ein capacity-Key dafür reichen? steffterra (P.S. Es gibt auch doppelt angelegte Stellplätze auf Privatgrund, also hat der capacity-Key auch hier seine Berechtigung!) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 19.07.2010 um 08:05 schrieb Guenther Meyer d@sordidmusic.com: Am Montag 19 Juli 2010, 07:53:22 schrieb Martin Simon: (auch ich bin der Meinung, daß man für Parkstände/Stellplätze ein eigenes tag benötigt...) und warum? die vorhandenen Tags bieten alles was man braucht. +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 19.07.2010 um 08:50 schrieb Martin Simon: Am 19. Juli 2010 08:20 schrieb steffterra steffte...@me.com: Auch wenn diese Parkstände auf öffentlichem Grund mit einem Parkschild (evtl. sogar mit Parkscheiben-Zusatzschild) als Parkplatz gekennzeichnet ist? Hast du den Unterschied zwischen Parkplatz und Parkstand verstanden? Die wikipedia-Definition, Du Du rezitiert hast ja. Du hattest nur nicht dazu geschrieben (kein Vorwurf, aber Grund meiner Nachfrage), dass das auch Parkstände sind, selbst wenn sie als _Parkplatz_ (so heisst das Schild nämlich, siehe http://www.sicherestrassen.de/VKZKatalog/Frameaufbau.htm?http://www.sicherestrassen.de/VKZKatalog/Kat314.htm) ausgeschildert sind. Fakt ist, dass Parkstände mit dem Zeichen 314 Parkplatz ausgeschildert sind. Das macht sie zu einem Parkplatz, sonst wäre das Schild ja überflüssig. Das Schild sagt laut StVO Hier ist Parken erlaubt. Ich sehe das Schild 314 Parkplatz, das auch an Parkständen Verwendung findet, gleichbedeutend mit der Erlaubnis zu Parken, so wie es der Gesetzestext auch sagt. Somit ist für mich amenity=parking Parkplatz im Sinne des Schildes und nicht der baulichen Gegebenheiten. parking heisst für mich deshalb im Sinne des Gesetzestextes zumindest in DE: Hier darf man parken Und dafür steht das Schild und der parking-Tag. Schau Dir unabhängig davon mal http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane an. Dort existiert ein sehr gut durchdachter Vorschlag, wie die ganzen Unterarten von parking getaggt werden könnten. Demnach wäre Dein Parkstand in parking:lane untergebracht. Mir ist bewusst, dass amenity=parking auf der Wikiseite mit dem großen Parkplatz mit seinen service=parking_aisle Keys. zumindest durch Beisspielbilder so dargestellt wird. Doch Du hast leider folgendes überlesen: amenity=parking kann sowohl als Fläche als auch als Punkt eingezeichnet werden. Für einen _einzelnen_ Parkplatz bitte entweder als Fläche oder als Punkt eintragen. Damit ist dann wohl ein Parkstand gemeint ;-) Des weiteren sind dort Keys beschrieben, die aus amenity:parking eine Tiefgarage (key:parking=underground) oder Parkhaus machen. Der Grund, dass es keinen eigenen Tag für Parkstände gibt, ist sicher auch in dem Wikieintrag zu suchen. Wenn ein Parkplatz keine parking_aisle's hat, dann ist es immer noch ein Parkplatz - auch ein einzelner. Und das Schild sagt ja auch: Parkplatz. Also klar, dass das noch keinen neuen Tag produziert hat, weil schlicht kein Bedarf bestand/besteht. In etwa genauso sinnvoll, wie die Praxis mancher, tausend einzelne Grundstücke mit landuse=residential zu belegen. Der Vergleich hinkt. Deiner Analogie nach wäre jeder einzelne Parkstand auf einem großen Parkplatz einzeln eingezeichnet und einzeln getaggt. Aber das macht nun wirklich keiner. Aber ich wollte mich eigentlich nicht in eure Diskussion einmischen - letztlich ist es mir recht egal. Ist doch kein Problem. diese Antwort ist ja auch nicht nur für Dich ;-) Nur schade, daß du anscheinend nur den Kommentar in Klammern gelesen hast und nicht den eigentlichen Inhalt, der dazu dienen sollte, daß ihr hier weniger aneinander vorbei redet... Ich denke schon, dass ich alles gelesen hat - udn ja, es sind immer die anderen Schuld, schon klar. Aber ich finde es gut, dass Du die Bezeichnung Parkstand' erwähnt hast. so habe auch ich etwas dazu gelernt. Ich halte nach längerer Überlegung übrigens nichts davon amenity=bicycle_parking in einer Untermenge von amenity=parking unterzubringen. Ich bin deshalb dafür, dass man amenity=parking exakter definiert und auf KFZ beschränkt (Motorräder werden dafür so vorgeschlagen: capacity:motorcycle=yes/no/number - http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces) . Aus den ganzen genannten Gründen heraus halte ich einen eigenen Tag für Parkstände für überflüssig. Schon weil er im Proposal Würzburg Parking mit parking:lane schon untergebracht ist. (s.o.) Danke und Gruß, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Am 19.07.2010 um 10:58 schrieb M∡rtin Koppenhoefer:
Am 17. Juli 2010 20:45 schrieb steffterra steffte...@me.com:
btw, die Wiki-Seite wird insgesamt komisch gerendert. Woran kann
das liegen? Sie war übrigens auch schon so, als ich sie heute das
erste mal sah ;-) Vlt. kann mal jemand drüber schauen und ggf.
mitteilen, woran das lag. Denn schon im Editiermodus ist das
Rednering der Seite eigenartig ist und auch im weiteren Text das
Textrendering von Fettschrift, innerhalb des Editierbereichs nach
dem Speichern nicht korrekt angezeigt wird.
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/De:Hausnummern
Habe den Fehler im Proposal gefunden und behoben. War aus dem
Januar 09 ;-) Danke dennoch.
Welchen Fehler?
Schau mal in die Version vor meiner Korrektur Da wird eine
Gliederungshierarchie eingeblendet ohne Text.
Der Fehler war in
=== Einzelnes Haus als Fläche ===
[[Image:HousePolygonNextToRoad.png]]
Ein [[Proposed_features/Building|Haus als Fläche]] wird so
gekennzeichnet:
{{Tag|building||yes}} (oder {{Tag|building|apartements}}, ...)
+ {{Tag|addr:housenumber||XXX}}
Ich habe statt dem XXX nun 10 eingegeben.
Schaus Dir in den Versionen an. ;-)
Du hast das ziemlich umgestrickt und viele Werte von
optional nach erforderlich geschoben:
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2FDe%3AHausnummerndiff=502805oldid=426114
ja, da sich in der Diskussion, die hier ja auch stattfand,
herausgestellt hat, dass _vollständiges_ taggen sinnvoll ist, um
Neuuser das Taggen von Hausnummern zu erleichtern. Siehe auch letzter
Absatz! Für ein _vollständiges_ Tagging gehören diese keys aber
nicht zu den optionalen, sondern sind nötig. Sowohl als Einzeltagging
am Gebäude/Adress-Node als auch einmal einer Adress-Relation
angehängt.
Ist also nicht falsch, sondern eine Aktualisierung des Proposal, oder?
Soweit ich weiss, waren wir uns hier darüber einig, dass einfach
ausschließlich _nur_ addr:housenumber zu taggen keinen Sinn macht, da
Spezialfälle nicht von Software erraten werden können. Aber das
kannst Du auch alles im Wiki-Absatz ganz unten nachlesen oder zur Not
in diesem Diskussionsstrang.
Wäre nun schade, wenn wir uns umsonst unterhalten hätten, und das
Ergebnis keinen Einfluss auf die Aktualisierung haben dürfte, wenn Du
es wieder löschst. Und: Es ist ein Proposed_Feature.
Das ganze nur in einer von 6 vorhandenen Sprachen.
Da sich das auf deutsche Hausnummern-Schemata bezog, habe ich es erst
mal nur dort eingetragen. Im Englischen sollte man noch einmal darüber
senieren, ob es komplett übertragbar ist. Können wir hiermit gerne
tun. Dann ist es auch dokumentiert und kann übernommen werden, wenn
dabei herauskommt, dass es Praxis ist wie bei uns auch.
Kannst Du das bitte
wieder rückgängig machen? Derart etablierte Schemata mal kurz (und
vor
allem unvollständig und ohne Diskussion)
s.o. ich verwiese auf diese Diskussion hier. Außerdem ist es nicht
unvollständig, da diverse Erläuterungen dabei stehen. Ausserdem steht
jedem frei diese Erläuterungen weiter um Sinnhaftigkeit zu ergänzen.
im Wiki zu ändern ist m.E. schädlich.
Nur aus Prinzip, oder weil es inhaltlich nicht stimmt? Für den
inhaltlichen Fall würde ich Dir zustimmen. Doch der ist Fakt und wurde
nun in Worte gefasst.
Daraus resultieren dann Widersprüche und Ungereimtheiten.
Welche siehst du denn? Es sind ausreichend Erläuterungen und Hinweise
gegeben worden. Welche Ungereimtheiten bleiben für Dich denn übrig?
Je häufiger ein Schema in Verwendung ist, um so sorgfältiger sollten
Änderungen vollzogen werden.
Das Schema wird ja nicht verändert sondern gewichtet und bietet für
Neuuser nun eine leichtere Ortientierung, welches die Anforderungen
heute sind und welches Schema er als Anfänger dazu am besten Nutzen
könnte...
Lies Dir bitte den letzten Absatz auf der Wikiseite durch. Bitte,
bevor Du urteilst. Falls Du dann der Meinung bist, diese Gewichtung
der einzelnen Möglichkeiten sei falsch, dann können wir das ja gerne
weiter diskutieren.
steffterra
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 19.07.2010 um 09:31 schrieb Friedhelm Schmidt: Was für einen eigenen Tag amenity=parking_space als node wäre z.B. eine Option. sprechen könnte ist, dass es auch eine schöne Möglichkeit wäre, die genaue Lage eines Behindertenparkplatzes innerhalb eines größeren Parkplatzes zu kennzeichnen. (Einen Punkt amenity=parking,... in einer Fläche amenity=parking fände ich eher unschön) Ich würde den dann auch eher als Punkt denn als Fläche vorsehen. Ein Renderer kann den dann in einer hohen Zoomstufe mit dem entsprechenden Symbol kennzeichnen. Nein, ein Node in einer Fläche ist bei gleichartigen Tags eher ungünstig. Ich würde den Bereich als outer-polygon (den Rest als inner) und darin eine neue Fläche mit den Behindertenparkplätzen entsprechend getaggt einzeichen. Was spricht dagegen? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 19.07.2010 um 11:48 schrieb Thomas Ineichen: ... So muss nur dieser eine in ein amenity=parking und capacity:bicycle=yes geändert werden und gut ists. Das kann sehr einfach ein bot erledigen, sobald dass Proposal angenommen wurde: http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces Hier bist Du Dir inzwischen ja selber untreu geworden und möchtest amenity=bicycle_parking behalten. Warum bloss? Das habe ich an anderer Stelle erläutert. Weil mit parking - man könnte eszumindest so definieren - KFZ-Parkplätze gemeint sind und nicht die von unmotorisierten Zweirädern. Dies wird auch dadurch gedeckelt, weil capacity:motorcycle als kex für amenity=parking im genannten Proposal vorgeschlagen wird und noch kein eigener Tag vorhanden ist. Bei bicycle ist es anders und kann dann gerne auch so bleiben ;-) Hübsches Beispiel, wie man eine Karte unbrauchbar macht: http://www.openstreetmap.org/?lat=41.97575lon=2.81843zoom=15layers=B000FTF Wenn das alles ausgezeichnete Parkplätze sind, ist es doch nicht falsch. Das Tagging kann auch nichts dafür, dass alle drei Renderer hier nicht unter verschiedenen Parkplatzarten unterscheiden. Dass tatsächlich Behindertenparkplätze darunter sind, kann man in JOSM einfach nachschauen. Das Tagging kann sich aber überlegen, wie man die Renderer zumindes- tens unterstützen kann. Ansonsten kann Mapnik nur entweder alle an- zeigen oder keine. Richtig, und deshalb zerbrechen wir uns ja den Kopf, ob z.b. das Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/More_Parking_Spaces nicht toll und ausreichend wäre. Und die Parkstände sind bereits in diesem Proposal untergebracht: http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane , das alle Features bietet, was eine Parkstand-Tagging bietet, um es z.B. für eine Navi zu ermöglichen, alle Anwohnerparkplätze bei der Suche nicht zu berücksichtigen - nur so als Beispiel. Und äh - wie war nochmal Deine Frage zu Beginn des Threads? Die steht glaube ich immer noch da.. :) Das war eine rhetorische Frage. Danke. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz-Die Lösung
Am 19.07.2010 um 13:05 schrieb Martin Simon: Das Proposal ist ja ok - dann verstehe isch aber nicht, warum du trotzdem amenity=parking auch für einzelne Parkstände verwenden willst. Wenn nur ein einzelner ganz alleine steht - dachte ich vor unserer Diskussion. So hatte ich es bisher mit dem Schild Parkplatz auch immer so verstanden. Für die Nomenklatur, die die StVO verwendet kann ich nichts und sorry, dass ich dem wohl erlegen war. Außerdem, was man dann im wiki auch mal klar stellen sollte (Soll/muss man das wirklich?) Es heisst dann auch nicht Behindertenparkplatz sondern Behindertenparkstand ... Oh mann... Nun würde ich einen einzelnen Behindertenparkplatz neben drei normalen (für Anwohnerparkausweis G) entsprechend des Proposals http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane so taggen: highway=residental parking:lane:right=inline capacity:standard=3 capacity:disabled=1 parking:condition:right=residents parking:condition:right:residents=G Das ganze natürlich zwischen den beiden Nodes, wo sich die vier Parkplätze - ähh Parkstände befinden. Alles klar. Nach so einer Lösung hattest Du doch gesucht, oder? Für den einzeln stehenden Behinderten-stand- aus Deinem Themenstart wäre es dann das: highway=residental parking:lane:right=inline capacity:disabled=1 Dein Anliegen war ja genau das. . Saubere Lösung. - Also kein neuer amenity-Tag (da aus Proposal genommen) nötig und Lösung in bestehendem Proposal gefunden. Das ist doch gut für Deine Behindertenkarte, oder? (welche ich sehr begrüße!) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stats OSM Routing View 2010-07
Am 19.07.2010 um 14:01 schrieb Pascal Neis: Hi, Matthias Versen schrieb: steffterra wrote: Darf ich fragen was da in Hessen passiert ist? Von einem Monat (11.06.10) auf den anderen (17.07.10) wurden die Fehler um fast die Hälfte reduziert? Und davor (10.05.10) waren sie sogar weniger als am 17.07.10? Wurde da großflächig gepfuscht und dann kurz darauf alles auf einen Schlag wieder Rückgängig gemacht? Ich glaube es handelt sich dabei um die Aktion Oberförster. Walter hatte im letzen Monat geschrieben das es sich dabei wohl wahrscheinlich um den User oberförster handeln würde, vgl. http://lists.openstreetmap.org/pipermail/talk-de/2010-June/069981.html Danke :-) steffterrra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behindertenparkplatz
Am 19.07.2010 um 14:07 schrieb Tobias Knerr: Ein amenity=parking_space in einem amenity=parking wäre wie ein natural=tree in einem natural=wood: Völlig ok. Ich würde den Bereich als outer-polygon (den Rest als inner) und darin eine neue Fläche mit den Behindertenparkplätzen entsprechend getaggt einzeichen. Was spricht dagegen? Dass es dann zwei separate Parkplätze sind (nebenbei bemerkt mit allen Konsequenzen fürs Rendering, POI-Listen etc.), was nicht der Realität entspricht? ok. verstehe. Was würde dagegen sprechen, es wie an normalen Strassen auch am service des Parkplatzes zu taggen? Nach dem Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane also so: wiederum natürlich zwischen den beiden nodes, der Lokalisation des Behindertenparkplatzes highway=service service=parking_aisle parking:lane:right=orthogonal (wenn man das denn angeben möchte/muss) capacity:disabled=1 Das würde doch passen, oder? Wenn jetzt der Rednerer noch disabled richtig auswertet, dann kommt da auch ein entsprechendes Icon an die richtige Stelle auf dem Gesamtparkplatz. Machbar oder nicht? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgehende Mittellinie
Proposal von mir, das die durchgezogene Mittelline ergänzt. JOSM kehrt in manchen Fällen die Richtung automatisch um. Aber nicht ohne Rückfrage, oder? Aber irgendwo machen Anfänger mal ihre ersten Gehversuche. Und da bleibt die Fahrtrichtung beim ersten Probieren mal leicht in der falschen Richtung, weil sie vermeintlich nur bei Einbahnstra0e und Kreisverkehr gilt. Bis man dann bestürzt wahrnimmt, dass die Richtung auch noch im fortgeschrittenen Tagging eine Rolle spielt, hat man schon mehrere Stra0en umgedreht. Deshalb Doku lesen und/oder einer örtlichen OSM-Gruppe anschließen und die ersten Gehversuche dort unternehmen. Wenn ich auf taggs stoße, die ich nicht kenne, lese ich nach, was sie bedeuten. Das steht schon in den Verhaltenstips für Neueinsteiger, die sowieso Pflichtlektüre sind. Es gibt noch andere Beispiele wo das eigene Tagging Auswirkungen auf andere Dinge hat. Doku lesen, Doku lesen. Wenn ich an meinem Auto rumschrauben würde, obwohl ich davon keine Ahnung habe . Klar, man kann es Anfängern erschweren oder erleichtern. Ich sehe das Taggen der durchgezogenen Mittellinie als einfache Bereicherung an, da sie an bestimmten Stellen (Beispiele wurden im lauf der Diskussion genannt) sogar einen Mehrwert vor Relationen bieten, die nun wirklich erst für fortgeschrittene User geeigent sind. Du argumentierst, dass Neuuser Fehlerquelle sein könnten beim Drehen von Wegen (wegen der Auswirkungen auf forward und backward), schlägst aber unbewusst vor, an diesen Stellen Abbiegerelationen zu erstellen, denn das wäre die Konsequenz ... Auch da wird er sich Hilfe holen oder die Doku sehr genau lesen müssen. So wie ich auch, als ich darauf das erste mal sties. Besser wäre es vielleicht daher, wenn die Straßenrichtung beim Neuerstellen eines Ways von der Datenbank festgelegt würde und nicht umkehrbar wäre. Dabei bleibt sie zwischen zwei Knotenpunkten immer gleich Und was machst Du wenn sich die Richtung einer Einbahnstraße ändert? Dasselbe was Du dann beim ersten Richtungtagging einer Einbahnstraße machst: Je nachdem ob sie gegen oder mit der von der Datenbank festgelegten Richtung läuft, tagst Du forward oder backward. Die Richtung in der Du in JOSM zeichnest, also wo Du Deine Maus zuerst ansetzt gibt die Richtung vor. Wie soll JOSM wissen, dass es die Richtung anders herum zeichnen (vorgeben) muss. Und ab welchen Winkeln (wir können in 360°-Winkeln Richtungen einzeichnen), legst Du fest wie herum die Richtungen verlaufen müssen? Neee, lassen wir das. Ausserdem ist es offtopic. Ich glaube Du bist bei einer Grundsatzdiskussion über Schreibrechte für gewisse Eigenschaften und sog. Userleveln/Editierrechten angelangt. Lassen wir das bitte in diesem Thread ;-) Ich mache mal einen eigenen Thread dazu auf. Deshalb äußere ich mich jetzt nicht hier weiter darüber :-) Ich wünsche eine schöne Woche, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Am 18.07.2010 um 03:06 schrieb Tirkon: steffterra steffte...@me.com wrote: Wenn alle Straßen in Orten, in den denen es Hausnummern gibt, in Relationen gefasst wären, dann könnten wir OSM für Neuuser dicht machen und wären ständig am nachreparieren der Hausnummer-Straßen-Relationen. Weil - selbst wenn man nichts mit Hausnummern am Hut hat und auch gar nichts an der Relation ändern will - und sei es nur dass sich der Verlauf eines Radweges geändert hat, dann ist die Relation futsch und ein Router findet keine einzige Hausnummer dieser Relation mehr, wenn der (Neu)User die Relation nicht richtig beachtet hat. Es bleibt ohne Relation besser menschenlesbar. +1 Zu all den genannten Argumenten gegen eine Relation hier noch ein weiteres, das sich auf der Insel Baltrum auftut: Dort werden Hausnummern in der Reihenfolge der Errichtung der Häuser vergeben. Bei jedem Bauantrag wird also eine neue Nummer vom Stapel genommen. Damit hat das erste erbaute Haus auf der Insel die Hausnummer 1. Nummer 11 könnte durchaus neben Nummer 111 stehen. Die Hausnummer hat dort also keine geografischen Bezug mehr. Die explizite Adressnennung am Haus bewährt sich auch dort als die beste Methode. +1 Aber, ohne Dir/mir selbst in den Rücken fallen zu wollen: Hausnummern-Relationen _können_ an _manchen Stellen_ sinnvoller sein, als das Einzeltagging. Aber eben auch umgekehrt, wie man an Tirkons Beispiel Baltrum sehen kann. Sie sind aber defintiv nicht das Allerheilmittel, als das die Informatiker unter uns sie immer (vlt. unbewusst?) hinstellen möchten. Noch ein Frage zu Baltrum Tirkon, Die durcheinander gewürfelten Hausnummern von Häusern nebeneinander einer Straße gehören aber schon zur gleichen Straße? Und die Anwohner haben schon die gleiche Adresse, mal abgesehen von der jeweiligen Hausnummer? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18.07.2010 um 10:38 schrieb Markus: Hallo Jens, hallo Tilmann, Das sind Dinge, die ich im API über amenity=fuel, operator=Aral suchen kann. Siehe http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Also Relations sind keine Sammlungen von Daten mit den selben Eigenschaften. Mehrwert ist wie Jens sagt gleich null. Wenn das einhellige Meinung ist, dann sollte man das hier: http://wiki.openstreetmap.org/wiki/DE:Relations und hier: http://wiki.openstreetmap.org/wiki/Relations in einem entsprechenden Abschnitt deutlich dokumentieren. Auf diesen Seiten steht bereits der Hinweis auf http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Ich ergänze es eben noch um einen kleinen erklärenden Satz mit einem aktuellen Beispiel :-) auf DE und EN. doch die anderen Sprachen bekomme ich nicht hin ;-) Hier scheint die Meinung anders zu sein: http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations Deshalb ist es auch nur ein Vorschlag. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 um 07:36 schrieb fx99: In der OSM Darstellung müssen die Punkte in einem Weg eine Ordnung haben, damit man weiß, wie sie zu verbinden sind. Warum? Eigentlich benötigt man eine Richtung nur da, wo man eine Richtung benötigt ;-) Dabei gibt es bei einem nicht in sich geschlossenen genau zwei Möglichkeiten: A-B-C-D oder D-C-B-A, was dann als Richtung bezeichnet wird. Dort wo nötig, sicher sinnvoll, aber sonst? In vielen Fällen ist die Richtung ohne jede Bedeutung, s.o. in manchen Fällen (z.B. Flüsse) wird eine sinnvolle Konvention festgelegt. Soweit so gut. Was mich jetzt aber stört, ist, dass an eine oft willkürliche Richtung entscheidenen Eigenschaften durch forward oder backward gekoppelt werden. Dies führt dann zu den oben aufgezählten Problemen. Richtig. Es sollte Regeln geben, an denen man sich orientieren kann, in welche Richtung ein way gedreht sein muss, dass backward und forward richtig interpretiert werden können. Für den destination-Tag bin ich auch auf so ein Problem gestoßen und habe es so gelöst, dass der way immer in Richtung der bedeutsameren (hierarchisch höher stehenden) Straßenart zeigen sollte. Also im Falle einer residental zu einer secondary hin. Vielleicht ist das ein allgemein möglicher Vorschlag? Ich hielt es für wesentlich sinnvoller, diese Eigenschaften durch von der Richtung des Weges unabhängige, absolut gültige Beschreibungen ergänzt werden, wie z.B. Himmelsrichtung oder andere geographische Beschreibungen ( von A nach B etc. ). s.o. ich denke an die Richtung hin zum hierarchisch höher wertigen highway-Klassifizierung. (aber nur, wenn der forward-backward-tag überhaupt genutzt wird!) Wenn zwei gleichwertige ways aufeinander stoßen, dann sollte die Richtung _aus_ der Richtung kommen, die weniger bedeutsam ist. (Z.B. wenn eine secondary aus einem Wohnviertel herausführt und auf eine secondary-Bundesstraße führt) Bei der Bundesstraße bin ich mir nicht sicher, ob es wieder relevant ist... Damit wären auch die meisten Probleme der unkontrollierten Richtungsumkehr verschwunden. Solange man diese Regeln, wie der way auszurichten ist, kennt udn diese beachtet. Aber so ist es ja immer in OSM. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vollkommen sinnlose, zerstörerrische Richtungsfunktion in OSM?
Am 18.07.2010 um 10:47 schrieb Frederik Ramm: Vorschlag 2: Die Richtung der Straße könnte bei neuen way-Objekten - zweckmässigerweise zwischen zwei Knotenpunkten ohne Richtungsänderung - entweder vom Editor oder der Datenbank automatisch festgelegt werden und wäre dann für niemanden mehr umkehrbar. Bei einer Vereinigung von zwei gegenläufigen Straßen durch Auflösung einmes Knotenpunktes drehen Editor oder Datenbank (je nachdem, wer oben für diese Aufgabe zuständig war) auf allen richtungsgeänderten ways auch alle forwards und backwards in betroffenen Tags und Relationsabschnitten um. Die Datenbank waere das bestimmt nicht, denn sie kuemmert sich nicht um den Inhalt von Tags. Automatisch festgelegte Way-Richtungen finde ich nicht so gut, weil das dazu fuehren wuerde, dass wir deutlich mehr oneway=-1 in der Datenbank haetten, und ich bin eigentlich ganz froh, dass das derzeit die absolute Ausnahme ist. +1 Welcher von beiden wäre zu bevorzugen? Keiner. Anstatt ein immer engeres Korsett zu bauen, innerhalb dessen die Editoren - von denen es viele gibt, und von denen nie alle sich einig sein werden - Benutzern Vorschriften machen, sollte man sich Methoden fuer das Tagging ueberlegen, die weniger fragil sind. Stimmt auch wieder. Doch hast Du einen Vorschlag, wie dieses Tagging aussehen könnte? Und jetzt kommt nicht wieder mit Relationen um das einfache Taggging zu ersetzen. Bitte. Worueber man allerdings fuer eine Uebergangszeit mal nachdenken koennte, ist, die Way-Umdreh-Funktion in JOSM etwas mehr zu verstecken. Vielleicht in einem Untermenue Advanced... oder sowas. Damit man nicht so leicht versehentlich draufklickt ;) +1 Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
Am 18.07.2010 um 12:02 schrieb Markus: http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Sollte jemand vielleicht noch auf deutsch übersetzen... Freue mich auf Deine Übersetzung. Leider ist mien englisch nicht s gut, dass ich das adäquat könnte. Und das mit der benutze die Suche in OSM müsste man auch noch irgendwie sinnvoll verlinken (ich wüsste nämlich nicht wie man nach einer Kombination von zwei Schlüssel-/Wertepaaren sucht). Derjenige, der eine Datenbank für seine Zwecke aufbaut, kann auch in OSM-Daten nach Schlüsselpaaren suchen ;-) Bei der Relation müsste das ja auch klappen ;-) Hier scheint die Meinung anders zu sein: http://wiki.openstreetmap.org/wiki/Relations#Proposed_uses_of_relations Deshalb ist es auch nur ein Vorschlag. Aber einer der Schule zu machen scheint... Woran erkennst Du das bzgl. unseres Themas? Welche Zusammenfassungen von z.B. amenities in Relationen kennst Du? Hast Du Beispiele? Die meisten anderen Proposed_uses_of_relations beziehen sich tatsächlich auch Relationen, wie sie eigentlich gemeint sind, nicht der blosen Zusammenfassung von Daten einer Kategorie. Sie sind nur deshalb noch Vorschläge, weil sie kaum genutzt wurden/werden, oder mittlerweile andere Wege gefunden wurden, die jeweiligen Ziele zu erreichen. Und der im Widerspruch zu der Aussage unter Definition steht. Laut dieser Definition sollen verschiedene Elemente auch in OSM zusammengebracht werden, die mit einer bestimmten Rolle auch in der Wirklichkeit untereinander in Beziehung stehen. Sie sind nicht nur in Beziehung untereinander, weil sie der selben Kategorie angehören. Das ist der Unterschied. Das verwirrt den Benutzer. Wenn er die Defintion gelesen und verstanden hat nicht. Da müssten zumindest die Vor- und Nachteile der beiden Modelle verständlich beschrieben sein... Es gibt nur ein Modell: s.o. bei Definition. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
