Einheitliches Tagging für POIs & App zur Kontrolle

misterboo · 2012-04-24 11:25:29

Ich würde gerne eine App erstellen, mit der man bestimmte Themen visualisieren und kontrollieren kann.
Als Test habe ich mir das Thema Education ausgesucht, also tags mit amenity=kindergarten, school, college, university, education

Ziel soll es sein diese einfach zu visualisieren und evt mal ein einheitliches Taggingschema auszuarbeiten, das auch entsprechend
gut dokumentiert ist im Wiki.

Einfach bedeutet: der Datenbestand soll aktuell sein und weltweit auswertbar sein. Eine eigene Infrastruktur fällt da schon mal weg,
denn für eine weltweite Auswertung fehlt mir die Hardware.

Dank Overpass API ist das aber problemlos möglich.

Hier mal eine erste Testversion der App (funktioniert mit modernen Browsern, aber nicht mit dem IE 6-8 - meine Popups funktionieren dort nicht)

http://osm.misterboo.de/education/

Ausgangspunkt für Anwender die so etwas auswerten möchten, sollte eigentlich das Wiki sein, hier z.B. zum Tagging amenity=school

http://wiki.openstreetmap.org/wiki/DE:T … y%3Dschool

Setze einen Punkt Node oder zeichne die Fläche Area des Schulgeländes (die Schulgebäude können innerhalb dieser als Flächen mit building=school gezeichnet werden)

Wenn man sich als Auswerter danach richten könnte, wäre das gut, die Realität des taggings weicht jedoch
wie so oft in OSM von den Vorgaben im Wiki ab, was eine Auswertung nicht gerade erleichtert.

Hier ein paar Beispiele wie abweichend von den Wiki Vorgaben getagged wird:
(In dem Startbereich meiner TestApp sieht man schon einige problematische Taggings)

1. Gebäude werden mit amenity=school getagged, einfache und auch mutipolygone, teilweise dann auch mehrere Gebäude, die zur Schule gehören, alle jeweils mit amenity=school
2. die Fläche des Schulgeländes wird getaggt mit amenity=school, zusätzlich aber auch die Gebäude auf dem Gelände ebenfalls mit amenty=school und teilweise auch noch zusätzlich ein Node
3. Es werden Relaltionen verwendet, die mit amenity=school getagged werden, man findet dabei type=site, type=multipolygon und type=collection, auch hier wieder oft noch zusätzlich amenity=school bei den Mitgliedern der Realtionen.

Meine App soll evt. mal helfen, das etwas zu vereinheitlichen.

Dazu sollte aber erst mal etwas detaillierter festgelegt werden, wie das optimale Tagging denn aussehen sollte.

Die Visualisierung ist recht einfach für nodes, Gebäude und Flächen, da openlayers ja das OSM Format kennt, es werden allerdings keine Relationen ausgewertet.
Daher auch mal in die Runde gefragt: hat sich schon mal jemand näher damit beschäftigt, OSM Relationen in Javascript zu visualisieren aus den xml Daten ?

Last edited by misterboo (2012-04-24 13:14:59)

misterboo · 2012-04-25 15:43:57

Hier noch ein Bildschirmfoto der App:

Die einzelnen Elemente sind anklickbar und können mit einem Klick auf Bearbeiten auch direkt in JOSM geladen und bearbeitet werden.

Wie im Bild zu erkennen, erkennt man recht leicht die gängigen Fehler, wie hier im Beispiel, wo die Fläche der Schule,
zusätzlich die Gebäude und noch zusätzlich ein Node mit amenity=school getagged sind.

Last edited by misterboo (2012-04-25 16:49:38)

wambacher · 2012-04-25 16:48:19

misterboo wrote:

http://gis-1/education/img/preview.png

link geht nicht, da gis-1 kein Rechner im Internet ist - zumindest ist der Name unvollständig. gis-1.hkts.de oder sowas wäre nötig

Gruss
walter

Last edited by wambacher (2012-04-25 16:51:31)

misterboo · 2012-04-25 16:51:12

wambacher wrote:

link geht nicht, da gis-1 kein Rechner im Internet ist - zumindest ist der Name unvollständig. gis-1.hkts.de oder sowas wäre nötig
Gruss
walter

Danke, korrigiert.

misterboo · 2012-04-26 10:49:15

Was meint Ihr ?

Im Wiki steht nichts über Relationen bei Schulen.

Realtionen sind viel aufwendiger auszuwerten, daher die Frage an diesem Beispiel:

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

Ist da eine Relation wirklich notwendig ? Würde es nicht reichen die Grenze des Schulgeländes mit amenity=school zu taggen ?

Last edited by misterboo (2012-04-26 10:52:20)

chris66 · 2012-04-26 11:06:39

Die Grenze ist ja als mit amenity=school getaggt, zusätzlich wurden per site-Relation die einzelnen Bestandteile
zusammengefügt, also mMn. alles in Ordnung.

wambacher · 2012-04-26 11:08:53

misterboo wrote:

Ist da eine Relation wirklich notwendig ? Würde es nicht reichen die Grenze des Schulgeländes mit amenity=school zu taggen ?

Site-Relationen decken mMn alle solche Situationen ab: "Was liegt innerhalb eines definierten Bereiches (Fläche) und besteht aus welchen Objekten? "
Da sind Schulen nur eine von vielen.
Aus diesem Grunde halte ich nicht viel davon, ausgerechnet für Schulen die Sache festzuklopfen und alle anderen "Sites" draussen vor zu lassen.

Da allerdings für viele (Mapper und Puter) Relationen immer noch schwer zu greifen sind, schlage ich folgenden Kompromiss vor:
Alles, was sich innerhalb einer amenity-Fläche befindet (amenity=school / amenity=parking / ...) gehört dazu.

Gruss
Walter

p.s. ich erfasse derzeit die "Schulen in Hessen" (da war doch mal ein Projekt ???) und halte mich bei den Relationen derzeit auch etwas zurück. Es kann aber sein, dass ich das Thema doch nochmal anfasse und händisch umtagge.

wambacher · 2012-04-26 11:11:51

chris66 wrote:

Die Grenze ist ja als mit amenity=school getaggt, zusätzlich wurden per site-Relation die einzelnen Bestandteile
zusammengefügt, also mMn. alles in Ordnung.

"Knackpunkt" für mich ist eigentlich die Frage, wo die "gemeinsamen/globalen" Tags hinkommen: an die amenity oder in die Relation?
Formal richtiger ist für mich die Relation.

misterboo · 2012-04-26 11:19:32

OK, type=site wird also schon verwendet

Wo ist das genau dokumentiert im Wiki ? Denn genau solche Dokumentationen sind notwendig für Auswerter.

Ist site überhaupt ein offizielles tagging ?
Wenn es denn für Schulen (oder andere POIs) verwendet werden kann, sollte das auch im Wiki stehen.

Dazu dann eine Erklärung wo die tags der Schule(name, Adresse und sonstigen Infos) dran sollen bei einer site. Wenn die Tags an der Relation sind, hilft es mir ja zum Beispiel als Auswerter nichts, wenn der perimeter mit amenity=school getagged ist. Ich muss dann trotzdem die Relation auswerten um an die tags zu kommen.

misterboo · 2012-04-26 11:20:53

wambacher wrote:

chris66 wrote:
Die Grenze ist ja als mit amenity=school getaggt, zusätzlich wurden per site-Relation die einzelnen Bestandteile
zusammengefügt, also mMn. alles in Ordnung.
"Knackpunkt" für mich ist eigentlich die Frage, wo die "gemeinsamen/globalen" Tags hinkommen: an die amenity oder in die Relation?
Formal richtiger ist für mich die Relation.

Genau das ist das Problem ... wo kommen die Tags hin und wo ist das dokumentiert ?

Was ist mit Schule, die statt type=site type=collection oder type=multipolygon verwenden und die tags an der Relation sind ... auch hier muss ich als Auswerter aufwendig und zeitintensiv die Relationen auswerten, was meiner meinung nach unnötig ist, wenn man Relationen bei POIs vermeiden würde.

Ich verstehe ja den Spruch "wir taggen nicht für die Renderer" ... das ist auch OK ... aber wir sollten so taggen, dass Auswerter auch etwas mit den Daten anfangen können und in diesem Sinne sollte man sich an das KISS Prinzip halten. Relationen auswerten um an simple Sachen wie die Adresse einer Schule zu kommen sind für mich nicht KISS.

Last edited by misterboo (2012-04-26 11:27:44)

chris66 · 2012-04-26 11:27:16

Da "site" momentan von fast keiner Anwendung ausgewertet wird, würde ich davor warnen, die Tags nur an
die site zu heften.

misterboo · 2012-04-26 11:29:13

chris66 wrote:

Da "site" momentan von fast keiner Anwendung ausgewertet wird, würde ich davor warnen, die Tags nur an
die site zu heften.

also wohin dann ? doppelt an die site und den perimeter ist ja auch nicht gerade überzeugend ?

Ich könnte als Auswerter mit der site leben wenn da ein node verpflichtend wäre, an diesen kommen dann die Tags. Dann gibt es wegen mir die komplizierte site relation, wenn mich aber nur die Infos der Schule interessieren, dann reicht es wenn ich den node auswerte.

Daraus könnte man gut eine allgemeine Regel machen: An die Infos von POIs aller Art sollte man ohne Auswertung von Relationen rankommen. Und pro POI sollte auch die Angabe des POI Typs einmalig sein. Das würde die Auswertung deutlich erleichtern.

Last edited by misterboo (2012-04-26 11:39:45)

moenk · 2012-04-26 11:57:26

Hallo alle,

ich würde eh begrüßen, wenn POI immer ein Punkt wären. Würde das gesamte Handling vereinfachen, siehe das Wheelmap-Problem. So ein Punkt kann auch immer Teil des Way sein. Ich habe auch immer den Verdacht, dass die Attribute eines POI nur deswegen an die Polygone geheftet werden, damit sie auf der Karte korrekt als Zentroid dargestellt werden. Das wiederspricht für mich dem Mantra nicht für Renderer zu mappen. Ein Punkt bleibt für mich ein Punkt und eine POI ist wie der Namen schon sagt erst mal ein Punkt. POI und sie enthaltende Gebäude kann man und sollte sie auch sauber trennen. Trotzdem werde ich deswegen nicht anfangen, fremde Datensätze zu ändern oder Vorgaben zu machen, wie man mappen sollte. Eine Software muss damit klarkommen, wie sie die Daten vorfindet.

LG,

-moenk

monotar · 2012-04-26 12:04:54

Mappen für den Renderer->Gebäude
Mappen für den Router->Eingang
Mappen für niemand->POI in der Luft

Wie ich schon den Hass kriege wenn jemand "Mappen für den Renderer" als Floskel benutzt. Natürlich muss man auch so mappen, dass dann was ordentliches rauskommen kann beim !Rendern!, ansonsten können wir alle POI-Nodes 1 Meter neben die Straße setzen, haben wir nichts gekonnt und sieht am Ende alles wie bei Google aus. Warum zeichnen wir dann überhaupt Gebäude und Flächen ein??? Ich lach jedes Mal wenn ich eine Stadt sehe wo jede Nummer auf den Eingang gesetzt wird, schlechte Platzausnutzung, sieht scheußlich aus und das wichtigste: Es wird keinem Renderer gelingen die Nummer so platzieren, dass es irgendwann gut aussehen wird.

Deshalb: Gebäude/Fläche mit POI und wen es interessiert, soll eine Relation zum Eingang setzen oder diesen als Haupteingang kennzeichnen.

chris66 · 2012-04-26 12:05:54

@moenk
Na ja, wann ein Objekt ein POI ist, ist ja in OSM auch nicht genau definiert.
Du würdest dann z.B. Parkplätze auch immer als Node taggen wollen? Und die P-Fläche
mit einem anderen Tag amenity=parking_area oder so? Kann's auch net sein.

Last edited by chris66 (2012-04-26 12:06:25)

misterboo · 2012-04-26 12:14:53

Also nur Node POIs ist sicherlich keine gute Idee.

Natürlich sollte die POis bzw es geht ja eher um die tags der POIs auch an Gebäude oder Flächen

Aber meiner Meinung nach sollten eben 3 Regeln gelten:

1. man sollte an die Infos der POIs ohne Auswertung von Relationen kommen
2. Pro POI nur einmal der typ des POIs, also z.b. nicht Fläche + zusätzlich alle Gebäude mit amenity=school taggen
3. Und auch die Info tags auch nur einmal pro POI, also die Tags nicht an die Fläche und nochmal als zusätzlicher node

Mondschein · 2012-04-26 12:28:23

moenk wrote:

ich würde eh begrüßen, wenn POI immer ein Punkt wären.

http://wiki.openstreetmap.org/wiki/POI

moenk wrote:

Ich habe auch immer den Verdacht, dass die Attribute eines POI nur deswegen an die Polygone geheftet werden, damit sie auf der Karte korrekt als Zentroid dargestellt werden. Das wiederspricht für mich dem Mantra nicht für Renderer zu mappen.

Diesen Verdacht habe ich nicht.
Ein Parkplatz ist eine Fläche und diese Fläche bekommt auch die Tags.

Gruß,
Mondschein

aighes · 2012-04-26 13:20:18

misterboo wrote:

1. man sollte an die Infos der POIs ohne Auswertung von Relationen kommen
2. Pro POI nur einmal der typ des POIs, also z.b. nicht Fläche + zusätzlich alle Gebäude mit amenity=school taggen
3. Und auch die Info tags auch nur einmal pro POI, also die Tags nicht an die Fläche und nochmal als zusätzlicher node

zu 1): sollte man anstreben, aber wenn es nicht anders geht, geht es halt nicht anders. Bspw. weil eine Schule zwei getrennte Schulgelände hat.

zu 2): JA

zu 3): JA, wobei es bei Unterobjekten natürlich auch Infotaggs geben kann. Bspw. die Sporthalle sollte man schon mit der Info versehen, dass es eine Sporthalle ist und was alles sonst noch taggesnwert ist. Aber alle Taggs, die die Schule beschreiben sollen auch an das Objekt mit dem amenity=school.

@moenk: Ich bevorzuge die Darstellung des POI-Symbols einer Fläche an dem Eingang. Je nach Auswerter ist das umgesetzt bzw. möglich umzusetzen.

misterboo · 2012-04-26 13:25:33

aighes wrote:

misterboo wrote:
1. man sollte an die Infos der POIs ohne Auswertung von Relationen kommen
2. Pro POI nur einmal der typ des POIs, also z.b. nicht Fläche + zusätzlich alle Gebäude mit amenity=school taggen
3. Und auch die Info tags auch nur einmal pro POI, also die Tags nicht an die Fläche und nochmal als zusätzlicher node
zu 1): sollte man anstreben, aber wenn es nicht anders geht, geht es halt nicht anders. Bspw. weil eine Schule zwei getrennte Schulgelände hat.
zu 2): JA
zu 3): JA, wobei es bei Unterobjekten natürlich auch Infotaggs geben kann. Bspw. die Sporthalle sollte man schon mit der Info versehen, dass es eine Sporthalle ist und was alles sonst noch taggesnwert ist. Aber alle Taggs, die die Schule beschreiben sollen auch an das Objekt mit dem amenity=school.
@moenk: Ich bevorzuge die Darstellung des POI-Symbols einer Fläche an dem Eingang. Je nach Auswerter ist das umgesetzt bzw. möglich umzusetzen.

Dein zu 1) angegebener Fall ist auch der einzige wo meiner Meinung eine Relation Sinn macht ... So z.B wenn eine Hochschule noch ein Nebengebäude hat, das einige Blocks entfernt ist. Aber genau für den Fall sollte man sich ein Tagging überlegen, mit dem man das Auswerten der Relationen umgehen könnte, z.B. mit einem node und den entsprechenden Tags als Teil der Relation.

Nur für diese wenigen Ausnahmen, wo eine Relation bei POIs auch fast notwendig ist, eine zeitlich aufwendige Relationen Auswertung durchlaufen zu müssen um auch an diese POIs zu kommen, ist doch unsinnig.

Last edited by misterboo (2012-04-26 13:27:22)

aighes · 2012-04-26 13:35:55

Es lohnt nicht unbedingt da recht viel Aufwand reinzustecken...lieber den Aufwand in API0.7 stecken, sodass wir einen vernünftigen Flächen-Datentyp bekommen.

misterboo · 2012-04-26 13:45:59

aighes wrote:

Es lohnt nicht unbedingt da recht viel Aufwand reinzustecken...lieber den Aufwand in API0.7 stecken, sodass wir einen vernünftigen Flächen-Datentyp bekommen.

Da bin ich anderer Meinung. Je klarer und eindeutiger ein Tagging ist, umso einfacher kann man das auch später per Bot oder anders automatisiert auswerten und umwandeln für eine evt. neue API.

Der ganze Lizenzwechsel war bzw. ist ja schon eine Heidenarbeit für Mapper und die Programmierer, die daran im Moment arbeiten. Alle paar Jahre den Mappern was vorsetzen, wo sie wieder eine Menge korrigieren müssen und evt. wieder Daten verloren gehen, wird nicht gerade viele motivieren auf Dauer. Und ich denke, dass ein Lizenzwechsel Kindergarten ist im Vergleich zu einer umfangreichen Änderung an der API.

Und da bin ich der Meinung, dass egal was man mit den Daten macht, ob Auswerten, Karten erstellen oder irgendwann in einen anderen Datentyp umwandeln. Je besser das Tagging ist, umso einfacher sind die ganzen Prozesse. Und genau deshalb sollten wir anfangen, etwas mehr auf die Qualität des Taggings zu achten, und dazu gehört meiner Meinung dass man für einfache POI Informationen keine Relationen auswerten sollte.

Und dabei soll eben meine Karte etwas helfen, die man später auch für andere POI Themen ausweiten kann.

http://osm.misterboo.de/education/

Wichtig, um die Karte auch vernünftig zu nutzen, ist aber erst mal eine eindeutige und genaue Definition im Wiki, die ich dann auch in meiner Karte verlinken kann.

Also nach der Art:

- Wenn Du eine Schule findest die zusätzlich zur Fläche einen Node hat, übertrage die tags auf die Fläche und lösche den node.
- Wenn du eine POI Fläche findest mit amenity=school, wo neben der Fläche auch zusätzlich die einzelnen Gebäude mit amenity=school getagged sind, dann lösche diesen Tag bei den Gebäuden
- wenn du mehrere Gebäude findest, die zu der gleichen Schule gehören und alle jeweils mit amenity=school getagged sind, versuche eine Fläche um die Schule zu erstellen, gib dieser den tag amenity=school und lösche diesen Tag bei den einzelnen Gebäuden. Sollten die Gebäude schon info tags haben, übertrage diese an die neu erstellte Fläche
u.s.w.

das heir ist z.B ein typisches Beispiel:

http://osm.misterboo.de/education/?zoom … yers=B00TT

Da sollten die Tags an die Fläche, der node sollte weg und bei den Gebäuden sollte amenity=school weg , evt. building=school an die Gebäude, so wie es im Wiki steht.

ebenso z.B. hier:

http://osm.misterboo.de/education/?zoom … yers=B00TT

Und hier noch ein seltsames Beispiel:

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

Eine Schule als Multipolygon, outer die Fläche und inner die beiden Gebäude

Last edited by misterboo (2012-04-26 14:39:29)

moenk · 2012-04-26 14:59:16

chris66 wrote:

Du würdest dann z.B. Parkplätze auch immer als Node taggen wollen? Und die P-Fläche
mit einem anderen Tag amenity=parking_area oder so? Kann's auch net sein.

Chris,

beides kann man machen. Die Fläche mit dem Tag, nur um die Raumnutzung zu dokumentieren. Den POI, wie man ihn in der Datenbank haben möchte, vermutlich mitten rein. Der Renderer wird dann dort die Zahl reinmalen, das Navi führt einen dann dort hin. Der Renderer der dann beides nimmt, also das Attribut von der Fläche und den des POI, ist dann selbst schuld weil er nicht gut genug generalisiert.

Mir gefällt das Mantra mit dem "nicht für Renderer mappen", an dieser Stelle erscheint mir die Vorgehensweise jedoch inkonsequent. Aber soll meinetwegen jeder machen wie er/sie/es will. Um auf den Ausgangspunkt zurückzukommen: Eine App (was für eine überhaupt?) die irgendwas kontrolliert oder Vorgaben macht erscheint mir nicht sinnvoll.

LG,

-moenk

chris66 · 2012-04-26 15:02:29

moenk wrote:

Aber soll meinetwegen jeder machen wie er/sie/es will.

Ja, so läuft es momentan und das halbwegs gut. Die Meinungen ob es mit einem verbindlichen Regelwerk besser laufen
würde gehen ja durchaus auseinander.

moenk · 2012-04-26 15:03:14

moenk wrote:

Ein Parkplatz ist eine Fläche und diese Fläche bekommt auch die Tags.

Mondschein,

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.

LG,

-moenk

misterboo · 2012-04-26 15:07:17

moenk wrote:

chris66 wrote:
Du würdest dann z.B. Parkplätze auch immer als Node taggen wollen? Und die P-Fläche
mit einem anderen Tag amenity=parking_area oder so? Kann's auch net sein.
Chris,
beides kann man machen. Die Fläche mit dem Tag, nur um die Raumnutzung zu dokumentieren. Den POI, wie man ihn in der Datenbank haben möchte, vermutlich mitten rein. Der Renderer wird dann dort die Zahl reinmalen, das Navi führt einen dann dort hin. Der Renderer der dann beides nimmt, also das Attribut von der Fläche und den des POI, ist dann selbst schuld weil er nicht gut genug generalisiert.
Mir gefällt das Mantra mit dem "nicht für Renderer mappen", an dieser Stelle erscheint mir die Vorgehensweise jedoch inkonsequent. Aber soll meinetwegen jeder machen wie er/sie/es will. Um auf den Ausgangspunkt zurückzukommen: Eine App (was für eine überhaupt?) die irgendwas kontrolliert oder Vorgaben macht erscheint mir nicht sinnvoll.
LG,
-moenk

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

Announcement

#1 2012-04-24 11:25:29

Einheitliches Tagging für POIs & App zur Kontrolle

#2 2012-04-25 15:43:57

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

#3 2012-04-25 16:48:19

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

#4 2012-04-25 16:51:12

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

#5 2012-04-26 10:49:15

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

#6 2012-04-26 11:06:39

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

#7 2012-04-26 11:08:53

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

#8 2012-04-26 11:11:51

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

#9 2012-04-26 11:19:32

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

#10 2012-04-26 11:20:53

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

#11 2012-04-26 11:27:16

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

#12 2012-04-26 11:29:13

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

#13 2012-04-26 11:57:26

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

#14 2012-04-26 12:04:54

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

#15 2012-04-26 12:05:54

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

#16 2012-04-26 12:14:53

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

#17 2012-04-26 12:28:23

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

#18 2012-04-26 13:20:18

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

#19 2012-04-26 13:25:33

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

#20 2012-04-26 13:35:55

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

#21 2012-04-26 13:45:59

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

#22 2012-04-26 14:59:16

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

#23 2012-04-26 15:02:29

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

#24 2012-04-26 15:03:14

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

#25 2012-04-26 15:07:17

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

Board footer