Am 22.07.2010 um 10:36 schrieb Tobias Knerr: > Am 22.07.2010 02:50, schrieb steffterra: >> Wenn ich eine Software zur Suche von Parkplätzen bauen müsste, >> dann würde ich diesen, so lange so interpretierten, >> Tag auch so interpretieren, wie er mal war. Das versteht sich >> von selbst. Wenn dann jemand einen kley dranbaut, der was >> anderes sagt, ist klar, dass es vorher falsch getaggt war, >> weil es ein Parkstand war... > > Wenn du diese Software bereits gebaut hättest, müsstest du sie dann > natürlich umbauen, damit die Software beim Vorliegen eines solchen > Zusatztags das für ihre Zwecke irrelevante Objekt auch tatsächlich > ignoriert. Automatisch geht das nicht.
Warum müsste ich die Software umbauen, wenn ein tag immernoch so interpretiert werden soll, wie er ist. Ich müsste lediglich eien Bedingung einfügen: "wenn kein Zusatztag/Key" vorhanden ist -> alte Interpretation. Und wenn Key "parking_area" vorhadnen, gleiche interpretatioen -> Parkplatz mit ways. Dass ich natürlich für die Unterstützung der keys auch deren Nichtnennung mit programmieren muss, ist klar. Das ist Teil der Erweiterung auf die keys, die sagen, um welche Parkmöglichkeit es sich handelt. Doch dass ohne key das gleiche gilt, wie mit parking_area-key ist nicht die große Kunst. Selbst wenn die keys später mal etabliert wären und jemand vergisst einen anzuhängen, ist es immerhin erst mal ein Parkplatz alter Bedeutung - sofern man dann noch die alte Interpretation nicht irgendwann mal abgeschafft hat. >> Wir würden uns nicht "streiten", wenn es nicht darum ginge einen tag zu >> einem Überbegriff zu machen. Wenn amenity=parking schon ein überbegriff >> mit keys wäre, wäre es ein Kinderspiel, einfach einen neuen key >> einzuführen. > > amenity=parking ist bereits ein Überbegriff mit einem Key "parking" für > Unterkategorien: Da stehen dann solche Dinge wie surface, multi-storey > und underground drin, also die /Bauart/ der Parkmöglichkeit. Ja, aber diese bestehenden Unterkategorien "parking:underground, parking:multi_storey, etc. fügen sich nahtlos in das system der neuen keys ein: "parking:parking_area, parking:parking_space, etc.) Wo ist das Problem? > Das bitte beim Erfinden neuer Unterkategorien berücksichtigen, damit es > nicht auch noch Konflikte mit der Bauartbeschreibung gibt. Habe ich. s.o. ;-) >> Angst! Arbeit! .. oder wie? Wenn man hier zusammenhalten würde und sich >> nicht jeder als Einzelkämpfer (der für "seine Art zutaggen" kämpfen >> würde) sondern vielmehr gemeinsamen nach _guten_ Lösungen (mit freiem >> Kopf!) gesucht würde, dann könnte man das auch stark gemeinsam >> flächendeckend umsetzen. > > Wenn ich deine Lösung gut und den Aufwand wert fände, würde ich sie > gerne auch flächendeckend mit umsetzen. Ich behaupte nicht das Ei des Columbus gefunden zu haben, sondern den Kopf frei zu machen, von bisherigen OSM-Beschränkungen, aus denen man nicht herauskommt, wenn man sich bei seinen Argumenten immer wieder darauf bezieht. Und letzteres nur deshalb tut, weil man weiss, selbt wenn mal jemand eine guten Vorschlag macht, hängt man eh alleine dran es umzusetzen. > Es gibt hier aber nur endlich viel Arbeitskraft. Die kann man jetzt > entweder in immer wieder neue Umbenennungen, Modifikationen und > Ergänzungen existierender Tags stecken (mit fast keiner anderen Wirkung > als einer subjektiv "schöneren" Sortierung). Nein, es geht nicht um schön oder hässlich, sondern um praktisch zu mappen, einfach zu verstehen, Neueinsteigereinfachheit, und letzendlich leichteres Auswerten. Leider hast Du den Absatz nicht zitiert: "Eine Parkplatz/Parkstand/Stellplatz-Datenbank ist viel leichter aufzuziehen, wenn man nicht darauf achten muss, wieviele unterschiedliche Tags es fürs Parken gibt. Einfach den amenity nehmen, auslesen, welche keys dazu gemappt wurden und gut ist. Aber das wäre wohl zu fortschrittlich gedacht. Es ist einfacher, 1 bis 5 neue Tags für ähnliche Dinge einzuführen. " Eben weil sich das in der Community "leichter" durchsetzen und umsetzen lässt, als etwas, was zwar besser wäre, aber mal richtig Arbeit verursachen würde. > Oder man kümmert sich um Dinge, die bislang noch *überhaupt nicht* > vernünftig eintragbar sind. Wie eben die Linienbündel, die du ja auch > ansprichst. Oder verbessert die Software. Und so weiter. Linienbündel nach den Proposals fände ich gut, doch schwieriger umsetzbar als meinen Vorschlag mit der Gruppierung, da sie mit der aktuellen DB erreicht werden kann und "nur" um eine Datenart für die Gruppierung ergänzt werren muss. Es muss laos nichts neues erfunden werden, und man muss nicht wieder auf Relationen zurückgreifen, die wieder Einarbeitungszeit benötigen und abstrakter sind ,als das, was JOSM mit entsprechender Erweiterung dann kann. Und das wichtigste: Es wäre abwärtskompatibel. Man müsste nicht alles umtaggen, sondern _könnte_ es dort tun, wo es sinnvoll wäre. Wenn ich die Linienbündel richtig verstanden habe, treffen mehrere Punkte davon aber leider zu. > Ich bevorzuge Themen und Tätigkeiten der letzteren Kategorie und hätte > mich hier deshalb gar nicht erst zu Wort melden sollen. Na ja, mein Fehler. > > Viel Spaß noch beim Diskutieren! Nö, ist doch interessant, was Du dazu denkst. Danke für Dein Interesse! steffterra _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
