Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sat, 20 Nov 2010 15:56:48 -0800 (PST) Von: NopMap ekkeh...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? qbert biker wrote: Und es gibt das Konzept der Sichtbarkeit http://wiki.openstreetmap.org/wiki/Key:trail_visibility das wenigstens einen Teilaspekt abdeckt, allerdings nicht vergeben war und wie man in einer anderen Diskussion nachlesen kann, oft falsch vergeben wird. Das Attribut habe ich mittlerweile ergänzt - ob und wie es ins Rendering einfliesst, weiss ich derzeit nicht. Nach meinem Wissen wird dieses Tag von allen Renderern ignoriert. Meines Erachtens spielt es bei einem markierten Weg auch keine Rolle - wozu ist er markiert? :-) Das ist auch im anderen thread angesprochen - das ist ein Missverständnis, denn es geht um die Sichtbarkeit des Weges ansich, was allerdings von vielen mit der Existenz von Markierungen verwechselt wird. Im konkreten Fall ist es einfach so, dass es ein Pfad mit stark wechselnder Sichtbarkeit ist, der sich teilweise im Gelände verliert. Dass es keinerlei Markierungen und Schilder gibt, ist davon unabhängig, bzw. ein weiteres Merkmal. Wer experimentierfreudig ist und solche Pfade mag (z.B. ich), der ist durchaus interessiert an so einer Eintragung. Ich habe deshalb hier das mit der Sichtbarkeit ergänzt, egal obs nun gerendert wird oder nicht. Das ist halt eines der Probleme mit OSM: Es gibt keinen Mindeststandard. Es gab eigentlich immer Bestrebungen, einen Mideststandard zu halten, aber leider arbeiten einige Fundis aktiv dagegen an, da sie darin eine Bevormundung sehen. Schade eigentlich... Gruesse Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sat, 20 Nov 2010 15:30:05 -0800 (PST) Von: NopMap ekkeh...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? Wanderwege werden in der Tat als Relationen eingetragen und dann sind auf den einschlägigen Karten auch entsprechend hervorgehoben. Dabei ist es egal, ob es sich um einen offiziellen internationalen Premium-Millenium-Fernwanderweg handelt, ein Trampelpfad mit ein paar Farbtupfen auf den Felsen oder ein Netzwerk von Wegen wie in der Schweiz - das läßt sich alles sinnvoll abbilden. Wenn es ein vor Ort erkennbar markierter Weg ist, dann ist es auch eine Relation wert. Infos dazu finden sich im Wiki unter Wanderweg. [1] Das ist wohl auch der Grund fuer die Stifmütterliche Behandlung abseits der Hauptrouten. Viele haben noch nie eine Relation gesetzt und werden es auch nie tun, weil eine Relation ansich zu abstrakt erscheint und auch nicht leicht zu handhaben ist, zumindest mit den gängigen Relation-Editoren, die ich so kenne. Man muss das Modell hinter den Relations erst verstanden haben, um sie als solche zu verstehen. Ist das nicht vom einfachen Mapper etwas zuviel erwartet? Auf der Hauptseite wirst Du nichts geeignetes finden. Die Anforderungen für die Hauptseite sind wohl auch ziemlich heftig. Ein Layer für Fussgänger/Radfahrer und ein anderer optimiert fürs KFZ statt drei sehr ähnlichen Styles wäre machbar. Hier wird viel Potential verschwendet, denn langsam wird OSM für den Wanderer zu einer recht bemerkenswerten Quelle - wenn er sich nicht im Informations- und realem Dickicht verläuft ;) Die Presets in der Richtung sind mit Vorsicht zu genießen. Sie sind aber derzeit das beste Mittel, mal schnell etwas einzutragen. Dass sehr viele Mapper das ähnlich sehen, lässt sich retour über die Fehler der Eintragung erkennen. Ich führe den aktuellen Stand bei den Wanderwegen direkt auf auf diese Handlungsweise zurück. Man hat einen Weg gezeichnet und will ihn attributieren - schnell und effektiv und sich nicht parallel im Wiki verfransen. Ich arbeite daran, parallel zu meiner Wanderkarte auch einen dedizierten Editor speziell für Wanderwege bereitzustellen, mit entsprechenden Presets. Man kann das Ganze schon ausprobieren, auch wenn es noch nicht fertig und der Editor Potlatch2 auch noch experimentell ist, tue ich mir beim Mappen abseits der Straßen damit schon jetzt deutlich leichter als mit JOSM. Klingt spannend - Ein Tipp vor mir, was Relations angeht: Es sollte eine Funktion geben, die die komplexität der Relations vor dem Nutzer versteckt. Cloudmade hat das mal mit Abbiegebeziehungen versucht, wenn ich mich recht erinnere. Umso direkter eine Eintragung möglich ist, desto mehr spricht sie den Nutzer an. Also optimalerweise als Kontextstruktur, die im Hintergrund dann die Relation anlegt. Gruesse Hubert -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sun, 21 Nov 2010 11:42:50 +0100 Von: Johannes Huesing johan...@huesing.name An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? Meine ich nicht. Ich interpretiere es so, dass eine Farbmarkierung an jedem siebten Stein eine gute Sichtbarkeit bedingt. Wieder mal klassisch OSM - das Zusatzattribut vermischt sich in Inhalt und Funktion mit dem Hauptattribut, denn auch da ist die Sichtbarkeit ein Thema. Ich glaube, dass die Hochgebirgswanderwegtags im JOSM *zu* präsent sind. Wobei das weniger an JOSM liegt, sondern daran, dass man ein Schema auf alle Wanderpfade umlegt, das nur fürs Hochgebirge wirklich gut passt. sec_scale ist zwar gut gemeint, aber die meisten Pfade sind nun mal in leichten oder mittelschweren Gelände und da kann ich wieder nur einen schwammigen Mischmasch eintragen. Im genannten Beispiel bestimmt nicht das Gelände oder die Höhe über Null (kein Schotterabhang) die Sichtbarkeit, sondern schlicht, dass sich für diesen Weg kein Touribüro oder sonstwer interessiert. Er ist einfach da, zwar schlecht zu erkennen aber trotzdem begehbar und wurde eingetragen. Und welcher OSMler nimmt nicht gerne die gelegenheit war, etwas neues einzutragen das nicht ganz so leicht zu finden ist. Ich könnte mir also gut vorstellen, dass genau diese Wege in OSM stark zunehmen werden und dass man sich nicht ganz so stark vom Hochgebirge und dem was die Touriverbände unter Wegen verstehen, leiten lassen sollte. Wenn es eine Regel gibt, die auch in mittelschweren Gelände abseits des Hochgebirges zwischen leicht erkennbaren und fast unsichtbaren Pfaden unterscheidet, trage ich diese Unterscheidung ein. Wenn nicht gibts eben auch von mir Einheitstagging und wer sich verläuft, hat eben den Fehler gemacht, sich auf OSM zu verlassen ;) Grüsse Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Was ist jetzt bei Dir das Haupt- und was das Zusatzattribut? Nachdem 'sec_scale' direkt als Klassifizierung verwendet wird und auch viualisiert wird, ist es das Hauptattribut. Über 'trail_visibility' wird geschrieben, dass es ausgelagert wurde und es hat eigentlich nur ergänzende Bedeutung. Oder andersrum - ohne 'sec_scale' kann man mit 'trail_visibility' relativ wenig anfangen. Beide haben aber bestimmte Beschreibungen gemeinsam, also z.B. 'Wegspur kaum vorhanden.' bei 'sec_scale' und 'trail_visibility'. Eine starke Beschreibungssprache verzichtet auf solche Überschneidungen und dann sind die Attribute gleichwertig und unabhängig voneinander anwendbar. Der Schwierigkeitsgrad eines Weges ansich ist ja weitgehend unabhängig davon, wie gut er im Gelände sichtbar ist. Einen kaum zu findenden Waldpfad kann ich u.U. mit Pantoffeln begehen, bei einem ausgezeichnet sichtbaren Hochgebirgssteig ist das weniger zu empfeheln. Auf einer Ferrata haben sich auch noch wenige verlaufen, auch wenn die durch die Felsen führt. -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sun, 21 Nov 2010 21:36:04 +0100 Von: Johannes Huesing johan...@huesing.name An: qbert biker qbe...@gmx.de CC: talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? qbert biker qbe...@gmx.de [Sun, Nov 21, 2010 at 07:19:41PM CET]: [...] Der Schwierigkeitsgrad eines Weges ansich ist ja weitgehend unabhängig davon, wie gut er im Gelände sichtbar ist. Sag das dem Schweizer Alpenverein. Nach dieser Skala ist ein Weg, der selten begangen über eine flache Alm führt (und somit keine Wegspur hat oder sie nicht von den quer verlaufenden Spuren der Rinder zu unterscheiden ist), nicht zu klassifizieren. Um das gehts ja - die Alpenvereine können zwar mit ihren Skalen einen Anhaltspunkt für die Klassifizierung geben, aber sie können sie aus guten Gründen nicht bestimmen. Alpenvereine, auch die hiesigen, haben klare Vorstellungen von der touristischen Nutzung der Pfade, die aber von dem Konzept einer allgemeinen Karte abweichen. Sie wollen ja nicht jeden Pfad in ihren Gebiet beschreiben, sondern die Wanderer kanalisieren. Und deshalb legen die Alpenvereine wenig wert auf eine unabhängige Beschreibung von Sichtbarkeit und Schwierigkeitsgrad. Und dass der schweizer Alpenverein besonderen Wert auf die gute Beschreibung von möglichst extremen Wegen legt, hat ja nun sicher auch etwas mit dem dahinterliegenden Geschäftsmodell zu tun. Wenn sich jetzt aber die OSM-Karte immer mehr von den Alpenvereinen weg emanzipiert und viele Wege eingezeichnet werden, die von diesen ignoriert werden, dann muss man die Oberhoheit der sec skala in Frage stellen, zumindest auuserhalb der Extremregionen bzw. in der Fläche. Gruesse Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Alpin?
Ich habe gerade ein wenig in den Diskurs um sac_scale und visibility reingeschaut und erst mal heftig geschluckt. In diesm Fall bin ich ein konkret Betroffener, denn ich bin kuezlich mit ausgedruckten OSM Screenshot munter im Gebirge rum und dabei genau über dieses Thema gestolpert - wobei das ziemlich woertlich zu nehmen ist. Es geht um das Gebiet um den Heimgarten herum. Zwar am Alpenrand gelegen, aber trotzdem gefährlich genug, dass man beim Verlaufen ernsthaft in Gefahr kommen kann. Ich hatte mir also eine nette Rundtour zusammengesucht, die so nach der OSM-Karte haette eigentlich funktionieren hätte sollen, aber übersehen, dass einige Wege darin nicht ausgeschildert und auch sonst eher kaum vorhanden sind. Da steht man dann schnell im offenen Gelände und versucht den Weg wiederzufinden. Gut, es gäbe da Tags dafür und es wurde ja oben munter diskutiert, wie man die am besten anwendet. Allerdings löst das nicht das Problem, dass die Information die Beteiligten nicht erreicht hat. Wo liegt nun das Problem? Hatte der Eintragende schlicht keine Lust, die Sichtbarkeit einzutragen oder wusste er nichts von der Option? In diesem Fall war die Lehre aus der Sache, dass OSM derzeit keine Wanderkarte ersetzt, die markierte und beschilderte Wege sauber in der Darstellung von wilden Trampelpfaden trennt, wobei man letzere nur mit viel Selbstvertauen und Geländegefühl begehen sollte. Ich vermisse hier die klare eindeutige Darstellung z.B. in den klassischen Wanderkarten wie rot (durchgaengig, gestrichelt, gepunktet) für ausgeschilderte markierte Wege nach Schwierigkeit sortiert und schwarz (durchgezogen, gestrichelt) für Wege bei denen man auf Ueberraschungen gefasst sein sollte. Dann muesste nur noch die Informationskette funktionieren damit die Information des Eintragenden auch beim Nutzer ankommt. Diskussionen wie oben sind zwar fuer Kenner sehr aufschlussreich, der normale Mapper ist aber offensichtlich deutlich überfordert und und verlässte sich daher einfach auf das Werkzeug und interpretiert die Optionen wie es ihm gefällt. Gruesse Hubert -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sat, 20 Nov 2010 16:07:50 +0100 Von: Torsten Leistikow de_m...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? qbert biker schrieb am 20.11.2010 14:55: In diesem Fall war die Lehre aus der Sache, dass OSM derzeit keine Wanderkarte ersetzt, die markierte und beschilderte Wege sauber in der Darstellung von wilden Trampelpfaden trennt, wobei man letzere nur mit viel Selbstvertauen und Geländegefühl begehen sollte. Nach meinem Verstaendnis sollten ausgeschilderte Wege als Relationen eingetragen werden, Mein Verständnis ist ja eher, dass Relations eine Eigenschaft mehreren Elementen zuweisen sollen, also z.B. dass der Wanderweg xy über die ways A,B,C und D geht. Ich hätte z.B. auch keine Ahnung, welche Relation ich anwenden sollte. die dann auf den ueblichen Wanderkarten auch entsprechend hervorgehoben Und zu denen muss man erst mal finden. Ohne Intergrundinfo lande ich auf der OSM-Hauptseite und habe die Auswahl zwischen Osmarender, Mapnik und Radfahrer. Welche Karte müsste ich nutzen, damit ich mehr Infos zu Wanderwegen bekomme? werden. Etablierte Mittel und Wege gibt es also. Man kann in der Liste Hunderte von Beiträgen lesen, die alle beinhalten, dass alles irgendwie geht. Nur was man unter etabliert verstehen soll, ist etwas anderes. Offensichtlich warst du in einer Gegend unterwegs, wo die OSM-Karte noch nicht so ausgereift ist wie anderswo. Ein paar Meter weiter ist die Zugspitze und da toben sich natuerlich etwas mehr Leute aus ;) Aber im Ernst - es ist schon eine gut versorgte Ecke, leicht von München aus zu erreichen und auch entsprechend begangen, insofern nichts exotisches. Aber das wir mehr oder minder weisse Flecken haben ist ja nichts neues. Nein, das hat nichts mit weissen Flecken zu tun. Es ist eher die Standardversorgung in der Fläche, abseits der total überlaufenen Wege. Und hier stellt sich die Frage, ob das Zusammenspiel von Wiki und Presets wirklich funktioniert. Ein massenhaft begangener Weg hat auch viele Eintrager, die auch mal etwas korrigieren, aber in der Fläche muss auch der Mapper angesprochen werden, der eben gerade da ist und keine Lust hat, im Wiki zu wühlen, ob es für das was er sieht irgendwo schon eine Lösung, womöglich auch noch mittels Relation, gibt. Die meisten machens wohl so wie ich auch meistens. Wenn ein Preset zu passen scheint, erstmal rein damit. Gruesse Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sat, 20 Nov 2010 16:36:15 +0100 Von: Fichtennadel soski...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? Wenn Du Dir Nop's Reit- und Wanderkarte z.B. für http://www.wanderreitkarte.de/index.php?lon=15.7306lat=47.6933zoom=14ansiehst und die Legende einblendest, wird sehr schön zwischen den einzelnen Wegarten unterschieden. Ob der Weg markiert ist oder nicht, ist leider nicht zu erkennen, stimmt. Ahhh, ich wusste ja, dass es da noch was gibt, es gibt sicher auch noch ein paar mehr verborgene Perlen, schade dass man sie auf dem direkten Weg nicht findet. Leider komme ich im Moment nicht drauf, aber ich setze dann noch einen Link. Der Mapnik Stil auf der OSM Hauptseite ist als Wanderkarte total untauglich. Gilt eigentlich fuer alle Stile dort. Irgendwie habe ich den Eindruck, dass die auch schon mal besser rübergekommen sind. Warum tracks, die breite gut ausgebaute Forststrassen sind, die man auch mit einem Porsche befahren könnte, eine ähnliche Optik haben wie ein kleiner Pfad, erschliest sich nicht unbedingt. Platz genug für Doppellinien wäre in den hohen Zoomstufen schon da. Alles in allem gibt die OSM-Hauptseite wenig für den Wanderer her. Das Problem gibt's bei OSM immer. Ich denke im Wiki sind die Sachen schon recht gut beschrieben, sie müssten nur gelesen und auch befolgt werden. Das Wiki ist eine riesige Informationswüste, die wohl nur von wenigen wirklich durchquert wird ;) Mich stört hier, dass das einfach als gegeben dargestellt wird. Ist das Wiki wirklich eine sinnvolle Informationsquelle für den Gelegenheitsmapper, der mal schnell etwas eintragen will, oder bräuchte es kürzere Informationswege, damit auch weniger eingeweihte schnell mal eine Information dazufügen können? Gruesse Hubert -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sat, 20 Nov 2010 18:03:27 +0100 Von: Falk Zscheile falk.zsche...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? Ich sehe in dem von Dir geschilderten Fall kein Problem in den OSM-Daten. Das von Dir geschilderte Problem resultiert aus einer für Deine Zwecke unpassend gerenderten Karte Leider nein, ich habe mir sowohl die Daten als auch die Beschreibung nochmal angeschaut. Dafür, dass es keine Beschilderung gibt, ist offensichtlich kein Konzept vorgesehen. Es gibt das Konzept der Routen, das mittels Relations umgesetzt ist. Hier interessieren aber keine Routen, sondern schlicht ob es einen Hinweis gibt, wohin der Weg geht. Und es gibt das Konzept der Sichtbarkeit http://wiki.openstreetmap.org/wiki/Key:trail_visibility das wenigstens einen Teilaspekt abdeckt, allerdings nicht vergeben war und wie man in einer anderen Diskussion nachlesen kann, oft falsch vergeben wird. Das Attribut habe ich mittlerweile ergänzt - ob und wie es ins Rendering einfliesst, weiss ich derzeit nicht. und einer falschen Vorstellung vom Karteninhalt. Na ja, was hier falsch oder richtig ist - in diesem Fall war es die Art der Eintragung. Man kann also von einem eingezeichneten Weg in der Karte auf dessen Vorhandensein in der Realität schließen, aber nicht darauf, dass dieser Weg auch markiert ist. Nimm dir eine Wanderkarte des bayrischen Vermessungsamts zur Hand und du kannst eben genau das sehen. Was darin rot markiert ist, erfüllt einen Mindeststandard an Existenz, Markierung und Bschilderung. auch nur heißenda ist schon einmal jemand entlang gelaufen. Dessen bin ich mir sehr wohl bewusst und ich bin auch mit einer Abenteuerlust da reingestolpert. Ich habe genug Bergerfahrung, um damit umzugehen, mich auch mal zu verlaufen und hätte umkehren können, als kein Schild vorhanden war. Problematisch wird es bei der Planung des Ausflugs und besonders dann, wenn ich nicht alleine bin. Dann heisst es dann, dass alles was nicht näher beschrieben ist, erst mal als 'da ist mal wer durchmarschiert' eingestuft werden muss. Und spätestens hier muss ich dann wieder zum Alternativmaterial von Vermessungamt und Alpenverein zurückgreifen. Man muss also bei der Verwendung von auf OSM basierendem Kartenmaterial auch wissen, was der Renderer bei der Datenauswertung berücksichtigt (das sollte sich mittelbar über die Legende der Karte erschließen). Was dann ziemlich traurig für OSM aussehen würde, wenn der Renderer wirklich konservativ vorgeht und nur Wege als begehbar anzeigt, die das auch belegbar sind. Gruesse Hubert -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sat, 20 Nov 2010 18:11:10 +0100 Von: Johannes Huesing johan...@huesing.name An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? Soll der Gelegenheitsmapper die alpinen Wege pflegen? Er soll die gesammelten Informationen möglichst effizient und sicher eintragen können. Wenn massenhaft Fehler passieren (siehe path_visibility thread) könnte das auf ein konzeptionelles problem hindeuten. Ich habe den Weg im Wiki verfolgt und man kommt schon an die Information ran, wie man besser einträgt - ob viele Mapper diese Geduld aufbringen, kann bezweifelt werden, wenn man die Ergebnisse anschaut. Nur als beispiel meine Wenigkeit. Wenn ich kaputt von der Tour zurückkomme und noch schell josm anwerfe, dann klappe ich kurz die Vorschläge auf und werde bei demanding_alpine fündig. War ja anstrengend, auch technisch anspruchsvoll und in den Alpen wars auch. Dann klick ich ein paar Wege rundrum an - die anderen machens auch so - und schon habe ich Murks eingetragen. Ich werde das demnächst anpassen, so wie meine alten footway-Frühsünden, aber die Masse wirds nicht machen. Expertise für OSM ist alles andere als deckungsgleich mit der Expertise für das Bergwandern. Ein Gelegenheitsmapper kann ein Bergfex sein, ein OSMonaut mit schwarzem Gürtel kann bergunerfahren sein. Und hier setze ich den Anspruch etwas anders an. Ich sehe das problem nicht darin, dass so etwas in OSM nicht lösbar wäre, sondern eher darin, dass man auf uralte Ansätze setzt, die mal richtiger Strukturierung bedürften. Wenn ich eine halbe Stunde im Wiki rumklicken muss, um mit viel Glück die Beschreibungen zu finden, werde ich es irgendwann einfach unterlassen und blind dem Editor vertrauen - was der vorschlägt und irgendwie passt, wird schon richtig sein... Grüsse Hubert -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Alpin?
Original-Nachricht Datum: Sat, 20 Nov 2010 21:01:13 +0100 Von: Ulf Möller o...@ulfm.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] OSM Alpin? Am 20.11.2010 18:51, schrieb qbert biker: Und hier setze ich den Anspruch etwas anders an. Ich sehe das problem nicht darin, dass so etwas in OSM nicht lösbar wäre, sondern eher darin, dass man auf uralte Ansätze setzt, die mal richtiger Strukturierung bedürften. Das hilft bei diesem Problem wenig. Bei einem Crowdsourcing-Projekt Crowdsourcing oder nicht spielt hier keine Rolle. kann es prinzipbedingt immer Lücken und Fehler geben. Es gibt immer Fehler, auch in der DAV-Karte. Es stellt sich einfach nur die Frage, wie man mit ihnen umgeht. Im Prinzip ist jeder nicht offizielle Weg ein Mehrwert für OSM, solange es ein Minimum an Unterscheidbarkeit gibt. Das Problem, das sich hier aufzeigt ist doch, dass 1. Viele Mapper die Informationen nicht finden, die sie bräuchten, um alles so einzutragen wie sei es vorfinden und 2. Sich manche Klassifizierungen als zu komplex erweisen, dass sie sich in der praktischen Anwendung bewähren. Am Beispiel sac_scale kann man gut sehen, dass man hier zwar feine Unterscheidungsgrade fürs Hochgebirge hat, aber die Masse der Wege landet in nur 2 Kategorien: 'hiking' und 'mauntain hiking'. Die restlichen Abstufungen beziehen sich auf Gelände, das die Masse der Mapper wohl selten zu sehen bekommt. Wenn Kartenfehler dich in eine gefährliche Situation bringen können, darfst du dich nicht allein auf OSM verlassen. Dann gehört halt eine DAV-Karte in den Rucksack... Ich habe kein ernstes problem damit - mach deine Aussage einfach nochmal, wenn OSM eine schlechte Presse bekommt, weil sich irgend ein Sandalentourist wegen OSM verlaufen hat, weil er daran geglaubt hat, dass es nichts besseres als OSM als Karte geben kann ;) Gruesse Hubert -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Original-Nachricht Datum: Mon, 08 Nov 2010 08:15:50 +0100 Von: André Joost andre+jo...@nurfuerspam.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de]AIO Europe nun zu groß für 4GB SD Nun, dann sollen die Editoren (ob mobil oder nicht) die OSM-IDs eben auch als Text behandeln, und -wenn nötig- intern eine eigene numerische Indizierung verwenden. Den gesamten planet.osm bekommt ja sowieso keiner in den Speicher. Das mit dem IDs als Text ist für den Export praktisch, aber ansonsten ist der 64Bit Namensraum (1.8*10^19) schon ganz ansehnlich. Deshalb auch die Unterscheidung von Editoren, die auf Mobilgeräten arbeiten und welchen, die man auf dem heimischen PC einsetzt. Der 0815-PC ist von Haus aus 64-Bittig und hat soviel Speicher, dass die Verdopplung kaum etwas ausmacht. Im Mobilbereich hat man es aber mit vorwiegend mit 32-Bittern zu tun (z.B. ARM) und dann sind 64 Bit ungünstig was Rechnezeit und den nicht so üppig vorhandenen Speicher angeht. Bleibt das Mapping, also die Abbildung auf einen eigenen Namesraum. Es ist zwar kein grösseres Problem, sich für den mobilen Router die Daten einzudampfen und mit gemappten lokalen IDs ohne Lücken zu arbeiten, aber fürs Zurückschreiben sind dann Klimmzüge notwendig, weil man dafür die original-IDs zwingend braucht. Und die brauchen als Text dann noch mehr Speicher als der normale 64Bitter, also 10 Byte statt 8 und das auch nur bis 33Bit. Und Rechnen mit Strings macht nur begrenzt Spass, auch wenn man Strings schon zum indizieren verwenden kann... -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO Europe nun zu groß für 4GB SD
Original-Nachricht Datum: Sat, 06 Nov 2010 08:54:16 +0100 Von: Carsten Moeller cmindivid...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] AIO Europe nun zu groß für 4GB SD ich hab keine Ahnung (das ist ja eine tolle Einleitung ...;), was da alles in die Karte aufgenommen wird. Anscheinend ja fast alles! Ich sehe mich mit ähnlichen Dingen konfrontiert und will nur ein paar Zahlen für Deutschland liefern. Als ich mich vor einem Jahr mit dem OSM-Routing (hardcore) begann zu beschäftigen, da lieferte mir OSM in etwa 40Mio Knoten. Heute sind's bereits annähernd 60Mio. Und dies eigentlich nur, weil OSM ja nicht zwischen z.B. Gebäuden und Wegen und so trennt. Da ist ein Knoten erstmal ein Knoten. Wenn also der Speicher zu gering ist, egal ob Kiste oder Navi, dann kann man eigentlich nur noch Dinge weglassen, um die Mengen zu reduzieren. Ein weiteres Problem wird es gefühlt in ca. 3 Jahren geben. Dann nämlich wird OSM mit seinen IDs an die 32-Bit-Grenze stoßen - schöpfen heute bereits 31 Bits aus - und sämtliche IDs auf 64-Bit umstellen. Wenn da vorher seitens der Garmins, Router, usw. keine Umschlüsselung stattfindet, dann wird der Speicherbedarf sogar ohne Mehrinformation von heut auf morgen aufgepumpt. Gruß, Carsten Korrektur: Meinte natürlich 30 / 31 Bits (32 wären ja negativ;-) Nö, das mit den 32 Bit passt schon, denn ein Knoten hat in der Anwendung keine negativen Werte. Die Beschneidung auf 31 Bit, bzw. negative Werte ist nur ein Trick, um noch ein Flag zu übrig zu haben. Das kann bei Editoren sein, ob jetzt ein Datum schon übertragen wurde oder auch nicht. Das OSM-XML-Format ist komplett aussen vor, da die Zahlen in Textform gespeichert werden, die keine Begrenzung kennen. Bei der praktischen Anwendung in mobilen Geräten muss man nur unterscheiden, ob man die Fähigkeit behalten will, Daten zurückzuschreiben. Bei rein darstellendem Zugriff kann man mit 32 Bit noch lange leben, da man bei der Wandlung den Knotennamensraum komprimieren kann. Auch kann man Flächen in effiziente Strukturen wandeln und kann sie getrennt speichern. Wer allerdings mobil Daten eintragen will, braucht das original OSM-Datenmodell mit seinen Unzulänglichkeiten und da wird man wohl in den sauren 64-Bit Apfel beissen müssen. -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Original-Nachricht Datum: Fri, 5 Nov 2010 10:08:48 +0100 Von: M∡rtin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen? ja, man sollte einfach mal ins Wiki schreiben, dass width die Fahrbahnbreite ohne Gehsteige enthalten sollte. Im Wiki dämmert viel Information vor sich hin, ohne von der Mehrheit beachtet zu werden. Tags ohne Sichtbarkeit auf der Karte haben wenig Chancen überhaupt wahrgenommen zu werden. Ausserdem wurde ja das Wiki von höherer Stelle als reines Vorschlagswesen eingestuft ;) ja, oder auch schmaler. In Z18 ist die OSM-Straße meist schmaler als die Realität. Stimmt, Fällt z.B. hier unangenehm auf: http://www.openstreetmap.org/?lat=52.08868lon=8.69753zoom=17layers=B000FTF In dieser Zoomstufe wird die vorhandene Fläche nicht effektiv zur Darstellung der Fahrbahneinzelheiten genutzt. Möglich ist z.B. diese Darstellung (noch ausbaufähig): http://img214.imageshack.us/img214/2618/bosmcrossing2.png Dass es GoogleCo (noch) nicht hinbekommen, so aufgelöst darzustellen, da auch z.B. GDF hier alles andere als optimal ist, ist eine andere Sache. Aber OSM will doch in jeder Beziehung anders und vor allem besser sein als das ewige Vorbild. Gruesse Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Original-Nachricht Datum: Thu, 04 Nov 2010 03:16:06 +0100 Von: Stephan Wolff s.wo...@web.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen? Sobald die Bedeutung von width klar ist, könnte man enge Straßen in der Karte schmaler zeichnen. Osmarender wertet width für Flüsse aus. Solange nicht klar ist, ob eine Straße im Gewerbegebiet mit 20m Gesamtbreite und 7m Fahrbahnbreite oder eine enge Altstadtstraße mit 7m Gesamtbreite und 4m Fahrbahnbreite das Tag width=7 erhält, kann man es nicht nutzen. Ist ein Klassiker, der zeigt, dass diese Form der Basisdeokratie, also abwarten bis es sich von selber löst, Schwächen hat. Niemand hat Vorteile von zwei konkurierenden Definitionen, die sich gegenseitig ausschliessen und die Auswertung erschweren. Dabei gäbe es durchaus interessante Definitionen und Vorgaben, an denen man sich orientieren könnte: http://de.wikipedia.org/wiki/Stra%C3%9Fenquerschnitt http://de.wikipedia.org/wiki/Richtlinie_f%C3%BCr_die_Anlage_von_Stra%C3%9Fen_%E2%80%93_Querschnitt (Analog auch für andere Länder) Ähnlich sieht es mit den Spuren aus. Ich habe mal ausprobiert wie man mittels Spurbeschreibungen auf eine gute Annäherung an die Realität kommen kann: http://lists.openstreetmap.org/pipermail/talk-de/2010-January/060852.html Zusammen mit den Informationen zur Spurbreite, die man auch aus den Standards ableiten kann (falls als Bezug angegeben) ergibt das in den unteren Zoomstufen eine Alternative zu der heute gebäuchlichen Überhöhung der Breite. Gemeint ist die übliche nicht massstabsgerechte Darstellung der Breite, die je nach Zoomstufe deutlich breiter ist als in der Realität. Dabei ist in den hohen Zoomstufen durchaus eine realistische Darstellung des Flächenverbrauchs möglich und dann wird auch die Breite real nutzbar. Gruesse Hubert -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen?
Original-Nachricht Datum: Sat, 30 Oct 2010 09:45:42 +0200 Von: Jochen Topf joc...@remote.org An: Jonas Stein n...@jonasstein.de CC: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Wie erreichen wir einheitliche Tagdefinitionen? Das ist keine Anarchie. Nein, das ist keine Anarchie, das ist die natürliche Entwicklung eines Systems, das weitgehend sich selbst überlassen ist. Es verliert Struktur und verfettet. Kennt jeder irgenwie vom deutschen Steuerrecht oder manche von uns von endlosen Projektsitzungen bei denen immer nur ein schaler Kompromiss herauskommt. OSM ist hier nicht herrausragend, weder in die eine, noch in die andere Richtung. Ein Konzept wie das OSM-Taggingschema kann an seinen Selbstreinigungskräften gemessen werden. Wie gross sind die Chancen, dass Altlasten, die sich nicht bewährt haben, abgeworfen werden oder wird alles zusammenaggregiert und verwurschtelt? Aber es funktioniert. Es kommt darauf an, was man unter 'funktionieren' versteht. Ja, es stimmt, das OSM Datenmodell schleppt sich gemächlich über die Jahre ohne eine echte Entwicklunsperspektive zu haben. Langfristig setzt sich so nämlich die Mehrheit der an einem Thema interessierten durch. Na ja, meistens setzt sich das durch, was der Editor als Mehrheitsbeschaffer vorgibt ;) Aber auch wenn nicht, Mehrheiten erzeugen keine Tiefe und vermitteln auch keine Selbstreinigungskräfte. Das wird besonders deutlich, wenn sich zwei Lager bilden, von denen jede Seite genug Einfluss hat, um ihre Wahrheit in Teilbereichen durchzusetzen. dann muss man das nicht in einem speziellen (selbsternannten) Gremium durchsetzen. Der gute alte Buhmann - das Gremium, das über die Köpfe der Anwender hinweg bestimmt. Was ist, wenn dieses Gremium nur Vorschläge macht und die Anwenderschaft darüber abstimmt, ob sie diesen Vorschlag für Vrteilhaft hält? Aber im heutigen OSM ist das undenkbar - es gibt nur die primitive Abstimmung mit der Macht der Einträge über tagwatch oder einsame diktatorische Entscheidungen hinter verschlossnen Türen, die man als Mapper gefälligst zu akzeptieren hat. Oder es hat diese Macht, dann werden sich alle Mapper, die der Meinung des Gremiums nicht zustimmen, von OSM abwenden. Huhuuu, noch so ein Horrorszenario. Ein pöses machtgeiles Gremium vertreibt die Mapper. Warum immer diese dummen Polarisierungen, die jeden Mittelweg als ungangbar brandmarken? In den ganzen Jahren gab es so gut wie niemanden. der ein so machtvolles Gremium gefordert hat, aber jeder gut gemeinte Ansatz wurde mit Pauschalargumenten wie diesem hier in Grund und Boden geschrieben. Was hingegen immer wieder viele Mapper gefordert haben, war eine Richtschnur, die ihnen das Mappingleben erleichtert. OSM verwendet schon das richtige Verfahren. Sonst wäre das Projekt nicht so weit gekommen. Es ist wie es ist und weil es so ist, ist es gut? Diese Aussage ist in dieser Pauschalität einfach nur Unsinn. Keiner von uns hat eine Glaskugel, die das 'was wäre wenn' beantworten kann, aber einige von uns kennen noch die alten Zeiten (vor Mitte 2007), in denen durchaus kreativ an den Tags gearbeitet wurde und zusammen das Schema verbessert wurde - ganz ohne Tagwatch Co. die Welt, die nunmal sehr komplex ist, in ein simples Schema zu pressen. Und deshalb versucht man bei OSM diese Komplexität noch zu übertreffen, indem man über ein primitives Basisschema eine quasi unendliche Vielfalt an Taggingvariationen stülpt die alles oder nichts aussagen? es geht darum, etwas praktisch nutzbares zu entwickeln. Und genau hier hätte ich weniger fromme Sprüche erwartet, sondern eine ernsthafte Abhandlung darüber, ob OSM in der praktischen Nutzbarkeit wirklich so überlegen ist. Also etwas Modelltheorie, die sich mit Redundanzen und der maximal erreichbaren Komplexität (nicht nur schreibend, auch lesend) befasst. Schon eine so simple Sache wie Abbiegeverbote hat OSM schon oft an seine Grenzen gebracht oder bringt es sie noch? -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätsvergleich, war schlechteste Wertung
Original-Nachricht Datum: Tue, 26 Oct 2010 11:43:07 +0200 Von: M∡rtin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]Qualitätsvergleich, war schlechteste Wertung Am 25. Oktober 2010 20:56 schrieb qbert biker qbe...@gmx.de: - Schwammige Beschreibungen, die man sich in einem unübersichtlichen Wiki selber zusammensuchen muss und die auch nicht durchgängig angewendet werden. das wird sich bei einem crowdgesourceten Anarchoprojekt wie OSM systembedingt nicht vermeiden lassen und hat auf der anderen Seite ja auch positive Effekte. Geht nicht, gibts nicht ;) Was sich systembedingt vermeiden lässt, ist eine weitgehend eine Frage der Spekulation, auch ob die positiven Effekte mehr Realität als Wunschtraum sind, kann weder bewiesen, noch widerlegt werden. Ich halte mich hier lieber an das konkrete und das bedeutet in diesem Fall, dass Fred immer sehr aggressiv gegen jede Form von Datenmodell angewettert hat unds jetzt genau er sich beschwert, dass man draussen mehr die Karte sieht und weniger die Daten. - Eine Ebene, also ein Graph für alles und damit eine sehr unübersichtliche und ineffiziente Struktur zum Routen Wer routen will, muss sich natürlich die Daten entsprechend vorbereiten, das ist klar. Wir sind ja keine reine Routingdatenbank. 'Wir mappen ja nicht für...' ich weiss noch gut, wie dieser Spruch damals aufgekommen ist. Das war eine Reaktion darauf, dass immer mehr Leute sich die Attribute so zurechtgebogen haben, dass es auf der Karte gut aussieht. Hier wurde dann mit Recht darauf hingewiesen, dass nicht die Optik der Kachel im Mittelpunkt steht, sondern die Integrität der Daten. Hier geht es aber um etwas anderes. Es gibt verschiedene Ansätze, wie man Daten so strukturiert, dass sie von verschiedenen Anwendungstypen gut verarbeitet werden können. Die Datenstruktur von OSM erschwert derzeit einseitig das Routen, da es sehr schwierig ist, den Graphen von Ballast zu befreien und zu straffen. Das ist aber dann wieder die Voraussetzung für effizientes schnelles Routen und gute Optimierung. - Flache Struktur bei der Abbildung der Strassenattribute, also keine getrennte Erfassung verschiedener Typenklassen kannst Du das nochmal weiter ausführen? Wir haben ja sowohl administrative (ref) als auch intelligent gewichtete (highway) als auch physikalische (surface, width, lanes, smoothness, trackgrade) als auch legale (access, maxspeed, z.T. highway) Klassen bzw. Typen. Wo fehlt Dir da noch was? Was fehlt sind weniger 'intelligent gewichtete' sondern nach konkreten Angaben gewichtete Parameter und das flächendeckend. Es stimmt, dass es eine fast unüberschaubare Anzahl von additiven Parametern gibt, die aber sehr selten angewendet werden. Ein negativer Effenkt der intelligenten Gewichtung ist auch, dass viele konkrete Angaben nicht eintragen weil sie annehmen, dass die Angabe schon irgendwo in der intelligenten Entwicklung steckt. Draussen kommt OSM vor allem als grosser Malkasten an und deshalb auch der ständige Vergleich mit Google Maps und seinen auf Fremddaten aufgebauten Kacheln. Wenn man OSM vor allem als Datensammlung anbieten will, sollte man dann doch ein wenig daran arbeiten, die Daten als abstraktes Datenwerk etwas verdaulicher anzubieten. ich sehe das eher so: wir bieten die Daten kostenlos an z.T. in einer besseren Qualität als kommerzielle Anbieter. Der Preis dafür ist, dass man sich ein bisschen anstrengen muss bei der Interpretation / Auswertung. Diese Hürde werden immer mehr auf sich nehmen, je besser und vollständiger unsere Daten werden, sieht man ja schon jetzt unübersehbar (z.B. Skobbler, AOL). Auch hier wieder wie oben: Ursache und Wirkung. Warum Skobbler ausweichen musste ist bekannt und auch ansonsten geht es eher zäh als flott voran mit der Anerkennung der OSM-Formate und der blanken Daten. In der derzeitigen Form verteuert OSM die Entwicklung von Anwendungen statt die potentiellen Entwickler zu umschmeicheln. Ich schreibe das als Entwickler, der OSM Daten seit Ende 2006 interpretieren kann und seit Anfang 2007 darauf routet. So hart wie es klingt, das einzige was die Arbeit wirklich derzeit erleichtert ist, dass an den Strassen und Wegen kaum mehr gefummelt wird und die Stagnation das erreichte erhält. Gruesse Hubert -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlechtest Wertung für OSM im Kartenv ergleich
Original-Nachricht Datum: Tue, 26 Oct 2010 06:59:57 +0200 Von: Bernd Wurst be...@bwurst.org An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Schlechtest Wertung für OSM im Kartenvergleich Ich denke nicht, dass dieser Test mich irgendwie vom Hocker reißt... Muss er auch nicht, er hat nur einen Teilaspekt verglichen, also was man in einer bestimmten Zoomstufe in verschiedenen Onlinekarten sehen kann. Und dabei ist er auf bekannte Schwächen der OSM-Renderer gestossen, die ja auch hier schon ausgiebig diskutiert wurden. Meiner Meinung nach hat da jemand zwar schon Ahnung von Kartographie, aber dennoch das Internet nicht verstanden. Die Möglichkeit in verschiedenen Zoom- Leveln eben nicht das selbe Bild anzuzeigen sondern Details ein- oder auszublenden ist doch grade das was das Internet von gedruckten Karten unterscheidet. Es ist auch ein Kriterium, wieviel ich zoomen muss, um an die gewünschte Information zu kommen. Man kann es dem Anwender nicht vorwerfen, wenn er ein wenig 'zoomfaul' ist. Dennoch hat der Autor einen sehr merkwürdigen Anspruch, denn er will Details sehen ohne dafür zu zoomen. Er fidnet es offenbar eine gute Idee bzgl. der Übersichtlichkeit, die Karte flächendeckend mit Symbolen und Texten voll zu stopfen. Überladen ist die eine Sache, eine andere ist es, ob in der jeweiligen Zoomstufe die wichtigsten Inforrmationen angezeigt werden, die in exakt dieser Zoomstufe interessieren. Ich kenne das Problem in der Art, dass ich oft dauernd rein- und rauszoome weil eine Infoemation anders nicht zu finden ist, ganz typisch dabei sind eben Ortsnamen. An anderer Stelle kommt OSM aber noch gut weg. Bei anderen Ausschnitten sind nach wie vor die wichtigen trunks fast unsichtbar, weil sie von stark grün eingefärbten Flächen fast verdeckt werden. Hier sollte man doch wirklich mal ernsthaft überlegen, ob es nicht möglich ist, Hauptverkehrsstrassen vom Hintergrund besser abzuheben, entweder indem man die Flächen weniger intensiv einfärbt oder indem man eine andere Farbe für trunk wählt. Dann zoomt man sich vielleicht nicht mehr die Mausfinger wund, wenn man einen Streckenverlauf verfolgen will ;) Gruesse Hubert -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Qualitätsvergleich, war schlechteste Wertung
Frederik Ramm wrote Genau, das ist aergerlich. Wenn wir es besser schaffen wuerden, darauf hinzuweisen, dass es bei uns nicht primaer darum geht, gegen Google etc. anzustinken, dann wuerde OpenStreetMap in so einem Test gar nicht aufgenommen Diese Haltung von dir hatte ich noch nie verstanden. Statt sich zu freuen, dass OSM als Alternative wahrgenommen wird, soll sich OSM verstecken und nicht verglichen werden? (genauso wie auch Navteq und Teleatlas nicht mit eigenen Produkten antreten) - und darauf sollten wir hinarbeiten. Das wird ohne Datenmodell nicht gehen, und gegen ein ausgearbeitetes Datenmodell hast du dich ja persönlich ja mit aller Macht gestemmt. Ich will, das in so einem Test dann MapQuest oder sonst wer steht und dass am Rand angemerkt wird, dass fuer dieses oder jenes Angebot die Quelle OpenStreetMap ist. Deshalb hatte ich vor längerer Zeit angemerkt, dass man auch ein Auge auf externe Anwendungsentwickler haben sollte und denen werden OSM-Daten nach wie vor nicht schmackhaft gemacht. Die Steine, die OSM den Anwendungsentwicklern in den Weg legt haben sich seit langer Zeit nicht geändert: - Schwammige Beschreibungen, die man sich in einem unübersichtlichen Wiki selber zusammensuchen muss und die auch nicht durchgängig angewendet werden. - Eine Ebene, also ein Graph für alles und damit eine sehr unübersichtliche und ineffiziente Struktur zum Routen - Flache Struktur bei der Abbildung der Strassenattribute, also keine getrennte Erfassung verschiedener Typenklassen Draussen kommt OSM vor allem als grosser Malkasten an und deshalb auch der ständige Vergleich mit Google Maps und seinen auf Fremddaten aufgebauten Kacheln. Wenn man OSM vor allem als Datensammlung anbieten will, sollte man dann doch ein wenig daran arbeiten, die Daten als abstraktes Datenwerk etwas verdaulicher anzubieten. Drueber zu jammern, dass die Daten als solche nur als Nebensache gesehen werden und man die Renderkacheln doch bitte nicht vergleichen sollte, bringt eher wenig. Grüsse aus der (beruflich bedingten) Versenkung Hubert -- GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] eZ430-Chronos Development Tool
Hallo, es gibt jetzt ein Entwicklungstool für MSP430 Microcontroller in Form einer Armbanduhr von Texas Instruments. Was das Gerät für die Bastler unter den OSMlern interessant machen könnte sind die eingebauten Sensoren. Ein barometrischer Höhenmesser ist dabei, ein Temperatursensor wie auch Beschleunigungssensoren für x,y, und z. Dazu gibts noch ein Funkmodul, um die Daten aus dem Gerät herauszubekommen. Das ganze gibts incl. Dokumentation, Entwicklungsumgebung, USB-Verbinder für Funk und Entwicklung für 50$. In der aktuellen c't (9/2010, ab Montag, ausser bei Abo) gibts einen Kurzartikel zum Gerät und hier http://focus.ti.com/docs/toolsw/folders/print/ez430-chronos.html gibts auch noch etwas Information dazu. Barometrische Höhenmessung war ja schon des öfteren ein Thema hier auf der Liste und deshalb dachte ich, das Ding könnte den einen oder anderen interessieren. Grüsse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs. Nutzung
Original-Nachricht Datum: Fri, 9 Apr 2010 16:03:09 +0200 Von: Thomas Ineichen osm.mailingl...@t-i.ch An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs. Nutzung Hallo MWinkelzeichnerrtin, Für mich ist wichtig: da muss ich normalerweise nicht mit zweispurigen Fahrzeugen rechnen, also setze ich ein highway=path. Eine genauere Angabe, wie breit der Weg ist, setze ich im width-Key. Wenn Du den Weg nur vom Satellitenfoto kennst, wie willst Du dann beurteilen, ob Du da mit zweispurigen Fahrzeugen rechnen musst oder nicht? Mein obiger Absatz war allgemein formuliert und nicht auf den konkreten Weg bezogen. Dass zwei Personen den selben Weg unterschiedlich bewerten können, es daher kein richtig oder falsch gibt und ich meine unvollkommene Beurteilung nicht als den einzig wahren Weg durchsetzen möchte, sollte eigentlich aus meiner Mail bereits hervorgegangen sein.. Das eigentliche Problem ist, dass man zwei Abhängigkeiten in eine Skala presst und das wird immer zu den genannten Problemen führen. Solange Ausbauzustand und Nutzungsbeschränkung nicht unabhängig voneinander erfasst werden, kann ich mir weder beim Ausbau, noch bei den Beschränkungen wirlich sicher sein, was ich vorfinde. Wenn man so eintragen möchte, dass die Daten später richtig interpretiert werden, sollte man sich nicht auf die Einordnung als track oder nicht verlassen, sondern mit getrennten Attributen beschreiben, was man vorfindet. In diesem Bereich ist ein explizites access und ein explizites surface Gold wert, denn niemand weiss, wie sich die Sichtweise auf implizit vermutete Eigenschaften von track morgen wieder ändert. Grüsse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs. Nutzung
Original-Nachricht Datum: Sun, 11 Apr 2010 16:37:00 +0200 Von: Johann H. Addicks addi...@gmx.net An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] track/footway/dogwalk: Konstruktion vs. Widmund vs. Nutzung Am 11.04.2010 15:54, schrieb qbert biker: Solange Ausbauzustand und Nutzungsbeschränkung nicht unabhängig voneinander erfasst werden, kann ich mir weder beim Ausbau, noch bei den Beschränkungen wirlich sicher sein, was ich vorfinde. Du ignorierst trotzdem die dritte Dimension: Die Tatsächliche Nutzung. Nicht wirklich, denn es gibt noch einige 'Dimensionen' mehr. Es gab ja auch mal den Vorschlag mit der Smoothness, die z.B. für die Skater interesant ist. Die Anzahl der potentiellen Dimensionen und der möglichen Kriterien ist nach oben offen. Ich erinnere nochmal an die betonierten Feldwege zwischen den Äckern in der Gegend hier. Überall 250er davor mit Land- und Forstwirtschaft frei. Reale Nutzung (nach Nutzerzahlen) jedoch nicht durch Traktoren oder Förster, sondern 99% Jogger, Gassigänger und Freizeitradler (ebenfalls mit Hund...). Gebaut ist das als etwas was anderswo schon ein unclassified wäre. Breite 250 bis 350, stabilisierte Bankette, guter smoothness-Wert. Designiert ist es ein Track mit jede menge no für den Access (vermutlich sogar Radfahrer). Von der Nutzung ist's zu 100% ein kombinierter Rad- und Fußweg wo 1-2 mal die Woche auch ein Traktor langfährt, wenn nicht gerade Zuckerrübenkampagne oder Weinlese ist. Ich sehe das ja immer aus der Entwicklersicht, also demjenigen, der die Daten liest und interpretiert und dann dem Nutzer Vorschläge machen kann, welcher Weg für ihn geeignet ist. Zuerst interessiert da, ob überhaupt ein Weg vorhanden ist, was der Eintragung des Ways abgehakt ist. Die zweite Ebene beschreibt dann, ob man den Weg nutzen kann oder darf und zwar unabhängig voneinander. Man kann das als Matrix sehen und ich versuche das mal zu verdeutlichen, indem ich jeweils 5 Stufen für die Beschaffenheit und 5 Stufen für die Beschränkungen annehme. Das gibt dann eine Matrix von 5x5 mit Beton- oder Teerstrasse bis fast verwildert in der einen Dimension und komplett frei bis komplett verboten in der anderen Dimension. Die meisten Verbindungen sammeln sich in der Diagonale, die von 'guter Ausbau/freie Benutzung' nach 'miserabler Ausbau/ Verboten' geht. Je weiter weg man sich von der Diagonale weg bewegt, desto seltener sollte die Kombination werden. Das gipfelt dann in den Ecken senkrecht zur Diagonale mit den Kombinationen 'guter Ausbau/Totalverbot' und 'freie Fahrt/unbefahrbar'. Insgesamt erhalte ich mit nur zwei Attributen 25 Möglichkeiten der Basisbeschreibung eines Weges, die alle gültig sind. Der Beschreibungaufwand steigt linear, die Beschreibungsqualität quadratisch. Bei dem oben beschriebenen Fall driftet das in die Ecke 'guter Ausbau/Totalverbot' Quetscht man Ausbau und Restriktion in eine Skala, bewegt man sich entlang der wahrscheinlichsten Kombination, also entlang der beschriebenen Diagonalen und spannende Details bleiben auf der Strecke. Das von dir beschriebene Beispiel ist hier sehr typisch. Egal für was sich der Mapper entscheidet, ob unclassified, track oder was auch immer, ohne Zusatzinformation bleibt der Weg suboptimal beschrieben. Bestimmte Nutzer wie z.B. Fahrradfahrer oder Rollstuhlfahrer fühlen sich in der Ecke mit dem guten Ausbau und der starken Restriktion am wohlsten und auf der anderen Seite sucht der Motocrossfahrer ganz gezielt nach unbefestigten Strassen in möglichst miserablen Zustand, die er befahren darf und die ihm erst Spass machen, wenn man kaum noch durch kommt. Ich denke also durchaus an die Dimension der tatsächlichen Nutzung, wenn ich eine möglichst differenzierte und neutrale Beschreibung für die beste halte. Grüsse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Sat, 3 Apr 2010 03:21:58 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Am 2. April 2010 12:15 schrieb qbert biker qbe...@gmx.de: Um mit den obigen Worten zu sprechen: Man kann den Eindruck bekommen, dass einige so berauscht von den Luftbildern sind, dass sie am liebsten OSM auf ein simples Vektorabbild dieser Bilder reduzieren möchten. ein simples Vektorabbild, mit einer Handvoll simplen Tags. Das willst Du ernsthaft mit einem Bitmap auf eine Stufe stellen? Was soll das Wort simpel in diesem Kontext bedeuten? Simpel bezieht sich auf das Modell, bzw. den Abstraktionsgrad. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurzahl-Tagging statt Linienbündel (was: Details mappen in Dortmund)
Original-Nachricht Datum: Fri, 02 Apr 2010 17:52:20 +0200 Von: Johann H. Addicks addi...@gmx.net An: talk-de@openstreetmap.org Betreff: [Talk-de] Spurzahl-Tagging statt Linienbündel (was: Details mappen in Dortmund) qbert biker schrieb: Und nochmal der Gegenbeweis: http://img214.imageshack.us/img214/2618/bosmcrossing2.png Jede Koordinate in diesem Bild wurde aus den Basislinien erstellt. Man muss dazu nichts per Hand parallel zeichnen, das kann der Rechenknecht viel besser. Das ist doch wunderbar! Auch wenn sich's blöd anhört, aber ließe sich das irgendwie in Mapnick einbringen? Ich weiss nicht, warum sich das blöd anhören sollte ;) Dann könnte die die Darstellung von einigen Autobahn- und Motorway-Kreuzen deutlich vereinfachen. Und sicher wird dann irgendwann auch mkgmap nachziehen und sinnvolle Garmin-Routinganweisungen daraus erstellen (statt wie derzeit Abbiegehinweise zum Befahren von Abbiegespuren zu geben) Ich habe leider sehr wenig Ahnung von Mapnick und SVG und kann deshalb nur ein wenig spekulieren. Ich gehe davon aus, dass Mapnik mit Vektoren und Flächen, die über Geokoordinaten definiert sind, etwas anfangen kann. Diese Daten fallen in dem gezeigten Programm als Zwischenergebnis an. Was ich mir vorstellen könnte ist eine art Proxy, der das Teilnetz auswertet, die benötigten Koordinaten erstellt und dann an Mapnik übergibt. In meinem Beispiel ist die Darstellung ueber Qt mit normalen Grafikprimitiven realisiert. Zuerst wird die graue Fläche als Basis gezeichnet und dann an den Begrenzungen die weissen Linien. Zuletzt kommen die gestrichelten Linien dran, die über die graue Fläche gezeichnet werden. Zur Realisierung: Die gegebenen Netzdaten werden in eine Abbildung projeziert, die die Rechtwinkligkeit herstellt. Auch wird auf Meter normiert so dass ich Befehle anwenden kann wie: Erstelle eine Parallele zum Polygon in 3m Abstand zur Basislinie. Diese Funktionen bauen ihrerseits auf einer selbstgebastelten Geometrielib auf, die Geradengleichungen nutzt, um an die benötigten Schnittpunkte zu kommen. Die erstellten neuen Punkte können dann wieder zu Geokoordinaten zurückgewandelt werden. Im Grenzbereich zu den anderen Elementen werden dann noch gemeinsame Punkte berechnet, um Darstellungsfehler zu vermeiden. Deshalb braucht das Verfahren auch einen Netzbezug, die auf einen Knoten grenzenden Links muessen also bekannt sein. Wie kann ich also helfen. Wenn Interesse besteht, kann ich die Verfahren dokumentieren, so dass sie direkt in einem Renderer umgesetzt werden können. Und/oder ich kann die C/C++ Routinen zur Verfügung stellen, damit jemand den Proxy bauen kann. Ich selber habe leider nur sehr begrenzte (Zeit-)Ressourcen. Gruesse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund
Original-Nachricht Datum: Thu, 01 Apr 2010 22:16:31 +0200 Von: Nils Heuermann w...@oemmes.net An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund Hi, da muss ich mich kurz entschuldigen, denn ich hatte Quatsch geschrieben, weil ich was verwechselt hatte. Ich halte die wayparts hier für einen sehr eleganten Lösungsansatz. Grüsse Hubert Hi! Am Wed, 31 Mar 2010 17:01:37 +0200 hat qbert biker qbe...@gmx.de geschrieben: Dazu nochmal das klassische Gegenbeispiel, bei dem die Linienbuendel nicht wirklich gut funktionieren: Die Doppellinie, die nur von einer Spur zur anderen gequert werden kann. Das laesst sich auf den Graphen nicht abbilden. Mit dem Modell der Wayparts http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts ginge es, wenn man ein Tag festlegt, dass den Divider nicht nur crossable, sondern z.B. outside- crossable (von der beschreibenden Spur weg) bezeichnet. da das ganze Modell bisher ohnehin nur ein Ansatz ist, kann man gerne weitere Dinge dort definieren. Wobei ich mir das für die einseitig gestrichelte Linie so gedacht hatte: | part1 || part2 | |^ | || | v || || part1:divider=line part2:divider=dash oder: | || part1 | part2 | part3 | | ^ || ^ | | | || v | | || | | | part1:divider = line part2:divider = line part2:outer_divider = line part3:divider = dash ... -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Fri, 02 Apr 2010 03:15:02 +0200 Von: André Reichelt andr...@online.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Wenn es immer so einfach wäre. Nein, es muss nicht IMMER so einfach sein, es reicht, wenn es FAST IMMER so einfach ist. Nicht die Ausnahme sollte das Design bestimmen, sondern die Regel, aber die Regel sollte Ausnahmen zulassen koennen. Jedoch geschieht der Übergang zwische verschiebenden Straßenbreiten nicht schlagartig. Ich hatte bei den Parametern eine Uebergangslänge angegeben, die das ausdrückt. Dementsprechend müsste ich die Breitenzunahme komplex als Funktion beschreiben, um exakt zu sein. Um was zu beschreiben? Um dies zu tun muss ich nicht nur Mathematik studieren sondern auch noch diverse Regeln festlegen, um aus der abstrakten Beschreibung ein genaues Bild zu rekonstruieren. Die Erweiterung beginnt an Punkt A mit x Meter und endet an Punkt B mit y Meter Breite. Dazu ist weder ein koplexes Regelwerk, noch ein Mathematikstudium nötig. Wem das nicht genug ist, der kann noch einen Abrundungsradius dazufügen. Und kommt mir jetzt nicht mit dem Argument, diese Genauigkeit sei gar nicht erforderlich. Ich weiss, dass ich den genauen Verlauf der weißen Linien an einer Autobahnauffahrt für die Navigation nicht brauche. Das ist aber nicht der einzige Anwendungsfall, auch wenn sich das einige hier anscheinend wünschen. Findest du das nicht ein wenig zu polemisch? Ja, Routing ist wichtig bei einer digitalen Karte, aber weder das wichtigste, noch die einzige Anwendung. Aber hier gehts nicht darum. Hier gehts darum, ob es mehr als eine Methode der genauen Darstellung gibt und dass hier der Eindruck erweckt wird, dass allein das haendische Reinmalen von Nodes den Anspruch hoechster Genauigkeit erfuellen kann. Und ich vertrete eben die Meinung, dass da ein geometriegestützter Ansatz gut mithalten kann oder vielleicht sogar überlegen ist. Um mit den obigen Worten zu sprechen: Man kann den Eindruck bekommen, dass einige so berauscht von den Luftbildern sind, dass sie am liebsten OSM auf ein simples Vektorabbild dieser Bilder reduzieren möchten. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Fri, 02 Apr 2010 03:08:44 +0200 Von: André Reichelt andr...@online.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Nehmen wir als Beispiel die Einfädelspur einer beliebigen Autobahnauffahrt. Um diese zu beschreiben müsste ich unter Verwendung von *Vektoren* zunächst zwei Spuren parallel zeichnen: Die Autobahnspur sowie die Beschleunigungsspur. Und nochmal der Gegenbeweis: http://img214.imageshack.us/img214/2618/bosmcrossing2.png Jede Koordinate in diesem Bild wurde aus den Basislinien erstellt. Man muss dazu nichts per Hand parallel zeichnen, das kann der Rechenknecht viel besser. Und ja, der Übergang am Ende der Einfädelspur fehlt noch, aber die lässt sich ebenso einfach aus den Basislinien errechnen wie der Rest. Ich hatte das ohne Luftbild gemacht aber mit Luftbild kann man dann die Geometrie nochmal gegen dieses prüfen und die Daten interaktiv berbessern. Dann muss ich über abstrakte Elemente (Relation) beschreiben, in welchem Stück eine Überfahrt möglich ist. Auch das ist kein Zwang. Für den Router sind parallele Spuren ein Weg und eine Spurassistenz hat bei dieser Darstellung die Daten, die sie braucht. Nur Ausnahmeregeln (z.B. Doppellinie, einseitiges Wechseln) müssen noch explizit hinterlegt werden. Sofern die Übergangsflächen rechteckig sind, geht das einfach. Spätestens wenn ich allerdings wie auf der Autobahn S-Kurven habe, muss ich über zusätzliche Vektoren beschreiben, wie die Ränder der Auffahrspur genau verlaufen. Nein, man muss es nicht, man kann. Ausserdem sind diese S-Übergänge kein Hexenwerk (siehe anderer Beitrag) Des weiteren muss ich über ein Regelwerk festlegen, ob denn nun der Startpunkt des Auffahrspurenvektors die Straßenmitte widerspiegelt oder ob wir uns auf der Linie befinden. Stimmt, aber festzulegen, auf was sich ein Punkt oder eine Linie eigentlich bezieht, könnte direkt Sinn machen ;) Wenn wir in der Mitte sind muss außerdem der Abstand zum Rand bekannt sein, den man über die abstrakte Angabe der Breite nur schwer abstrahieren kann. Also, man gehe davon aus, dass die Breite bekannt ist, bzw. sich ausmessen lässt. Dann ist bei einer Linienführung in der Mitte der Abstand vom Rand Breite/2. Ohne Breite macht eine Flächeneintragung wenig Sinn. Dass die Mitte als Referenzlinie nicht immer die beste Lösung ist, ist ein anderes Thema. Bei einer *Fläche* hingegen habe ich ein sichtbares, für den Menschen intuitives Abbild der Wirklichkeit. Eine Festlegung von Regeln ist nicht notwendig, da sich alle Regeln aus der Abbildung ergeben, und auch ohne Fachwissen über das Datenformat kann Jedermann sofort erkennen, was gemeint ist. Hint: Das geht noch besser, wenn man sich das Bild, also die Vorlage von der man abmalt, direkt anschaut und man spart sich viel Arbeit ;) Sorry für den kleinen Scherz, aber das OSM-Format ist in seiner Rohform ziemlich unverdaulich. Erst die Interpretation über josm, die Renderer oder auch die Router bereitet das menschenlesbar auf. Und so aufbereitet erkennt Otto-Normaluser seine Strasse, egal ob die als Fläche oder als Vektor kodiert ist. Gruesse Hubert -- GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern E-Mail, SMS mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Fri, 2 Apr 2010 13:51:42 +0200 Von: Bernd Wurst be...@bwurst.org An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Am Freitag 02 April 2010 12:49:31 schrieb qbert biker: Und nochmal der Gegenbeweis: http://img214.imageshack.us/img214/2618/bosmcrossing2.png Mache einen Renderer, der solche Bilder macht, OK, abgehakt, siehe screenshot irgendwo öffentlich zugänglich Naja, das letzte Vierteljahr ist keiner auch nur auf die Idee gekommen, danach zu fragen. Also OK, wenn sich jemand fuer den Quellcode interessiert, dem kann geholfen werden, sobald die aktuellen bugs raus sind. (das stets aktualisierte Ergebnis, nicht nur den Sourcecode), Kacheln? Da muesste jemand anderes ran. Das ist (eher wird) ein Editor mit WYSISYG-Darstellung. Ich interessiere mich mehr für Echtzeit-Vektorvisualisierungen (z.B. Spurassistent fürs Handy). Bitmaps sind nicht so mein Ding. dokumentiere die Tags die es dazu braucht In der Mail vom 1.1.2010 ist das Netzbeispiel mit drin. Eigentlich muss nur 'lanes' richtig gesetzt sein. und ich garantiere dir, in kürzester Zeit wird es einige Autobahnen geben, die derartig gemapped sind. Kann sein, kann auch nicht. Ich habe jetzt erstmal einiges an Arbeit reingesteckt, um diese Methode überhaupt demonstrieren zu können. Weiterentwicklung findet statt, aber berufsbedingt relativ langsam. Grüsse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Open Kataster Map, war Details mappen in Dortmund
Original-Nachricht Datum: Thu, 01 Apr 2010 02:59:54 +0200 Von: André Reichelt andr...@online.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Hallo, Das einfache Modell funktioniert bei der Navigation und bei groben Stadtplänen wunderbar, das habe ich schon gesagt. Spätestens wenn ich aber in die Straßenperspektive wechsle wird dir das Ding um die Ohren fliegen -- und zwar ganz massiv. Das ist mir jetzt zu pauschal und entspricht auch nicht meinen Erfahrungen. Mit ein paar zusaetzlichen Vereinbarungen kann man eine Darstellung bauen, der die Masse der staedtischen Strassen gut abbildet. Es gibt Anwendungen, da interessiert mich, wo genau in der Kreuzung eine Insel liegt und wie groß die ist. Du kannst Dir das vielleicht nicht vorstellen, da Du selbst keine Anwendungen in diese Richtung entwickelst, aber grundsätzlich müssen wir so detailiert wir möglich mappen. Wir dürfen uns nicht auf die Falle einlassen, etwas wegzulassen nur weil wir glauben, dass es gegenwärtig nicht sinnvoll nutzbar ist. Du verwechselst den Detaillierungsgrad mit der Abbildung. Nur weil man derzeit fast nichts aus dem aktuellen Modell rauskitzelt, bedeutet das nicht, dass das nicht geht. Da ist noch sehr viel drin, ohne dass man den ganzen aktuellen Datenbestand auf den Kopf stellt. Leider ist die Ueberhoehung der Breiten bei den OSM-Renderern der Stand der Technik und sie uebernehmen diese Darstellung damit (leider) vom grossen Vorbild Google Maps. Ich spreche mich nicht dagegen aus, dass man moeglichst jedes Detail mappt, aber ich spreche mich dafuer aus, dass man nicht alles mit der Brachialmethode 'dann setze ich eben eine Node mehr rein' loest. Das war auch genau der Grund, weswegen man das bis heute nicht macht. Jetzt stehen allerdings die Luftbilder zur Verfügung, die uns auf ein paar Zentimeter genau erlauben, genau diese Daten zu erfassen. Ist doch OK, dann werden eben endlich mal Breiten und Abrundungsradien konkret erfassbar und koennen interaktiv ermittelt werden. Wir mappen nicht für heute sondern für morgen. Und morgen haben wir dann die OpenKatasterMap :) Gruesse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Thu, 01 Apr 2010 02:52:25 +0200 Von: André Reichelt andr...@online.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Das mag auf Autobahnen fast immer und außerorts gelegentlich gelten, Ich glaube wir leben auf unterschiedlichen Planeten ;) Bitte zeige mir mal die Ausserortsstrassen, deren Breite gar so fuerchterlich staendig schwankt, dass sie nur 'gelegentlich' den Anschein erwecken, parallel zu sein. innerstädtisch wirst Du damit aber in der Regel massiv auf die Schnauze fallen. Abbiegespuren kannst Du mit deiner Methode im Übrigen auch nicht sauber darstellen. Warum? Rinksbuendige Referenz + Spurbreite + Spuranzahl + Uebergangsbeschreibung (z.B. Aufweitung auf 100m Laenge) und das Ding ist sauber beschrieben. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Thu, 1 Apr 2010 13:32:37 +0200 (CEST) Von: Fabian Schmidt fschm...@informatik.uni-leipzig.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Am 01.04.10 schrieb Robert S.: 2010/4/1 qbert biker qbe...@gmx.de Warum? Rinksbuendige Referenz + Spurbreite + Spuranzahl + Uebergangsbeschreibung (z.B. Aufweitung auf 100m Laenge) und das Ding ist sauber beschrieben. Ach, und das soll dann ernsthaft EINFACHER zu erfassen sein als das einfache Nachzeichnen einer Fläche anhand von hochauflösenden Luftbildern? Ja, denn dabei kann man sich von der SW sehr gut unterstuetzen lassen. Man zeichnet die Basislinie ein, zieht sie in die Breite, bis das mit dem Luftbild uebereinstimmt und traegt die Spuranzahl ein. GGf. zieht man das noch ein wenig zurecht. Jetzt Klickt man die Spuren an und parametrisiert sie. Geht ganz sicher schneller und einfacher als jede einzelne Spur und die die Flaeche einzeln Punkt fuer Punkt reinzufummeln. Ja, denn spätestens für turn_restrictions muss ich die Spuren sowieso erfassen, egal ob als eine Linie + Tags oder als mehrere Linien. Also warum soll ich die Fläche zusätzlich erfassen? Turn restrictions funktionieren auch ohne einzeln eingetragene Spuren. Rein technisch ist es moeglich, die Information an eine einzige Basislinie zu haengen und ich halte das auch fuer sinnvoll. Ein Vorteil ist z.B. dass die Breite der Fahrbahn auch wieder direkt ausgelesen werden kann. OSM soll doch eine freie Datensammlung sein - warum kommt jetzt ploetzlich diese Fixierung auf Umrisse? Wenn eine Datenbank abgeleitete Groessen wie eben die Fahrbahnbreite direkt zur Verfuegung stellt, was soll daran falsch sein? Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Thu, 1 Apr 2010 14:55:42 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Hallo, das ist nicht falsch, und sicher wird das auch im überwiegenden Fall so gemacht werden (vor allem ausserhalb der Städte, da gibt es weder Luftbilder, noch Leute oder Bedarf, die Flächen genau zu erfassen, Auf die Gafahr hin, dass ich mich wiederhole. Es geht hier um die Flaechen, die man mittels geometrischer Beschreibung und etwas Rechnerhilfe auch sehr gut und vielleicht sogar besser erfassen kann als mit einem Knotenmeer. Und gerade wenn man Luftbilder hat, kann man die Geometrie nutzen, mehr Information mit weniger Overhead unterzubringen. Die Annahme, dass eine Flaecheneintragung pauschal genauer ist als eine geometrische Beschreibung, ist irrefuehrend. Es kommt auf den Einzelfall an. auch sind die Straßen da fast immer regelmäßig), aber es gibt auch andere Fälle, wo die Leute gerne Flächen hätten, und wo diese auch viele Vorteile bieten. Was hier immer in Raum schwebt ist, dass es hier um zwei Dinge geht, die sich ausschliessen. Die Masse der Strassen ist eben regelmaessig und kann vereinfacht abgebildet werden und fuer den keinen Rest gibts wie auch heute schon (- Plaetze), die Alternativmethode. Im Übrigen ist Flächen zeichnen intuitiver und damit deutlich weniger komplex (und fehleranfällig z.B. auch bei Edits von weniger Erfahrenen) als die Parametrisierung. Weil die Werkzeuge das bisher nicht unterstuetzen. Wenn ich eine Basislinie zeichne und die in die Breite ziehe, ist das auch intuitiv und einfach und ich vermesse in einem Arbeitsgang auch gleich die Breite mit. Das fehleranfaellige haendische Eintragen der Breite entfaellt. Gruesse -- NEU: GMX DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassen als Flaechen
Original-Nachricht Datum: Thu, 01 Apr 2010 15:38:46 +0200 Von: Frederik Ramm frede...@remote.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org CC: m...@koppenhoefer.com Betreff: Re: [Talk-de] Strassen als Flaechen Hallo, qbert biker wrote: Weil die Werkzeuge das bisher nicht unterstuetzen. Wenn ich eine Basislinie zeichne und die in die Breite ziehe, ist das auch intuitiv und einfach und ich vermesse in einem Arbeitsgang auch gleich die Breite mit. Vorausgesetzt, Du hast die Basislinie intuitiv in die Mitte gezeichnet ;-) Vielleicht intuitiv, besser ueberlegt, bzw. konfigurierbar. Bei Luftbildern ist es intuitiv einfacher mit einer der Kanten anzufangen und das dann ueber die Mitte zur anderen Kante rueberzuziehen. Dann stimmt auch die geometrische Mitte ;) Bei rechteckigen Haeusern mache ich das schon ein Weilchen und da klappts das super. Bei Strassen klappt das massstabsgetreue Darstellen schon ganz gut (siehe Link vom 1.1.), aber das Werkzeug zur dynamischen Manipulation fehlt noch. Mal schaun, wenn das Wetter zu Ostern so mies wird wie angesagt... Gruesse Hubert -- NEU: GMX DSL für 19,99 EUR/mtl. und ohne Mindest-Laufzeit! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Wed, 31 Mar 2010 00:07:16 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund nö, das eine hat mit dem anderen nichts zu tun. Wem an einer ansehnlichen Darstellung gelegen ist, der sollte wohl versuchen, die Nodes jeweils auf gleicher Höhe zu setzen, solange es wirklich um parallele Verläufe geht. Also die vielen 'krummen Dinger', die ich bei OSM finde, finde ich in der Realitaet nicht ;). Ansonsten ist das natuerlich auch etwas, was der Fehlerfortpflanzung unterworfen ist, ausser man hat so perfeke Ausgangsdaten, dass man beide Linien an Messdaten oder Bildern ausrichten kann, die eine entsprechende Aufloesung (Hausnummer: unter einem Meter) erlauben. Änderungen in der Bauausführung im Vergleich zur Planung sind nicht in erster Linie Fehler des Bauarbeiters sondern Reaktionen auf Unvorhergesehenes, Änderungen aufgrund zwischenzeitlich geänderter Anforderungen, sonstiger (z.B. gesetzlicher) Grundlagen und Einschätzungen, Reaktionen auf Widerstände (z.B. von Anwohnern), etc. Oder eben Pixelfehler, die zu angenommenen Abweichungen fuehren oder, eher der Normalfall, kleine Aussetzer im Auge des Mappers. Ich habe lange genug die Richtungsfahrbahnen der Autobahnen als Doppellinie gesetzt, um Erfahrungen darin zu haben... Interessant sind ja gerade die Stellen, wo es zu Reibungen kam, oder z.B. auf unterirdisch verlaufende Leitungen reagiert wurde, etc., nicht die, die glatt durchgezogen werden konnten. Diese Vorgänge sind so komplex dass wir mit unserem Ansatz, iterativ diese Details aufzunehmen, besser fahren als mit der Idee, von der Planung über die Realisierung die Wirklichkeit parametrisch nachbauen zu wollen. Aus eigener Erfahrung kann ich sagen, dass von dieser gefuehlten Genauigkeit wenig uebrig bleibt, wenn man da mal richtig nachmisst. So ein Klassiker ist z.B. die Zeitmessung im Skisport. Da haben mal teusendstel Sekunden ueber Sieg und Niederlage entschieden, bis sich jemand mal den Ausloeser am Start vorgenommen- und rausgefunden hat, dass der technisch nur Hunderstel aufloest ;) Derzeit wird bei Strassen eh nur eine gefuehle Mittellinie eingetragen, schon das ist eine Fehlerquelle. Ich kenne jetzt auch keine Moeglichkeit, eingetragene Spuranzahlen und Breiten ueberhaupt zu verifizieren. Wie schon geschrieben, hatte ich mich mal an dem besagten Kreuz ausgetobt und Breitendaten aktiv zur besseren Anpassung an die Realitaet genutzt und ich finde das Ergebnis bildet die Flaechen schon ganz gut ab. Gruesse Hubert -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Wed, 31 Mar 2010 13:23:02 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund wobei ein Autobahnkreuz auch nicht der Anwendungsfall ist, der mir vor Augen schwebt. Da kommt es prinzipiell auf 10 m mehr oder weniger überhaupt nicht an (wahrscheinlich nicht mal auf 30 m oder 50 m). Wie locker flockig da mal 50m hin oder her egal sind ;) Eigentlich waers schoen, wenn es eine groessere Entkopplung von Detailschaerfe und persoenlichen Praeferenzen gaebe. Bei 50m daneben ortet einen das GPS gerne mal auf den Feldweg daneben, nur so nebenbei. Aber schon bei 10 oder 20m daneben sieht einiges ziemich eigenartig aus, z.B. wenn sich die Fahrbahnen bei massstabsgerechter (Breiten-)Darstellung wie wild ueberlappen oder Waypoints von Zufahrten mitten auf der Hauptfahrbahn liegen. Interessant sind die Flächen doch in Gegenden wie hier: So spannend finde ich diese Ecken jetzt auch wieder nicht. Die grossen Abweichungen arbeitet man dann mittels expliziter Flaeche ein und bindet die an die Breite der Normalfahrbahn an. Eigentlich kein Hexenwerk. Mal konkret: An welche Anwendung denkst du, wenn du diese Flaechen besser abgebildet haben willst? Gruesse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund
Original-Nachricht Datum: Wed, 31 Mar 2010 15:45:32 +0200 Von: Wolfgang o...@kahl-hinsch.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund Hallo, hier nochmal das Beispiel (vielleicht war es schon zu spät am Abend... :-) ) xx k r\ bb k \ -r k \/ \ ppp / / x = normale Fahrbahn r = Rechtsabbiegespur b = Busspur, überqueren nicht erlaubt p = Parkplätze k = Kreuzung Der Bereich direkt vor der Kreuzung ist eine zusammenhängende Verkehrsfläche, aber aufgrund der Busspur darf man nur vor den Parkplätzen auf die Spur r wechseln. An der Kreuzung darf von x aus nicht und von r aus nur rechts abgebogen werden. Im Bereich der Parkplätze sind x und r baulich getrennt. OK, dann hatte ich das schon richtig verstanden. Klar, das kann man. Aber, vielleicht fehlt mir hier eine Info, woher weiß die Routing-Routine, dass zum Rechtsabbiegen über den Parkplatz, für die übrigen Richtungen aber am Parkplatz vorbei geroutet werden muss? Der Klartext reicht dazu wohl kaum aus, und das Zusammenführen der Fahrbahn vor der Kreuzung lässt der Routing-Routine wieder die (falsche) freie Auswahl. Auch wenn die nicht wieder zusammengefuehrt sind, kann die Kuerzestwegsuche nichts damit anfangen, ausser man trickst sie aus und macht den Weg fuer Rechtsabbieger kuerzer, indem man die Node ein wenig verschiebt. Eine einfache Routingengine weiss ja nichts vom Rechtsabbiegen. Wenn die Rechtsabbiegerspur einen Bogen macht und dadurch laenger wird, wird sie unattraktiver und Normal- und Rechtsabbiegerspur sind ja wieder mit der Querstrasse verknuepft und somit beide eine Option. | ---x | ---| |---x |---|| \/ Eine Wertung fuer Abbiegevorgaenge ist prinzipiell moeglich, allerdings weiss ich nicht, ob eine der hiesigen Engines sowas eingebaut hat. Dazu nochmal das klassische Gegenbeispiel, bei dem die Linienbuendel nicht wirklich gut funktionieren: Die Doppellinie, die nur von einer Spur zur anderen gequert werden kann. Das laesst sich auf den Graphen nicht abbilden. Mit dem Modell der Wayparts http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts ginge es, wenn man ein Tag festlegt, dass den Divider nicht nur crossable, sondern z.B. outside- crossable (von der beschreibenden Spur weg) bezeichnet. Das ist dann auf die Wayparts abgebildet, aber der Graph ist gnadenlos und interessiert sich nur wenig dafuer. Die Kuerzestwegsuche ueber den Graphen kennt keine Links, ueber deren Laenge ein Austausch, egal ob in eine oder in beide Richtungen, passieren kann. Man kann natuerlich nach belieben Knoten einfuegen und die Lanes mit Einbahnen verbinden, aber das ist auesserst unschoen. In etwa fuer zwei ways einer Fahrbahn mit einseitiger Wechselmoeglichkeit: x---x--x ^ ^ ^ | | | x---x--x Das alles, nur um das einseitige Wechseln der Spur im Graphen annaeherungsweise abzubilden. Ein Netzoptimierer, der erkennt, dass das Spuren sind wird das aber wohl wieder rausschmeissen, denn jeder Knoten erhoeht den Rechen- und Zeitaufwand der Suche (linear). aber welche? Ich kann die Busspur, die baulich nicht getrennt ist, nicht weiter beschreiben, ohne dabei auf Relationen auszuweichen, die nicht allgemein unterstützt werden. Damit fehlt mir für das Straßenstück von der Wiedervereinigung der baulich getrennten Fahrspuren bis zur Kreuzung der nicht überquerbare Trenner, eben die Busspur. Meine ganz persoenliche meinung dazu: Lieber Elemente verwenden, die noch nicht allgemein ueblich sind, als zu versuchen, den Router auszutricksen, was nur funktioniert, wenn man den Funktionsmechanismus des Routers wirklich gut versteht. Genau das würde ich ja gerne machen, aber wie? Dafür muss es ein Muster geben, wie diese Zusatzinformation automatisch bei den Informationssystemen ankommen soll. Die klassische OSM-Antwort darauf ist: Einfach loslegen und machen, wenn sich auf der Liste keiner findet, der da naeheres dazu weiss. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund
Original-Nachricht Datum: Wed, 31 Mar 2010 17:01:37 +0200 Von: qbert biker qbe...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund Kleine Korrektur: | ---x - Turn restriction | ---| |---x |---|| \/ OK, leasst man sie getrennt, kann man eine turn-restriction einbauen, fuer Rechtsabbieger Das laesst sich aber auch mit einem Datensatz loesen, der die Daten eines Links aufnimmt. Ist ja ein haeufiger Fall: Z.B. Spur 1 ist Rechtsabbieger 2 Gradeaus und 3 Linksabbieger. Gruesse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Attraktivitaetsbezogenes Routen, war Re: Routen ueber Flaechen
Original-Nachricht Datum: Tue, 30 Mar 2010 02:04:46 +0200 Von: Martin Simon grenzde...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Routen ueber Flaechen Ich dachte auch daran, nur einzelne Objekte, die Verkehrsflächen sind, einer solchen Behandlung zu unterziehen und die Ergebnisse dann in den Graphen einfließen zu lassen - der dadurch ja nicht komplizierer wird, wenn auch etwas größer. ;-) Wenn ich also 1000x highway=* area=yes habe, mache ich diese kompakte Betrachtung nur 1000x, ohne Kenntnis vom gesamten Verkehrsnetz zu haben und baue dann mit den gewonnenen Erkenntnissen den Graphen. OK, ich denke, jetzt hab ichs auch. Aber ich sehe da durchaus eine Option, das ein wenig groesser anzugehen. Manche verkehrsberuhigte Innenstadt ist fuer einen Fussgaenger eher eine Flaeche mit Hausinseln als ein restriktives Wegenetz. Ich kann mir vorstellen, den Rasteransatz fuer so einen Bereich als ganzes anzuwenden. Die Vorschlaege kommen also nicht mehr von einem streng begrenzten Vektor, sondern ich schaue mir die Attraktivitaet der Kacheln um mich herum an und lasse mich in der Flaeche routen. Muss sagen, die Idee hat was :) Ich nenn das mal 'attraktivitaetsgesteuertes Routen' so als Kontrast zum restriktionsgesteuerten Routen. Ich kann mir vorstellen, dass das bei Aufgaben wie einen Innenstadtbummel zu unterstuetzen, deutlich flexibler zu handhaben ist. Oder wenn sich eine Gruppe mittels Smartphone organisiert. Danke fuer die interessante Idee und Gruesse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund
Original-Nachricht Datum: Mon, 29 Mar 2010 22:56:52 +0200 Von: Wolfgang o...@kahl-hinsch.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund Hallo, Nach örtlicher Beschilderung und Verkehrsregeln muss der Fahrer über die extra-Fahrbahn fahren, wenn er rechts abbiegen will. Um richtig geroutet zu werden, darf die Fahrbahn also wirklichkeitswidrig nicht wieder vereint werden. Das habe ich damit gemeint, dass viele Konflikte gar keine sind. Natuerlich darf die Fahrbahn wieder vereint werden und das sollte man auch tun, wenn es in der Realitaet so aussieht. Was du ansprichst, ist Fahrerinformation, und das ist eine Zusatzinfo. Wenn vor dem Komplex ein Schild steht, dass man sich als Rechtsabbieger auf der Sonderspur einordnen soll, kann man das auch im Klartext, z.B. an einer Node hinterlegen. Warum soll man die Realtiaet verzerren, Informationen verlieren (dass es sich um eine durchgehende Fahrbahn handelt), nur damit der Router versuchen darf, aus indirekt gegebener Info eine Nachricht zum Einordnen zu generieren? Dazu nochmal das klassische Gegenbeispiel, bei dem die Linienbuendel nicht wirklich gut funktionieren: Die Doppellinie, die nur von einer Spur zur anderen gequert werden kann. Das laesst sich auf den Graphen nicht abbilden. In deinem Fall wird man die baulich getrennte Spur als eigenen Way eintragen und bei der Busspur wuerden Attribute helfen, die die Beziehung der Spuren untereinander klaeren, bzw., dass es fuer eine der Spuren eine Nutzungsbeschraenkung gibt. Es ist mit den bisherigen Werkzeugen nicht möglich, diese Ecke richtig für Router und Karten zu mappen. Das sehe ich wie oben schon geschrieben nicht so. Fuer die Kuerzestwegsuche genuegt ein Link bis zur Kreuzung. Zusatzinformationen hinterlegt man am besten explizit und direkt fuer das Informationssystem (das die Route auswertet) lesbar. Vielen scheint das Routing im Moment der wichtigste Aspekt für OSM zu sein. Wirklich? Ich sehe da die Renderer mit ihren Rasterkarten noch weit vorne. Das Problem ist, dass man Fehler in den Rasterkarten sofort sieht, aber die Routingqualitaet ein sehr abstrakter Wert ist. Es ist eher eine sehr aktive Minderheit, die sich das Routing zu Herzen nimmt und der es wichtig ist, dass es bei den wichtigeren Entscheidungen mit eine Rolle spielt. Gruesse Hubert -- GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern E-Mail, SMS mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Original-Nachricht Datum: Thu, 25 Mar 2010 00:03:16 +0100 Von: olvagor o...@terbrueggen.net An: Frank newslet...@fotodrachen.de, Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Hallo, Man kann ganz andere Auswertungen fahren. Z.B. gibt es immer mal wieder Zeitungsberichte, dass die Umwelt darunter leidet, dass zuviel städtische Fläche versiegelt ist. Saubere Daten dazu bekommst du aber nur, wenn die Flächen auch wirklich erfasst sind. Linien mit width=x sind eine Annäherung aber bilden nicht die Realität in dem Maße ab, den ich mir vielleicht wünsche. Die Frage ist, ob es wirklich eine Verbesserung der Darstellung ist. Ich frage mich z.B. bei diesen Diskussionen immer, warum keiner Kreissegmente fordert, denn einen Bogen in einzelne Segmente aufzuloesen, ist auch ungenau. Diese Ungenauigkeit wird jetzt noch verstaerkt, wenn man versucht, per Hand eine parallele Linie zu setzen. Strassen sind ja menschengemacht und die wurden mal konstruiert. Natuerlich kann man das ignorieren und Fehler der Bauarbeiters und Pixelfehler vermessen, aber ist die Flaeche dann wirklich genauer wiedergegeben? Das Routing funktioniert meines Erachtens eben noch nicht zuverlässig. Auf aktuellen OSM-Daten ist es meines Wissens momentan nicht möglich, Abbiegeinformatinonen zu bieten, wie sie mein Garmin-Navi seit Jahren möglich macht: Halten Sie sich rechts Richtung Karlsruhe und dann links. Das bedingt allein schon das Erfassen mehrerer Fahrspuren und ihrer Beziehung untereinander. Um mehrere Spuren zusammenzufassen böten sich Flächen einfach an. Dazu ein Experiment, das ich Anfang des Jahres mal gemacht habe. Hier ist ein Grossteil der Geometrie eines Kreuzes bis hinunter zu den Fahrspuren (aber noch keine Spurverengungen) abgebildet. http://lists.openstreetmap.org/pipermail/talk-de/2010-January/060852.html Jeder Punkt der hier dargestellt ist, ist eine reelle Geokoordinate, auch die Strichellinien als Spurentrenner. Die Parallelverschiebung passiert also direkt mit den Geokoordinaten und erst dann wird das fuer den Bildschirm skaliert. Trotzdem unterlasse ich es, diese Koordianten der parallel verschobenen Linien in den Datenbank zu schreiben, denn sie sind redundant, da aus den Daten jederzeit zu ermitteln. Das was ich hier gemacht habe, hat allerdings einen Haken, muss ich zugeben. Bei Autobahnen/Schnellstrassen gehe ich von der Linksbuedigkeit aus, also dass sich der Way auf den linken Rand bezieht und nicht auf die Mitte. Nur so kann man den schmalen Streifen, der die Richtungen trennt genau genug abbilden, so meine Erfahrungen. Hat niemand verlangt. Das Routing soll ruhig weiterhin auf Linien laufen. Mal andersrum: Wenn ich mit etwas Parallelverschiebung eine so gute Annaeherung erreiche, warum nehme ich dann nicht Linien als Basis fuer Flaechen? Ich habe den Eindruck, dass wir derzeit einen Deadlock haben, der verhindert, dass Spuren und Breiten effizient genutzt werden. Nicht zwangsläufig. Wie ich oben geschrieben habe, würde ich nicht alle Informationen als Linie _und_ als Fläche erfassen. Ich würde routingrelevante Infos (Spuren) als Linie taggen und andere Dinge (Name der Straße) als Fläche. Gegenvorschlag: Man nutze mal Spuranzahl und Breite nach allen Regeln der Kunst und schaut dann mal, wie nah man an das Original rankommt, ohne gleich doppelt einzutragen. Bei grossen Abweichungen vom Normal (Parallelitaet) ist die konkrete Flaeche eine gute Ergaenzung, aber macht es wirklich Sinn, jetzt auf Tausenden von km Autobahn jede Spur nochmal haendisch zu ergaenzen? Das bedeutet aber immer, dass da ein Mensch (oder eine KI) hocken muss, die die Daten interpretiert. Wenn ich als Mapper die Bilder bereits abstrahiert und mit maschinenlesbaren Daten versehen habe, habe ich einen Mehrwert. Natürlich kann ich aus den tatsächlichen Fotos oft noch zusätzliche Informationen gewinnen. Wo willst du die Grenze setzen, ob Daten sinnvoll sind oder nicht. Anhand einer Fehlerbetrachtung. Nur wenn die handgemalte Flaeche die Situation genauer darstellt als ihre geometrische Beschreibung, macht der Zusatzaufwand Sinn. Gruesse Hubert -- GMX.at - Österreichs FreeMail-Dienst mit über 2 Mio Mitgliedern E-Mail, SMS mehr! Kostenlos: http://portal.gmx.net/de/go/atfreemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routen ueber Flaechen
Original-Nachricht Datum: Fri, 26 Mar 2010 19:46:21 +0100 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Am Freitag 26 März 2010 14:14:31 schrieb Michael Buege: Geht eigentlich Fussgaengerrouting ueber Fussgaengerzonen als Flaeche, wenn die entsprechenden Wege nicht mit eingezeichnet sind? Flächen im Sinne von highway=pedestrian / area=yes werden von den mir bekannten Routern in der Regel als Weg an der Außenkante behandelt und das Routing leitet einen dann an der Außenkante entlang. Was natuerlich eine Kruecke ist, so wie jede Behandlung von Flaechen in einem graphenbasierten Router eine Kruecke ist. Das Problem geht ja schon damit an, dass das Ziel des Routens nur in einer restriktiven Umgebung Sinn macht. Also umso zugeregelter eine Einbahnwueste ist, desto mehr Hilfestellung brauche ich. Auch der gruenen Wiese gehe ich einfach direkt von Punkt A nach Punkt B. Wie man nun mit einem Platz umgeht, ist mehr oder weniger Geschmackssache, denn es muss ja nicht immer der kuerzeste Weg ueber den Platz der sein, den der Nutzer haben will. Die Umrandung des Platzes als Verbindung in den Graphen aufzunehmen, bietet sich als Kompromiss an. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Breite als Attribut, war Details mappen in Dortmund
Original-Nachricht Datum: Fri, 26 Mar 2010 15:16:35 +0100 Von: Chris-Hein Lunkhusen chris66...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Details mappen in Dortmund Für mich persönlich sind routingfähige Karten das wichtigste Produkt für OSM, deshalb bekomme ich immer Bauchschmerzen wenn ich diese Vermischung von Fläche und Vektor sehe. Besonders, weil es meiner Ansicht nach auch keinen echten Konflikt gibt. Die Masse aller Strassen hat eine ueber lange Strecken unveraenderliche Breite. Diese vielleicht 99% aller Strassen sind mit einer definierten Linie und der Breite doch exakter beschrieben als man das je mittels der Editoren reinmalen koennte. Bevor man sich jede Menge Redundanz und potentielle Fehlerquellen in die Datenbank holt, sollte man vielleicht doch ueberdenken, ob mehr Punkte wirklich immer mehr oder bessere Information bedeuten. Ein paar eindeutige Definitionen koennten viele Konflikte loesen, so wie der Wiese, die an die Strasse heranreicht. Wenn definiert ist, wie sich die Wiese zu der Mittellinie der Strasse verhaelt, kann man diese Mittellinie auch mehrfach nutzen, also z.B.: Wenn eine Flaeche eine Strasse als Abgrenzung nutzt, ist die Breite der Strasse zu beachten und die Flaechengrenze der Wiese entsprechend parallel zu verschieben. Programme (z.B. Renderer) koennen das dann in ihre Abbildung einbauen. Es gibt eigentlich wenige wirkliche Konflikte zwischen genauer Darstellung und Graphenabstraktion. Die meisten sind hausgemacht. Gruesse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routen ueber Flaechen
Original-Nachricht Datum: Mon, 29 Mar 2010 18:13:12 +0200 Von: Martin Simon grenzde...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Routen ueber Flaechen Am 29. März 2010 16:41 schrieb qbert biker qbe...@gmx.de: Was natuerlich eine Kruecke ist, so wie jede Behandlung von Flaechen in einem graphenbasierten Router eine Kruecke ist. Kann man nicht einfach beim bauen des Graphen die kleinstmögliche Länge[1] der Verbindungen zwischen jeweils 2 einmündenden Wegen berechnen und diese dann als Grundlage der Berechnung der Kosten für einen Geisterweg benutzen? Kann man, kenne ich z.B. auch von Kreuzungen, wenn man die Kosten der Abbiegemöglichkeiten bewerten will. Das gibt dann eine Matrix von virtuellen Verbindungen. Bei einem Platz kann man die Matrix typischerweise stark vereinfachen, denn die Wege zu den benachbarten Einfahrten liegen näherungsweise auf dem Umfang. Bei einem rechteckigen Platz mit Zufahrten an den Ecken bleiben dann noch die Diagonalen übrig. Trotzdem würde ich es bei einem eigenen Programm nicht so machen (und laut der Aussage oben machen das die anderen auch nicht), denn die Verarbeitung wird eines marginalen Vorteils willen deutlich komplexer. Ausserdem ist der Weg quer drüber nicht immer der, den man nimmt. Der Fussgänger hat ja die absolute Freiheit, ob er lieber am Rand entlang läuft, um z.B. in die Schaufenster zu sehen. Bei exotischen Formen gibts immer noch die Möglichkeit, bei günstigen Verbindungen einen expliziten Fussweg zu ergänzen und grössere Plätze sind meistens sowieso strukturiert. [1] Das kann doch kein so großes Problem sein, auch bei komplexen Flächen, wenn in Egoshootern schon seit ~15 Jahren Bots zuverlässig ihren Weg durch komplexe Labyrinthe finden, oder? hmm, Quake(gpl) als Teil eines Routers für OSM... ;-) Wie komplex sind die Labyrinthe der Spiele im Vergleich zu OSM? Und wenn ich das richtig in Erinnerung haben, sind diese Labyrinthe primär nicht graphenbasiert, sondern matrixbasiert. Gruesse Hubert -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routen ueber Flaechen
Original-Nachricht Datum: Mon, 29 Mar 2010 21:35:25 +0200 Von: Martin Simon grenzde...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Routen ueber Flaechen Ah ok, also benutzt man nicht wirkliche zusätzliche Wege, sondern bewertet nur die Kosten individuell. Aus Sicht des Graphen sind es schon echte Wege. Allerdings ist der Routensuche die physische Gestalt des Weges egal. Bewertet wird nur eine Zahl, die im einfachsten Fall die Länge ist. Ja, aber routing will ja auch nur den optimalen Weg finden - was man draus macht, bleibt ja jedem selbst überlassen... Bei der Form von Routing, über die hier immer geschrieben wird, ist die Umgebung sehr restriktiv. Ich darf mit dem Fz. die Strasse nicht einfach verlassen, auch wenn ich es könnte. Diese Regeln bildet der Algorithmus mit Hilfe der Graphentheorie ab. Auf den Fussgänger, der sich relativ frei bewegen kann, lässt sich das schwer übertragen. Das beste Kriterium ist noch der kürzeste Weg, aber der weicht auch nicht dramatisch ab, wenn ich um einen Platz rumgehe, statt mittendurch. Im Stadtszenario gehts ja eher darum, Durchgänge zu finden, die nicht direkt ersichtlich sind. Oder eben andersrum - Durchgänge zu identifizieren, due ich nicht benutzen kann, z.B. als Rollstuhlfahrer. Ja, aber das wäre ja eine Krücke, die sich eines Objektes bedient, das es nicht gibt. Der entsteht doch schnell von selber, wenn eine Abkürzung attraktiv ist, z.B. in Form von Trampelpfaden. Na ja, man müsste die Plätze ja nur einzeln analysieren, um sie durch Geisterwege für den Graphen zu ersetzen... also einfach die Geometrie betrachten und prüfen, ob eine Verbindung als gerade Linie zulässig ist - wenn nicht, diese durch einfügen zusätzlicher Punkte so lange modifizieren, bis sie an keiner Stelle mehr außerhalb der Fläche läuft oder innerhalb eines Hindernisses. Siehe oben, die Frage ist, mit was man auf das Fussgängerrouting raus will. Die Randmethode ist ja nicht so schlecht und die betrifft ja nur die Kürzestwegsuche. Beim Auswerten, also dem Abgehen der gefundenen Route kann man immer noch Informationen geben wie 'Überqueren sie den Platz xy'. Wie das mit der Wegfindung in Computerspielen genau funktioniert, weiß ich nicht, ich kann auch keine 5 Zeilen Code schreiben, ohne daß jemand die Hände überm Kopf zusammenschlägt ;-) - das sind also nur die Gedanken eines absoluten Laien... Die klassische Methode ist die Definition eines Spielfelds wie ein Schachbrett und man definiert die Übergänge von jedem Feld zum anderen. Ausgehend von der eigenen Position sind dann für jede Figur die Bewegungsmöglichkeiten definiert. Das Geschehen in einem Spiel ist ja ziemlich kompakt. In einem realen Verkehrsnetz ist das anders. Grüsse Hubert -- GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele Fehler in Haiti
Original-Nachricht Datum: Tue, 26 Jan 2010 19:46:32 +0100 Von: Stefan Schwan stefan.sch...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Viele Fehler in Haiti Der Grundgedanke ist, dass OSM Geodaten sammeln und frei zur Verfügung stellen möchte. Ja, soweit OK. Ein anderer Grundgedanke ist, dass sich die Sache von alleine steuern muss. Das wird von der endlosen Wiederholung auch nicht richtiger. Das ist kein Grundgedanke, sondern eine Entwicklung, die vor ein paar Jahren andere Positionen verdraengt hat. Du tust so, als könnte man Mapper (in Haiti, oder sonstwo) irgendwie in eine bestimmte Richtung, sei es hin zu bestimmten Qualitätsstandards oder Schwerpunkten beim Mappen, steuern.Es gibt keine Steuerung, keine Mindeststandards. Natuerlich gibts eine Steuerung, auch wenn die unterschwellig passiert. Diese Steuerung hat vor ein paar Jahren die Parole ausgegeben, dass man vorerst alles einfach halten muss, weil Entwickler fehlen und solange es weisse Flaechen gibt Masse wichtiger ist als Klasse. Und spaeter hat diese Steuerung eben die Parole ausgegeben, dass es jetzt so viele Daten und Mapper gibt, dass man nichts mehr aendern kann und hat die Entscheidung von vorgestern zum Grundprinzip erklaert. Die Diskussion Warum malen wir nicht die freien Flächen zu? Werden unter anderem deswegen gefuehrt, weil man nie ein Layerkonzept eingefuehrt hat. Jetzt versucht man verzweifelt, mit Daten auszukommen, die historisches und aktuelles, Wege und Flaechen, temporeaeres und statisches, usw. zu einem gigantischen Knotensalat verwurschteln. Selbst etwas so einfaches wie 'zeige mir alle Wege an und blende Wiesen und Waelder aus', ist bei OSM alles andere als trivial. Aber Minimalstandards waeren ja der Untergang von OSM... Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie sicher ist Openstreetmap vor Ausbeutung?
Original-Nachricht Datum: Mon, 25 Jan 2010 13:53:18 +0100 Von: Jonas Stein n...@jonasstein.de An: talk-de@openstreetmap.org Betreff: [Talk-de] Wie sicher ist Openstreetmap vor Ausbeutung? Welche Abhaengigkeiten bestehen? Falls Stadtplandienst die OSM Server kauft, koennte eine neue Gruppe den letzten Datenstand auf eigene Server hochladen und weiter machen? Soweit es das Worldfile betrifft, ist die Sache einfach zu beantworten. Alle Daten, die da drin sind, koennen fuer einen Neustart auf einem beliebigen Server an beliebigen Ort verwendet werden. Spannender wirds bei den ganzen Changeset-Sachen, die immer wichtiger werden. Das wuerde mich auch interessieren, inwieweit da Daten verlorengehen, wenn alle DB-Server mit allen Backups verloren gehen wuerden. Welches Interesse haben die Betreiber und Sponsoren an dem Projekt? Ich fand dazu bislang noch keine Antwort, auch bei der letzten Mapping-Party war das den Teilnehmern nicht ganz klar. Bei Geofabrik und Cloudmade sollte das Interesse klar sein. Wenn die ein Geschaeftsmodell haben, muesste die Antwort da drin stehen. Denke mal, die ziehen Projekte rund um OSM-Daten an Land mit denen sie die Loehne der Mitarbeiter bezahlen. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gratisnavi von Nokia
Original-Nachricht Datum: Thu, 21 Jan 2010 16:10:04 +0100 Von: DarkAngel darkan...@ms-team.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: [Talk-de] Gratisnavi von Nokia Nokia bietet seine Navilösung Ovi-Karten ab sofort (für ausgewählte Handys) kostenlos an. In Kürze soll der Dienst dann für alle Symbian60 Handys verfügbar sein. Im Gegensatz zu früher ist damit auch die Navigation kostenlos und die Karten lassen sich im Gegensatz zu Google bereits vorher am PC herunterladen und auf dem Handy speichern. Somit ist unterwegs keine Datenverbindung erforderlich. http://www.focus.de/digital/handy/gratis-navigation-nokia-eroeffnet-den-kartenkrieg_aid_472846.html http://www.nokia.de/ovi-dienste-und-apps/ovi-karten/home Möglicherweise ist dies aber nicht nur als Schritt gegen Google gedacht, sondern auch eine Reaktion auf OSM. Gibts denn ein Massenprodukt, das auf OSM aufsetzt? Wenn nicht, waere es ziemlich dumm von Nokia, auf die Einnahmen gerade jetzt wegen OSM zu verzichten. Im Gegenzug muss sich NOKIA gegen Google positionieren, das mit Android und dessen Online-Navi maechtig aufgetrumpft hat. NOKIA ist ein weltweit agierendes Unternehmen und da stellt sich die Frage, wie gut die OSM Abdeckung in Europa und ganz besonders in Asien ist, denn da verkauft NOKIA nicht schlecht. Gibts dazu eine Statistik? Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gartenzwerge im OSM-Land, war Aufruf
Original-Nachricht Datum: Sat, 16 Jan 2010 13:00:54 +0100 Von: Sven Sommerkamp s_sommerk...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Gartenzwerge im OSM-Land, war Aufruf Aber damit das anders laufen könnte bräuchte es andere Strukturen bei OSM.. Das waere wieder mal ein Thema zum totdiskutieren. Es ist wie es ist und Gartenzwerge sind den meisten eben wichtiger als Autobahnen ;) Oder vielleicht ein zweites in dem man einen Gegenvorschlag für allgemeine Verfahrensweisen macht. Noe, kein zweites OSM, aber es gibt freilich schon Moeglichkeiten. Ich habe schon angefangen, andere Verfahrensweisen und Werkzeuge zu entwicklen, die OSM nutzen, ohne dessen Begrenzungen abzubekommen. Ein Zwischenergebnis davon habe ich am 1. Januar, siehe 'spurgenaue Abbildung' veroeffentlicht. Das ist allerdings nur ein Zwischenschritt. Das mittelfristige Ziel ist Konstruktionen als solche abzubilden mit ihren Parallelen, Symmetrien und anderen Eigenschaften. Dieses (Arbeits-)format kann dann auch nach OSM exportiert werden, wobei die internen Konstruktionsdaten natuerlich verloren gehen. Die neuen Werkzeuge sind also keine Konkurrenz zur OSM-Welt, sondern eine Parallelwelt mit Verbindungen zu OSM. Wenn ich z.B. einen Router mit Spurassistenz will, man sich aber bei OSM nicht auf entsprechend genaue Abbildungen eingen kann, erstelle ich die Autobahnen teilweise neu und binde ansonsten das bestehende OSM-Datenmaterial ein. Ein weiteres Problem, das ich mit dieser Vorgehensweise erschlage ist das leidige Lizenzproblem. Alle von mir mit den neuen Tools erstellten Daten sind lizenztechnisch von OSM unabhaengig. Erst mit dem Einbinden der OSM Daten zu einem Gesamtdatensatz greift die jeweilige OSM-Lizenz. Die Ursprungsdaten kann ich auch unter einer BSD-Lizenz vertreiben. Gruesse Hubert Ach ja, wenn es bei den Werkzeugen entsprechende Fortschritte gibt, werde ich die hier melden. Derzeit sind die noch nicht so weit, dass eine Veroeffentlichung viel Sinn macht. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gartenzwerge im OSM-Land, war Aufruf
Hallo zusammen, letztens hat mal jemand die OSM-Gemeinde mit einem Kleingartenverein verglichen, in dem jeder die schoenste Parzelle haben will. Kleiner Nebeneffekt dieses Parzellendenkens ist dann auch oft, dass sich der Blick aufs Ganze eintruebt und der Gartenzwerg auf der eigenen Parzelle zum Zentrum des Universums wird. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed=DE:Urban
Original-Nachricht Datum: Thu, 07 Jan 2010 23:13:59 +0100 Von: Tobias Knerr o...@tobias-knerr.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] maxspeed=DE:Urban qbert biker schrieb: Ich glaube, du hast das Problem nicht ganz getroffen. Die *Realität* ist dreidimensional, und wenn in der Realität die Straße auf einer Brücke zu einer anderen Zone gehört als die Straße unten drunter, dann kann man das nur mit zweidimensionalen Polygonen nicht abbilden. Das Modell ist ausschlaggebend, der Rest ist Definition, wie man bei Polygonen drin und draussen definiert, z.B. waybasiert oder knotenbasiert. Damit kann man entsprechende Schlaufen ziehen, was zwar nicht elegant ist, aber technisch realisierbar. Etwas einfacher ists natuerlich, wenn man eine Relation baut, die das Polygon mit dem Exotenelement verbindet. Wenn diese Exotenkonstruktion ueberhaupt mal vorkommt, die Masse der Polygone ist problemlos definierbar. Was voraussetzt, dass zumindest beim Vorverarbeitungsschritt eben doch alle Daten zur Verfügung standen. Lösbar, aber eine kleine zusätzliche Auflage. Eben, ich wende mich an dieser Stelle nur gegen ein plumpes geht nicht. Ob man es macht und obs Vorteile bringt, ist etwas anderes, aber die genannten Punkte sind alle technisch loesbar. Ok, wir messen anscheinend den Aufwand unterschiedlich. Anwendungsentwickler gegenueber Tagger? Meine Betrachtung bezog sich hier auf eine Fehler in den Daten werden in den Daten gefixt, nicht von mir-Software. Wenn du dich natürlich noch für das Erraten von Fehlern zuständig fühlst, werden Tags in der Tat aufwendiger. Das halte ich aber nicht für die Aufgabe der meisten Datennutzer. Als Anwendungsentwickler gehe ich prinzipiell von fehlerhaften Daten aus und versuche stabile Verfahren zu bauen, die den Fehlereffekt von sich aus begrenzen. Kleines Beispiel: Ein potentielles Polygon umfasst 100 ways. Die wiederum sind auf 10 verschiedene Arten Limit-getaggt und bei einem ist der Schreibfehler passiert und es steht statt 30km/h 300km/h drin. 2km mit 300kmh statt 30 koennen das Routingergebnis ganz schoen verziehen. Oder mir gehen 10 Strassen mit 30 durch die Lappen, weil wieder mal jemand eine neue Schreibweise eingefuehrt hat und die gehen auf den Default 100kmh oder 50kmh zurueck. Die 50kmh kommen schon aus der Fehlerbegrenzung, wenn man den Default fuer residential so setzt. Wird innerorts unclassified verwendet (nicht verboten) und ich habe kein Polygon, wird 100kmh draus. Da werte ich lieber Ortsgrenzen aus und begrenze den moeglichen Fehler. Wenn ich also einen Router baue und den einem Nicht-OSMler zumuten will (also einer, der das Ding einfach benutzen will ohne Fehler zu berichtigen) werde ich versuchen, diese Dinge zu stabilisieren, weil ich OSM und die Taggingkreativitaet der OSMler kenne. Ein Polygon ist sehr stabil, weil es algorithmisch ausgewertet werden kann und visuell sehr einfach zu testen ist. Einen Algo zu bauen, der alle in OSM verwendeten Schreibweisen, Trenner usw. zu 100% auseinanderdroeselt, ist da schon ein anderes Kaliber. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed=DE:Urban
Original-Nachricht Datum: Fri, 8 Jan 2010 13:28:07 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] maxspeed=DE:Urban Du solltest nicht die Höchstgeschwindigkeit als Durchschnittsgeschwindigkeit annehmen. Wenn ich jetzt maxspeed=12346743245 km/h tagge, bin ich dann mit Deinem Router in Sekundenbruchteilen diese Straße komplett abgefahren? ;-) Erwischt :-) So und jetzt die technische Antwort: Der Router machts genau so, solange ich ihm den Wert einfach durchreiche. Dass man vorfiltern sollte und nicht blind den Werten vertrauen, darum gings ja. Wenn ich jetzt von 12346743245kmh 20% abziehe um von max auf real zu kommen, ists immer noch viel. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed=DE:Urban
Original-Nachricht Datum: Fri, 8 Jan 2010 14:27:00 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: qbert biker qbe...@gmx.de CC: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] maxspeed=DE:Urban Am 8. Januar 2010 14:15 schrieb qbert biker qbe...@gmx.de: Hallo, eben. Deshalb sollte man als Router einen Default annehmen (z.B. 80 auf Landstraßen, 110 auf der Autobahn), bzw. den User eingeben lassen, und an den Stellen, wo kein Maxspeed angegeben ist, diesen verwenden, andernfalls diesen _begrenzen_ natürlich aber nicht nach oben ausdehnen. Von daher spielen Maxspeeds oberhalb meiner erreichbaren Geschwindigkeit keine Rolle. Im Prinzip sind wir uns einig, ich gebe nur zu bedenken, dass man keine Auswertelogik voraussetzen kann. Dein Vorschlag ist sinnvoll aber nicht der einzig moegliche. Ein Limit kann ja auch die maximale moegliche Geschwindigkeit erhoehen, also z.B. von 100 auf 120kmh auf besser ausgebauten Landstrassen oder von 50kmh auf 60 oder 70kmh in der Ortschaft. Ist ein explizites Limit gegeben, setze ich normalerweise auch voraus, dass es auch stimmt, verwende es direkt und errechne die typische Geschwindigkeit mittels prozentualen Abzug vom Limit anhand div. Parameter (Spuranzahl, Ampeln, etc.). Den Job des Abschneidens nach Maximum uebernimmt eine nachgeschaltete Plausibilitaetspruefung und die laesst bei mir viel hoehere Werte zu als z.B. die 80kmh auf Landstrassen. Na ja, jeder hat eben so seine eigene Methodik ;) Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reisezeitmodelle, war: maxspeed=DE:Urban
Original-Nachricht Datum: Fri, 8 Jan 2010 16:04:23 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: qbert biker qbe...@gmx.de CC: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] maxspeed=DE:Urban Am 8. Januar 2010 15:13 schrieb qbert biker qbe...@gmx.de: Ein Limit kann ja auch die maximale moegliche Geschwindigkeit erhoehen, nein, ein Fahrzeug kann nicht schneller fahren, nur weil man schneller fahren darf. Dieser Zusammenhang ist so nicht gegeben. Denke mal, jetzt hab ich begriffen, auf was du raus willst: Du beziehst dich auf dynamische, also verkehrsabhängige Modellierung und das ist eine ganz andere Baustelle. in gewissem Rahmen bekommst Du halt trotzdem funktionierende Ergebnisse... Ich halte es für eine korrekte, aber eben statische Modellierung. Es wird modelliert, was Strasse und Fahrzeug hergeben. Ob das Limit stimmt und welche Geschwindigkeit im Schnitt erzielbar ist, sind 2 Paar Schuhe, Deine Auswertelogik (maxspeed-20%) ist ein Hack, der mit vernünftigen und üblichen Werten funktioniert (wenn alle Autos ungefähr ähnlich schnell fahren können), aber eben einen Zusammenhang herstellt, wo nur bedingt einer ist. Ich machs so wie ichs gelernt habe: Die typische Geschwindigkeit ergibt sich aus der Zielgeschwindigkeit (das was der Fahrer fahren will, also meistens maxspeed) abzueglich der gemittelten Verluste beim Anfahren, Wartezeiten, etc. Bei einer Vorfahrtsstrasse sind diese Verluste geringer also zieht man anteilig weniger ab. Bei einer kurvigen Nebenstrasse zieht man mehr ab, aber immer steht das im Verhältnis zur Zielgeschwindigkeit. Erst jetzt kommt der Verkehr, also der dynamische Part, ins Spiel und der kann die erreichbare Geschwindigkeit nochmal verringern, muss aber nicht. Und hier sehe ich ein Problem in deinem Ansatz, denn du mischt dynamische Aspekte in das statische Modell. Es ist aber sinnvoll, dynamische und statische Modellierung zu trennen, denn so kann man beliebige externe Quellen in die dynamische Modellierung einfliessen lassen. Ob man wegen LKW nicht über 80 drüberkommt, hängt vom Wochentag ab und der tägliche Berufsverkehrsstau eine Rolle spielt kann man über Tageszeitprofile ermitteln. Gruesse Hubert -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] maxspeed=DE:Urban
Original-Nachricht Datum: Wed, 06 Jan 2010 18:34:24 +0100 Von: Tobias Knerr o...@tobias-knerr.de An: Sascha Silbe sascha-ml-reply-to-200...@silbe.org, Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] maxspeed=DE:Urban Hallo, als ob die Arbeit mit Polygonen ein Hexenwerk waere... Why don't you use polygons for this? * Polygons are two-dimensional. There are situations where bridges or similar three-dimensional structures cause zones to vertically overlap, which cannot be represented by polygons. Das Datenmodell von OSM ist zweidimensional, daran aendern auch die Ebenen nix. Die OSM-Datenverarbeitung kennt keine echte Z-Ebene, sondern nur Kreuzungen, die keinen Knoten bilden mit der Erklaerung dazu, dass sie sich eben in einer anderen Ebene befaenden, hauptsaechlich als Hinweis an die Visualisierung. Ein zweidimensionaler Algorithmus wird also alle Elemente finden. * Downloading only a part of the map (e.g. a part of a city) can result in polygons missing from the download, despite ways from inside the polygon being part of the downloaded data. Ein einfacher Loesungsansatz dafuer: Jedes Polygon bekommt ein umschreibendes Rechteck, das sich leicht zuordnen laesst, auch wenn kein einziges Element des Polygons heruntergeladen wird, z.b. weil das Polygon viel groesser ist als der geladene Bereich. Der Rest ist, die Beziehung der Polygone und des geladenen Bereichs zu klaeren (alle drin, alle draussen, Schnittmenge) * A mapper will often know that a certain way is part of a zone without knowing where the zone boundaries are. Da kann ja 'is_in' als Uebergangsloesung verwendet werden, oder es wird eine Teilgrenze eingetragen und ein anderer macht das polygon dann zu. * Tags on ways are easier to evaluate for applications. Polygons require more advanced programming techniques to reduce performance problems from inclusion tests. Da bin ich durchaus anderer Meinung. Was hier immer wieder an Beschreibungsvarianten auftaucht ist durchaus vielfaeltig und ein Algo muss die alle fehlerfrei erkennen koennen und auch ob ein Geasschen vergessen wurde. Ein Polygon hingegen ist geometrisch stabil und wenn die Algorithmen dazu sauber durchgetestet ist, laeuft das erstmal. Fehler in einem Polygon zuzuordnen (nicht geschlossen, etc.) ist auch sicherer und stabiler als sicherzustellen, dass alle Einzelelemente des Bereichs auch richtig ausgewertet werden. Letzteres ginge uebrigends am einfachsten, indem man ein Poygon erzeugt und alle Elemente innerhalb des Polygons ueberprueft (Katze, Schwanz, beissen...). * it's very incorrect, because only the roads themselves are part of any kind of traffic-zone and not the whole area; e.g. roads in parcs or on private property or even tracks. Stimmt, wie will man sicherstellen, dass ein Baum in einem Park sich beim davonlaufen ans Tempolimit haelt :) Etwas Logik in die Auswertung und das Thema ist gegessen: private schlaegt public, explizites Schild schlaegt Zone, usw. Es gibt auch noch die Moeglichkeit, eine Zone ueber den Graphen selber zu beschreiben, indem man alle begrenzenden Knoten markiert und mit den Mitteln des Graphen in das Gebiet hineinscannt. Diese Methode erfasst nur Elemente des Graphen selber (also i.A. 'highway'), erfordert aber ein gehoeriges Mass an Disziplin und ist etwas sensibel gegen das 'Auslaufen', z.B. wenn eine Node nicht erfasst ist. Auch das kann man abfangen aber fuer die technisch robusteste Loesung halte ich das echte Flaechenpolygon. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung, Update
Hallo, hab heute noch ein wenig mit dem Programm rumgespielt und eine alternative Visualisierung gemacht: http://img214.imageshack.us/img214/2618/bosmcrossing2.png Die Ausgangsdaten sind gleich geblieben, also: http://www.opencarbox.de/osm/test6.osm.bz2 Vielen Dank an Guenther Meyer fürs Bereitstellen. Für die Änderungen der Spuranzahl auf der Strecke muss ich mir noch was einfallen lassen, eine Abschrägung sollte es fürs erste tun. Gruesse Hubert Original-Nachricht Datum: Fri, 01 Jan 2010 11:05:17 +0100 Von: qbert biker qbe...@gmx.de An: talk-de@openstreetmap.org Betreff: [Talk-de] Spurgenaue Abbildung Erstmal ein gutes Neues zusammen! Ich war letztes Jahr mal in ein paar Diskussionen dabei, in denen es um spurgenaue Abbildung von Autobahnkreuzen, etc. ging. Ueber die Feiertage hatte ich Zeit, ein wenig damit zu spielen und das ist dabei rausgekommen: http://img191.imageshack.us/img191/7219/bosmcrossing1.png Das Kreuz ist bei Herford (ca. 52°05'20'', 8°41'46'') und wurde mal im November als Beispiel angegeben: http://www.openstreetmap.org/?lat=52.08868lon=8.69753zoom=17layers=B000FTF http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html Ich bin dabei komplett ohne Relations ausgekommen und habe als Eingangsdaten nur 'lanes', '*.link', 'oneway' und 'highway' verwendet (ohne Gewähr auf Vollständigkeit). Bei einer angenommenen Spurbreite von 5m sieht das ganze relativ realistisch aus. Allerdings habe ich das Kreuz lokal bei mir ziemlich umbauen muessen, damit das raus kommt, was zu sehen ist. Die Änderungen habe ich sicherheitshalber nicht hochgeladen, denn mit einem lokalen Datensatz kann man besser basteln ohne die anderen zu stören. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung, Update
Original-Nachricht Datum: Sat, 2 Jan 2010 18:19:08 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Spurgenaue Abbildung, Update Hallo, Sieht schon viel anschaulicher aus, fast perfekt. Richtig schön wäre es jetzt noch, wenn man auch den Beginn einer Spur drin hätte, also dort, wo sie noch nicht voll benutzbar ist, der Asphalt sich aber schon verbreitert (bisher fangen die Spuren sofort bei voll an, ist aber vielleicht auch nur ein Renderingthema?). Ist es - ich habe schlicht noch keine Regel dafür implementiert. Bisher habe ich mich nur mit der automatischen Anpassung von Y-Verbindungen beschäftigt, also '2 auf 1' oder '1 auf 2'. Es bräuchte also noch eine Regel für '1 auf 1' mit Spuranzahländerung. Mal schaun, wann ich dazu komme. Etwas merkwürdig der südliche Teil der durchgehenden horizontalen Autobahn: ist da gerade Baustelle, oder warum hat die z.T. nur eine Spur? Das was von rechts unten nach links oben geht ist keine Autobahn, sondern eine autobahnähnlich ausgebaute Bundesstrasse, also in diesem Bereich 'trunk'. Die Spuränderungen sind zumindest nach den Satellitenbildern so wie beschrieben, ohne Baustelle. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung, Update
Original-Nachricht Datum: Sat, 02 Jan 2010 19:33:59 +0100 Von: Nils Heuermann w...@oemmes.net An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Spurgenaue Abbildung, Update Hallo Hubert, hab heute noch ein wenig mit dem Programm rumgespielt jetzt hab ichs mir auch angeguckt. Sieht hübsch aus :) Vom Tagging her ist es sehr simpel und nutzt auch keinen neuen Zaubereien. Für tiefgehendere Informationen zu einzelnen Spuren bräuchte man dann natürlich eine ganze Latte an Tags am Way... Oder eben dann Relations. Grundsätzlich finde ich es sehr praktisch, die ways an Verzweigungen zu unterbrechen. Das hab ich gemacht und weils dann fast keinen Grund mehr gab, innerhalb von ways Info einzufügen, hab ichs für den ersten Schritt beim einfachen Tagging gelassen. Das Programm ist als Versuch zu sehen, wie man aus sehr wenig Info einiges rausholt. Und mir ist klar, dass das z.B. bei Sonderlinien an die Grenzen stösst. Zu beachten wäre noch, dass wenn eine Spur im normalen Straßenverlauf wegfällt, dies i. d. R. die linke ist. Im Beispiel z. B. die von Nordwest kommenden 2 Spuren, die sich auf 1 verringern. Das beschriebene Konzept klappt nur bei Autobahnen oder autobahnähnlich ausgebauten Strassen. Und da sind die Masse an Spuren die wegfallen, Einfädelspuren von Kreuzungen oder Einfahrten. Die links wegfallenden Spuren sind die Ausnahme wenn man Einfädelspuren wie alle andern Spuren betrachtet. Aber du hast natürlich recht damit, dass das vorkommt und man eine Ausnahmebehandlung vorsehen sollte. Auch dies ist nichts Neues für dich: Auf Straßen mit Gegenverkehr, also die nicht oneway sind, gibt es z. B. die wechselnden 2+1-Straßen oder unterschiedlichste Abbiegespuren an Kreuzungen. Da kanns schnell unübersichtlich werden und nur mit lanes=x kommt man nicht weiter. Hast du dir dazu weitere Gedanken gemacht? Wohl am besten mit einem speziellen Konstrukt, z.B. mit passenden Relations. Ich wollte ja hauptsächlich demonstrieren, dass es sich lohnt, die Basisdaten wie lanes einzutragen, weil passende SW da einiges rauskitzeln kann. Wer mehr will, kann jederzeit mehr eintragen, aber es wäre schade, wenn Leute Spuranzahl und ähnliches gar nicht eintragen, weil sie meinen, dass keiner damit was anfangen kann. Grüsse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Spurgenaue Abbildung
Erstmal ein gutes Neues zusammen! Ich war letztes Jahr mal in ein paar Diskussionen dabei, in denen es um spurgenaue Abbildung von Autobahnkreuzen, etc. ging. Ueber die Feiertage hatte ich Zeit, ein wenig damit zu spielen und das ist dabei rausgekommen: http://img191.imageshack.us/img191/7219/bosmcrossing1.png Das Kreuz ist bei Herford (ca. 52°05'20'', 8°41'46'') und wurde mal im November als Beispiel angegeben: http://www.openstreetmap.org/?lat=52.08868lon=8.69753zoom=17layers=B000FTF http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html Ich bin dabei komplett ohne Relations ausgekommen und habe als Eingangsdaten nur 'lanes', '*.link', 'oneway' und 'highway' verwendet (ohne Gewähr auf Vollständigkeit). Bei einer angenommenen Spurbreite von 5m sieht das ganze relativ realistisch aus. Allerdings habe ich das Kreuz lokal bei mir ziemlich umbauen muessen, damit das raus kommt, was zu sehen ist. Die Änderungen habe ich sicherheitshalber nicht hochgeladen, denn mit einem lokalen Datensatz kann man besser basteln ohne die anderen zu stören. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung
Original-Nachricht Datum: Fri, 01 Jan 2010 12:07:15 +0100 Von: Tobias Knerr o...@tobias-knerr.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Spurgenaue Abbildung qbert biker schrieb: Ich bin dabei komplett ohne Relations ausgekommen und habe als Eingangsdaten nur 'lanes', '*.link', 'oneway' und 'highway' verwendet (ohne Gewähr auf Vollständigkeit). Bei einer angenommenen Spurbreite von 5m sieht das ganze relativ realistisch aus. So eine Minimallösung geht aber doch nur, wenn man zahlreiche Einschränkungen vornimmt, die mehr oder weniger nur für Autobahnkreuze zutreffen? Ich kann mir nicht vorstellen, dass sich damit eine innerstädtische Situation abbilden ließe - selbst dann, wenn man sich auf Autofahrbahnen beschränken würde. Fuer jedes Gebiet die passende Abbildung. Das was ich da probiert habe, ist erstmal für Autobahnen/Schnellstrassen gedacht, weil die sehr genauen Regeln folgen. Andererseits sind für Navis mit Spurwechselassistent die Autobahnen/Schnellstrassen von besonderer Bedeutung. Wenn ich dazukomme, werde ich noch etwas ähnliches für Innenstadtbereiche probieren. Ich denke schon, dass da mit der passenden Abstraktion einiges drin ist. Allerdings habe ich das Kreuz lokal bei mir ziemlich umbauen muessen, damit das raus kommt, was zu sehen ist. Die Änderungen habe ich sicherheitshalber nicht hochgeladen, denn mit einem lokalen Datensatz kann man besser basteln ohne die anderen zu stören. Kannst du das als .osm-Datei bereitstellen? Gerne, aber eine kurze Frage vorab, wie ich das am besten anstelle. Die bz2-komprimierte Datei kommt noch auf ca. 52kb und das dürfte etwas zuviel für die Liste hier sein, oder? Aber viel hab ich nicht gemacht. Erstmal habe ich Einfädelspuren korrigiert, die als eigener Link drin waren. Dann habe ich die ways anhand der tracks von der Mitte der Fahrbahn auf den linken Rand verschoben, weil sonst die Geometrie kracht. Und ich habe noch die ways neu gesplittet und wieder zusammengefügt, so dass sie an jeder Verzweigung enden und beginnen. Letzteres ist nicht unbedingt nötig, erleichtert aber die Programmierung ungemein. Ich hätte sonst virtuell im Programm splitten müssen und da habe ich über die Nachbearbeitung des Netzes ein wenig abgekürzt ;) Ach ja, ein Hinweis noch. Für das Rauslesen der Spuranzahl habe ich Google Earth benutzt, der Datensatz ist also nicht mehr lizenztechnisch sauber. Grüsse Hubert -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung
Original-Nachricht Datum: Fri, 01 Jan 2010 13:34:50 +0100 Von: Chris-Hein Lunkhusen chris66...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Spurgenaue Abbildung Erstmal ein gutes Neues zusammen! Dito! Ich bin dabei komplett ohne Relations ausgekommen Die Relationen sind dafür gedacht, dass ein Router die Spuren wieder zu einer Fahrbahn zusammenfassen kann. Auf Grund der GPS Genauigkeit wird ein Router durch zu eng zusammenliegende Spuren ja eher verwirrt. Wenn man wirklich vor hat, einem Router so ein Linienbündel vorzusetzen. Ich hatte ja schon mal einen Router für OSM geschrieben und schon damals habe ich die meiste Zeit in die Vorbehandlung investiert, also der Vereinfachung des Graphen. Auch hier wäre das erste was ich machen würde, einen Algo zu bauen, der die Linienbündel wieder in einen einfachen Graphen zurückbaut. Einzelspurabbildung ist ineffizient beim Routing, weil es plötzlich pro Spur einen eigenen Weg im Graphen gibt. Des weiteren ist die Fehleranfälligkeit eines solchen Konstrukts natürlich auch größer, so dass das Spurenmapping für das Routing vermutlich eher eine Verschlechterung bringen wird. Als Anwendungsentwickler wollte ich mit dem Bild zeigen, welche Daten ich brauche, um die Geometrie abzubilden und das mit einfach zu handhabenden Attributen. Und dazu sind fast alle Informationen drin, die ich für Navigation und Spurwechselassistenz brauche. Genaue geometrische Beschreibung und Navigation müssen ja kein Gegensatz sein. Was fehlt, aber relativ einfach nachzutragen ist, sind Sonderlinien, wie die breiten Strichlinien, die die Einfädelspuren abgrenzen. Das wäre noch ein Attribut dazu. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurgenaue Abbildung
Original-Nachricht Datum: Fri, 1 Jan 2010 13:53:06 +0100 Von: Guenther Meyer d@sordidmusic.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Spurgenaue Abbildung immer diese vorschnellen und unbewiesenen behauptungen... man sollte sich vielleicht erst mal die realisierung, also die daten selbst, anschauen, bevor man darueber urteilt. Höhere Komplexität verstärkt die Gefahr, dass sich Fehler einschleichen. Wenn ich 3 Spuren als Einzelelemente des Graphen einfüge und danach dem System über ein weiteres Konstrukt mitteilen muss, dass man beliebig zwischen ihnen wechseln kann, ist das fehleranfälliger als 'lanes=3' Wenn ich Einzelspuren als ways tagge und die dem Router direkt vorsetze, wird er erstmal langsamer, weil die Geschwindigkeit direkt von der Anzahl der (Verbindungs-) Knoten abhängig ist. Grüsse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring
Original-Nachricht
Datum: Wed, 23 Dec 2009 06:34:46 +0100
Von: Mathias Kemper math...@ghbiker.de
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de] KFZ-strasse und primary, war Nürburgring
Moin moin Hubert,
Ok, also würdest du folgende Taggs für korrekt halten ?
highway = primary
motorroad = yes
name = Nürburgring Nordschleife
oneway = yes
sport = motor
toll = yes
Die Darstellung halte ich was die KFZ-Strasse betrifft fuer
richtig und ansonsten hat das einen hohen Informationsgehalt.
Ich mag diese Form der aufgeschluesselten Darstellung, denn
jeder kann sich sie Info rausholen, die er braucht, und das
ohne viel Redundanz.
Könnte ich sehr gut mit leben. Durch primary bekommt die NS nicht den
so hohen Stellenwert wie durch trunk und auch die Renderer dürften die
Strecke nicht so fett zeichnen.
Schwierige Frage, denn es gibt ja nach wie vor keine
Definition, was die Strassenklasse ('highway=') eigentlich
aussagen soll. Die Nordschleife hat so gut wie keine
Verbindungsfunktion, ist aber sehr gut ausgebaut. Dass es
eine KFZ-strasse ist, ist ja schon ueber motorroad ausgesagt
also kann man prinzipiell alles von trunk bis unclassified
vergeben, ohne die Regeln zu verletzen.
Ich denke, man sollte mal ueber Sondernutzungen nachdenken,
denn es gibt ja viele solcher Strassen, die hauptsaechlich
von Firmen betrieben werden. Ich denke da an abgeschlossnene
Teststrecken, Rennstrecken oder auch Flughaefen. Deshalb
auch das beispiel vorher mit dem Muenchner Flughafen, denn
da sind die KFZ-Strassenschilder auf dem Gelaende des
Flughafens ja auch aus rein organisatorischen Gruenden
aufgestellt (z.B. Fussgaenger aussperren) und nicht weil das
eine besonders wichtige Strasse ist.
Allerdings sollte es den verkehrstechnischen Gegebenheiten entsprechen
und nicht einfach nur schön sein:-)
Wir mappen nicht fuer ... :)
Verkehrstechnisch ists eine unclassified, wenn man den
Verbindungstyp betrachtet aber nicht nach Breite und
Ausbau. Schade dass man sich nicht durchringen kann, Ausbau
und Verbindungstyp getrennt zu erfassen, denn dann waere
das Abbilden der Nordschleife und vielen anderen
Problemfaellen deutlich einfacher und genauer.
Gruesse Hubert
--
Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.!
http://portal.gmx.net/de/go/dsl02
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring
Original-Nachricht Datum: Wed, 23 Dec 2009 14:11:13 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]KFZ-strasse und primary, war Nürburgring Hallo, habe ich was verpasst? Genau diese Abgrenzung hat man doch vor ein paar Monaten vorgenommen und bestätigt, dass der Verbindungstyp in der Highway-Klasse steckt. Ich habe viel Diskussion mitbekommen und dass es nach wie vor keine Entscheidung gibt oder etwas was einer nahe kommt. Aber wenns weitgehenden Konsens gibt, dass highway den Verbindungstyp beschreibt, umso besser :) (S. Wiki, rel. große Abstimmung, rel. eindeutiges Ergebnis). Im hier vorliegenden Fall ist aber highway=raceway auch eine Überlegung wert, meint Ihr nicht? Quasi alle sind sich doch mittlerweile einig (die PR-Abteilung des Betreibers eingeschlossen), dass es sich um eine Rennstrecke handelt, die ansonsten für Touristenfahrten geöffnet wird. Ist sicher nicht verkehrt. Ich halte es zwar fuer grundsaetzlich moeglich, jede Rennstrecke in das normale Klassenkonzept einzubinden (andere Datenanbieter machen das afaik auch), aber raceway(racetrack?) macht nix kaputt und ist selbsterklaerend. Mir gings mit meinem Beitrag nur um die Verwirrung um trunk und motorroad und da liegt im Gegensatz zur Nordschleife noch einiges im argen. Gruesse Hubert -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kleines Meinungsbild: Tagging des Nü rburgringes/Nordschleife
Original-Nachricht Datum: Wed, 23 Dec 2009 14:07:37 +0100 Von: Mirko Küster webmas...@ts-eastrail.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]kleines Meinungsbild: Tagging des Nürburgringes/Nordschleife daraus leite ich ab, dass die nordschleife *keine normale* straße im rahmen der stvo ist. die nürburgring-gmbh übernimmt nur freiwillig die regeln der stvo, das ist aber alles. Was ist dann eine 'normale Strasse'? Eben nichts anderes wie jede andere exclusive Rennstrecke auch. Auch anderswo kann man privat rauf. Der einzige Unterschied der zu stören scheint ist wahrscheinlich folgender. Normale Rennstrecken befinden sich auf in sich geschlossenem Privatgelände, was hier aufgrund der Ausdehnung ja nicht geht und das ganze wie eine normale Aussieht. Siehe Tourist Trophy, es gibt kein normales Aussehen einer Rennstrecke. Die Nordschleife ist eigentlich einfach nur eine weitgehend ausgemusterte Rennstrecke, da der moderne F1-Rennbetrieb nach einem Neubau geschriehen hat. Das die StVO gilt hat nichts zu bedeuten. Kann jeder freiwillig für sein Privatgelände festlegen. Exakt, so wie jeder auf Privatgelaende das Tempolimit festlegen oder aufheben kann wie bei der Nordschleife unter Nutzung des KFZ-Strassenschildes geschehen. Also Rennstrecke und nichts anderes. Diese Straße hat nichts mit den öffentlichen Straßen zu tun und hat keine Funktion im Straßennetz. Ich habe ja nix gegen racetrack aber diese Definition einer Strasse ist etwas aus der Luft gegriffen. Auch die Nordschleife ist eine Strasse, auch wenn auf der nur zum Vergnuegen gefahren wird und nicht um von A nach B zu kommen. Das ist eine reine private Touristenrennstrecke. Das mit Mitteln zu beschreiben die wir für das öffentliche Netz nutzen wäre hier total falsch. Außer ich will die Router damit verarschen und nicht ortskundige Kartenutzer ein bissel rollen. Schiebt doch nicht immer alles auf die Router ab, denn die koennen mit sowas recht gut umgehen. Die Schleife braucht viele km um zwei Punkte zu verbinden, die recht nah beieinander sind. Ein Router, der nicht rausfindet, dass das keine optimale Loesung ist, gehoert weggeschmissen (mal ganz abgesehen von der Auswertung von access-tags, usw.) Auch wenn ich auch der Meinung bin, dass highway=racetrack hier keine schlechte Loesung ist, waere ich mit dem 'total falsch' schon vorsichtiger. Eigentlich ists eine Betriebsstrasse und auch wenns komisch klingt, service waere wohl die Alternative zu racetrack. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kleines Meinungsbild: Tagging des Nü rburgringes/Nordschleife
Original-Nachricht Datum: Wed, 23 Dec 2009 15:41:48 +0100 Von: Mirko Küster webmas...@ts-eastrail.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]kleines Meinungsbild: Tagging des Nürburgringes/Nordschleife Hallo, Dadurch wird aber noch immer keine Straße im Sinne des öffentlichen Verkehrs. Es ist und bleibt eine Hobbyrennstrecke oder Touristenattraktion ohne Verbindungsfunktion, Bedeutung oder Aufgabe im Straßennetz. Wie schon geschrieben, habe ich kein Problem mit racetrack, aber ich habe ein Problem mit der Begründung. Warum ist es absolut selbstverständlich, dass eine 'normale Strasse' ein Teil des öffentlichen Strassennetzes mit Verbindungsfunktion zu sein hat? An anderer Stelle wird diese Voraussetzung schlicht ignoriert, z.B. beim Flughafen. Das ist typischerweise Privatgelände, das über Privatstrassen den Kunden (=Fluggäste) zugänglich gemacht wird, die über die üblichen Klassen abgehandelt werden. Ich finde, dass so implizit definierte bombenfeste 'Tatsachen' eine schlechte Voraussetzung für saubere Definitionen und Beschreibungen sind. Wenn so eine Definition existiert, dann sollte sie explizit ausgearbeitet sein, denn für einen anderen ist ein Teerband, auf dem Autos fahren genauso felsenfest eine normale Strasse und es hagelt Missverständnisse. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring
Original-Nachricht Datum: Tue, 22 Dec 2009 15:54:39 +0100 Von: Mathias Kemper math...@ghbiker.de An: m...@koppenhoefer.com, Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Nürburgring Nordschleife (betrifft eventuell Rennstrecken allgemein) unter highway=primary lese ich was von Bundesstraße, nicht BundesKRAFTFAHRstraße. Primary ist die Hauptverbindungsstrasse, die typischerweise, aber nicht immer mit der Bundesstrasse zusammenfaellt. Eine Bundesstrasse kann KFZ-Strasse sein aber auch eine Staats- oder Kreisstrasse. KFZ-Strasse bezieht sich darauf, wie eine Strasse von wem benutzt werden darf (z.B. Radfahrer und Fussgaengerverbot) und nicht darauf, welche Bedeutung sie hat oder wie sie ausgebaut ist. Und natuerlich ist eine KFZ-Strasse normalerweise eine gut ausgebaute Strasse, aber es gibt auch Ausnahmen und man kann das nicht zwingend voraussetzen. Auch finde ich dort keinen Hinweis auf motorroad=yes. 'motorroad' ist ein unabhaengiges Attribut das sich eindeutig auf Strassen(abschnitte) bezieht, die vom entsprechenden Schild begrenzt werden. Der Unterschied Bundesstraße zu Bundeskraftfahrstraße fänd ich in so fern schon wichtig als dass man auch auf der NS nicht (gundlos - für die Koritenkacker) anhalten darf und Fahrzeuge auch bauartbedingt 60Km/h (?) fahren können müssen, Mofas jedenfalls nicht. Klappt aber so nicht, weil sich das eine auf die Bautreagerschaft bezieht und das andere auf Verkehrsregeln. Wie schon geschrieben gibts durchaus auch Kreisstrassen, die den Status KFZ-strasse haben. Bleibt die etwas gequaelte Konstruktion 'trunk'. Es scheint sich leider durchgesetzt zu haben, dass immer 'trunk' gesetzt wird, wenn das KFZ-Schild angebracht wird. In Muenchen und Umgebung schaut das jetzt so aus, dass der kreuzungsfrei und autobahnaehnlich ausgebaute Mittlere Ring den trunk-Status verloren hat, weil das Schild fehlt und gut ausgebaute gegen schlechter ausgebaute Abschnitte (Ampeln, etc.) nicht mehr unterscheidbar sind. Besser ausgebaute Nebenstrassen (die genannten Kreisstrassen) erscheinen im fetten gruen, nur weil das Schid vorhanden ist. Am Muenchner Flughafen ist die eine Strasse unclassified und eine andere aehnliche Strasse trunk, nur in Abhaengigkeit vom KFZ-Strassenschild. Besonders aussagekraeftig fuer die Orientierung ist das alles leider nicht. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KFZ-strasse und primary, war Nürburg ring
Original-Nachricht Datum: Tue, 22 Dec 2009 16:57:51 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]KFZ-strasse und primary, war Nürburgring Am 22. Dezember 2009 16:50 schrieb qbert biker qbe...@gmx.de: Bleibt die etwas gequaelte Konstruktion 'trunk'. Es scheint sich leider durchgesetzt zu haben, dass immer 'trunk' gesetzt wird, wenn das KFZ-Schild angebracht wird. kannst das ja ändern und am Besten einen Note setzen, damit es nicht übermorgen wieder zurück geändert wird. Na eher morgen... Mittlerweile finde ich bei diesen Dingen das Beobachten spannender als das Ändern, besonders wenn ich das vor langer Zeit mal selber eingetragen hatte. Und diese trunk-Murks setz ich eh nimmer, denn einerseits finde ich das grün hässlich und andererseits weiss ich selber nicht mehr, was ich mir drunter vorstellen soll. OK, ok, die erste Begründung ist ein Scherz :) Grüsse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
Original-Nachricht Datum: Fri, 18 Dec 2009 17:21:44 +0100 Von: Florian Lohoff f...@rfc822.org An: Marcus Wolschon mar...@wolschon.biz CC: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Fahrtzeiten in Staus Aber steht nicht in den TMC meldungen genau die zu erwartende verzoegerung in Minuten? Zumindest erinnere ich mich da an was. Wohl eher eine sehr grobe Schaetzung. TMC stammt ja historisch von den Radiomeldungen ab, bei denen die Meldung die Meldekette oft erst dann durchlaufen hatte, wenn das Stau schon wieder weg war. Heute geht das zwar schneller aber die Krux bleibt die Schaetzung der zu erwartenden Verzoegerung. Die ist nicht direkt messbar, weil es ja eine Prognose eines Vorganges ist, der in der Zukunft stattfindet. In der Zukunft deshalb, weil ich den Stau idealerweise noch nicht erreicht habe, wenn die Meldung frueh genug kommt, um ihn zu umfahren. Jetzt ist ein Stau aber keine statische Angelegenheit, sondern in vielen Faellen ein hochdynamischer Vorgang mit vielen Unbekannten. Schon alleine deshalb kann so eine Prognose gar nicht genau sein, bzw. man muesste einen Soll- ist Vergleich machen um zu sehen, wie nahe die Prognose an die Realitaet rangekommen ist. Der wird aber nur in den seltensten Faellen gemacht. Was bleibt sind Daumen mal Pi Abschaetzungen aus allgemeinen Erfahrungswerten. Man kennt meist die Verkehrsfluesse als Profil ueber den Tag hinweg und kann bei einer Spurverengung Rueckschluesse ziehen. Dann dazu noch die berühmte Schätzung der Staulänge und fertig ist der Prognosewert. Manchmal ists auch pure Statistik, denn manche Staus treten ja zyklisch auf und ein Blick eines Operators auf die Überwachungskamera genügt, um die Standardmeldung auszulösen. Eine andere, leider sehr fehlerbehaftete Quelle sind automatisch erzeugte Stauwarnungen aus den Streckenbeeinflussungsanlagen heraus. Die haben nur ein paar Querschnitte als Bezug und daraus eine Prognose der Verzögerung abzuleiten, grenzt an Kaffeesatzleserei ;) Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
Original-Nachricht Datum: Thu, 17 Dec 2009 07:22:42 +0100 Von: Marcus Wolschon mar...@wolschon.biz An: talk-de@openstreetmap.org Betreff: [Talk-de] Fahrtzeiten in Staus Mit der Weihnachtszeit stehen auch wieder sie Staus an. Nachdem ich in der vergangenheit ein wenig mit dem Thema Staus und Reisezeitschaetzung verbandelt war, ein wenig Senf von mir dazu: Bei der Reisezeitschaetzung hat man zwei unterschiedliche Datenquellen. Zum einen die klassische Methode ueber Querschnitte, also die Induktionsschleifen oder andere Detektoren die die Bewegungen ueber einen Querschnitt zaehlen. Die zweite und modernere Methode ist das 'floating car' also das Fz, das im Verkehr mitschwimmt und dabei Statusmeldungen abgibt. Bei der Querschnittserfassung gibts zwar massig staatlich erhobener Daten, auch dank der Streckenbeeinflussungen (Schilderbruecken mit variablem Tempolimit), die wie Pilze aus dem Boden spriessen. Allerdings ist die Reiszeitschaetzung ueber diese Daten nicht besonders genau, da man nur lokale Effekte messen kann, ein Stau aber ein Effekt ist, der irgendwo dazwischen beginnen und enden kann. Meine Erfahrungen mit den entsprechenden Methoden waren jedenfalls nicht das gelbe vom Ei. Frueher wurde die TMC-Daten fast ausschliesslich ueber diese Daten erhoben oder noch schlimmer ueber die beruehmte Schaetzung der Polizei vor Ort, die auch so in den verkehrsmeldungen rueberkommt. Entsprechend duenn ist (war?) die Aussagekraft. Die Navihersteller wollen verkaufen und wurschteln das rein, so gut wies eben geht. Gemeinerweise kann man ja immer nur eine Route gleichzeitig fahren und erfaehrt so selten, ob die andere schneller gewesen waere ;) Nun zur zweiten Erfassungsmethode, die Floating cars. Leider bin ich nicht mehr in diesem Geschaeft und weiss nicht wie sich das entwickelt hat. Grundsaetzlich gibts aber ein ziemliches Problem, Floatingcar-Daten oeffentlich zu erheben und verfuegbar zu machen. Wir haben damals schon einiges damit gemacht, z.B. mit Taxiflotten, die die Daten online Kommunen zur Verfuegung gestellt haben, aber da gibts natuerliche Grenzen. Das geniale dran ist, dass man im Idealfall ein exaktes Profil des Staus bekommt und auch exakt den Zeitverlust (gemessene Fahrtdauer abzueglich Standardfahrzeit). Klar gibts da auch Fehlerquellen, aber die lassen sich eigentlich ganz gut filtern. Ich denke, wenn man schon Staus vergleicht, sollte man versuchen, das auf eine moeglichst objektive Basis zu stellen. Da viele von uns ein GPS haben und auch so manches mittracken, gibts auch immer mal einen Track, der einen Stau beschreibt. Diese Tracks waeren eine tolle Ergaenzung zu den einfachen Stauberichten, die hier vorgeschlagen werden. Gruesse Hubert -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenbegleitende Fußwege an Ampeln (was: Wie würdet Ihr das zeichnen ??)
Original-Nachricht Datum: Sun, 13 Dec 2009 03:24:36 +0100 Von: Mirko Küster webmas...@ts-eastrail.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de]Straßenbegleitende Fußwege an Ampeln (was: Wie würdet Ihr das zeichnen ??) Hallo, Und genau dafür lohnt es sich das auch genau zu erfassen. Wir haben die Mittel und Wege, auch wenn das Straßenmodell noch einiges an Luft nach oben hätte. Es stellt sich eher die Frage, ob das Strassenmodell das begrenzende Element ist, oder die OSM-Modellierung an sich. Jedes noch so kleines Element in einen einzigen jetzt schon gewaltigen Knoten-Namensraum zu packen ist kein besonders elegantes Konzept. Eine Kreuzung ist erstmal eine einfaches Element fuer den Treffpunkt zweier Elemente des Graphen, das anzeigt, wie man weiterkommt. Man kann natuerlich diese Kreuzung bis zur Pflastersteinebene ausschmuecken, aber muss das unbedingt im Namensraum des Graphen passieren? Mit ein wenig Objektorientierung waere das ganze besser loesbar: 'Du naeherst dich jetzt der Kreuzung xy, wenn du weitere Infos willst, lade die Detaildaten der Kreuzung nach'. Das Problem liegt schlicht an den Routern selbst. Router werden so oft missverstanden, dabei sind sie eigentlich nur Abbildungen von relativ einfachen Algorithmen. Je besser die Abstraktion des Wegenetzes gestaltet ist, desto schneller ist die Berechnung und desto brauchbarer sind die Anweisungen. Ein OSM-Router muss sich an technischen Tatsachen orientieren, wie sein kommerzielles Gegenstueck auch. Klar kann man aus komplexesten Abbildungen wieder auf die wesentlichen Verbindungen zurueckrechnen, aber dafuer brauchts stabile Vereinbarungen. Und das ist eben das Problem mit 'dann mach eben eine Relation drum, der OSM-Wunderrouter wird schon rausfinden, was damit gemeint ist'. Ein Router, bzw. die davorgeschaltete Datenaufbereitung kann nur verarbeiten, was er kennt. Wenn man einigermassen konfliktfrei Autos, Radfahrer, Rollstuhlfahrer und Blinde jeweils fuer sich optimal routen will, sollte man sich mal Konzepte ausdenken, wie man das besser organisiert. Einfach die Datenbank ohne jede Ruecksicht auf irgendeine Anwendung zu befuellen und auf den OSM-Wunderrouter zu warten, der mittels HAL9000-KI die optimale Route fuer jeden findet, ist die Alternative ;) Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Lauf
Original-Nachricht Datum: Wed, 02 Dec 2009 23:28:59 +0100 Von: André Reichelt andr...@online.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Luftbilder aus Lauf qbert biker schrieb: Aber die Rundungen, die ich meine, kann man abstrakt beschreiben und direkt rendern: 'corner=round size=3m' oder ähnlich kann beschreiben, dass die Ecken der Kreuzung mit einem Radius von 3Meter abgebildet werden sollen / so gebaut sind. Das klingt leider alles sehr abstrakt und extrem kompliziert zu bedienen. Außerdem brauchst du für jede Sonderform eine Extrawurst. Welche Sonderformen sollten denn betrachtet werden? Eckig ergibt sich automatisch, wenn nichts eingetragen ist (Kreuzungspunkt der Parallelen mit Radius = 0) und rund mit Radius ist immer eine sehr gute Naeherung. Den Rest kann man immer noch explizit reinmalen. Abstraktion ist die Methode der Wahl, wenn man mit wenig Daten viel Effekt haben will. Navis mit (Pseudo-)3D und Spurwechselassistent speichern ja auch nicht jeden Strich auf der Strasse einzeln, sondern rechnen das aus komprimierter Information raus. Ich habe ja bereits vor einigen Monaten angeregt, man könne neben geraden Ways ja auch echte Kurvenobjekte einsetzen. Das Ganze verlief sich aber im Sand, da damals noch keine Notwendigkeit bestand. Bei detaillierter Flächenbeschreibung sehe ich aber keinen Weg mehr daran vorbei. Es bestand immer Notwendigkeit oder auch nie, je nachdem wie man das Ziel von OSM definiert. Jede Kurve kann ueber Einzelpunkte angenaehert werden, was ja auch der Grund ist, warum GDF und shape auf Kreise oder andere Kurvenbeschreibungen verzichten. Bei OSM ist man frei, da darueber raus zu gehen, man muss sich aber klar sein, dass es ohne Planung und Regeln sehr, sehr schwierig wird, neue Geometrieobjekte einzufuehren. Aber wie gesagt, ich bin gegen eine reine Taggingbeschreibung. Das wird so komplex, dass man Anfänger damit sofort vertreibt und keiner mehr aus den Tags herauslesen kann, was eigentlich gemeint ist. Das gehoert in die Editoren rein und dann ist das relativ einfach. Kreuzungsnode anklicken, Radius ziehen und Ergebnis direkt am Editor betrachten - so solls sein. Die anachronistische Knoten-Way-Fummelei mit haendischen Eintragen von Attributen ueberfordert die meisten Mapper schon heute. Meiner Meinung nach sollten geometrische und physikalische Eigenschaften klar voneinander getrennt werden, sofern dies möglich ist. Die Oberflächenbeschaffenheit einer Straße kann man nur in Tags abbilden, jedoch sollte man diese nicht dazu missbrauchen, Dinge wie Fahrspuren, die Breite jeder einzelner Spur und ähnliches anzugeben. Dagegen bin ich. Die Alternative ist eine endlose Fummelei an jedem Detail, egal ob es einer Regel folgt oder nicht. Will ich die Abrundung an einer normalen Kreuzung per Hand reinmalen, bedeutet das 4 Ecken mit ca. 90Grad also bei 10Grad Aufloesung das haendische setzen von ca. 36Nodes. Da finde ich eine abstrakte Beschreibung: 'Die Fahrbahn ist 5m breit und die Ecken im 3m Radius abgerundet' viel einfacher. Gruesse Hubert -- Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen Debütalbum One Moment in Time. http://portal.gmx.net/de/go/musik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Lauf
Original-Nachricht
Datum: Wed, 2 Dec 2009 15:33:22 +0100
Von: Mirko Küster webmas...@ts-eastrail.de
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org
Betreff: Re: [Talk-de] Luftbilder aus Lauf
Problem ist das man mit Flächen allein nicht weit kommt. Lässt sich
nicht
drüber Routen etc. Es läuft also erstmal auf einen Mix aus Fläche und
darunter liegenden Linien mit den eigentlichen Funktionen heraus. Diese
Wege
kann man dann rein für die Funktion nutzen und die Darstellung bei der
Fläche belassen Dann würden ortsplazierte Dinge mit Straßenbezug wie
Bushaltestellen auch endlich mal einen Sinn ergeben, den es bisher nicht
hat. Ob Punkt auf der Linie oder daneben, an normalen Haltestellen in
kleinen Orten kein spürbarer Unterschied.
Da halte ich dagegen, dass man Flaechen auch abstrakt beschreiben
kann, ohne das Graphenprinzip zu verlassen. Man muss die Parallelen
dann eben fuer die Realumgebung (metrisch) rechnen und nicht in
der Ansichtsebene. Auch die Rundungen an den Kreuzungen lassen
sich automatisiert berechnen.
Der Bedarf an konkreten Flaechen wuerde sich dann auf krumme
Dinger beschraenken (alte Ortsdurchfahrten, exotische Wendehaemmer)
die dann ausserhalb des Graphen existieren.
Ich arbeite derzeit an sowas, ist aber in einem sehr fruehen Stadium
und braucht noch seine Zeit.
Was mir allerdings gar nicht gefaellt, ist die Verwendung von
highway fuer Flaechen, unabhaengig von Attributen. 'highway' konnte
bisher immer als Graphenelement aufgefasst werden, mit einer
Parallelbedeutung als Flaeche wird das aufgeweicht. Ein
unabhaengiger Bezeichner ('highway_area'?) koennte helfen, dass
man nicht rund um die eigentliche Strasse herumroutet, wenn
einer vergisst, das Flaechenattribut anzugeben.
Gruesse Hubert
--
Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 -
sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Lauf
Original-Nachricht Datum: Wed, 2 Dec 2009 17:06:48 +0100 Von: Mirko Küster webmas...@ts-eastrail.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Luftbilder aus Lauf Der Bedarf an konkreten Flaechen wuerde sich dann auf krumme Dinger beschraenken (alte Ortsdurchfahrten, exotische Wendehaemmer) die dann ausserhalb des Graphen existieren. Was in meinem Gebiet eher die absolute Regel darstellt. Exakte Reißbrettstraßen gibts nur in absoluten Neubaugebieten oder eben größeren Städten. Da könnte sowas automatisches helfen. Aber in der großen Fläche ist die Straße nach Bebbaung geplant, nicht umgekehrt. Normal ist sowas wie beispielsweise hier. http://osm.org/go/0MBdGAqKm http://osm.org/go/0MBW4x34r Also der zweite Link mag grade nicht, aber beim ersten verstehe ich das Problem nicht. Und ich bin auch schon viele km im Osten gefahren und die Strassen sind zwar nicht gerade (hier im Westen ja auch nicht), aber weitgehend parallel. Strassen, die im Verlauf ihre Breite dauernd um mehr als 10% ändern, sind überall in der Minderheit. So, jetzt ist der zweite auch da und auch da erkenne ich nicht, wo das Problem sein soll. Das kann kein System errechnen und die Maßangabe für die Breite über alles wäre fließend. Bei der Fahrbahn selbst gehts noch einigermaßen, obwohl auch die in vielen Fällen eher konisch als genau läuft.. Es geht ja in erster Linie um die Fahrbahn und konische Bereiche sind möglich und auch das ist abbildbar. Node 1, Breite a, Node 2, Breite b und fertig. Das drumherum fließt förmmlich. Da geht nur exakt nachzeichnen, alles andere geht in die Hose. Was einen eigenen unabhängigen, Verlauf hat, wird auch als solcher gezeichnet, wo liegt das Problem? Trotzdem folgen deutlich mehr als 90% aller Strassen der technischen Vorgabe, den Verkehr aufzunehmen und seit der Römerzeit oder schon vorher laufen die Räder parallel ;) Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Lauf
Original-Nachricht Datum: Wed, 2 Dec 2009 17:04:53 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Luftbilder aus Lauf Hallo, Rundungen ist ein gutes Stichwort: Kurven wären auch mal nicht schlecht als Grundobjekt. Sehe ich auch so und ist auch so eine Sache, an der ich dran bin. Ist aber im Moment zurückgestellt, weil mich das wayparts Konzept davon überzeugt hat, einen Zwischenschritt einzulegen und zu sehen, was man aus ways und nodes rauskitzeln kann. Aber die Rundungen, die ich meine, kann man abstrakt beschreiben und direkt rendern: 'corner=round size=3m' oder ähnlich kann beschreiben, dass die Ecken der Kreuzung mit einem Radius von 3Meter abgebildet werden sollen / so gebaut sind. als ob die Welt aus Neubaugebieten auf dem Land und in Suburbia bestehen würde ;-) Man vergleiche bei einer Stadt wie München die Strassen-km die älter als 100 Jahre sind und welche neuer. Dabei werden schon mendestens seit der Aufklärung Strassen geplant. Kompletten Kickhack gibts vor allen auf wenigen 100m in kleinen Orten und in mittelalterlich geprägten Orten. Grüsse Hubert -- Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen Debütalbum One Moment in Time. http://portal.gmx.net/de/go/musik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder aus Lauf
Original-Nachricht Datum: Wed, 2 Dec 2009 19:52:31 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Luftbilder aus Lauf In der Großstadt sind es hundert Faktoren, die eine Extrawurst brauchen, Und so gut wie alle Extrawürste führen zu geometrisch gut beschreibbaren Strukturen. Ich habe München angeführt, weil ich die Stadt gut kenne und auch über OSM noch besser kennengelernt habe. Dabei bin ich über viele km mit parallelen Verläufen gefahren, geradelt und gelatscht. Eine Ausnahme ist der historische Kern der aber flächenmässig fast untergeht. Schwabing, das zu den ältesten Vierteln gehört hat mit die exaktesten Geometrien, abschnittsweise perfekt rechtwinklig. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik - living streets
Original-Nachricht Datum: Tue, 1 Dec 2009 14:37:17 +0100 Von: Mirko Küster webmas...@ts-eastrail.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapnik - living streets Wenn nichtmal in den Mapfeatures für width eine eindeutige Angabe steht, in deutsch gleich garnicht, muss man sich auch ehrlich gesagt nicht wundern. Breiten zu Straßen beziehen sich i.d.R. immer nur auf die Fahrbahn, nicht über straßenbegleitende Bauten, zwischen Grundstücken ist komplett falsch. So ins Wiki, als hint in JOSM und schon dürften sich die Ausreißer in Grenzen halten. Wuerde ich begruessen und zumindest ich finde es so logisch und verstaendlich. Allerdings gabs schon einige Diskussionen darueber hier und die Meinungen waren vielfaeltig und der Konsens fern. Die Maße beziehen sich vielleicht auf aktuelle Bauvorschriften für Neubauten. Sind aber in der Praxis für den überwältigenden größeren Altbestand total unbrauchbar. Das mag regional stimmen, aber in anderen Ecken ist die Mehrheit der Strassen schon mehrheitlich nach aktuellen Regeln ausgebaut. Also hier im Sueden muss man Altbestaende, die massiv abweichen, eher suchen. = Breite bei 2 Spuren im Gegenverkehr: 5 - 9 m = Breite bei 4 Spuren: 10 - 11,20 m = Breite bei 6 Spuren: 15 - 16,80 m Das sind Milchmädchenrechnungen die man sich auch komplett schenken kann. Immerhin besser als nichts. Das hauptproblem ist, dass der Mapper vor Ort die Bauvorschrift selten kennt und schon gar kein Messgeraet dabei hat um das genau festzustellen. Und ein Massband quer ueber die Autobahn zu spannen ist ja auch nicht jedermans Sache ;) Mal ein anderer Ansatz: Ich denke, dass ein Mapper vor Ort schon gut einordnen kann, ob der Ausbau normal, ueberbreit oder sehr schmal ist. Wenn man dann noch ein wenig Hilfestellung gibt (Querschnittszeichnung, Bilder?) bekommt man vielleicht eine Genauigkeit hin, die zwar nicht perfekt ist, aber schon mal die Richtung vorgibt. für eine zukünftige Routinganwendung für LKW Fahrer interesannt. Auch hier scheints regional Unterschiede zu geben. Ich kenne das eigentlich nur so, dass relevante Engstellen explizit beschildert sind, solange es auch nur einen Hauch von Durchgangsverkehr gibt. Dann sind aber die Daten (Hoehe, Breite) direkt abzulesen. In der Theorie. In der Praxis wird das unterschritten, genau wie Fahrstreifen bei breiten Straßen oft auch nur nach Kassenlage aufgebracht werden. Da steht dann an der Kreisgrenze das berühmte Straßenschäden und die Markierung endet. Dann wird eben die Strasse immerhalb und aussserhalb der Kreisgrenze anders beschrieben. Abweichungen von mehr als 0,5 m sind für unsere Möglichkeiten deutlich zuviel. Bleibt die Frage, wie mans besser hinbekommt. Leute mit Lasermessgeraeten sind Mangelware. im Schnit bei ca 5 m liegen dürfte. Eine eingebildete Unsicherheit. Nach welcher Messmethode? Sowohl die Abbildung aus Bildern als auch aus Tracks ist fehlerbehaftet. Es geht hier nicht um wenige Spezialisten, die das Maximum aus der technik rauskitzeln, sonndern um den Durchschnitt der Mapper mit durchschnittlicher Technik und da ist man mit 5Meter gut dabei, denk ich mal. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik - living streets
Original-Nachricht Datum: Tue, 01 Dec 2009 16:25:26 +0100 Von: Tobias Knerr o...@tobias-knerr.de An: Mirko Küster webmas...@ts-eastrail.de, Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapnik - living streets Mirko Küster schrieb: Wer interpretiert da wo und wie? Ist mir noch nirgends untergekommen das da einer Breite über alles eingetragen hätte, schon garnicht absurderweise zwischen Grundstücksgrenzen. Straßenbreiten, Regelquerschnitte etc. beziehen sich immer auf die Fahrbahn und nicht auf straßenbegleitende Maßnahmen. In OSM repräsentiert ein Straßen-Way meist nicht nur eine Fahrbahn, sondern auch verschiedene begleitende Gehsteige, Radwege etc. - sonst hätten die ja eigene Ways und wären nicht nur Attribute (Tags/Relationen) am Straßen-Way. Darueber gehen die Meinungen weit auseinander. Die Verfechter des expliziten Eintragens von Einzelways fuer jedes Element sehen das z.B. komplett anders. Ich selber sehe Parallelwege auch lieber als Element eines Ways, die man z.B. im Einzelnen so beschreiben kann: http://lists.openstreetmap.org/pipermail/talk-de/2009-November/058720.html http://wiki.openstreetmap.org/wiki/DE:User:%C3%96mmes/Wayparts width=* ist die Breite des mit einem Way dargestellten Gebildes. Dieser Logik nach ist das alles beim width-Wert eines highway-Ways mit einzubeziehen. Und wie beschreibt man dann die Fahrbahn selber? Die Breite ueber alles hat sehr wenig Aussagekraft, z.B. wenn man die Breite beim Rendern einbeziehen will oder pruefen, ob man mit dem Fz. nun durchkommt oder nicht. Der worst case ist aber wenn die eine Haelfte in width die Breite der Fahrbahn sieht und die andere die des ganzen Gebildes. Eine Definition dazu waere hilfreich, egal wie sie ausfaellt, sonst ist die Auswertung sehr schwierig. Gruesse Hubert -- Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen Debütalbum One Moment in Time. http://portal.gmx.net/de/go/musik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik - living streets
Original-Nachricht Datum: Tue, 1 Dec 2009 17:01:09 +0100 Von: Mirko Küster webmas...@ts-eastrail.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapnik - living streets Hallo, Es gibt Dinge wo man sich wahrlich streiten kann. Und es gibt Dinge wo man sich sinnlos totquatschen kann. Breitenangaben beziehen sich in allen mir bekannten Quellen immer auf die Fahrbahn. Kann ich nur zustimmen. Das alles über einen Kamm zu scheren mag für manchan schön einfach sein, ist und bleibt aber eine Krücke. Meiner Meinung nach fehlt vor allem ein Konzept um von einer einfachen Darstellung stufenweise mehr Komplexität zu erreichen, ohne vorhandenes wieder zu zerstören. Auch deshalb stimme ich dir bei der Fahrbahnbreite als Basis zu. Da kann man gut anbauen, allerdings tendiere ich mehr und mehr zu einem relationbasierten Konzept, das zusätzlich der Fragmentierung entgegenwirken kann. Die aktuellen Bauvorschriften nützen hier in der Regel ohnehin nichts. Da bin ich grade dran. Ich denke schon, dass Standardquerschnitte etwas Ordnung ins Chaos bringen können, weil man geeignete Strassen einrasten lasten kann, optimalerweise mit etwas SW-Unterstützung. Nur weil irgendwo eine Vorschrift 6 m für Landstraßen vorsieht, wird es in der Realität nicht breiter. *g* Andersrum funktionierts auch besser. Wenn ich weiss, dass eine Strasse etwa vor 10 Jahren erneuert wurde (wissen Ansässige meist recht gut), brauch ich nur antesten, ob und welcher Standard zur Anwendung gekommen ist und kann direkt die Daten auslesen und vergleichen. Das kann man, ist aber immer auf die subjektive regionale Sichtweise bezogen. Na ja, ich bin auch schon im Osten gefahren und ganz so konzeptlos gehts da auch nicht zu ;) Aus eigener Erfahrung sind bei normalen Strassen so ca. 3-4 Ausbaustufen relativ gut unterscheidbar. Die Breite vor allem über die Restbreite, wenn man ein Bild mit PKW vor sich hat aus dem hervor geht, wie das Verhältnis von Fz-Breite zu Fahrbahnbreite ist. Maximal nur Gewichtsbeschränkungen an beispielsweies Brücken im Abschnitt werden wit vorher angekündigt, alles andere nur direkt vor dem Hinderniss selbst. Der LKW erkennt das Problem erst wenn er davor steht. Das ist durchaus üblich, aber mehr brauchts ja auch nicht. Der Mapper kann am Hindernis direkt ablesen, welche Breite (oder auch Höhe) das Hindernis zulässt. Das ist aber eine Eigenschaft des Hindernisses (z.B. Unterführung) und nicht der Strasse und soll auch dem Hindernis zugeordnet werden. Bröckelhafter Ausbau ist hier Normalzustand. Müsste man gute und schlechte Abschnitte über den Highway tag abbilden, es würde ein bunter Mix aus kurzen Schnipseln entstehen. Das auf das highway-tag abzuladen ist auch keine gute Idee, solange die Tendenz zur verbindungsorientierten Abbildung geht. Wenn man will, dass die Info nicht vom nächsten highway- Spezialisten überschrieben wird, benutzt besser ein geeignetes, direkt und eindeutig auf den Ausbau bezogenes Attribut. Klar geht das so nicht auf den Millimeter, aber allemal um Lichtjahre genauer wie Schätzen oder Fehlinterpretationen über Bauvorschriften, die im Einzellfall garnicht auf die vorliegende Straße anwendbar sind. Fotometrische Auswertung ist aber nicht jedermanns Sache. Bauvorschriften dürfen natürlich nicht blind vorausgesetzt werden, so nach dem Motte, dass man allen Bundesstrassen einfach eine Standardbreite zuweist. Aber man kann die Information geben, dass im Bundesland xy folgende Standardbreiten angewendet werden und dann muss man nur noch prüfen, ob man davon etwas anwenden kann. Gruesse Hubert -- Sarah Kreuz, die DSDS-Siegerin der Herzen, mit ihrem eindrucksvollen Debütalbum One Moment in Time. http://portal.gmx.net/de/go/musik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht Datum: Sun, 22 Nov 2009 15:04:51 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Relationen besser als Tags? das halte ich nach wie vor fuer einen umstaendlichen und vor allem unnoetig abstrakten Weg, die Realitaet abzubilden. Zudem verliert man Lagedetails. Ein klein wenig abstrakt vielleicht, aber gleich unnoetig abstrakt? Und die Lagedetails, die man verliert, sind meist pseudogenau. Radwege werden z.b. gerne mal im Abstand der Visualisierung angepasst und auch wenn nicht ist die Angabe 'dieser Bereich ist 3m breit' fast immer genauer als der versuch, parallele Linien per Hand reinzumalen. Ich habe in der Vergangenheit hier schon Beispiele gepostet (zugegebenermassen extreme), wo man am Ende auf ueber 30 einzelne virtuelle Spuren kommt. Und warum nimmt man nicht die 95% der Wege zum vorbild, die nicht extrem sind und macht fuer die eine passende Abstraktion? Fuer die 5% Rest kann man dann immer noch ueberlegen, ob man aufdroeselt. Da blickt man selbst mit Editorunterstuetzung kaum noch durch, vor allem, weil diese Spueren ja noìicht durchgaengig laufen, sondern irgendwo anfangen und aufhoeren (d.h. splitten waere auch da ziemlich oft noetig). Kommt eben auf den Editor an, das im link gezeigte Plugin macht das alles schon ganz handlich. Und zum splitten: Auch beim Ansatz mit eigenen ways fuer jede Spur wird gesplittet und nicht zu knapp. Aber nicht nur eindimensional wie beim Vorschlag hier, sondern das ganze Netz wird gespreizt. Ich plaediere fuer den Ansatz, die Spuren und divider separat zu mappen, und dann ueber Relationen die Verbindung bzw. den Bezug herzustellen (z.B. auch, wenn es eine trennende Mauer ist, aber auch, um bei parallelen Spuren eine unterbrochene oder durchgezogene Linie abzubilden). Wenn es eine physische Trennung (Mauer, Gruenstreifen) gibt, wird ja i.A. schon immer mit getrennten ways gearbeitet. Neben der erhoehten Lagegenauigkeit sehe ich dabei auch einen Vorteil in der unmittelbaren Abbildung der Realitaet (einfacher fuer den Mapper), und auch ohne extreme Erweiterung der Tools ist das Resultat besser nachvollziehbar und optisch ueberpruefbar. Ich bezweifle eben, dass ein ganzes Geflecht von ways besser handhabbar ist als ein way, dessen Gestalt ueber Zusatzinfos ausgearbeitet ist. Besonders bei den Relationen, die die Beziehungen der Spuren untereinander klaeren sollen, bin ich bei Einzelways skeptisch. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht Datum: Fri, 20 Nov 2009 21:20:52 +0100 Von: Nils Heuermann w...@oemmes.net An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Relationen besser als Tags? Hallo, thematisch sind es schon 2 verschiedene Dinge (die sich u. U. direkt ergänzen können); ich hatte meine Aussage eher aufs Prinzip mit Start-/Endnode bezogen, damit die Wege nicht zerstückelt werden. Hatte ich auch so aufgefasst. Aber wenn man sich mit dem einen Beschäftigt, stolpert man fast zwangsläufig über das andere. Was vielleicht ein wenig untergeht ist die Sache mit der Bezugslinie. Soweit ich das sehe, gehts du ja davon aus, dass die Basislinie als linke Seite der Richtungsfahrbahn angenommen wird, richtig? Damit 'waechst' die Fahrbahn mit den unterschiedlichen Spuren und Breiten in Fahrtrichtung rechts. genau. Also Vorwärts-Spuren (mit partnum +) sind in der Regel rechts, Rückwärts-Spuren (mit partnum -) links, von der Mitte (ergo dem OSM-Way) aus gesehen. Wobei hier nicht die Richtung des Ways entscheidend ist, sondern die der Relation (Start-/Endnode). Meiner Erfahrung nach ist das auch die einzige Methode, das optisch richtig hinzubekommen. Abgesehen davon, dass die Darstellung vom Plugin noch lange nicht perfekt ist, habe ich vor allem bei Einbahnstraßen überlegt: Wahrscheinlich müsste man dort die Spur (wenn es nur 1 ist) auf die Mitte zeichnen bzw. rechts/links immer gleich viele Spuren. Wird jedoch auch nicht immer passen... Ich bin das Thema mal vor ein paar Jahren angegangen: http://lists.openstreetmap.org/pipermail/talk-de/2007-July/001651.html (flickr link im Beitrag) Damals hatte ich mich dafuer entschieden, auch Einbahnstrassen mit Linksorientierung darzustellen, denn so kann man die an Kreuzungen gut erkennen. Zusaetzlich habe ich auf das Zeichnen der linken Linie verzichtet, um mehr Details erkennen zu können. Deshalb auch die etwas eigenartige Optik beim Autobahnkreuz. Mit etwas Übung sieht man aber direkt, ob die Richtungen der Einbahnverbinder stimmen. Die Visualisierung war mehr als Testsysem gedacht, denn als realistischer Renderer und verwendete die wenigen Tags die damals üblich waren. noch nicht getestet, aber im Moment wird es dort genauso aussehen wie überall ;) Bei mir hat er bei Linksverkehr die Darstellung ziemlich versaut, weil die Spuren über die Mittellinie rübergewachsen sind, deshalb der kleine Hinweis. Man hätte dafür ja 2 Möglichkeiten: 1) Zusätzlichen Tag, der Linksverkehr angibt, sodass man direkt Bescheid weiß und die Teile getauscht werden: rechts - links (nicht die Richtung) usw. Hab das damals damit hinbekommen, dass man die Werte bei Linksfahrländern negativ angibt. Länderregeln sind bei OSM so eine Sache - sie wären eigentlich für vieles die eleganteste Lösung, aber es gibt keine vernünftige Infrastruktur dafür, so entnehme ich das jedenfalls den laufenden Diskussionen. Ich bin grade wieder ein wenig am basteln und verwende ein paar Komponenten des alten Ansatzes weiter. Wenn sich dabei die Querverbindung zu deinem Ansatz nutzen lässt, umso besser :) Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht Datum: Thu, 19 Nov 2009 20:54:01 +0100 Von: Nils Heuermann w...@oemmes.net An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Relationen besser als Tags? einen prinzipiell fast identischen Ansatz (auch zu segmanted_ways) habe ich mir in letzter Zeit ebenfalls erdacht. Schon interessant, dass dazu auf einmal mehrere unabhängige Ideen entstehen. Wobei ich bei dem einen Ansatz den Fokus darin sehe, dass man die Fragmentierung entlang des Weges in den Griff bekommt und bei deinem Ansatz mehr die Querschnittsbeschreibung. Aber die beiden Dinge sind schon verwandt zueinander. Meinen Ansatz habe ich im Wiki zusammengefasst: http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts Genial, besonders die Idee mit dem Plugin. Was vielleicht ein wenig untergeht ist die Sache mit der Bezugslinie. Soweit ich das sehe, gehts du ja davon aus, dass die Basislinie als linke Seite der Richtungsfahrbahn angenommen wird, richtig? Damit 'waechst' die Fahrbahn mit den unterschiedlichen Spuren und Breiten in Fahrtrichtung rechts. Meiner Erfahrung nach ist das auch die einzige Methode, das optisch richtig hinzubekommen. Der kleine Haken dran ist, dass dann beruecksichtigt werden muss, auf welcher Seite gefahren wird. Hast du dein Plugin schon mal in England getestet? Ich werde mich auf alle Fealle noch genauer mit deinem Ansatz auseinandersetzen, denn es ist bisher das beste, das ich zum Thema der Beschreibung von Strassenquerschnitten bei OSM gesehen habe, besonders weil es sich auf innerorts (Gruenstreifen, begleitende Wege) und ausserorts (Autobahn, Abbiegespuren) gut anwenden laesst. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handy für OSM
Original-Nachricht Datum: Fri, 20 Nov 2009 12:33:49 +0100 Von: marcus.wolsc...@googlemail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Handy für OSM On Fri, 20 Nov 2009 11:18:40 +0100, Peter Körner osm-li...@mazdermind.de wrote: Dieter Jasper schrieb: Hallo Liste, da ich nun als bisher Handy-Vereigerer ein Handy brauche, hätte ich gerne Info über Handys ,die auch gut für OSM geeignet sind: Wie wäre es mit einem iPhone? MotionX GPS als Tracker, Fotos sind automatisch Georeferenziert und ein Voice Recorder liegt auch bei. Beliebiges Windows-Mobile Handy mit GPS und/oder Bluetooth(für externes, genaueres GPS). Optional mit Kamera. Als Windows- und iPhoneverweigerer bin ich am ueberlegen ob ich mir ein Nokia N900 zulege. Kamera, GPS Co ist alles an Bord und getrieben wird das Ding offensichtlich von einem recht originalem Linux. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leerstehende Ladenlokale
Original-Nachricht Datum: Mon, 16 Nov 2009 00:34:15 +0100 Von: Garry garr...@gmx.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Leerstehende Ladenlokale Es gibt Leute, die gehen nicht ohne Not zum Makler um ihm das Geld in den Rachen zu werfen. Und warum soll nicht jemand auch OM zu Hilfe nehmen können wenn er bei Gelegenheit in einen seinen Bedürfnissen besser entprechenden Verkaufsraum wechseln möchte? OSM wäre dazu auch eine zentrale Anlaufstelle während es Immobilienportale und Makler tausende gibt. Absolut richtig, solche Anwendungen sind es, die aus einer simplen Datanbank den Mehrwert rausholen. Aber wie schon bei den Weihnachtsmaerkten entwickelt sich die Diskussion in eine eigenartige Richtung. Loeschen oder nicht loeschen ist doch nicht die Frage, sondern wie man das alles so strukturiert, dass man an die Infos auch noch rankommt. Ein potentieller Wohnungssuchender hat wenig von einer DB, in der die Info die er sucht, in staendig wechselnden Tags versteckt ist und wer nicht gerade nach der Wohnung sucht, den interessiert die Info nicht. Das schreit doch gerade nach Datenoverlays. Relativ statische Daten in die Basis-DB und temporaere Sonderfaelle in einen Overlay, der sich bei der Ortung auf OSM-Basisdaten bezieht. Es ist jedenfalls von Vorteil, wenn man sich OSM-intern mal drueber gedanken macht. Denn ein Externer, der OSM fuer ein Immoportal nutzen will, braucht die Community nicht und es ist dann fraglich, ob in dem Fall etwas zurueckfliesst. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenSeaMap auf der boot in Düsse ldorf
Original-Nachricht Datum: Wed, 11 Nov 2009 11:26:27 +0100 Von: Frederik Ramm frede...@remote.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] OpenSeaMap auf der boot in Düsseldorf Hallo, Eigentlich will OpenSeaMap am liebsten eien Reihe internationaler Standards auf OSM abbilden - so etwas haben wir noch nie gemacht und es ist total OSM-untypisch; Bzw. eine kleine Minderheit wettert sehr lautstark gegen jede Standardisierung und Konsensbildung und legt fest, was die OSM-Prinzipien zu sein haben. bei OSM wird normalerweise immer das Rad neu erfunden. Das stimmt, immer wieder neu und parallel und keiner kommt auf die Idee, an den vier Ecken aehnliche Raeder anzuschrauben. Man hat ja mittlerweile das Rad viermal neu erfunden also soll auch bitte von jeder Sorte eines ran ;) Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzregeln für OpenStreetMap?
Original-Nachricht Datum: Mon, 9 Nov 2009 15:02:41 + (UTC) Von: Sven Geggus li...@fuchsschwanzdomain.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Relevanzregeln für OpenStreetMap? Nop ekkeh...@gmx.de wrote: Zu guter letzt haben wir es bisher nicht geschafft, uns auf das Tagging von Basiselementen wie Radwegen zu einigen, da möchte ich nicht wirklch versuchen einen Konsens für Relevanzregeln auszudiskutieren. :-) Ich halte eine solche Diskussion für Unfug, weil das Problem bei OSM so nicht existiert. Na ja, Definitionssache ;) Sobald man in die Anwendungsebene wechselt, steht man exakt vor dem Problem, was man als relevant auswertet. Es ist ja heute schon faktisch unmoeglich, alles in der Form auszuwerten, in der es mal vorgesehen war, da die Selbstreinigungskraft der DB dafuer nicht ausreicht. Die reale Relevanz besteht also auch darin, ob meine Eintragungen von allen Applikationen, von wenigen oder von keinen ausgewertet werden... -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht Datum: Sat, 07 Nov 2009 14:32:00 +0100 Von: Tirkon tirko...@yahoo.de An: talk-de@openstreetmap.org Betreff: [Talk-de] Relationen besser als Tags? Hallo Man mappt die Straßen zunächst einmal als Grundgerüst. Jede Straße verläuft grundsätzlich ungeteilt zwischen den zwei nächsten Abzweigungen (bzw Kreuzungen). Eine Teilung der Straße ist also nur noch möglich, wenn eine neue Abzweigung eingefügt wird. Ansonsten ist eine Straße unteilbar. Die Straßen erhalten grundsätzlich keine Tags. Entspricht der gaengigen graphenorientierten Abbildung, die sich anderswo sehr bewaehrt hat. Ein Strassen- oder Wegstueck ist dabei die Verbindung zwischen zwei Netzknoten. Es bleibt das Problem der Fragmentierung, wenn sich wichtige Eigenschaften innerhalb einer Verbindung ändern. Damals vor API 0.5 habe ich das Konzept von Segment/Way mal als Lösungsansatz gesehen, aber das Problem der Fragmentierung wurde damit ebensowenig gelöst wie mit der heutigen Abbildung. Im Prinzip hat man den damaligen Fehler nur eine Stufe weiter geschoben und der war schon immer, dass alles Attribute haben kann, die auch konkurrieren können. Damals warens Segment und way und heute sinds way und relation (und die node-Attribute wurschteln ja auch noch mit rein). Deshalb finfde ich deinen eigenschaftsorientierten Ansatz absolut klasse, denn Attribute werden immer komplexer und es sollten auch Attributsgruppen- und Bäume möglich sein. Von hier bis dort heißt die Straße XY-Straße. Also Relationen die sich entweder auf ein Stück einer Verbindung beziehen oder Verbindungen verknüpfen (aktuell die einzige Möglichkeit) oder Verbindungsstücke verknüpfen - klingt gut. 1) Funktioniert das Eigenschaftskonzept grundsätzlich? Davon kann man wohl ausgehen, aber die Sache hat einen Haken. Das Konzept ist sehr mächtig, mächtiger als die aktuellen Relationen. Ohne eine Richtschnur, die vorgibt, wohin man eigentlich will, läuft das Konzept Gefahr, die alten Fehler nochmal zu wiederholen und ein noch schlimmeres Dickicht zu schaffen. Gruesse Hubert -- DSL-Preisknaller: DSL Komplettpakete von GMX schon für 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht Datum: Sat, 07 Nov 2009 19:52:27 +0100 Von: Tirkon tirko...@yahoo.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Relationen besser als Tags? Voraussetzung dafür ist natürlich eine sehr breite Zustimmung für ein neues Konzept innerhalb der Community. Oder eben man macht einen begrenzten Feldtest mit einem eigenen Datensatz an dem man die Vorteile demonstrieren kann. So könnte das Umdenken der User so langsam wie erforderlich stattfinden und mögliche Konzeptkorrekturen am lebenden Modell erprobt werden. Ich denke aber mal, dass ein gutes Konzept, das dem User als auch dem Programmierer der Anwendungen von vielen Beschwerlichkeiten und Begrenzungen eines alten Konzeptes befreit und zudem durchsichtiger ist, dem neuen OSM die User in Scharen zutreiben würde. Wenn dann OSM 1.0 verwaist, dann wird die Umschaltung auf OSM 2.0 schneller erfolgen, als mancher zu träumen gewagt hätte. So sehe ich auch meine eigenen Arbeiten - Brainstorming für eine mögliche 2.0 oder irgendeine Mischform. Derzeit teste ich mit einem Geometrielayer rum, der über das Knoten-Link-Konzept noch hinausgeht. Ich will keine Brüecken mehr mit zig Einzelelementen abbilden, sondern als Objekt in Abhängigkeit einer Kreuzung zweier Geometrieelemente. Was oben ist und was unten und die Breite der Brücke (ein bool und ein real) reichen zur Beschreibung, alles andere ist geometrisch bestimmt, zumindest in guter Annäherung. Mal schaun obs klappt. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen besser als Tags?
Original-Nachricht Datum: Mon, 9 Nov 2009 19:20:48 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Relationen besser als Tags? es gibt ja auch den Fall, dass oben mehrere Ways laufen, da waere es schoen, diese unterscheiden zu koennen in mehrere parallele Bruecken und mehrere Ways ueber eine gemeinsame Bruecke. Ich zeichne derzeit (vereinzelt) den Brueckenumriss und tagge das mit bridge=area. Freilich gibts das alles, aber die Masse der Brücken folgt einfachen Regeln, die sich automatisieren lassen sollten. So eine Vorgabe kann man automatisch rechnen und wenns mal nicht ins Schema passt, löst man die Automatik auf und verbessert manuell, um auch noch die letzten Exoten abzubilden. Wenn z.B. 90% aller Strassenbrücken symmetrisch sind, kann das für diese 90% der Rechner viel exakter berechnen als ich das je mit josm und geübten Auge hinbekommen würde. Ein (GPL-lizensierter-) Editor ist in Arbeit, aber bei max. 0.5h/Tag Zeit dafuer gehts eben nur langsam voran. Gruesse Hubert -- DSL-Preisknaller: DSL Komplettpakete von GMX schon für 16,99 Euro mtl.!* Hier klicken: http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich?
Original-Nachricht Datum: Sun, 08 Nov 2009 10:37:23 +0100 Von: Frederik Ramm frede...@remote.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Was macht OSM in Deutschland so erfolgreich? Angenommen, der Reiseveranstalter Sunny Travel hat fuer alle Hotels in seinem Katalog eine interne Hotel-Id. Um die nun huebsch auf einer OSM-Karte eintragen zu koennen, versieht er die betr. Hotels in OSM mit dem Tag sunny_travel:id=1234. Grundsaetzlich ist das zwar von der Tag-Freiheit gedeckt, aber man kann sich leicht ausmalen, dass das nicht skaliert und das OSM hier unter der Faulheit oder Unfaehigkeit des Anbieters leidet, die Sache besser zu organisieren. Ich neige dazu, zu fordern, dass alle Information in OSM zumindest theoretisch fuer jeden Menschen verstaendlich und nuetzlich sein muss. Andererseits waere u.U. selbst die Information, dass ein bestimmtes Hotel by Sunny Travel die ID 1234 hat, fuer mich nuetzlich, koennte sie doch eventuell eine Buchungsanfrage vereinfachen... Also das vom grossen Verteidiger des regellosen Eintragens noch lesen zu dürfen ;) Genau auf das wollte ich doch immer raus und habe dafür nicht gerade nette Kommentare geerntet. Jeder kann zwar 'stone in my shoe' eintragen, aber es bleibt für alle anderen eine Dateileiche. Damit die Informationen fuer jeden verstaendlich und nützlich sein können, ginbts aber nur zwei Wege. Entweder schreibt man Prosa rein, so dass die Kommunikation über die normale Sprache geht oder man entwickelt eine gemeinsame Sprache für die Inhalte, also ein Beschreibungsmodell. Mit deinen Aussagen wie 'niemand bei OSM will ein Modell entwicklen' und Forderungen nach der Abschaffung oder Entmachtung des Wikis, gehen die Forderungen nach Verständlichkeit und Nützlichkeit nicht gut zusammen. Wenn ich kein Nachschlagewerk für die Bedeutung habe, muss ich mir selber ausmalen, was gemeint sein könnte und zumindest aus meiner Sicht bleiben dann Verständlichkeit und Nützlichkeit auf der Strecke. Tagnamen alleine sind nicht sprechend genug. Grüsse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenklassifizierung
Original-Nachricht Datum: Fri, 6 Nov 2009 09:03:34 +0100 (CET) Von: Dirk Stöcker openstreet...@dstoecker.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Strassenklassifizierung Die Frage ist, was die Highway-Klassifizierung sein soll. *seufz* Was von Anfang an das Problem war. Niemand weiss, was es sein soll und jeder interpretiert munter rein. Dass die meisten die Bedeutung reininterpretieren sah man letztens bei der Abstimmung recht gut und man sieht es auch in der Karte. Dein Gegenüber sucht eine 1:1-Umsetzung der englischen Verhältnisse. Das geht nicht. Was genau geht nicht? Sind die engl. Verwaltungsklassen wirklich so aussagekraeftig, dass man sie blind anwenden kann oder gibts auch auf der Insel Konflikte wie wir sie hier haben? Ich habe eine Klassifizierung in Deutschland gesucht, die dem Original entspricht, intuitiv ist und der gelebten Kartenrealität entsprach. Diese nutzt JOSM jetzt. Die gelebte Kartenrealitaet ist, dass es keinen Sinn macht, sich gross gedanken drueber zu machen, was man wie eintragen soll. Der naechste interpretiert was anderes rein, nutzt einen anderen Editor oder was auch immer der Grund ist, dass er die Klasse aendert. Egal, wer sich wenig Muehe bei den Klassen gibt und sich nicht daran stoert, dass die Karte nicht die vor Ort wahrgenommene Realitaet wiedergibt, hats bei OSM leichter. Strassen, die ich mal eingetragen habe, kann jedenfalls jeder aendern, wie er lustig ist. Ich werde da weder nacheditieren, noch Kontakt aufnehmen. Warum auch? Bei OSM ist laut Definition ja immer alles richtig ;) Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenklassifizierung
Original-Nachricht Datum: Tue, 3 Nov 2009 08:41:06 +0100 Von: Martin Simon grenzde...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Strassenklassifizierung Loswerden muss man es ja nicht komplett, aber eine gewisse Demokratisierung oder Entmachtung des verwirrten Königs Highway der XIII. wäre schon wünschenswert. ;-) Runter mit dem Kopf! ;) Tumulte in der das sieht in Mapnik nicht richtig aus-Fraktion. Teilweise könnte ich das auch nachvollziehen - man müsste halt sicherstellen, daß die Verbindungsklasse angemessen berücksichtigt wird und trotzdem in der Übergangszeit das Rendering von highway=* ohne connection_level=* nicht vollkommen kaputt ist - obwohl wir nicht für den Renderer mappen ;-) Einfache Regel: Wenn connection_level nicht vorhanden ist, wird highway wie bisher verwendet. Ich sehe auch keinen zwingenden Grund, connection_level flaechendeckend einzufuehren. Er wird ja hauptsaechlich dann gebraucht, wenn highway nicht konfliktfrei vergeben werden kann. Also die alte unwichtige Staatsstrasse bleibt z.B. bei highway=secondary, aber bekommt die Verbindungsklasse tertiary oder unclassified, bzw. einem Ersatz dafuer (unclassified passt als Beschreibung zu untergeordneter Verbindung eher schlecht) Wie siehts eigentlich mit dem neuen deutschen (na ja, besser Festlandseuropaeischen) Mappingstil aus? Der waere doch eine ideale Spielwiese fuer sowas. Nun ja, wenn die Darstellung plötzlich in der Gesamten Welt bescheiden ist, außer in einem kleinen germanischen Dorf, das tapfer die Renderregeln umgekrempelt hat, dürfte es schwierig sein, die Leute *nicht* gegen sich aufzubringen... ;-) Ein weicher Uebergang, der ohne das Aufmischen von Roemischen Legionen auskommt, sollte moeglich sein. Gruesse Hubert PS. Bin noch nicht dazu gekommen, mich um die Wikiseite zu kuemmern, aber ich habs nicht vergessen. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Back to the roots? war: Semikolon als Trenner
Original-Nachricht Datum: Tue, 3 Nov 2009 00:24:24 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen) Am 3. November 2009 00:11 schrieb Florian Gross flor...@grossing.de: Und was macht man dann, wenn es im Stockwerk darüber ein Bastelgeschäft ist und darüber noch eine Pizzeria? in diesem Fall definitiv verschiedene Nodes, da ja auch die Layer-Tags unterschiedlich sind (so wie alle anderen Tags auch). Falls sich Deine Frage auf die Adresstags bezieht: sauber wäre wohl eine Relationslösung, wo man diese gemeinsamen Tags als Haus zusammenfasst und nur der Relation mitgibt, gehackt könnte man wohl auch jedem der Nodes (oder Polygone) die kompletten Adressdaten mitgeben, zur Unterscheidung ggf. mit einem Tag für das Stockwerk. Nur mal so als Frage: Denkt eigentlich einer von euch noch an den armen Mappinganfaenger, der das alles verstehen soll? Letztens gabs ja die Diskussion, warum andere mehr POIs haben und OSM da nicht ganz so gut in die Puschen kommt. Wer hier und bei anderen aehnlichen Diskussionen mitliest, ist doch wohl eher verunsichert als alles andere. Bei aller Liebe zur Detailversessenheit - die Mapper muessen begreifen koennen, was sie machen koennen und machen sollen. Gerade POIs koennen gut von Gelegenheitsmappern kommen, denn die uebliche Vorstellung davon ist, dass es ein einfacher Ort ist, den man mit einer Node abbilden kann. Da ist etwas und das ist genau dort, Punkt. Also zwei, drei, oder mehr Nodes fuer einen Ort (lat,lon), die dann die Hoehe (=Stockwerk) beschreiben? Am gleichen Ort oder nur nahe beieinander? Wie nahe und meckert da dann der Validator? Mehrere Nodes fuer mehrere Funktionen an einem Ort? Nicht nur die Auswertung ueber die Maschinen wird da zum Problem, sondern auch die Verwirrung bei den potentiellen Mappern, die dann vielleicht lieber garnix eintragen, bevor sie sich mit diesem Dickicht auseinandersetzen. Nur so meine Gedanken beim Durchlesen des Threads Gruesse Hubert -- DSL-Preisknaller: DSL Komplettpakete schon für 16,99 Euro mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Back to the roots? war: Semikolon als Trenner
Der wollte mich doch nur aergern (glaubt zu wissen) ;) -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Back to the roots? war: Semikolon als Trenner
Original-Nachricht Datum: Tue, 3 Nov 2009 13:43:58 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: qbert biker qbe...@gmx.de CC: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Back to the roots? war: Semikolon als Trenner nochn Versuch... Nur mal so als Frage: Denkt eigentlich einer von euch noch an den armen Mappinganfaenger, der das alles verstehen soll? Letztens gabs ja die Diskussion, warum andere mehr POIs haben und OSM da nicht ganz so gut in die Puschen kommt. Wer hier und bei anderen aehnlichen Diskussionen mitliest, ist doch wohl eher verunsichert als alles andere. hm, das ist doch eher ein seltenes Problem, dass man mehrere POIs für verschiedene Stockwerke hat, und das ist auch bei Google und anderen ein Problem: 3D-Daten in 2D-Darstellung. Darauf habe ich geantwortet. Es gab mal einen ausfuehrlichen Beitrag ueber den oeffentlichen 3D Modellierer bei Google in der c't. Das ist ein sehr maechtiges Werkzeug und es arbeitet in echtem 3D und versucht nicht, 3D mit einem 2D Werkzeug in den Griff zu bekommen. Aber das ist die Gebaeudeebene. Bisher habe ich keine Anhaltspunkte gefunden, dass Google die 3D Konstruktion mit den POIs verknuepft, sondern es sieht eher nach einer Abstraktion ueber die Adressen aus. unerheblich, sehr nahe beieinander ist wohl einfacher zu editieren und sonst wird vermutlich die eine oder andere Applikation wegen doppeltem Node meckern. Das Problem dabei ist, dass man normalerweise bei zwei Nodes zwei Objekte erwartet, die sich oertlich (lat,lon) voneinander unterscheiden und auch unterscheidbar sind. Ab welcher Neahe soll ich sie als ein Objekt mit verschiedenen Leveln (und Pseudokoordinaten?) betrachten oder brauche ich eine Relation, die mir erklaert, dass die zwei Punkte in Wirklichkeit nur einer sind, weils in die dritte Dimension geht? unerheblich, der meckert auch so öfters mal, ohne dass es stimmt. Und wer bestimmt, ob er jetzt berechtigt oder unberechtigt meckert? Aber egal, ich wollte nur zum Ausdruck bringen, dass Dinge, die feur die einen ganz einfach und logisch erscheinen, andere ganz locker zur Verzweiflung bringen koennen. Fuer anwenderfreundlich halte ich aber keines der hier diskutierten Konstrukte. Gruesse Hubert -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Back to the roots? war: Semikolon als Trenner
Original-Nachricht Datum: Tue, 3 Nov 2009 14:42:16 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Back to the roots? war: Semikolon als Trenner darum gings hier ja: Gebäudeebene. Randbemerkung: Wenn Du Dich auf Sketchup beziehst: das hat eher den Fokus einfach als mächtig. Im 3D-Bereich ist die meiste Software mächtiger als Sketchup, aber es hat halt den Vorteil, dass man mit wenig Einarbeitungszeit schon was zu Stande bringen kann, und dass es ohne Ende kostenlose Modelle (Ausstattung, Personen, Pflanzen, etc.) dafür gibt. Professionelle 3D-Software erfordert ansonsten meist monate- bis jahrelanges Erlernen. Professionelle 3D-SW ist auch nicht gefragt, denn es geht ja um sinnvolle Vereinfachung und normale User als Eintragende. ja, das Problem der verschiedenen Stockwerke bleibt daher auch ungelöst. Wenn man ein Problem darin sieht. Die Adresse ist eben und passt gut ins Konzept einer 2D Erfassung. Das Konzept: Hier ist das Gebaeude, das hat eine Adresse und darauf beziehen sich alle POIs darin ist ja nicht unpraktisch fuer Eintragende und Nutzer. Dahinter kann man ja einen unformatierten beschreibenden Text setzen, so wie der aufpoppt wenn man bei Google einen POI anklickt. Dann kommt eben Arztpraxis Dr. Wimmermeier 2. Stock links im Klartext. tun sie ja, in der Höhe. Sind aber bestimmt ueber lat/lon und nicht ueber die Hoehe, das finden manche Leute ziemlich verwirrend und unlogisch, z.B. ich ;) Und wer bestimmt, ob er jetzt berechtigt oder unberechtigt meckert? der Mapper. Und wenn der das gar nicht will, sondern sich vom Validator eine Hilfestellung erhofft? Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenklassifizierung
Original-Nachricht Datum: Tue, 3 Nov 2009 16:34:38 +0100 Von: Falk Zscheile falk.zsche...@googlemail.com An: m...@koppenhoefer.com, Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Strassenklassifizierung Was mich stört ist die Darstellung der Verwaltungsklasseneinteilung. Liest man den einen oder anderen Beitrag so scheint es die Einteilung in die Verwaltungsklassen (Bundesstraße, Landes-/Staatsstraße, Kreisstraße, Ortsverbindungsstraße) sei eine vom Himmel herabgefallene Entscheidung ohne jeden Bezug zur Realität. Was wohl eher der Laenge der Diskussion geschuldet ist als der tatsaechlichen Aussage. Den Zusammenhang zwischen Verwaltungsklasse, Bedeutung und Ausbau bestreitet ja so gut wie keiner. Es geht eher darum, wie man vorgehen soll, wenn die mal auseinanderdriften und es passiert eben oft genug, dass man sich bei der von den Verwaltungsklassen vorgegebenen Wegfuehrung den Kopf kratzt. Tatsache ist aber, dass zwischen der Einteilung in eine Straßenklasse und dem Verkehrsaufkommen ein enger Zusammenhang besteht. Auf einer Straße die dem weiträumigen Verkehr dient (Bundes- oder Landes-/Staatsstraße) herrscht in der Regel ein höheres Verkehrsaufkommen als auf Straßen die dem Verkehr zwischen Kreisen oder aber nur Gemeinden dienen. Bund und Länder achten sehr genau auf die Verkehrsbedeutung (Verkehr und Ausbauzustand). Verliert eine Straße ihre Bedeutung so kann man sie herabstufen und ein anderer Straßenbaulastträger muss sich um die Unterhaltung kümmern. Das schont den Haushalt des bisherigen Baulastträgers. Reiche Kommunen wollen aber nicht immer warten und uebernehmen die Bautraegerschaft fuer eine Entlastungsstrasse oder eine alte Staatsstrasse gammelt vor sich hin, weil ihr eine Bundesstrasse die Bedeutung geraubt hat. Es ist eben nur eine typische Zuordnung aber keine absolute. Nur den Verkehr in Ballungsräumen und Städten bilden die eben aufgezeigten Definitionen nicht ab, weil hier das hohe Verkehrsaufkommen nur lokal zu bewältigen ist. Nur in diesem Bereich ist also eine zusätzliche Attributierung oder eine Loslösung von einer Eintragung nach Verwaltungsklasse geboten. Es gibt auch auf dem Land genug Beispiele für Verschiebungen. Bei Bundesstrassen funktionierts ja noch, aber Staats- und Kreisstrassen driften oft gewaltig. Scheinbar ists nur wirklich lukrativ, dem Bund die Kosten zuzuschieben. Die meisten Mapper wohnen in Städten und Ballungsräumen. Das darf aber nicht dazu führen dort auftretende Probleme auch auf ländliche Regionen zu beziehen und Lösungen auch auf diese zu verallgemeinern. Innerhalb der Stadtgrenzen sind normalerweise nur noch Bundesstrassen sichtbar und das auch nur, weil die an Vorfahrtsschildern und Wegweisern herausgehoben beschildert sind. 'secondary', 'tertiary' und 'unclassified/residential' werden da ja schon lang anhand der Bedeutung eingetragen. Aber auf dem Land aergerts mich eben, dass ich weder die kreuzungsfrei (1 Spur/Richtung) ausgebaute Kreisstrasse gut beschreiben kann, noch die total heruntergekommene Staatsstrasse mit rein lokaler Verkehrsbedeutung. Und über solche Relikte stolpere ich auf dem Land nur zu oft. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenklassifizierung (was:Gratulation!)
Original-Nachricht Datum: Sun, 1 Nov 2009 12:20:34 +0100 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Christoph Eckert c...@christeck.de CC: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Strassenklassifizierung (was:Gratulation!) Hallo, d) in Anlehnung an RAS-N ((Richtlinien für die Anlage von Straßen) - großräumige und überregionale Straßenverbindung (primary) - regionale und zwischengemeindliche Straßenverbindung (secondary) - flächenerschließende oder untergeordnete Straßenverbindung (tertiary) Vorschlag d) gefällt mir nicht, da ich ein Problem mit der Umsetzung der dort definierten Stufen habe. Eine Verbindung kann ja auch sehr wichtig sein, obwohl sie nicht quer durch die ganze Republik geht, zwischengemeindlich könnte also z.B. durchaus auch primary sein. Ist ausserdem ein bisschen lang. Mit einer allzu simplen Zuordnung wird man sehr schwierig erreichen, dass der Nutzer der Karte mit den Inhalten etwas anfangen kann. Bei der haendischen Planung will der einfach nur gut informiert werden, wo er mit welchem Verkehrsmittel am besten durchkommt. Ich kann mir nicht vorstellen, dass das jemals mit einem einfachen abschreiben einer externen Kategorie zu erschlagen ist. Ich sehe in der Zuordnung der Klassen zu den realen Strassen eine kreativen und kommunikativen Vorgang. Der, der die Strasse kennt, teilt den anderen mit, wie er diese Verbindung beurteilt. Was hier fehlt ist eine Sprache, der man sich bedienen kann, damit das nicht komplett ins subjektive abdriftet (auf der Strasse fahr ich nicht gerne und ausserdem ist da immer Stau und deshalb werte ich sie ab, oder aehnlich). Was andere (z.B. die EU mit GDF) versucht haben, ist so eine Sprache aufzubauen und das in Form eines Modells. Wenn man von simplen Zuordnungen wegkommen will, die immer an irgendeiner Stelle haken, braucht OSM ein eigenes Beschreibungsmodell, das von den Leuten weiterentwickelt wird, die es benutzen, die Mapper. a-c machen darüberhinaus allesamt deutlich, dass es sich um eine Hierarchie-gliederung handelt. Genauer gesagt, ein hierarchisch aufgebautes Netz. Die untere Klasse fuellt die Maschen des Netzes der hoeheren Klasse. In einer realen Karte starten und enden Verbindungen nicht irgendwo, sondern fast immer an Knoten des Netzes der hoeheren Klasse (ausser die Topologie leasst das nicht zu - Sackgassental). Eine secondary startet und endet typischerweise an primary oder hoeher oder an einer anderen secondary. Verwendet man nur die Verwaltungsklassen zur Klassifizierung, ergibt sich so ein Netz, das ziemlich gut an die Darstellung rankommt, die man von den bekannten Karten gewohnt ist. Es bleibt der Konflikt, dass das nicht immer mit der besten Verbindung uebereinstimmt, wurde ja schon x mal durchgekaut. Dieser Konflikt ist nicht eindeutig aufloesbar und deshalb unterscheiden sich auch die Karten von verschiedenen Quellen in dieser Interpretation. Was aber alle Darstellungen (incl. OSM) verbindet ist, dass jeder bemueht ist, ein harmonisch wirkendes Netz zu zeigen. Ein Loesungsansatz ist eine weiche Interpretation, wie sie auch immer wieder im Wiki auftaucht: Nimm die Verwaltungsklassen und verschiebe nach Wichtigkeit bei Bedarf nach oben oder nach unten. Diese Wichtigkeit nach verschiedenen Kriterien besser greifbar zu machen koennte dann ein Modell leisten. Gruesse Hubert -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einfache serverbasierte Routingsoftware?
Original-Nachricht Datum: Wed, 28 Oct 2009 23:00:45 +0100 Von: Christoph Eckert c...@christeck.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Einfache serverbasierte Routingsoftware? Moin, Ich habe mal Navit dafuer vergewaltigt - Mit ein bischen patcherei kann man damit brauchbare ergebnisse erzielen - Und der vorteil ist das es sau schnell ist - C code halt ... Problem ist das Navit eigentlich nicht ohne frontend (grafisch) leben kann - das muss man rauspatchen ... der Routingalgo von Navit ist momentan AFAIK eher auf KFZ-Routing ausgelegt und versucht unabhängig von der Konfiguration, möglichst auf besser ausgebaute Straßen zu kommen. Für Sven daher eher ungeeignet. Ich glaube, ich muss mir den Kram mal wieder antun. Haben die eine Priorisierung fix eingebaut? Ansich sollte der Router den kuerzesten Weg ausgeben koennen und der ist eindeutig. Die Priorisierung soll da eigentlich nicht reinmurksen. Die Standardvorbelegung bei der Gewichtung der Abschnitte ist die Leange und entspricht der Vorgabe 'kuerzester Weg'. Eine gezielte Gewichtung nach Vorlieben und Verboten kann man ja dann immer noch draufsetzen. Jeder wie er will, das ist ja das schoene am Projekt hier. Niemand ist auf eine fix im Navi verbaute Engine angewiesen. Gruesse Hubert Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Google wieder mal aktiv
Ein Navi fuer alle kommenden Android 2.0 Nutzer: http://www.engadget.com/2009/10/28/google-adds-free-turn-by-turn-navigation-car-dock-ui-to-android/#continued Nur zur Info, grade so nebenbei aufgeschnappt. Gruesse Hubert -- Neu: GMX DSL bis 50.000 kBit/s und 200,- Euro Startguthaben! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google Maps - Update
Original-Nachricht Datum: Tue, 27 Oct 2009 11:54:53 +0100 Von: Tobias Wendorff tobias.wendo...@uni-dortmund.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Google Maps - Update Ich konnte mir die POIs endlich in Aktion ansehen. OMG ... die sind teilweise um 180° verdreht und teilweise komplett veraltet, ich schätze den Stand auf 2006. Na ja, aus Sicht des normalen Anwenders ist das ganze gar nicht so schlecht. Ich hab mal in Muenchen ein wenig rumprobiert und was ich kenne, war groesstenteils an der richtigen Stelle drin. Soll heissen, um nachzusehen, obs an der naechten Ecke eine Apotheke, Bank oder ne Kneipe gibt, reichts. Das mit den POIs hätte sich Google wirklich verkneifen sollen. Jetzt wird noch deutlicher, wie schlecht die Datenbasis ist. Kommerziell eben - langsam, so gut wie eben noetig aber auch stabil. Und wenn Google die Anwender auffordert, POIs zu korrigieren, erreichen sie derzeit noch mehr Leute als OSM - die Datenkraake lebt ;) Die Dynamik wird sich auch bei OSM noch aendern - heute sinds die Neuerfasser, die den Ton angeben, morgen sinds die Bestandssichter und Anpasser. Es bleibt eine spannende Frage, ob man letztere auf Dauer motivieren kann, denn nur dann bleibt OSM so tagesaktuell wie es heute ist. Gruesse Hubert -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
