Re: [Talk-de] Mal ganz anders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 qbert biker schrieb: Hab auch noch ein paar Verfeinerungen parat, z.B. dass man innen mehr als ein Rechteck nimmt, wenn das Polygon allzu krumm ist. Die andere ist, dass man aus den inneren Rechteckseiten und Polygonabschnitten kleinere Teilpolygone erstellt und dann auf die testet. Ist in Arbeit und wird kommen - relativ bald die schnelle Selektion auf ein Rechteck, z.B. um den Datenwust in den USA rauszufiltern. Was spricht dagegen, dafür das kleinstmögliche Rechteck zu nehmen in das das Polygon vollständig reinpasst? - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTrKtFUbODdpRVDwRAt9WAJ41MgR5z0P4GuIwXE51LGzHGUBjEwCgmdRy kAuncq8vqiNxw/Tp4wFoYsI= =GuR+ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, Was spricht dagegen, dafür das kleinstmögliche Rechteck zu nehmen in das das Polygon vollständig reinpasst? Die Sache wird dann interessant, wenn man exakt feststellen will, was alles innerhalb eines grossen Polygons ist. Ziel ist es dabei, die Fläche zu minimieren, innerhalb derer man konkret auf die komplexen Grenzen testen muss, weil die Rechtecksuche so viel schneller ist. Dazu hab ich mir eben ein paar Konzepte ausgedacht, um das zu optimieren. Das konkrete Problen oben: Ist das Polygon sehr faltig, kann das innere Rechteck gegen Null gehen, bei anderen Formen kann das umschreibende Rechteck sehr ineffizient sein. Nicht jedes Polygon ist so handlich wie D-Land. Grüsse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, zuerst mal zur Relation. So begeistert bin ich davon nicht, derart triviale Dinge in die Relations zu verlegen. Auf der way-Ebene sollte wenigstens eine Grundbeschreibung drin sein, dass man sich als Programmierer nicht durch einen Wust aus Relations durchwühlen muss, um rauszufinden, dass die Linie eine (wichtige) Straße ist. Man hat jetzt die Chance, auf der way-Ebene ein paar Grundlagen zu fixieren, mit denen ein lesendes Programm schon ein paar Vorannahmen treffen kann, um dann die Relations gezielt auszuwerten. So in dem Sinne: way-Ebene: 'Das ist ein Polygon oder eine Fläche' oder 'das ist eine Straße oder eine Waldgrenze' relation-Ebene: 'Dieser Wald grenzt an diese Straße' oder 'diese Nodes und Ways gehören zum Autobahnkreuz xy'. Man kann das jetzt fixieren oder darauf warten, dass das auf dem üblichen Weg über die Renderer geht, die tief in Relations versteckte Basisinfo einfach nicht finden und nicht darstellen. Super Idee... und woran machst Du die logische Wichtigkeit fest damit so eine Bewertung eindeutig bleibt und nicht von Mapper zu Mapper wieder verändert wird? Für den Lokalverkehr kann so eine Verbindung sehr wichtig sein (Z.B. Bypass für einen naheliegenden Ikea-Markt der die bisherige Strasse hoffnungslos überlastet), für den Fernverkehr ist sie dagegen bedeutungslos obwohl wesentlich besser ausgebaut - oder umgekehrt... - und jetzt? Da hilft wohl wirklich nur die 'functional road class' weiter. Was ähnlich ausgebaut ist, ist in einer Klasse. Die administrative Zuordnung ist die erste Näherung und in der nächsten Ebene sind Ausbauzustand und Vorfahrtregelungen dran. Im Beispiel sind dann Stxxx und MÜxxx in einer Klasse, weil das Ausbauzustand und Vorfahrt so vorgeben. Wenn man mit einer sauberen frc-Abbildung von 95% auf 99,x% konfliktfreier Straßenabbildung hochkäme, wäre das schon ein ganz schöner Fortschritt. Sonderfälle so wie im IKEA-Beispiel kommen dann in eine andere Ebene mit eigenem Tag. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Am Sonntag, 25. November 2007 schrieb qbert biker: Kurz die Beschreibung: | Stxxx | |__ Styyy | | MÜxxx === B12 Früher ging Stxxx in Styyy über. Jetzt hat der Kreis eine Verbindung zur nahen B12 gebaut (Kreisstr. MÜxxx). Die Staatsstraße Styyy hat ihre Bedeutung verloren und Straßenausbau und Vorfahrt wurden angepasst. Jetzt geht Stxxx unmerklich in MÜxxx über und die Styyy ist eine unbedeutende Abzweigung. Das will ich eintragen - auf der ref-Ebene ist das gar kein Problem. Das Problem ist, darzustellen, dass Stxxx-MÜxxx eine durchgängige Straße ist. Mit der strengen Anwendung der highway-Regel müsste ich Stxxx und Styyy als secondary eintragen. Optisch ergibt das den Eindruck einer abknickenden Vorfahrt, was komplett falsch ist und die wichtige Verbindung zur B12 geht optisch als tertiary unter. Naja, und wieder ein Beispiel, dass ein starres mapping zwischen organisatorischer Straßenkategorie und highway-tag nicht klappt. (Zumindest solange diese Tag noch von irgendeinem Programm wie renderer interpretiert wird. - Wenn man die highway-Tags ganz abschaffen würde hätte ich ja nichts dagegen eine eindeutige Zuordnung einzuführen ;-) Rapha ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hi, Eigentlich sollte man IMO besser die Start- und Endnodes der Einbahnstraße angeben. Kann man sowas nicht über eine Relation lösen? Macht halt mehr Aufwand, für den der es macht und für JOSM das darzustellen- und erzeugt mehr Daten. Momentan schon. Es wird aber sicher im Laufe der Zeit für Standardrelationen einfachere UI-Gesten geben. Cheers, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Das Rendern ist eh' noch ein Schwachpunkt im Projekt. Würde es einen leicht aufzusetzenden Renderer geben, dem man neue Stile ebenfalls recht leicht beibringen könnte, dann würden mehr Leute eine eigene Map aufsetzen. Wie wäre es mit einem Stil-Generator im Web? Man gibt die gewünschten Eigenschaften wie betroffenes Tag, gewünschte Farbe, gewünschter Linienstil, Icon-Dateiname, Zoomlevel etc. an und der Service spuckt die passende XML-Datei aus. Wenn ich nicht gerade an meiner Diplomarbeit schreiben würde, würde ich es auch selber machen. Gruß, Wabba ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, Die Selektionsroutine für ein Rechteck/Polygon fehlt noch, aber von der zeitabschätzung her ist das Parsen des XML-Files der kritischere Faktor. Taeusch' Dich da mal nicht. Ein halbwegs ordentliches Deutschland-Polygon hat eine hohe vierstellige Anzahl von Begrenzungspunkten, und Du musst fuer jeden Node, der in der Bounding-Box liegt, pruefen, ob er im Polygon ist. Das braucht zumindest bei mir den Loewenanteil der Zeit. (Noch nicht umgesetzte Optimierungs-Idee - ermittle zunaechst das groesste Rechteck, das noch innerhalb des Polygons liegt, und pruefe jeden Punkt des Planet-Files zunaechst auf liegt im aeusseren, wenn ja, dann auf liegt im inneren und nur wenn nein, dann auf liegt im Polygon.) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Moin, Wie wäre es mit einem Stil-Generator im Web? Man gibt die gewünschten Eigenschaften wie betroffenes Tag, gewünschte Farbe, gewünschter Linienstil, Icon-Dateiname, Zoomlevel etc. an und der Service spuckt die passende XML-Datei aus. grundsätzlich natürlich cooler als eine Standalone-Applikation. Allerdings würde dann die gesamte Rechenlast dem Server aufgebürdet; da braucht es schon ein dickes Eisen. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, erst braucht es ein sauberes, moeglichst anwendungsunabhaengiges datenmodell, das alle noetigen informationen klar und eindeutig darstellt. Ja, das denkt jeder Anfaenger ;-) Ich habe mit Jochen vor rund einem halben Jahr genau das gleiche gesagt: Das OpenStreetMap-Modell taugt nichts, wir muessen das von Grund auf neu machen. Fuer historisch Interessierte und des Englischen Maechtige: http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf Zu dem stehe ich auch heute noch (besonders die Zielsetzungen in 1.1). Auch wenn manchmal ein anderer Eindruck aufkommen koennte: Ich bin keineswegs der Ansicht, dass das OSM-Datenmodell irgendwie gut waere. Was ich halt inzwischen erkannt habe, und weswegen ich an diesem Datenmodell-Konzept nicht mehr weitergemacht habe, ist, dass das beste Modell nichts wert ist, wenn wir es nicht umgesetzt kriegen. Und das Umsetzen haengt halt von der Akzeptanz der Leute ab. Ich habe dann die hochfliegenden Ideen von einem sauberen Modell erstmal bleiben lassen und mich darauf konzentriert, dass wir wenigstens Objekt-Beziehungen in das aktuelle Modell reingefriemelt bekommen. Mittlerweile ist das technisch drin, aber bis wir die Leute dazu kriegen, das auf breiter Basis einzusetzen, bis Editoren und Renderer damit gut umgehen koennen, wird noch einige Zeit und Arbeit ins Land gehen. Die einzige Chance fuer ein sauberes, neues Datenmodell waere in meinen Augen die, dass man das separat entwickelt (mit allen Komponenten, Server, Editor, Renderer) und dann mit konvertierten OSM-Daten bestueckt und den Leuten live die Vorteile zeigen kann: Schaut her, bei uns sind Replikation, Rollbacks, beliebige Queries mit beliebigen Ergebnismengen, sauberes und performantes Rendering mit beliebigem Level of Detail, korrektes Routing einfach mit drin, weil unser Datenmodell gut designt ist, und das Editieren ist nicht mal schwieriger geworden als vorher. Wenn man einen solchen Punkt erreicht, dann bestuende eine Chance, begleitet von viel Politik, dass OSM komplett auf das neue Modell umsattelt. Alternativ kann man auch darauf verzichten, die Ueberzeu- gungsarbeit zu leisten, und einfach einen fork von OSM aufsetzen und schauen, wie es sich entwickelt, aber das waere so ein bisschen die Billigloesung; die Ueberzeugungsarbeit ist naemlich in meinen Augen der wahre Brocken. (Steve Coast hat neulich im Rahmen der Lizenzdiskussion mal zu mir gesagt, dass er annehme, dass man OSM heute noch komplett neu anfangen koennte, also bei Null beginnen mit einer PD-Lizenz, so dass man auch keine Daten aus dem existierenden OSM uebernehmen kann, sondern alles neu erfassen muss; er ist der Ansicht, dass man das schaffen koennte. Das waere natuerlich auch eine Chance fuer ein neues Projekt mit besserem Datenmodell - einfach nochmal von vorn anfangen. Ist nicht so abwegig, wie es klingt!) Hat man allerdings ausser einem sauberen Datenmodell nichts vorzuweisen - so nach dem Motto: Unser System kann nur die Haelfte von dem, was OSM kann, und das Editieren ist 3x komplexer, aber wenigstens *ginge* es jetzt theoretisch, dass man... - dann kann man es gleich bleiben lassen. Wir schreiben hier keine Diplomarbeit. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, Ziel wäre, ein Regelwerk zu entwickeln, mit dem man Straßen gut abbilden kann. Dieses Regelwerk soll von Programmen interpretiert werden können, so daß typische Anwendungen wie Router sicher darauf zugreifen können und sich nicht blind auf Vereinheitlichungen wie das highway-tag verlassen müssen. Das ist eine gute Idee. Ich wuerde der Expertengruppe dringend raten, mit Andy Robinson Kontakt aufzunehmen, der, wie ich mehrmals erwaehnt habe, ebenfalls an einer solchen feineren Klassifizierung arbeitet (oder arbeitete?). Es waere schade, wenn hier unnoetig das Rad an mehreren Orten zugleich erfunden wird. Bei Bedarf stelle ich den Kontakt gerne her. Denjenigen, die auch die englische Talk-Liste lesen, wird bewusst sein, dass dort auch gerade ueber das Thema diskutiert wurde; auch diese Diskussion sollte das Team natuerlich mitverfolgen und mit denen, die Ahnung zu haben scheinen, korrespondieren - damit wir keine Inselloesung entwickeln. Idealerweise sollte man die Gruppe gleich international aufsetzen. Manchmal haben die Australier oder aehnliche Randgruppen ;-) durchaus was interessantes zu erzaehlen, was Strassentypen usw. betrifft. Damit das nicht von vorneherein zum Scheitern verurteilt ist, werden die besonders strittigen Dinge wie das highway-tag erst mal aussen vor gelassen. Das war auch Andys Idee (minus erst mal). Das highway-Tag einfach lassen, wie es ist, und *zusaetzlich* Detail-Tags entwickeln. Langfristig koennte das dazu fuehren, dass das highway-Tag obsolet wird - muss aber nicht. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, nachdem das Chaos bei den Taggingregeln jetzt so ziemlich perfekt zu sein scheint, probier ichs mal ganz anders rum. Sehr defaetistische Ausdrucksweise fuer ein paar kleinere Unstimmigkeiten! Bei 95% aller Strassen duerften wir uns alle ueber das Tagging einig sein. Sachlich korrekt waere also eher, von Unstimmigkeiten beim Tagging, die rund 5% der Strassen betreffen, zu sprechen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Am Sonntag 25 November 2007 schrieb Frederik Ramm: Hallo, erst braucht es ein sauberes, moeglichst anwendungsunabhaengiges datenmodell, das alle noetigen informationen klar und eindeutig darstellt. Ja, das denkt jeder Anfaenger ;-) nein, das denkt jemand, der ein einfaches, klares system haben will, das jeder versteht, und nutzen kann, egal ob als mapper, entwickler, oder anwender. im moment sind wir weit von sowas entfernt. aber ich glaub, da erzaehl ich keinem was neues... Ich habe mit Jochen vor rund einem halben Jahr genau das gleiche gesagt: Das OpenStreetMap-Modell taugt nichts, wir muessen das von Grund auf neu machen. Fuer historisch Interessierte und des Englischen Maechtige: http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf Zu dem stehe ich auch heute noch (besonders die Zielsetzungen in 1.1). Auch wenn manchmal ein anderer Eindruck aufkommen koennte: Ich bin keineswegs der Ansicht, dass das OSM-Datenmodell irgendwie gut waere. Was ich halt inzwischen erkannt habe, und weswegen ich an diesem Datenmodell-Konzept nicht mehr weitergemacht habe, ist, dass das beste Modell nichts wert ist, wenn wir es nicht umgesetzt kriegen. Und das Umsetzen haengt halt von der Akzeptanz der Leute ab. Ich habe dann die hochfliegenden Ideen von einem sauberen Modell erstmal bleiben lassen und mich darauf konzentriert, dass wir wenigstens Objekt-Beziehungen in das aktuelle Modell reingefriemelt bekommen. Mittlerweile ist das technisch drin, aber bis wir die Leute dazu kriegen, das auf breiter Basis einzusetzen, bis Editoren und Renderer damit gut umgehen koennen, wird noch einige Zeit und Arbeit ins Land gehen. Die einzige Chance fuer ein sauberes, neues Datenmodell waere in meinen Augen die, dass man das separat entwickelt (mit allen Komponenten, Server, Editor, Renderer) und dann mit konvertierten OSM-Daten bestueckt und den Leuten live die Vorteile zeigen kann: Schaut her, bei uns sind Replikation, Rollbacks, beliebige Queries mit beliebigen Ergebnismengen, sauberes und performantes Rendering mit beliebigem Level of Detail, korrektes Routing einfach mit drin, weil unser Datenmodell gut designt ist, und das Editieren ist nicht mal schwieriger geworden als vorher. richtig, das ist die einzige sinnvolle loesung: parallel sauber entwickeln, und zwar durchgehend von editor ueber datenbank, bis zu den anwendungen (renderer, route, usw...) aufgrund der momentanen struktur koennte man den datenbank teil problemlos erstmal zurueckstellen, und ueber ein klares durchgehendes tagging-schema schon viel erreichen. allerdings sehe ich folgende probleme: 1. auf einer mailingliste mit hunderten von meinungen wird das nicht funktionieren, es braucht, wie qbert schonmal meinte, ein kleines team, dass sowas ausarbeitet, am besten zusammen an einem tisch. 2. es muss durchgehend funktionieren, d.h. man braucht leute die sich mit josm/potlatch, mapnik/osmarender, bzw. den anderen anwendungen soweit auskennen, dass sie diese entsprechend anpassen koennen. ich wuerde da mitmachen. ich hab ein - meiner meinung nach- brauchbares poi-schema, und mit gpsdrive eine anwendung, die osm-daten nutzt. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Die einzige Chance fuer ein sauberes, neues Datenmodell waere in meinen Augen die, dass man das separat entwickelt (mit allen Komponenten, Server, Editor, Renderer) und dann mit konvertierten OSM-Daten bestueckt und den Leuten live die Vorteile zeigen kann: Das sehe ich auch so. Ein neues Datenmodell steht und fällt mit der Möglichkeit, die bestehenden Daten zu übernehmen, denn niemand hat Lust, seine ganze Arbeit ein zweites Mal zu machen. Wenn diese Möglichkeit besteht, sehe ich wenig Probleme mit Überzeugungsarbeit, besonders wenn Renderer und Editoren besser sind als die bestehenden. Und wenn das Datenmodell offen ist, d.h. wenn es eine offen zugängliche Datenbank für Tags gibt. Keine Diskussionen mehr, keine Abstimmungen mehr - einfach einen Tag definieren, ein Icon dafür entwerfen, alles hochladen, und die Renderer würden sofort die entsprechenden Tags korrekt anzeigen. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Am Sonntag 25 November 2007 schrieb Frederik Ramm: Hallo, aufgrund der momentanen struktur koennte man den datenbank teil problemlos erstmal zurueckstellen, und ueber ein klares durchgehendes tagging-schema schon viel erreichen. Oh, dann haben wir aneinander vorbeigeredet, ich dachte, Du wolltest grundlegender ansetzen als bloss an den Tags herumzuschrauben. Meiner Ansicht nach muesste, wenn man es richtig machen will, auch das ganze Objektmodell umgestellt werden. wenn man's richtig machen will, ja. aber das liesse sich dann immer noch in einem zweiten schritt machen. Ich wollte an der Tatsache, dass jeder Taggen kann, was er will, gar nicht ruetteln, sondern praktisch einen Layer untendrunter erstmal etwas einfuehren, was Hand und Fuss hat. Naja, aber wie gesagt, ich hatte das ja eh aufgegeben. Wenn man bloss Tag-Kataloge erstellt, wird es vermutlich noch schwieriger, echten Mehrwert zu demonstrieren. es geht eben nicht nur um einen blossen tag-katalog, der ist nur die basis, die einheitlich vom mapping bis zur endanwendung benutzt werden muss. dazu muessen sowohl die editoren, als auch die renderer und was sonst noch kommt, entsprechend angepasst werden. ein grundkatalog, der alle momentan sinnvollen moeglichkeiten enthaelt, wird ausgearbeitet, ein wildes hinzufuegen von selbst erfundenen tags lassen die editoren nicht zu. gut, als zusatzinfos meinetwegen, aber zumindest sollte jedes element entsprechende tags aus der vorgegebenen auswahl haben. da man natuerlich unmoeglich alle eventualitaeten beruecksichtigen kann, soll das ganze durchaus erweiterbar sein. aber eine erweiterung kann nur in den katalog eingefuegt werden, wenn sie komplett ist, d.h. sowohl bezeichnung, tag, renderingregel/icon usw. vorhanden ist. ein fiktives beispiel zur anwendung: ein deutscher mapper zeichnet eine autobahn. aus einer dropdown-liste mit vorgegebenen typen waehlt er den eintrag autobahn aus. ein zweites, beschriftetes eingabefeld ermöglicht ihm die eingabe der Nummer, also z.B. A9. wenn ein englaender dasselbe mit seiner josm-version macht, steht halt motorway in der liste. intern wird das ganze immer mit den tags way=highway.motorway und ref=A9 gespeichert. nur bekommt der normale benutzer diese tags nie zu gesicht. aber ein rendere oder eine navi-software wissen ganz genau, was sie mit diesen daten anzufangen haben. dasselbe gilt natuerlich nicht nur fuer strassen, sondern auch fuer alles andere. wie das z.B. fuer POIs aussehen kann, sieht man ansatzweise in gpsdrive bzw. der zugehoerigen icons.xml ich hatte schon ueberlegt, das (zumindest fuer mein poi-schema) selbst zu machen, aber ich habe echt nicht den nerv, mich in jede einzelnen dieser anwendungen einzuarbeiten. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Das Interesse an OSM-artigen Projekten ist so gross - selbst wenn wir alle unsre bisherige Arbeit wegwerfen wuerden, in ein paar Monaten koennte alles neu gemacht sein, wenn nicht von uns, dann von anderen Leuten. Fuer jeden, der bislang an OSM mitgemacht hat, gibt es 1000 andere, die das genauso koennten. Sorry, aber da identifiziere ich mich doch mehr mit meiner Arbeit. Die Gegend, durch die ich mit großem Aufwand an Zeit und Kraft meinen GPS-Empfänger geradelt habe, betrachte ich als meine Gegend, und die will ich dann auch selbst gemappt haben. Andere Leute haben schließlich nur meine hochgeladenen GPX-Files, aber nicht meine Notizzettel und Erinnerungen. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, Das Interesse an OSM-artigen Projekten ist so gross - selbst wenn wir alle unsre bisherige Arbeit wegwerfen wuerden, in ein paar Monaten koennte alles neu gemacht sein, wenn nicht von uns, dann von anderen Leuten. Fuer jeden, der bislang an OSM mitgemacht hat, gibt es 1000 andere, die das genauso koennten. Sorry, aber da identifiziere ich mich doch mehr mit meiner Arbeit. Die Gegend, durch die ich mit großem Aufwand an Zeit und Kraft meinen GPS-Empfänger geradelt habe, betrachte ich als meine Gegend, und die will ich dann auch selbst gemappt haben. Naja, aber 1000 andere koennten genauso herum fahren und Notizzettel aufschreiben, und auch in Deiner Gegend wird es genug Leute geben. Ich will ja nicht sagen, dass das, was wir haben, keinen Wert haette, auch ich habe viel Arbeit ins Mappen gesteckt - aber angesichts exponentiellen Wachstums der Userbasis ist eine komplette Neuerstellung, auch von Null an, kein Ding der Unmoeglichkeit. Wenn jemand mit einem klaren Taggingschema und coolem Datenmodell und ueberlegenen Applikationen daherkommt, koennte es unter Umstaenden sauberer sein, wirklich bei Null anzufangen, als den Versuch zu unternehmen, die existierenden Daten sinnvoll zu uebertragen - dabei muesste man moeglicherweise viele Kompromisse machen, und ein halbes Jahr spaeter haette man dann wieder die Noergler am Hals ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Sorry, aber da identifiziere ich mich doch mehr mit meiner Arbeit. Die Gegend, durch die ich mit gro?em Aufwand an Zeit und Kraft meinen GPS-Empf?nger geradelt habe, betrachte ich als meine Gegend, und die will ich dann auch selbst gemappt haben. Naja, aber 1000 andere koennten genauso herum fahren und Notizzettel aufschreiben, und auch in Deiner Gegend wird es genug Leute geben. Mitnichten. Ich kenne mich im Zentrum von Hannover gut aus, und wenn ich sehe, was da für Bugs drin stecken... z.B. fehlt die Gartenstraße komplett, und das ganz nahe beim Hauptbahnhof, also eine Gegend, wo eigentlich viele Leute vorbeikommen sollten. Das sieht nicht gerade nach breiter Unterstützung aus. Nun wohne ich aus beruflichen Gründen in Rauma/Südwestfinnland. Die Zahl der Mitarbeiter in Finnland ist verschwindend gering. Alles, was Du dort von Rauma siehst, stammt aus meiner Hand (außer der E8 und der Küstenlinie). Da hilft mir niemand. Aber was theoretisieren wir hier herum. Erst mal muss beschlossen werden, dass das Datenmodell überhaupt geändert wird. Dann muss ein neues Modell entwickelt werden. Und DANN kann man sich über eine Konvertierung der alten Daten den Kopf zerbrechen. Aber all die Mannjahre, die schon in OSM gesteckt wurden, können doch nicht nur ein einziges Ergebnis gebracht haben: dass das Datenmodell nichts taugt... Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo, bin eben so wie ich bin. Sehr defaetistische Ausdrucksweise fuer ein paar kleinere Unstimmigkeiten! Bei 95% aller Strassen duerften wir uns alle ueber das Tagging einig sein. Grade hat jemand etwa 95% aller getaggten Straßen in Frage gestellt. Auch wenn das jetzt vom Tisch zu sein scheint, ist das doch nicht ohne. Sachlich korrekt waere also eher, von Unstimmigkeiten beim Tagging, die rund 5% der Strassen betreffen, zu sprechen. Sprachregelungen hin oder her, aber das ist eben nicht mein Eindruck. Derzeit kann ich fast nur Trivialinfo so eingeben, dass sie bei anderen eindeutig ankommt. Sobald ein Zustand von mehr als nur einem Attribut abhängig ist, klappts oft nicht mehr. Eine Straße, die ohne bauliche Änderung als Vorfahrtsstraße von Staats- auf Kreisstraße wechselt, kann ich schon nicht mehr so darstellen, dass ein anderer weiss, was ich gemeint habe. Ausser ich setze Prosa rein, die aber dann nicht mehr rechnerlesbar ist. Und das ist und bleibt mein Anliegen: Eine möglichst effiziente Kommunikation zwischen Mappern untereinander und den Anwendern mit dem Mittel der Software, die die OSM-Daten möglichst eindeutig interpretieren kann. Das klappt derzeit nicht besonders gut und Straßen werden umcodiert, wenn sich die Diskussion wieder mal dreht. Anderes Beispiel: Ich habe jetzt in München wieder mal einige Einbahnstraßen entdeckt, deren Richtung gedreht wurde. Vielen, die mit guter Absicht in fast fertigen Gebieten werkeln, sind die Auswirkungen eines solchen Fehlklicks nicht bewusst. Im konkreten Fall hätte ein Router die Leute quer durchs Wohngebiet geleitet, weil eine wichtige Hauptverkehrsader nur noch in eine Richtung befahrbar war. Hab ich gefixt, aber das ist schon ziemlich ermüdend. In etwa so ermüdend wie wenn man zuschauen muss, dass eine Straße, die man mal eingetragen hat, X mal ein neues highway-tag erhält. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Frederik Ramm schrieb: Zu dem stehe ich auch heute noch (besonders die Zielsetzungen in 1.1). Auch wenn manchmal ein anderer Eindruck aufkommen koennte: Ich bin keineswegs der Ansicht, dass das OSM-Datenmodell irgendwie gut waere. Wenn ich daran denke, das OSM noch nicht besonders alt ist und IMHO auch noch in der Beta-Phase ist, wundert es nicht, dass es damit schwierig ist, alles abbilden zu können. Vieles wurde am Anfang halt gar noch nicht berücksichtigt. Das ist nicht unbedingt schlecht. Klar haben wir im Moment ein Tag-Chaos. Aber gerade dadurch werden die Ideen gesammelt und man sieht was alles berücksichtigt werden muss. Hätte man z.B. mit einem Standard wie GDF angefangen währen die Richtlinen viel klarer gewesen, aber man hätte auch viel mehr Probleme Elemente zu beschreiben, die in GDF nicht vorgesehen sind. Die einzige Chance fuer ein sauberes, neues Datenmodell waere in meinen Augen die, dass man das separat entwickelt (mit allen Komponenten, Server, Editor, Renderer) und dann mit konvertierten OSM-Daten bestueckt und den Leuten live die Vorteile zeigen kann: Das ist ein Möglichkeit. Ich sehe mehr die Richtung, dass es mit den momentan zur Verfügung stehenden Mittel eine grobe Karte erfasst wird: Das Rendering ist einigermassen akzeptabel, wichtige Informationen wie Strassenverläufe und Namen sind erfasst. Je mehr Informationen der Karte hinzugefügt wird, um so mehr Orte komplett erfasst sind (zumindest das Strassennetz), sieht man die Defizite des Datenformat hervorstechen. Das wird zwangsläufig dazu führen, dass Änderungen an der Infrastruktur notwendig werden. Das diese aufwändiger einzupflegen sind, als wenn alles auf der grünen Wiese enstanden wäre ist klar. Möglich ist es aber durchaus die Daten nach und nach zu verfeinern. Das Schöne an diesen Daten ist doch, das die Geodaten selten ändern: Strassen sind Jahrzehnte unverändert, Häuser stehen ebenso lange. Jetzt, wo vermehrt auch Routing an den OSM-Daten probiert wird, kommen neue Kriterien ins Spiel als nur eine schöne Karte. Das wird dazu führen, dass diese Mängel erkannt werden und nach und nach Verbessert werden. Sei das durch Erweiterungen am Datenmodell, an besseren Tools wie einem Routing-Validierer oder auch bloss an Korrekturen am jetzigen Datenbestand. Gruss, Andy signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Am Sonntag, 25. November 2007 schrieb qbert biker: bin eben so wie ich bin. Freut mich, sonst würde hier was fehlen. Sobald ein Zustand von mehr als nur einem Attribut abhängig ist, klappts oft nicht mehr. Eine Straße, die ohne bauliche Änderung als Vorfahrtsstraße von Staats- auf Kreisstraße wechselt, kann ich schon nicht mehr so darstellen, dass ein anderer weiss, was ich gemeint habe. Ausser ich setze Prosa rein, die aber dann nicht mehr rechnerlesbar ist. Naja, den Weg an der Stelle wo sie sich ändert aufsplitten, und beim einen ref=StXXX und beim anderen ref=KXXX eintragen. Und das ist und bleibt mein Anliegen: Eine möglichst effiziente Kommunikation zwischen Mappern untereinander und den Anwendern mit dem Mittel der Software, die die OSM-Daten möglichst eindeutig interpretieren kann. Das klappt derzeit nicht besonders gut und Straßen werden umcodiert, wenn sich die Diskussion wieder mal dreht. Wünsche mir auch, dass die Kommunikation besser wird. - Das Message-System ist ja nun seit einiger Zeit gut nutzbar und hat mich schon in Kontakt mit verschiedenen anderen Mappern gebracht. Ich hoffe, dass das von vielen genutzt wird, da ich es in einem solchen Gemeinschaftsprojekt sehr wichtig finde, dass man sich austauscht. Und nicht alles ist von globalem Interesse, dass man es hier auf der ML diskutieren sollte. Vielleicht findet sich ja auch mal noch ein Freiwilliger, der in JOSM einbaut, dass man dort direkt dem zuletzt bearbeitenden Mapper eine Nachricht schicken kann... Anderes Beispiel: Ich habe jetzt in München wieder mal einige Einbahnstraßen entdeckt, deren Richtung gedreht wurde. Vielen, die mit guter Absicht in fast fertigen Gebieten werkeln, sind die Auswirkungen eines solchen Fehlklicks nicht bewusst. Im konkreten Fall hätte ein Router die Leute quer durchs Wohngebiet geleitet, weil eine wichtige Hauptverkehrsader nur noch in eine Richtung befahrbar war. Hab ich gefixt, aber das ist schon ziemlich ermüdend. In etwa so ermüdend wie wenn man zuschauen muss, dass eine Straße, die man mal eingetragen hat, X mal ein neues highway-tag erhält. Darum finde ich in solchen Situation das beste, wenn man direkt mit dem Mapper Kontakt aufnehmen kann. - Und das so einfach wie möglich... Rapha ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Freut mich, sonst würde hier was fehlen. Vielen Dank für die Blumen ;) Naja, den Weg an der Stelle wo sie sich ändert aufsplitten, und beim einen ref=StXXX und beim anderen ref=KXXX eintragen. Kurz die Beschreibung: | Stxxx | |__ Styyy | | MÜxxx | === B12 Früher ging Stxxx in Styyy über. Jetzt hat der Kreis eine Verbindung zur nahen B12 gebaut (Kreisstr. MÜxxx). Die Staatsstraße Styyy hat ihre Bedeutung verloren und Straßenausbau und Vorfahrt wurden angepasst. Jetzt geht Stxxx unmerklich in MÜxxx über und die Styyy ist eine unbedeutende Abzweigung. Das will ich eintragen - auf der ref-Ebene ist das gar kein Problem. Das Problem ist, darzustellen, dass Stxxx-MÜxxx eine durchgängige Straße ist. Mit der strengen Anwendung der highway-Regel müsste ich Stxxx und Styyy als secondary eintragen. Optisch ergibt das den Eindruck einer abknickenden Vorfahrt, was komplett falsch ist und die wichtige Verbindung zur B12 geht optisch als tertiary unter. Stufe ich MÜxxx zu secondary hoch und Styyy zu tertiary runter, schauts optisch zwar richtig aus aber dann kommt jemand daher und wendet secondary==Staatsstraße an und die Information ist futsch. Ich kann also derzeit nicht bleibend darstellen, wie die Situation wirklich ist. Darum finde ich in solchen Situation das beste, wenn man direkt mit dem Mapper Kontakt aufnehmen kann. - Und das so einfach wie möglich... Das ist natürlich auch eine sehr wichtige Sache. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
qbert biker schrieb: Freut mich, sonst würde hier was fehlen. Vielen Dank für die Blumen ;) Naja, den Weg an der Stelle wo sie sich ändert aufsplitten, und beim einen ref=StXXX und beim anderen ref=KXXX eintragen. Kurz die Beschreibung: | Stxxx | |__ Styyy | | MÜxxx | === B12 Früher ging Stxxx in Styyy über. Jetzt hat der Kreis eine Verbindung zur nahen B12 gebaut (Kreisstr. MÜxxx). Die Staatsstraße Styyy hat ihre Bedeutung verloren und Straßenausbau und Vorfahrt wurden angepasst. Jetzt geht Stxxx unmerklich in MÜxxx über und die Styyy ist eine unbedeutende Abzweigung. Das will ich eintragen - auf der ref-Ebene ist das gar kein Problem. Das Problem ist, darzustellen, dass Stxxx-MÜxxx eine durchgängige Straße ist. Mit der strengen Anwendung der highway-Regel müsste ich Stxxx und Styyy als secondary eintragen. Optisch ergibt das den Eindruck einer abknickenden Vorfahrt, was komplett falsch ist und die wichtige Verbindung zur B12 geht optisch als tertiary unter. Stufe ich MÜxxx zu secondary hoch und Styyy zu tertiary runter, schauts optisch zwar richtig aus aber dann kommt jemand daher und wendet secondary==Staatsstraße an und die Information ist futsch. Ich kann also derzeit nicht bleibend darstellen, wie die Situation wirklich ist. vielleicht eine relation mit type=street auf die STxxx und MÜxxx setzen? Ist aber auf jeden Fall ein gutes Beispiel dafür, dass es keinen Sinn macht primary, secondary und tertiary 100ig auf irgendwelche administrativen Straßentypen zu verteilen, sondern es im Fokus stehen sollte die logische Wichtigkeit darzustellen... Gruß mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mal ganz anders
qbert schrieb: Kurz die Beschreibung: | Stxxx | |__ Styyy | | MÜxxx | === B12 Optisch sollte sich das aus der Geometrie ergeben, Der Router muss sich über zusätzliche Informationen die günstigere Route aussuchen - nur weil eine Strecke besser ausgebaut ist ist sie ja noch nicht der bessere Weg für die Route. Vielleicht kann man ja automatisiert einen Index für die Kurvigkeit einer Strecke erstellen und auch diesen Berücksichtigen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mal ganz anders
Raphael schrieb: / Anderes Beispiel: Ich habe jetzt in München wieder mal einige // Einbahnstraßen entdeckt, deren Richtung gedreht wurde. Vielen, // die mit guter Absicht in fast fertigen Gebieten werkeln, // sind die Auswirkungen eines solchen Fehlklicks nicht bewusst. // Im konkreten Fall hätte ein Router die Leute quer durchs // Wohngebiet geleitet, weil eine wichtige Hauptverkehrsader // nur noch in eine Richtung befahrbar war. Hab ich gefixt, // aber das ist schon ziemlich ermüdend. In etwa so ermüdend // wie wenn man zuschauen muss, dass eine Straße, die man mal // eingetragen hat, X mal ein neues highway-tag erhält. / Darum finde ich in solchen Situation das beste, wenn man direkt mit dem Mapper Kontakt aufnehmen kann. - Und das so einfach wie möglich... Besser ist es die Definition gleich so zu präzisieren dass eine Kommunikation in diesen Fällen erst gar nicht nötig werden. Dass Problem mit den Einbahnstrassen kann in JOSM entschärft werden wenn er ein umdrehen einer Richtung nicht mehr oder nur unter massiver Warnung zulässt wenn oneway=yes gesetzt ist. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mal ganz anders
Mario schrieb: vielleicht eine relation mit type=street auf die STxxx und MÜxxx setzen? Ist aber auf jeden Fall ein gutes Beispiel dafür, dass es keinen Sinn macht primary, secondary und tertiary 100ig auf irgendwelche administrativen Straßentypen zu verteilen, sondern es im Fokus stehen sollte die logische Wichtigkeit darzustellen... Super Idee... und woran machst Du die logische Wichtigkeit fest damit so eine Bewertung eindeutig bleibt und nicht von Mapper zu Mapper wieder verändert wird? Für den Lokalverkehr kann so eine Verbindung sehr wichtig sein (Z.B. Bypass für einen naheliegenden Ikea-Markt der die bisherige Strasse hoffnungslos überlastet), für den Fernverkehr ist sie dagegen bedeutungslos obwohl wesentlich besser ausgebaut - oder umgekehrt... - und jetzt? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mal ganz anders
Hallo, nachdem das Chaos bei den Taggingregeln jetzt so ziemlich perfekt zu sein scheint, probier ichs mal ganz anders rum. Gibt es Leute hier, die ein Interesse daran haben, eine Art Arbeitsgruppe zu bilden, die eine Lösung für ein konkretes Problem herausarbeiet? Ziel wäre, ein Regelwerk zu entwickeln, mit dem man Straßen gut abbilden kann. Dieses Regelwerk soll von Programmen interpretiert werden können, so daß typische Anwendungen wie Router sicher darauf zugreifen können und sich nicht blind auf Vereinheitlichungen wie das highway-tag verlassen müssen. Damit das nicht von vorneherein zum Scheitern verurteilt ist, werden die besonders strittigen Dinge wie das highway-tag erst mal aussen vor gelassen. Es ginge also nicht darum, zu beschreiben, ob Straße A schneller/besser/ etc. als Straße B ist, sondern um ganz allgemeine Kriterien und ihre Beziehung zueinander, so dass man sich aus der Beschreibung heraus die Straße vorstellen kann. Ein erster Vorschlag wäre die Bildung von Attributgruppen für die Beschreibung: Physikalisch: Breite, Spuranzahl, Belag, etc. Administrativ: Bundes-/Staatsstrasse, inner-, ausserorts, etc. Restriktiv: Verbote, Limitierungen Verkehrlich: Vorfahrt, kreuzungsfreiheit, Ampeln, Umgehung Die Attribute sollten so gewählt werden, dass die möglichst auf der ganzen Welt (oder wahlweise auf dem Mond *g*) Gültigkeit haben - nationale Eigenheiten sollten in die Werte der Attribute und deren Abhängigkeiten untereinander einfliessen. Was jetzt natürlich toll wäre, ist, wenn es eine graphische Lösung gäbe, mit denen man die Attribute und deren Abhängigkeiten rechnerlesbar und optisch ansprechend verwalten könnte (UML?) So, und um jetzt nicht von div. Leuten virtuell gleich in der Luft zerfetzt zu werden ein paar Dinge dazu, zu was das Regelwerk NICHT dienen soll: OSM neu erfinden: Die Regeln sollen das, was bisher in OSM erarbeitet wurde nutzen und Möglichkeiten aufzeigen, wo man im Detail noch was verbessern kann. Verbindlich für alle sein: Alles, was bisher geht, wird auch weiterhin gehen. Im schlechtesten Fall existiert das Regelwerk später in einer Art Parallelwelt, aber wenn es gut ist, kann man vielleicht immer mehr Tagger überzeugen. Total unverbindlich sein: Wenn es rechnerlesbar sein soll, braucht es Regeln und Aussagen wie wahr und falsch, sowie festgeklopfte Versionen analog zur API. Wenns nötig ist, kann man auch im OSM-XML einen eigenen Namensraum dazu einführen. Ich würde das im Moment als Experiment auf Autostraßen beschränken, aber ich kann mir auch vorstellen, dass ich mal eine Anfrage an OSM stelle, wenn ich eine Bergtour machen will, bei der ich max. 10% der Strecke auf langweiligen Forststraßen latschen muss. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mal ganz anders
Halo Hubert, Gibt es Leute hier, die ein Interesse daran haben, eine Art Arbeitsgruppe zu bilden, die eine Lösung für ein konkretes Problem herausarbeiet? Ja, ich wäre dabei. Meine Bemühungen mit den klaren highway Tags zielen ja genau auf diese Richtung ab. Sorry wenn ich das jetzt doch mit den highwayTags erwähne): Was mir an Deinem Vorschlag nicht so gefällt ist das aussen vorlassen eben der highway Tags Der highway Tag ist der allererste Tag der überhaupt erst eine Strasse zuwege bringt und auf den die Renderer aufbauen. Und ich finde es einfach ineffizient wenn man das Pi mal Daumen macht oder nach einem jeweils persönlich eingefahrenem inkonsistenten Muster wenn man schon die Information hat die meist alle paar Meter am Strassenrand steht. Wenn man sie mal nicht weiss kann man es ja als FIX ME eintragen. Somit hat man von Anfang an eine Information die auch verfizierbar ist und nicht von den Launen des Mappers abhängt. Was das ganze Problem allerrdings umgehen könnte wenn man einen (Projektgruppen)eigenen Renderer aufsetzen könnte... Dann wäre mir das highway Tag auch egal... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
qbert biker schrieb: Gibt es Leute hier, die ein Interesse daran haben, eine Art Arbeitsgruppe zu bilden, die eine Lösung für ein konkretes Problem herausarbeiet? hurra, ich hatte ja schon gar nicht mehr daran geglaubt. endlich mal ein VERNÜNFTIGER VORSCHLAG in dieser seit wochen andauernden supernervigen diskussion um des kaisers bart. vielleicht kommen wir damit von diesen fundamentalistischen glaubenskriegen die hier um highway tags geführt werden weg. das hat schon was von amiga ist besser als atari - ach nein wir sind ja in der neuzeit - windows ist besser als linux. grüße frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hallo Garry, Ja, ich wäre dabei. schon mal super :) Was mir an Deinem Vorschlag nicht so gefällt ist das aussen vorlassen eben der highway Tags Ich sehe keine andere Möglichkeit mehr. Ich hab jetzt zig mails geschrieben, nur um zu erreichen, dass es mal eine greifbare Aussage gibt, was highway eigentlich aussagen soll. Wenn keine Einigkeit besteht, was highway aussagen soll, wird es nie eindeutige Regeln geben können. Was das ganze Problem allerrdings umgehen könnte wenn man einen (Projektgruppen)eigenen Renderer aufsetzen könnte... Dann wäre mir das highway Tag auch egal... Sowas könnte ich schon liefern - hatte das vor ein paar Monaten auch angekündigt - als reine Vektoranwendung auf Qt4-Basis (im Moment nur linux) mit integriertem Router. Mit dem Pixelkram hab ichs nicht so. Derzeit will ich aber noch vorher mein aktuelles Projekt abschliessen, bei dem es darum geht, dass man in akzeptabler Zeit Rechtecke aus dem World-file schneiden kann. Grüsse Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Hi, Derzeit will ich aber noch vorher mein aktuelles Projekt abschliessen, bei dem es darum geht, dass man in akzeptabler Zeit Rechtecke aus dem World-file schneiden kann. http://wiki.openstreetmap.org/index.php/Osmosis --bounding-polygon rechnet Germany in akzeptabler Zeit aus dem Planetfile 'raus. Vor ein paar Wochen ging das noch in 40', dürfte aber inzwischen etwas mehr sein. Nachdem --bounding-box ein eigener Aufruf ist nehme ich an, dass das hinreichend schnell ist. Übrigens: Ich denke kaum, dass jemand was dagegen einzuwenden hat, wenn künftig das Straßentagging verfeinert wird. Ich bin mir sogar ziemlich sicher, dass das highway-Tag irgendwann zugunsten von etwas anderem verschwinden wird. Aber diese Änderung wird etwas anders vonstatten gehen, wie wir uns das vorstellen. Bis dahin wird es beim aktuellen Schema bleiben. Künftig könnten dann an einer Straße mehrer Tags hängen, und Renderer könnten verschiedene Karten bauen: eine die die Straßen nach administrativer Zugehörigkeit rendert, eine die die gefühlte Wichtigkeit für den täglichen Verkehr anzeigt, eine die den Straßenbelag visualisiert, eine die die Radtauglichkeit ausweist usw. Ich war leider nicht in Manchester dabei, aber vielleicht interessiert euch ja der STAGS-Vortrag von Andy Robinson: http://wiki.openstreetmap.org/index.php/State_Of_The_Map_2007 Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
--bounding-polygon rechnet Germany in akzeptabler Zeit aus dem Planetfile 'raus. Vor ein paar Wochen ging das noch in 40', dürfte aber inzwischen etwas mehr sein. Nachdem --bounding-box ein eigener Aufruf ist nehme ich an, dass das hinreichend schnell ist. Vor ein paar Wochen, damals hatte das ausgepackte OSM-File ca. 20GB, konnte ich das Ding in ca 8' parsen. Wenn ichs in 8' schaffe, warum soll ich dann 40' warten? Mit einem Dualcore kann man da vielleicht noch ein paar Minütchen rauskitzeln. Ich lese dabei direkt von einem gz-file, weil ich die fetten ausgepackten Brocken nicht auf der Platte haben mag und mir bz2 zu langsam ist. Die Selektionsroutine für ein Rechteck/Polygon fehlt noch, aber von der zeitabschätzung her ist das Parsen des XML-Files der kritischere Faktor. Übrigens: Ich denke kaum, dass jemand was dagegen einzuwenden hat, wenn künftig das Straßentagging verfeinert wird. Ich bin mir sogar ziemlich sicher, dass das highway-Tag irgendwann zugunsten von etwas anderem verschwinden wird. Aber diese Änderung wird etwas anders vonstatten gehen, wie wir uns das vorstellen. Ich kann mir ziemlich viel vorstellen und wenn die zitierten Konzepte mal neuen Wind reinbringen, freu ich mich drauf. Bis das mal greifbar ist - mal sehen ;) By, Hubert -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Moin, Ich kann mir ziemlich viel vorstellen und wenn die zitierten Konzepte mal neuen Wind reinbringen, freu ich mich drauf. Bis das mal greifbar ist - mal sehen ;) ich denke das ist ein Henne-Ei-Problem. Sobald die Renderer Tags cool rendern, werde sie auch benutzt. Aber solange es einen Tag nicht massenhaft in der Datenbank gibt, wird sich kein Renderer dafür interessieren. Das Rendern ist eh' noch ein Schwachpunkt im Projekt. Würde es einen leicht aufzusetzenden Renderer geben, dem man neue Stile ebenfalls recht leicht beibringen könnte, dann würden mehr Leute eine eigene Map aufsetzen. Dann klappt auch das Vorstellen neuer Taggingregeln IMO besser, weil jemand dann sagen kann Heh guckt mal, ich tagge soundso und mache dann diese Karte davon. Was haltet ihr davon? Just my two cents, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mal ganz anders
Am Sonntag 25 November 2007 schrieb Christoph Eckert: Moin, Ich kann mir ziemlich viel vorstellen und wenn die zitierten Konzepte mal neuen Wind reinbringen, freu ich mich drauf. Bis das mal greifbar ist - mal sehen ;) ich denke das ist ein Henne-Ei-Problem. Sobald die Renderer Tags cool rendern, werde sie auch benutzt. Aber solange es einen Tag nicht massenhaft in der Datenbank gibt, wird sich kein Renderer dafür interessieren. erst braucht es ein sauberes, moeglichst anwendungsunabhaengiges datenmodell, das alle noetigen informationen klar und eindeutig darstellt. dann erst sollten die anwendungen wie rendering darauf aufsetzen. ansonsten ist man staendig am hinterherentwickeln. aber natuerlich muss dieses neue modell nicht endgueltig sein, sondern durchaus erweiterbar... aussagen wie es gibt kein richtig oder falsch bei osm sind auf keinen fall sinnvoll. das war vielleicht fuer den anfang in ordnung, um ueberhaupt mal irgendwas zu haben. aber inzwischen sind wir auf einem level, wo das keinen sinn mehr macht. es braucht ein vernuenftiges konzept mit klaren vorgaben, sonst wird das ganze frueher oder spaeter den bach runtergehen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
