Re: [Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
Florian Lohoff schrieb: > On Fri, Oct 24, 2008 at 02:40:23PM +0200, Martin Koppenhoefer wrote: >>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. > > Das ist mir schon klar das die existieren - aber ob ich mit einem pseudo > pfad neben der Straße die interpoliere (also positionen rate) - oder ob > ich das an die straße klebe ist doch eins oder? > Vom Routingergebnis her vielleicht schon, allerdings nicht von der Bedeutung her. Obwohl die Daten selbstverständlich prinzipiell benutzbar sein sollen, mappen wir trotzdem nicht für eine bestimmte Anwendung. Nur weil es einem Router vielleicht reicht die Hausnummern direkt an der Straße zu haben, ist für eine andere Anwendung die etwas korrektere Abbildung der Wirklichkeit vielleicht entscheidend. > Mein ziel ist es die Address/Hausnummernpflege zu simplifizieren. Im > moment scheue ich mich ueberhaupt das zu erheben weil die > interpolierende loesung des Karlsruhe Schema einfach ekelig ist. > Findest du. Setzt du Restaurants oder Telefonzellen auch direkt auf die Straße? > Es gibt keinen genauen bezug an welchem Punkt der Straße nun die > Hausnummer ist (und das ist fuer die Navigation das interessante). > D.h. der konverter kann nur raten und 2 rechtwinkelige auf die straße > und den interpolierenden weg konstruieren um dann dem navi zu sagen wo > es denn hinfahren soll. Das ist CPU aufwand der einfach umsonst ist. > Dazu kommt noch das die datenmenge riesig ist und die pflege aufwendig > und unuebersichtlich. > Den CPU Aufwand kann ich nicht beurteilen, allerdings bezweifle ich es, dass es für eine einzelne Adresse (zu mehreren gleichzeitig will man ja selten) so viel ausmacht. Dass man quasi raten muss ist natürlich klar. Andererseits gibt es bei manchen Häusern auch Zugänge von mehreren Seiten, da ist es sowieso fraglich wie man das abbilden soll. > Ich pflege keine Daten fuer die ich nachher nicht eine wirklich sauberere > weiterverarbeitung bzw nutzung sehe. Das ist ein aehnliches problem > wie is_in auf den places. Da das Freitext ist und wir nunmal mehrere > "Langenberg" oder "Neuenkirchen" haben ist das ganze fuer die katz weil > keine zuordnung existiert. Ebenso die nummer mit den flaechenpolygonen > um die Straße den places zuzuordnen - Das ist technisch unsauber und > einfach nur hochwissenschaftliches raten. Daher waere ich fuer Place/is_in > relations die eben die ganzen zugehoerigen Straßen (auch meinetwegen > mehrfach hierarchisch) eindeutig zuordnet. Ja - das mag auf den ersten > blick wie grosser bearbeitungsaufwand aussehen - aber es ist die einzige > saubere technische variante. Mir ist es schleierhaft wie im moment > ueberhaupt die Straßensuche funktionieren kann - Im prinzip ist das > alles nur gerate welche Straße mit dem namen nun "nahe bei" (was ja auch > schon geraten ist) einem Place ist. > Nur ist halt "nahe bei" in Mastholte im umkreis von 300m - Und in Mexiko > Stadt oder Moskau halt auch mal 100km. > Für Relations die Straßen einem Ort zuordnen wäre ich auch, da es einfach schrecklich ist, an jede Straße die PLZ und den Ort zu hängen. Eventuell sollte man auch für die PLZ eine extra Relation verwenden, da ein Ort ja nicht immer nur genau eine PLZ hat. Aber prinzipiell wären solche Relations schon praktisch um die Datenredundanz zu minimieren. Gruß ___ 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 Fri, Oct 24, 2008 at 02:40:23PM +0200, Martin Koppenhoefer wrote: >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. Das ist mir schon klar das die existieren - aber ob ich mit einem pseudo pfad neben der Straße die interpoliere (also positionen rate) - oder ob ich das an die straße klebe ist doch eins oder? Mein ziel ist es die Address/Hausnummernpflege zu simplifizieren. Im moment scheue ich mich ueberhaupt das zu erheben weil die interpolierende loesung des Karlsruhe Schema einfach ekelig ist. Es gibt keinen genauen bezug an welchem Punkt der Straße nun die Hausnummer ist (und das ist fuer die Navigation das interessante). D.h. der konverter kann nur raten und 2 rechtwinkelige auf die straße und den interpolierenden weg konstruieren um dann dem navi zu sagen wo es denn hinfahren soll. Das ist CPU aufwand der einfach umsonst ist. Dazu kommt noch das die datenmenge riesig ist und die pflege aufwendig und unuebersichtlich. Ich pflege keine Daten fuer die ich nachher nicht eine wirklich sauberere weiterverarbeitung bzw nutzung sehe. Das ist ein aehnliches problem wie is_in auf den places. Da das Freitext ist und wir nunmal mehrere "Langenberg" oder "Neuenkirchen" haben ist das ganze fuer die katz weil keine zuordnung existiert. Ebenso die nummer mit den flaechenpolygonen um die Straße den places zuzuordnen - Das ist technisch unsauber und einfach nur hochwissenschaftliches raten. Daher waere ich fuer Place/is_in relations die eben die ganzen zugehoerigen Straßen (auch meinetwegen mehrfach hierarchisch) eindeutig zuordnet. Ja - das mag auf den ersten blick wie grosser bearbeitungsaufwand aussehen - aber es ist die einzige saubere technische variante. Mir ist es schleierhaft wie im moment ueberhaupt die Straßensuche funktionieren kann - Im prinzip ist das alles nur gerate welche Straße mit dem namen nun "nahe bei" (was ja auch schon geraten ist) einem Place ist. Nur ist halt "nahe bei" in Mastholte im umkreis von 300m - Und in Mexiko Stadt oder Moskau halt auch mal 100km. 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
> > 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 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
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 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 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, 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
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: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
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, 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
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!) 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 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. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Richtungsabhaengige oder Abschnittsweise attribute/tags Was: Fahrradspur
On Wed, Oct 22, 2008 at 01:34:58PM +0200, Birgit Nietsch wrote: > Solche Fleißarbeit ist auch anderswo zu beobachten, und das finde > ich furchtbar. Vor lauter separaten Radspuren, Busspuren, > Bebauungsdaten landen wir bei einem Gewirr von parallelen Linien, > das man beim Bearbeiten kaum mehr auseinanderhalten kann. Naja - was physisch seperat existiert sollte auch demnaechst noch seperat erfasst und getagged werden. > Ich meine, dass es besser wäre, eine gut sortiere Datenstruktur für > Spuren auf einem Linienzug zu haben, und irgendwann brauchen wir > dann auch Editoren, die das so unterstützen, dass man sich als > Benutzer möglichst wenig mit den einzelnen Tags herumschlagen muss. > > Vielleicht etwas in der Art (nicht wortwörtlich, sondern sinngemäß): > > lane:a = pedestrian > lane:a:surface = gravel > lane:b = bicycle > lane:b:surface = bricks > lane:c = barrier > lane:c:barrier = fence > lane:d = road > lane:d:road:type = secondary > lane:d:road:direction = opposite > lane:d:road:speed_limit = 60 km/h > lane:e = bus > lane:e:road:direction = forward > lane:e:road:speed_limit = 60 km/h *urgs* - Ja - eine idee - bedeutet aber das eben diese dinge immer wirklich gleichzeitig existieren - d.h. im prinzip explodiert die anzahl der ways weil oefter unterbrochen werden muss weil sich parameter des ways aendern. 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 Steigungen/Gefaelle: type=decend from=nodeida to=nodeidB via=wayId angle=10% Hausnummerninterpolation: type=housenumber from=nodeIdA to=nodeIdB via=wayId left:start=50 left:end=55 Unidirektionale zufahrtsbeschraenkungen (Anlieger Frei nur an einer seite des weges) type=access from=nodeIdA to=NodeIdB via=wayId access=destination > Die Spuren in meinem Versuch eines Datenmodells gehen von links nach > rechts in Richtung des Wegs. Wenn man die Richtung eines Wegs > umdreht, sollte ein Editor nachfragen, ob er die Reihenfolgen und > Richtungen der lanes mitdrehen soll oder nicht. Das waere bei dem relationsmodell nicht notwendig - ein weitere punkt waere das ein weg keine richtung mehr braucht - Ein oneway waere auch nach obigem modell zu modellieren und die problematik das der fahrradweg auf der richtigen seite des weges bleibt wenn die richtung umgedreht wird ergibt sich erst gar nicht. > So ein neues System würde vieles über den Haufen werfen. Darum > sollte es schon sehr durchdacht sein, ehe man es einbaut. Ich > finde, wir sollten es irgendwann angehen. Obiges waere parallel einfuehrbar... Wenn man die relations noch schoen im editor versteckt ists straight forward ... 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
