Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Florian Lohoff schrieb: So wie ich diverse mails bereits auf talk und dev interpretiert habe gibt es auch ausserhalb Deutschlands die mit dem Karlsruhe schema nicht klarkommen. Ich meine da mails aus Indien gesehen zu haben. Das liegt möglicherweise an der etwas exotischen Einordnung des Menüpunkt in JOSM, und daran, dass man beim Eintragen nicht geführt wird, sondern wissen muss, was dabei rauskommen sollte. Sobald man das rausgefunden hat, ist es dann simpel. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Florian Lohoff schrieb: Das argument das Hausnummern kein attribut der straße sind ist richtig. Aber genausowenig sind sie attribut eines ways der neben der straße liegt. Und nach dem Motto das wir nur mappen in form von nodes und ways was physich existiert (siehe diskussion um fluglinien) ist das way anlegen fuer die inerpolation von hausnummern auch dran vorbei. Und besser machen koennen wir sicherlich - aber ich werde den interpolierenden teil des Karlsruhe Schemas nicht anwenden. Alleine beim anblick der ways die links und rechts neben der straße sind rollen sich mir die Fußnaegel hoch. Hausnummern sind keine Hausnummern sondern Grundstücksnummern, und sind Attribute der Grundstücke, die neben der Straße liegen. Die zusätzlichen Wege sind die Grundstücksfronten. Es ist zwar schade, dass man nicht einzelne Linienabschnitte von Areas verschieden attributieren kann (Eckhäuser mit zwei Eingängen), aber man kann wohl nicht alles haben. Relationen schön und gut, das ist ein *interessantes* Konzept. Aber bitte schreibe auch die passenden, für absolut blutige Anfänger tauglichen Anleitungen für alle verbreiteten Editoren, wenn du so etwas einführen oder etablieren möchtest. Inklusive Erkennung, Wartung, Fehlerquellen. Sonst bleibt das kann man mit Relations machen eine Geek-Phrase, für die du von einigen Leuten mit nicht mehr frischen Lebensmitteln beworfen und bis in die Antarktis gejagt wirst, um dort die Bruchkanten der Gletscher zu mappen. Ich zum Beispiel werde bösartig, wenn mir jemand meine Arbeitsweise madig macht, ohne mir eine verständliche Anleitung zum Andersmachen zu geben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Am 28. Oktober 2008 11:59 schrieb Birgit Nietsch [EMAIL PROTECTED]: Hausnummern sind keine Hausnummern sondern Grundstücksnummern, und sind Attribute der Grundstücke, die neben der Straße liegen. Schlichtweg Falsch. Deine Konstruktion fällt bereits bei mehreren Eingängen pro Gebäude (habe ich öfters bei Mehrparteien-Häusern) und Hinterhöfen mit ihren eigenen Hausnummern (typisch in Berlin) auseinander. Die Hausnummer ist ein postalisches Attribut des Eingangs eines Hauses. Abstrahiert durch das Gebäude. Ein Eingang kann mehrere Nummern haben und eine Nummer sogar in seltenen Fällen mehrere zugeordnete Eingänge. Die Nummern können auch aus Buchstaben bestehen und wir haben mittlerweile so einige andere Ordnungen als nur 1-x und gerade/ungerade finden können. Ich halte die Interpolation für ein notwendiges Feature um schnell ganze Straßenzüge grob erfassen zu können. Sie hat bisher gute Dienste geleistet. Auch halte ich das Karlsruhe-Schema für einen guten Testlauf. Wer ein besseres Schema hat, soll es gerne in seiner Stadt mal 3-5 Wochen ausgiebig nutzen und dann Leuten aus anderen Regionen mit anderen Adress-Schemata zum Test anbieten. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Am 28. Oktober 2008 13:10 schrieb Marcus Wolschon [EMAIL PROTECTED]: Am 28. Oktober 2008 11:59 schrieb Birgit Nietsch [EMAIL PROTECTED]: Hausnummern sind keine Hausnummern sondern Grundstücksnummern, und sind Attribute der Grundstücke, die neben der Straße liegen. Schlichtweg Falsch. Deine Konstruktion fällt bereits bei mehreren Eingängen pro Gebäude (habe ich öfters bei Mehrparteien-Häusern) und Hinterhöfen mit ihren eigenen Hausnummern (typisch in Berlin) auseinander. nein, ist richtig. Steht uebrigens auch genauso in der Berliner Numerierungsverordnung (kann ich mir nicht verkneifen, da Du Berlin als Beispiel zitierst): http://www.berlin.de/ba-spandau/verwaltung/gesetze/nrvo.html Wenn Du nicht mal sicher ueber das bist, was Du schreibst, solltest Du einen etwas gemaessigteren Ton anschlagen. Diese leidige Diskussion ueber das Karlsruhe-Schema nervt ein bisschen, da bisher noch kein Fall aufgezeigt wurde, wo das Schema nicht funktioniert, und es wohl kaum eine einfachere Loesung gibt, als einfach jede Nummer mit einem Node zu repraesentieren (eine der Moeglichkeiten des KA-Schemas und von all denjenigen, denen die Interpolation nicht passt, einfach und simpel anzuwenden). Geht raus und mappt die Nummern, anstatt hier sinnlos Traffic zu produzieren, oder denkt Euch ein eigenes Schema aus, dokumentiert das im Wiki, und postet *danach* hier. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Tue, Oct 28, 2008 at 01:23:14PM +0100, Martin Koppenhoefer wrote: nein, ist richtig. Steht uebrigens auch genauso in der Berliner Numerierungsverordnung (kann ich mir nicht verkneifen, da Du Berlin als Beispiel zitierst): http://www.berlin.de/ba-spandau/verwaltung/gesetze/nrvo.html Dir ist aber schon bewusst das es prominente abweichung von diesem dingen gerade in Berlin gibt? (1) Die Grundstücke sind an den Straßen zu numerieren, von denen sie ihren Zugang haben. Grundstücke mit mehreren Hauseingängen oder Zugängen erhalten jeweils so viele Grundstücksnummern, wie für den allgemeinen Verkehr benötigt werden. Wieviele werden denn benoetigt? Damit ist doch schon die erste regelmaessigkeit tot ... Noetig sind so viele wie der Eigentuemer und die Stadt fuer angemessen halten - also beliebig viele. Damit hat Marcus also recht das es sowohl mehrere Nummern fuer einen Eingang wie auch eine Nummer fuer mehrere Eingaenge geben kann. (3) Die Grundstücke sind wechselseitig zu numerieren. Die ungeraden Zahlen sind für Grundstücke an der linken, die geraden Zahlen für Grundstücke an der rechten Seite der Straße zu verwenden. Und hiervon gibt es genau Prominente abweichungen - Eine seite Hoch - andere seite Runter ... Geht raus und mappt die Nummern, anstatt hier sinnlos Traffic zu produzieren, oder denkt Euch ein eigenes Schema aus, dokumentiert das im Wiki, und postet *danach* hier. Ich werde mit dem Karlsruhe Interpolationsschema nix mappen - Beim anblick der wege die nichts repraesentieren was wirklich existiert rollen sich mir die Fußnaegel hoch ... Und wenn du mal was suchst was mit KA Schema nicht geht: http://lists.openstreetmap.org/pipermail/talk/2008-October/030471.html oder beim konvertieren in bestehende Formate: http://lists.openstreetmap.org/pipermail/talk/2008-October/030464.html Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Hi, Martin Koppenhoefer wrote: Diese leidige Diskussion ueber das Karlsruhe-Schema nervt ein bisschen, da bisher noch kein Fall aufgezeigt wurde, wo das Schema nicht funktioniert, und es wohl kaum eine einfachere Loesung gibt, als einfach jede Nummer mit einem Node zu repraesentieren (eine der Moeglichkeiten des KA-Schemas und von all denjenigen, denen die Interpolation nicht passt, einfach und simpel anzuwenden). Find ich ja auch, aber hack nicht so auf Marcus rum, der war einer von denen, die sich das Schema ausgedacht haben ;-) 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/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Fri, Oct 24, 2008 at 07:43:11PM +0200, Sebastian Hohmann wrote: Allerdings kommt es ja darauf an wo man wohnt. In Gegegenden die gut erfasst sind und viele Mapper haben, werden sicher auch Hausnummern schneller und detaillierter erfasst. Aber es stimmt wohl schon, dass meistens eine Interpolation reicht und habe auch nichts gegenteiliges behauptet. Ich finde eben bloss die Mischung zwischen neben der Straße/an der Straße nicht schön. So wie ich diverse mails bereits auf talk und dev interpretiert habe gibt es auch ausserhalb Deutschlands die mit dem Karlsruhe schema nicht klarkommen. Ich meine da mails aus Indien gesehen zu haben. Musste doch mal schnell in den USA bei den Tiger daten gucken - da ist nix mit Hausnummern so wie es aussieht ... D.h. es wird derzeit noch wenig Hausnummer existieren in den Datensaetzen - Also noch zeit umzusteuern und einfacherere moeglichkeiten der erfassung zu finden. Die muessen ja nicht mit Karlsruhe kollidieren. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Hallo, Florian Lohoff wrote: Und der Aufwand von Straßennetz zu erfassen zu Straßen + Interpolierte Hausnummern ist vermutlich irgendwas mit 1:10. Wenn wir jetzt noch JEDE Hausnummer einzeln aufnehmen und einen genauen punkt zuordnen ist man nochmal bei 1:10. Es passt halt nicht so recht, wenn man jedes einzelne Haus als Gebaeude erfasst - und das tun wir -, dann aber bei den Hausnummern auf Interpolation setzt. Aber zugegben - Die Hausnummern kommen halt nicht vom Luftbild, daher werden wir vielerorts auf absehbare Zeit noch mit Interpolation leben muessen (als Zwischenloesung, wohlgemerkt). Dein Argument die kommerziellen tun das ja auch kann ich im uebrigen nicht gelten lassen - das stimmt zwar, dass die das tun, aber ich sehe nicht, warum wir das imitieren muessen; die Idee ist ja aus der Not heraus geboren. Es scheint, dass das Karlsruhe-Schema einfach zu schlecht dokumentiert ist; Du schreibst irgendwas davon, wie gut Du Interpolation findest und dass es vielleicht noch nicht zu spaet sei, umzusteuern und etwas zu machen, was einfacher sei - aber das Karlsruher Schema unterstuetzt doch auch Interpolation. Das einzige, was es nicht unterstuetzt, ist, Hausnummern-Information direkt an solche Ways anzuhaengen, die eine Strasse repraesentieren, und das ist IMHO sowieso der groesste Quatsch, weil man sich sofort in einem Dickicht von left_dieses und right_jenes verstrickt und bei jedem Zusammenfuegen oder Splitten von Ways alles den Bach runtergeht. Hausnummern haben an der Strasse selbst nichts zu suchen, Hausnummern sind ein von der Strasse logisch komplett unabhaengiges Schema. Haeuser liegen *neben* der Strasse, und die Position eines Hauses aendert sich nicht, selbst wenn die Strasse umgebaut werden sollte. Haeuser liegen oft auch an einer Strasse, die eine andere ist als die, die in der Adresse vorkommt. Dieses bei derzeitigen Geodaten uebliche Schema, einfach an jedes Strassensegment vier Hausnummer zu pappen, ist ein ganz furchtbarer Hack, den wir auf keinen Fall uebernehmen sollten - wir haben die Chance, es besser zu machen. Ich habe schon einige Strassenzuege mit dem Karlsruher Schema und der Interpolationsmethode erfasst. Das ist ueberhaupt kein Problem und geht flott von der Hand, wenn man den Arbeitsablauf erstmal drin hat, und man bekommt saubere und robuste Daten. Ich habe auch nichts gegen irgendein anderes ordentliches Schema, aber ich glaube nicht, dass man da ohne ein geruettelt Mass an Relationen auskommen wird - *einfacher* als das Karlsruher Schema wird es kaum werden. Und irgendwas an den Way dranzutaggen, was sich dann verschiebt und umdreht und kaputtgeht, wenn man Ways verknuepft und so, das ist doch Murks. Wer den kleinen Extraschritt zum sauber arbeiten nicht gehen will, der soll doch bitte einfach die Hausnummern denen ueberlassen, die dazu die Zeit haben. 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/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Sat, Oct 25, 2008 at 05:36:02PM +0200, Frederik Ramm wrote: Es passt halt nicht so recht, wenn man jedes einzelne Haus als Gebaeude erfasst - und das tun wir -, dann aber bei den Hausnummern auf Interpolation setzt. Aber zugegben - Die Hausnummern kommen halt nicht vom Luftbild, daher werden wir vielerorts auf absehbare Zeit noch mit Interpolation leben muessen (als Zwischenloesung, wohlgemerkt). Dein Argument die kommerziellen tun das ja auch kann ich im uebrigen nicht gelten lassen - das stimmt zwar, dass die das tun, aber ich sehe nicht, warum wir das imitieren muessen; die Idee ist ja aus der Not heraus geboren. Ich habe gesagt das dort die Hausnummerninformationen dort auch nur aus interpolation bestehen und da die ergebnisse doch beachtlich sind. Von imitieren sprach keiner ... Es scheint, dass das Karlsruhe-Schema einfach zu schlecht dokumentiert ist; Du schreibst irgendwas davon, wie gut Du Interpolation findest und dass es vielleicht noch nicht zu spaet sei, umzusteuern und etwas zu machen, was einfacher sei - aber das Karlsruher Schema unterstuetzt doch auch Interpolation. Das einzige, was es nicht unterstuetzt, ist, Hausnummern-Information direkt an solche Ways anzuhaengen, die eine Strasse repraesentieren, und das ist IMHO sowieso der groesste Quatsch, weil man sich sofort in einem Dickicht von left_dieses und right_jenes verstrickt und bei jedem Zusammenfuegen oder Splitten von Ways alles den Bach runtergeht. Hausnummern haben an der Strasse selbst nichts zu suchen, Hausnummern sind ein von der Strasse logisch komplett unabhaengiges Schema. Haeuser liegen *neben* der Strasse, und die Position eines Hauses aendert sich nicht, selbst wenn die Strasse umgebaut werden sollte. Haeuser liegen oft auch an einer Strasse, die eine andere ist als die, die in der Adresse vorkommt. Dieses bei derzeitigen Geodaten uebliche Schema, einfach an jedes Strassensegment vier Hausnummer zu pappen, ist ein ganz furchtbarer Hack, den wir auf keinen Fall uebernehmen sollten - wir haben die Chance, es besser zu machen. Sorry - Aber left/right blah find ich genausoschlimm - deshalb war ja meine idee (beginn des threads) das eben ueber eine relation zu machen. Und gegen leute die daten modifizieren ohne zu wissen was sie tun kann auch das Karlsruhe Schema nichts ausrichten. Das argument das Hausnummern kein attribut der straße sind ist richtig. Aber genausowenig sind sie attribut eines ways der neben der straße liegt. Und nach dem Motto das wir nur mappen in form von nodes und ways was physich existiert (siehe diskussion um fluglinien) ist das way anlegen fuer die inerpolation von hausnummern auch dran vorbei. Und besser machen koennen wir sicherlich - aber ich werde den interpolierenden teil des Karlsruhe Schemas nicht anwenden. Alleine beim anblick der ways die links und rechts neben der straße sind rollen sich mir die Fußnaegel hoch. Ich habe schon einige Strassenzuege mit dem Karlsruher Schema und der Interpolationsmethode erfasst. Das ist ueberhaupt kein Problem und geht flott von der Hand, wenn man den Arbeitsablauf erstmal drin hat, und man bekommt saubere und robuste Daten. Dann mach ... Sicher sind wege schnell zu machen - kann jeder selbst mit potlatch - nur im gewirr von Straße, Fuß+Radweg, Landuse, Building die richtige linie wiederzufinden die die Hausnummern beinhaltet ist quasi ein unnoetiges chaos. Sauber nenn ich was anderes - Robust vieleicht. Ich bin gespannt wieviele leute da mal ausversehen wege miteinander verbinden weil alles so dicht beineinander liegt und dann mit unglue ways alles moegliche wieder auseinanderziehen und dabei beliebig zerstoeren. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Florian Lohoff schrieb: On Sat, Oct 25, 2008 at 05:36:02PM +0200, Frederik Ramm wrote: Es passt halt nicht so recht, wenn man jedes einzelne Haus als Gebaeude erfasst - und das tun wir -, dann aber bei den Hausnummern auf Interpolation setzt. Aber zugegben - Die Hausnummern kommen halt nicht vom Luftbild, daher werden wir vielerorts auf absehbare Zeit noch mit Interpolation leben muessen (als Zwischenloesung, wohlgemerkt). Dein Argument die kommerziellen tun das ja auch kann ich im uebrigen nicht gelten lassen - das stimmt zwar, dass die das tun, aber ich sehe nicht, warum wir das imitieren muessen; die Idee ist ja aus der Not heraus geboren. Ich habe gesagt das dort die Hausnummerninformationen dort auch nur aus interpolation bestehen und da die ergebnisse doch beachtlich sind. Von imitieren sprach keiner ... Es scheint, dass das Karlsruhe-Schema einfach zu schlecht dokumentiert ist; Du schreibst irgendwas davon, wie gut Du Interpolation findest und dass es vielleicht noch nicht zu spaet sei, umzusteuern und etwas zu machen, was einfacher sei - aber das Karlsruher Schema unterstuetzt doch auch Interpolation. Das einzige, was es nicht unterstuetzt, ist, Hausnummern-Information direkt an solche Ways anzuhaengen, die eine Strasse repraesentieren, und das ist IMHO sowieso der groesste Quatsch, weil man sich sofort in einem Dickicht von left_dieses und right_jenes verstrickt und bei jedem Zusammenfuegen oder Splitten von Ways alles den Bach runtergeht. Hausnummern haben an der Strasse selbst nichts zu suchen, Hausnummern sind ein von der Strasse logisch komplett unabhaengiges Schema. Haeuser liegen *neben* der Strasse, und die Position eines Hauses aendert sich nicht, selbst wenn die Strasse umgebaut werden sollte. Haeuser liegen oft auch an einer Strasse, die eine andere ist als die, die in der Adresse vorkommt. Dieses bei derzeitigen Geodaten uebliche Schema, einfach an jedes Strassensegment vier Hausnummer zu pappen, ist ein ganz furchtbarer Hack, den wir auf keinen Fall uebernehmen sollten - wir haben die Chance, es besser zu machen. Sorry - Aber left/right blah find ich genausoschlimm - deshalb war ja meine idee (beginn des threads) das eben ueber eine relation zu machen. Und gegen leute die daten modifizieren ohne zu wissen was sie tun kann auch das Karlsruhe Schema nichts ausrichten. Das argument das Hausnummern kein attribut der straße sind ist richtig. Aber genausowenig sind sie attribut eines ways der neben der straße liegt. Und nach dem Motto das wir nur mappen in form von nodes und ways was physich existiert (siehe diskussion um fluglinien) ist das way anlegen fuer die inerpolation von hausnummern auch dran vorbei. Mit dem Unterschied, dass Fluglinien nicht immer genau auf dem gleichen Weg verlaufen müssen, während Hausnummern meist an der gleichen Stelle bleiben. Ich verstehe auch nicht, warum du immernoch darauf beharrst, dass die Interpolationslinien nichts physisches sind. Die machen doch nichts anderes als die Punkte dazwischen abzubilden, ohne diese einzeln zeichen zu müssen. Auch wenn da in der Realität keine Wege in Form von Straßen sind, dient die Datenstruktur totzdem dazu etwas Physisches abzubilden. Und besser machen koennen wir sicherlich - aber ich werde den interpolierenden teil des Karlsruhe Schemas nicht anwenden. Alleine beim anblick der ways die links und rechts neben der straße sind rollen sich mir die Fußnaegel hoch. Ich habe schon einige Strassenzuege mit dem Karlsruher Schema und der Interpolationsmethode erfasst. Das ist ueberhaupt kein Problem und geht flott von der Hand, wenn man den Arbeitsablauf erstmal drin hat, und man bekommt saubere und robuste Daten. Dann mach ... Sicher sind wege schnell zu machen - kann jeder selbst mit potlatch - nur im gewirr von Straße, Fuß+Radweg, Landuse, Building die richtige linie wiederzufinden die die Hausnummern beinhaltet ist quasi ein unnoetiges chaos. Sauber nenn ich was anderes - Robust vieleicht. Ich bin gespannt wieviele leute da mal ausversehen wege miteinander verbinden weil alles so dicht beineinander liegt und dann mit unglue ways alles moegliche wieder auseinanderziehen und dabei beliebig zerstoeren. Das ist eine Sache des Editors. Wenn man damit einzelne Arten von Ways (Hausnummern, Landuse) ausblenden kann oder definieren kann welche Ways nicht miteinander verbunden werden sollen, dann ist das doch auch kein Problem. Ich denke mit Relations haben die Leute um einiges mehr Probleme, sprich die Editoranpassungen wären noch aufwendiger und das Editieren nicht unbedingt weniger fehleranfällig. Und wie willst du denn die Hausnummern auf den Ways wiederfinden? Grundsätzlich habe ich nichts gegen Relations, aber ganz unproblematisch ist das Ganze auch nicht. Und ohne entsprechende Editor-Anpassungen definitiv nicht übersichtlicher. Gruß ___ Talk-de mailing list
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
Ein weitere punkt weshalb ich eine partial way relation bevorzuge ist das ich das interpolationsschema Karlsruhe sowas von Schei*** finde. Mit einem mal tauchen in den daten ways auf die gar nicht physisch existieren und das zeugs ist einfach nur unuebersichtlich. Ein vorschlag hier mit den partways waere: n1 + | |w1 | --+--+ n2 w2 n3 type=housenumberinterpolation from=n1 to=n2 via=w2 leftnumber=50,54,even rightnumber=51,55,odd type=housenumberinterpolation from=n3 to=n2 via=w2 leftnumber=1,21,odd rightnumber=2,22,even Und schon sind die Hausnummern da dran ... Keine millionen von nodes und ways die voellig unuebersichtlich werden nur um hausnummern darzustellen. Flo Du uebersiehst bei Deiner Kritik, dass die Hausnummern sehr wohl physisch existieren, naemlich als Grundstuecke bzw. Haeuser, bzw. Eingaenge, und diese sind nicht Teil der Strasse sondern getrennt davon. Von daher habe ich ueberhaupt keine Bedenken, mit den Hausnummern wie bisher fortzufahren. Schoen waere es aber, die Tags im Editor auf verschiedene Layer filtern zu koennen, so dass man sie bei Bedarf z.B. sperren (oder sogar ausblenden) kann, und nicht versehentlich Ways verbindet, die eigentlich nichts miteinander zu tun haben. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Thu, Oct 23, 2008 at 11:02:27PM +0200, Sebastian Hohmann wrote: Besser daran ist, dass Häuser nunmal neben der Straße liegen und wir versuchen die Wirklichkeit vereinfacht abzubilden. Zudem ist es noch konsistent zu POIs wie Geschäften oder Restaurants die auch neben der Straßen eingetragen werden und Adressen tragen können. Nichts spricht dagegen addressen/hausnummern die man genauer kennt auch so einzutragen - aber fuer den grossteil der Straßen wird auf alle ewigkeit eine interpolation reichen. Mehr haben die kommerziellen im moment auch nicht und kriegen damit schon ganz beachtliche ergebnisse hin. Und der Aufwand von Straßennetz zu erfassen zu Straßen + Interpolierte Hausnummern ist vermutlich irgendwas mit 1:10. Wenn wir jetzt noch JEDE Hausnummer einzeln aufnehmen und einen genauen punkt zuordnen ist man nochmal bei 1:10. Da wir noch nichtmal mit dem Straßennetz vollstaendig sind liegen noch 99% der Aufgabe vor uns. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Florian Lohoff schrieb: On Thu, Oct 23, 2008 at 11:02:27PM +0200, Sebastian Hohmann wrote: Besser daran ist, dass Häuser nunmal neben der Straße liegen und wir versuchen die Wirklichkeit vereinfacht abzubilden. Zudem ist es noch konsistent zu POIs wie Geschäften oder Restaurants die auch neben der Straßen eingetragen werden und Adressen tragen können. Nichts spricht dagegen addressen/hausnummern die man genauer kennt auch so einzutragen - aber fuer den grossteil der Straßen wird auf alle ewigkeit eine interpolation reichen. Mehr haben die kommerziellen im moment auch nicht und kriegen damit schon ganz beachtliche ergebnisse hin. Und der Aufwand von Straßennetz zu erfassen zu Straßen + Interpolierte Hausnummern ist vermutlich irgendwas mit 1:10. Wenn wir jetzt noch JEDE Hausnummer einzeln aufnehmen und einen genauen punkt zuordnen ist man nochmal bei 1:10. Da wir noch nichtmal mit dem Straßennetz vollstaendig sind liegen noch 99% der Aufgabe vor uns. Allerdings kommt es ja darauf an wo man wohnt. In Gegegenden die gut erfasst sind und viele Mapper haben, werden sicher auch Hausnummern schneller und detaillierter erfasst. Aber es stimmt wohl schon, dass meistens eine Interpolation reicht und habe auch nichts gegenteiliges behauptet. Ich finde eben bloss die Mischung zwischen neben der Straße/an der Straße nicht schön. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
Florian Lohoff schrieb: Ausserdem suche ich einen ausweg aus dem Karlsruhe Schema. Neben jeden weg noch 2 wege zu pflanzen nur weil ich dem weg ein paar interpolierte hausnummern geben will ist overkill. Dazu kommt ja noch das Dogma das nur physisch existentes gemappt werden soll. Dieser interpolation weg ist aber eben nichts existentes sondern nur etwas virtuelles. Also ist mein ansatz eben dem weg noch eine zusaetzliche richtung zu geben die unabhaengig von der richtung des ways ist, und auch unabhaengig von den nodes in der mitte. Ich dachte die Idee hinter dem Karlsruhe Schema ist es die einzelnen Häuser zu mappen. Die Interpolation ist doch nur eine Übergangslösung (in einigen Gegenden vermutlich für recht lange) die es eben zunächst einfacher machen soll. Aber letztendlich ist es doch auch etwas physisch existentes. Hausnummern gehören nunmal zu Häusern und nicht nur an den Rand der Straße. Natürlich würde es vom Ergebnis her in den meisten Fällen aufs Gleiche rauskommen, aber z.B. POIs werden ja auch nicht auf die Straße gemappt. Wenn man das nun aber mit den Hausnummern macht, sind sie einmal an der Straße und einmal an den POIs. Die Interpolationslinie existiert so natürlich nicht, aber repräsentiert eben die Häuser auf einer in etwa gleichmäßig bebauten Strecke, ohne jedes einzeln angeben zu müssen. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Thu, Oct 23, 2008 at 06:41:50PM +0200, Sebastian Hohmann wrote: Florian Lohoff schrieb: Ausserdem suche ich einen ausweg aus dem Karlsruhe Schema. Neben jeden weg noch 2 wege zu pflanzen nur weil ich dem weg ein paar interpolierte hausnummern geben will ist overkill. Dazu kommt ja noch das Dogma das nur physisch existentes gemappt werden soll. Dieser interpolation weg ist aber eben nichts existentes sondern nur etwas virtuelles. Also ist mein ansatz eben dem weg noch eine zusaetzliche richtung zu geben die unabhaengig von der richtung des ways ist, und auch unabhaengig von den nodes in der mitte. Ich dachte die Idee hinter dem Karlsruhe Schema ist es die einzelnen Häuser zu mappen. Die Interpolation ist doch nur eine Übergangslösung (in einigen Gegenden vermutlich für recht lange) die es eben zunächst einfacher machen soll. Aber letztendlich ist es doch auch etwas physisch existentes. Hausnummern gehören nunmal zu Häusern und nicht nur an den Rand der Straße. Natürlich würde es vom Ergebnis her in den meisten Fällen aufs Gleiche rauskommen, aber z.B. POIs werden ja auch nicht auf die Straße gemappt. Wenn man das nun aber mit den Hausnummern macht, sind sie einmal an der Straße und einmal an den POIs. Die Interpolationslinie existiert so natürlich nicht, aber repräsentiert eben die Häuser auf einer in etwa gleichmäßig bebauten Strecke, ohne jedes einzeln angeben zu müssen. Was ist daran besser eine nicht existente linie neben eine straße einzuzeichen die haeuser represaentieren soll - anstatat die straße dafuer zu missbrauchen? Beides hat vor und nachteile und wenn ich mir den datenwust ansehe wenn jemand da volles programm die interpolation dranmalt dann prost malzeit ... Das ganze muss trivial sein zum eintragen sonst machts keiner. Ich habe das ganze auch noch nicht angefangen mit den Hausnummern weil ich das Karlsruhe Schema einfach zu haesslich finde - Und mehr als interpolation sehe ich im moment hier keine notwendigkeit fuer. Ich meine wenn wir freigegebene Luftbilder haben und schoen jedem haus auch die hausnummer geben ist das ja alles super. So lange - interpoliert bis der arzt kommt ... Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, 22 Oct 2008, Florian Lohoff wrote: Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via relations dranknoten d.h. Wunderbar. Statt also den Weg in zwei Teile zu teilen willst Du unzählige Relationen dranpappen, bei denen der Synchronisierungsaufwand so enorm ist, dass wir mehr damit zu tun haben werden die Daten synchron zu halten, als neue Daten einzupflegen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, Oct 22, 2008 at 03:34:48PM +0200, Dirk Stöcker wrote: Subject: Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur On Wed, 22 Oct 2008, Florian Lohoff wrote: Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via relations dranknoten d.h. Wunderbar. Statt also den Weg in zwei Teile zu teilen willst Du unzählige Relationen dranpappen, bei denen der Synchronisierungsaufwand so enorm ist, dass wir mehr damit zu tun haben werden die Daten synchron zu halten, als neue Daten einzupflegen. Egal wie du es drehst und wendest - irgendwelche datenobjekte die die abschnitte spezifizieren und deren attribute brauchst du. Wie schlaegst du es also vor? Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, 22 Oct 2008, Florian Lohoff wrote: Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via relations dranknoten d.h. Wunderbar. Statt also den Weg in zwei Teile zu teilen willst Du unzählige Relationen dranpappen, bei denen der Synchronisierungsaufwand so enorm ist, dass wir mehr damit zu tun haben werden die Daten synchron zu halten, als neue Daten einzupflegen. Egal wie du es drehst und wendest - irgendwelche datenobjekte die die abschnitte spezifizieren und deren attribute brauchst du. So einfach ist das nicht. Die bisherige Methode Wege in Abschnitte zu teilen sieht vielleicht nicht so schön aus, ist algorithmisch aber leicht zu verarbeiten. Wenn die Renderer sich endlich mal bequemen würden zusammengehörige Teile wieder zusammenzufügen, dann wäre der einzige wirkliche Kritikpunkt einer unschönen Kartendarstellung endlich aus der Welt. Dein Vorschlag hingegen würde die Daten aber in einer Art und Weise über die Datenbank verteilen, die dafür sorgt, dass der Aufwand zusammengehörige Informationen in einem konsitenten Zustand zu halten sehr groß wird. Wie schlaegst du es also vor? Das bisherige Schema konsequent nutzen. Bei richtungsabhängigen Informationen wenige Standardtags etablieren (meinetwegen backward, forward, left, right) und diese auch in den Editoren unterstützen. Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen Weg betrachten. An Kachelgrenzen muss man dann ein wenig aufpassen, aber sonst ist das eigentlich trivial, da ich in Zweifelsfällen ja immer auf die Methode einfach alles auszugeben zurückfallen kann. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, Oct 22, 2008 at 04:25:13PM +0200, Dirk Stöcker wrote: So einfach ist das nicht. Die bisherige Methode Wege in Abschnitte zu teilen sieht vielleicht nicht so schön aus, ist algorithmisch aber leicht zu verarbeiten. Wenn die Renderer sich endlich mal bequemen würden zusammengehörige Teile wieder zusammenzufügen, dann wäre der einzige wirkliche Kritikpunkt einer unschönen Kartendarstellung endlich aus der Welt. Dein Vorschlag hingegen würde die Daten aber in einer Art und Weise über die Datenbank verteilen, die dafür sorgt, dass der Aufwand zusammengehörige Informationen in einem konsitenten Zustand zu halten sehr groß wird. Den renderer interessieren teile der daten nicht. Ausserdem fuehrt das derzeitige schema und dessen konsequente anwendung zu einer massenhaften duplikation von informationen - auf jedem way teilstueck ist ein name, ein ref, ein highwaytype und dann entsprechend alle attribute dieses teilabschnittes erneut. Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen Weg betrachten. An Kachelgrenzen muss man dann ein wenig aufpassen, aber sonst ist das eigentlich trivial, da ich in Zweifelsfällen ja immer auf die Methode einfach alles auszugeben zurückfallen kann. Es geht mir ueberhaupt nicht ueber das rendering sondern darum das bestimmte attribute im moment nicht zu modellieren sind. So sind vorschlaege zu fahrradwegen, gefaellen/steigungen, einseitige geschwindigkeitsbeschraenkungen, einseitige zufahrtsbeschraenkungen alle bisher dran gescheitert das es eben keine moeglichkeit der modellierung gibt. Um bei meinem Beispiel zu bleiben: |--| Way Beispielstraße ref K1 || Geschwindigkeit 80 |---| Fahrradweg links |---|Fahrradweg rechts |111355| Derzeit: way 1 highway=tertiary ref=k1 name=Beispielstraße maxspeed=80 way 2 highway=teriary ref=k1 name=Beispielstraße maxspeed=80 left:cycleway=lane way 3 highway=teriary ref=k1 name=Beispielstraße maxspeed=80 cycleway=both way 4 highway=teriary ref=k1 name=Beispielstraße maxspeed=80 left:cycleway=lane way 5 highway=teriary ref=k1 name=Beispielstraße left:cycleway=lane Mein vorschlag: way 1 highway=tertiary ref=k1 name=Beispielstraße rel 1 type=maxspeed from=Node1 to=Node2 via=way1 maxspeed=80 rel 2 type=cycleway from=Node3 to=Node4 vi=way1 cycleway=left rel 3 type=cycleway from=Node5 to=Node6 vi=way1 cycleway=right D.h. es geht mir drum informationen nur noch einmal zu halten und nicht alles bis zum exitus zu verdoppeln und verdreifachen. Dazu kommt noch das ich hier dinge abbilden kann die eben nur mit 3 mal durch den hulahupp reifen und viel editor gewurschtel richtig hinzubekommen ist. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
2008/10/22 Florian Lohoff [EMAIL PROTECTED]: On Wed, Oct 22, 2008 at 04:24:03PM +0200, Dominik Spies wrote: Hallo, Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via relations dranknoten d.h. Unidirektionale geschwindigkeitsbeschraenkungen: type=speedlimit from=nodeidA to=nodeidB via=wayID speed=60 direction=both Cyclelanes auf einer ODER beiden seiten type=cyclelane from=nodeidA to=nodeidB via=wayId side=both ... OMG! Nein. Das ist ja eine Vergewaltigung von Relationen. Den Weg zerteilen, alle Teile in eine Relation. Alles Information, die für die komplette Relationen gültig ist in die Relationen (name, ref, highway=x, ..) und dann entsprechend die Tags auf die ways. Das ist doch viel besser zu pflegen (wäre auch einfach und komfortabel in einen Editor zu implementieren!) Der vorteil ist halt das eine information immer genau nur einmal vorhanden ist. Das problem ist ja heute (was ich recht haeufig repariere) das irgendwelche mapper ein ref oder einen namen auf einer bisher unbeleckten straße eintragen - Leider jedoch nur auf einem bruchteil der strecke weil die landstraße halt alle 300m unterbrochen ist durch eine bruecke etc - D.h. die idee das so oder so aehnlich zu loesen ist das eben das ref oder der name oder die geschwindigkeitsbeschraenkung unabhaengig von irgendwelchen fragmenten existiert. Beispiel: |--| Way Beispielstraße ref K1 || Geschwindigkeit 80 |---| Fahrradweg links |---|Fahrradweg rechts |111355| Sind derzeit 5 ways und bei allen 5 ist das ref, der name und der straßentyp drauf. In einem datenmodell wie oben waere das EIN way + 3 relations. Hm. 5 ways ja, bei meinem Vorschlag wäre aber nur der maxspeed und cycleway=lane Tag teilweise redundant. Den ref und name könnten Problemlos in die Relation! Von deiner Position auch habe ich das noch gar nicht betrachtet. Hat auch Vorteile, das die Tags nicht redundant ausfallen. Dominik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, Oct 22, 2008 at 04:24:03PM +0200, Dominik Spies wrote: Hallo, Ich wuerde halt den way gar nicht mehr unterbrechen wollen sondern alle nur abschnittsweise, oder richtungsabhaengig auftretenden attribute via relations dranknoten d.h. Unidirektionale geschwindigkeitsbeschraenkungen: type=speedlimit from=nodeidA to=nodeidB via=wayID speed=60 direction=both Cyclelanes auf einer ODER beiden seiten type=cyclelane from=nodeidA to=nodeidB via=wayId side=both ... OMG! Nein. Das ist ja eine Vergewaltigung von Relationen. Den Weg zerteilen, alle Teile in eine Relation. Alles Information, die für die komplette Relationen gültig ist in die Relationen (name, ref, highway=x, ..) und dann entsprechend die Tags auf die ways. Das ist doch viel besser zu pflegen (wäre auch einfach und komfortabel in einen Editor zu implementieren!) Der vorteil ist halt das eine information immer genau nur einmal vorhanden ist. Das problem ist ja heute (was ich recht haeufig repariere) das irgendwelche mapper ein ref oder einen namen auf einer bisher unbeleckten straße eintragen - Leider jedoch nur auf einem bruchteil der strecke weil die landstraße halt alle 300m unterbrochen ist durch eine bruecke etc - D.h. die idee das so oder so aehnlich zu loesen ist das eben das ref oder der name oder die geschwindigkeitsbeschraenkung unabhaengig von irgendwelchen fragmenten existiert. Beispiel: |--| Way Beispielstraße ref K1 || Geschwindigkeit 80 |---| Fahrradweg links |---|Fahrradweg rechts |111355| Sind derzeit 5 ways und bei allen 5 ist das ref, der name und der straßentyp drauf. In einem datenmodell wie oben waere das EIN way + 3 relations. Ja das mag sein das das fuer renderer schwieriger auszuwerten ist als das bisherige modell - da hat aber jemand bei Karlsruhe Hausnummernschema auch keine ruecksicht drauf genommen. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, Oct 22, 2008 at 04:56:12PM +0200, Dominik Spies wrote: Beispiel: |--| Way Beispielstraße ref K1 || Geschwindigkeit 80 |---| Fahrradweg links |---|Fahrradweg rechts |111355| Sind derzeit 5 ways und bei allen 5 ist das ref, der name und der straßentyp drauf. In einem datenmodell wie oben waere das EIN way + 3 relations. Hm. 5 ways ja, bei meinem Vorschlag wäre aber nur der maxspeed und cycleway=lane Tag teilweise redundant. Den ref und name könnten Problemlos in die Relation! Von deiner Position auch habe ich das noch gar nicht betrachtet. Hat auch Vorteile, das die Tags nicht redundant ausfallen. Ich bin da ja nicht religioes ob man die relations so vergewaltigen muss/sollte. Defakto sind das die art der objekte die mehrere ways/nodes verknoten koennen. Vielleicht liesse sich das auch mit einem relation type erschlagen d.h. relation=waypart oder so der dann die informationen enthaelt. Ich weiss das relations im moment fuer die meisten mapper noch Boehmische Doerfer sind und sich da kaum einer rantraut aber die dinger sind wirklich ein segen und universell einsetzbar. Fuer die mapper kann das der editor ja super verstecken. Der kann einfach einen teilabschnitt markieren und sagen was darauf gilt und der editor baut die relation zusammen. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, Oct 22, 2008 at 04:52:24PM +0200, Florian Lohoff wrote: Es geht mir ueberhaupt nicht ueber das rendering sondern darum das bestimmte attribute im moment nicht zu modellieren sind. So sind vorschlaege zu fahrradwegen, gefaellen/steigungen, einseitige geschwindigkeitsbeschraenkungen, einseitige zufahrtsbeschraenkungen alle bisher dran gescheitert das es eben keine moeglichkeit der modellierung gibt. Um bei meinem Beispiel zu bleiben: |--| Way Beispielstraße ref K1 || Geschwindigkeit 80 |---| Fahrradweg links |---|Fahrradweg rechts |111355| Ein weitere punkt weshalb ich eine partial way relation bevorzuge ist das ich das interpolationsschema Karlsruhe sowas von Schei*** finde. Mit einem mal tauchen in den daten ways auf die gar nicht physisch existieren und das zeugs ist einfach nur unuebersichtlich. Ein vorschlag hier mit den partways waere: n1 + | |w1 | --+--+ n2 w2 n3 type=housenumberinterpolation from=n1 to=n2 via=w2 leftnumber=50,54,even rightnumber=51,55,odd type=housenumberinterpolation from=n3 to=n2 via=w2 leftnumber=1,21,odd rightnumber=2,22,even Und schon sind die Hausnummern da dran ... Keine millionen von nodes und ways die voellig unuebersichtlich werden nur um hausnummern darzustellen. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, 22 Oct 2008, Florian Lohoff wrote: Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen Weg betrachten. An Kachelgrenzen muss man dann ein wenig aufpassen, aber sonst ist das eigentlich trivial, da ich in Zweifelsfällen ja immer auf die Methode einfach alles auszugeben zurückfallen kann. Es geht mir ueberhaupt nicht ueber das rendering sondern darum das bestimmte attribute im moment nicht zu modellieren sind. So sind vorschlaege zu fahrradwegen, gefaellen/steigungen, einseitige geschwindigkeitsbeschraenkungen, einseitige zufahrtsbeschraenkungen alle bisher dran gescheitert das es eben keine moeglichkeit der modellierung gibt. Gehen wir mal auf die Basis zurück. Wir haben momentan drei Datentypen: a) einfache Knoten b) Wege, die aus diesen Aufgebaut sind c) Relationen, welche aus Wegen oder Knoten aufgebaut sind. Was Du vorschlägst ist das Durchbrechen dieser einfachen Struktur - Du willst Relationen, welche Abschnitte von Wegen beschreiben. Jeder der objektorientierte Programmierung verstanden hat wird Dir sagen, dass Zugriff auf Innereien eines Objekts nichts in anderen Objekten zu suchen haben, da dadurch eine sehr hohe Komplexizität entsteht. Und die Knoten sind interne Informationen eines Weges. Ich verstehe, dass es nicht sofort einsichtig ist, dass diese Herangehensweise zu Chaos führt, aber ich kann Dir nach mehr als 15 Jahren Programmierpraxis beteuern, dass es so ist. Ich habe zu oft gesehen, dass Software gescheitert ist, welche sich nicht an diese Regeln hielt. Wenn Dich die Doppelinformationen stören, dann baue das ganze andersherum auf. In Deinem Beispiel: Teile den Weg in 5 Abschnitte und packe die Informationen in Relationen. Name und Ref bleiben sehr wahrscheinlich lange konstant, also kommen diese in eine Relation. Maxspeed und ähnliches ändert sich schnell, wird also direkt an den Weg geklebt. Bei dieser Herangehensweise bleibt eine Stack-artige Strukt bestehen. Jede Objektgruppe baut auf Objekten niederer Gruppen auf ohne durch eine Objekt hindurch auf dessen interne Informationen zuzugreifen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, Oct 22, 2008 at 06:03:19PM +0200, Dirk Stöcker wrote: On Wed, 22 Oct 2008, Florian Lohoff wrote: Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen Weg betrachten. An Kachelgrenzen muss man dann ein wenig aufpassen, aber sonst ist das eigentlich trivial, da ich in Zweifelsfällen ja immer auf die Methode einfach alles auszugeben zurückfallen kann. Es geht mir ueberhaupt nicht ueber das rendering sondern darum das bestimmte attribute im moment nicht zu modellieren sind. So sind vorschlaege zu fahrradwegen, gefaellen/steigungen, einseitige geschwindigkeitsbeschraenkungen, einseitige zufahrtsbeschraenkungen alle bisher dran gescheitert das es eben keine moeglichkeit der modellierung gibt. Gehen wir mal auf die Basis zurück. Wir haben momentan drei Datentypen: a) einfache Knoten b) Wege, die aus diesen Aufgebaut sind c) Relationen, welche aus Wegen oder Knoten aufgebaut sind. Was Du vorschlägst ist das Durchbrechen dieser einfachen Struktur - Du willst Relationen, welche Abschnitte von Wegen beschreiben. - Abschnitte - Richtung - Ueberlappende Abschnitte - Unterschiedliche richtungen auf den unterschiedlichen abschnitten Jeder der objektorientierte Programmierung verstanden hat wird Dir sagen, dass Zugriff auf Innereien eines Objekts nichts in anderen Objekten zu suchen haben, da dadurch eine sehr hohe Komplexizität entsteht. Und die Knoten sind interne Informationen eines Weges. Ich verstehe, dass es nicht sofort einsichtig ist, dass diese Herangehensweise zu Chaos führt, aber ich kann Dir nach mehr als 15 Jahren Programmierpraxis beteuern, dass es so ist. Ich habe zu oft gesehen, dass Software gescheitert ist, welche sich nicht an diese Regeln hielt. Wir haben dieses defakto schon by turn relations. Ich gebe dir recht das das nicht die schoenste loesung ist - aber sie ist etabliert. Wenn Dich die Doppelinformationen stören, dann baue das ganze andersherum auf. In Deinem Beispiel: Teile den Weg in 5 Abschnitte und packe die Informationen in Relationen. Name und Ref bleiben sehr wahrscheinlich lange konstant, also kommen diese in eine Relation. Maxspeed und ähnliches ändert sich schnell, wird also direkt an den Weg geklebt. Ja - gebe ich dir recht - ist schoener - problem ist halt das dinge die OFT benutzt werden d.h. name, ref, highway dann mit der relation abgefruehstueckt werden - und dinge die selten benutzt werden direkt auf dem weg. Also irgendwie ziemlich unschoen. Natuerlich koennte man die modelle parallel existieren lassen - was aber das ganze nur noch komplexer macht. Bei dieser Herangehensweise bleibt eine Stack-artige Strukt bestehen. Jede Objektgruppe baut auf Objekten niederer Gruppen auf ohne durch eine Objekt hindurch auf dessen interne Informationen zuzugreifen. Damit ist das richtungsproblem aber nicht geloest. Natuerlich ist dieses stacking schoen - aber es loest das imho groesste problem des datenmodells - der richtungsabhaengigkeit - nicht. Und richtungsabhaengigkeit ist halt zwischen punkten eines weges. Und leider muessen wir auf dem selben weg mehrere attribute abfruehstuecken die unterschiedliche richtungen haben - und ich denke du gibst mir recht das oneway=-1 ein ziemlich ekelhaftes hilfskonstrukt ist. D.h. die eine existente richtung des weges mehrfach zu missbrauchen um unterschiedliches zu modellieren ist grosser bullshit. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Wed, 22 Oct 2008, Florian Lohoff wrote: dass Zugriff auf Innereien eines Objekts nichts in anderen Objekten zu suchen haben, da dadurch eine sehr hohe Komplexizität entsteht. Und die Knoten sind interne Informationen eines Weges. Ich verstehe, dass es nicht sofort einsichtig ist, dass diese Herangehensweise zu Chaos führt, aber ich kann Dir nach mehr als 15 Jahren Programmierpraxis beteuern, dass es so ist. Ich habe zu oft gesehen, dass Software gescheitert ist, welche sich nicht an diese Regeln hielt. Wir haben dieses defakto schon by turn relations. Ich gebe dir recht das das nicht die schoenste loesung ist - aber sie ist etabliert. Nein. Hier ist ein großer Unterschied. Die Turn-Relations nutzen einen Knoten als Teil der Relation. Sie nutzen keinen Knoten als Teils eines Weges in der Relation. Das ist ein wichtiges Detail. Bei dieser Herangehensweise bleibt eine Stack-artige Strukt bestehen. Jede Objektgruppe baut auf Objekten niederer Gruppen auf ohne durch eine Objekt hindurch auf dessen interne Informationen zuzugreifen. Damit ist das richtungsproblem aber nicht geloest. Natuerlich ist dieses stacking schoen - aber es loest das imho groesste problem des datenmodells - der richtungsabhaengigkeit - nicht. Und richtungsabhaengigkeit ist halt zwischen punkten eines weges. Und leider muessen wir auf dem selben weg mehrere attribute abfruehstuecken die unterschiedliche richtungen haben - und ich denke du gibst mir recht das oneway=-1 ein ziemlich ekelhaftes hilfskonstrukt ist. D.h. die eine existente richtung des weges mehrfach zu missbrauchen um unterschiedliches zu modellieren ist grosser bullshit. Deswegen wie gesagt standardisierte Methoden backward, forward, left, right. Wenn das etabliert ist, dann ist klar das maxspeed:backward und maxspeed:forward richtungsabhängig sind und maxspeed nicht. Und das kann dann auf alle Tags ausgedehnt werden: tracktype:forward=3, tracktype:backward=1 oder meinetwegen sogar bridge:forward=yes, bridge:backward=no (auch wenn mir hier eine Anwendung fehlt :-). JOSM unterstützt das ja schon seit einer Weile zumindest bei Drehen eines Weges. Das Tag oneway wird wohl trotzdem bleiben, auch wenn es dann eigentlich access:backward=no sein müsste. Und wenn man irgendwann mal das Datenmodell ändern will, dann teilt man das ganze gleich in entsprechende Gruppen auf statt den Schlüssel zu verunstalten. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Wed, Oct 22, 2008 at 06:38:52PM +0200, Dirk Stöcker wrote: Wir haben dieses defakto schon by turn relations. Ich gebe dir recht das das nicht die schoenste loesung ist - aber sie ist etabliert. Nein. Hier ist ein großer Unterschied. Die Turn-Relations nutzen einen Knoten als Teil der Relation. Sie nutzen keinen Knoten als Teils eines Weges in der Relation. Das ist ein wichtiges Detail. Der Knoten in der turn restriction ist teil beider wege oder habe ich da was nicht verstanden an den turn restrictions? Der unterschied meiner idee zur turn restriction ist dann wohl das ich 2 punkte eines weges brauche und die turn restriction nur einen oder? Und richtungsabhaengigkeit ist halt zwischen punkten eines weges. Und leider muessen wir auf dem selben weg mehrere attribute abfruehstuecken die unterschiedliche richtungen haben - und ich denke du gibst mir recht das oneway=-1 ein ziemlich ekelhaftes hilfskonstrukt ist. D.h. die eine existente richtung des weges mehrfach zu missbrauchen um unterschiedliches zu modellieren ist grosser bullshit. Deswegen wie gesagt standardisierte Methoden backward, forward, left, right. Wenn das etabliert ist, dann ist klar das maxspeed:backward und maxspeed:forward richtungsabhängig sind und maxspeed nicht. Und das kann dann auf alle Tags ausgedehnt werden: tracktype:forward=3, tracktype:backward=1 oder meinetwegen sogar bridge:forward=yes, bridge:backward=no (auch wenn mir hier eine Anwendung fehlt :-). JOSM unterstützt das ja schon seit einer Weile zumindest bei Drehen eines Weges. Das Tag oneway wird wohl trotzdem bleiben, auch wenn es dann eigentlich access:backward=no sein müsste. Und wenn man irgendwann mal das Datenmodell ändern will, dann teilt man das ganze gleich in entsprechende Gruppen auf statt den Schlüssel zu verunstalten. Sorry - aber das modell ist krank - Weil ich keine lust habe weitere richtungen zu modellieren vergewaltige ich die einzige richtung des weges die ich habe und overloade die mit allem was richtungsabhaengig ist. Ausserdem ist ja hier dann auch das stacking kaputt. Beispiel: 1 2 3 |a|b| Ich moechte darstellen das von node 1 bis node 3 eine geschwindigkeitsbeschraenkung nur in der richtung existiert. Relation aus a + b - maxspeed=50 und dann? Wo ist die richtung? Also doch wieder die daten auf den weg a und b ? a forward:maxspeed=50 b backward:maxspeed=50 Das ist doch das krankeste modell was ich jeh gesehen habe. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Wed, 22 Oct 2008, Florian Lohoff wrote: Wir haben dieses defakto schon by turn relations. Ich gebe dir recht das das nicht die schoenste loesung ist - aber sie ist etabliert. Nein. Hier ist ein großer Unterschied. Die Turn-Relations nutzen einen Knoten als Teil der Relation. Sie nutzen keinen Knoten als Teils eines Weges in der Relation. Das ist ein wichtiges Detail. Der Knoten in der turn restriction ist teil beider wege oder habe ich da was nicht verstanden an den turn restrictions? Das das praktisch so ist stimmt. Aber wenn Du theoretisch herangehst, dann habe ich Weg1 - Über-Knoten - Weg2. Das kaum Fälle vorstellbar sind, wo die Knoten nicht zu Weg1 und Weg2 gehört ist richtig, aber theoretisch eben vorstellbar. Der unterschied meiner idee zur turn restriction ist dann wohl das ich 2 punkte eines weges brauche und die turn restriction nur einen oder? Nein. Du erwartest die Garantie, das beide Knoten im Weg enthalten sind und auch Ihre Geometrie zueinander nicht geändert haben. Dies ist ein um Größenordnungen stärker Eingriff. Sorry - aber das modell ist krank - Weil ich keine lust habe weitere richtungen zu modellieren vergewaltige ich die einzige richtung des weges die ich habe und overloade die mit allem was richtungsabhaengig ist. Ausserdem ist ja hier dann auch das stacking kaputt. Beispiel: 1 2 3 |a|b| Ich moechte darstellen das von node 1 bis node 3 eine geschwindigkeitsbeschraenkung nur in der richtung existiert. Relation aus a + b - maxspeed=50 und dann? Wo ist die richtung? Relationen haben momentan keine Richtung, da die Elemente nicht geordnet sind. Wenn man eine Richtung einer Relation haben will, dann wäre das die Richtung der Reihenfolge Ihrer Elemente (und nicht die Richtung der zugrundeliegenden Wege). Sollte sich eine bessere Richtungsabbildung auf Ebene der Wege durchsetzen, dann wird schon irgendjemand das gleiche auch für Relationen fordern. Also doch wieder die daten auf den weg a und b ? a forward:maxspeed=50 b backward:maxspeed=50 Das ist doch das krankeste modell was ich jeh gesehen habe. Es ist mit Deiner Überlegung identisch nur durchbricht es das Datenprinzip nicht. Jeder Weg hat automatisch eine Richtung, die durch die Reihenfolge der Knoten geschaffen wird. Das Tagging setzt nur darauf auf. Dein Vorschlag läuft darauf hinaus die Richtungsherrschaft vom Weg in eine Relation zu überführen, die Teile eines Weges abbildet, aber ansonsten hast Du das gleiche Prinzip. Warum ist jetzt Deine Variante nicht krank, obwohl ich Dir versuchte die grundlegenden Probleme der Herangehensweise aufzuzeigen? Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags
On Wed, Oct 22, 2008 at 07:08:09PM +0200, Dirk Stöcker wrote: Das das praktisch so ist stimmt. Aber wenn Du theoretisch herangehst, dann habe ich Weg1 - Über-Knoten - Weg2. Das kaum Fälle vorstellbar sind, wo die Knoten nicht zu Weg1 und Weg2 gehört ist richtig, aber theoretisch eben vorstellbar. Der unterschied meiner idee zur turn restriction ist dann wohl das ich 2 punkte eines weges brauche und die turn restriction nur einen oder? Nein. Du erwartest die Garantie, das beide Knoten im Weg enthalten sind und auch Ihre Geometrie zueinander nicht geändert haben. Dies ist ein um Größenordnungen stärker Eingriff. Okay - das heisst wir haben ein validator problem hinterher - aber kein syntaktisches oder semantisches. Ich meine ich kann niemanden daran hindern in einer relation mist objekte als member einzubauen. Ob nodes in einem way die reihenfolge aendern koennen ist vermutlich richtig auch wenn mit einem editor ohne loeschen/neu anlegen des weges das nicht machbar scheint. Also doch wieder die daten auf den weg a und b ? a forward:maxspeed=50 b backward:maxspeed=50 Das ist doch das krankeste modell was ich jeh gesehen habe. Es ist mit Deiner Überlegung identisch nur durchbricht es das Datenprinzip nicht. Jeder Weg hat automatisch eine Richtung, die durch die Reihenfolge der Knoten geschaffen wird. Das Tagging setzt nur darauf auf. Dein Vorschlag läuft darauf hinaus die Richtungsherrschaft vom Weg in eine Relation zu überführen, die Teile eines Weges abbildet, aber ansonsten hast Du das gleiche Prinzip. Warum ist jetzt Deine Variante nicht krank, obwohl ich Dir versuchte die grundlegenden Probleme der Herangehensweise aufzuzeigen? Weil die zufaellige reihenfolge von nodes hier mehrfach ueberladen wird. Und wenn die richtung nicht passt dann muss ich das was ich drantagge im vorzeichen aendern. Das ist wesentlich unintuitiver als explizit einen abschnitt und richtung anzugeben fuer jedes attribut was ich an einen weg haenge. Ist es auf dem weg selber gilt es fuer den gesamten weg, habe ich eine waypart relation gilt es nur fuer eben diesen abschnitt und auch evtl nur in der angegebenen richtung. Wenn man das generisch anlegt dann duerfen in der relation dieselben attribute wie auf dem weg auftauchen und jeder renderer kann den weg dann nach gusto zerlegen, zusammenfuegen oder was auch immer. Bisher koennten osmarender und mapnik jedenfalls sowas wie maxspeed ignorieren. Dennoch penetrieren wir die renderer mit den ganzen wayschnipseln nur weil sich der maxspeed aendert. Im prinzip ist es doch so das auch ein weg nur eine besondere art der relation ist. D.h. ich setze nodes zu einer relation zusammen und haenge da attribute dran. Wenn ich die richtung ignoriere ist ein way nichts anderes als eine relation - Die besonderheit des weges ist im vergleich zur relation das es ein ordering der member gibt. Ich suche einfach eine Loesung der modellierung ohne die ways in 740 schnipsel zerlegen zu muessen. Wegen jeder dummen bruecke, geschwindigkeitsbeschraenkung, cyclelane aenderung dupliziere ich alle tags des weges. Das fuehrt hier in der gegend gerne dazu das nur auf einem bruchteil der way schnipsel sowas wie ref oder name gepflegt sind. Sowas wie die bridge schnipsel werden gerne vergessen. Ausserdem suche ich einen ausweg aus dem Karlsruhe Schema. Neben jeden weg noch 2 wege zu pflanzen nur weil ich dem weg ein paar interpolierte hausnummern geben will ist overkill. Dazu kommt ja noch das Dogma das nur physisch existentes gemappt werden soll. Dieser interpolation weg ist aber eben nichts existentes sondern nur etwas virtuelles. Also ist mein ansatz eben dem weg noch eine zusaetzliche richtung zu geben die unabhaengig von der richtung des ways ist, und auch unabhaengig von den nodes in der mitte. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
Dirk Stöcker wrote: On Wed, 22 Oct 2008, Florian Lohoff wrote: Und wie gesagt, das Rendering verbessern. Wenn ich x Wege habe, die alle den gleichen Namen/Ref tragen und sich jeweils einen gemeinsamen Endpunkt teilen, dann kann ich diese zum Zwecke der Namensvergabe auch als einen Weg betrachten. An Kachelgrenzen muss man dann ein wenig aufpassen, aber sonst ist das eigentlich trivial, da ich in Zweifelsfällen ja immer auf die Methode einfach alles auszugeben zurückfallen kann. Es geht mir ueberhaupt nicht ueber das rendering sondern darum das bestimmte attribute im moment nicht zu modellieren sind. So sind vorschlaege zu fahrradwegen, gefaellen/steigungen, einseitige geschwindigkeitsbeschraenkungen, einseitige zufahrtsbeschraenkungen alle bisher dran gescheitert das es eben keine moeglichkeit der modellierung gibt. Gehen wir mal auf die Basis zurück. Wir haben momentan drei Datentypen: a) einfache Knoten b) Wege, die aus diesen Aufgebaut sind c) Relationen, welche aus Wegen oder Knoten aufgebaut sind. Was Du vorschlägst ist das Durchbrechen dieser einfachen Struktur - Du willst Relationen, welche Abschnitte von Wegen beschreiben. Jeder der objektorientierte Programmierung verstanden hat wird Dir sagen, dass Zugriff auf Innereien eines Objekts nichts in anderen Objekten zu suchen haben, da dadurch eine sehr hohe Komplexizität entsteht. Und die Knoten sind interne Informationen eines Weges. Ich verstehe, dass es nicht sofort einsichtig ist, dass diese Herangehensweise zu Chaos führt, aber ich kann Dir nach mehr als 15 Jahren Programmierpraxis beteuern, dass es so ist. Ich habe zu oft gesehen, dass Software gescheitert ist, welche sich nicht an diese Regeln hielt. Was genau unterscheidet denn einen Weg (K0 - K1 - K2 - ... - Kn) in deinem Modell von einer Relation bei Dirk (K0 - K1 - K2 - ... - Kn). Also ich seh das Problem mit der Objektorientierung hier nicht. Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
