Einheitliches Tagging für POIs & App zur Kontrolle

monotar · 2012-04-26 15:19:02

moenk wrote:

natürlich bekommt die Fläche die Tags. Und meinetwegen noch ein POI der die Tags hat gleich dazu. Machen wir bei Städten doch auch so. Soll der Renderer doch damit klarkommen, das ist doch nicht unser Problem.

Das kann man einfach nicht unkommentiert stehen lassen. Auch keine Lust das nun auszudiskutieren, das mit den Städten und boundarys ist eine vollkommen andere Sache und in dem Sinne eine Ausnahme. In OSM hat man noch nie Flächen und Nodes gleichzeitig eingestellt, das war schon immer verpöhnt und es ist auch in der Auswertung kein laxes "sollen die sich doch selber einen Kopf machen". Wir machen kein Anti-Mapping für die Renderer genauso wie wir kein Anti-Mapping für die Router machen sollten (siehe Spur-Blödsinn).

misterboo wrote:

Ich sehe, das wird wieder mal eine Diskussion ohne echten Konsens ... soll dann wohl so sein bei OSM. Jeder macht was er will. Wegen mir dann auch so

Das ist ein grundsätzliches Problem von OSM, ich bin da aber voll auf der Seite von Radeln alles enger zu fassen. Vielleicht wird die Comm diesen Weg gehen, vielleicht auch nicht, sie bräuchte auf jeden Fall ein neues Regelset und einen neuen Aufbau, allerdings zweifel ich daran wenn ich die endlosen Diskussionen sehe.
Aber: Linux hat sich auch nie durchgesetzt oder nur in bestimmten Bereichen, warum solls mit OSM anders sein.

misterboo · 2012-04-26 15:55:58

Hier ist übrigens ein Beispiel einer site relation, mit der sicher Mapper und Auswerter gut leben könnten

http://www.openstreetmap.org/browse/relation/1966465

Die Relation hat ein label node, an dem alle wichtigen tags dran sind.

Ich kann also problemlos die Schule finden, ohne die Relation auszuwerten. Viele site relationen haben die tags allerdings direkt an der Relation, an die kommt man dann nicht ohne aufwändige Relationen Auswertung.

Last edited by misterboo (2012-04-26 15:57:50)

aighes · 2012-04-26 16:22:12

Wobei der Aufwand nun bei site-Relationen auch nicht höher ist als bei Flächen.

Vorgehensweise in etwa so:

Suche alle Ways mit amenity=school und merke sich min. einen Node mit den Taggs des Weges.
Suche alle site-Relationen mit amenity=school und merke sich den Node mit der Rolle label und die Taggs der Relation.

Beides geht in einem Durchlauf.

Weiter geht es mit dem Parsen der Nodes. Suche alle gemerkten und alle mit amenity=school.

misterboo · 2012-04-26 16:26:26

aighes wrote:

Wobei der Aufwand nun bei site-Relationen auch nicht höher ist als bei Flächen.
Vorgehensweise in etwa so:
Suche alle Ways mit amenity=school und merke sich min. einen Node mit den Taggs des Weges.
Suche alle site-Relationen mit amenity=school und merke sich den Node mit der Rolle label und die Taggs der Relation.
Beides geht in einem Durchlauf.
Weiter geht es mit dem Parsen der Nodes. Suche alle gemerkten und alle mit amenity=school.

Das meinte ich ja auch .. aber ich muss nicht die Relationen komplett auswerten.

Ohne Label Node, also wenn die Tags nur an der site relation sind, brauche ich ja noch einen Durchlauf für die ways und dann noch mal einen für die nodes, um an die Koordinaten der relation zu kommen. Wichtig wäre eben dass es in der relation einen node als Mitglied gibt, der alle tags des POIs besitzt. Und viele site relations haben eben keinen node mit den Infos.

Last edited by misterboo (2012-04-26 16:29:03)

aighes · 2012-04-26 16:30:39

Obiges funktioniert nur, wenn die Taggs alle an der Relation sind und der Node mit der role label leer ist.
Wenn das label komplett getaggt ist und auch noch das Gelände ein amenity=school hat musst du die Relation parsen, alle Wege merken, dann bei den Wegen schauen, ob einer mit amenity=school dabei ist und diesen dann auslassen. Ist aufwendiger, als mein Weg oben, weil du dreimal parsen musst.

In deinem Beispiel muss man einmal die Relationen parsen und sich Wege und label-Node merken, dann alle Wege und nach amenity=school filtern, wenn Weg-ID gemerkt wurde diese ignorieren und vom Rest min. einen Node merken. Dann alle Nodes parsen und nach amenity=school filtern und die gemerkten Node-IDs noch hinzu.

Macht 3mal parsen. Obiges kommt auf 2mal parsen.

Last edited by aighes (2012-04-26 16:36:34)

quasilotte · 2012-04-26 16:41:58

Ich dachte wir mappen weder für die Renderer noch für die Auswerter!

Ich werde jedenfalls jede Information nur einmal in OSM eintragen.
Und wenn die "Schule" durch eine Relation definiert ist kommt amenity=school in die Relation.
Mit was die Relation verknüpft ist ist mir da schon wurscht da die Renderer das ja hiarisch abarbeiten.
Wenn der "Name" nicht in die Mitte der "Fläche" soll muß das Programm halt nach entrance suchen (wie mkgmap das schon macht)

Ich sehe bei den Renderern nicht das Problem der Auswertung, auch geht es recht flott.

Und hier wird ja verhemend gegen jedwede Reglementierung gearbeitet damit sind irgendwelche Einheitliche taggins schon gegessen!

Gruß
aus den schönen OSM-Daten-Wirrwar

misterboo · 2012-04-26 16:47:54

aighes wrote:

Obiges funktioniert nur, wenn die Taggs alle an der Relation sind und der Node mit der role label leer ist.
Wenn das label komplett getaggt ist und auch noch das Gelände ein amenity=school hat musst du die Relation parsen, alle Wege merken, dann bei den Wegen schauen, ob einer mit amenity=school dabei ist und diesen dann auslassen. Ist aufwendiger, als mein Weg oben, weil du dreimal parsen musst.

Also verstehe ich das richtig: du bevorzugst die Tags an der Relation ?

Und nicht wie hier im Beispiel, wo alle Tags am label node sind ?

http://www.openstreetmap.org/browse/relation/1966465

Damit hätten wir dann auch schon wieder unterschiedliche Ansichten und da es eben kein Konsens gibt, müssen eh wieder beide Arten beachtet werden.

Meine Idee war ja, dass man durch den Label node die relation überhaupt nicht beachten muss, wenn man nicht will

aighes · 2012-04-26 16:54:33

Mit dieser Idee liegst du aber falsch. Denn woher weißt du dass du den Weg mit der role perimeter beim Parsen der Ways nicht beachten darfst? Genau dadurch, dass du vorher in der Relation geschaut hast, dass perimeter und label zu einem Objekt gehören und somit nicht doppelt angezeigt werden sollten.

Ebenfalls wollte ich dir den Hinweis geben, dass das zusätzliche Parsen der site-Relation nicht aufwändiger ist, als würde man nur nach Nodes und Ways parsen, WENN die Taggs nur an der Relation sind.

misterboo · 2012-04-26 16:57:51

quasilotte wrote:

Ich dachte wir mappen weder für die Renderer noch für die Auswerter!
Ich werde jedenfalls jede Information nur einmal in OSM eintragen.
Und wenn die "Schule" durch eine Relation definiert ist kommt amenity=school in die Relation.
Mit was die Relation verknüpft ist ist mir da schon wurscht da die Renderer das ja hiarisch abarbeiten.
Wenn der "Name" nicht in die Mitte der "Fläche" soll muß das Programm halt nach entrance suchen (wie mkgmap das schon macht)
Ich sehe bei den Renderern nicht das Problem der Auswertung, auch geht es recht flott.
Und hier wird ja verhemend gegen jedwede Reglementierung gearbeitet damit sind irgendwelche Einheitliche taggins schon gegessen!
Gruß
aus den schönen OSM-Daten-Wirrwar

Für was oder wen mapped ihr denn ? Aus Zeitvertrieb ? Ich dachte wir mappen, dass wir selbst oder andere mit den Daten auch etwas anfangen können. Da muss es doch logischerweise einen Dialog geben, und so ein Dialog manifestiert sich doch auch normalerweise dann in festen Regeln. Regeln in denen der Auswerter nachsehen kann wie er den Algorithmus für seine Auswertung schreibt und gleichzeitig Regeln für den Mapper, damit er weiß, wie er am sinnvollsten sachen Mapped, mit denen der Auswerter oder er selbst was anfangen kann.

Wenn es da keinen Dialog gibt, und ehrlich gesagt sehe ich diesen Dialog nirgends, dann ist die Chance groß, dass weder Mapper noch Auswerter so richtig gücklich werden.

misterboo · 2012-04-26 17:05:00

aighes wrote:

Mit dieser Idee liegst du aber falsch. Denn woher weißt du dass du den Weg mit der role perimeter beim Parsen der Ways nicht beachten darfst? Genau dadurch, dass du vorher in der Relation geschaut hast, dass perimeter und label zu einem Objekt gehören und somit nicht doppelt angezeigt werden sollten.
Ebenfalls wollte ich dir den Hinweis geben, dass das zusätzliche Parsen der site-Relation nicht aufwändiger ist, als würde man nur nach Nodes und Ways parsen, WENN die Taggs nur an der Relation sind.

Ich bin da flexibel ... wichtig ist mir eine einheitliche Regel. Was nützt es mir denn als Auswerter wenn deine Idee die bessere ist, und trotzdem die meisten eben die tags an den label node schreiben.

Also das eigentliche ist: im Grunde ist es mir egal wie was gemacht wird, nur sollte es einheitliche Regeln geben.

site relationen mit den tags in der relation
site relationen mit den tags im label node
multipolygon relationen (müssen eh immer 3 mal geparst werden um an die Geometry zu kommen)
collection relationen

egal was du vorschlägst und egal ob das auch evt. leichter zu parsen ist, es nützt eh nichts da es nicht einheitlich ist und ich am Ende doch alle erdenklichen Taggings parsen muss.

Also nochmal: Fangen wir doch einfach mal an, ein einheitliches Tagging im wiki festzuschreiben. Zumindest bei den doch eigentlich trivialen Sachen wie den POIs.

Und im Wiki steht momentan eben nur : entweder Node oder Fläche mappen. Genau diese Info hat auch der Auswerter. Da aber die Realität von dieser Info erheblich abweicht und es dort alle möglichen denkbaren und undenkbaren Kombinationen von nodes, ways und relationen gibt, die aber nicht mal im wiki erwähnt sind, muss der Auswerter für jede Kleinigkeit erst mal eine hochkomplizierte Analyse machen welche Taggings es gibt und wie er diese alle in seiner Auswertung unter einen Hut bekommt.

Last edited by misterboo (2012-04-26 17:17:00)

hurdygurdyman · 2012-04-26 18:15:36

misterboo wrote:

...
Ich sehe, das wird wieder mal eine Diskussion ohne echten Konsens ... soll dann wohl so sein bei OSM. Jeder macht was er will. Wegen mir dann auch so

Und wieder eine Diskussion um Kaisers Bart...
...wie immer ohne Konsens.
Meine (für mich) logische Lösung. Ein POI- oder was auch immer -tag kommt an das größtmögliche zusammenhängende Gebilde, für das diese Eigenschaft flächenmäßig oder räumlich zutrifft.
Am Beispiel einer Schule heißt das: amenity=school kommt an den Flächenumriss der auch den Schulhof, Lehrerparkplatz usw. beinhaltet. Darin liegende Schulgebäude bekommen building=school, das Wohnhaus des Hausmeisters bekommt building=house usw.

badger123 · 2012-04-26 19:17:37

Und was wird gemacht wenn die Fläche durch eine Strasse geteilt wird? Kommt das amenity=school nur an die größer Flache oder macht man dann aus der Fläche ein Relation vom Typ Multipolygon das wäre zumindest konsequent.

Blos was machen Mappe die eigentlich keine Flachen eintragen sonder nur die Häuser von Bing abzeichnen?
Die müssten dann zumindest eine Relation erstellen in der alle Schulgebäude eingetragen sind damit amenity=school nicht zu häufig vorkommt.

Es kann halt nur so funktionieren dass der Auswerter alles Mögliche von Node über Weg zu Relation berücksichtigen muss.

Last edited by badger123 (2012-04-26 19:18:15)

misterboo · 2012-04-26 19:27:09

badger123 wrote:

Und was wird gemacht wenn die Fläche durch eine Strasse geteilt wird? Kommt das amenity=school nur an die größer Flache oder macht man dann aus der Fläche ein Relation vom Typ Multipolygon das wäre zumindest konsequent.
Blos was machen Mappe die eigentlich keine Flachen eintragen sonder nur die Häuser von Bing abzeichnen?
Die müssten dann zumindest eine Relation erstellen in der alle Schulgebäude eingetragen sind damit amenity=school nicht zu häufig vorkommt.
Es kann halt nur so funktionieren dass der Auswerter alles Mögliche von Node über Weg zu Relation berücksichtigen muss.

Wie schon geschrieben hätte ich weder als Mapper noch Auswerter etwas gegen eine Site Relation mit einem Label Node mit allen relevanten tags wie hier in dem Beispiel:

http://www.openstreetmap.org/browse/relation/1966465

badger123 · 2012-04-26 20:09:08

Meine Interpretation vom Proposal ist aber anders.
Hier sollten alle Informationen in die Relation und der Label Node ist nur um zu definieren wo der Name bzw. das Symbol gerändert werden soll.
Tags doppelt zu erfassen (in deinem Beispiel Name und Amenity) halte ich für verkehrt. Wie soll ein Runderer bei unterschiedlicher Bedatung wissen was verwendet werden soll?

Es ist aber im Endeffekt genauso wie mit den Highways. Jedem ist was anderes wichtig deswegen wird ein Highway nicht von Anfang an mit allen Informationen angelegt sonder sie kommen nach und nach mit durch andere Mapper hinzu.

Bei POIs ist es genauso. Die Information zu dem POI wird immer genauer.
Am Anfang ist es meist nur ein Node. Dann macht einer ein Fläche und später werden Einzelheiten erfasst die dann erst in einer Relation zusammengeführt werden müssen.

misterboo · 2012-04-26 20:22:25

badger123 wrote:

Meine Interpretation vom Proposal ist aber anders.
Hier sollten alle Informationen in die Relation und der Label Node ist nur um zu definieren wo der Name bzw. das Symbol gerändert werden soll.
Tags doppelt zu erfassen (in deinem Beispiel Name und Amenity) halte ich für verkehrt. Wie soll ein Runderer bei unterschiedlicher Bedatung wissen was verwendet werden soll?
Es ist aber im Endeffekt genauso wie mit den Highways. Jedem ist was anderes wichtig deswegen wird ein Highway nicht von Anfang an mit allen Informationen angelegt sonder sie kommen nach und nach mit durch andere Mapper hinzu.
Bei POIs ist es genauso. Die Information zu dem POI wird immer genauer.
Am Anfang ist es meist nur ein Node. Dann macht einer ein Fläche und später werden Einzelheiten erfasst die dann erst in einer Relation zusammengeführt werden müssen.

Nochmal: das war nur ein Vorschlag. Im Grunde ist es mir egal. Es gibt Mapper die haben viel mehr Erfahrung als ich. Es war nur ein Vorschlag. Der Kernpunkt ist ein einheitliches, dokumentiertes Tagging, an das sich Mapper und Auswerter halten können.

Solange es diese Einheit aber nicht gibt ist jeder Vorschlag eigentlich genauso gut oder schlecht, denn ich muss als Auswerter doch eh alle unterschiedlichen Taggings berücksichtigen.

Wenn denn eine Relation gebraucht wird bei den POIs, und das Tagging der Infos an der Relation als besser erachtet wird, dann ist das auch OK. Nur sollten wir das dann auch dokumentieren. Und zwar so genau wie möglich. Andernfalls können wir ewig weiter diskutieren und es wird nicht besser. Momentan sehe ich halt recht viel wildes Tagging bei den POIs.

Bisher ist die site ja nicht mal offizielles Tagging sondern nur ein inaktives Proposal

http://wiki.openstreetmap.org/wiki/Rela … posed/Site

Last edited by misterboo (2012-04-26 20:24:36)

moenk · 2012-04-26 22:26:03

Monotar,

monotar wrote:

In OSM hat man noch nie Flächen und Nodes gleichzeitig eingestellt, das war schon immer verpöhnt und es ist auch in der Auswertung kein laxes "sollen die sich doch selber einen Kopf machen".

Auf solche Argumente steh ich ja - das haben wir noch nie so gemacht, das machen wir auch künftig nicht. Ich werd auch nicht damit anfangen, ich mappe auch weiter so, wie ich erkenne das andere das auch machen. Nicht aus einem Mangel aus Induvidualität, sondern einfach um bei den Fluss in diesem schönen Projekt nicht zu stören sondern die Entwicklung voranzubringen.

Fakt ist aber, bei OSM ist die Qualität der Geodaten nach normalen Kriterien ziemlicher Schrott, ohne das hier weiter auszuführen. Sowohl Punkte als auch die "Polygone" sollten vollständig sein. Wir kommen natürlich auch mit solchen "mal so, mal so" Layern klar, und überhaupt ist die OSM trotz der mangelnden Qualität von unbestreitbar hohem praktischen Nutzen.

So eingefahren wie die Entwicklung ist wird ist es auch schwer da noch irgendwas dran zu drehen, allein ein kleiner Lizenzwechsel macht schon einen riesigen Bohei, da sollte lieber alles so weiter laufen, auch wenn das nicht optimal ist. Letztlich gibts da ja auch verschiedene Vorstellungen, was zu verbessern wäre.

LG,

-moenk

Tordanik · 2012-04-27 02:51:49

misterboo wrote:

Hier ist übrigens ein Beispiel einer site relation, mit der sicher Mapper und Auswerter gut leben könnten
http://www.openstreetmap.org/browse/relation/1966465

Nein, das ist ein eindeutiges Negativbeispiel. Selbst wenn man die Relation ignoriert, gibt's da nämlich zwei Schulen - eine als Node und eine ohne weitere Tags als Fläche. Dass das nicht gemacht werden soll, ist doch eigentlich klar?

Man muss also für Kritik an deinem Beispiel nicht mal die Relation heranziehen (wo die Situation wirklich noch nicht ausdiskutiert ist).

hurdygurdyman · 2012-04-27 07:08:26

badger123 wrote:

Und was wird gemacht wenn die Fläche durch eine Strasse geteilt wird? Kommt das amenity=school nur an die größer Flache oder macht man dann aus der Fläche ein Relation vom Typ Multipolygon das wäre zumindest konsequent.

Durch Straße geteilt ist nicht mehr "größtmöglich zusammenhängend2, wie ich schrieb. Beide Flächen bekämen bei mir dann unabhängig voneinander amenity=school. Was soll das MP da bringen?

Blos was machen Mappe die eigentlich keine Flachen eintragen sonder nur die Häuser von Bing abzeichnen?
Die müssten dann zumindest eine Relation erstellen in der alle Schulgebäude eingetragen sind damit amenity=school nicht zu häufig vorkommt.

Da reicht doch an jedem Gebäude building=school. Das Problem wäre nur für name=* relevant, damit nicht an jedem Schulgebäude der Name separat klebt.

Es kann halt nur so funktionieren dass der Auswerter alles Mögliche von Node über Weg zu Relation berücksichtigen muss.

Klasse, wir machen es uns einfach und die Auswertung hat das Problem

aighes · 2012-04-27 08:02:43

hurdygurdyman wrote:

badger123 wrote:
Und was wird gemacht wenn die Fläche durch eine Strasse geteilt wird? Kommt das amenity=school nur an die größer Flache oder macht man dann aus der Fläche ein Relation vom Typ Multipolygon das wäre zumindest konsequent.
Durch Straße geteilt ist nicht mehr "größtmöglich zusammenhängend2, wie ich schrieb. Beide Flächen bekämen bei mir dann unabhängig voneinander amenity=school. Was soll das MP da bringen?

Dann hast du zwei Schulen eingetragen. Ob das sinnvoll ist oder der Realität entspricht?

So eine ganz andere Idee...evtl. sollte man mal ein inverses planet-file anbieten. Das mit Relationen beginnt, dann die ways und am Schluss erst die Nodes. Für so Auswertungen wäre das durchaus sinnvoll.

Last edited by aighes (2012-04-27 08:04:58)

hurdygurdyman · 2012-04-27 09:15:59

aighes wrote:

...
Dann hast du zwei Schulen eingetragen. Ob das sinnvoll ist oder der Realität entspricht?
...

Nö, ich habe zwei Flächen, die als Schulgelände genutzt werden eingetragen und das entspricht der Realität

aighes · 2012-04-27 10:25:53

Die logische Interpretation einer dummen Maschine ist aber: Hier sind 2 Schulen. amenity=school sagt nämlich genau dies aus. Daher sollte es auch an ein Konstrukt getagt werden, dass die gesamte Schule abbildet.

hurdygurdyman · 2012-04-27 10:46:22

aighes wrote:

Die logische Interpretation einer dummen Maschine ist aber: Hier sind 2 Schulen. amenity=school sagt nämlich genau dies aus. Daher sollte es auch an ein Konstrukt getagt werden, dass die gesamte Schule abbildet.

Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.

wambacher · 2012-04-27 11:54:46

hurdygurdyman wrote:

Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.

Da liegst du leider leicht daneben: "ein" Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern ... der Fall, wenn sie in mehreren Teilflächen erfasst werden.

Gruss
Walter

hurdygurdyman · 2012-04-27 12:54:40

wambacher wrote:

hurdygurdyman wrote:
Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.
Da liegst du leider leicht daneben: "ein" Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern ... der Fall, wenn sie in mehreren Teilflächen erfasst werden.
Gruss
Walter

Zur Klarstellung: ich meinte einen Wald in der Realität. Ansonsten gebe ich dir recht, aber wird das auch so gemacht?

quasilotte · 2012-04-27 14:18:20

hurdygurdyman wrote:

wambacher wrote:
hurdygurdyman wrote:
Wenn wir Wälder aus Riesen-Polygonen zerschneiden, sind das auch mehrere Flächen aber immer noch ein Wald
In o.g. Fall sind die Flächen wenigstens durch die Straße getrennt.
Da liegst du leider leicht daneben: "ein" Wald, erfasst mit zwei landuse - oder auch zwei MP - sind und bleiben in OSM zwei Wälder. Auch wenn diese durch künstliche/mutwillige Überlappung auf der Mapnik-Karte als zusammenhängende Fläche dargestellt werden.
Willst du mehrere unabhängige Flächen zusammenfassen weil sie logisch zusammenhängen aber physikalisch getrennt sind (z.b gleicher Name für verschiedene Teilstücke), kommst du um Relationen nicht rum.
Und das ist auch bei Naturschutzgebieten, Militaria, Industriegebieten, Schulen, Krankenhäusern ... der Fall, wenn sie in mehreren Teilflächen erfasst werden.
Gruss
Walter
Zur Klarstellung: ich meinte einen Wald in der Realität. Ansonsten gebe ich dir recht, aber wird das auch so gemacht?

Auch in der Realität kommt sowas vor (ich glaub das war der Harz) - das EIN Wald in meheren Teilen erstellt ist und durch eine Realtion zusammengefasst ist!
Dort ist es sogar noch extremer da nicht Flächen zu einem Wald zusammengefsst sind sondern der Wald erst durch zusammensetzten von Ways zu einer Fläche wird (Grund ist dort die 2000 Punktegrenze von Ways).

Einheitliches Tagging wird ohne feste vorgeschriebene Regeln nicht gehen und diese werden in OSM nicht gewollt - deshalb alles für des Kaisers Bart!!!!

Announcement

#26 2012-04-26 15:19:02

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#27 2012-04-26 15:55:58

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#28 2012-04-26 16:22:12

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#29 2012-04-26 16:26:26

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#30 2012-04-26 16:30:39

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#31 2012-04-26 16:41:58

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#32 2012-04-26 16:47:54

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#33 2012-04-26 16:54:33

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#34 2012-04-26 16:57:51

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#35 2012-04-26 17:05:00

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#36 2012-04-26 18:15:36

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#37 2012-04-26 19:17:37

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#38 2012-04-26 19:27:09

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#39 2012-04-26 20:09:08

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#40 2012-04-26 20:22:25

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#41 2012-04-26 22:26:03

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#42 2012-04-27 02:51:49

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#43 2012-04-27 07:08:26

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#44 2012-04-27 08:02:43

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#45 2012-04-27 09:15:59

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#46 2012-04-27 10:25:53

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#47 2012-04-27 10:46:22

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#48 2012-04-27 11:54:46

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#49 2012-04-27 12:54:40

Re: Einheitliches Tagging für POIs & App zur Kontrolle

#50 2012-04-27 14:18:20

Re: Einheitliches Tagging für POIs & App zur Kontrolle

Board footer