POI nicht als Polygon eintragen!

Oli-Wan · 2013-01-14 19:38:54

moenk wrote:

Frag mal einer die Wheelmapper was die für ein Rad drehen mussten.

Frag mal einer die Mapper, die den Murks der Wheelmapper regelmäßig aufgeräumt haben, weil letztere einen unfertigen Editor auf ein Massenpublikum losgelassen haben. Damit wären wir wieder bei den unausgereiften Anwendungen - ich bedaure, falls meine Äußerung bei Dir nun zu erneuter Emesis führt.

pyram · 2013-01-15 00:50:06

Die Grundfrage des Problems ist eigentlich eine andere: Sind die Eigenschaften des "POIs" am richtigen Element angehängt.
Die meisten "POIs", die als Polygon gemappt sind, sind doch nur Tags an buildings. Und das ist meistens falsch. Warum? Weil das Gebäude eben nicht so wie der POI heißt oder wie bei Aldi meistens gar keinen Namen hat. Wenn man den Aldi schon als Polygon mappen will, dann schon gleich als Ring um Gebäude UND Parkplatz. Dann erübrigen sich auch häufige Fantasiename wie "Aldi-Parkplatz", "Besucherparkplatz" und dergleichen.

Seit einiger Zeit sehe ich, dass dieses letztgenannte Taggingprinzip zumindest bei Schulen schon Schule macht ;-) Das Schulgelände bekommt den Schulnamen und die Einzelgebäude können "richtige" Namen -so vorhanden- oder auch lokale Namen (wie "Südflügel") bekommen.

Leider gibt es genügend Mapper, die nach dem Prinzip "eine Fläche ist besser als ein Punkt" die Arbeit von Vor-Ort-Erfassern einfach abändern (der POI wird einfach an das darunterliegende Gebäude gehängt - auch wenn sich noch weitere (nicht gemappte) POIs und Wohnungen darin befinden). Das eigentlich sehr schöne buildings_tools-Plugin ist sogar standardmäßig so eingestellt, einen innerhalb des neuen Gebäudes liegenden POI zu verwursten (glücklicherweise habe ich die Einstellungsmöglichkeit gefunden - und sofort ausgeschaltet) :-(

Jimmy_K · 2013-01-15 10:10:21

Zu einem Zeitpunkt, wo wir beim Detailmapping so weit sind, dass wir beginnnen in öffentlich zugänglichen Gebäude Räume einzuzeichnen, gleichzeitig darüber zu diskutieren, ob wir einen weit über 100m² großen Supermärkte wieder auf einen Punkt reduzieren finde ich ein wenig widersprüchlich.
Wenn sich nur ein POI am Gebäude befindet, auch wenn es nur ein kleines ist, es gleich an das gesamte Gebäudepolygon zu hängen, ist auch ein wenig übertrieben. Wenn die Fläche bekannt ist, würde ich ein eigenes Polygon anstreben (mit Stockwerksangabe).

LG Jimmy

PS: Bitte nicht daran aufhängen, dass im POI "Point" steht, das muss nicht gezwungener maßen heißen, dass es ein Punkt ohne Flächenausbreitung ist.

moenk · 2013-01-15 11:06:40

Oli-Wan wrote:

Damit wären wir wieder bei den unausgereiften Anwendungen - ich bedaure, falls meine Äußerung bei Dir nun zu erneuter Emesis führt.

Oli-wan,

ich bin da recht unemotional. Ändert aber nichts dran, dass ich POI als Polygon für falsch halte und das Problem mit den Wheelmapper mit POI-Punkten hätte auch vermieden werden können. Für mich heißt es auch sich der Realität der Anwendungen zu stellen, wenn man sich Gedanken über ein Datenmodell macht. Das ist ein Problem von OSM: Das Datenmodell ist historisch gewachsen und erfüllt nicht was man an allgemeinen Qualitätsmaßstäben an Geodaten anlegt - daran gemessen ist völliger Murks. Das kann man nun verteidigen oder schrittweise beheben.

LG,

-moenk

moenk · 2013-01-15 11:08:12

erwin6330 wrote:

Ich wäre auch für eine Trennung, denn dieses Erfassungssystem ist nicht konsequent
Befindet sich nur ein POI im Gebäude, dann ans Gebäude, sind es mehrere dann an einen Node, nicht gut

Erwin,

danke für Deinen Hinweis. Das erschien mir schon so trivial, dass ich vergessen habe darauf hinzuweisen. Allein das ist schon Grund genug POI nur als Punkt zu mappen.

LG,

-moenk

hurdygurdyman · 2013-01-15 11:10:10

Jimmy_K wrote:

...
PS: Bitte nicht daran aufhängen, dass im POI "Point" steht, das muss nicht gezwungener maßen heißen, dass es ein Punkt ohne Flächenausbreitung ist.

+1
point kann auch einfach "Ort" heißen ( http://www.dict.cc/?s=point ) und interest kann mit "Wichtigkeit" oder "Bedeutung" übersett werden ( http://www.dict.cc/?s=interest&failed_kw=interest ), woraus sich für "point of interest" "Ort von Bedeutung" ergibt.

moenk · 2013-01-15 11:12:42

S-Man42 wrote:

@moenk: Machen wir das mal anders herum. Mit Polygonen hast du die Möglichkeit, dem Restaurant eine Fläche zu geben. Wenn wir jetzt komplett auf Punkte umsteigen würden, wie würdest du dann irgendwann (man weiß ja nie, vielleicht bekommen wir ja irgendwann Pläne von Gebäuden auf einem Level 20 oder so) die Fläche angeben?

S-Man,

danke auch für Deinen Hinweis, über den ich erst mal nachdenken musste. Es ändert sich aber nichts für mich. Selbst wenn wir in einer Shopping-Mall jeden Laden indoor kartiert haben, über mehrere Geschosse meinetwegen, dann möchte ich den Laden als solchen und dann den POI als Punkt mit Hinweis was da gibt kartieren. Der Punkt liegt drin, vielleicht denken wir über einen Tag nach der Sorte von "is_in" als eine Art Relation nach, dass man zu einem Polygon immer den passenden POI und umgekehrt finden kann.

LG,

-moenk

moenk · 2013-01-15 11:16:23

Jimmy.

Jimmy_K wrote:

Zu einem Zeitpunkt, wo wir beim Detailmapping so weit sind, dass wir beginnnen in öffentlich zugänglichen Gebäude Räume einzuzeichnen, gleichzeitig darüber zu diskutieren, ob wir einen weit über 100m² großen Supermärkte wieder auf einen Punkt reduzieren finde ich ein wenig widersprüchlich.

so ist das nicht. Das Gebäude des Supermarkts ist doch da mit seiner Fläche. Der Punkt zeigt dann sogar auf den Eingang und nicht nur auf die Mitte. Und der Bäcker-Laden vorweg kann auch indoor kartiert werden, dazu ein POI auf den Eingang.

LG,

-moenk

tunnelbauer · 2013-01-15 11:21:24

moenk wrote:

Der Punkt zeigt dann sogar auf den Eingang und nicht nur auf die Mitte.

Dann ist jeder "POI" also auch als "building:entrance" zu taggen... (oder sollten wir dann nicht gleich auch noch shop/amenity/...:entrance einführen?)

moenk · 2013-01-15 11:31:23

tunnelbauer wrote:

Dann ist jeder "POI" also auch als "building:entrance" zu taggen...

Thomas,

das hängt dann davon ab, wie der POI liegt - wenn er denn auf dem Eingang liegt, eine gute Idee. Ich würd das nicht mal vorschreiben wollen, vielleicht gibts auch Fälle wo man den POI nicht auf den Eingang legen will. Vielleicht gibt sogar Fälle, wo man den POI auf einen Zuweg mit einem Schild legen will, weil man sonst gar nicht hinfindet.

LG,

-moenk

tunnelbauer · 2013-01-15 11:37:53

Dann wiedersprichst du dir jetzt gerade selber: Geradeeben sagst du der POI darf nicht irgendwo liegen sondern genau am eingang und jetzt liegt er aufeinmal am "Zuweg" - oder sollen wir POIs setzen? Ähnlich einer Krümelspur? Dann bräuchten wir auch keine routing-Software mehr - einfach der POIs-Kette folgen...

Also für mich ist und bleibt ein POI ein "Ort" und kein "Punkt" - ein Schloss/Burg kann ja zB ein "POI" sein - da will ich dann aber nicht nur einen Punkt im Innenhof sehen, sondern das Bauwerk in seiner Gesamtheit - somit bleibe ich bei Tagging-Schema alt: "Ein POI" > way/polygon - "mehrere POIs" > nodes

streckenkundler · 2013-01-15 11:55:30

Hallo,

POI? was ist ein POI?

hurdygurdyman wrote:

point kann auch einfach "Ort" heißen ( http://www.dict.cc/?s=point ) und interest kann mit "Wichtigkeit" oder "Bedeutung" übersett werden ( http://www.dict.cc/?s=interest&failed_kw=interest ), woraus sich für "point of interest" "Ort von Bedeutung" ergibt.

Aber was ist es genau? Es ist immer das, was der jeweilige Betrachter darin sieht. Für den einen sind es geschichtliche Orte, den anderen ehemalige Bahnstrecken, wieder andere Einkaufsläden, oder Taxistände. Dasraus ergibt sich für mich, daß ein POI sowohl Fläche, Linie oder Punkt sein kann (auch in Relationen). Diese POI's immer als Punkte zu sehen, halte für unlogisch.

POI ist wie ein Gummituch. Jeder zieht es dahin, wo er es haben will.

Sven

errt · 2013-01-15 20:17:18

moenk wrote:

Selbst wenn wir in einer Shopping-Mall jeden Laden indoor kartiert haben, über mehrere Geschosse meinetwegen, dann möchte ich den Laden als solchen und dann den POI als Punkt mit Hinweis was da gibt kartieren. Der Punkt liegt drin, vielleicht denken wir über einen Tag nach der Sorte von "is_in" als eine Art Relation nach, dass man zu einem Polygon immer den passenden POI und umgekehrt finden kann.

Die is_in-Relation macht die Sachen aber für alle Seiten komplexer und ohne die geht die Beziehung zwischen Fläche und POI verloren. Den automatisch darin zu verorten ist noch wesentlich blöder für die Auswerter. Und es gibt ja durchaus verschiedene Auswerter. Für Rederer ist es Mist, wenn der POI auf dem Gebäuderand liegt wie ein Eingang, denn dann landet der Schriftzug völlig falsch oder man muss deutlich mehr Aufwand betreiben. Letzlich bleiben insgesamt fast nur Nachteile.

moenk · 2013-01-16 16:20:25

Errt,

ich will die Relation oder "is_in"-Geschichte auch nicht haben. Mir reicht wenn der Punkt in der Fläche liegt. Und die Attribute für den POI an dem Punkt und nicht am Gebäude hängen. Wo der Renderer den Schriftzug hinsetzt ist mir eigentlich recht egal, mir ist wichtiger, dass man alle POI bekommt wenn man die z.B. über die Overpass-API abfragt.

LG,

-moenk

errt · 2013-01-16 16:34:41

Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem. Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden. Schlag es denen halt mal vor. Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.

reneman · 2013-01-16 16:38:23

errt wrote:

Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem. Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden. Schlag es denen halt mal vor. Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.

+1

moenk · 2013-01-16 16:46:40

errt wrote:

Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden.

Errt,

hast dazu mal ein Beispiel? Punkte lassen sich einfach abfragem Zentroide wäre mir neu.

LG,

-moenk

chkr · 2013-01-16 21:15:55

errt wrote:

Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem.

Ich glaube, du irrst. Ein guter Renderer setzt Symbole und Beschriftungen so, dass der Zusammenhang zum dazugehoerigen Objekt nicht verloren geht und wird ansonsten das Gesamtbild optimieren. Da kommt's auf ein paar Pixel lechts oder rinks nicht an.

errt wrote:

Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.

Du hast: "Das haben wir schon immer so gemacht! Das haben wir noch nie so gemacht! Da koennte ja jeder kommen!" vergessen.

Warum reagieren hier eigentlich viele so, als ob moenk ihnen ihr Lieblings-Sandfoermchen wegnehmen will? Er schlaegt eine Vereinfachung vor. Die ist mit Beschraenkungen verbunden. Was geht denn nun wirklich verloren, wenn wir seinen Vorschlag umsetzen wuerden?

Gruss Christian

errt · 2013-01-16 23:09:21

moenk wrote:

errt wrote:
Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden.
hast dazu mal ein Beispiel? Punkte lassen sich einfach abfragem Zentroide wäre mir neu.

Das Zitat lese sich als 'technisch kein Problem, leider noch nicht umgesetzt'

chkr wrote:

errt wrote:
Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem.
Ich glaube, du irrst. Ein guter Renderer setzt Symbole und Beschriftungen so, dass der Zusammenhang zum dazugehoerigen Objekt nicht verloren geht und wird ansonsten das Gesamtbild optimieren. Da kommt's auf ein paar Pixel lechts oder rinks nicht an.

Natürlich tut das ein guter Renderer. Aber das kann er nur solange er den Zusammenhang kennt. Und wenn ich nunmal irgendwohin (weiter oben hieß es schon, auf den Parkplatz) einen Punkt setze, kann er den nicht mit der Fläche in Verbindung bringen. Man sollte es ihm doch nicht unnötig schwer machen, wenn doch eine der Hauptbegründungen für die Punktvariante war, dass sei für die Auswerter leichter - ist es eben nicht für alle, nur für bestimmte.

chkr wrote:

errt wrote:
Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.
Du hast: "Das haben wir schon immer so gemacht! Das haben wir noch nie so gemacht! Da koennte ja jeder kommen!" vergessen.
Warum reagieren hier eigentlich viele so, als ob moenk ihnen ihr Lieblings-Sandfoermchen wegnehmen will? Er schlaegt eine Vereinfachung vor. Die ist mit Beschraenkungen verbunden. Was geht denn nun wirklich verloren, wenn wir seinen Vorschlag umsetzen wuerden?

Ich habe nichts gegen eine Verbesserung. Aber hier sehe ich eben einen Rückschritt. Und es ist ja nun so, dass das Ganze seit längerem so praktiziert wird und die meisten damit keine Probleme haben und die Tool-Unterstützung schon recht gut ist.
Was uns verloren geht, wenn wir das umsetzen? Der Bezug von Fläche und Nutzung geht uns verloren. Das kann man natürlich unproblematisch finden, mich würde es stören. Viele Renderer stellen beispielsweise Gebäude mit POI anders da, als solche ohne, das verbessert die Orientierung auf der Karte doch gewaltig. OSM wirbt doch gerade auch damit, dass wir semantisch wertvolle Daten mit Beziehungen der geographischen Objekte untereinander und mit weiterführenden Informationen haben, und nicht nur, wie kommerzielle Datensätze, Punktwolken mit gerade so viel Information, wie für wenige Hauptanwendungsfälle gerade so notwendig.
Natürlich müssen wir darauf achten, dass unsere Daten leicht zu erfassen und leicht zu verwerten sind. Aber mal ehrlich: Zumindest mit JOSM (andere Editoren nutze ich zu wenig, um das beurteilen zu können) ist es kein bisschen komplexer, das mit Flächen zu erfassen. Die Auswertung ist natürlich etwas komplexer, ganz klar, schließlich muss man ja zwei Fälle abdecken. Aber mit Unterstützung der einschlägigen Werkzeuge (osmconvert wurde schon angesprochen) und der Tatsache, dass das als häufig benötigte und technisch nicht so komplexe Funktion ist und deshalb sicher auch von anderen Werkzeugen unterstützt werden wird (wie schon gesagt, schlagt es doch für die Overpass-API mal vor - wenn sie's nicht doch schon kann), sehe ich auch keine allzu großen Hürden für Auswerter. Da haben wir wirklich wesentlich komplexere Daten, wenn es z.B. um Relationen, Multipolygone, ÖPNV-Linien geht.

HolgerJeromin · 2013-01-16 23:50:25

Ok, ich habe ein großen Aldi (um beim Beispiel zu bleiben). Dieser hat zwei Eingänge. Einer ist nicht rollstuhltauglich, der andere schon. (nicht realitätsnah, aber egal :-)
Aktuelles mapping:
Gebäude+Aldi polygon. Auf diesem sind zwei entrance=yes nodes, wheelchair=yes/no jeweils. Meine (fiktive?) wheelchair-Routingsoftware kann also mich zum Aldi führen und weiss, dass sie direkt den entrance node mit wheelchair=yes ansteuern muss. Einfach, weil sie sieht, dass der Such-Treffer ein polygon ist und der zwei entrances nodes hat.

Vorgeschlagenes Mapping:
Gebäudepolygon und in der Mitte ein Aldi-Node. Das Gebäude hat auch jeweils die Entrance Nodes.
Meine routing-software hat jetzt einen Berg arbeit vor sich, rauszufinden, ob der Such-Treffer-Node jetzt innerhalb eines Gebäudes liegt. Dazu muss sie zusätzlich raten, dass beide entrance-nodes hoffentlich auch wirklich in den Supermarkt führen.

Alternativ:
Gebäudepolygon mit Aldinode am Haupteingang. Damit weiss erst recht keiner, dass der 20 meter danebenliegende wheelchair entrance auch in den supermarkt führt...

Alternativ 2:
Gebäudepolygon mit Aldinode in der Mitte. Dazu zwei Eingänge auf dem Gebäude und zwei footways von den Eingängen zum Aldi-Node. wird dann aber erstens hässlich und zweitens aufwändiger zu mappen.

Da gefällt mir das aktuelle Datenmodell irgendwie besser.

chkr · 2013-01-16 23:51:54

... nur kurz wegen der vorgerueckten Stunde:

errt wrote:

... und die meisten damit keine Probleme haben ...

Die "meisten" Mapper lesen dieses Forum nicht. Und die "meisten" von den hier Mitlesenden/-schreibenden arbeiten nicht in Projekten mit, die irgendwas zur Verfuegung stellen, dass dann von 'Nicht-Mappern' verwendet wird.

Leute wie moenk kriegen durch Fragen von Benutzern (anders als die "meisten") mit, wie unlogisch und kompliziert unser Tagging-Modell an manchen Stellen ist und wie viele Probleme in der Praxis dadurch entstehen.

Wenn wir die Erfahrungen der "Verwerter" unserer Daten nicht Ernst nehmen, anstelle sie mit "Problem der Anwendung - mir doch egal, ich kippe in die DB was ich diese Woche gerade glaube, was en vogue ist!" abzubuegeln, dann werden wir dem Gedanken der "Foerderung freier Geodaten" wohl nicht wirklich gerecht.

Gruss Christian

Last edited by chkr (2013-01-17 00:02:49)

errt · 2013-01-17 00:24:26

Das wird aber auch nicht besser, wenn wir in die DB kippen, was gerade bei den "Verwertern" en vogue ist, wie du so schön sagst. Alles was wir für die tun können, ist vernünftige Schnittstellen zu schaffen, welches Datenmodell denen auch immer zu Grunde liegt. Und grundsätzlich kommt man nun mal nicht drumherum, sich mit dem Datenmodell auseinanderzusetzen, wenn man die Daten vernünftig verwerten will, so viele sollten da also nicht von Außen kommen und dann erwarten, dass alles irgendwie gebrauchsfertig vorliegt. Jedenfalls kritisiere ich, dass ihr behauptet, die vorgeschlagene Variante wäre für "die Auswerter" besser - das stimmt eben nicht. Sie ist für manche Nischen etwas einfacher, korrekt, aber Wege das zu ermöglichen wurden aufgezeigt, aber für andere Nischen wesentlich komplizierter, das wurde ebenfalls schon angesprochen, siehe auch HolgerJeromin über dir, Lösungsansätze dafür wurden aber nicht genannt. Warum also einen Weg forcieren, der zwar manche Auswertungen vereinfacht, andere aber fast unmöglich macht, wenn der aktuell eingeschlagene, natürlich sicher auch nicht perfekte, Weg für praktisch alles, was mir bisher an Auswertungen unserer Daten bekannt geworden ist, zumindest keine besonders großen Hürden aufwirft. Insbesondere ist das Beispiel mit der Wheelmap ungeeignet, denn das Problem war von Anfang an bekannt und obwohl grundsätzlich Lösungen existierten wurde eine halbfertige Anwendung auf die Öffentlichkeit losgelassen.

Mondschein · 2013-01-17 00:44:14

errt und HolgerJeromin:
+1

moenk wrote:

"ganz einfach" isses übrigens gar nicht, nur in bestimmten Szenarien lässt sich die Auswertung mit relativ wenig Aufwand machen. Frag mal einer die Wheelmapper was die für ein Rad drehen mussten.

Das Beispiel mit Wheelmap ist auch deshalb ungeeignet, weil Wheelmap nicht nur ein Auswerter ist, sondern auch einen POI-Editor über die Internetseite bietet.
Erst die Möglichkeit der Bearbeitung und Rückgabe (Synchronisierung) von Daten in die OSM-Datenbank macht die Sache so aufwändig.

Gruß,
Mondschein

Last edited by Mondschein (2013-01-17 00:45:50)

wambacher · 2013-01-17 05:10:26

Mondschein wrote:

Erst die Möglichkeit der Bearbeitung und Rückgabe (Synchronisierung) von Daten in die OSM-Datenbank macht die Sache so aufwändig.

Komisch, ich muß da gerade an ein anderes Programm denken, dass sich wohl mit den gleichen Problemen rumschlagen muß.

Lösungsansatz A: Programm erweitern
Lösungsansatz B: Rohdaten vereinfachen

Ein Schelm, wer da Böses denkt

Gruss
walter

moenk · 2013-01-17 11:55:13

errt wrote:

Die Auswertung ist natürlich etwas komplexer, ganz klar, schließlich muss man ja zwei Fälle abdecken.

Errt,

zwei nur? Zähl mal nach.

LG,

-moenk

OpenStreetMap Forum

#26 2013-01-14 19:38:54

Re: POI nicht als Polygon eintragen!

#27 2013-01-15 00:50:06

Re: POI nicht als Polygon eintragen!

#28 2013-01-15 10:10:21

Re: POI nicht als Polygon eintragen!

#29 2013-01-15 11:06:40

Re: POI nicht als Polygon eintragen!

#30 2013-01-15 11:08:12

Re: POI nicht als Polygon eintragen!

#31 2013-01-15 11:10:10

Re: POI nicht als Polygon eintragen!

#32 2013-01-15 11:12:42

Re: POI nicht als Polygon eintragen!

#33 2013-01-15 11:16:23

Re: POI nicht als Polygon eintragen!

#34 2013-01-15 11:21:24

Re: POI nicht als Polygon eintragen!

#35 2013-01-15 11:31:23

Re: POI nicht als Polygon eintragen!

#36 2013-01-15 11:37:53

Re: POI nicht als Polygon eintragen!

#37 2013-01-15 11:55:30

Re: POI nicht als Polygon eintragen!

#38 2013-01-15 20:17:18

Re: POI nicht als Polygon eintragen!

#39 2013-01-16 16:20:25

Re: POI nicht als Polygon eintragen!

#40 2013-01-16 16:34:41

Re: POI nicht als Polygon eintragen!

#41 2013-01-16 16:38:23

Re: POI nicht als Polygon eintragen!

#42 2013-01-16 16:46:40

Re: POI nicht als Polygon eintragen!

#43 2013-01-16 21:15:55

Re: POI nicht als Polygon eintragen!

#44 2013-01-16 23:09:21

Re: POI nicht als Polygon eintragen!

#45 2013-01-16 23:50:25

Re: POI nicht als Polygon eintragen!

#46 2013-01-16 23:51:54

Re: POI nicht als Polygon eintragen!

#47 2013-01-17 00:24:26

Re: POI nicht als Polygon eintragen!

#48 2013-01-17 00:44:14

Re: POI nicht als Polygon eintragen!

#49 2013-01-17 05:10:26

Re: POI nicht als Polygon eintragen!

#50 2013-01-17 11:55:13

Re: POI nicht als Polygon eintragen!

Board footer