[Talk-de] ArcSDE, XML...
Hallo! Ich hätte eine Frage zu einem Projekt an dem ich gerade arbeite. Die Aufgabestellung ist folgende: Ich habe einen Server (ArcSDE) und möchte auf diesem, die A (Autobahnen), B (Bundestrassen), und L (Landestrasse) Straßennetze speichern. Des weiteren sollten diese Netze in einem, von mir vorgegebenen Intervall automatisch von einem OSM - Server aktualisiert werden. Was mir hier jetzt fehlt ist irgendwie der erste Schritt, wie und mit welchen Werkzeugen (XML) ich das jetzt lösen könnte. Auch wie ich eine Datenbankabfrage, welche ich ja zweifellos brauche implementiere, würde ich gerne wissen. Mit JAVA, MySQL und HTML kenne ich mich so einigermaßen aus, ich müsste meine Kentnisse wieder ein bisschen auffrischen. Vielleicht könnt Ihr mich ja ein bisschen in die richtige Richtung lenken. Ich hoffe ihr könnt Euch mit diesen Informationen ein Bild machen. Vielen Dank schon mal! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM und Merkator
Ist Merkator im aktuellen JOSM-tested schon als Standard implementiert? Dann könnte man hier den Hinweis löschen: http://wiki.openstreetmap.org/wiki/DE:Bing#JOSM Und wenn der Autom. Zoom schon standardmässig ausgeschaltet ist, könnte der Hinweis auch gleich weg. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Suche im Wiki
Wie konfiguriere ich die Wiki-Suche? Wenn ich Luftbild eingebe, sagt die Suche: Für deine Suchanfrage wurden keine Ergebnisse gefunden. Erstelle die Seite „Luftbild“ in diesem Wiki. Das Menü steht auf Erweitert. Inhaltsseiten würde funktionieren - aber wie stelle ich das ein? http://wiki.openstreetmap.org/wiki/de:Wiki_Help#Suche_benutzen ist veraltet und hilft auch nicht weiter. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche im Wiki
Am 1. März 2011 11:37 schrieb Markus liste12a4...@gmx.de: Wie konfiguriere ich die Wiki-Suche? gute Frage, bei mir geht es auch nicht :) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ArcSDE, XML...
Am 1. März 2011 09:25 schrieb Thomas Fink thomas_f...@live.at: Hallo! Ich hätte eine Frage zu einem Projekt an dem ich gerade arbeite. Die Aufgabestellung ist folgende: Ich habe einen Server (ArcSDE) und möchte auf diesem, die A (Autobahnen), B (Bundestrassen), und L (Landestrasse) Straßennetze speichern. Des weiteren sollten diese Netze in einem, von mir vorgegebenen Intervall automatisch von einem OSM - Server aktualisiert werden. Was mir hier jetzt fehlt ist irgendwie der erste Schritt, wie und mit welchen Werkzeugen (XML) ich das jetzt lösen könnte. Auch wie ich eine Datenbankabfrage, welche ich ja zweifellos brauche implementiere, würde ich gerne wissen. Mit JAVA, MySQL und HTML kenne ich mich so einigermaßen aus, ich müsste meine Kentnisse wieder ein bisschen auffrischen. Vielleicht könnt Ihr mich ja ein bisschen in die richtige Richtung lenken. m.E. müsstest Du mit regular Expressions den ref-tag hinsichtlich (A, B, L, K) parsen, da die highway-Klassen von OSM nicht in allen Fällen 1:1 mit der administrativen Klassifikation übereinstimmen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Relationsdialog - Templates für die gängisten Formen
Am 28. Februar 2011 23:30 schrieb NopMap ekkeh...@gmx.de: M∡rtin Koppenhoefer wrote: Kennst Du STRG+F Martin, wenn Du ihm nicht helfen willst, dann sei doch ganz einfach still. Ich helfe gerne, ihm wurde aber bereits geholfen, und dann erwarte ich schon, dass man sich die Wikiseite, die verlinkt wurde, auch mal ansieht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lübecker Stammtisch
Moin ! am kommenden Donnerstag (3.3.2011 - 19 Uhr) ist wieder unser Stammtisch im Feuerwerk in Lübeck http://wiki.openstreetmap.org/wiki/L%C3%BCbecker_Mappertreffen Interessierte, auch aus dem Umland sind herzlich willkommen. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und Merkator
Moin, Markus schrieb: Ist Merkator im aktuellen JOSM-tested schon als Standard implementiert? Dann könnte man hier den Hinweis löschen: http://wiki.openstreetmap.org/wiki/DE:Bing#JOSM ??? Merkator-Projektion ist doch m. W. schon sehr lange Standard bei der Auslieferung. Trotzdem kam es immer wieder zu Problemen, sei es durch ein Update auf ältere Versionen oder weil die Benutzer mit der Einstellung gespielt haben und das später vergaßen. Der Hinweis ist ein sinnvoller Hinweis und sollte m. E. bleiben - es schadet absolut nicht, die Einstellung sicherheitshalber mal zu überprüfen. Und wenn der Autom. Zoom schon standardmässig ausgeschaltet ist, könnte der Hinweis auch gleich weg. Ist er zum Glück nicht. Wenn der Autom. Zoom standardmäßig ausgeschaltet ist, muss man dafür jede detailiertere Zoomstufe einzeln (!) manuell abfordern per Zoom erhöhen - und landet dann trotzdem beim weißen Bild - das soll sinnvoller sein? Auch der Hinweis sollte bleiben - zumindest bis JOSM die Antwort der weißen Kachel auswerten kann und automatisch die letzte Zoomstufe beibehält - aber eben weiterhin mit Autom. Zoom! Man könnte den Hinweis ggf. um die Einstellung der maximalen Zoomstufe für das bearbeitete Lieblingsgebiet erweitert - das verhindert die weißen Kacheln m. E. besser. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche im Wiki
Moin, Markus schrieb: Wie konfiguriere ich die Wiki-Suche? Wenn ich Luftbild eingebe, sagt die Suche: Für deine Suchanfrage wurden keine Ergebnisse gefunden. Erstelle die Seite „Luftbild“ in diesem Wiki. Das Menü steht auf Erweitert. Inhaltsseiten würde funktionieren - aber wie stelle ich das ein? ich kann Dein Problem nicht nachvollziehen, bei mir zeigt er standardmäßig Inhaltsseiten an - aber Erweitert zeigt bei mir auch nur das gleiche (mit 54 Ergebnissen recht umfangreiche) Suchergebnis mit zusätzlicher Erweitert-Box, kein Problem also. Du kannst Dich ja mal einloggen und unter Einstellungen und dort Suchoptionen nachschauen. Bei mir sind dort (Seiten) und die Sprachoptionen angehakt. Die gleichen Einstellungen siehst Du ja auch bei Erweitert in der Box. Ich habe es nicht ausprobiert, ob Änderungen jetzt was bewirken. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ArcSDE, XML...
Moin, M∡rtin Koppenhoefer schrieb: Am 1. März 2011 09:25 schrieb Thomas Fink thomas_f...@live.at: Ich habe einen Server (ArcSDE) und möchte auf diesem, die A (Autobahnen), B (Bundestrassen), und L (Landestrasse) Straßennetze speichern. Des weiteren sollten diese Netze in einem, von mir vorgegebenen Intervall automatisch von einem OSM - Server aktualisiert werden. m.E. müsstest Du mit regular Expressions den ref-tag hinsichtlich (A, B, L, K) parsen, da die highway-Klassen von OSM nicht in allen Fällen 1:1 mit der administrativen Klassifikation übereinstimmen. würde ich auch so sehen - und S für L in Sachsen sowie St für L in Bayern. Vorausgesetzt, Du beschränkst Dich auf Deutschland ... Von einem OSM-Server kann ja vieles bedeuten, _der_ OSM-Server ist da evtl. schon eher ein Problem. Da XAPI ja eh schon hoffnungslos überlastet ist, würde ich da entweder auf die Extrakte der Geofabrik zurückgreifen oder eine eigene DB aufsetzen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und Merkator
Hallo Georg, Merkator-Projektion ist doch m. W. schon sehr lange Standard bei der Auslieferung. Das habe ich auch vermutet. Wenn das so ist sollten wir den Hinweis löschen. Es kann nicht Aufgabe einer Anfängerseite im Wiki sein, Schwierigkeiten mit veralteten Versionen oder gar mit künftigen durch Benutzerprüfungen vorzubeugen. Solche Informationen verwirren den Neuling. (Auch wenn sie früher mal essentiell waren.) Wenn der Autom. Zoom standardmäßig ausgeschaltet ist, muss man dafür jede detailiertere Zoomstufe einzeln (!) manuell abfordern per Zoom erhöhen - und landet dann trotzdem beim weißen Bild Das wäre natürlich keine Lösung ;-) Sinnvoll wäre, wenn das Programm dem Benutzer die Arbeit abnimmt, die er sonst immer wieder händisch wiederholen muss. automatisch die letzte Zoomstufe beibehält und automatisch bis zur letzten Zoomstufe nachlädt. Bis es soweit ist, ist der Hinweis natürlich sinnvoll. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche im Wiki - Luftbild
Hallo Georg, hat wohl irgendwer am Mediawiki runmgeschraubt? Jetzt geht es (wieder) :-) Ich finde viele regionale Einträge zu Luftbild, aber keine, die dem Neuling erklärt, wie man mit Luftbildern arbeitet. Ich mache mal einen neuen Thread auf... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und Merkator
Am 1. März 2011 18:51 schrieb Markus liste12a4...@gmx.de: Hallo Georg, Merkator-Projektion ist doch m. W. schon sehr lange Standard bei der Auslieferung. Das habe ich auch vermutet. Wenn das so ist sollten wir den Hinweis löschen. Auf keinen Fall, der Hinweis ist grundsätzlich wichtig. Ich habe mal ergänzt, dass Merkator bereits standardmäßig aktiviert sein sollte. Es kann nicht Aufgabe einer Anfängerseite im Wiki sein, Schwierigkeiten mit veralteten Versionen oder gar mit künftigen durch Benutzerprüfungen vorzubeugen. Solche Informationen verwirren den Neuling. (Auch wenn sie früher mal essentiell waren.) das ist keine Anfängerseite sondern die deutsche Beschreibung zu den Luftbildern von Bing. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Luftbildauswertung
Geometrie vom Luftbild wird zunehmend die GPS-Erfassung ersetzen. Anfänger (und auch Fortgeschrittenere) könnten sich mit einem HowTo zu Abzeichnen von Luftbildern schneller mit dem Thema vertraut machen. Erfahrene Luftbildauswerter könnten ja gemeinsam eine Wikiseite Luftbildauswertung gestalten, in der sie die Bedeutung der Parameter - Auflösung - Aktualität - Sichtbarkeit (Vegetation, Bewölkung, Reflexion, Schatten, Kontrast) - Aufnahmewinkel (Schrägverzerrung) - Georeferenzierung (Kissenverzerrung, Versatz) anhand von Bild-Beispielen erläutern, und ihre Entscheidungskriterien für die Wahl des Hintergrundbildes bzw ihren Workflow beschreiben. weitere Themen könnten sein: - Küstenlinie erkennen - Farbunterschiede deuten (Vegetation, etc) - Wege im Wald - Schatten nutzen Als Anfang könnte diese Seite dienen: http://wiki.openstreetmap.org/wiki/DE:Entwurf_Luftbilder_HowTo/neu Gruss, Markus Weitere Quellen: http://ant.dev.openstreetmap.org/bingimageanalyzer/ http://wiki.openstreetmap.org/wiki/Source_Layers http://wiki.openstreetmap.org/wiki/Vertical_Aerial_Photographs http://wiki.openstreetmap.org/wiki/Aerial_imagery http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Luftbilder http://wiki.openstreetmap.org/wiki/DE:DOP_Sources http://wiki.openstreetmap.org/wiki/DE:Entwurf_Luftbilder_HowTo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ArcSDE, XML...
Am 01.03.2011 18:39, schrieb Georg Feddern: Moin, M∡rtin Koppenhoefer schrieb: Am 1. März 2011 09:25 schrieb Thomas Fink thomas_f...@live.at: Ich habe einen Server (ArcSDE) und möchte auf diesem, die A (Autobahnen), B (Bundestrassen), und L (Landestrasse) Straßennetze speichern. Des weiteren sollten diese Netze in einem, von mir vorgegebenen Intervall automatisch von einem OSM - Server aktualisiert werden. m.E. müsstest Du mit regular Expressions den ref-tag hinsichtlich (A, B, L, K) parsen, da die highway-Klassen von OSM nicht in allen Fällen 1:1 mit der administrativen Klassifikation übereinstimmen. würde ich auch so sehen - und S für L in Sachsen sowie St für L in Bayern. Vorausgesetzt, Du beschränkst Dich auf Deutschland ... Ich befürchte sogar, dass man auch die route-Relationen zusätzlich zu dem ref-Tag hinzuziehen müsste. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbildauswertung
Am 1. März 2011 19:27 schrieb Markus liste12a4...@gmx.de: Als Anfang könnte diese Seite dienen: http://wiki.openstreetmap.org/wiki/DE:Entwurf_Luftbilder_HowTo/neu Was mir aufgefallen ist: - Du empfiehlst dort, einen source-tag zu setzen für eine Luftbildquelle. Besser wäre m.E., das in dem Changeset zu vermerken. - Trotz Aktualisieren habe ich den WMS-Eintrag nicht für Bayern (unter available default). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Mit einem Mausklick gleich mehrere neue Knotenpunkte für einen Weg einfügen?
Am 27.02.2011 11:43, schrieb Schorschi: Hallo, On Sat, 26 Feb 2011, Benedikt Schwarz wrote: Am 26.02.2011 19:50, schrieb Henning Scholland: nicht das ich wüsste, aber du kannst mit einem Klick + wegziehen auf die Mittelkreuze der Wegsegmente dort einen neuen Node einfügen. Habe ich gerade ausprobiert und eigentlich ganz praktisch. du kannst auch noch einen neuen Weg zeichnen, alle Knotenpunkte, die du auf dem alten Weg setzen willst, mit diesem neuen Weg erzeugen und am Ende den neuen Weg einfach löschen - die neuen Knotenpunkte bleiben erhalten, weil sie ja auch Teil eines anderen (des alten, jetzt modifizierten) Weges sind. Aber da du die neuen Punkte eigentlich nicht genau auf dem alten Weg haben willst und nach der obigen Methode dann noch einmal anfassen musst, ist die Methode mit dem Mittelkreuz meines Erachtens nach die effektivere. Gruß, Schusch ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Status Fahrradwege-Tags
Hallo, kurz zu mir selbst. Ich lese ab und an die Diskussionen auf dieser Liste mit und versuche gute Vorschläge bei meiner Arbeit an OSM umzusetzen. Ich tagge seit 2008 im Südraum Leipzig und lege mehr Wert auf Qualität (so wie die Masse, schätze ich), als schnell die DB zu stopfen. Über das Tagging zu Radrouten und -wegen wurde auf dieser Liste schon viel diskutiert. Ich will daher kurz mein Anliegen einordnen. Es geht mir um das Taggen von Fahrradwegen (nicht Radroutenrelationen o.ä.). Ich habe mir oft gedacht, dass das bisherige tagging der Radwege nicht nur schlecht, sondern für vielerlei Zwecke auch völlig unzureichend ist - wobei das nicht heißt, dass ich es aus Mangel an besseren Ideen nicht selbst verwendet habe. Also es geht um Radwege und ihre Nutzbarkeit für unterschiedliche Arten von Radlern. Momentan gibt es genau zwei etablierte Tags, die einen mit _Radwegen_ arbeitenden Radfahrer interessieren und weniger etablierte: * surface= unpaved| paved| etc.. * bicycle= yes| no| designated| official| etc.. - mtb: (mountainbike namespace, healthy and alive) - smoothness (hat sich nie so richtig durchgesetzt, weil Einschätzung größtenteils subjektiv) Lasst mich weiterhin festhalten, wofür genau die tags momentan verwendet werden: bicycle=* 1) im Wiki: klar als Zugangsbeschränkung (beschilderter Radweg, offizielle Nutzungsart, usw.) 2) in-the-wild: jeder Weg, der als für Radfahrer geeignet erscheint bekommt bicycle=yes verpasst surface=* ) beschreibt objektiv die Oberflächenbeschaffenheit ) nicht aber den Zustand!! smoothness=* ) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort fahren kann, weil a) die subjektive Ansicht des Taggenden im Wert steckt und b) ich die Entscheidungsbasis des Taggenden nicht kenne (ein Inliner wird strenger sein, als z.B. ein Radfahrer, etc.) Was will ich also ändern, was sind meine Ideen? Ziele: a) sowohl Mensch als auch Maschine (routing services) sollen in der Lage sein, eine für Radfahrer geeignete Route aus den Daten abzuleiten b) der Taggende soll objektiv entscheiden und nach Möglichkeit mit wenigen Werten arbeiten können, um a) zu erreichen (praktischer) Ansatz: (Idee während des Radelns :) ) 1) es gibt im wesentlichen 3 Kategorien von Radfahrern, welche i.d.R. ihre Präferenzen nach den unterschiedlichen Wegoberflächen/-beschaffenheiten richten (wichtig!) 2) Monotonie: MTB Trekking RaceBike ein MTB kann auch auf ausgewiesenen trekking und race Strecken fahren, umgekehrt geht dies i.d.R. nicht, bzw. ist nicht erwünscht (ich kenne niemanden, der sein Rennrad auf unpassenden trails schrottet) konkreter Tagging-Vorschlag: *) bicycle:mtb=(alle mgl. Zugangsbeschränkungen) *) bicycle:trek=(alle mgl. Zugangsbeschränkungen) *) bicycle:race=(alle mgl. Zugangsbeschränkungen) *) bicycle=(alle mgl. Zugangsbeschränkungen) Implikationen: _) bicycle:race impliziert, sofern für die anderen Tags nichts angegeben, bicycle:trek bicycle:mtb bicycle mit demselben Wert _) bicycle:trek impliziert, sofern für die anderen Tags nichts angegeben, bicycle:mtb bicycle mit demselben Wert _) bicycle:mtb impliziert keine weiteren bicycle Tags _) bicycle impliziert, sofern für die anderen Tags nichts angegeben, bicycle:trek bicycle:mtb mit demselben Wert Wobei letzteres die Rückwärtskompatibilität zu bestehendem Tagging gewährleistet. Beispiele *) ich habe einen sandigen Fußweg, der auch von MTBlern benutzt wird: bicycle=no bicycle:mtb=yes foot=yes highway=path surface=sand *) ich habe einen fein geschotterten Waldweg: bicycle=yes bicycle:trek=yes (:mtb wird impliziert, :trek eigentlich auch, ist aber für Menschen da, um zu sehen, dass man sich hier nach dem erweiterten Schema Gedanken gemacht hat - man könnte auch nur :trek verwenden, dass bricht dann aber die Kompatibilität) foot=yes highway=track surface=fine_gravel *) eine asphaltierte Straße, die für Rennräder geeignet ist bicycle=yes bicycle:race=yes (:mtb, :trek werden impliziert, können aber angegeben werden, z.B. auch wenn es für unterschiedliche Radtypen unterschiedliche Zugangsbeschränkungen gibt) foot=yes highway=secondary surface=asphalt *) eine (alte) asphaltierte Straße, die nicht für Rennräder geeignet ist bicycle=yes bicycle:race=no foot=yes highway=secondary surface=asphalt *) eine (alte) asphaltierte Straße, die so kaputt ist, dass man sie selbst mit Trekking-Rädern meiden sollte/nicht mehr befahren kann bicycle=yes bicycle:trek=no bicycle:race=no foot=yes highway=unclassified surface=asphalt *) eine (alte) asphaltierte Straße (Alternative, semantisch äquivalent) bicycle=no bicycle:mtb=yes foot=yes highway=secondary surface=asphalt Was sind die Vorteile einer Adaption dieses Schemas, dieser Erweiterung? - Zugangsaussagen pro
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 02:13, schrieb Christian Müller: smoothness=* ) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort fahren kann, weil a) die subjektive Ansicht des Taggenden im Wert steckt und b) ich die Entscheidungsbasis des Taggenden nicht kenne (ein Inliner wird strenger sein, als z.B. ein Radfahrer, etc.) Auch wenn diese Aussagen immer wieder kolpotiert werden, stimmen sie nicht. Die Werte mit den entsprechenden Bedeutungen sind dokumentiert: http://wiki.openstreetmap.org/wiki/Approved_features/Smoothness#Tag.2C_Values_and_Usage Für ein Trekking bike könnte man also bei folgenden Werten fahren: excellent, good, intermediate, bad - bei den anderen nicht. Da steht nichts von smoothness im Sinne (oder laut Ansicht) eines Inliners oder Radfahrers oder xy, sondern z.B. ist geeignet für Rennrad und darunter etc.. In etwa die gleiche Ansichtssache wie bei track auch. Auch da gab es am Anfang die gleichen Kritiken, scheint zumindest dort aber ganz gut zu funktionieren. Die Kritik an diesem Tag basieren auf der (wahrscheinlich falschen) Annahme, eine ganz objektive Methode finden zu können - die auch im Alltag handhabbar ist [1]. Wenn du jetzt anfängst, zu taggen ob etwas für einen Trekkingradfahrer geeignet ist: yes vs. no, stößt du doch an exakt die gleichen Probleme. Was für den einen durchaus noch geht ist für den anderen geht garnicht - genauso viel oder wenig Ansichtssache. Dann können wir aber auch gleich smoothness nehmen - das halte ich sogar für die praktikablere Alternative, sowohl für den Eintragenden als auch für den Verwender. Durch den Verlauf von gut nach schlecht sind die Grenzfälle sogar wohl wesentlich besser zu taggen und auszuwerten. Gruß, ULFL [1] Natürlich könnte man eine Art wissenschafliche Untersuchung starten (Welligkeit, Löcher, Rillen, ..., jeweils mit Höhe, Abstand, Form, Größe, Tiefe). Will sich aber wohl keiner antun. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 03:27, schrieb Ulf Lamping: Am 02.03.2011 02:13, schrieb Christian Müller: smoothness=* ) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort fahren kann, weil a) die subjektive Ansicht des Taggenden im Wert steckt und b) ich die Entscheidungsbasis des Taggenden nicht kenne (ein Inliner wird strenger sein, als z.B. ein Radfahrer, etc.) Auch wenn diese Aussagen immer wieder kolpotiert werden, stimmen sie nicht. Die Werte mit den entsprechenden Bedeutungen sind dokumentiert: http://wiki.openstreetmap.org/wiki/Approved_features/Smoothness#Tag.2C_Values_and_Usage OK, ich hatte das sogar mal gelesen. Damals war es allerdings noch nicht approved. Dennoch, good/bad/intermediate sind Begriffe, die nicht gerade intuitiv auf die Verwendbarkeit hindeuten, selbst wenn Sie definiert sein sollten - da smoothness in seiner Def.variante auch, wie Du schon feststellst, nicht gerade gängig ist, wohl auch aufgrund seiner undefinierten Historie, möchte ich nochmal auf das was Du schreibst eingehen, denn wenn man die access-Methodik auf die Fahrradtypen anwendet, ergeben sich schon feiner (und auch objektiver) granulierbare Taggings. Wenn du jetzt anfängst, zu taggen ob etwas für einen Trekkingradfahrer geeignet ist: yes vs. no, stößt du doch an exakt die gleichen Probleme. Was für den einen durchaus noch geht ist für den anderen geht garnicht - genauso viel oder wenig Ansichtssache. Ja und nein. 1) bicycle=yes wird momentan auf Wege gesetzt, die nur von MTB zu befahren sind - wenn smoothness vergessen/nicht ausgewertet/nicht nach Wiki-Def verwendet wird, bin ich als Trekker auf einem Pfad gelandet, der definitiv nichts für mich ist 2) gerade wenn ich den access-Wertebereich auf bicycle:trek=* anwenden kann, lässt sich speziell für diese Radkategorie sehr schön unterscheiden (Weg von amtlicher/offizieller Seite für Trekking-Räder vorgeschlagen, oder nur yes, womit ersichtlich wäre: ja, es geht) 3) natürlich kann ich nicht ausschließen, dass bicycle:trek=yes einen gewissen Spielraum hat - der dürfte aber (praktisch!) einen wesentlich kleineren Spielraum haben, als nur bicycle zu verwenden, oder sich auf smoothness zu verlassen.. und wenn die Kategorie trekbike dann vielen Leuten später zu breit ist, kann ich diese (die schon eine spezielle ist) immer noch feiner granulieren, indem ich z.B. (wie bei track, weil Du es ansprachst), weitere Werte einführe 4) die richtige Verwendung von smoothness ergibt sich ohne Wiki nicht - mein Vorschlag einfach die 3 wichtigen Fahrradkategorien auf vorgeschlagene Weise zu benutzen ist selbstdokumentierend Dann können wir aber auch gleich smoothness nehmen - das halte ich sogar für die praktikablere Alternative, sowohl für den Eintragenden als auch für den Verwender. Durch den Verlauf von gut nach schlecht sind die Grenzfälle sogar wohl wesentlich besser zu taggen und auszuwerten. Das sehe ich natürlich nicht so, würde ich dem zustimmen ergäbe meine mail auch wenig Sinn :) Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Ulf Lamping wrote: Dann können wir aber auch gleich smoothness nehmen - das halte ich sogar für die praktikablere Alternative, sowohl für den Eintragenden als auch für den Verwender. Dafür. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Christian Müller wrote: 1) bicycle=yes wird momentan auf Wege gesetzt, die nur von MTB zu befahren sind - wenn smoothness vergessen/nicht ausgewertet/nicht nach Wiki-Def verwendet wird, bin ich als Trekker auf einem Pfad gelandet, der definitiv nichts für mich ist Das sehe ich eher andersrum. bicycle=yes heißt, das das Radfahren dort nicht verboten ist. Mißbraucht wird es allenfalls dann, wenn ich einen Weg fahre, denke, der geht aber gar nicht und bicycle=no dran pappe. Das ist *eigentlich* falsch, denn das Radfahren ist dort ja nicht verboten. IIRC werten die gängigen Radkarten, z.B. die Garminkarte von Felix, die surface- und smoothness-Tags sehr wohl aus. Die exakten persönlichen Präferenzen wirst Du niemals unter einen Hut bekommen. Es gibt z.B. weicheiige MTBradfahrer die da absteigen wo Andere noch locker mit dem Trekkingrad fahren. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 04:40, schrieb Christian Müller: Am 02.03.2011 03:27, schrieb Ulf Lamping: Am 02.03.2011 02:13, schrieb Christian Müller: smoothness=* ) hilft mir nicht zu entscheiden, ob ich z.B. mit trekking bike dort fahren kann, weil a) die subjektive Ansicht des Taggenden im Wert steckt und b) ich die Entscheidungsbasis des Taggenden nicht kenne (ein Inliner wird strenger sein, als z.B. ein Radfahrer, etc.) Auch wenn diese Aussagen immer wieder kolpotiert werden, stimmen sie nicht. Die Werte mit den entsprechenden Bedeutungen sind dokumentiert: http://wiki.openstreetmap.org/wiki/Approved_features/Smoothness#Tag.2C_Values_and_Usage OK, ich hatte das sogar mal gelesen. Damals war es allerdings noch nicht approved. Dennoch, good/bad/intermediate sind Begriffe, die nicht gerade intuitiv auf die Verwendbarkeit hindeuten, Ich halte es auch nicht für sonderlich intuitiv, für jeden einzelnen Fahrzeugtyp erraten zu müssen, ob man da langfahren kann / will, wenn ein anderer eingetragen wurde. Wenn du jetzt ein bicycle:trek=yes gesetzt hast: - will ich da auf einer Radtour lang? - komme ich da nur zur Not lang? - komme ich da mit einem Rollstuhl lang? - ...? Ein smoothness=bad ist vielleicht vom Begriff her erstmal unklarer, kann aber alle diese Frage tatsächlich beantworten - und ist letztlich einfacher zu setzen ohne noch 10 andere Tags setzen zu müssen, die letztlich auch nicht mehr sagen. selbst wenn Sie definiert sein sollten - da smoothness in seiner Def.variante auch, wie Du schon feststellst, nicht gerade gängig ist, wohl auch aufgrund seiner undefinierten Historie, ?!? Die Definition war bereits Bestandteil des Proposals. möchte ich nochmal auf das was Du schreibst eingehen, denn wenn man die access-Methodik auf die Fahrradtypen anwendet, ergeben sich schon feiner (und auch objektiver) granulierbare Taggings. Die Aussage, mit welchem Fahrradtyp man da langfahren kann oder will, ist mit deinem Schema genauso (wenig) objektiv wie bei smoothness. Wenn du jetzt anfängst, zu taggen ob etwas für einen Trekkingradfahrer geeignet ist: yes vs. no, stößt du doch an exakt die gleichen Probleme. Was für den einen durchaus noch geht ist für den anderen geht garnicht - genauso viel oder wenig Ansichtssache. Ja und nein. 1) bicycle=yes wird momentan auf Wege gesetzt, die nur von MTB zu befahren sind - wenn smoothness vergessen/nicht ausgewertet/nicht nach Wiki-Def verwendet wird, bin ich als Trekker auf einem Pfad gelandet, der definitiv nichts für mich ist bicycle=yes sagt (nur) aus ob man dort langfahren *darf*, nicht ob man dort langfahren will oder kann. 2) gerade wenn ich den access-Wertebereich auf bicycle:trek=* anwenden kann, lässt sich speziell für diese Radkategorie sehr schön unterscheiden (Weg von amtlicher/offizieller Seite für Trekking-Räder vorgeschlagen, oder nur yes, womit ersichtlich wäre: ja, es geht) Der Tagname ist etwas unglücklich. Rein logisch würde ich bei bicycle:trek=* annehmen, das man dort mit einem Trekking Fahrrad rechtlich langfahren *darf*. Das willst du aber ja nicht aussagen. Eine Mischung von rechtlichen Einschränkungen und Vorlieben der Radfahrer sollten wir hier tunlichst vermeiden um nicht noch mehr Unverständlichkeit zu produzieren. Wenn, dann sowas wie: bicycle_smoothness:trek=* bicycle_usable:trek=* bzw. eher sogar :trekking, da wir tendenziell bei den tags eher nicht abkürzen. 3) natürlich kann ich nicht ausschließen, dass bicycle:trek=yes einen gewissen Spielraum hat - der dürfte aber (praktisch!) einen wesentlich kleineren Spielraum haben, als nur bicycle zu verwenden, oder sich auf smoothness zu verlassen.. und wenn die Kategorie trekbike dann vielen Leuten später zu breit ist, kann ich diese (die schon eine spezielle ist) immer noch feiner granulieren, indem ich z.B. (wie bei track, weil Du es ansprachst), weitere Werte einführe Letztlich landest du dann bei sowas wie mtb:scale von 0-5, stellst fest das sich die Bereiche von MTB, Trekking und Rennrädern irgendwie überschneiden und führst dann - weil es sonst für den Mapper viel zu kompliziert wird für viele verschiedene Fahrzeugarten die Sachen einzeln zu setzen - ein bicycle:smoothness von 0-10 ein ;-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 03:27, schrieb Ulf Lamping: [1] Natürlich könnte man eine Art wissenschafliche Untersuchung starten (Welligkeit, Löcher, Rillen, ..., jeweils mit Höhe, Abstand, Form, Größe, Tiefe). Will sich aber wohl keiner antun. ... weil Ergebnis nur bis zum nächsten Regen gültig smoothness gilt immerhin bis zur nächsten Holzabfuhr ;-) ... womit wir schon beim Thema wären, dass eins daneben bei tracktype und smoothness im Rauschen der jahreszeitlichen Änderungen in Wald und Flur untergehen, wodurch sich jedes exaktere tagging eh obsoletiert ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo, Am 02.03.2011 03:27, schrieb Ulf Lamping: Wenn du jetzt anfängst, zu taggen ob etwas für einen Trekkingradfahrer geeignet ist: yes vs. no, stößt du doch an exakt die gleichen Probleme. Was für den einen durchaus noch geht ist für den anderen geht garnicht - genauso viel oder wenig Ansichtssache. Dann können wir aber auch gleich smoothness nehmen - das halte ich sogar für die praktikablere Alternative, sowohl für den Eintragenden als auch für den Verwender. Durch den Verlauf von gut nach schlecht sind die Grenzfälle sogar wohl wesentlich besser zu taggen und auszuwerten. +1 Bei der Planung meiner Radtouren in unbekanntem Gebiet komme ich mit den existierenden Tags gut zurecht: mit dem Rennrad auf highway= secondary/tertitiary/residential/unclassified, sofern nicht explizit mit surface asphalt getaggt, sowie auf Tracks mit tracktype=grade1, und mit dem Trekkingrad möglichst nicht auf secondary Highways, dafür zusätzlich auf tracktype=grade2. Ich fahre aber auch mal mit dem Rennrad auf mir bekannten Grade2-Tracks mit sehr glatter Oberfläche und mit dem Tracking-Rad auf irgendwelchen Trampelpfaden. Aber die Entscheidung, ob ich da lang fahre, kann und soll mir aber kein Mapper abnehmen, dessen subjektive Bewertungskriterien ich nicht kenne. Probleme habe ich eigentlich nur mit Straßen, die etwas anderes als einen glatten Asphaltbelag haben, aber nicht mit einem Surface- bzw. Smoothness-Tag gekennzeichnet sind, und mit Tracks ohne Tracktype. Und natürlich mit allen Straßen und Wegen, die nicht entsprechend den Wiki-Konventionen getaggt sind, insbesondere Tracks ohne Tracktype. Wenn die existierenden Tags (highway, tracktype, bicycle, surface, smothness) korrekt und konsequent verwendet werden sind Renn- und Trekkingfahrer optimal versorgt. Oder anders ausgedrückt: für Renn- und Trekkingradler kann man eine Klassifizierung, wie Christian sie vorschlägt, aus den vorhanden Tags ableiten. Sie ist redundant und somit überflüssig. Und für die MTBler gibt es ja mtb:scale ;) Für eine Lösung auf Basis der existierenden Tags spricht auch, dass davon auch Nicht-Radfahrer einen Nutzen haben. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 07:58, schrieb Joerg Fischer: Das sehe ich eher andersrum. bicycle=yes heißt, das das Radfahren dort nicht verboten ist. Mißbraucht wird es allenfalls dann, wenn ich einen Weg fahre, denke, der geht aber gar nicht und bicycle=no dran pappe. Das ist *eigentlich* falsch, denn das Radfahren ist dort ja nicht verboten. Das wiki erreiche ich gerade nicht, aber ich meine, zumind. in einigen Sprachversionen ist oder war [div. access] = no doppelt belegt durch rechtlich unmöglich und technisch unmöglich/ungeeignet oder so. Selbst wenn man sich da auf eins einigt: Es wird das jeweils andere fehlen und zu tag-Verklemmungen führen. Wir werden um ein =gehtnicht wohl nicht rumkommen mittelfristig ... Was wir auch noch bräuchten, wäre ein Wert bicycle=beachteseparateradwege oder cycleway=separatgemappt bzw. cycleway=teilweiseseparatgemappt Dann bicycle=no wird auch öfters falsch benutzt, um das Radrouting von der Fahrbahn auf die Radwege zu verbannen, wenn die nicht als cycleway an der Fahrbahn hängen, sondern separat gemappt sind. Auch da ist aber das bicycle=no aber so aus div. Gründen auch nicht richtig. Wenn wir dann noch eine klarere Linie in yes/designated/official bringen, um entlang von Straßen die verschiedenen Fällevon Benutzungspflicht abzubilden, und smoothness verinnerlichen, dann haben wir's doch ... ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
