Kombination von Schlüsseln

TEL0000 · 2008-07-28T22:33:51.000Z

Stefan Rothe:

Zum Beispiel der Kirche: - Zunächst mal ist sie ein Gebäude, kann also gezeichnet und mit building=yes getagged werden. So wird es ja häufig mit auffälligen Gebäuden gemacht. - Dann ist sie zufällig auch noch ein POI, nämlich ein “place-of-worship”. Das kann dann natürlich zusätzlich eingezeichnet und als POI entsprechend getagged werden. Das ist zwar etwas inkonsistent wenn man es mal mit Parkplätzen vergleicht, die ja auch als Fläche ihr Parkplatzsymbol bekommen, letztere sind aber auch was größer und werden daher eher flächenmässig erfasst. Ein place-of-worship kann ja auch ne Winzkapelle, eine Mauer, ein Marterls an einem Pfad, etc sein, das man beim besten Willen nicht flächenmässig erfassen wollen wird. Deshalb macht es hier imho auch Sinn, die Fläche des Gebäudes vom POI (Kirche) zu trennen.

Aber warum den POI zusätzlich einzeichen? Kann nicht einfach der Mittelpunkt der Fläche für das Symbol benutzt werden? (Wie bei Parkplätzen halt auch) Die größe spielt da meiner Meinung nach keine Rolle. Wenn die Kirche so klein ist, dass man kein Gebäude einzeichnet, dann kann man ja ein POI machen. Genauso auch bei anderen Gebäuden. Viele Gebäude in Berlin haben ein extra POI, damit ein Symbol angezeigt wird. Das könnte man sich doch sparen. Außerdem wär es dann auch möglich z.B. Kirchengebäude anders zu rendern als Wohnhäuser. Daher brauchen meiner Meinung nach die Gebäude dringend auch die entsprechenden Tags.

Markus_B · 2008-07-30T10:31:31.000Z

Vorschlag: unspezifische Gebäude 1. Als **Fläche **gezeichnete unspezifische Gebäude werden mit {{Tag|building|yes}} ausgezeichnet und vom Renderer schattiert. besondere Gebäude 2. Als **Punkte **gezeichnete besondere Gebäude werden durch einen besonderen und eindeutigen Haupt-Schlüssel ausgezeichnet und bekommen vom Renderer ein besonderes Symbol. 3. Als **Fläche **gezeichnete besondere Gebäude werden durch einen besonderen und **eindeutigen Haupt-Schlüssel **ausgezeichnet und vom Renderer auffälliger schattiert und bekommen vom Renderer ein besonderes Symbol. 4. Alle Schlüssel, die explizit für Gebäude verwendet werden, werden automatisch als “building” gewertet und vom Renderer einfach oder besonders schattiert. (Kirche, Rathaus, Feuerwehr, Polizei, Krankenhaus, Gericht, Schule, Supermarkt, Museum, Hallenbad, …) Grundsatz 5. Gebäude werden entweder als Punkt **oder **als Fläche eingezeichnet. 6. Bei Flächen entscheidet der eindeutige Haupt-Schlüssel, ob die Fläche ein Gebäude (Kirche, Schulhaus, Bahnhof, Parkhaus), oder ein Bereich (Friedhof, Schulgelände, Bahnhofsgelände, Parkplatz) ist. 7. Bei gröberen Zoomstufen wird vom Renderer statt der Fläche nur das Symbol angezeigt, bei groben Zoomstufen nur noch besonders wichtige Objekte (Hauptbahnhof, Dom, Regierungssitz, …) Gruss, Markus

TEL0000 · 2008-07-30T13:05:18.000Z

So fänd ichs sinnvoll! Danke Markus!

Tordanik · 2008-07-30T13:37:17.000Z

Zustimmung insbesondere zu Punkt 5. Was noch einiger Präzisierung bedarf, ist der „eindeutige Haupt-Schlüssel“. (was ist ein „Haupt-Schlüssel“ überhaupt?) Da kann ich mir nicht wirklich etwas darunter vorstellen.

Bei Flächen entscheidet der eindeutige Haupt-Schlüssel, ob die Fläche ein Gebäude, oder ein Bereich ist.

Das heißt genau was? Derzeit würde ich z. B. (subjektiv!) ein einzelnes Universitätsgebäude mit building=yes, amenity=university taggen. Ein Universitätsgelände dagegen wäre amenity=university sowie name=bla etc., die einzelnen Gebäude dann noch building=yes. (Mit der Option, das amenity, den Namen etc. vielleicht später mal in eine Relation zu packen, die auch auf die Gebäude und die Fläche verweist.) Wie wäre deine Vorgehensweise in diesem Beispiel?

Markus_B · 2008-07-30T18:45:24.000Z

Hallo Tordanik, Bisher gibit es ja ca. ein Dutzend “Hauptschlüssel” mit so illustren Namen wie “manmade” oder “amenity”. Für mich sind das keine Schlüssel, sondern eher eine Art “Kategorien” aber selbst dann verstehe ich deren Sinn nicht wirklich. Unter eindeutiger Hauptschlüssel verstehe ich beispielsweise “Kirche”. Da weiss jeder was das ist. Und die Details (Name, Grösse, Religion, etc) werden dann in Unterschlüsseln angegeben. Dass eine Kirche ein Gebäude ist, ein öffentliches (wenn nicht ein Geheimorden dahinter steht), und sinnigerweise eine auffälligere Grundstücksfarbe bekommt als ein “normales Gebäude”, das ist irgendwie jedem klar. Weitere eindeutige Hauptschlüssel könnten sein: Schule, Krankenhaus, Bahnhof, Wald, Hafen, Flugplatz, etc. Es gäbe also viele solcher Hauptschlüssel. Und keiner bräuchte mehr überlegen, ob jetzt der Wald “manmade” oder “natur” oder “amenity” ist. Und wenn man wissen will, wie man **Wald **auszeichnet, dann sucht man nach “Wald” und findet alles was man in OSM damit machen kann. Und möglichst wenig hierarchisch-kategoriale Systeme. Also nicht “Bildungseinrichtung” und darunter Schule, Uni, Kiga - sondern einfach Schule, Uni und Kindergarten. Und wenn das Krankenhaus einen Heli-Landeplatz hat, dann heisst das nicht “Flugplatz ganz klein”, sondern einfach “Helikopterlandeplatz”. Ich finde, “Übliches” sollten die Renderer von selbst richtig darstellen (dass die Uni auf der Wiese steht und nicht umgekehrt), Layer braucht man nur für seltene Spezialfälle und nur in spezifischer Situation (wenn die Uni in einem Bunker ist und dieser unter der Wiese). Und auch “Relationen” finde ich eher kompliziert. Der Renderer soll beim Unigelände schauen, wieviele Gebäude es gibt, und den Uni-Namen nur einmal ausgeben, aber vielleicht die Mensa anschreiben und den Haupteingang. Mit “amenity” hat das alles sowieso nichts zu tun, höchstens wenn der Mensakoch wirklich gut kocht (aber auch da wäre {{Tag|Kochmützen|5}} geeigneter). Und dass ein Gebäude kein See ist und umgekehrt, ist doch auch klar, selbst wenn das Gebäude ein Grasdach hat oder das Dach undicht ist.

Wie wäre deine Vorgehensweise in diesem Beispiel?

Die ganzen Schlüssel mal zentral zusammenfassen, vereinfachen, vereinheitlichen, klare Regeln definieren. alles in eine Datenbank packen. Dann allen erzählen, dass es jetzt eine zentrale Anlaufstelle gibt und man dort mit einfachen Stichwörtern alles findet was man braucht. Und später dann einen Bot lossschicken, wenigstens den gröbsten Wildwuchs zu korrigieren. - Also nicht Einzelfalllösungen, sondern bessere Struktur, Organisation, Information. Und jedes neue Objekt wird wieder mit einem sprechenden Namen als weiterer Hauptschlüssel aufgenommen. Gruss, Markus

Hobby_Navigator · 2008-07-30T18:56:54.000Z

Also in dem Punkt, dass es viele “unlogische” key´s gibt, gebe ich dir recht. Jedoch sollte man überlegen das vieles aus der englischen Übersetzung stammt und deshalb nicht immer eins zu eins auf die deutsche Sprache passt. OSM wurde nun mal nicht in Deutschland erfunden. Aus diesem Grund wird es wohl auch bei den englischen key´s und values bleiben. OSM ist international und welche Sprache als die englische eignet sich da besser? Die Schlüssel für jedes Land zu übersetzen wäre wohl des guten zuviel, wer soll das noch bearbeiten? Auch die Admin´s machen das ganze in ihrer Freizeit!! Und es gibt noch eine weitere Überlegung, stell dir mal die ganzen “Hauptschlüssel” vor die entstehen wenn man alle “Unterkategorien” weg lassen würde. Wer soll das noch überblicken? Wie gesagt das einiges neu, anders oder besser “einsortiert” werden könnte, ok. Aber alles andere halte ich für illusorisch. Georg

krza · 2008-07-30T21:36:38.000Z

Wenn man mal in die Mailingliste schaut, wird man die Ansicht finden, dass es irgendwann zu lokalen Schlüsseln kommen wird, also in lokaler Sprache. Das hat dann aber wenig damit zu tun, dass bestimmte Leute kein Englisch können. Das ist für mich sowieso kein Grund. Erstens gehört das heute zur Allgemeinbildung, und zweitens muss man noch nicht einmal Englisch können, sondern nur ein paar Begriffe, die nun zufällig auf Englisch sind. Insofern könnte es meinetwegen auch auf arabisch sein, auch wenn´s anfangs anstrengend wäre. Nein, der Grund ist vielmehr, dass es bestimmte landestypische Dinge gibt, die entweder schlecht übersetzbar sind oder/und eine andere Bedeutung haben im Sinne der Gewichtung. Ich denke, dass man zumindest in der westlichen Welt beim Englisch bleiben sollte. Da bricht sich keiner einen ab, und die paar lokalen Spezialitäten werden dann halt hinzugefügt. Ist ja auch kein Problem, weil man ja normalerweise nur im eigenen Land taggt und andersrum niemand darüber stolpern dürfte (z.B. ein Japaner, der von Tokio aus einen See in Mecklenburg bearbeiten will). Wichtig ist an der Stelle, dass das lokale Rendering funktioniert, sprich, dass man deutsche, englische, chinesische, … Karten erstellen kann. Übrigens kann man mal einen Blick auf Japan werfen oder Indien. Da sind die Namen häufig in Landessprache und auf Englisch gerendert. Ob die dafür so ein lokales Template verwenden, weiß ich nicht, denn die Objekte, die ich hier in Deutschland mehrsprachig getaggt habe, erscheinen trotzdem nur auf Deutsch - zum Glück

TEL0000 · 2008-07-30T22:37:04.000Z

krza:

Übrigens kann man mal einen Blick auf Japan werfen oder Indien. Da sind die Namen häufig in Landessprache und auf Englisch gerendert. Ob die dafür so ein lokales Template verwenden, weiß ich nicht, denn die Objekte, die ich hier in Deutschland mehrsprachig getaggt habe, erscheinen trotzdem nur auf Deutsch - zum Glück

Gerendert wird halt der “name”-Tag. Der sollte immer in Landessprache sein. Andere (z.B. “name:de”, “name:en” oder “name:ru”) werden halt nicht gerendert. (Zumindest nicht von Osmarender oder Mapnik). Irgendwo hab ich auch schonmal “int_name” gesehen, für internationale Namen. Und “nat_name” für nationale Namen. Ich seh grad, das war Armenien. Dort wird transkribiert. Im “name”-Tag stehen dort beide Varianten, darum wird auch beides gerendert.

Markus_B · 2008-07-30T22:40:16.000Z

Wir sprechen grad von drei Ebenen: a) die Systematik der Objekte, ihrer Schlüssel und Eigenschaften b) ggf. landesspezifische Einführung besonderer Objekte und/oder besonderer Schlüssel c) die Verwendung von Englisch als Grund-Sprache und deren Übersetzung Ich sprach ausschliesslich von a) b) halte ich für problematisch. Wenn man grenzüberschreitende Karten will, müssen die Objektbeschreibungen konsistent sein. Auch wenn es in D keinen Urwald gibt, und im Urwald keine deutsche Autobahn. c) halte ich für selbstverständlich. Sowohl eine einheitliche Basissprache, als auch die Übersetzung der Schlüsselbegriffe. a) und c) lassen sich in einer Datenbank übersichtlich und einfach pflegen. Der von mir propagierte “eindeutige Schlüssel” ist bestimmt durch die Eigenschaften. Bei der “Autobahn” werden sie grad auf der Mailingliste diskutiert. Angenommen es kommt raus: kreuzungsfrei + fahrbahngetrennt + mehrspurig, dann ist alles was diese Eigenschaften aufweist eine “Autobahn” egal ob hier oder im Urwald. Und der Begriff “Autobahn” kann dann beliebig in alle Sprachen übersetzt werden, Hauptsache die Eigenschaften sind immer die gleichen. Gruss, Markus

Tordanik · 2008-07-31T10:58:05.000Z

Markus B:

Der von mir propagierte “eindeutige Schlüssel” ist bestimmt durch die Eigenschaften.

Um Begriffsverwirrungen zu vermeiden: Die derzeitige Terminologie von OSM ist ja: [1] Schlüssel/Key ist der erste Teil des Tags (amenity in amenity=toilets). Wert/Value ist der zweite Teil des Tags (toilets in amenity=toilets). Tag ist ein Paar aus Schlüssel und Wert (amenity=toilets). Verwendest du „Schlüssel“ in diesem Sinn? Wenn nein, bitte ich um Klarstellung.

Und der Begriff “Autobahn” kann dann beliebig in alle Sprachen übersetzt werden, Hauptsache die Eigenschaften sind immer die gleichen.

Und noch hierzu: Wenn wir schon landessprachlich taggen, wäre es dann nicht sinnvoller, die Begriffe in ihrer Bedeutung an die örtlichen Gegebenheiten anzupassen? Für Straßen also etwa einige Eigenschaften definieren, die für Renderer, Router und sonstige Software interessant sind (maxspeed, minspeed, Designation, so ziemlich alles unter access [2] …). Dann landesspezifische Straßentypen definieren, deren Set von Eigenschaften in idealerweise maschinen- und menschenlesbarer Form verfügbar ist, so dass wir hier etwas als „verkehrsberuhigter Bereich“ oder „Autobahn“ taggen können, und ein Programmierer/Renderregeldesigner/… trotzdem nur auf internationale Straßeneigenschaften zurückgreifen müsste. Wenn er etwa Fahrradrouting macht, findet die Software für de:Autobahn die Information bicycle=no. [1] http://wiki.openstreetmap.org/index.php/Data_Primitives [2] http://wiki.openstreetmap.org/index.php/Key:access

Markus_B · 2008-07-31T14:05:35.000Z

Hallo Frank, ja, das mit der Sprache hier ist nicht immer so eindeutige (sorry wenn ich manchmal auch nachlässig bin - ich bemühe mich um klare Ausdrucksweise). Objekt = Kurzform für “Objektklasse”, siehe “data primitives” Schlüssel = erster Teil des Eigenschaften-Paares “Schlüssel=Wert” auch Kurzform für “Eigenschaften-Paar” - präziser dafür wäre der Begriff “Eigenschaft” Haupt-Schlüssel = erster Teil des hierarchisch höchsten *sinnvollen *Eigenschaften-Paares “Schlüssel=Wert” einer Objektklasse. Beispiel: Autobahn, Wald, See (wie auch immer das dann in Englisch heisst) Baggersee ist zwar ein See, kann aber einfacher direkt beschrieben werden. Damit erspart man sich die Inkonsistenz von hierarchischen Systematisierungsversuchen.

der Begriff “Autobahn” kann dann beliebig in alle Sprachen übersetzt werden, Hauptsache die Eigenschaften sind immer die gleichen.

Genau.

wäre es nicht sinnvoller, die Begriffe in ihrer Bedeutung an die örtlichen Gegebenheiten anzupassen?

genau. Und wie Du sagst: es kommt auf die Eigenschaften an. Und bei definierten Objektklassen brauchen bestimmte Eigenschaften nicht immer händisch hinzugefügt werden: Autobahn:bicycle=no (Ausnahme: Autofreier Sonntag). Mit einem definieren Set von Eigenschaften kann der Programmierer dann gut arbeiten, beispielsweise Routing-Regeln aufstellen. Gruss, Markus

TEL0000 · 2008-07-31T15:59:44.000Z

@ Markus: Ich hab jetzt noch nicht ganz verstanden, wie du es haben willst. Mein Vorschlag dazu wäre, den Hauptschlüssel unabhängig von den anderen Schlüsseln zu machen, ohne die Kategorien (wie amenity, highway oder man_made), und dann die Eigenschaften

Markus_B · 2008-07-31T18:14:27.000Z

TEL0000:

Hauptschlüssel unabhängig von den anderen Schlüsseln: - River - name=Oder - width=50 - boat=yes

Ja, so meine ich das. “Hauptschlüssel” ist datebanktechnisch eine Objektkategorie. Einzelne Objekte bekommen dann in dieser Kategorie einen Schlüssel und ein Set von Eigenschaften. Gruss, Markus

Hobby_Navigator · 2008-07-31T18:51:53.000Z

Einspruch euer Ehren eine Autobahn mit den bespielhaft genannten Eigenschaften

kreuzungsfrei + fahrbahngetrennt + mehrspurig, dann ist alles was diese Eigenschaften aufweist eine “Autobahn” egal ob hier oder im Urwald. …Hauptsache die Eigenschaften sind immer die gleichen.

ist eben nicht überall eine Autobahn, bzw. die Eigenschaften einer Autobahn unterscheiden sich doch sehr. Selbst in Europa ist nicht immer eine bauliche Trennung gegeben. Sogar in den USA dem Land der Highways gibt es teilweise auf diesen die Möglichkeit zu wenden und die andere Richtung zu befahren.

Autobahn:bicycle=no

Ich habe schon Eselsfuhrwerke auf der “Autobahn” gesehen. Nein nicht in Deutschland. Obwohl…

Auch wenn es in D keinen Urwald gibt

Wer sagt das denn? Schau mal nach unter Nationalpark Kellerwald, Bayerischer Wald, Urwald Sababurg u.u. Ja, diese Bereiche sehen etwas anders aus als der tropische Regenwald, aber sie sind für unsere Verhältnisse durchaus als Urwald zu bezeichnen, werden auch bewußt so bezeichnet und irgendwann in ein paar Jahrzehnten sehen sie auch wieder so aus wie vor tausenden von Jahren. Also, so ganz einfach kann man sich das “über einen Kamm scheren” dann doch nicht machen. Lieber sollte man versuchen etwa falsch einsortierte values richtig unterzubringen. Was spricht denn gegen die Verwendung der z.B. von TEL0000 genannten “Anhäufung” von Tags? Nur weil die Renderer derzeit noch nicht damit umgehen können? Ja, jetzt kommts wieder, … wir zeichnen nicht… Georg

Markus_B · 2008-07-31T21:22:22.000Z

Hallo Georg,

Hobby Navigator:

Was spricht denn gegen die Verwendung der “Anhäufung” von Tags?

Nichts - solange alles im Haufen Sinn macht, und solange alles was Sinn macht im Haufen ist. Und was “Sinn” macht - das muss m.E. erst gesucht und gefunden und dann durch Regeln beschrieben werden. Und diese Regeln müssen dann irgendwo zentral so gespeichert werden, dass sie von jedem der sucht schnell, verständlich und erschöpfend gefunden werden. Gruss, Markus PS: meine “Beispiele” waren nur “zur Anschauung” gedacht. Es liessen sich sicher stringentere finden.

Tordanik · 2008-07-31T21:46:35.000Z

Hobby Navigator:

Was spricht denn gegen die Verwendung der z.B. von TEL0000 genannten “Anhäufung” von Tags?

Nun: 1. Dass das nicht ins derzeitige Dateiformat passt und deshalb nur durch Developer, nicht durch Mapper angepasst werden kann. Man betrachte einen Ausschnitt aus einer .osm:

  <way id='10048964' timestamp='2008-04-02T10:49:40+01:00' user='Tordanik' visible='true'>     <nd ref='38450176' />     <nd ref='38450179' />     <tag k='created_by' v='JOSM' />     <tag k='noexit' v='yes' />     <tag k='highway' v='residential' />     <tag k='name' v='Rotkreuzstraße' />     <tag k='maxspeed' v='30' />   </way>

Wie leicht zu erkennen ist, enthält das jeweils sowohl einen '‘k’'ey als auch einen '‘v’'alue. Man könnte natürlich irgendetwas wie k=object_type v=River nehmen, um TEL0000s Vorschlag zu simulieren. k=River v=yes ginge auch. Damit würde aber immer noch die Möglichkeit des Zuordnens mehrerer „Hauptschlüssel“ zu einem Node/Way fehlen. (Mit Relationen bekäme man das schon heute hin, aber die finden ja sicher wieder alle zu kompliziert.) 2. Es ist anders als die „althergebrachte“ Methode, und es gibt in solchen Belangen immer eine gewisse Trägheit – vor allem (verständlicherweise), wenn keiner der Vorschlagenden sich bereit erklärt, auch die nötige Programmierarbeit zu erledigen. Ich denke, es wäre nicht sinnvoll, das separatistisch anders zu machen, da muss man schon etwas Überzeugungsarbeit leisten. Erst mal auf talk-de und dann international … das Forum hier hat kaum die nötige Reichweite. Prinzipielle Einwände sähe ich momentan nicht dagegen, zumindest die für meine Begriffe kaum aussagekräftigen amenity, natural, man-made, leisure etc. abzuschaffen und die Hierarchie damit abzuflachen.

Markus_B · 2008-07-31T22:28:09.000Z

Wie wär’s mit: id=‘10048964’ timestamp=‘2008-04-02T10:49:40+01:00’ user=‘Tordanik’ visible=‘true’ ref=‘38450176’ ref=‘38450179’ created_by=‘JOSM’ noexi=‘yes’ highway=‘residential’ name=‘Rotkreuzstraße’ maxspeed=‘30’ Gruss, Markus

Tordanik · 2008-08-01T07:54:31.000Z

Wie wär’s mit:

<Sackgasse>   id='10048964'   timestamp='2008-04-02T10:49:40+01:00'   user='Tordanik'   […]

Das ist kein gültiges XML, und die Unterscheidung zwischen Nodes, Ways etc. sollte auch im Datenformat bleiben (das verwendet schließlich in Editoren etc. jeweils den selben Code). Aber um die Details im Format geht es mir gar nicht. Wollte nur ausdrücken: Für eine Umsetzung des Vorschlags bräuchte man eine Formatänderung. Die ist möglich – sagen wir, so:

  <way id='10048964' timestamp='2008-04-02T10:49:40+01:00' user='Tordanik' visible='true'>     <nd ref='38450176' />     <nd ref='38450179' />     <tagset t='Sackgasse'>        <tag k='created_by' v='JOSM' />        <tag k='highway' v='residential' />        <tag k='name' v='Rotkreuzstraße' />        <tag k='maxspeed' v='30' />     </tagset>   </way>

Sie ist halt lediglich ein praktisches, wenn auch nicht prinzipielles Hindernis.

Markus_B · 2009-02-11T13:18:38.000Z

Tordanik:

Wie wär’s mit:

  <way id='10048964' timestamp='2008-04-02T10:49:40+01:00' user='Tordanik' visible='true'>     <nd ref='38450176' />     <nd ref='38450179' />     <tagset t='Sackgasse'>        <tag k='created_by' v='JOSM' />        <tag k='highway' v='residential' />        <tag k='name' v='Rotkreuzstraße' />        <tag k='maxspeed' v='30' />     </tagset>   </way>

Ich versuche grad XML zu verstehen. Wäre das auch XML:

  <way id='10048964' timestamp='2008-04-02T10:49:40+01:00' user='Tordanik' visible='true'>     <nd ref='38450176' />     <nd ref='38450179' />     <tagset> Sackgasse </tagset>        <created_by> JOSM </created_by>        <highway> residential </highway>        <name> Rotkreuzstraße </name>        <maxspeed> 30 </maxspeed>     </tagset>   </way>

Gruss, Markus

zottel · 2009-02-11T14:18:14.000Z

Markus B:

Ich versuche grad XML zu verstehen. Wäre das auch XML:

  <way id='10048964' timestamp='2008-04-02T10:49:40+01:00' user='Tordanik' visible='true'>     <nd ref='38450176' />     <nd ref='38450179' />     <tagset> Sackgasse </tagset>        <created_by> JOSM </created_by>        <highway> residential </highway>        <name> Rotkreuzstraße </name>        <maxspeed> 30 </maxspeed>     </tagset>   </way>

Ja, aber kein gültiges XML-nodes müssen immer geöffnet und in gleicher Verschachtelungstiefe wieder geschlossen werden. Für nodes die die keine anderen nodes einschließen, wie die nd’s kann man den node in der gleichen Zeile durch das “/” am Ende direkt wieder schließen. Ansonsten hast du jeweils ein das durch eine wieder geschlossen wird. Folglich ist an dem Beispiel falsch, das das tagset zwei Mal geschlossen wird. Grüßle, detlef