[talk-ph] Cebu city finished
Hi all, No, Cebu city is far from finished. But after 2 months of intensive tracing from Bing I'm done (for a while). I did my best to guess the road type. (mainly residential, unclassified and track) Where I really didn't know I've put road. (in the center of Cebu city most should probably be residential) Now names need to be added, and road types verified. Some roads might be wrong, connected where they should not, or not connected where they should be. (Bing isn't always very clear). The good thing is that all this can be done by anyone, without GPS. I hope future local mappers will be more motivated now that there is already a start... Cheers, Totor ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Remarks about Bing imagery in Cebu city
Just a little note about the Bing imagery of Cebu. In Cebu city and surroundings, the highest available zoom level is old (2004) and has a relatively big offset (10 to 20 meters). Even worse, the offset seems to depend on the altitude. (Probably because the images were not taken vertically) On the transcentral highway some sharp curves with steep slopes, even have opposite offsets on the beginning and the end of the curve! One zoom level lower is recent (2009) and has a small offset that seems stable over big distances. At the beginning of each tracing session, I aligned each lower zoom level to GPS traces where they were reliable and available. (I use mainly Merkaartor, so the image layer has to be dragged again for each session) I then traced some roads and aligned the highest zoom level to those new roads, so that the alignment for the highest zoom level was done close to where I was tracing. Switching between old and new imagery is very confusing. Having to re-align the highest one regularly doesn't help. This is why (in the end) I traced most from the previous to the highest zoom level. I also noted that some of the available GPS traces are quite inaccurate. Please check things carefully before to realign roads to exising GPS traces or to the Bing imagery... Cheers, Totor ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] infrastructure tracing in Christchurch
On 3 March 2011 03:22, Richard Weait rich...@weait.com wrote: Bounding box contains ~53,000 objects and 94 users, extends roughly: Canon Street in the north, Coleridge Street in the south, Tui Street in the west and Bracken Street in the east. don't forget the equally incredible work in sumner (east of the city) and lyttelton (south-east) -- robin http://tangleball.org.nz/ - Auckland's Creative Space http://openstreetmap.org.nz/ - Open Street Map New Zealand http://bumblepuppy.org/blog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] all our addresses are belong to you
On 3/2/2011 3:54 PM, flambe...@gmail.com wrote: MapQuest is providing several address files that contain user-provided latitude and longitude locations across the world. Our users provided these exact locations to us so that they could be mapped correctly on our MapQuest maps. This is great to see! Our crowdsource participation would go up if the tools were simple enough to use (single purpose, etc). There are probably more addresses here than all manually gathered addresses in the US in the last year. A quick check shows that there are some duplicated addresses, probably caused by excitement to get the address on the map quickly (I reported it yesterday, why is it still not on the map??) For example, I see: 3000 Highway 29 N 3000 Highway 29 N. 3000 Highway 29 North 3000 Hwy 29 N 3000 Hwy 29 N. 3000 Hwy 29 North Not to look a gift horse in the mouth, but just wanted to note it to anyone looking at processing the data. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] all our addresses are belong to you
On 2 March 2011 21:54, flambe...@gmail.com flambe...@gmail.com wrote: MapQuest is providing several address files that contain user-provided latitude and longitude locations across the world. Our users provided these exact locations to us so that they could be mapped correctly on our MapQuest maps. There are currently three (3) main files - one for the United States, one for Canada and one for Europe. More information can be found on our wiki page: http://wiki.openstreetmap.org/wiki/MapQuest/Critical_Addresses We didn't want to just import these addresses directly into OSM, but wanted them to be available to anyone that wanted to have them. To be clear: 1. these addresses are user provided 2. there is a high degree of ground-truth from these users 3. they WANTED to be in the data and be correctly mapped 4. we've checked with our lawyers, and yes, you can have them - UNENCUMBERED! Fantastic. Perhaps the best way to incorporate this data would be some sort of data layer that mappers can load for their local area in JOSM? Since this data set doesn't have too many data points and obviously a straight import won't work it might be a good approach. I've heard ideas for this method mentioned before but I'm unsure if it's been done? Also, can we expect an extension of this data set in the future as more users add their addresses? -- Matt Williams http://milliams.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] all our addresses are belong to you
On Miércoles, 2 de Marzo de 2011 21:54:28 flambe...@gmail.com escribió: 4. we've checked with our lawyers, and yes, you can have them - UNENCUMBERED! Hey, you will at least want to keep track of how many of them are imported/uploaded into OSM. Have you thought about a source= tag, perhaps something like source=mapquest_critical_addresses ? Best, -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] all our addresses are belong to you
Umm yeah quick note on that – the dupes are different spellings of an address when it has a directional as part of the road name. lets call it a feature of how the CAF is checked before our hitting our commercial geocoding solution. Mike N wrote: A quick check shows that there are some duplicated addresses, probably caused by excitement to get the address on the map quickly (I reported it yesterday, why is it still not on the map??) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] all our addresses are belong to you
On Wed, 2011-03-02 at 13:54 -0700, flambe...@gmail.com wrote: There are currently three (3) main files - one for the United States, one for Canada and one for Europe. This is great, but the US is 300m, Canada 34m and Europe 700m. The world population is just under 6.8 million. Is there any schedule when the other 85% of the world might be released, or is there simply so much data that larger regions will have to wait? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] all our addresses are belong to you
On Wed, Mar 2, 2011 at 7:00 PM, David Murn da...@incanberra.com.au wrote: On Wed, 2011-03-02 at 13:54 -0700, flambe...@gmail.com wrote: There are currently three (3) main files - one for the United States, one for Canada and one for Europe. This is great, but the US is 300m, Canada 34m and Europe 700m. The world population is just under 6.8 million. Is there any schedule when the other 85% of the world might be released, or is there simply so much data that larger regions will have to wait? The Canada file has 503 addresses. The Europe file has 707 addresses. The US file has 10,397 addresses (of which about 20% appear to be duplicates). So, even if you're in the US, you're not that special. :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [HOT] Nametagging: Local script versus
On 28 February 2011 21:40, Steve Doerr steve.do...@blueyonder.co.uk wrote: On 28/02/2011 16:55, Ed Avis wrote: Jean-Marc Liotierjmat liotier.org writes: By the way, for latin script names, should we use int_name, name:en or both ? If the name is still in Arabic, but Arabic written with the Latin alphabet, then name:ar@Latin would be correct. Did you just make that up, or is this use of the @ symbol a pre-existing standard? The part after @ is the modifier in posix locales and is often used for script type, see for example http://wiki.services.openoffice.org/wiki/LocaleMapping Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] magical road detector to play with
Here's another example where it fails to spider because it doesn't want to cross, or even get close to, paved dips at intersection boundaries, no doubt because it thinks they are sidewalks. That should probably be a pattern it is sensitive to (roadColor-borderColor-roadColor) and allow it to go through it. It will occasionally generate non-existing intersections where a perp intersection is separated only by a single sidewalk, but these are rare IME. Also note the way (33.4587097, -117.1022644)-(33.4588280, -117.1024399). Not sure what this was supposed to be. Maybe the short dead-end heading ESE from near the second point? Note that it doesn't complete the road between the two given points, despite the fact that they are within about 10cm of the centerline endpoints (pt1 the center of the circle that fits the cul-de-sac and pt2 the intersection of the two centerlines). Future improvement thought: when it sees the road flare left and/or right just before an intersection, ignore the flare and draw the intersection where it would be if the corners came to right angles. This will prevent a lot of deviated intersections like the one at (33.4588280, -117.1024399), reducing complexity and improving appearance. http://3667a17de9b94ccf8fd278f9de62dae4.cloudapp.net/DetectRoad.svc/explore/?pt1=33.4583630,-117.1031114pt2=33.4578704,-117.1037238bbox=33.467,-117.109,33.452,-117.091 -- Alan Mintz alan_mintz+...@earthlink.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] all our addresses are belong to you
*Hello David, *I'm sorry if you misunderstood where these addresses came from. These are addresses where people have directly picked up the phone and called us with their address and latlng because they weren't being found in the commercial datasets we license. Our Support team gathers these addresses and places them in this file that sits above the commercial geocoder. Our Support team is becoming engaged with our Open initiative and took the internal steps necessary to get this file released to the OSM community to do with as it see fits, because they thought it would be potentially useful, and a good thing to do. Support provides the updates to us every couple or weeks or so, so the schedule will likely be whenever we get a breathing space to put an update up on the OSM Wiki. The coverage expansion schedule is literally at the whim of those nice people who take the time to pick up the phone and call us because they couldnt be found on our websites. HTH Ant (the Limey) * David Murn* wrote: This is great, but the US is 300m, Canada 34m and Europe 700m. The world population is just under 6.8 million. Is there any schedule when the other 85% of the world might be released, or is there simply so much data that larger regions will have to wait? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Project of the week: Stationery
This week, we suggest to put your eyes on the local stationery shops http://wiki.openstreetmap.org/wiki/Project_of_the_week Again, this is just a look what we can add and not a add XYZ immediately!. Feel free to notify your local groups if you like the idea. regards Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New Community Updates newsletter
Hi, we proudly presents the next issue of the Community Updates newsletter: http://wiki.openstreetmap.org/wiki/Community_Updates/2011-02-21 kind regards Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Status Fahrradwege-Tags
Hallo, On 03/02/2011 08:23 AM, Ulf Lamping wrote: 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. Eigentlich ist es eher nach Art von OSM, zu taggen, was da ist, und nicht, was man in das hineininterpretiert. (= also kein bicycle:bla=yes - das kann der bicycle:bla-Fahrer schon selbst entscheiden) Zugleich ist es aber nicht nach der Art von OSM, irgendwelche Schwammkategorien zu verwenden. (= also kein smoothness=bad - was fuer den einen bad, ist fuer den anderen superb) Am ehesten muessten wir also die Art und Groesse der Kiesel- oder Schottersteine, die Frequenz und Groesse der Schlagloecher usw. in Zahlen angeben, und jeder kann sich dann darauf seinen persoenlichen Reim machen. Das ist natuerlich nicht praktikabel, also haben verschiedene Leute sich da an Alternativen versucht, die alle irgendwelche Maengel haben, weil es eben ohne Maengel irgendwie nicht geht. Fest steht, dass sich die deutsche Community mit smoothness zum Gespoett der internationalen OSMer gemacht hat (Stichwort smoothness = very horrible, aus dem urspruenglichen Proposal). Genaugenommen ist die smoothness auch nur eine Neuauflage des tracktype, der ebenfalls eine OSM-unuebliche Klassifizierung darstellt, und der, genauso wie smoothness, die Intention hatte, dass man daran erkennen koennen soll, welche Art von Fahrzeugen auf dem Weg gut fahren koennen. Auch tracktype ist eine deutsche Erfindung und wird hauptsaechlich in Deutschland genutzt (Anteil aller highway=track, die damit ausgestattet sind: Deutschland 85%, Oesterreich 42%, Frankreich 33%. UK 27%). Manch einer mag sagen, das liegt daran, dass die Deutschen beim Mappen die Arschbacken mehr zusammenkneifen, aber vermutlich ist es halt einfach so, dass bei uns solche Sachen zuerst angegangen werden, weil wir so viele Mapper haben und so viel schon erfasst ist. Ein kleines bisschen sind wir da also auch Wegbereiter fuer die, die vielleicht erst in einigen Jahren an den Punkt kommen, an dem wir jetzt sind. Ich denke, wir tun dem Projekt insgesamt keinen Gefallen, wenn wir staendig neue Sachen erfinden, die alle irgendwie so aehnlich sind, bloss weil man mit dem, was die anderen machen, nicht so 100% zufrieden ist. Wir haben tracktype, wir haben surface, nun noch smoothness oder irgendwelche Eignungstags - gibt es da nicht viele Moeglichkeiten, sich taggingmaessig in den Fuss zu schiessen? Kann man das einem neuen Mapper halbwegs verstaendlich machen - oder wird der dann sagen: Oh, dann lasse ich davon lieber meine Finger? Bye Frederik ___ 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 02:13, schrieb Christian Müller: Hallo, Alles schön und gut aber wie willst Du garantieren dass die Mapper sich dran halten wenn sie schon das einfache Schema nicht kapieren und wild taggen ? Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo, du hast sicher recht, dass tracktype und smoothness subjektiv sind. Allerdings sollte man dabei nicht vergessen, was es bedeuten würde, dass ganze in objektive Kriterien zu gießen. Kaum einer würde mit einem Zentimetermaß die tiefe der Schlaglöcher nachmessen oder deren Abstand. Auch eine Statistik über die vorherrschende Größe der Kiesel halte ich für zu aufwändig, als dass es eine große Anzahl wirklich macht. Die Folge dürfte sein, dass die Masse der Mapper diese objektiven Kriterien ohnehin nur abschätzt. Dann macht es meiner Meinung aber auch keinen Unterschied zu einem Abschätzen von smoothness=bad. Henning ___ 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 09:15, schrieb Frederik Ramm: Fest steht, dass sich die deutsche Community mit smoothness zum Gespoett der internationalen OSMer gemacht hat (Stichwort smoothness = very horrible, aus dem urspruenglichen Proposal). Es kam aber auch irgendwie nie ein guter Vorschlag, wie man es denn besser machen könnte. Der Vorschlag smoothness=0-9 wird dann mit: das ist aber nicht intuitiv kommentiert. Egal wie man es macht, irgendwem paßt es nicht :-) Genaugenommen ist die smoothness auch nur eine Neuauflage des tracktype, der ebenfalls eine OSM-unuebliche Klassifizierung darstellt, und der, genauso wie smoothness, die Intention hatte, dass man daran erkennen koennen soll, welche Art von Fahrzeugen auf dem Weg gut fahren koennen. Na ja, tracktype gibt den Ausbau eines track wieder, smoothness Zustand/Eignung - das ähnelt sich häufiger, ist aber längst nicht immer das selbe. Manch einer mag sagen, das liegt daran, dass die Deutschen beim Mappen die Arschbacken mehr zusammenkneifen, aber vermutlich ist es halt einfach so, dass bei uns solche Sachen zuerst angegangen werden, weil wir so viele Mapper haben und so viel schon erfasst ist. Ein kleines bisschen sind wir da also auch Wegbereiter fuer die, die vielleicht erst in einigen Jahren an den Punkt kommen, an dem wir jetzt sind. Böse Zungen könnten behaupten, das der gemeine Deutsche ganz einfach penibel ist ;-) Ich denke, wir tun dem Projekt insgesamt keinen Gefallen, wenn wir staendig neue Sachen erfinden, die alle irgendwie so aehnlich sind, bloss weil man mit dem, was die anderen machen, nicht so 100% zufrieden ist. Wir haben tracktype, wir haben surface, nun noch smoothness oder irgendwelche Eignungstags - gibt es da nicht viele Moeglichkeiten, sich taggingmaessig in den Fuss zu schiessen? Kann man das einem neuen Mapper halbwegs verstaendlich machen - oder wird der dann sagen: Oh, dann lasse ich davon lieber meine Finger? Die Frage ist doch eher, wie man das Tagging handhabt, das der Einsteiger die Sache noch anwenden kann, aber auch der Versierte / Spezialist das eintragen kann was er möchte. Oder noch besser: Das beide Gruppen gut mit einem Ansatz leben können. Was wir vermeiden sollten ist, daß der gleiche Sachverhalt je nach Zielgruppe (Radfahrer vs. Rollstuhlfahrer vs. ...) mehrfach eingetragen werden muß, weil das Tagging das so vorgibt. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Suchbare Liste aller bekannten OSM-Objekte
Hallo, Anfänger- bzw. Usability/Nachschlag-Problem am PC (also nicht draussen :-): Man hat irgendein bestimmtes Objekt im Sinn, z.B. Schloss oder Aussichtspunkt, und möchte rasch wissen, wie der Tag (bzw. Value) heisst. = Was würdet ihr da empfehlen (welche Wiki-Seite oder Liste oder Webseite)? Ich stelle mir zunächst eine suchbare Seite vor, alphabetisch sortiert. Wenn es zusätzlich auch Kategorien gibt, wie bei den Editoren, umso besser (aber nach sachlich-logischen Kriterien und nicht nur nach Node, Way, etc.). Das habe ich diesbezüglich zusammengetragen: * DE:Map_Features (im OWM-Wiki) * DE:Howto_Map_A (im OWM-Wiki) * OSM Cheat Sheet (pdf): http://files.getdropbox.com/u/1418629/OpenStreetMap%20cheat%20sheet.pdf LG, S. P.S. Das OSM-Wiki scheint zurzeit down zu sein... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suchbare Liste aller bekannten OSM-Objekte
Hallo, ich denke es wäre sinnvoll, das Howto_Map_A zu erweitern und dort evtl. nicht direkt auf das Tagging einzugehen, sondern auf die jeweilige wiki-Seite zu verlinken. Man könnte auch einfach redirects im wiki anlegen, was dann vom Suchbegriff Schloss auf das entsprechende OSM-Haupt-Tag für dieses Objekte führt. Auf der Seite der Haupt-Tags stehen dann ja alle Möglichkeiten, wie man das spezialisieren kann. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo Frederik, Eigentlich ist es eher nach Art von OSM, zu taggen, was da ist Das finde ich einen guten Grundsatz. Trotzdem erlebe ich seit Jahren die immer wieder gleichen Diskussionen mit m.E. nicht wirklich befriedigenden Ergebnissen. Ich vermute die Ursache in unklaren Zielen und einer folglich mangelnden Systematik. Vielleicht ist inzwischen die Zeit reif, da genauer hinzuschauen? Ziel unserer ganzen Datensammlerei ist ja, damit coole Anwendungen zu ermöglichen. Im Wesentlichen sind das Karten und Router, plus hin und wieder Spezialkarten und Statistiken. Der Anwender will wissen, wie es irgendwo aussieht, und ober einen Weg benutzen kann. Je genauer man diese Fragen ausdrücken kann, desto klarer werden die Anforderungen an die Datenerfassung. _Weg_ Bezüglich Wege macht es einen Unterschied, welches Transportmittel zur Verfügung steht, und welche Fertigkeiten ich mitbringe. Entsprechend müssten die Daten darüber Auskunft geben, ob ich mit gegebenem Transportmittel und Fertigkeiten den Weg nutzen kann, bzw welche Transportmittel und Fertigkeiten erforderlich sind. Beispiel: Es ist ein Unterschied, ob ich einen 40-Tonner, ein Motorrad oder einen Kinderwagen benutze. Beim Motorrad macht es einen Unterschied, ob ich eine Harley oder eine Enduro habe, und ob ich mit einer Enduro umgehen kann oder sie nur auf Asphalt benutze. Selbst als Fussgänger macht es einen Unterschied, ob ich Oma mit Gehhilfe bin oder Wanderer oder erfahrener Kletterer. Und es macht einen Unterschied, ob man darf oder kann. *Dürfen* ist verordnet (access). *Können* ergibt sich aus der Kombination von Oberfläche, Oberflächenzustand, Steigung, Tragfähigkeit, Wetterbedingung, etc. plus meinen Fertigkeiten. Probleme mit den Attributen ergeben sich m.E. immer dann, wenn unterschiedliche Klassen in einem Schlüssel vermengt werden. (z.B. technisch möglich mit gesetzlich erlaubt, oder Oberflächenmaterial mit Holprigkeit, oder Wartungszuständigkeit mit Verbindungscharakter, etc). Solche Vermengungen erzeugen immer irgendwelche Schwammkategorien _Schlüssel_ Schlüssel sollten m.E. immer möglichst eindeutig sein und immer möglichst nur eine Klasse beschreiben. _Werte_ Werte sollten m.E. immer möglichst objektiv unterscheidbare Eigenschaften beschreiben. Diese können messbar sein (Meter, Tonnen, Grad, etc), oder definierte Stufen (1=mit PKW befahrbar, 2=mit Traktor befahrbar): Art und Groesse der Kiesel- oder Schottersteine, Frequenz und Groesse der Schlagloecher usw. in Zahlen In der Kombination müssten die Attribute so sein, dass jeder sich dann darauf seinen persoenlichen Reim machen kann. Bzw eben genau für seine Frage eine erfüllende Antwort findet. Und dafür muss erst die *Frage bekannt* sein. Hier haben wir ein Problem zu bewältigen, an dem OSM schon immer Schwierigkeiten hat: jeder Datensammler geht von seinen eigenen Fragen aus, erfindet dafür tags und sammelt dazu Werte, aber kommuniziert die Frage nicht ;-) Und so entsteht ein unnötig wirres System mit vielen Missverständnissen und sich immer wiederholenden Diskussionen. mit smoothness zum Gespoett der internationalen OSMer gemacht Der Ansatz von smoothness ist m.E. ein sinnvoller. Daraus lässt sich Benutzbarkeit ableiten. Zum Gespött wird man nur, wenn man nicht erklärt wozu der Schlüssel gut ist und wenn man einen wirren Wertekatalog benutzt. Aber das können wir ja ändern :-) smoothness eine Neuauflage des tracktype In tracktype werden verschiedene Klassen verwurschtelt. smoothness erfasst die Holprigkeit (unabhängig vom Material). Ein kleines bisschen sind wir da also auch Wegbereiter :-) Ich denke, wir tun dem Projekt insgesamt keinen Gefallen, wenn wir staendig neue Sachen erfinden, die alle irgendwie so aehnlich sind, Ja, an vielen Stellen schaffen wir bisher ein mehr desselben. Besser wären durchdachtere (neue) Konzepte (z.B. klare Klassentrennung, eindeutige Schlüssel, definierte Wertekataloge). Wir haben tracktype, wir haben surface, nun noch smoothness Das sind m.E. alles Entwickungen in die richtige Richtung. Wir müssen nur noch *eindeutigere Beschreibungen* erstellen, die auch für Neue *verständlich und nachvollziehbar* sind. irgendwelche Eignungstags Solche führen m.E. in eine ungünstige Richtung. Die Eignung sollte m.E. aus den objektiven Werten Werten abgeleitet werden. Das macht dann die Anwendung bzw der Anwender. Kann man das einem neuen Mapper halbwegs verstaendlich machen Das ist eine entscheidende Voraussetzung. Hilfreich sind anschauliche Beispiele, und unterstützende Editoren. Dabei ist es m.E. eher unerheblich, ob beispielsweise snoothness mit 1..7 oder mit verygood..verybad bezeichnet ist, solange es für jede Stufe eine für jedermann nachvollziehbare (Bild)-Beschreibung gibt. Das Schöne an unserer Community ist ja dass wir durch vielfältige Erfahrungen ein optimales Ergebnis kombinieren können. Voraussetzung dafür ist m.E., dass wir unsere verschiedenen
Re: [Talk-de] Suchbare Liste aller bekannten OSM-Objekte
Am 2. März 2011 10:47 schrieb Stefan Keller sfkel...@gmail.com Anfänger- bzw. Usability/Nachschlag-Problem am PC (also nicht draussen :-): Man hat irgendein bestimmtes Objekt im Sinn, z.B. Schloss oder Aussichtspunkt, und möchte rasch wissen, wie der Tag (bzw. Value) heisst. = Was würdet ihr da empfehlen (welche Wiki-Seite oder Liste oder Webseite)? oft findet man mehr, wenn man auf Englisch sucht. Die Wiki-Suche ist leider momentan überlastet (oder sonstwie kaputt), aber mit Google kann man z.B. auch im Wiki, im Forum und auf den Listen parallel suchen: http://www.google.com/cse/home?cx=015487330990472192076:qvmeg3q9qus Ich stelle mir zunächst eine suchbare Seite vor, alphabetisch sortiert. Wenn es zusätzlich auch Kategorien gibt, wie bei den Editoren, umso besser (aber nach sachlich-logischen Kriterien und nicht nur nach Node, Way, etc.). Die mapfeatures und die Proposed features (Details oft auch auf den entsprechenden Diskussionsseiten in Verbindung mit taginfo) sind sicher ein Anhaltspunkt, wenn man da nichts findet ist die Chance groß, dass es überhaupt noch keinen etablierten Weg gibt, ein feature zu taggen. HowtoMapA finde ich eher problematisch, weil es noch eine Seite ist, die jemand aktuell halten muss, und weil durch diese Zersplitterung die Chance wächst, dass es zu inkonsistenten Empfehlungen kommt. Guten Erfolg hat man m.E., wenn man nachdem man nichts gefunden hat, hier auf der Liste nachfragt. Gutes Mapping besteht m.E. darüberhinaus darin, verschiedene Aspekte eines Features zu beschreiben, also nicht nur einen Node mit historic=castle für das Schloss setzen, sondern z.B. auch einen Wikipedia-link, eine Adresse, Öffnungszeiten und ähnliches dokumentieren, sowie die Details zeichnerisch wiedergeben (wo ist der Eingang / das Tor, gibt es eine Mauer/Zaun, wo wird geparkt, wo sind Fußwege, sind die Treppen durchgehend oder wo liegen die Absätze, etc.). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Ironie Also ich finde das genial. Wenn wir das einführen, können wir auch noch über die Abgrenzung verschiedener Fahrradtypen diskutieren. Der Vorschlag ist doch sicher von der Chips-Industrie gesponsert. /Ironie Dass das ganze Unsinn ist, zeigt sich nur schon dran, dass ein Trekkingrad als eindeutiger Fahrradtyp praktisch nur in Deutschland vorkommt. Ev. könnt man sich ja noch knapp darauf einigen was ein MTB und was ein Rennrad ist (ob das international auch hinhaut ist aber auch fraglich). Trotzdem, wie schon von anderen geschrieben, sagt das dann noch lange nichts über die persönliche, was fahre ich noch Grenze aus (ich bin mit meinem Trainingszeitfahrrad auch schon Waldstrassen in wirklich schlechten Zustand gefahren, weil ich zu faul war umzukehren). Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suchbare Liste aller bekannten OSM-Objekte
Hallo Stefan, Man hat irgendein bestimmtes Objekt im Sinn, z.B. Schloss oder Aussichtspunkt, und möchte rasch wissen, wie der Tag (bzw. Value) heisst. Das müsste m.E. der Editor leisten. In JOSM gibt es dafür die Vorlagen, und dazu eine Suchfunktion. Dort gibst Du Schloss ein - und bekommst ein Formular, das Dir für jedes Attribut passende Auswahllisten und Eingabefelder anbietet, plus einen Link zu einer Hilfeseite, auf der man dann bebilderte Beispiele findet. Das Wiki dient als erklärende Hilfe und zur Planung und Entwicklung. How-to-map-A war ein Lösungsversuch aus der Zeit vor den GUI-Editoren. Die händisch eingetragenen englischen Schlüssel-/Werte-Paare stammen aus der Zeit der Konsolenfenster und sind heute wahrscheinlich zunehmend nur noch für Power-Mapper und DV-Profis interessant. Map-Features ist zusammen mit den Wiki-Seiten sozusagen die Datenbank der wichtigsten Attribute wie sie dann beispielsweise in den JOSM-Vorlagen verwendet werden. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 03:27 schrieb Ulf Lamping ulf.lamp...@googlemail.com: 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. ganz genau. Smoothness funktioniert eigentlich ziemlich gut, es gibt die vielbeschworenen Probleme nicht. Der Hauptkritikpunkt an dem Tag ist glaube ich eher die Wortwahl der values, die bei einigen Schmunzeln hervorruft (very horrible). Die Skala an sich kann man sowohl für Radwege, als auch für Wanderwege (und natürlich für alle anderen Wege auch) sehr gut verwenden. Leider tun das nur wenige. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 08:42 schrieb Rainer Kluge rklug...@web.de: Ich fahre aber auch mal mit dem Rennrad auf mir bekannten Grade2-Tracks mit sehr glatter Oberfläche Wenn Du diese Fehler kennst, kannst Du sie gerne auch korrigieren und ein grade1 draus machen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 08:55 schrieb Heiko Jacobs heiko.jac...@gmx.de: 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. Dann sollte man das vereinheitlichen. Schon seit einigen Jahren gibt es AFAIK einen Konsens, dass access rechtliche Zustände wiedergibt. Für die Eignung sollte man daher was anderes erfinden (so man überhaupt diese Richtung einschlagen will). Von Widersprüchen in der Doku hat niemand was. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 09:15 schrieb Frederik Ramm frede...@remote.org: Zugleich ist es aber nicht nach der Art von OSM, irgendwelche Schwammkategorien zu verwenden. (= also kein smoothness=bad - was fuer den einen bad, ist fuer den anderen superb) bad ist genau definiert. Das bedeutet, dass man stabile Räder benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann (robust_wheels) trekking bike, normal cars, Rickshaw and all below . Eine Stufe schlechter (very_bad) bräuchte man schon ein Auto mit großer Bodenfreiheit oder ein MTB, eine Stufe besser (intermediate) kommt man mit allgemeinen Fahrzeugen wie Rollstühlen und Citybikes auch noch durch. Dazu gibt es auch noch Fotos: BAD: http://wiki.openstreetmap.org/wiki/File:Smoothnessverybad.jpg (nicht vom Bildtitel verwirren lassen) eins schlechter: http://wiki.openstreetmap.org/wiki/File:Mountain-track1.jpg eins besser: http://wiki.openstreetmap.org/wiki/File:Map_feature_ford.jpg Das Schema schlechtzureden bringt nichts. Die Wortwahl kann man sicher kritisieren, aber es entstand halt in einer Zeit als behauptet wurde, sprechende Beschreibungen seien eingänglicher als Werte von 1-8. (Ich bestreite das mal, weil ich grundsätzlich nachsehen muss, welche Stufe von schlecht jetzt zutrifft, bei guter smoothness tagge ich die bisher sowieso nicht). Die Definitionen sind ziemlich eindeutig und es gibt daher keine Möglichkeit, das hier: http://wiki.openstreetmap.org/wiki/File:Smoothnessverybad.jpg mit dem zu verwechseln: http://wiki.openstreetmap.org/wiki/File:Highway_secondary-photo.jpg da ist wenig Subjektives dabei. Fest steht, dass sich die deutsche Community mit smoothness zum Gespoett der internationalen OSMer gemacht hat (Stichwort smoothness = very horrible, aus dem urspruenglichen Proposal). das ist auch nach wie vor Bestandteil der Definition ;-) Genaugenommen ist die smoothness auch nur eine Neuauflage des tracktype, der ebenfalls eine OSM-unuebliche Klassifizierung darstellt, und der, genauso wie smoothness, die Intention hatte, dass man daran erkennen koennen soll, welche Art von Fahrzeugen auf dem Weg gut fahren koennen. Nein, das stimmt so nicht. Tracktype ging nie um die Art von Fahrzeugen, die den Weg benutzen können, sondern um den Ausbaugrad, von asphaltiert über geschottert bis zu Graspiste. So ist es noch heute definiert. Smoothness hingegen trägt dem Umstand Rechnung, dass die Glattheit der Oberfläche nicht (nur) vom Material abhängt sondern vor allem auch vom Zustand. Eine Neuauflage ist das nicht. Ich denke, wir tun dem Projekt insgesamt keinen Gefallen, wenn wir staendig neue Sachen erfinden, die alle irgendwie so aehnlich sind, bloss weil man mit dem, was die anderen machen, nicht so 100% zufrieden ist. +1, zusätzliche Eignungstags für spezielle Fahrzeuge bringen uns nicht weiter. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo Martin, Am 02.03.2011 12:13, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 08:42 schrieb Rainer Klugerklug...@web.de: Ich fahre aber auch mal mit dem Rennrad auf mir bekannten Grade2-Tracks mit sehr glatter Oberfläche Wenn Du diese Fehler kennst, kannst Du sie gerne auch korrigieren und ein grade1 draus machen. Wäre die Definition von tracktype=grade1 Es gibt OSM-User, die hier bei schönem Wetter mit dem Rennrad fahren, dann würde ich das machen. Im Wiki ist aber tracktype=grade1 als Befestigter Weg (Asphalt, Beton, Pflastersteine etc) beschrieben. Die Wege, von denen ich schrieb, haben eine Oberfläche aus Schotter oder anderen dicht gepackten Materialien, was gemäß Wiki einem Grade2 entspricht. Im englischen Wiki wird übrigens heavily compacted hardcore dem Grade1 zugerechnet. Gruß rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 12:56 schrieb Rainer Kluge rklug...@web.de: Hallo Martin, Am 02.03.2011 12:13, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 08:42 schrieb Rainer Klugerklug...@web.de: Ich fahre aber auch mal mit dem Rennrad auf mir bekannten Grade2-Tracks mit sehr glatter Oberfläche Wenn Du diese Fehler kennst, kannst Du sie gerne auch korrigieren und ein grade1 draus machen. Wäre die Definition von tracktype=grade1 Es gibt OSM-User, die hier bei schönem Wetter mit dem Rennrad fahren, dann würde ich das machen. Im Wiki ist aber tracktype=grade1 als Befestigter Weg (Asphalt, Beton, Pflastersteine etc) beschrieben. Die Wege, von denen ich schrieb, haben eine Oberfläche aus Schotter oder anderen dicht gepackten Materialien, was gemäß Wiki einem Grade2 entspricht. Im englischen Wiki wird übrigens heavily compacted hardcore dem Grade1 zugerechnet. ja, Übersetzungsfehler bzw. Auslassung im Deutschen: grade1 schließt Wege mit ein, die zwar nicht asphaltiert sind, die aber eine Oberflächenstruktur haben, die dem faktisch gleichkommt (extrem verdichtet). Da Du schriebst dass Du dort mit dem Rennrad gut fahren kannst, ist es m.E. eher ein grade1 als grade2. Ich sehe mir normalerweise nur die englischen Features-Seiten an, die Übersetzungen sehe ich als Hilfe wenn man nicht so gut Englisch versteht, aber die eigentliche Definition ist die Englische. Insofern relativiere ich ein bisschen, was ich oben an Frederik geschrieben habe: im Bereich von trackgrade 1-3 spielt die Oberfläche mit rein, während 4 und 5 dann eher einen Ausbaugrad (und Nutzungsfrequenz) beschreiben. Gruß Martin ___ 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 13:11, schrieb M∡rtin Koppenhoefer: Im englischen Wiki wird übrigens heavily compacted hardcore dem Grade1 zugerechnet. ja, Übersetzungsfehler bzw. Auslassung im Deutschen: grade1 schließt Wege mit ein, die zwar nicht asphaltiert sind, die aber eine Oberflächenstruktur haben, die dem faktisch gleichkommt (extrem verdichtet). Das hatte ich schon befürchtet. Meine positive Meinung zu Tracktype muss ich wohl revidieren. Ob ein Weg befestigt ist, also asphaltiert, betonniert oder mit glatten Betonsteinen gepflastert, oder nur eine extrem kompaktierte Oberfläche hat, macht für mich schon einen erheblichen unterschied. Bei Regen und oft auch noch in den Tagen nach dem Regen sind solche Wege meist mit erheblicher Schmutzbildung verbunden und auch ein extrem kompaktierter Belag wird sich bei Dauerregen an der Oberfläche aufweichen. Vor ich eine Tour auf so einem Weg plane, will ich daher zumindest wissen, ob er befestigt ist oder nicht. Da Du schriebst dass Du dort mit dem Rennrad gut fahren kannst, ist es m.E. eher ein grade1 als grade2. Angesichts der Klarstellung bzgl. der Wiki-Artikel ist das auf meine Ansprüche bezogen richtig. Es bedeutet aber nicht im Umkehrschluss, dass jeder Grade1-Track zum Befahren mit dem Rennrad geeignet ist. Die Mehrzahl der Rennradler sieht das sicher anders. Für die ist ein Grade1-Track ohne surface=paved/asphalt nicht einplanbar. Als Radfahrer brauche ich objektive Informationen zur Beschaffenheit der Oberfläche. Mit einer konsequenten Verwendung von Surface gemäss dem aktuellen Wiki wäre schon viel erreicht. Dazu bei einigen Oberflächenarten noch eine Angabe zum Grad der Kompaktierung, dann könnte sich jeder die Befahrbarkeit entsprechend seinen Ansprüchen daraus ableiten. Grüße Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] hiking route mit ele angaben in den nodes?
hi, kennt jemand eine sehr gut verbundene (keine lücken) hiking relation, wo einzelne genutzte nodes auch ein ele tag haben? wenn ja, bitte location grob und die ID. danke gerhard ___ 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 08:23, schrieb Ulf Lamping: 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. Übertreibungen sind immer sehr konstruktiv. 1) es geht nicht um 10 tags, sondern um 3 2) für einen einzelnen Mapper geht es nicht um 3 tags, sondern um 1 (ein Trekker tagt nur bicycle:trekking) 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen 4) smoothness=bad sagt mir - will ich da auf einer Radtour lang? - komme ich da nur zur Not lang? - komme ich da mit einem Rollstuhl lang? - mir sagt es das mitnichten - bicycle:trekking=yes (ok, man muss nicht abkürzen) sagte mir schon, dass einer die strecke als für ein trekking rad geeignet erachtet - plane ich touren, betrachte ich natürlich, mit welchem Radtyp ich unterwegs bin - es gilt also konkret ein tag auszuwerten, wenn es existiert - das für meinen Radtyp - smoothness muss meinetwegen nicht abgeschafft werden, faktisch ist es, zumindest in meinem Raum kaum in Verwendung 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. Dann gab es damals noch kein Proposal. Ich meine mich zu erinnern, dass auf jeder tollen Liste über die Definitionen gezankt wurde, bis jemand kam, der Rad- und Inlinertypen auf die Werte dieses Tags gepresst hat (und nicht andersherum). 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. Das ist falsch. Bitte setze Dich mit meinem Vorschlag auseinander. Ich schrieb schon, dass die klare begriffliche Trennung vermutlich dazu führen wird, dass Trekker eher :trekking, MTBler eher :mtb und Rennradler eher :race nutzen werden - also pro Typ das Tag von einem Mapper, der am ehesten beurteilen kann, ob seine Radkategorie auf dem Weg nutzbar ist, gesetzt wird. Das ist eben mit smoothness mitnichten der Fall: hier weiß ich nicht, ob der tagger/mapper tatsächlich zu Fuß, mit dem Rad oder per Inline-Skates unterwegs war und auf welcher Grundlage er den Wert für smoothness entschieden hat. Ich habe also wesentlich weniger Information, um deine Fragen oben zu beantworten. Und für Rollstuhlfahrer gibt es wheelchair=*, btw.. bicycle=yes sagt (nur) aus ob man dort langfahren *darf*, nicht ob man dort langfahren will oder kann. Eben. Etwas anderes habe ich nie behauptet. Woher soll OSM wissen was ein Nutzer _will_? Bei kann sieht es schon anders aus. tatsächlich wird bicycle= wird auch gesetzt, schon wenn man nur dort langfahren *kann* - siehe designated auf [http://wiki.openstreetmap.org/wiki/Key:access]. Dort heißt es bei law or otherwise. Es geht bei der Zugangsbeschreibung nicht nur um die rechtliche, sondern auch um die tatsächliche Verwendung (wobei letzteres wieder subjektiver ist). Das lenkt aber vom Thema ab. Ich will mich nicht mit der Sinnhaftigkeit von access=* Werten auseinandersetzen. Denn die sind eigentlich etabliert, wenngleich Du scheinbar nur deren rechtlichen Aspekt beleuchtest 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. Doch, genau das will ich sagen. Ich will die gleiche Bandbreite an Werten, die für das normale bicycle-tag zur Verfügung stehen und dort ausdrücken, ob Räder dort langfahren dürfen oder es tatsächlich überwiegend tun. Eine Mischung von rechtlichen Einschränkungen und Vorlieben der Radfahrer sollten wir hier tunlichst vermeiden um nicht noch mehr Unverständlichkeit zu produzieren.
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 08:39, schrieb Heiko Jacobs: 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 ... Da steckt sehr viel Wahrheit drin. Da OSM aber das aktuelle Weltbild wiederspiegelt, ist das dann eben auch dynamisch - es gilt den aktuellen Zustand zu erfassen und der kann sich natürlich ändern. Die OSM-Daten haben kein absolutes Ziel, sie werden sich immer wandeln (müssen), so wie die Karten von traditionellen Herstellern auch. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 16:29 schrieb Christian Müller cmu...@gmx.de: 1) es geht nicht um 10 tags, sondern um 3 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen es geht um 3 zusätzliche tags allein für Radfahrer. Danach kommen die Rollstuhlfahrer mit 3 Typen, die Inlineskater mit 2 Typen, 4 Typen Kinderwägen, Tretroller, Einkaufswägen, Stelzen, verschiedene Arten von Schuhen, etc. Der Ansatz skaliert einfach ziemlich schlecht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Heiko Jacobs wrote: Wir werden um ein =gehtnicht wohl nicht rumkommen mittelfristig ... Ich bin eher Fredericks Meinung. Zu erfassen sind objektive Zustände von Wegen sowie Schilder, die die Nutzung einschränken, kein subjektives geht nicht, weil das jeder anders sieht. Was wir auch noch bräuchten, wäre ein Wert bicycle=beachteseparateradwege ... Dann bicycle=no wird auch öfters falsch benutzt, um das Radrouting von Eine Trennung in Du darfst hier nicht wegen Z254 und Du darfst hier nicht wegen straßenbegleitendem Radweg ist nicht sinnvoll, weil beides in Du darfst nicht mündet. Der extrem seltene Ausnahmefall Ja aber da liegt heute Schnee und jetzt darf ich _doch_ ist für die Praxis und das Routing nicht relevant. Konkret und vor Ort nimmt einem das Navi das Denken nicht ab. Aber die Diskussion hatten wir schon mehrfach und ich habe keine Lust das aufzuwärmen. 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
Rainer Kluge wrote: Bei der Planung meiner Radtouren in unbekanntem Gebiet komme ich mit den existierenden Tags gut zurecht: Ich auch. 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. ACK. 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 ;) Exakt. 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 2. März 2011 15:18 schrieb Rainer Kluge rklug...@web.de: Das hatte ich schon befürchtet. Meine positive Meinung zu Tracktype muss ich wohl revidieren. Ob ein Weg befestigt ist, also asphaltiert, betonniert oder mit glatten Betonsteinen gepflastert, oder nur eine extrem kompaktierte Oberfläche hat, macht für mich schon einen erheblichen unterschied. Bei Regen und oft auch noch in den Tagen nach dem Regen sind solche Wege meist mit erheblicher Schmutzbildung verbunden und auch ein extrem kompaktierter Belag wird sich bei Dauerregen an der Oberfläche aufweichen. Vor ich eine Tour auf so einem Weg plane, will ich daher zumindest wissen, ob er befestigt ist oder nicht. ja, ich auch. Daher setze ich auch explizit den surface key, z.B. mit asphalt, concrete, paving_stones, ground, ... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 16:13 schrieb Joerg Fischer o...@jfis.de: Eine Trennung in Du darfst hier nicht wegen Z254 und Du darfst hier nicht wegen straßenbegleitendem Radweg ist nicht sinnvoll, weil beides in Du darfst nicht mündet. Das sehe ich komplett anders. Die Du darfst hier nicht wegen straßenbegleitendem Radweg Geschichte kann der Router selbst erkennen (bzw. wenn das nicht so einfach geht, dann sollte man das mit einer Relation oder einem speziellen tag machen), dass dort ein Schild steht muss man ihm hingegen sagen. In der Praxis ist die straßenbegleitender-Radweg-regelung m.E. auch meistens wirkungslos hins. Sanktionen: man kann immer woanders hinwollen als der Radweg führt, und dann gilt die Benutzungspflicht auch nicht. Über ein Verbotsschild braucht man dagegen nicht lange zu diskuttieren, da ist die Lage klar. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo Rainer, Wenn die existierenden Tags (highway, tracktype, bicycle, surface, smoothness) 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. Ich stimme in vielen Punkten mit Dir überein. Mir geht es auch nicht darum, Tags abzuschaffen, sondern welche hinzuzufügen. Du sprichst gerade das Problem an, dass ich habe. Tracks ohne tracktype und ohne surface, aber mit bicycle=yes. Ich finde halt, dass es falsch ist, ein so vielgestaltiges Fortbewegungsmittel, wie das Fahrrad, in einem Tag zusammenzuschmelzen. Gerade Anfänger taggen nicht mit komplettem Satz an existierenden Tags, geben aber schnell mal bicycle=yes ein. Wenn die ihre Zugangsbeschränkungen mit dem Tag eintragen würden, dass ihrem Radlerprofil entspricht, könnte man daraus Informationen extrahieren, die durch das Fehlen vieler anderer Tags noch nicht zur Verfügung stehen (tracktype, surface, smoothness). Als redundant sehe ich diese Tags nicht an, da sie radspezifische Verwendung rechtlich und nach Gebrauch beschreiben und, vordergründig, zumindest nicht direkt Aussagen zur Wegbeschaffenheit treffen. Das heißt nicht, dass man keine Implikationen auf die Beschaffenheit treffen kann, aber erst mit dieser (und dem Regelgerüst in deiner mail) stellt sich ein gewisser Redundanzgrad ein - der ist aber eher unscharf. Und angenommen alle Tags werden verwendet, dann dient das für andere MapperInnen fast zur Plausibilitätsprüfung, ich sehe darin also eher einen weiteren Vorteil. Gruß, Christian ___ 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 09:28, schrieb Chris66: Am 02.03.2011 02:13, schrieb Christian Müller: Hallo, Alles schön und gut aber wie willst Du garantieren dass die Mapper sich dran halten wenn sie schon das einfache Schema nicht kapieren und wild taggen ? Guter Punkt. Wenn man aber davon ausgeht, dass das einfache Schema evtl. deshalb nicht kapiert wird, weil es zu unscharf/ungenau oder unverständlich ist, hätten wir auch einen Grund, zusätzliche Möglichkeiten des Taggens wenigstens zur Verfügung zu stellen. Das ist doch das Problem der Standardisierung allgemein. All das, was im Papier nicht spezifiziert ist, ist in der Implementation frei wählbar. Und so ist das dann auch in jedweder Industrie (ob Soft- oder Hardware). Die Frage ist nur, ob ich mit einer Änderung des Standards tatsächlich näher spezifiziere (als vorher) oder eben nicht. Das Anpassen des Tagging-Schemas bei OSM ist ja ohnehin ein mehr oder weniger evolutionärer Standardisierungsprozess.. Gruß Christian ___ 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 09:32, schrieb Henning Scholland: Hallo, du hast sicher recht, dass tracktype und smoothness subjektiv sind. Allerdings sollte man dabei nicht vergessen, was es bedeuten würde, dass ganze in objektive Kriterien zu gießen. Kaum einer würde mit einem Zentimetermaß die tiefe der Schlaglöcher nachmessen oder deren Abstand. Auch eine Statistik über die vorherrschende Größe der Kiesel halte ich für zu aufwändig, als dass es eine große Anzahl wirklich macht. Die Folge dürfte sein, dass die Masse der Mapper diese objektiven Kriterien ohnehin nur abschätzt. Dann macht es meiner Meinung aber auch keinen Unterschied zu einem Abschätzen von smoothness=bad. Nochmal, es geht mir nicht darum, smoothness=* abzuschaffen, oder dessen Definition in Frage zu stellen. Fakt ist, dass es sich nicht selbst erklärt, so wie es aber fast jedes andere tag in OSM tut (..erm.. tun sollte). Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 17:04 schrieb Christian Müller cmu...@gmx.de: Nochmal, es geht mir nicht darum, smoothness=* abzuschaffen, oder dessen Definition in Frage zu stellen. Fakt ist, dass es sich nicht selbst erklärt, so wie es aber fast jedes andere tag in OSM tut (..erm.. tun sollte). Dein Vorschlag widerspricht allerdings diversen Regeln: 1. Beförderungsmittel=yes/no/designated ist eine legale Attributierung. Von daher erklärt es sich auch nicht selbst, sondern verleitet zu Fehlinterpretationen. 2. Tags sind auf Englisch. 3. Wir verwenden keine Abkürzungen. Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. da drückt man ein Auge zu, ganz korrekt im Sinne des Schemas ist das auch nicht. Gruß Martin ___ 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 12:45, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 09:15 schrieb Frederik Rammfrede...@remote.org: Zugleich ist es aber nicht nach der Art von OSM, irgendwelche Schwammkategorien zu verwenden. (= also kein smoothness=bad - was fuer den einen bad, ist fuer den anderen superb) bad ist genau definiert. Das bedeutet, dass man stabile Räder benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann (robust_wheels) trekking bike, normal cars, Rickshaw and all below . Eine Stufe schlechter (very_bad) bräuchte man schon ein Auto mit großer Bodenfreiheit oder ein MTB, eine Stufe besser (intermediate) kommt man mit allgemeinen Fahrzeugen wie Rollstühlen und Citybikes auch noch durch. vielleicht sollte man die smoothness-Werte überdenken und gleich die Erklärungen, statt der schwammigen Wörter verwenden.. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo, On 03/02/2011 12:45 PM, M?rtin Koppenhoefer wrote: bad ist genau definiert. Das bedeutet, dass man stabile Räder benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann (robust_wheels) trekking bike, normal cars, Rickshaw and all below . bad ist ein ganz normales Wort des alltaeglichen Sprachgebrauchs und bedeutet schlecht. Instinktiv werden Leute es also bei einer schlechten Oberflaechenbeschaffenheit verwenden, und die Definition kannst Du in der Pfeife rauchen. Das Schema schlechtzureden bringt nichts. Schlechtreden kann man nur etwas, was an sich gut ist. Ich finde das Schema schlecht. Meine Alternative ist, das Mapping von Oberflaechenqualitaeten abseits von tracktype und surface sein zu lassen. Solang Leute das fuer sich selber als Hobby benutzen, mir egal, aber in dem Moment, wo jemand ankommen sollte und sowas sagen wie zu einer guten Erfassung von Wegen gehoert auch smoothness, werde ich dem widersprechen. Nein, das stimmt so nicht. Tracktype ging nie um die Art von Fahrzeugen, die den Weg benutzen können, sondern um den Ausbaugrad, Das ist genau die Haarspalterei, die uns nicht weiterbringt. Erst kuerzlich sagte ein Fahrradfahrer zu mir: Mit der OpenCycleMap kann ich nichts anfagen, weil sie nicht nach tracktype unterscheidet. Natuerlich koennte es auch Wege geben, die trotz sehr glatter Oberflaeche und asphaltiertem Ausbauzustand aus anderen Gruenden fuer Radfahrer nicht geeignet sind. Gleich mal ein Proposal schreiben! Bye Frederik ___ 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 16:41, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 16:29 schrieb Christian Müllercmu...@gmx.de: 1) es geht nicht um 10 tags, sondern um 3 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen es geht um 3 zusätzliche tags allein für Radfahrer. Danach kommen die Rollstuhlfahrer mit 3 Typen, die Inlineskater mit 2 Typen, 4 Typen Kinderwägen, Tretroller, Einkaufswägen, Stelzen, verschiedene Arten von Schuhen, etc. Der Ansatz skaliert einfach ziemlich schlecht. Evtl., der bisherige aber auch: foot motorcar motorcycle motor_vehicle bicycle wheelchair psv hgv Wenn die Inliner kommen, sollen sie ihre Tags haben, genauso wie die anderen Leute. We can't have it, because it does not fit the spec. hatten wir schon vor OSM.. Gruß, Christian ___ 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 16:43, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 15:18 schrieb Rainer Klugerklug...@web.de: Das hatte ich schon befürchtet. Meine positive Meinung zu Tracktype muss ich wohl revidieren. Ob ein Weg befestigt ist, also asphaltiert, betonniert oder mit glatten Betonsteinen gepflastert, oder nur eine extrem kompaktierte Oberfläche hat, macht für mich schon einen erheblichen unterschied. Bei Regen und oft auch noch in den Tagen nach dem Regen sind solche Wege meist mit erheblicher Schmutzbildung verbunden und auch ein extrem kompaktierter Belag wird sich bei Dauerregen an der Oberfläche aufweichen. Vor ich eine Tour auf so einem Weg plane, will ich daher zumindest wissen, ob er befestigt ist oder nicht. ja, ich auch. Daher setze ich auch explizit den surface key, z.B. mit asphalt, concrete, paving_stones, ground, ... Der surface=* key z.B. ist in einem wesentlichen Punkt auch überladen: 1) Unterscheidung paved | unpaved (dt. befestigt | unbefestigt) 2) Materialien (manche Programme hinterlegen Listen, um best. Materialen auf paved | unpaved zu mappen.. da sich die Liste im Wiki erweitert/ändert - not good) Persönlich ist mir surface=* vor den anderen, sprachlich schlecht definierten Tagwerten (smoothness/tracktype mainly), noch am liebsten. Man kann surface=*, ohne groß das Wiki zu konsultieren, aus der Realität ableiten und umgekehrt direkt aus dem DB-Wert auch den Oberflächentyp wieder bestimmen. Das funktioniert hervorragend (in der Praxis!) - für tracktype=* hingegen schlecht und für smoothness=* fast gar nicht. Ich kenne die Wiki-Definition zu tracktype genau, aber sie ist eben ohne Wiki unbrauchbar (grade1-5 - was soll ein noob damit anfangen, wenn er das Wiki nicht kennt und es. evtl. gerade nicht verfügbar ist). tracktype/smoothness sollten m.E. die gleiche, _unmittelbare_ Aussagekraft erreichen, wie surface. Dann würde man sie in der Datenbasis auch häufiger und in richtiger Verwendung antreffen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hi, On 03/02/2011 05:50 PM, Christian Müller wrote: Der surface=* key z.B. ist in einem wesentlichen Punkt auch überladen: 1) Unterscheidung paved | unpaved (dt. befestigt | unbefestigt) 2) Materialien (manche Programme hinterlegen Listen, um best. Materialen auf paved | unpaved zu mappen.. da sich die Liste im Wiki erweitert/ändert - not good) Da musst Du mir als nicht-Bauingenieur aber mal nachhelfen. Kann denn eine Strasse mit z.B. surface=cobblestones mal paved und mal unpaved sein, oder wie muss ich das verstehen? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] hiking route mit ele angaben in den nodes?
Am 02.03.2011 15:42, schrieb Gary68: hi, kennt jemand eine sehr gut verbundene (keine lücken) hiking relation, wo einzelne genutzte nodes auch ein ele tag haben? wenn ja, bitte location grob und die ID. danke gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ist jetzt nicht genau das was du suchst, aber evtl. kannst du dir mit srtm2wayinfo [1] genau so eine Route selber erstellen. Selber damit gearbeitet hab ich allerdings noch nicht. Henning [1] http://wiki.openstreetmap.org/wiki/Srtm2wayinfo ___ 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 17:10, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 17:04 schrieb Christian Müllercmu...@gmx.de: Nochmal, es geht mir nicht darum, smoothness=* abzuschaffen, oder dessen Definition in Frage zu stellen. Fakt ist, dass es sich nicht selbst erklärt, so wie es aber fast jedes andere tag in OSM tut (..erm.. tun sollte). Dein Vorschlag widerspricht allerdings diversen Regeln: 1.Beförderungsmittel=yes/no/designated ist eine legale Attributierung. Von daher erklärt es sich auch nicht selbst, sondern verleitet zu Fehlinterpretationen. Ich schätze Du meinst rechtlich (engl. legal). Ja, Fehlinterpretationen möglich, in demselben etablierten Maße, wie für bestehende Beförderunsmittel - das ist ja gerade der Vorteil. Die meisten Mapper müssen nichts hinzulernen, denn sie kennen den Katalog rechtlicher Attribute bereits. 2. Tags sind auf Englisch. Welches meiner Tags ist nicht auf Englisch? 3. Wir verwenden keine Abkürzungen. Das wurde schon erklärt. Man muss sich nicht daran aufhängen, ob nun trek oder trekking verwendet wird. Ansonsten ist mir nicht klar, was Du mit 3. meinst. Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. da drückt man ein Auge zu, ganz korrekt im Sinne des Schemas ist das auch nicht. Ich verstehe nicht, wie Du darauf kommst - was sonst wäre denn im Sinne des Schemas? Das OSM-Schema ist ein evolutionäres Produkt und wächst mit den Anforderungen, wenig daran wurde wirklich durch-designed - it just-works (tm) or not, abhängig davon, was Du damit anfangen willst. Gruß ___ 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 17:19, schrieb Frederik Ramm: Hallo, On 03/02/2011 12:45 PM, M?rtin Koppenhoefer wrote: bad ist genau definiert. Das bedeutet, dass man stabile Räder benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann (robust_wheels) trekking bike, normal cars, Rickshaw and all below . bad ist ein ganz normales Wort des alltaeglichen Sprachgebrauchs und bedeutet schlecht. Instinktiv werden Leute es also bei einer schlechten Oberflaechenbeschaffenheit verwenden, und die Definition kannst Du in der Pfeife rauchen. Na endlich - ich dachte schon, dass mich hier gar niemand versteht :) Das ist exakt das, was ich sagen wollte. Es geht mir nicht darum, dass die Wiki-Definition eindrucksvoll, hübsch und komplett ist, sondern dass das Tag selbst schwach ist. Das Schema schlechtzureden bringt nichts. Schlechtreden kann man nur etwas, was an sich gut ist. Ich finde das Schema schlecht. Meine Alternative ist, das Mapping von Oberflaechenqualitaeten abseits von tracktype und surface sein zu lassen. Solang Leute das fuer sich selber als Hobby benutzen, mir egal, aber in dem Moment, wo jemand ankommen sollte und sowas sagen wie zu einer guten Erfassung von Wegen gehoert auch smoothness, werde ich dem widersprechen. +1 Gruß ___ 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 17:50, schrieb Christian Müller: Der surface=* key z.B. ist in einem wesentlichen Punkt auch überladen: 1) Unterscheidung paved | unpaved (dt. befestigt | unbefestigt) 2) Materialien (manche Programme hinterlegen Listen, um best. Materialen auf paved | unpaved zu mappen.. da sich die Liste im Wiki erweitert/ändert - not good) Da versteh ich dich nicht so ganz... paved und unpaved sind allgemeine Werte, die man weiter spezifizieren kann, in dem man stattdessen das Material explizit erfasst. Hier gibt es keinen Widerspruch. Wenn Programme Listen führen, können diese Programme diese Listen genauso erweitern, wie es das wiki auch kann. Ich führe auch so eine Liste, die ich ab und an an das wiki bzw. an Taginfo anpasse. Das muss man aber generell bei jeder Auswertung machen. Henning ___ 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 17:57, schrieb Frederik Ramm: Hi, On 03/02/2011 05:50 PM, Christian Müller wrote: Der surface=* key z.B. ist in einem wesentlichen Punkt auch überladen: 1) Unterscheidung paved | unpaved (dt. befestigt | unbefestigt) 2) Materialien (manche Programme hinterlegen Listen, um best. Materialen auf paved | unpaved zu mappen.. da sich die Liste im Wiki erweitert/ändert - not good) Da musst Du mir als nicht-Bauingenieur aber mal nachhelfen. Kann denn eine Strasse mit z.B. surface=cobblestones mal paved und mal unpaved sein, oder wie muss ich das verstehen? Nein, es geht nur darum, dass surface Heimat für zwei Arten von Klassifikationen ist a) einer groben (befestigt, unbefestigt) b) nach verwendetem Material Konsistent bleibt das ganze, klar, weil sich Materialen i.d.R. der einen oder anderen, groben Klasse zuordnen lassen. Problematisch finde ich, dass durch neue Materialientypen, verschiedenste Softwareprojekte ständig ihre Klassifikation nachpflegen müssen, wenn sie surface=* verwenden (denn sie können sich ja nicht einfach darauf verlassen, dass paved oder unpaved drinsteht, sondern müssen alle Materialen auswerten, selbst wenn sie nur zw. paved|unpaved entscheiden wollen). Und was macht man z.B. mit Holz? Ich würde schon sagen, dass manche hölzerne Wege als befestigt gelten können (Hausbrücken z.B.), andere, wo nur ein paar logs verstreut im Sumpf liegen, eher nicht. surface=* ist auch nicht perfekt, aber es ist _wesentlich_ besser zu handhaben und brauchbarer, auch was die unmittelbare Lesbarkeit des tags betrifft, als tracktype/smoothness.. Grüße, Christian ___ 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 18:11, schrieb Henning Scholland: Da versteh ich dich nicht so ganz... paved und unpaved sind allgemeine Werte, die man weiter spezifizieren kann, in dem man stattdessen das Material explizit erfasst. Hier gibt es keinen Widerspruch. Wenn Programme Listen führen, können diese Programme diese Listen genauso erweitern, wie es das wiki auch kann. Ich führe auch so eine Liste, die ich ab und an an das wiki bzw. an Taginfo anpasse. Das muss man aber generell bei jeder Auswertung machen. Eben, angenommen paved/unpaved würde extra erfasst (ich glaube da gab es sogar mal ein proposal, dass surface:material verwendet hat, um das Material konkret zu erfassen), müsstest Du, insofern Du an einer genauen Auswertung gar nicht interessiert bist, auch nicht diese Listen ständig mitpflegen.. deshalb meinte ich das tag sei überladen.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Ein trekking bike ist in etwa so Englisch wie ein handy. Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone). Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht halbwegs klar definiert sind (wir taggen ja auch nicht typische residentials in Bergdörfern mit lambo=no oder subaru=yes). Simon Am 02.03.2011 18:03, schrieb Christian Müller: Am 02.03.2011 17:10, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 17:04 schrieb Christian Müllercmu...@gmx.de: Nochmal, es geht mir nicht darum, smoothness=* abzuschaffen, oder dessen Definition in Frage zu stellen. Fakt ist, dass es sich nicht selbst erklärt, so wie es aber fast jedes andere tag in OSM tut (..erm.. tun sollte). Dein Vorschlag widerspricht allerdings diversen Regeln: 1.Beförderungsmittel=yes/no/designated ist eine legale Attributierung. Von daher erklärt es sich auch nicht selbst, sondern verleitet zu Fehlinterpretationen. Ich schätze Du meinst rechtlich (engl. legal). Ja, Fehlinterpretationen möglich, in demselben etablierten Maße, wie für bestehende Beförderunsmittel - das ist ja gerade der Vorteil. Die meisten Mapper müssen nichts hinzulernen, denn sie kennen den Katalog rechtlicher Attribute bereits. 2. Tags sind auf Englisch. Welches meiner Tags ist nicht auf Englisch? 3. Wir verwenden keine Abkürzungen. Das wurde schon erklärt. Man muss sich nicht daran aufhängen, ob nun trek oder trekking verwendet wird. Ansonsten ist mir nicht klar, was Du mit 3. meinst. Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. da drückt man ein Auge zu, ganz korrekt im Sinne des Schemas ist das auch nicht. Ich verstehe nicht, wie Du darauf kommst - was sonst wäre denn im Sinne des Schemas? Das OSM-Schema ist ein evolutionäres Produkt und wächst mit den Anforderungen, wenig daran wurde wirklich durch-designed - it just-works (tm) or not, abhängig davon, was Du damit anfangen willst. Gruß ___ 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] Status Fahrradwege-Tags
Am 02.03.2011 18:16, schrieb Christian Müller: Am 02.03.2011 18:11, schrieb Henning Scholland: Da versteh ich dich nicht so ganz... paved und unpaved sind allgemeine Werte, die man weiter spezifizieren kann, in dem man stattdessen das Material explizit erfasst. Hier gibt es keinen Widerspruch. Wenn Programme Listen führen, können diese Programme diese Listen genauso erweitern, wie es das wiki auch kann. Ich führe auch so eine Liste, die ich ab und an an das wiki bzw. an Taginfo anpasse. Das muss man aber generell bei jeder Auswertung machen. Eben, angenommen paved/unpaved würde extra erfasst (ich glaube da gab es sogar mal ein proposal, dass surface:material verwendet hat, um das Material konkret zu erfassen), müsstest Du, insofern Du an einer genauen Auswertung gar nicht interessiert bist, auch nicht diese Listen ständig mitpflegen.. deshalb meinte ich das tag sei überladen.. Natürlich musst man auch dann über die Materialien gehen. Ich als Auswerter will doch entscheiden, was für mich befestigt ist und was nicht. Ist Schotter noch befestigt, oder nicht? Was überladen ist, sind Werte wie concreteplates:40 oder so. Da gebe ich dir recht. Sowas hat im surface nicht wirklich was verloren. Henning ___ 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 18:16, schrieb Simon Poole: Ein trekking bike ist in etwa so Englisch wie ein handy. Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone). Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht halbwegs klar definiert sind (wir taggen ja auch nicht typische residentials in Bergdörfern mit lambo=no oder subaru=yes). bitte dann den korrekten namespace verwenden motorcar:lambo=yes motorcar:subaru=no ;-) Dann mach halt einen besseren Vorschlag.. Im übrigen ist das gar nicht so verkehrt - es gibt ja auch unterschiedliche Klassen an Fahrzeugen. USVs, Pickups, etc. Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse ist. Und ein Engländer kennt doch sehr wohl auch den Unterschied zwischen Rennrad und Mountainbike. Wenn ihm die Kategorie Trekking nicht bewußt ist, ist das nur ein Zeichen, das hier das marketing versagt hat, oder andere Wege gegangen ist.. Gruß, Christian ___ 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 18:22, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 18:02 schrieb Christian Müllercmu...@gmx.de: in demselben etablierten Maße, wie für bestehende Beförderunsmittel - das ist ja gerade der Vorteil. Die meisten Mapper müssen nichts hinzulernen, denn sie kennen den Katalog rechtlicher Attribute bereits. verstehe ich jetzt nicht, Du willst es doch gerade nicht für ein Verbot, sondern für die Eignung verwenden. Deine Beispiele verwenden bicycle für eine Empfehlung (sandiger Weg - no), das ist nicht die Bedeutung des bicycle-tags. Hier bin ich Opfer der unscharfen Definition des access-tags in der Wiki. Viele OSMer auf _dieser_ Liste beschränken access=* auf rein rechtliche Gegebenheiten. Die englische Wiki zieht Eignung mit in den Wertebereich von access=* - bei designated z.B. (by law or otherwise). Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Dennoch müsst ihr auch hier wieder unterscheiden: 1) Die schöne, rechtlich orientierte, Definition von bicycle=* im Wiki 2) Die Verwendung in der Realität 3) Problem hier wieder: kein Namespace - nicht selbsterklärend Eigentlich spezifiziert, nach der Meinung dieser Liste, wenn ich es richtig aufgenommen habe, das bicycle=* Tag access=* näher, so dass, bei Verwendung eines Namespaces, die Daten eigentlich so aussehen müssten: access=* access:bicycle=* access:psv=* etc. So hübsch ist aber die OSM-Welt nicht, weswegen vermutlich auch viele Newbies bicycle=* und andere nicht im Sinne der Zugangsbeschränkung, sondern als Eignungswert verwenden. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] hiking route mit ele angaben in den nodes?
On Wed, Mar 02, 2011 at 03:42:52PM +0100, Gary68 wrote: hi, kennt jemand eine sehr gut verbundene (keine lücken) hiking relation, wo einzelne genutzte nodes auch ein ele tag haben? Die Routen in der Schweiz haben an den Nodes, wo Wegweiser stehen, meistens ein ele-Tag. Beispiel: http://www.openstreetmap.org/browse/relation/1107385 Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
On 2011-03-02 18:46, Christian Müller wrote: Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Nur zur Info: zumindest Rennräder kennt der Gesetzgeber hier in Österreich. § 4. (1) Als Rennfahrrad gilt ein Fahrrad mit folgenden technischen Merkmalen: 1. Eigengewicht des fahrbereiten Fahrrades höchstens 12 kg; 2. Rennlenker; 3. äußerer Felgendurchmesser mindestens 630 mm und 4. äußere Felgenbreite höchstens 23 mm. (2) Rennfahrräder dürfen ohne die in § 1 Abs. 1 Z 2 bis 8 genannte Ausrüstung in Verkehr gebracht werden; bei Tageslicht und guter Sicht dürfen Rennfahrräder ohne diese Ausrüstung verwendet werden. (BGBl. II, Nr. 146/2001 - Fahrradverordnung) Alles nicht so einfach :-). Tschau, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 18:46 schrieb Christian Müller cmu...@gmx.de: Am 02.03.2011 18:22, schrieb M∡rtin Koppenhoefer: Hier bin ich Opfer der unscharfen Definition des access-tags in der Wiki. Viele OSMer auf _dieser_ Liste beschränken access=* auf rein rechtliche Gegebenheiten. Die englische Wiki zieht Eignung mit in den Wertebereich von access=* - bei designated z.B. (by law or otherwise). das lese ich anders: neben gesetzlichen Verbote gibt es ja auch privatrechtliche Verbote. Im SonyCenter in Berlin darfst Du z.B. nicht Fahrradfahren. Nicht mal nachts um 4 wenn ausser den privaten Wachleuten kein anderer weit und breit da ist. Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Dennoch müsst ihr auch hier wieder unterscheiden: man könnte den Tag ja umbenennen und sowas wie geeignet (suitability oder so) verwenden. Fände ich aber immer noch nicht gut aus den o.g. Gründen: wir sollten nicht für jede Fahrzeugunterart ein eigenes Tag brauchen, um eine subjektive Eignung zu vermerken. Ich bin auch kein Freund von Smoothness und habe das bisher bei ungefähr ein bis zwei Mapping-anlässen mal benutzt, das aber vor allem deshalb, weil man ständig nachsehen muss, wie was definiert ist und geschrieben werden soll. 8 Stufen sind auch nicht gerade wenig. Besser wären wohl 3 Grade, die man dann zum Haarespalten noch mal feiner unterteilen könnte. 1. Die beste Klasse wäre (smooth) (war excellent, good, intermediate) (d.h. alles, was man mit Rollstühlen, normalen Fahrrädern und Sportwägen problemlos benutzen kann), glatte Fahrbahn, weiter unterteilbar (subtags) in sehr glatt, normal, schon etwas rauher Für Rennräder würde man am liebsten die Unterklasse 1 haben wollen, 2 geht noch, 3 ist schon unangenehm bzw. kaum möglich 2. die mittlere Klasse: (coarse ?) (war bei smoothness bad, very bad, horrible) alles was man mit einem normalen Auto noch meistern kann (Breite vorausgesetzt), wobei horrible schon Schrittgeschwindigkeit erfordert. Fürs Fahrrad nicht mehr richtig angenehm aber machbar bei etwas Können. D.h. entweder Steinchen, die noch überfahrbar sind, Rillen, und andere Unebenheiten 3. die rauhe Klasse (rough) wenn überhaupt nur noch mit Traktoren / Geländewagen befahrbar, mit MTB und gutem Können, je nach Subklasse evtl. nur noch mit Maschinen, die gehen können, machbar ;-), Esel, etc., d.h. größere Steine, größere und tiefe Löcher, Spalten, etc. das könnte man dann noch weiter unterteilen z.B. in nochmal 3 Stufen (grade1 bis grade3, um Verwechslungen (umtaggen) auszuschließen würde ich jeweils einen anderen key verwenden, z.B. coarse=grade1, smooth=grade1 etc. Wers genau wissen will, macht dieses Subtagging, der Normalmapper müsste sich nur unterscheiden zwischen glatt, Schotter und kleinere Unebenheiten sehr rau, mit KfZ nicht befahrbar Obs jetzt die Wörter sind, oder man was besseres findet, ist im Prinzip egal. M.E. ist die Ebenheit schon eine Eigenschaft, die interessiert, und smoothness konnte sich nie so richtig durchsetzen, m.E. vor allem wegen der unseligen Wortwahl bei den values. Was allerdings grundsätzlich ein Problem bei diesem Schema ist: es ist vor allem für mineralische Oberflächen geeignet. Feuchter organischer Boden, Sand, Matsch und so was wäre damit immer noch nicht charakterisiert (aber dafür gibts ja surface). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
On 2011-03-02 18:27, Christian Müller wrote: Am 02.03.2011 18:16, schrieb Simon Poole: Ein trekking bike ist in etwa so Englisch wie ein handy. Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone). Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht halbwegs klar definiert sind (wir taggen ja auch nicht typische residentials in Bergdörfern mit lambo=no oder subaru=yes). bitte dann den korrekten namespace verwenden motorcar:lambo=yes motorcar:subaru=no ;-) Dann mach halt einen besseren Vorschlag.. Ich denke, das Grundproblem bei Deinem Vorschlag ist, dass Du das Problem der unzureichenden bzw. lückenhaften Kennzeichnung der Tauglickeit von Wegen mit Fahrradtypen lösen willst, deren Einteilung genauso subjektiv ist, wie smoothness oder tracktype. Dadurch wird mMn die Situation nicht klarer. Tschau, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbildauswertung
Wenn das Luftbild nicht genau georeferenziert ist, die Daten aber bereits zum richtig korrigierten Luftbild eingetragen sind, dann muss ich, bevor ich neue Daten hinzufüge, das Luftbild passend verschieben. Wie mache ich das? http://wiki.openstreetmap.org/wiki/DE:Entwurf_Luftbilder_HowTo/neu#Verschobene_Luftbilder Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] osmosis - mal wieder zu blöd...
hi, habe srtm daten der uni stuttgart im osm format runtergeladen. scheint v0.5-format zu sein. wie kann ich das in 0.6 umwandeln? habe folgendes probiert: ../osmosis/osmosis-0.35.1/bin/osmosis --read-xml-0.5 file=a.osm --sort type=TypeThenId --write-xml-0.6 file=as.osm aber: SEVERE: Execution aborted. org.openstreetmap.osmosis.core.OsmosisRuntimeException: Task 2-sort does not support data provided by default pipe stored at level 1 in the default pipe stack. at org.openstreetmap.osmosis.core.pipeline.common.PipeTasks.retrieveTask(PipeTasks.java:157) at org.openstreetmap.osmosis.core.pipeline.common.TaskManager.getInputTask(TaskManager.java:165) at org.openstreetmap.osmosis.core.pipeline.v0_6.SinkSourceManager.connect(SinkSourceManager.java:51) at org.openstreetmap.osmosis.core.pipeline.common.Pipeline.connectTasks(Pipeline.java:74) at org.openstreetmap.osmosis.core.pipeline.common.Pipeline.prepare(Pipeline.java:116) at org.openstreetmap.osmosis.core.Osmosis.run(Osmosis.java:79) at org.openstreetmap.osmosis.core.Osmosis.main(Osmosis.java:30) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) at org.codehaus.classworlds.Launcher.main(Launcher.java:31) was habe ich heute falsch gemacht? files sind diese hier: http://geoweb.hft-stuttgart.de/SRTM/srtm_as_osm/ BY THE WAY: gibt es die srtm daten in aktuellem osm format für z.b. hessen oder deutschland? ciao gerhard ___ 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 19:07, schrieb Andreas Perstinger: On 2011-03-02 18:46, Christian Müller wrote: Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Nur zur Info: zumindest Rennräder kennt der Gesetzgeber hier in Österreich. § 4. (1) Als Rennfahrrad gilt ein Fahrrad mit folgenden technischen Merkmalen: 1. Eigengewicht des fahrbereiten Fahrrades höchstens 12 kg; 2. Rennlenker; 3. äußerer Felgendurchmesser mindestens 630 mm und 4. äußere Felgenbreite höchstens 23 mm. (2) Rennfahrräder dürfen ohne die in § 1 Abs. 1 Z 2 bis 8 genannte Ausrüstung in Verkehr gebracht werden; bei Tageslicht und guter Sicht dürfen Rennfahrräder ohne diese Ausrüstung verwendet werden. (BGBl. II, Nr. 146/2001 - Fahrradverordnung) Rein interessehalber: Gibt es auch rennradbezogene Ge- und Verbote, was die Wegnutzung betrifft? z.B. Wege, auf denen ein Fahrradverbot besteht, Rennräder aber ausnahmsweise erlaubt sind? In diesem Fall müßte ich mein Implikationsschema überdenken. Gruß ___ 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 19:07, schrieb Andreas Perstinger: On 2011-03-02 18:46, Christian Müller wrote: Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Nur zur Info: zumindest Rennräder kennt der Gesetzgeber hier in Österreich. § 4. (1) Als Rennfahrrad gilt ein Fahrrad mit folgenden technischen Merkmalen: 1. Eigengewicht des fahrbereiten Fahrrades höchstens 12 kg; 2. Rennlenker; 3. äußerer Felgendurchmesser mindestens 630 mm und 4. äußere Felgenbreite höchstens 23 mm. (2) Rennfahrräder dürfen ohne die in § 1 Abs. 1 Z 2 bis 8 genannte Ausrüstung in Verkehr gebracht werden; bei Tageslicht und guter Sicht dürfen Rennfahrräder ohne diese Ausrüstung verwendet werden. (BGBl. II, Nr. 146/2001 - Fahrradverordnung) Ist in DE, soweit ich weiß, ähnlich; ich vermute, §1 verweist dabei auf die vorgeschriebene Beleuchtung. Das führt dazu, dass in DE auch nur Rennräder nach der entsprechenden juristischen Definition mit ausschließlich Ansteck-Lampen im Straßenverkehr fahren dürfen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Christian schreibt: Dann mach halt einen besseren Vorschlag.. Wieso sollte ich zu einem nicht existierenden Problem einen Vorschlag machen? Der Bereich an Wegen ,die man mit irgendwas mit 2 Rädern problemlos befahren kann ist so gross*, dass es einfach nicht sinnvoll ist, da feiner zu unterteilen, als es mit mtb (für technische mtb Trails, wo's mit dem City Bike langsam Probleme gibt) und surface (für empfindliche Rennräder und Popos) schon ist. Im übrigen ist das gar nicht so verkehrt - es gibt ja auch unterschiedliche Klassen an Fahrzeugen. USVs, Pickups, etc. Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse ist. Natürlich wäre das äquivalent zu deinem Vorschlag: motorcar:sport=no motorcar:suv=yes gewesen, und da sieht man, dass eigentlich lambo sogar hilfreicher wäre, oder noch besser: sportwagen_ohne_bodenfreiheit_und_breit_wie:-) Es scheint mir wirklich sinnvoller objektiv feststellbare Kriterien zu taggen, um beim Beispiel zu bleiben: maxwidth und mingroundclearance (gibt's nicht, wäre aber denkbar). Simon * die meisten Motorradfahrer werden dies wohl kennen: http://www.youtube.com/watch?v=yjBrpN9nmZQ für das gleiche motorisiert ___ 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 16:32, schrieb Christian Müller: Am 02.03.2011 08:39, schrieb Heiko Jacobs: 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 ... Da steckt sehr viel Wahrheit drin. Da OSM aber das aktuelle Weltbild wiederspiegelt, ist das dann eben auch dynamisch - es gilt den aktuellen Zustand zu erfassen und der kann sich natürlich ändern. Die OSM-Daten haben kein absolutes Ziel, sie werden sich immer wandeln (müssen), so wie die Karten von traditionellen Herstellern auch. !? Ja, aber doch nicht im jahreszeitlichen Wandel! Wenn jemand große Ereignisse, langfristige Baustellen etc. einträgt und die hinterher wieder entfernt - okay. Aber hiermit forderst du explizit, dass das komplette Wegenetz auf Verdacht mindestens viermal im Jahr gesichtet werden muss - das halte ich für Blödsinn. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmosis - mal wieder zu blöd...
On 02.03.2011 20:32, Gary68 wrote: habe srtm daten der uni stuttgart im osm format runtergeladen. scheint v0.5-format zu sein. wie kann ich das in 0.6 umwandeln? ../osmosis/osmosis-0.35.1/bin/osmosis --read-xml-0.5 file=a.osm --sort type=TypeThenId --write-xml-0.6 file=as.osm Warum nicht über migrate wie in der Doku beschrieben? Example: Migrating an 0.5 OSM file to API version 0.6. osmosis --read-xml-0.5 enableDateParsing=no file=input_0.5.osm --migrate --write-xml file=output_0.6.osm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] osmosis - mal wieder zu blöd...
ah, das mit dem migrate kannte ich noch nicht. und das mit dem dateparsing ist mir auch neu. DANKE! On Wed, 2011-03-02 at 21:06 +0100, Stephan Knauss wrote: On 02.03.2011 20:32, Gary68 wrote: habe srtm daten der uni stuttgart im osm format runtergeladen. scheint v0.5-format zu sein. wie kann ich das in 0.6 umwandeln? ../osmosis/osmosis-0.35.1/bin/osmosis --read-xml-0.5 file=a.osm --sort type=TypeThenId --write-xml-0.6 file=as.osm Warum nicht über migrate wie in der Doku beschrieben? Example: Migrating an 0.5 OSM file to API version 0.6. osmosis --read-xml-0.5 enableDateParsing=no file=input_0.5.osm --migrate --write-xml file=output_0.6.osm ___ 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] Status Fahrradwege-Tags
Am 02.03.2011 19:34, schrieb Simon Poole: Es scheint mir wirklich sinnvoller objektiv feststellbare Kriterien zu taggen, um beim Beispiel zu bleiben: maxwidth und mingroundclearance (gibt's nicht, wäre aber denkbar). Da die Bodenfreiheit Abhängig vom Achsabstand unterschiedliche Auswirkungen hat, ist das auch blöd. Wo ein PKW mit 20cm Bodenfreiheit noch ganz gut durchkommt, ist ein LKW mit 20cm Bodenfreiheit wegen Unterfahr-Schutz aufgeschmissen, wenn er bei 8m Achsabstand über die Kuppe fährt. Gruß Peter ___ 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 20:40, schrieb Peter Wendorff: Am 02.03.2011 19:07, schrieb Andreas Perstinger: On 2011-03-02 18:46, Christian Müller wrote: Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Nur zur Info: zumindest Rennräder kennt der Gesetzgeber hier in Österreich. § 4. (1) Als Rennfahrrad gilt ein Fahrrad mit folgenden technischen Merkmalen: 1. Eigengewicht des fahrbereiten Fahrrades höchstens 12 kg; 2. Rennlenker; 3. äußerer Felgendurchmesser mindestens 630 mm und 4. äußere Felgenbreite höchstens 23 mm. (2) Rennfahrräder dürfen ohne die in § 1 Abs. 1 Z 2 bis 8 genannte Ausrüstung in Verkehr gebracht werden; bei Tageslicht und guter Sicht dürfen Rennfahrräder ohne diese Ausrüstung verwendet werden. (BGBl. II, Nr. 146/2001 - Fahrradverordnung) Ist in DE, soweit ich weiß, ähnlich; ich vermute, §1 verweist dabei auf die vorgeschriebene Beleuchtung. Das führt dazu, dass in DE auch nur Rennräder nach der entsprechenden juristischen Definition mit ausschließlich Ansteck-Lampen im Straßenverkehr fahren dürfen. In D ist es ähnlich, aber nicht gleich. Im Verkehrsrecht wird nur unterschieden zwischen Sportgerät (Gewicht 12kg) und dem Rest, wobei aber alle Licht haben müssen, bei den Sportgeräten muss es aber kein von einem Dynamo betriebenes Licht sein. Henning ___ 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 19:35, schrieb Andreas Perstinger: On 2011-03-02 18:27, Christian Müller wrote: Am 02.03.2011 18:16, schrieb Simon Poole: Ein trekking bike ist in etwa so Englisch wie ein handy. Beim Handy gibt es wenigstens eine richtige Übersetzung (mobile phone). Und nochmals: es ist nicht sinnvoll die Eignung für bestimmte Fahrzeugtypen zu taggen, wenn die Fahrzeugtypen selber nicht halbwegs klar definiert sind (wir taggen ja auch nicht typische residentials in Bergdörfern mit lambo=no oder subaru=yes). bitte dann den korrekten namespace verwenden motorcar:lambo=yes motorcar:subaru=no ;-) Dann mach halt einen besseren Vorschlag.. Ich denke, das Grundproblem bei Deinem Vorschlag ist, dass Du das Problem der unzureichenden bzw. lückenhaften Kennzeichnung der Tauglickeit von Wegen mit Fahrradtypen lösen willst, deren Einteilung genauso subjektiv ist, wie smoothness oder tracktype. Dadurch wird mMn die Situation nicht klarer. Eben doch. Natürlich bleibt die Subjektivität, aber mit der Klassenbildung trage ich das (subjektive) Urteil, ob ein Weg benutzbar ist, oder nicht, an die konkreten Nutzer heran. Das habe ich auch schon in anderen mails geschrieben. Das ist ein feiner, wesentlicher Unterschied zu smoothness, wo jeder kommen kann, und einem Wegnutzer (Rennradler, Trekker, MTBler) vorsetzen kann, wofür er den Weg als geeignet erachtet. Und das _ohne_ dass derjenige, der die Daten nutzt, eine Vorstellung davon hat, wie derjenige der smoothness=* erfasst hat, den Weg benutzt hat. Wozu erfassen wir (hauptsächlich) den Oberflächenzustand - um dem Datennutzer eine Entscheidungshilfe zu seiner geplanten Nutzung dieses Weges zu geben. /Wer/, wenn nicht ähnliche Nutzer, kann dem Datennutzer am besten/ehesten mitteilen, ob der Weg für ihn brauchbar ist? smoothness=* ist einfach nicht das gleiche. Der Ansatz der Erfassung für einen Fahrradtyp kommuniziert einem Nutzer gleichen Fahrradtyps wesentlich mehr, als typ-unspezifische tags, weil er i.d.R. davon ausgehen kann/darf, dass sich die gleiche Zielgruppe mit der Erfassung solcher tags beschäftigt. Zieht dazu bitte einfach die Parallele zu den Mountainbikern - die handhaben das schon so. Ein Fußgänger wird kaum für einen MTB-Profi Daten erfassen, weil er _nicht weiß_ inwiefern die Strecke für MTB geeignet ist. Also gibt es den mtb: namespace. Warum dort aufhören und alle anderen Fahrradtypen in einen Topf werfen? Ich finde bei der Erfassung von smoothness ist es fast weniger die Subjektivität, die eine Rolle spielt, als vielmehr noch, dass der Anwender nicht darauf vertrauen kann, dass die Einschätzung des Datenerfassers /für sein Anwendungsgebiet/ eine richtige ist. Das ist, mit der Gewißheit, dass der Erfassende zur gleichen Radlerkategorie wie man selbst gehört, immer noch nicht gegeben, aber die Einschätzung wird _wesentlich_ qualifiziert sein, als eine fachfremde. Es geht mir nicht darum, smoothness zu ersetzen oder zu verbessern - das schrieb ich von Anfang an. Mein Ansatz hat mit smoothness=* eigentlich überhaupt nichts zu tun. Dass einige dass hier so zu einem Brei vermengen, mag daran liegen, dass viele aus dem Oberflächenzustand direkt die Nutzbarkeit für ihren Radtyp ableiten. Das ist nicht falsch, aber mit meinem Vorschlag geht es mir ganz konkret darum, die Verwendbarkeit von Daten dadurch zu erhöhen, dass die Fachleute/Mapper eines Radtyps auf genau die Datennutzer desselben Radtyps treffen. Wenn es um Verwendbarkeit geht, und Verwendbarkeit eine subjektive Sache ist, dann können wir Präzision nur auf die Art und Weise erreichen, dass die Erfasser von Daten der gleichen/ähnlichen Gruppe entspringen, wie die Nutzer der Daten. Dazu müssen die Tags aber kommunizieren, /wer/ erfasst hat, bzw. /wer/ adressiert wird. Das tut smoothness nicht. Es gibt auch nicht die Programmiersprache, sondern viele anwendungsspezifische (DSL) - nicht, weil man keine generelle Sprache hat, die DSL überflüssig machen können, sondern weil DSL dem Problem kurz, bündig und adequat begegnen können. Von der Anwendersicht lässt sich generalisieren, wenn die Kriterien messbar sind und objektiviert werden können, smoothness ist hier bereits ein Grenzfall. Smoothness versucht die Quadratur des Kreises, indem /jeder/ kommen kann und eine passende Verwendbarkeit für /spezifische/ Anwender erfasst. Das funktioniert einfach nicht. Der Kommunikationskanal ist hier gebrochen - smoothness=* ist, kommunikationstechnisch betrachtet ein Broadcast ohne Absenderadresse. Bei der ganzen konservativen Denke, frage ich mich, wie es die MTBler geschafft haben, eine ganze Reihe von Änderungen beizusteuern. Vermutlich haben die ohne viel fuzz gleich Tatsachen geschaffen :) Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 21:26 schrieb Christian Müller cmu...@gmx.de: Ein Fußgänger wird kaum für einen MTB-Profi Daten erfassen, weil er _nicht weiß_ inwiefern die Strecke für MTB geeignet ist. Also gibt es den mtb: namespace. Warum dort aufhören und alle anderen Fahrradtypen in einen Topf werfen? mtb, wenn auch aus ähnlichen Gründen wie Dein Vorschlag schon des öfteren kritisiert, macht wenigstens nicht den Fehler, sowas wie mtb=yes/no einzuführen. Der mtb-namespace ist klar getrennt vom rechtlichen Aspekt des Verbots für bestimmte Fahrzeugtypen und lädt nicht zu Verwechslungen ein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Ohne Zweifel wahr (Verschränkung müsste man ja auch noch beachten) perfekt wäre auch das nicht. Trotzdem besser als irgendwelche Fahrzeugkategorieren, die doch nicht passen (immerhin wäre der LKW-Fahrer vorgewarnt, dass es Probleme geben könnte). Simon - Original Message - From: Peter Wendorff wendo...@uni-paderborn.de To: talk-de@openstreetmap.org Sent: Wednesday, March 02, 2011 9:25 PM Subject: Re: [Talk-de] Status Fahrradwege-Tags Am 02.03.2011 19:34, schrieb Simon Poole: Es scheint mir wirklich sinnvoller objektiv feststellbare Kriterien zu taggen, um beim Beispiel zu bleiben: maxwidth und mingroundclearance (gibt's nicht, wäre aber denkbar). Da die Bodenfreiheit Abhängig vom Achsabstand unterschiedliche Auswirkungen hat, ist das auch blöd. Wo ein PKW mit 20cm Bodenfreiheit noch ganz gut durchkommt, ist ein LKW mit 20cm Bodenfreiheit wegen Unterfahr-Schutz aufgeschmissen, wenn er bei 8m Achsabstand über die Kuppe fährt. Gruß Peter ___ 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] Status Fahrradwege-Tags
Am 02.03.2011 20:55, schrieb Peter Wendorff: Am 02.03.2011 16:32, schrieb Christian Müller: Am 02.03.2011 08:39, schrieb Heiko Jacobs: 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 ... Da steckt sehr viel Wahrheit drin. Da OSM aber das aktuelle Weltbild wiederspiegelt, ist das dann eben auch dynamisch - es gilt den aktuellen Zustand zu erfassen und der kann sich natürlich ändern. Die OSM-Daten haben kein absolutes Ziel, sie werden sich immer wandeln (müssen), so wie die Karten von traditionellen Herstellern auch. !? Ja, aber doch nicht im jahreszeitlichen Wandel! Wenn jemand große Ereignisse, langfristige Baustellen etc. einträgt und die hinterher wieder entfernt - okay. Aber hiermit forderst du explizit, dass das komplette Wegenetz auf Verdacht mindestens viermal im Jahr gesichtet werden muss - das halte ich für Blödsinn. Wenn die Holzabfuhr (das war das Beispiel auf das ich geantwortet hatte) einmal durch ist und das Wegenetz zerstört UND hinterher nichts daran gemacht wird, ist kaum anzunehmen, dass es durch den jahreszeitlichen Wechsel wieder besser wird. Für Wege, die regelmäßig überflutet werden, gibt es andere Sachen, wie flood_prone=* - das wäre auch für andere reale Änderungen, die an Jahreszeiten gebunden sind, denkbar. Davon sprach ich aber nicht, sondern von längerfristigen Änderungen, z.B. ein Weg ist drei Jahre durch Rennradler befahrbar, weitere 4 durch Trekking, irgendwann ist die Qualität hin und die bumpiness so groß, dass sich die Mehrheit der Trekking-Radler das nicht mehr antut. Ergo wieder umtaggen zu MTB. Alles unter der Vorraussetzung, dass in der Zeit nichts am Weg gemacht wurde. Diese Änderungen gilt es zu erfassen - ergo ist nichts in OSM wirklich final (bis vielleicht auf die place-tags).. Selbst die coast_line ändert sich, aber das trägt nicht mehr zum Thema bei.. Ein anderer Aspekt ist - jemand der bei feuchtem Wetter Wege erfasst wird tendentiell den Weg eher abwerten, obwohl er ihn bei Trockenheit vielleicht besser bewertet hätte. Da haben wir auch schon wieder (jahreszeitlich gebundene) Subjektivität. Deshalb ist in einem solchen Fall surface=* objektiver (Mud/Dirt), als smoothness=* (das sich evtl. stark nach der Bodenfeuchte richtet) oder tracktype=* - das schrieb auch Heiko schon. Jahreszeitliche Änderungen lassen sich schwerlich aufnehmen, sicher, da sind andere Sachen an/in OSM wichtiger. Eine Karte in Abhängigkeit des aktuellen Wetters zu rendern und dann bei Regen tracktype und smoothness automatisch abzuwerten wäre aber aus momentaner Sicher nur ein Ressourcenproblem. Natürlich könnte der Radler das Wetter auch selbst in Betracht ziehen, so wie der Klimaforscher seine Berechnungen auch von Hand rechnen lassen könnte :-) Gruß ___ 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 21:39, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 21:26 schrieb Christian Müllercmu...@gmx.de: Ein Fußgänger wird kaum für einen MTB-Profi Daten erfassen, weil er _nicht weiß_ inwiefern die Strecke für MTB geeignet ist. Also gibt es den mtb: namespace. Warum dort aufhören und alle anderen Fahrradtypen in einen Topf werfen? mtb, wenn auch aus ähnlichen Gründen wie Dein Vorschlag schon des öfteren kritisiert, macht wenigstens nicht den Fehler, sowas wie mtb=yes/no einzuführen. Der mtb-namespace ist klar getrennt vom rechtlichen Aspekt des Verbots für bestimmte Fahrzeugtypen und lädt nicht zu Verwechslungen ein. So wie das Fehlen des access: präfix an allen sonstigen, für rechtliche Aspekte verwendeten Tags zum Fehler begehen einlädt, meinst Du? Haare spalten kann ich auch.. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
On 2011-03-02 20:36, Christian Müller wrote: Am 02.03.2011 19:07, schrieb Andreas Perstinger: On 2011-03-02 18:46, Christian Müller wrote: Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Nur zur Info: zumindest Rennräder kennt der Gesetzgeber hier in Österreich. § 4. (1) Als Rennfahrrad gilt ein Fahrrad mit folgenden technischen Merkmalen: 1. Eigengewicht des fahrbereiten Fahrrades höchstens 12 kg; 2. Rennlenker; 3. äußerer Felgendurchmesser mindestens 630 mm und 4. äußere Felgenbreite höchstens 23 mm. (2) Rennfahrräder dürfen ohne die in § 1 Abs. 1 Z 2 bis 8 genannte Ausrüstung in Verkehr gebracht werden; bei Tageslicht und guter Sicht dürfen Rennfahrräder ohne diese Ausrüstung verwendet werden. (BGBl. II, Nr. 146/2001 - Fahrradverordnung) Rein interessehalber: Gibt es auch rennradbezogene Ge- und Verbote, was die Wegnutzung betrifft? z.B. Wege, auf denen ein Fahrradverbot besteht, Rennräder aber ausnahmsweise erlaubt sind? In diesem Fall müßte ich mein Implikationsschema überdenken. Im Rahmen einer Trainingsfahrt (dieser Begriff ist nicht wirklich definiert, gilt auch für den oben genannten Rennlenker) ist die Radwegbenutzungspflicht aufgehoben, d.h. mit dem Rennrad fahre ich auf der Strasse und nicht am danebenführenden Radweg. Tschau, Andreas ___ 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 21:39, schrieb M∡rtin Koppenhoefer: Der mtb-namespace ist klar getrennt vom rechtlichen Aspekt des Verbots für bestimmte Fahrzeugtypen und lädt nicht zu Verwechslungen ein. Vielleicht sollte man generell von bicycle=yes Abstand nehmen, wenn man bicycle=permitted meint.. Wieder so ein Stückchen OSM, wo ohne Wiki gar nichts geht? Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
On 2011-03-02 21:27, Henning Scholland wrote: Am 02.03.2011 20:40, schrieb Peter Wendorff: Am 02.03.2011 19:07, schrieb Andreas Perstinger: On 2011-03-02 18:46, Christian Müller wrote: Falls access=* ausschließlich rechtliche Ge- und Verbote wiederspiegelt, dann macht es keinen Sinn bicycle=* Werte wiederzuverwenden, schon aus dem Grund, dass der Gesetzgeber nur das Fahrrad kennt, nicht seine Klassen (ich hoffe, ich irre mich da jetzt nicht). Nur zur Info: zumindest Rennräder kennt der Gesetzgeber hier in Österreich. § 4. (1) Als Rennfahrrad gilt ein Fahrrad mit folgenden technischen Merkmalen: 1. Eigengewicht des fahrbereiten Fahrrades höchstens 12 kg; 2. Rennlenker; 3. äußerer Felgendurchmesser mindestens 630 mm und 4. äußere Felgenbreite höchstens 23 mm. (2) Rennfahrräder dürfen ohne die in § 1 Abs. 1 Z 2 bis 8 genannte Ausrüstung in Verkehr gebracht werden; bei Tageslicht und guter Sicht dürfen Rennfahrräder ohne diese Ausrüstung verwendet werden. (BGBl. II, Nr. 146/2001 - Fahrradverordnung) Ist in DE, soweit ich weiß, ähnlich; ich vermute, §1 verweist dabei auf die vorgeschriebene Beleuchtung. Ja, unter anderem (zusätzlich sind Klingel, Rückstrahler vorne/hinten/an den Pedalen/an den Reifen notwendig). Das führt dazu, dass in DE auch nur Rennräder nach der entsprechenden juristischen Definition mit ausschließlich Ansteck-Lampen im Straßenverkehr fahren dürfen. In D ist es ähnlich, aber nicht gleich. Im Verkehrsrecht wird nur unterschieden zwischen Sportgerät (Gewicht 12kg) und dem Rest, wobei aber alle Licht haben müssen, bei den Sportgeräten muss es aber kein von einem Dynamo betriebenes Licht sein. Gilt das nur für Nachtfahrten, oder müssen in D Rennräder auch am Tag ein Licht mitführen? In AT braucht man das eben nicht AFAIK (ich bin zumindest noch nie deswegen angehalten worden). Tschau, Andreas ___ 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 18:27, schrieb Christian Müller: Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse ist. Und ein Engländer kennt doch sehr wohl auch den Unterschied zwischen Rennrad und Mountainbike. Wenn ihm die Kategorie Trekking nicht bewußt ist, ist das nur ein Zeichen, das hier das marketing versagt hat, oder andere Wege gegangen ist.. Noch den obligaten Wikipedia Link zum Thema: http://en.wikipedia.org/wiki/Mixed_Terrain_Cycle-Touring Simon ___ 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 22:15, schrieb Andreas Perstinger: Gilt das nur für Nachtfahrten, oder müssen in D Rennräder auch am Tag ein Licht mitführen? In AT braucht man das eben nicht AFAIK (ich bin zumindest noch nie deswegen angehalten worden). Laut http://www.polizei.bremen.de/sixcms/detail.php?gsid=bremen09.c.3499.de schon. (siehe ganz unten auf der Seite) Gruß Christian ___ 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 22:15, schrieb Andreas Perstinger: Gilt das nur für Nachtfahrten, oder müssen in D Rennräder auch am Tag ein Licht mitführen? In AT braucht man das eben nicht AFAIK (ich bin zumindest noch nie deswegen angehalten worden). In D müssen Fahrräder immer ein, von einem Dynamo angetriebenes, Licht mitführen. Ausnahme wie gesagt die Sportgeräte, die ihr Licht auch immer mitführen müssten. Geschlossene Veranstaltungen sind aber komplett ausgenommen. Zur täglichen Praxis und der Durchsetzung des Gesetzestextes sag ich aber nichts ;) Henning ___ 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 22:31, schrieb Simon Poole: Am 02.03.2011 18:27, schrieb Christian Müller: Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse ist. Und ein Engländer kennt doch sehr wohl auch den Unterschied zwischen Rennrad und Mountainbike. Wenn ihm die Kategorie Trekking nicht bewußt ist, ist das nur ein Zeichen, das hier das marketing versagt hat, oder andere Wege gegangen ist.. Noch den obligaten Wikipedia Link zum Thema: http://en.wikipedia.org/wiki/Mixed_Terrain_Cycle-Touring Genial, danke. Die Types of dort sind ja schonmal ein prima Wertebereich, da bräuchten wir nur noch nen passenden Schlüssel - die smoothness-Leute werden ihren ja sicher nicht hergeben :-) .. Vielleicht kann man die smoothness-Beschreibung wenigstens in den Wertebeschreibungen um die Typen ergänzen, gerade für die engl. smoothness-Version bestimmt nicht uninteressant. Christian ___ 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 17:19, schrieb Frederik Ramm: Hallo, On 03/02/2011 12:45 PM, M?rtin Koppenhoefer wrote: bad ist genau definiert. Das bedeutet, dass man stabile Räder benötigt, und mit Trekking-Rädern und Autos noch den Weg benutzen kann (robust_wheels) trekking bike, normal cars, Rickshaw and all below . bad ist ein ganz normales Wort des alltaeglichen Sprachgebrauchs und bedeutet schlecht. Instinktiv werden Leute es also bei einer schlechten Oberflaechenbeschaffenheit verwenden, und die Definition kannst Du in der Pfeife rauchen. S schlecht hat es die Sache in vielen Fällen dann auch wieder nicht getroffen. Jetzt tu halt nicht so, als ob wir an anderen Stellen nicht ähnliche Probleme hätten. Die Unterscheidung von landuse=forest vs. natural=wood ist bei OSM auch nicht unbedingt intuitiv. Das Schema schlechtzureden bringt nichts. Schlechtreden kann man nur etwas, was an sich gut ist. Ich finde das Schema schlecht. Meine Alternative ist, das Mapping von Oberflaechenqualitaeten abseits von tracktype und surface sein zu lassen. Das ist dein gutes Recht. Solang Leute das fuer sich selber als Hobby benutzen, mir egal, aber in dem Moment, wo jemand ankommen sollte und sowas sagen wie zu einer guten Erfassung von Wegen gehoert auch smoothness, werde ich dem widersprechen. Schön für dich, so hat halt jeder seine Meinung :-) Nein, das stimmt so nicht. Tracktype ging nie um die Art von Fahrzeugen, die den Weg benutzen können, sondern um den Ausbaugrad, Das ist genau die Haarspalterei, die uns nicht weiterbringt. Erst kuerzlich sagte ein Fahrradfahrer zu mir: Mit der OpenCycleMap kann ich nichts anfagen, weil sie nicht nach tracktype unterscheidet. Mal Beispiele aus der Praxis des Motorradfahrers: Auf einem Weg mit grade1 kann ich normalerweise prima fahren, auf einem grade5 werde ich mir wahrscheinlich nach kurzer Zeit das Lenkkopflager ruinieren. Beides ein highway=track. Z.B. in Tschechien (beim Erzgebirge) gibt es einiges an Straßen, die eigentlich vom Ausbau track1 bzw. sogar unclassified sind, aber vom Zustand des Belags streckenweise so übel das man da freiwillig nicht drüber möchte. Hier hat smoothness sehr wohl seinen Sinn. Ich sehe daher sowohl Sinn für tracktype als auch für smoothness - aus ganz praktischen Erfahrungen. Ob man bei smoothness bessere (intuitivere) Values verwenden könnte, ist eine andere Frage. Gruß, ULFL P.S: Und wenn das hier in D mit den Schlaglöchern so weitergeht, werden wir bald auch eine großflächige Verwendung von smoothness brauchen :-( ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Hallo Ulf, On 03/02/11 22:59, Ulf Lamping wrote: Z.B. in Tschechien (beim Erzgebirge) gibt es einiges an Straßen, die eigentlich vom Ausbau track1 bzw. sogar unclassified sind, aber vom Zustand des Belags streckenweise so übel das man da freiwillig nicht drüber möchte. Hier hat smoothness sehr wohl seinen Sinn. Aber das ist doch genau die Haarspalterei, von der ich spreche. Wozu erfasse ich denn tracktype=grade1? Doch nicht, damit ein Akademiker Statistiken machen kann, wie viele Wege jetzt asphalt or heavily compacted hardcore sind (heisst das, man kann darauf gut fahren? - nein, das heisst nur, dass man darauf in einer idealen verschleissfreien Welt gut fahren koennte...). Mich interessiert das herzlich wenig, was ein Weg eigentlich vom Ausbau her waere - ein asphaltierter Weg, dessen Asphalt alle 20cm von einer Baumwurzel durchbrochen wird, kriegt bei mir ganz gewiss keinen tracktype=1. Ich sehe daher sowohl Sinn für tracktype als auch für smoothness - aus ganz praktischen Erfahrungen. Ob man bei smoothness bessere (intuitivere) Values verwenden könnte, ist eine andere Frage. Und ich finde, dass die Unterscheidung keinen Sinn hat. tracktype=1/smoothness=very horrible? tracktype=5/smoothness=excellent? Und als naechstes erzaehlst Du mir, wir muessen smoothness auch bei Autobahnen einfuehren, weil z.B. in Tschetschenien auch mal eine Autobahn sonst Dein Lenkkopflager ruiniert. Meine Meinung ist, *wenn* wir schon nicht echte physische Details erfassen, dann reicht *ein* interpretierter Tag, aus dem man die Qualitaet des Weges ablesen kann. Ich benutze dafuer (etwas widerstrebend) tracktype. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Ich wollte ja eigentlich noch was dazu schreiben, hab es aber dann sein gelassen, jetzt aber trotzdem noch: Eins der Probleme an deinem Vorschlag ist das du die Art des Fahrradfahrens krampfhaft versuchst am Fahrzeugtyp festzumachen (was bei Fahrrädern nicht wirklich gut geht). Schlussendlich willst du aber ja eigentlich wissen: kann ich da ein Zeitfahren machen, oder kann ich die Strecke über wechselnde Unterlage ohne grosse technische Hindernisse (im MTB Sinne) gemütlich abfahren usw. So was kann man vermutlich nicht wirklich vernünftig an einzeln Wegen taggen, aber bei Radrouten wäre das sicher möglich (und wird ja mindestens für MTB ja auch gemacht) , vielleicht ist da ein Ansatz um dein Anliegen weiter zu bringen. Simon Am 02.03.2011 22:45, schrieb Christian Müller: Am 02.03.2011 22:31, schrieb Simon Poole: Am 02.03.2011 18:27, schrieb Christian Müller: Weiterhin musst Du wohl feststellen, auch wenn Du dich gerade an trekking aufhängst, dass das keine Fahrradmarke, sondern -klasse ist. Und ein Engländer kennt doch sehr wohl auch den Unterschied zwischen Rennrad und Mountainbike. Wenn ihm die Kategorie Trekking nicht bewußt ist, ist das nur ein Zeichen, das hier das marketing versagt hat, oder andere Wege gegangen ist.. Noch den obligaten Wikipedia Link zum Thema: http://en.wikipedia.org/wiki/Mixed_Terrain_Cycle-Touring Genial, danke. Die Types of dort sind ja schonmal ein prima Wertebereich, da bräuchten wir nur noch nen passenden Schlüssel - die smoothness-Leute werden ihren ja sicher nicht hergeben :-) .. Vielleicht kann man die smoothness-Beschreibung wenigstens in den Wertebeschreibungen um die Typen ergänzen, gerade für die engl. smoothness-Version bestimmt nicht uninteressant. Christian ___ 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] Status Fahrradwege-Tags
Am 02.03.2011 16:13, schrieb Joerg Fischer: Der extrem seltene Ausnahmefall Ja aber da liegt heute Schnee und jetzt darf ich _doch_ ist für die Praxis und das Routing nicht relevant. Es geht hier nicht um schlechtes Wetter, sondern u.a. um die Randziffer 23 in http://bernd.sluka.de/Recht/StVO-VwV/VwV_zu_2.txt bzgl. mehrspurigen Rädern/Anhängern etc. In .de gummimäßig formuliert,ist man in .at restriktiver und untersagt ab einer gewissen Hängerbreite das Fahren auf Radwegen. Gruß Mueck ___ 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 17:37, schrieb Christian Müller: Am 02.03.2011 16:41, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 16:29 schrieb Christian Müllercmu...@gmx.de: 1) es geht nicht um 10 tags, sondern um 3 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen es geht um 3 zusätzliche tags allein für Radfahrer. Danach kommen die Rollstuhlfahrer mit 3 Typen, die Inlineskater mit 2 Typen, 4 Typen Kinderwägen, Tretroller, Einkaufswägen, Stelzen, verschiedene Arten von Schuhen, etc. Der Ansatz skaliert einfach ziemlich schlecht. Evtl., der bisherige aber auch: foot motorcar motorcycle motor_vehicle bicycle wheelchair psv hgv Beim diesem Ansatz geht es um die rechtliche Einsortierung, diese ist (größtenteils) jeweils unabhängig von den anderen Verkehrsteilnehmern. Wenn es irgendwo ein Verbot für Motorräder gibt, hat das keine Auswirkungen für die anderen. Es muß daher für jede Verkehrsart ein unabhängiger Eintrag vorhanden sein, weil man sonst die Kombinatorik nicht hinbekommt. Bei smoothness (oder ähnlichem) ist das aus meiner Sicht anders. Hier haben wir (in erster Näherung) einen linearen Übergang von gut nach schlecht, die bei einem bestimmten Wert Auswirkungen für alle Teilnehmer hat. Wenn die Inliner kommen, sollen sie ihre Tags haben, genauso wie die anderen Leute. We can't have it, because it does not fit the spec. hatten wir schon vor OSM.. Es wird dich wahrscheinlich keiner davon abhalten sowas entsprechend deines Vorschlags zu taggen. Aus den (für diese Liste sehr eindeutigen) Reaktionen hier ist für mich aber rausgekommen, das es kaum ein anderer wirklich gut findet. Wäre es da nicht vielleicht besser, das (bislang etwas brachliegende) Thema smoothness zu forcieren und zu schauen wie weit wir damit kommen? Wenn ich dich recht verstehe, willst du wissen ob du bzw. ob du zur Not mit einem Trekkingrad über einen Weg kommst. Das sollte mit smoothness doch machbar sein ... 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 17:10, schrieb M∡rtin Koppenhoefer: Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. da drückt man ein Auge zu, ganz korrekt im Sinne des Schemas ist das auch nicht. Es mus ja nicht ins Schema pasen, denn wheelchair ist kein access-tag wie bicycle, denn Rollis DÜRFEN überall dort hin, wo auch Fußgänger hindürfen (Turborollis mit 6 km/h oder so lasse ich mal außen vor) sondern ein Eignungs-Tag, ob man dort, wo man hin DARF, auch hin KANN. Deswegen auch die Werte yes/no/limited statt destination Co. Gruß Mueck ___ 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 13:11, schrieb M∡rtin Koppenhoefer: ja, Übersetzungsfehler bzw. Auslassung im Deutschen: grade1 schließt Wege mit ein, die zwar nicht asphaltiert sind, die aber eine Oberflächenstruktur haben, die dem faktisch gleichkommt (extrem verdichtet). Was den für's Radfahren nicht unwichtigen Rollwiderstand betrifft und die jahreszeitliche Konstanz der Benutzbarkeit kommt eine wassergebundene Decke, auch wenn sie nagelneu noch perfekt ist, eben nicht einer asphaltierten/betonierten Decke gleichwertig. Ich möchte daher keine wassergebundenen Decken in grade1 finden, auch wenn ich nicht mit Rennrad unterwegs bin ... Gruß Mueck ___ 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 18:13, schrieb Christian Müller: Und was macht man z.B. mit Holz? Ich würde schon sagen, dass manche hölzerne Wege als befestigt gelten können (Hausbrücken z.B.), andere, wo nur ein paar logs verstreut im Sumpf liegen, eher nicht. surface=* ist auch nicht perfekt, aber es ist _wesentlich_ besser zu handhaben und brauchbarer, auch was die unmittelbare Lesbarkeit des tags betrifft, als tracktype/smoothness.. surface=asphalt ohne smoothness hilft Dir aber auch nix. Ich habe auch schon surface=asphalt in smoothness=intermediate oder in wenigen Fällen m.E.n. gar in bad eingestuft. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 2. März 2011 23:28 schrieb Frederik Ramm frede...@remote.org: Meine Meinung ist, *wenn* wir schon nicht echte physische Details erfassen, dann reicht *ein* interpretierter Tag, aus dem man die Qualitaet des Weges ablesen kann. Ich benutze dafuer (etwas widerstrebend) tracktype. benutzst Du das auch für footways und path? Für tracks braucht man kein smoothness, aber tracktypes an footways habe ich fast nie gesehen. Physische Details nicht zu erfassen muss ja nicht zum Dogma werden. Welche echten Details schlägst Du vor? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Moin, Am 02.03.2011 23:35, schrieb Simon Poole: Ich wollte ja eigentlich noch was dazu schreiben, hab es aber dann sein gelassen, jetzt aber trotzdem noch: Eins der Probleme an deinem Vorschlag ist das du die Art des Fahrradfahrens krampfhaft versuchst am Fahrzeugtyp festzumachen (was bei Fahrrädern nicht wirklich gut geht). Schlussendlich willst du aber ja eigentlich wissen: kann ich da ein Zeitfahren machen, oder kann ich die Strecke über wechselnde Unterlage ohne grosse technische Hindernisse (im MTB Sinne) gemütlich abfahren usw. Da steige ich nicht dahinter - das geht doch hervorragend. Die Fahrradtypen werden ja auch genau terrainspezifisch vermarktet: mtb - rough ride trekking - long ride road_bike - fast ride Wer denkt bitte beim Zeitfahren an ein Trekking- oder MTB-Rad? Anhand der Implikationsvorschläge war auch zu erkennen, inwiefern ich mir über Überschneidungen Gedanken gemacht habe. Natürlich kann ich mit einem MTB auch auf Straßen und Tracks fahren - dafür kauft man sich i.d.R. aber kein MTB. Wir benutzen diese etablierten Marketingbegriffe doch nur, weil i.A. jeder weiß, was unter einem mtb/trekking/race bike zu verstehen ist und eben gerade deren Hauptanwendungsgebiete kennt und einordnen kann. Insofern gebe ich den Esel zurück und frage, warum Du das krampfhaft auseinanderdividieren willst? =) So was kann man vermutlich nicht wirklich vernünftig an einzeln Wegen taggen, aber bei Radrouten wäre das sicher möglich (und wird ja mindestens für MTB ja auch gemacht) , vielleicht ist da ein Ansatz um dein Anliegen weiter zu bringen. Das wollte ich gerade nicht - siehe erste mail. Das wäre auch völlig fatal: Def. Radroute - Menge von Wegabschnitten, deren Beschaffenheit und Oberfläche völlig unterschiedlich sein kann. Ich kann mit einem tagging der Route dann überhaupt keine Rückschlüsse auf die Befahrbarkeit ihrer Segmente ziehen. Klar kann ich sagen, eine Route wurde speziell für Trekking-Räder zusammengestellt. Das hat dann aber rein empfehlenden Charakter und lässt sich z.B. bei Routing-Software auch schwerlich verwenden. Siehe erste mail: mir geht es um den Weg, nicht um Routen, und das aus gutem Grund. Ausnahme evtl. knotenbasiertes, niederländisches cycle-network.. Was man noch machen könnte, ist, Relationen zu benutzen um die Nutzung/Verwendbarkeit von Teilsegmenten darüber zu taggen, also z.B. eine Relation trekking-geeignet und da dann alle Segmente rein. Dann könnte ich aber auch die Zugangsbeschränkungen komplett über Relationen lösen (Relation bicycle=yes und dort entsprechend alle Ways rein, die jetzt direkt dieses Tag tragen). Problem wäre dann auch, dass solche Relationen sich einer bounding-box Abfrage widersetzen. Angenommen ich will dann z.B. die treking-geeignet-Liste für Leipzig, ziehe ich mir eine Riesenrelation, in der ein Haufen Wege sind, die mich nicht interessieren und aufgrund derer ich dann vorfiltern müsste. Das kann es dann auch nicht sein - Parent-Childrelationen zu nutzen würde _hier_ die Komplexität noch weiter aufblähen. M.E. gehört die Eignung -subjektiv oder nicht- daher an den Way und nicht in eine Relation. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags / Tag-Voting für subjektive Kriterien
Am 02.03.2011 23:55, schrieb Ulf Lamping: Am 02.03.2011 17:37, schrieb Christian Müller: Am 02.03.2011 16:41, schrieb M∡rtin Koppenhoefer: Am 2. März 2011 16:29 schrieb Christian Müllercmu...@gmx.de: 1) es geht nicht um 10 tags, sondern um 3 3) hättest Du dich vernünftig mit meinem Vorschlag auseinandergesetzt, würdest Du feststellen, dass durch die Implikationen tatsächlich sehr wenig zusätzlicher tagging-Aufwand zustande kommt. es geht um kleine, aber entscheidende Verbesserungen es geht um 3 zusätzliche tags allein für Radfahrer. Danach kommen die Rollstuhlfahrer mit 3 Typen, die Inlineskater mit 2 Typen, 4 Typen Kinderwägen, Tretroller, Einkaufswägen, Stelzen, verschiedene Arten von Schuhen, etc. Der Ansatz skaliert einfach ziemlich schlecht. Evtl., der bisherige aber auch: foot motorcar motorcycle motor_vehicle bicycle wheelchair psv hgv Beim diesem Ansatz geht es um die rechtliche Einsortierung, diese ist (größtenteils) jeweils unabhängig von den anderen Verkehrsteilnehmern. Wenn es irgendwo ein Verbot für Motorräder gibt, hat das keine Auswirkungen für die anderen. Es muß daher für jede Verkehrsart ein unabhängiger Eintrag vorhanden sein, weil man sonst die Kombinatorik nicht hinbekommt. Ja, ist mir doch alles klar - dennoch bläht allein diese Zahl der Attribute das tagging eines Weges schon auf, dass das Argument wir können hier nicht noch mehr gebrauchen einfach nicht zieht. Zumal alle o.g. zusätzlich alles andere als Neuling-freundlich sind, aber ich wiederhole mich: - kein access: präfix - hgv / psv nicht ausgeschrieben (entgegen der OSM Konvention) - Verwendung nicht selbstdokumentierend (an unterschiedlichen Stellen im Wiki findet man evtl. sogar unterschiedliche Erklärungen..) Bei smoothness (oder ähnlichem) ist das aus meiner Sicht anders. Hier haben wir (in erster Näherung) einen linearen Übergang von gut nach schlecht, die bei einem bestimmten Wert Auswirkungen für alle Teilnehmer hat. Ja, auch das habe ich nie in Frage gestellt. Ich will auch nicht in Konkurrenz zu smoothness treten, hm, sagte ich das schon? Wäre es da nicht vielleicht besser, das (bislang etwas brachliegende) Thema smoothness zu forcieren und zu schauen wie weit wir damit kommen? Erachte ich als sinnlos - all die Jünger, die jetzt nach langer Diskussion mit ihrem gefundenen Kompromiss damit glücklich sind, werde ich nicht überzeugen können. smoothness=* ist eine Religion. Das merke ich schon an den ganzen Antworten und dem ständigen flachgebügele meines Vorschlags mit dieser streitbaren Definition. Wenn ich dich recht verstehe, willst du wissen ob du bzw. ob du zur Not mit einem Trekkingrad über einen Weg kommst. Das sollte mit smoothness doch machbar sein ... Nein das ist es nicht, zumindest nicht ganz. Was ich will, habe ich in epischer Breite in der ersten Mail zum Thema erklärt und, vielleicht wichtiger, hier: http://www.mail-archive.com/talk-de@openstreetmap.org/msg82510.html Es geht mir darum, tags zu schaffen, die END-to-END kommunizieren, ob ein Weg für meine Nutzungsart etwas taugt, oder nicht. Wenn schon subjektiv, dann gleich fachspezifisch. Aber bitte lies die mail, ich habe mir Mühe gegeben, dass so detailiert darzulegen, wie möglich. Natürlich haben all die Leute recht, dass auch ein Trekking-Radler nicht die gleichen Präferenzen hat, wie der nächste. Aber das Urteil dürfe näher an dem dran sein, was ich haben will, als wenn es von einem Rennradler (da würde ich nie im Leben lang fahren und kann mir auch nicht vorstellen, dass andere Radler das tun) oder MTBler kommt - die wissen eben in ihrem Feld Bescheid. Wenn man sich die Menge der Trekker z.B. mal vor Augen hält, sieht das vielleicht so aus: Hardcore-Trekker (fast MTBler) .. Normalo-Trekker .. Sonnenschein-Trekker (fährt nur asphaltierte Wege) Die Normalo-Trekker, die Waldwege mit in Betracht ziehen, wenn sie nicht zu stark verwurzelt sind, bilden am ehesten (da mittig) das ab, was dann zu taggen wäre. Natürlich kann ich nicht ausschließen, dass der Fast-MTB-Typ kommt und mir meinem Verständnis der Kategorie entgegentritt. Das Problem habe ich aber mit allen Tags, wo nur ein mü Interpretationsspielraum für den Wert besteht. Mir ist noch ein anderer Gedanke gekommen, mit dem ich für die geplanten Kategoriebegriffe Quasi-Objektivität (im Sinne einer Mittelwertsbildung) aus der Subjektivität der Taggenden extrahieren könnte. Das wird umso besser, je mehr Leute ihren Senf zur Klassifikation eines Ways hinzugeben. Ich nenne das Verfahren mal tag-voting. Idee ist folgende (bitte haltet euch nicht wieder an den konkreten Namen auf, sondern am Konzept, über die konkreten Bezeichnungen lässt sich am Ende reden): trekking:thumbs_up erfasst alle yes-votes der Trekker (=Leute, die sich kompetent fühlen zum Thema trekking-Befahrbarkeit eines Ways eine Aussage zu treffen) trekking:thumbs_down erfasst alle no-votes dieser Trekker Angenommen /ich/ befinde einen Weg als
Re: [Talk-de] Status Fahrradwege-Tags
Am 03.03.2011 00:31, schrieb Heiko Jacobs: Am 02.03.2011 18:13, schrieb Christian Müller: Und was macht man z.B. mit Holz? Ich würde schon sagen, dass manche hölzerne Wege als befestigt gelten können (Hausbrücken z.B.), andere, wo nur ein paar logs verstreut im Sumpf liegen, eher nicht. surface=* ist auch nicht perfekt, aber es ist _wesentlich_ besser zu handhaben und brauchbarer, auch was die unmittelbare Lesbarkeit des tags betrifft, als tracktype/smoothness.. surface=asphalt ohne smoothness hilft Dir aber auch nix. Ich habe auch schon surface=asphalt in smoothness=intermediate oder in wenigen Fällen m.E.n. gar in bad eingestuft. Ja, kenne ich, solche Fälle gibt es hier in der Gegend auch en masse. Zwischen smoothness=intermediate smoothness=bad smoothness=horrible mag ich aber nicht entscheiden. Sicher kann ich für den gemeinen Trekking-Freund eine passende Klassifizierung finden, dann lyncht mich aber der Inliner, der sich auf meine smoothness=good Klassifikation verlassen hat (die inkompetent war, da ich eben nicht skate). smoothness ist für all seine Anwender/Nutzer nicht nur schwammig, sondern auch zu allgemein - meine Meinung :) Eine grobe Peilung kann es liefern, aber mir ging es in diesem Thread NIE, auch wenn ich mich wiederhole, um die Sinnhaftigkeit oder Abschaffung dieses einen Tags. Gruß, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ID 24502104
Hallo, irgendwas scheint bei dem edit am 24 Feb 10:23 von Geisbock1212 mit dem Wald (ID 24502104) schief gegangen zu sein, da er aktuell nicht mehr gerendert wird (nur noch auf niedrigen Zoomstufen mit mapnik zu finden). Osmarenderer hat auch schon weisse Flecken. Allerdings sehe ich den Fehler nicht wenn denn einer da ist (Evtl. Relation?). Da der edit schon länger zurück liegt wundert mich das die Darstellung nicht passt wenn keine Fehler vorh. sein sollten. Changeset ist: http://www.openstreetmap.org/browse/changeset/7386064 Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Nutzung von Ortskoordinaten
Hi ! es gibt doch da so freie Adress-Projekte wie Geonames etc. - dürfte man von denen die Ortskoordinaten ziehen um z.b. im Ausland fehlende Orte und Namen nachtragen zu dürfen ?? Hat einer dafür vielleicht schon Skripte rumliegen? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung von Ortskoordinaten
Hallo! Natürlich wäre das möglich, auch von der Lizenz her, jedoch stammen die Daten von GeoNames.org aus Quellen mit unterschiedlicher Datenqualität. Ein automatischer Abgleich fände ich persönlich daher gefährlich. Des Weiteren ist eine Datenquelle von GeoNames.org OpenStreetMap. Ich könnte mir vorstellen, dass das nicht zu gewünschten Ergebnissen führt. Gruß, Philip -- View this message in context: http://gis.638310.n2.nabble.com/Nutzung-von-Ortskoordinaten-tp6083938p6083947.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suchbare Liste aller bekannten OSM-Objekte
Danke vielmals für eure zahlreichen Antworten. Der Verweis auf Editoren ist interessant. Doch löst das nicht das oben beschriebene Bedürfnis, mal schnell nach einem OSM Objekt suchen zu können, z.B. um Analyse-Queries zu schreiben oder Styles eigener Karten zu konfigurieren. Der Hinweis scheint mir aber interessant, weil Editoren ein ähnliches Problem lösen müssen. In JOSM ist das wie beschrieben mit Vorlage suchen/F3 (Presets) gelöst. Ich stellte mir eher so etwas wie die Custom Google Suche vor, die ich nicht kannte: http://www.google.com/cse/home?cx=015487330990472192076:qvmeg3q9qus Ev. geht es aber noch besser. Wenn ich so rumstöbere, dann sieht man, dass Howto_map_A schon noch gerne verwendet wird: Siehe z.B. http://josm.openstreetmap.de/wiki/De%3APresets . Eine bereinigte Wiki-Seite DE:Howto_Map_A wäre natürlich schon schön aber wer macht das? Die JOSM-Presets jedenfalls wären so direkt suchbar: http://josm.openstreetmap.de/browser/josm/trunk/data/defaultpresets.xml . Was da noch fehlt, ist eine Suchanfrage, die deutsche Worte entgegennimmt, und die Suchanfrage dann mit englisch übersetzten Worten macht. Hat nicht Frederik oder Jochen letzthin beschrieben, wie sie für irgend ein Tool automatisiert Tags aus der Wiki-Seite DE:Map_Features extrahieren. So was könnte man auch machen und dann auf einer kleinen Webseite zur Verfügung stellen - mit OpenSearch (d.h. der Möglichkeit, die Suche direkt im Browser einzugeben, z.B. der Instant Search (Ctrl-K) in Firefox). LG, S. Am 2. März 2011 11:40 schrieb Markus liste12a4...@gmx.de: Hallo Stefan, Man hat irgendein bestimmtes Objekt im Sinn, z.B. Schloss oder Aussichtspunkt, und möchte rasch wissen, wie der Tag (bzw. Value) heisst. Das müsste m.E. der Editor leisten. In JOSM gibt es dafür die Vorlagen, und dazu eine Suchfunktion. Dort gibst Du Schloss ein - und bekommst ein Formular, das Dir für jedes Attribut passende Auswahllisten und Eingabefelder anbietet, plus einen Link zu einer Hilfeseite, auf der man dann bebilderte Beispiele findet. Das Wiki dient als erklärende Hilfe und zur Planung und Entwicklung. How-to-map-A war ein Lösungsversuch aus der Zeit vor den GUI-Editoren. Die händisch eingetragenen englischen Schlüssel-/Werte-Paare stammen aus der Zeit der Konsolenfenster und sind heute wahrscheinlich zunehmend nur noch für Power-Mapper und DV-Profis interessant. Map-Features ist zusammen mit den Wiki-Seiten sozusagen die Datenbank der wichtigsten Attribute wie sie dann beispielsweise in den JOSM-Vorlagen verwendet werden. Gruss, Markus ___ 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
