Re: [Talk-de] ÖPNV - Erfassen von Tarifzonen
Im VBB (Verkehrsbund Berlin-Brandenburg) gibt es auf jeden Fall mehrere Haltestellen die in zwei oder drei Tarifzonen liegen. Der C-Bereich Berlins setzt sich z.B. aus Teilen der Landkreise Brandenburgs zusammen. Diese wiederum sind in einzelne Waben unterteilt. Selbiges gilt auch für die Tarifzonen in Potsdam, Frankfurt/O., Cottbus und Brandenburg a.d.H. Im Havelland sieht das dann so aus http://www.havelbus.de/fileadmin/daten/03%20Verkehr/Liniennetz%20und%20Wabenplan/Wabenplan_010408_Layout_Havelbus_Aktuell.pdf Es existieren somit recht viele Stationen mit mehreren Tarifzonen. Deswegen wäre ich für Relations. Wird zwar wieder schwerer für Neulinge zu verstehen sein, aber gerade ÖPNV ist ja nicht gerade einfach. On 09/29/2010 06:00 PM, Johannes Huesing wrote: Da würde ich eher die Grenzen einzeichnen. Was räumlich zusammengehört, sollte nach Möglichkeit nicht in eine Relation, so will es der Brauch. -1 Da die Grenzen willkürlich von den Verbünden gemacht werden, haben sie keine direkt sichtbaren Bezüge. Der Mehrwert wäre dann nur minimal, dass man die Grenze sieht. Eigentlich geht es ja nur darum wie viel es kostet von Haltestelle A nach Haltestelle B zu kommen. Da reicht ein Einordnen der Haltestellen aus. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
On 07/21/2010 08:55 AM, Markus wrote: Dazu entgegen habe ich folgendes gefunden: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults (aber mangels Übersetzung nicht genau verstanden) Ist das eine gute Relation? Und wenn ja: wofür genau? Gruss, Markus Die Relation ist auf jeden Fall keine Sammlung von Daten mit gleichen Werten. Viel mehr sollen Redundanzen vermieden werden, beziehungsweise Daten abgebildet werden, die keine direkte geographische Referenz haben, aber dennoch wichtig für Router sind. Also entspricht diese Relation genau dem, wozu Relations gedacht waren. Als Beispiel werden Feiertage in bestimmten Ländern und Regionen genannt, wobei ich jetzt nicht weiß, wieso das gut für die Routingalgorithmen ist. Höchstens zur Vermeidung von bestimmten Autobahnen, wenn die Niederlande Ferien hat ;). Als Beispiel für die Feiertage hier die französischen http://www.openstreetmap.org/browse/relation/957715 und die Ferien in Franche-Comté http://www.openstreetmap.org/browse/relation/957702 . Wobei ich jetzt ein bisschen neidisch auf die Franzosen bin. Die haben die Ferientermine maschinenlesbar im Netz. Aber auch die Tempolimits in unterschiedlichen Ländern sind abbildbar z.B. http://www.openstreetmap.org/browse/relation/934933 für Frankreich. Das hätte den Vorteil, dass man nicht an jeder Straße maxspeed=* taggen müsste, sondern nur noch explizite Ausnahmen. Somit bräuchte man Tags à la maxspeed=DE:urban nicht mehr. Von dem Ganzen wird bloß Otto-Normal-Mapper nichts mehr mitbekommen, da die Relation weitesgehend bei politischen Grenzen angewandt werden. Da ist halt die Frage, ob dieses Schema nicht dem Anarchie-Prinzip von OSM widerspricht. Aber das gilt ja für die meisten Relations. Grüße, Tilmann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für relationale Struktur
On 07/18/2010 09:35 AM, Jens Frank wrote: Am 18. Juli 2010 08:45 schrieb Markus liste12a4...@gmx.de: Ist es ok, mit Relationen eine relationale DB-Struktur zu simulieren? Also Objekte zu Klassen zusammenzufassen? Beispielsweise alle Tankstellen? Und in weiteren Relationen die Netze von BP, Esso, etc? Oder je alle Autogas und Strom-Tankstelle? Das sind Dinge, die ich im API über amenity=fuel, operator=Aral suchen kann. Wozu noch eine Relation? Die wird nie vollständig sein, hat extra Pflegeaufwand und keinen Mehrwert. Siehe http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories Also Relations sind keine Sammlungen von Daten mit den selben Eigenschaften. Dann könnte man ja auch alle secondary Straßen in Deutschland in einer Relation zusammen fassen etc. Mehrwert ist wie Jens sagt gleich null. Grüße Tilmann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Das in die Relation nur eine Straße hereinkommt ist Schwachsinn. Ich trage auch mehrere Straßen in die Relation ein und zumindest Nominatim kommt damit klar (siehe http://www.openstreetmap.org/browse/relation/454381). Womit wieder einmal belegt ist, dass nicht alles was im Wiki steht auch so umgesetzt wird. Und die Kontrolle finde ich jetzt auch besser, da man nur gucken muss, ob alle Objekte in der Relation enthalten sind und nur noch die in der Relation enthaltenen Adressdaten kontrollieren muss. Viele Grüße Tilmann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
On 07/17/2010 01:32 PM, steffterra wrote: ... Du hast in dieser Relation auch nur eine Straße (Sterndamm), natürlich mit allen ways dieser Straße, vlt. meintest Du mehrere ways und nicht mehrere Straßen und damit kommt Nominatim natürlich klar, weil es weiss, dass alle Hausnummern dieser Relation zum Straßennnamen Sterndamm gehören. Ich denke es war gemeint, dass man nicht mehrere Straßen im Sinne von Straßennamen nicht in eine Relation gehören, weil man sonst nicht weiss welche Hausnummer zu welchem Straßennamen gehören. Deshalb dafür eigene Relationen erstellen, wenn es denn schon Relationen sein müssen. Denn in dieser Diskussion haben wir ja festgestellt, dass das zwar die schönere Datenart ist, aber das full-addr:-tagging nach Karlsruher Schema die praktikabelste Lösung für das nachfolgende Mappen/Änderungen an der betroffenen Straße ist. Also soweit ich die Diskussion verstanden habe, war das Argument bei veränderten Tags der Straße (oneway, cycleway, surface etc.) müsse man neue Relations für jede Änderung anlegen. Dies stimmt aber nicht, wie man am Beispiel sehen kann. Und ich kenne Adressen bisher so, dass sie sich auf eine Straße mit Straßennamen xyz beziehen und die Hausnummern nicht fortlaufen bei verändertem Straßennamen abc. Mit Ausnahme vielleicht von Venedig. Und bei Deinem Beispiel sieht man, dass noch lange nicht alles enthalten ist, was an POI's und Gebäuden schon (noch ohne Hausnummer) erfasst ist. Ja ich weiß ich muss noch ein bisschen mehr mappen, sind ja bald Semesterferien :D Ob vollständig getaggt ist, kann man aber auch sehen, wenn man die Hausnummern durch Mehrfachmarkierung in JOSM anklickt und eben mal schnell vervollständig ;-) Geht sogar leichter und schneller, als die Hausnummern in die Relation aufzunehmen, da in JOSM nur ein Klick entfernt . Ich gebe zu das Hinzufügen ist etwas mühseliger wegen der Rollenvergabe, aber die Anzahl der Klicks ist dieselbe, jedenfalls wenn man die Relationsliste offen hat. Und solange man nur die house-Rolle vergibt geht das auch recht fix. Aber dass das full-addr:-tagging nach Karlsruher Schema fürs Erfassen und vor allem spätere Editieren an den Straßen praktikabler ist, wurde ja nun schon mehrfach erwähnt und ist der eigentliche Outcome dieser Diskussion. Finde ich nicht. Wenn zum Beispiel die Straße umbenannt wird, müssten erst einmal alle zugehörigen Hausnummern gesucht werden und dann umbenannt, während bei der Relation nichts verändert werden müsste, solange die Straße einheitlich umbenannt wird. Oder falls irgendjemand die addr:city und addr:country bei bestimmten Hausnummern gelöscht hat, weil er meinte diese seien aus der Geometrie ableitbar, müsste man diese suchen und wieder reparieren. Bei Relations müsste man nur die Tags wieder hinzufügen. Die Pflege der Daten ist damit mit Relations einfacher. Deswegen nehme ich den etwas höheren Erfassungsaufwand auf mich. Grüße Tilmann ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
