Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
On 25/04/12 19:53, Christian Müller wrote: Am 23.04.2012 23:29, schrieb Tirkon: Von welcher Meldung sprichst Du konkret? In der Abteilung Relationen wird jede betroffene Relation mit dem Zusatz (unvollständig) versehen. Das veranlasst zum Nachzuladen, womit es verschindet. Es ist demnach ein Kürzel für unvollständig geladen. Inzwischen achte ich darauf, dass nachgeladen wird, was natürlich im Rahmen der Zunahme von Relationen immer mühevoller wird. Besonders dann, wenn die Geschichte rekursiv wird - also das Nachladen zur Aufnahme neuer, unvollständig geladener Relationen in die Relationsliste führt.. Denn JOSM hat nach umfangreichen Edits etwas von der ID einer solchen Relation gefaselt und dann das Hochladen komplett verweigert. Die Arbeit war somit für den A. Ein Fall ist mir noch erinnerlich, wo ich Punkte gemergt habe. Eventuell gehörte einer davon zu solch einer Relation. Das passiert mir auch häufig, wenn ich nicht darauf geachtet habe, dort nachzuladen, wo Punkte außerhalb der ursprünglich geladenen Bereichsgrenzen liegen. Mit Nodes, die komplett innerhalb von geladenen Bereichen liegen, sollte das, auch beim Mergen, nicht passieren.. Leider hat JOSM zur Zeit mehrere Bugs, was Mergen angeht. Scheint ein kompliziertes Thema zu sein, da einige Tickets schon fast zwei Jahre bestehen. Desshalb habe ich persönlich auch aufgehört offline zu editieren, da ich mehr Zeit damit verbracht habe Konflikte zu lösen und mich mit Bugs rumzuärgen als für das eigentliche Editieren. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 23.04.2012 23:29, schrieb Tirkon: Von welcher Meldung sprichst Du konkret? In der Abteilung Relationen wird jede betroffene Relation mit dem Zusatz (unvollständig) versehen. Das veranlasst zum Nachzuladen, womit es verschindet. Es ist demnach ein Kürzel für unvollständig geladen. Inzwischen achte ich darauf, dass nachgeladen wird, was natürlich im Rahmen der Zunahme von Relationen immer mühevoller wird. Besonders dann, wenn die Geschichte rekursiv wird - also das Nachladen zur Aufnahme neuer, unvollständig geladener Relationen in die Relationsliste führt.. Denn JOSM hat nach umfangreichen Edits etwas von der ID einer solchen Relation gefaselt und dann das Hochladen komplett verweigert. Die Arbeit war somit für den A. Ein Fall ist mir noch erinnerlich, wo ich Punkte gemergt habe. Eventuell gehörte einer davon zu solch einer Relation. Das passiert mir auch häufig, wenn ich nicht darauf geachtet habe, dort nachzuladen, wo Punkte außerhalb der ursprünglich geladenen Bereichsgrenzen liegen. Mit Nodes, die komplett innerhalb von geladenen Bereichen liegen, sollte das, auch beim Mergen, nicht passieren.. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, Am Samstag, 21. April 2012 13:03:51 schrieb Wolfgang: eine Kette von Polygonen zu teilen, die nicht jeder immer laden Ist nicht korrekt ausgedrückt, es hätte Polygonlinien ( in Anlehnung an geod. Polygonzug) oder offenes Polygon heißen müssen, da das Polygon als Figur betrachtet wird (obwohl es IMO eigentlich nur viele Winkel bzw. freier viele Ecken heißt). Ich verfolge diesen thread nicht mehr so ausführlich, er dreht sich im Polygon :-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Martin Koppenhoefer dieterdre...@gmail.com schrieb: Am 22. April 2012 18:08 schrieb Christian Müller cmu...@gmx.de: Am 22.04.2012 14:47, schrieb Tirkon: Multipolygon - zu deutsch etwa viele Vielecke diese Übersetzung greift zu kurz, es sind Vielecke (eingeschlossen sind Dreiecke aufwärts), die aus mehreren Umrissen und/oder Umrissteilen bestehen. Das ist keine Übersetzung mehr, sondern eine Erklärung. Auch eine nicht geschlossene Linie kann als ein Polygon aufgefasst werden, der Wortbedeutung nach. Hilfsweise kann man sich eine Linie zwischen (offenem) Anfangs- und Enpunkt denken. -1, das bringt uns in OSM nicht weiter sondern sorgt nur für Verwirrung und ist ggf. auch falsch: wenn solche offenen ways in der Summe einen geschlossenen Way (und damit je nach Tagging ein Polygon) ergeben, dann ist die Summe der Polygone, die sich durch einzelnes Schließen der offenen ways jeweils ergeben, noch lange nicht daselbe Polygon. Das hat auch niemand behauptet. Dennoch kann man jeden offenen Streckenzug mit mehr als einer Ecke der Wortbedeutung nach als Vieleck auffassen. Das eine Aneinanderkettung ein neues Polygon bildet, ist implizit klar. Verwirrend für den OP empfinde ich daher deine Antwort. Im Extremfall (lauter Segmente mit jeweils nur 2 nodes) kann das Multipolygon durchaus valide sein, die einzelnen Teile sind aber trotzdem keine Polygone (da es Zweiecke nicht gibt). Das ist falsch. Schau Dir de.wikipedia.org/wiki/Polygon an. Streng genommen ist sogar der Punkt eine Ecke. kann man zwar (unvollständig interpretiere ich als unvollständig geladen), davon ist aber meistens abzuraten, weil die Gefahr, Dinge zu zerstören, groß ist. Finde ich nicht, es funktioniert hervorragend. Evtl. braucht man etwas Übung, aber das gilt für so ziemlich alles - insbes. wenn z.B. Elemente unsortiert vorliegen. Es gibt aber viele Situationen in denen das extrem hilfreich ist. Momentan hässlich ist, dass der Editor versucht, unvollständig geladene Flächen zu rendern - das geht i.d.R. schief und sieht unschön aus - es weist aber nicht auf Fehler in den Daten hin. es weist darauf hin, dass dort etwas unvollständig geladen ist, und nach Möglichkeit diese Daten nachgeladen werden sollten, m.E. ist das ein Feature. Das ist eine Geschmackssache. M.E. sollten Grafikfehler auf echte Fehler in den Daten hinweisen, nicht darauf, dass ein Datensatz nur unvollständig geladen ist. Außerdem lenkt das ganze ab - es ist u.U. nicht nötig, Daten für einen bestimmten Edit nachuladen, aber aufgrund der Grafikfehler beschäftigt sich ein Mapper mit dem iterativen Nachladen sämtlicher MP, bis alles hübsch ist. Da es eine Geschmackssache ist, wird es konfigurierbar sein, so wie die Option, nur die Außenlinie von Flächen zeichnen zu lassen. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 22. April 2012 02:14 schrieb Garry garr...@gmx.de: Es gibt auch Sonderfälle die nicht per MP gelöst werden können. Beispiel: Gib mir alle deutschen Bundestrassenabschnitte. - Ein Abschnitt der B317 bei Lörrach verläuft (Zollfreie,Freigabe im Laufe des Jahres) über schweizer Gebiet und liegt damit ausserhalb der deutschen Grenze, hat aber keinerlei Verbindung (Fluchtwege nicht betrachtet) ans schweizer Strassennetz. mit dem OSM Modell mappen wir bisher nicht, welche Straßen deutsch sind bzw. grundsätzlich wem eine Straße oder ein anderes Objekt gehört. Wir mappen nur, wo die Grenzen des deutschen Staats verlaufen, daher können wir auch eine Anfrage nach allen deutschen Bundesstraßen höchstens näherungsweise beantworten. Solche Ausnahmen wie von Dir genannt werfen u.U. auch andere Fragen auf. Ist es z.B. sicher, dass auf dieser deutschen Straße auf schweizerischem Gebiet deutsche Gesetze und Regeln gelten? Falls ja, nur hinsichtlich StVO oder auch StVG? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 22. April 2012 18:08 schrieb Christian Müller cmu...@gmx.de: Am 22.04.2012 14:47, schrieb Tirkon: Multipolygon - zu deutsch etwa viele Vielecke diese Übersetzung greift zu kurz, es sind Vielecke (eingeschlossen sind Dreiecke aufwärts), die aus mehreren Umrissen und/oder Umrissteilen bestehen. Auch eine nicht geschlossene Linie kann als ein Polygon aufgefasst werden, der Wortbedeutung nach. Hilfsweise kann man sich eine Linie zwischen (offenem) Anfangs- und Enpunkt denken. -1, das bringt uns in OSM nicht weiter sondern sorgt nur für Verwirrung und ist ggf. auch falsch: wenn solche offenen ways in der Summe einen geschlossenen Way (und damit je nach Tagging ein Polygon) ergeben, dann ist die Summe der Polygone, die sich durch einzelnes Schließen der offenen ways jeweils ergeben, noch lange nicht daselbe Polygon. Im Extremfall (lauter Segmente mit jeweils nur 2 nodes) kann das Multipolygon durchaus valide sein, die einzelnen Teile sind aber trotzdem keine Polygone (da es Zweiecke nicht gibt). Du kannst auch eine unvollständige Relation editieren und Elemente hinzufügen. kann man zwar (unvollständig interpretiere ich als unvollständig geladen), davon ist aber meistens abzuraten, weil die Gefahr, Dinge zu zerstören, groß ist. Momentan hässlich ist, dass der Editor versucht, unvollständig geladene Flächen zu rendern - das geht i.d.R. schief und sieht unschön aus - es weist aber nicht auf Fehler in den Daten hin. es weist darauf hin, dass dort etwas unvollständig geladen ist, und nach Möglichkeit diese Daten nachgeladen werden sollten, m.E. ist das ein Feature. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hi, On Sat, Apr 21, 2012 at 04:39:59AM +0200, Tirkon wrote: Die ÖPNV Relationen sind das beste Beispiel dafür, wie sich ein als möglichst umfassend und stimmig befundenes Oxomoa Schema einfach nicht durchsetzt. Selbst die Spezialisten mappen das Schema in zig Varianten. Die meisten örtlichen Mapper hingegen setzen intuitiv an die Stelle des Haltestellen-Schildes ein busstop und fertig. Denn genau diese Vokabel haben sie im Englisch-Unterricht oder als muttersprachliches Kind als Bezeichnung dafür gelernt. Wird eine Bushaltestelle verlegt, dann wird das Schild versetzt oder temporär ein anderes aufgestellt und das originale als ungültig gekennzeichnet. Ich bin ja nun 20 Jahre in der Informatik unterwegs - eine Sache die ich Leuten immer wieder Predige die tolle Datensammlungen mit tollen möglichkeiten Designen ist: Wenn es keine technische Abhaengigkeit gibt wird es nicht gepflegt. Wenn der mapper etwas erreichen möchte - wie z.b. - Es taucht auf der Karte auf - Es funktioniert im Routing - Die Namenssuche funktioniert dann werden Daten richtig erfasst und auch im zweifelsfalle so lange korrigiert bis sie funktioniert. Es wird auch im Forum nachgefragt Warum taucht das nicht in der Karte auf. D.h. schaff eine Applikation die etwas mit den Daten macht und erklaere wie deine Applikation die Daten nutzt und schon werden sich Leute finden die die Daten korrigieren. Nur vom Datenmodell ist das in etwa wie eingeschlafene Fuesse. Im ueberigen geht mir das genauso - Ich habe die ganzen Schulen in der Umgebung auch erst korrigiert als der Straßenindex bei MapOSMatic kaputt war. Ich habe auch viele ÖPNV Linien eingetragen - die tauchen auch alle schön in der ÖPNV Karte auf - Aber bei der ganzen forward/backward Nummer war meine Motivation weg - Es gibt IIRC keine Applikation die da irgendwas sinnvolles mit macht - Auch wenn es eine Applikation geben würde die mit den Linien ein Routing macht ständen sofort eine Menge leute da die die Linien feiner Mappen würden. Auch der Durschnittliche Bundesbuerger ist in der Lage eine Relation zu Pflegen aber er muss a) Motiviert sein etwas zu erreichen und b) in der Lage sein sich dieses Wissen ohne grosse Hürden anzueignen. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Christian Müller cmu...@gmx.de wrote: Wenn ich einen Umring teile, so sind diese Teile keine geschlossenen Linien und somit kein Polygon mehr. Wo kommt also die Kette von Polygonen her? Möchtest Du einen Staat in Flächenteile (Polygone) zerlegen, um diese dann zu vereinen (Kette von Polygonen)? Könntest Du das erläutern? Ich habe ihn so verstanden: normale Polygone - ein geschlossener Weg Multipolygone - mehrere, offene Polygone, die aneinandergereiht einen geschlossenen Weg ergeben Was Wolfgang also meinte, waren Multilinestrings - in diesem Fall zum (Multi)-Popolygon geschlossene. http://wiki.openstreetmap.org/wiki/Relation:multilinestring Die sind bekannt und so wird sein Konstrukt verständlich und einige der weiteren Fragen lösen sich in Wohlgefallen auf. Polygon war hier etwas missverständlich, da mir solche im Allgemeinen und auch bei OSM-Objekten nur als geschlossen definiert bekannt waren. Ich habe aufgrund Deiner Erklärung noch bei Wikipedia geschaut und dort scheint man der gleichen Meinung zu sein: http://de.wikipedia.org/wiki/Polygon Multipolygone sind auch bekannt. Gerade die von mir bearbeiteten waren diejenigen, die mich bei der Auswertung des OSM Inspektors stutzig machten und zum Ursprungsposting dieses Threads veranlassten. Zudem meckert JOSM bei unvollständigen Relationen. Von welcher Meldung sprichst Du konkret? In der Abteilung Relationen wird jede betroffene Relation mit dem Zusatz (unvollständig) versehen. Das veranlasst zum Nachzuladen, womit es verschindet. Es ist demnach ein Kürzel für unvollständig geladen. Inzwischen achte ich darauf, dass nachgeladen wird, was natürlich im Rahmen der Zunahme von Relationen immer mühevoller wird. Denn JOSM hat nach umfangreichen Edits etwas von der ID einer solchen Relation gefaselt und dann das Hochladen komplett verweigert. Die Arbeit war somit für den A. Ein Fall ist mir noch erinnerlich, wo ich Punkte gemergt habe. Eventuell gehörte einer davon zu solch einer Relation. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Florian Lohoff f...@zz.de wrote: ... Wenn es keine technische Abhaengigkeit gibt wird es nicht gepflegt. ... +1 für das gesamte Posting. Schön, Dich wieder zurück im Projekt zu haben. Aber bei der ganzen forward/backward Nummer war meine Motivation weg - Es gibt IIRC keine Applikation die da irgendwas sinnvolles mit macht Dieses mühevolle Unterfangen beim Erfassen und Lesen einer ÖPNV Linie ist IMHO bei getrennter Erfassung der beiden Fahrtrichtungen obsolet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Wolfgang wolfg...@ivkasogis.de wrote: Hallo, Am Samstag, 21. April 2012 04:39:59 schrieb Tirkon: Zurück zum multipolygon und zur boundary. Das multipolygon ist ein geometrisches Objekt und hat zunächst einmal wenig mit OSM zu tun. Was wir erfassen, ist eine Grenze, also boundary. Von daher wird es sich wesentlich weniger Mappern erschließen, warum ich an ein multipolygon Landkreis X dranpappen soll anstatt an ein boundary. Bei Landkreisen sind normale Polygone noch handhabbar, Was ist der Unterschied zwischen einem normalen Polygon und einem unnormalen? Ist letzteres für Dich ein Multipolygon? Bei Landkreisen, die unverbundene/disjunkte Inseln beinhalten, sehe ich keine andere Möglichkeit, als Multipolygone zu benutzen. Oder sehe ich das falsch? bei Staatsgrenzen teilweise nicht mehr. Da macht es Sinn, die Umringe in eine Kette von Polygonen zu teilen, die nicht jeder immer laden muss. Wenn ich einen Umring teile, so sind diese Teile keine geschlossenen Linien und somit kein Polygon mehr. Wo kommt also die Kette von Polygonen her? Möchtest Du einen Staat in Flächenteile (Polygone) zerlegen, um diese dann zu vereinen (Kette von Polygonen)? Könntest Du das erläutern? Zudem meckert JOSM bei unvollständigen Relationen. Dabei wird man im Unklaren gelassen, was nun passiert, wenn man nicht nachlädt und dennoch editiert. Also lädt man vorsichtshalber doch nach. Der Vorteil ist also nur ein theorethischer. Das leistet das Multipolygon. Ich halte dieses Argument für vermittelbar. Ich verstehe aufgrund oben Beschriebenen ncht einmal das Argument, geschweige die Folgerung. Nicht jeder hat einen vdsl50-Anschluss. Was hat die Art des Mappings mit einem dicken Internet Anschluss zu tun? Muss ich Internettechnologie können, um Grenzen adäquat mappen zu können? Und wo läge das Problem, ein nach außen als boundary getagtes Objekt so zu behandeln, als ob es mit multipolygon getagt sei. Denn so wie ich die bisherigen Postings verstehe, sind diese austauschbar. In Deutschland hießen sie vor der Massenänderung multipolygon, in anderen Ländern boundary. Oder nicht? Es ist nicht sinnvoll, in jede Relation wieder jede Formel reinzupacken, nur weil jemand ausschließlich das mappen will, was ihm gerade so eingefallen ist. Von welcher Formel sprichst Du? Etwas im Wiki zu lesen sollte zumutbar sein, das machen gerade die neuen Mapper in der Regel auch bereitwillig.Ob der Mapper jetzt boundary oder multipolygon benutzt, dürfte ihm insofern egal sein. Zumal er wahrscheinlich überhaupt keine Relation benutzen wird, denn rein intuitiv ist die Grenze eines kleineren Gebildes mit dem boundary=administrative und dem admin-level bereits fertig. Könntest Du mal ein Beispielobjekt verlinken, das ohne Relation mit boundary=administrative und dem admin-level bereits fertig ist? Außer einer Insel mit fehlenden Anrainern fällt mir da nichts ein, wo dies möglich wäre. Wenn jemand mappt boundary=county, name='Ostfriesische Schweiz' bist du auch wieder nicht zufrieden. Was sollte mir an der Ostfriesischen Schweiz nicht gefallen, außer dass sie kein Landkreis (county) ist? Und was hat das mit multipolygon vs boundary zu tun? Ich habe keinen Schimmer, was Du oben insgesamt aussagen willst - insbesondere bezogen auf boundary vs multipolygon. Etwas im Wiki zu lesen sollte zumutbar sein, das machen gerade die neuen Mapper in der Regel auch bereitwillig. ... sofern sie dieses umsetzen können. Du siehst dabei vermutlich nur die Mapper, welche von sich aus in Foren, Mailinglisten etc. in Erscheinung treten aber nicht die schweigende Mehrheit. Ich denke, man ist schon zu sehr Insider, um die Probleme des Mappers noch zu verstehen. Um das mal zu illustrieren, folgender Fall: Das Straßennetz einer Stadt wurde im Wesentlichen von zwei Mappern erfasst. Einer davon war im Zuge der Lizenzumstellung nicht mehr erreichbar. Daraufhin habe ich kurz vor Toresschluss den anderen Mapper freundlich auf diesen Umstand hingewiesen und angefragt, ob er die Straßen des anderen remappen könne. Die Antwort war, dass nun alles rot sei und OSM jetzt nicht mehr funktioniere. Damit kenne er sich nicht aus. Ich habe nicht mehr weiter insistiert, was genau das Problem sei und mich stattdessen bedankt. Denn insgesamt machte es den Eindruck, als ob weitere Nachfragen nicht beantwortet werden könnten. alles rot bedeutet nach meiner Einschätzung die inzwischen durch den Eintrag von landuse eines weiteren Mappers erzeugte rote Fläche im Datenlayer auf osm.org. Sobald diese rote Fläche auftaucht, ist ein Objekt innerhalb kaum mehr anklickbar. Meistens trifft man den landuse und gewinnt dadurch möglicherweise den Eindruck, dass OSM innerhalb einer roten landuse Fläche nicht mehr wie gewohnt funktioniere. In einem weiteren Beispiel hat ein User erzählt, dass er bisher unter dem Usernamen XY an OSM mitgearbeitet habe. Dieser Name exstiert in OSM und im Wiki aber nicht. Rein zufällig bin ich dann in einer der Bugreportseiten auf den
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 22.04.2012 14:47, schrieb Tirkon: Wenn ich einen Umring teile, so sind diese Teile keine geschlossenen Linien und somit kein Polygon mehr. Wo kommt also die Kette von Polygonen her? Möchtest Du einen Staat in Flächenteile (Polygone) zerlegen, um diese dann zu vereinen (Kette von Polygonen)? Könntest Du das erläutern? Ich habe ihn so verstanden: normale Polygone - ein geschlossener Weg Multipolygone - mehrere, offene Polygone, die aneinandergereiht einen geschlossenen Weg ergeben Multipolygon - zu deutsch etwa viele Vielecke Auch eine nicht geschlossene Linie kann als ein Polygon aufgefasst werden, der Wortbedeutung nach. Hilfsweise kann man sich eine Linie zwischen (offenem) Anfangs- und Enpunkt denken. Normale Polygone sind nur ein Sonderfall von Multipolygonen, solchen, die nur ein Mitglied in der Rolle outer haben - den geschlossenen Weg. Mehr Details siehe http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon Mir fallen folgende Möglichkeiten ein, eine Staatsgrenze zu erfassen: - ein geschlossener Weg - mehrere offene Wege (bzw. Polygone) als outer innerhalb eines MP - diese können von Bundeslandgrenzen recyclet worden sein - oder eine eigenständige Näherung darstellen - mehrere Relationen als outer innerhalb eines MP - jede Teilrelation enthält dann mehrere offene Wege (bzw. Polygone) Letztere Variante wird für die Relation mit der ID 1.111.111 verwendet. Die Teilrelationen sind jeweils zusammenhängende Abschnitte der Gesamtgrenze. Je Abschnitt werden genau die offenen Wege gruppiert, die an genau einen Nachbarstaat grenzen, siehe http://www.openstreetmap.org/browse/relation/111 Zudem meckert JOSM bei unvollständigen Relationen. Dabei wird man im Unklaren gelassen, was nun passiert, wenn man nicht nachlädt und dennoch editiert. Also lädt man vorsichtshalber doch nach. Der Vorteil ist also nur ein theorethischer. Nein, er ist praktischer Natur - Du kannst auch eine unvollständige Relation editieren und Elemente hinzufügen. Von welcher Meldung sprichst Du konkret? Momentan hässlich ist, dass der Editor versucht, unvollständig geladene Flächen zu rendern - das geht i.d.R. schief und sieht unschön aus - es weist aber nicht auf Fehler in den Daten hin. Entweder lädt man die MP komplett, dann werden sie auch richtig angezeigt, oder man nutzt die Option Flächen nicht rendern in den Einstellungen. Evtl. ändert sich dieses Verhalten in einer zukünftigen Version von JOSM. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 20. April 2012 18:00 schrieb Christian Müller cmu...@gmx.de: Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu tun. Warum gehen davon eigentlich alle aus? Nicht immer stecken die zu verarbeitenden Daten in einer fetten DB, die bereitwillig rechnet. Gäbe es die Flächenbezüge in den Daten wären z.B. auch billige JavaScript Hacks denkbar, die dann client-seitig laufen, anstatt einen Server zu belasten.. Das stimmt, und wäre ein interessantes Thema für ein paralleles Projekt, wo man solche Bezüge aus der OSM db ableitet, und zum download bereitstellt. Man sollte aber nicht die Server des Gesamtprojekts, wo diese Bezüge bereits enthalten sind, --- wenn auch in einer Form, die eine gewisse Verarbeitung erfordert, um sie herauszubekommen --- damit belasten. +1 In diese Richtung gehende Bemühungen wären sicherlich hilfreich und würden viele Probleme ebnen - auch in der Kommunikation zwischen Geeks und einfachem Mapper. Ergebnisse aus Abfragen müssten dann auch online oder in JOSM als Hintergrund visualisierbar und dort auch selektiv als Datenebene downloadbar sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, Am Samstag, 21. April 2012 04:39:59 schrieb Tirkon: Zurück zum multipolygon und zur boundary. Das multipolygon ist ein geometrisches Objekt und hat zunächst einmal wenig mit OSM zu tun. Was wir erfassen, ist eine Grenze, also boundary. Von daher wird es sich wesentlich weniger Mappern erschließen, warum ich an ein multipolygon Landkreis X dranpappen soll anstatt an ein boundary. Bei Landkreisen sind normale Polygone noch handhabbar, bei Staatsgrenzen teilweise nicht mehr. Da macht es Sinn, die Umringe in eine Kette von Polygonen zu teilen, die nicht jeder immer laden muss. Das leistet das Multipolygon. Ich halte dieses Argument für vermittelbar. Nicht jeder hat einen vdsl50-Anschluss. Es ist nicht sinnvoll, in jede Relation wieder jede Formel reinzupacken, nur weil jemand ausschließlich das mappen will, was ihm gerade so eingefallen ist. Etwas im Wiki zu lesen sollte zumutbar sein, das machen gerade die neuen Mapper in der Regel auch bereitwillig.Ob der Mapper jetzt boundary oder multipolygon benutzt, dürfte ihm insofern egal sein. Zumal er wahrscheinlich überhaupt keine Relation benutzen wird, denn rein intuitiv ist die Grenze eines kleineren Gebildes mit dem boundary=administrative und dem admin-level bereits fertig. Wenn jemand mappt boundary=county, name='Ostfriesische Schweiz' bist du auch wieder nicht zufrieden. ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Wolfgang-4 wrote Bei Landkreisen sind normale Polygone noch handhabbar, bei Staatsgrenzen teilweise nicht mehr. Da macht es Sinn, die Umringe in eine Kette von Polygonen zu teilen, die nicht jeder immer laden muss. Das leistet das Multipolygon. jo, ganz deiner Meinung. Schau dir mal diese Relation an: http://www.openstreetmap.org/browse/relation/111 www.openstreetmap.org/browse/relation/111 Mein Baby wird bald 2 Jahre alt. Gruss Walter -- View this message in context: http://gis.19327.n5.nabble.com/Massenumbenennung-Relationen-von-Multipolygon-in-Boundary-tp5650288p5656548.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 21.04.2012 19:41, schrieb Walter Nordmann: Wolfgang-4 wrote Bei Landkreisen sind normale Polygone noch handhabbar, bei Staatsgrenzen teilweise nicht mehr. Da macht es Sinn, die Umringe in eine Kette von Polygonen zu teilen, die nicht jeder immer laden muss. Das leistet das Multipolygon. jo, ganz deiner Meinung. Schau dir mal diese Relation an: http://www.openstreetmap.org/browse/relation/111 www.openstreetmap.org/browse/relation/111 Wenn type=boundary und type=multipolygon das gleiche sein sollen (vgl. [1]/[2] und div. Auffassungen der Liste), ist es ein herrliches Beispiel für die Verwendung verschachtelter Multipolygone: Alle Elemente in der outer-Rolle sind Relationen. Laut Definition [2] ist das kein gültiges Multipolygon, aber teilweise die Umsetzung dessen, worauf ich mich mit den Termini Flächenlinks und -netzwerk bezog. Wenn eine Landesgrenze in genügend viele Teilschnipsel zerlegt wird, steht auch dieser notwendigerweise eine ähnliche Erfassung bevor. Gleiches gilt für andere genügend große Gebiete, wie z.B. den Harz, wenn die Grenze nicht separat sondern über die Einzelflächengrenzen der landuses und roads erfasst wird. Umgehen ließe sich das nur, wenn man eine höhere Unschärfe in längeren Grenzen akzeptiert, also nicht die detailierten Grenzen durch Ansammlung recyclet, sondern separate, ungenauere osm-ways nutzt, die eine Annäherung ans Detail darstellen. Als Fläche ließe sich relation 111 jedenfalls mit aktuellen Tools (JOSM, etc.) nicht anzeigen, weil es kein gültiges Multipolygon ist - wenngleich es das IMHO sein könnte - die Verschachtelungstiefe liegt bei 1. Gruß Christian [1] http://wiki.openstreetmap.org/wiki/DE:Relation:boundary [2] http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20.04.2012 14:38, schrieb Martin Koppenhoefer: Andererseits könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden müssen. dann werden die eben der Reihe nach abgearbeitet. Davon bekommst Du normalerweise gar nichts mit, die DB spuckt das Ergebnis aus und fertig. Es gibt auch Sonderfälle die nicht per MP gelöst werden können. Beispiel: Gib mir alle deutschen Bundestrassenabschnitte. - Ein Abschnitt der B317 bei Lörrach verläuft (Zollfreie,Freigabe im Laufe des Jahres) über schweizer Gebiet und liegt damit ausserhalb der deutschen Grenze, hat aber keinerlei Verbindung (Fluchtwege nicht betrachtet) ans schweizer Strassennetz. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, Am Freitag, 20. April 2012 02:20:24 schrieb Christian Müller: Moin, ich mag in diesem Zusammenhang noch einmal kurz auf das Thema Flächennetzwerk zurückzukommen. Have a fun read.. Da hast du dir ja richtig Arbeit gemacht ;-) Am 19.04.2012 13:05, schrieb Wolfgang: -1 Das Multipolygon sollte rein Fläche bleiben, und Fläche sollte nur im Multipolygon erfasst werden. Wer was dazu sammeln will, kann das über eine site verbinden. Wieder das Thema Relationen verbiegen. Damit würdest Du z.B. sämtliche Parks als type=site Relationen erfassen, in denen Du dann die MP der Einzelflächen sammelst. Aber was ist überhaupt eine Einzelfläche? Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern verhindern, dass - das Multipolygon mit Elementen verwässert wird, die mit der Fläche nichts zu tun haben (place etc) und - die Flächenberechnung / Darstellung im Multipolygon konzentrieren (wenn sie komplizierter ist als ein einfacher Umring) Betrachten wir beispielsweise einen Schlosspark bestehend aus mehreren Teichen, Rabatten, Wiesen, etc. die im Park verteilt sind - das Schloss selbst steht auf einem Sockel im Zentrum des Parks. 1. MP - Teiche 2. MP - Rabatten 3. MP - Wiesen 4. MP - Sockel 5. MP - Schloss 6. Schlosspark-Verwaltung Wenn du das Schloss (mit Sockel :-) ) als nicht zum Schlosspark zugehöriig betrachtest, brauchst du in der Tat ein Multipolygon für den Park mit inner = Schlosssockel. Die Seen, Wiesen etc würde ich als zum Schlosspark zugehörig ansehen und nicht aus der Parkfläche ausschließen wollen. Die Seen werden natürlich extra gemappt und erhalten wegen der Inseln ein Multipolygon, wobei ein Multipolygon für alle Seen reicht. Da die ganze Fläche außer dem Schloss zum Schlosspark gehört, ist für den Renderer auch klar, dass die Inseln ebenfalls leisure=park zu rendern sind. Verwaltungsmäßig gehören sie sowieso zum Schlosspark. Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum Park gehört und 2. üblicherweise der Renderer damit klar kommt, die Wasserfläche hat insofern Vorrang. Für das Schloss würde mir eine einfaches Polygon mit building=castle/yes reichen. Beim Sockel kommt es drauf an, wie der aussieht. Das könnte ein building=sockel (?) sein. In dem Falle bekäme das Schloss dann den layer=1, denn es liegt ja tatsächlich auf dem Sockel. Jetzt haben wir ein Multipolygon für den Schlosspark, eins für die Seen, jeweils ein Polygon für den Sockel und das Schloss. Einzelheiten des Parks wie Rabatte etc erhalten einfache Polygone. Es ist eine reine Frage der Logig, dass sie, wenn gewünscht, über dem Park gerendert werden. Dass sie zum Park gehören, muss ggf. aus der Lage ermittelt werden. Wenn jemand eine Statistik aller Rosenbeete in den Schlossparks des Landes erstellen will, dann muss er eben abfragen, welche Beete sich räumlich in einem solchen Park befinden. Für die Verwaltung kommt eine Site hinzu, name = Staatliche Verwaltung der Beispielhaften Gärten, Schlösser und Seen, Members sind der Schlosspark, das Schloss und weitere Anlagen, die zu der Verwaltung gehören, sowie ggf. das Verwaltungsgebäude, das vermutlich in der Landeshauptstadt des Beispielhaften Freistaates steht. :-) [...] Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, wenn es um die Berechnung der Fläche geht, die sich aus den Einzelflächen der Kinder und Kindeskinder (..) ergibt. Schließlich sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..) interessant, die tatsächlich einen Beitrag zu Außen- oder Innenringen des nestedMP liefern. Ab einer bestimmten Schachtelungstiefe wird die Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht werden, also alle Relationen, die dann tatsächlich way-members als Mitglieder haben und nicht selbst ein nestedMP sind. Je tiefer dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr irrelevante members als relevante gibt. So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das Multipolygon überraschend einfach zu berechnen und gleichzeitig geschickt aufgebaut. Regel 1: Jeder Umring kann aus einer beliebigen Anzahl von Polygonen bestehen, dabei müssen Anfangs- und Endpunkte auf einander folgender Polygone identisch sein und der Umring als Ganzes ein geschlossenes Polygon ergeben Regel 2: Alle geschlossenen Polygone (Umringe), die innnerhalb eines geschlossenen Polygons liegen, bilden ein Loch in diesem, sie dürfen das äußere Polygon nicht berühren. Regel 3: Die Umringe werden geschachtelt und liegen in beliebiger Tiefe ineinander. Inner und Outer können, müssen aber nicht angegeben werden. Sie dienen der Übersicht des Mappers und können zur Fehlerkontrolle benutzt werden. Regel 4: Die
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 12:04 schrieb Wolfgang wolfg...@ivkasogis.de: Park mit inner = Schlosssockel. Die Seen, Wiesen etc würde ich als zum Schlosspark zugehörig ansehen und nicht aus der Parkfläche ausschließen wollen. +1 Beim Sockel kommt es drauf an, wie der aussieht. +1. Wenn es sich dabei eher um eine Terrasse handelt (d.h. massiv und unten nicht begehbar), dann würde ich die Stützmauern (ggf., also den Umriss des Sockels) als barrier=retaining_wall mappen, und für die Fläche oben ein Multipolygon mit highway=pedestrian, area=yes Wenn es dagegen ein begehbarer Sockel ist (also z.B. der Schlosskeller da drin ist), dann würde ich es als Teil des Schloss-buildings sehen, und evtl. als getrennntes building erfassen (wegen unterschiedlicher Stockwerksanzahl). Oder building part. Für die Verwaltung kommt eine Site hinzu, name = Staatliche Verwaltung der Beispielhaften Gärten, Schlösser und Seen, würde ich eher in operator als in name taggen. Eine Verwaltung ist keine site m.E. Solange das nur ein ganz einfaches geschlossenes Polygon ist, würde ich immer das benutzen. Sobald aber kompliziertere Gebilde auftreten, die entweder Löcher haben oder/und durch mehrere zusammenhängende Abschnitte sinnvollerweise definiert sind, sollte nur das Multipolygon für die Fläche genutzt werden. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20.04.2012 03:14, schrieb Martin Koppenhoefer: Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als auch für die zukünftige Pflege bei Daten im Vergleich zu einer site-relation als bunte Mischung aller möglichen Elemente und Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche beschreibt. Bei umfriedeten Grundstücken kann man z.B. einen (im einfachsten Fall) way für Zaun/Mauer haben, der dann als outer einer Multipolygon-relation dient, die das Gesamtareal beschreibt. Alles Darinliegende (Schloßteich, Blumenrabatte, Mülltonnen und Hundekottütensp...) ist dann automatisch erstmal Bestandteil, sofern man es nicht explizit als inner way wieder ausschließt, eine Site braucht man dazu nicht. Ich würde in die site (falls man sie überhaupt benötigt für das, was man abbilden will) dann auch nicht unbedingt alle Einzelteile reintun, sondern dieses Gesamtobjekt. Für so was wie die Teiche in einem Schloßpark würde ich keine eigene site-Relation anlegen. Die von Dir beobachtete Verschachtelung, die Du gerne mit Relationen abbilden willst, ergibt sich bereits geometrisch aus den Daten, auch ohne jegliche Relation. Das sie implizit durch mehrfach als Ringelemente verwendete ways vorhanden ist, war mir klar - das ist aber dennoch nicht das gleiche. Ich habe das Beispiel mit den Kreisgrenzen gebracht - für eine komplett innenliegende Kreisgrenze innerhalb eines Landes ist der Flächenbezug zwar herstellbar, aber ohne explizite Sammelrelation nur mit rechnerischem Aufwand. Der Unterschied nochmal dargestellt anhand des Schlossparks: Sammelvariante: Eine Anfrage nach den Teichgeometrien innerhalb des Schlossparks ist durch lookup in die Relation zu lösen. Boundary-Only-Variante: (also nur die outers des Schlossparks) Man benutzt die Grenze des Schlossparks zum Verschneiden und sucht sich in den verbleibenden Daten die Teiche raus. Bezogen auf einen kleineren Park ist der Aufwand für beide Varianten sicher vernachlässigbar. Für ein größeres Gebiet ergeben sich mit der Sammelvariante aber Vorteile - da man nicht verschneiden muss. Einen gedachten expliziten MP-Baum zu crawlen und alle Teilflächen ohne geometrische Berechnung zu ermitteln, dürfte abhängig vom Anwendungsfall die bessere Variante sein - manche Anwendungsfälle werden durch ein solches Netzwerk evtl. praktisch erst möglich. Es gibt natürlich auch Probleme: z.B. könnten die Relationen schlecht gepflegt sein und man erwischt nicht alle Ergebnisse, die man mit einem Verschnitt erhalten hätte. Andererseits könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden müssen. Mir ging es darum, aufzuzeigen, dass egal wie man das Kind nennt - type=collection, type=site, type=multipolygon - im Endeffekt über den Flächenbezug gesprochen wird. Ich habe jetzt nicht nachgeschaut, aber ich schätze Du findest Sammelrelationen aller Kreisgrenzen pro Bundesland - sie bilden genau das ab, was auch ein nestedMP abbilden würde. Gleiches gilt für beliebige Sammelrelationen, die Flächen auf die ein oder andere Weise sammeln und taggen. Momentan lungern die alle mehr oder weniger zusammenhangslos in der DB - würde man sich auf ein paar Regeln für die Verschachtelung einigen, könnten die alle mittels nestedMP verlinkt bestehen. Was Du als schlichtes Polygon beschreibst, ist das, was übrig bleibt, wenn man die Flächenlinks (nachgeordnete MP-Mitglieder) innerhalb des gedachten 6. MP meiner letzten mail entfernt. Der Zusammenhang zu den Kindern ist dann nicht mehr explizit erkennbar, allenfalls implizit geometrisch. Der Komplexitätsgrad aller Relationen ist dann gleich, sie sind alle gewöhnliche Multipolygone. Erhält ein Datenverwerter (e.g. renderer) diese MP, überlappen die Flächen nun - entweder der Schlosspark wird als monotone Fläche opaque über die Einzelflächen gezeichnet, oder darunter. Für einfache Sachen (etwa buildings on top of landuses) kriegt ein Renderer das per Regel hin, ob das aber für jeden denkbaren Fall von (sinnvoller) Verschachtelung der Fall ist? Die Verschachtelung entsteht schon implizit durch gewöhnliche MP. Um es festzuhalten: Die Überlappung kann dadurch entstehen, dass je nach Sicht auf eine Einzelfläche, sie entweder ein Loch innerhalb einer anderen Fläche (sie wäre dann nur deren Grenze), sie selbst eine Gesamtfläche, sie eine Teilfläche von einer oder mehrerer größerer Flächen darstellt. Je nachdem, welches Thema ein Renderer hat, müssen nicht alle Sichten auf diese Einzelfläche dargestellt werden. Wären Flächenlinks innerhalb der Relation vorhanden, könnte ein Datenverwerter allerdings durch die schiere Anwesenheit von Flächenlink-Mitgliedern erkennen, ob mehr Detail vorhanden ist. Ohne die Geometrie zu berechnen, ließe sich entscheiden, welche Flächen dann beispielsweise nicht opaque bzw. nur mit Namen gerendert werden. Zugegeben, das
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 14:01 schrieb Christian Müller cmu...@gmx.de: Am 20.04.2012 03:14, schrieb Martin Koppenhoefer: Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als auch für die zukünftige Pflege bei Daten im Vergleich zu einer site-relation als bunte Mischung aller möglichen Elemente und Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche beschreibt. Das sie implizit durch mehrfach als Ringelemente verwendete ways vorhanden ist, war mir klar - das ist aber dennoch nicht das gleiche. +1 Sammelvariante: Eine Anfrage nach den Teichgeometrien innerhalb des Schlossparks ist durch lookup in die Relation zu lösen. Boundary-Only-Variante: (also nur die outers des Schlossparks) Man benutzt die Grenze des Schlossparks zum Verschneiden und sucht sich in den verbleibenden Daten die Teiche raus. genau, funktioniert immer, sofern die Grenzen aussen geschlossen ist, erfordert keine Relationen, und findet alle Elemente, nicht nur die, die ein Mapper eingetragen hat. Ausserdem sind Datenbanken mit Geofunktionen u.a. genau für Anfragen dieser Art optimiert. Bezogen auf einen kleineren Park ist der Aufwand für beide Varianten sicher vernachlässigbar. Für ein größeres Gebiet ergeben sich mit der Sammelvariante aber Vorteile - da man nicht verschneiden muss. da man einer händisch erstellten und von zig Mappern (davon die überwiegende Menge keine Experten, manche auch Anfänger oder Wenigmapper, manche arbeiten auch mit Tools ohne Unterstützung für alle Relationen, d.h. sie sehen evtl. nicht einmal in ihrem Editor, dass ein Objekt, das sie bearbeiten evtl. Teil einer site-Relation ist, oder sie halten nichts von Site-Relationen und fügen ein Objekt das sie erstellen absichtlich nicht dazu, etc.) weiterbearbeiteten Relation sowieso nicht wirklich trauen kann, würde ich selbst wenn es die Relation gibt mich lieber auf die geographischen Gegebenheiten verlassen, als auf die Relationenzugehörigkeit einer site-Relation. Es gibt natürlich auch Probleme: z.B. könnten die Relationen schlecht gepflegt sein und man erwischt nicht alle Ergebnisse, die man mit einem Verschnitt erhalten hätte. +1, s.o. Andererseits könnte ein Verschnitt sehr komplex werden - wenn das MP aus mehreren Einzelflächen besteht, also mehrere Verschnitte berücksichtigt werden müssen. dann werden die eben der Reihe nach abgearbeitet. Davon bekommst Du normalerweise gar nichts mit, die DB spuckt das Ergebnis aus und fertig. Mir ging es darum, aufzuzeigen, dass egal wie man das Kind nennt - type=collection, type=site, type=multipolygon - im Endeffekt über den Flächenbezug gesprochen wird. -1, multipolygon unterscheidet sich hier von site und collection dadurch, dass es nur eine Fläche definiert, während die anderen eine Gruppe definieren, die nicht notwendigerweise räumlichen Bezug haben muss. Z.B. könnte man einer site-Relation ein Ticket-Office zuordnen, das ausserhalb der site liegt. Eine collection (und auch eine site) kann alles enthalten, nodes, ways, Flächen, Relationen. Theoretisch müsste eine Relation überhaupt keine Geometrie haben und könnte trotzdem Sinn machen (weil sie als member in einer anderen Relation sitzt. So was haben wir bisher allerdings nicht oder kaum in der db, und ist auch mit unseren (Editier-)Mitteln eher schwer in Schuss zu halten). Ich habe jetzt nicht nachgeschaut, aber ich schätze Du findest Sammelrelationen aller Kreisgrenzen pro Bundesland - sie bilden genau das ab, was auch ein nestedMP abbilden würde. das hoffe ich nicht, wäre ja komplett überflüssiger Ballast, ich denke aber, dass es üblicherweise auch nicht so ist. Erhält ein Datenverwerter (e.g. renderer) diese MP, überlappen die Flächen nun - entweder der Schlosspark wird als monotone Fläche opaque über die Einzelflächen gezeichnet, oder darunter. Für einfache Sachen (etwa buildings on top of landuses) kriegt ein Renderer das per Regel hin, ob das aber für jeden denkbaren Fall von (sinnvoller) Verschachtelung der Fall ist? hast Du Dich schonmal mit den Render-Regeln von Mapnik auseinandergesetzt? Da spielt es bei den Flächen kaum eine Rolle, wie die getaggt sind, die sortiert er nach Größe (innerhalb desselben Layers, nicht alle Flächen sind in einem Layer). Es gibt aber auch überhaupt keinen Grund, Flächen grundsätzlich gefüllt darzustellen, manches macht als Grenze mehr Sinn. Wie gerendert wird, hat mit der Dateneingabe also dem Modell, wie die Welt in der DB abgebildet wird, nicht so viel zu tun. Je nachdem, welches Thema ein Renderer hat, müssen nicht alle Sichten auf diese Einzelfläche dargestellt werden. Wären Flächenlinks innerhalb der Relation vorhanden, könnte ein Datenverwerter allerdings durch die schiere Anwesenheit von Flächenlink-Mitgliedern erkennen, ob mehr Detail vorhanden ist. mehr Detail von was? Dein Vorschlag zielt darauf hinaus, alles was sowieso schon über räumliche Bezüge verbunden ist, nochmal mit site- und collection-Relationen zu
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo Wolfgang, Am 20.04.2012 12:04, schrieb Wolfgang: Ich glaube, an dieser Stelle missverstanden zu sein. Solange es nur um zusammengehörige Flächen gleichen Typs geht, reicht das Multipolygon völlig aus. Ich will nicht Multipolygone durch Sites ersetzen, sondern verhindern, dass - das Multipolygon mit Elementen verwässert wird, die mit der Fläche nichts zu tun haben (place etc) und - die Flächenberechnung / Darstellung im Multipolygon konzentrieren (wenn sie komplizierter ist als ein einfacher Umring) Weshalb verwässern? Anhand der inner/outer Rolle, die nur durch ways besetzt werden darf, ist doch klar, was zur Flächenberechnung herangezogen wird. Weshalb fürchtest Du die Aufnahme weiterer Elemente in anderen Rollen? Oder geht es Dir nur um die Größe, auf die ein MP dann u.U. anwachsen kann? Die Seefläche wird nicht als Loch im Park definiert, weil sie 1. zum Park gehört und 2. üblicherweise der Renderer damit klar kommt, die Wasserfläche hat insofern Vorrang. Die Zugehörigkeiten fasse ich genauso auf wie Du - damit sind wir bei der Überlappung der Flächen angekommen. Das Beispiel wird von den jetzigen Renderern sicher erwartungsgemäß priorisiert und richtig dargestellt. Spätestens wenn sich landuse=* und leisure=* MPs überlappen, kann ich mir aber nicht mehr vorstellen, wie eine Renderregel das sinnvoll priorisieren will - Nehmen wir an ein kleinerer Stadtpark überlappt auf den Rand einer großflächigeren Wiese. Es ist durch geographische Gegebenheit zu erkennen, dass die Überlappungsfläche je nach Sichtweise beiden MP zugeordnet werden kann, also erfasst ein OSMler das auch so - in klassischen Karten würde man vermutlich im Überlappungsgebiet schraffieren oder punkten. Da das ganze sehr theoretisch ist, lohnt eine Fortsetzung an dieser Stelle vermutlich erst mit einem echten Beispiel. Belassen wir es also dabei.. Wenn jemand eine Statistik aller Rosenbeete in den Schlossparks des Landes erstellen will, dann muss er eben abfragen, welche Beete sich räumlich in einem solchen Park befinden. - Etwas in der Richtung hatte ich im Hinterkopf. Für komplexe Statistiken ist der Rechenaufwand über die räumlichen Abfragen evtl. unnötig hoch und wenn es viele Anwender gibt, die unabhängig voneinander die gleichen Statistiken erstellen, verschwendet man Energie ;.-) Ist es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn Schachtelungszusammenhänge explizit in den Relationen wären? Klar können wir uns auch von diversen Rechenzentren abhängig machen, aber eine intelligente Lösung ist das nicht, klingt eher wie brute force.. Leider sind verschachtelte MP-Relationen (nestedMP) unpraktikabel, wenn es um die Berechnung der Fläche geht, die sich aus den Einzelflächen der Kinder und Kindeskinder (..) ergibt. Schließlich sind nur die outer/inner Mitglieder der Kinder und Kindeskinder (..) interessant, die tatsächlich einen Beitrag zu Außen- oder Innenringen des nestedMP liefern. Ab einer bestimmten Schachtelungstiefe wird die Grenzbestimmung daher unbeherrschbar - um die Flächengrenze eines nestedMP zu ermitteln, müssten alle Blätter des MP-Baumes durchsucht werden, also alle Relationen, die dann tatsächlich way-members als Mitglieder haben und nicht selbst ein nestedMP sind. Je tiefer dieser Baum, desto höher die Wahrscheinlichkeit, dass es mehr irrelevante members als relevante gibt. So ganz kann ich deinen Ausführungen nicht folgen. Im Prinzip ist das Multipolygon überraschend einfach zu berechnen und gleichzeitig geschickt aufgebaut. Es ging um (gedachte) nested MP, in denen MP Mitglieder anderer MP sind - das ist bisher nicht erlaubt. Für die gewöhnlichen MP, stimme ich Dir zu - schicke Sache. Mir fällt auf, dass der Terminus geschachtelte MP auch für die durch alternierende inner / outer Ringe konstruierten MP verwendet wird - von diesen habe ich ausdrücklich nicht gesprochen - mir ging es um die Verschachtelung von Flächen verschiedenen Typs, weil sie logisch Teil einer oder mehrerer anderer Flächen sind. [...] Das heißt auch, dass nur die Umringe als Typ outer definiert werden dürfen, die tatsächlich vom Typ des Multipolygons sind. Ich verweise dann einfach immer auf http://wiki.openstreetmap.org/wiki/DE:Relation:multipolygon - spart Tipp-Arbeit ;-) Für Grenzen bietet sich das Multipolygon an - nicht um irgendwelche inner zu definieren, sondern weil es möglich ist, das outer aus einer größeren Anzahl von (nicht geschlossenen) Polygonen zu definieren, die zusammen einen geschlossenen Umring ergeben. Ähnlich wie bei der coastline hat es gewisse Vorteile, nicht immer den ganzen Umring der z.B. USA laden zu müssen. Die Landesgrenze ist ein MP, die Kreisgenzen jeweils auch. Wer die Hauptstadt, Verwaltungszentrale oder was auch immer da rein bringen will, kann das dann über die Site machen. Members sind dann das Multipolygon mit der Grenze und der place-Node der Zentrale. Land und Kreise untereinander brauchen
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Duerfte ich als unbeteiligter Dritter dem OP diesen Link empfehlen: http://en.wikipedia.org/wiki/Spatial_database Interessanterweise gibt es keine gute Uebersetzung dafuer und Wikipedia verlinkt es auch nicht zu einem deutsche Artikel. Wer den findet, kann ihn ja gerne mal posten. Ich glaube, die spezielle Eigenschaft dieser Art der Datenhaltung scheint hier unbekannt, was den merkwuerdigen Optimierungswillen hin zu 'billigeren' Anfragen mit expliziten site-Relationen ausloest. Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber ich habe es zumindest bisher immer angenommen. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 14:57 schrieb Ronnie Soak chaoschaos0...@googlemail.com: Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber ich habe es zumindest bisher immer angenommen. AFAIK ist die Haupt-db eine Postgres-db ohne PostGIS (das sind die spatial-Erweiterungen), während Mapnik z.B. eine Datenbank mit PostGIS verwendet (verwenden kann). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, On 04/20/2012 02:54 PM, Christian Müller wrote: Ist es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn Schachtelungszusammenhänge explizit in den Relationen wären? Als jemand, der mit solchen Fragen staendig in der Praxis umgeht, kann ich sagen: Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) Ich muss also in jedem Fall, wenn ich jetzt nicht gerade nur Christian Muellers Heimatort analysieren will, die geometrische Abfrage *zusaetzlich* zu etwaigen explizit modellierten Beziehungen machen. Daher spart mir die explizierte Modellierung nichts, egal, wie schoen sie in der Theorie waere. (Ich teile allerdings auch die Ansicht, dass sie selbst in der Theorie genauso schoen ist wie is_in, also gar nicht ,) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo nochmal, noch ein Nachtrag - für Statistiken, welche die implizite Variante der Flächenbezüge als Grundlage nutzen, wäre zwar auch ein Cache für aufwendig errechnete Ergebnisse denkbar - für einen solchen existieren aber m.W. in und um OSM weder Standards noch die Möglichkeit ihn sinnvoll zu teilen / publishen. Gibt es grob gedacht eine Kreuzung aus Nominatim und dem Relation Browser für das Browsen von Flächenbezügen? Evtl. gibt es da schon Ansätze in OSM Inspector oder anderen Validatoren. Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den OSM-Daten abgeleitete Daten bereitstellen? Die MapQuest-Dienste sind mir geläufig. Gruß und Dank, Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 17:27 schrieb Christian Müller cmu...@gmx.de: Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den OSM-Daten abgeleitete Daten bereitstellen? Die MapQuest-Dienste sind mir geläufig. Es gibt da diverse Dienste, neben den von Dir genannten (Overpass und Nominatim) kommen mir u.a. XAPI und ein Online-Datenbank-Interface in der Schweiz in den Sinn, aber sobald Du wirklich viele Abfragen machen willst, empfehle ich Dir, eine eigene Kopie der DB (bzw. eines Ausschnitts) aufzusetzen. Dazu gibt es div. Möglichkeiten und Varianten, das Wiki hat einiges an Anleitungen und Tipps parat, s.z.B. osm2pgsql im Wiki für eine räumliche DB mit einem thematischen Auszug (site wird davon allerdings ignoriert, Multipolygone sind unterstützt). Auch osmium (framework) oder osmosis (damit kannst Du u.a. die DB replizieren, es gibt aber verschiedene Schemata) oder imposm könnten evtl. für Dich interessant sein. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Du kannst mit dem Planet Dump die Daten in jede DB stopfen, wenn Du dir die Mühe machst einen Converter zu schreiben. Nochmal: Es geht nicht darum, alle automatisch ermittelbaren/herstellbaren Flächenbezüge, manuell zu erfassen, sondern nur die, welche dem Mapper sinnvoll erscheinen. Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu tun. Warum gehen davon eigentlich alle aus? Nicht immer stecken die zu verarbeitenden Daten in einer fetten DB, die bereitwillig rechnet. Gäbe es die Flächenbezüge in den Daten wären z.B. auch billige JavaScript Hacks denkbar, die dann client-seitig laufen, anstatt einen Server zu belasten.. Gruß Am 20.04.2012 14:57, schrieb Ronnie Soak: Duerfte ich als unbeteiligter Dritter dem OP diesen Link empfehlen: http://en.wikipedia.org/wiki/Spatial_database Interessanterweise gibt es keine gute Uebersetzung dafuer und Wikipedia verlinkt es auch nicht zu einem deutsche Artikel. Wer den findet, kann ihn ja gerne mal posten. Ich glaube, die spezielle Eigenschaft dieser Art der Datenhaltung scheint hier unbekannt, was den merkwuerdigen Optimierungswillen hin zu 'billigeren' Anfragen mit expliziten site-Relationen ausloest. Ich weiss ehrlich gesagt nicht, ob OSM wirklich so organisiert ist, aber ich habe es zumindest bisher immer angenommen. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20.04.2012 16:19, schrieb Frederik Ramm: Hallo, On 04/20/2012 02:54 PM, Christian Müller wrote: Ist es nicht gerade für die Erstellung solcher Statistiken von Vorteil, wenn Schachtelungszusammenhänge explizit in den Relationen wären? Als jemand, der mit solchen Fragen staendig in der Praxis umgeht, kann ich sagen: Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) Liegt vielleicht auch an der elitären Haltung, die man ihnen entgegenbringt, will man es erklären (nur so ein Gedanke..). Ich stimme Dir im Inhalt zu, die Form finde ich grauenhaft.. Ist halt leider so. Ich muss also in jedem Fall, wenn ich jetzt nicht gerade nur Christian Muellers Heimatort analysieren will, die geometrische Abfrage *zusaetzlich* zu etwaigen explizit modellierten Beziehungen machen. Daher spart mir die explizierte Modellierung nichts, egal, wie schoen sie in der Theorie waere. Prophetentum ist eigentlich nicht unser Metier, aber ich stimme ein in den Kanon, dass OSM vermutlich immer ein Sammelsorium an verschiedensten Ausdrucksmöglichkeiten für geographische Sachverhalte bleiben wird. Gruß Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20. April 2012 18:00 schrieb Christian Müller cmu...@gmx.de: Der Optimierungswille den Du ansprichst, hat nicht nur etwas mit DBs zu tun. Warum gehen davon eigentlich alle aus? Nicht immer stecken die zu verarbeitenden Daten in einer fetten DB, die bereitwillig rechnet. Gäbe es die Flächenbezüge in den Daten wären z.B. auch billige JavaScript Hacks denkbar, die dann client-seitig laufen, anstatt einen Server zu belasten.. Das stimmt, und wäre ein interessantes Thema für ein paralleles Projekt, wo man solche Bezüge aus der OSM db ableitet, und zum download bereitstellt. Man sollte aber nicht die Server des Gesamtprojekts, wo diese Bezüge bereits enthalten sind, --- wenn auch in einer Form, die eine gewisse Verarbeitung erfordert, um sie herauszubekommen --- damit belasten. Die Relationen würden sämtliche Nutzer der Daten (auch Mapper) zusätzlich belasten, jeden der ein Gebiet herunterlädt wo solche Dinge redundant explizit in speziellen Relationen stecken, und jeden, der dort die Daten irgendwie interpretieren oder weiterverarbeiten will, unabhängig davon, ob er das braucht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Am 20.04.2012 16:19, schrieb Frederik Ramm: Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) [...] Oder wir haben zu wenig gute How To Vids.. Vielleicht eine Youtube Hilfe in JOSM integrieren. Aber das feature nicht Video2Brain nennen, das ist m.W. ne Marke von einem größeren Buchverlag. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, Am Freitag, 20. April 2012 17:44:57 schrieb Martin Koppenhoefer: Am 20. April 2012 17:27 schrieb Christian Müller cmu...@gmx.de: Ist die Overpass API momentan die einzige Möglichkeit Daten-Queries zu tätigen, oder gibt es noch andere Dienste, die evtl. zusätzlich, aus den OSM-Daten abgeleitete Daten bereitstellen? Die MapQuest-Dienste sind mir geläufig. Es gibt da diverse Dienste, neben den von Dir genannten (Overpass und Nominatim) kommen mir u.a. XAPI und ein Online-Datenbank-Interface in der Schweiz in den Sinn, aber sobald Du wirklich viele Abfragen machen willst, empfehle ich Dir, eine eigene Kopie der DB (bzw. eines Ausschnitts) aufzusetzen. Dazu gibt es div. Möglichkeiten und Varianten, das Wiki hat einiges an Anleitungen und Tipps parat, s.z.B. osm2pgsql im Wiki für eine räumliche DB mit einem thematischen Auszug (site wird davon allerdings ignoriert, Multipolygone sind unterstützt). Auch osmium (framework) oder osmosis (damit kannst Du u.a. die DB replizieren, es gibt aber verschiedene Schemata) oder imposm könnten evtl. für Dich interessant sein. Für den Anfang würde ich osm2postgresql empfehlen. Da bekommt man den gewählten Ausschnitt, ohne dass da irgendwas rausgefiltert wird. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Hallo, On 04/20/2012 06:08 PM, Christian Müller wrote: Es ist 100% klar, dass ich mich nie darauf verlassen kann, dass unsere Mapper solche Schachtelungen eintragen. (Sie kriegen ja nicht mal geometrisch gueltige Polygone hin...) Liegt vielleicht auch an der elitären Haltung, die man ihnen entgegenbringt, will man es erklären (nur so ein Gedanke..). Ich stimme Dir im Inhalt zu, die Form finde ich grauenhaft.. Ist halt leider so. Du solltest das nicht als die Mapper sind alle bloede lesen, dann ist es auch nicht mehr grauenhaft. Es ist einfach eine Tatsache, dass an unserer Karte sehr viele Leute mitarbeiten, denen Informatikerdenken, denen abstrakte Modelle, ordentliche Datenstrukturen und so weiter nichts bedeuten und die sich in diese Welt nicht hineindenken koennen. Ein Stueck weit kann man durch clevere Editoren oder durch gute Howtos dafuer sorgen, dass auch solche Leute einen nuetzlichen Beitrag zum Projekt leisten koenen. Und in dem Masse, indem wir mehr Leute fuer zum Mitmachen gewinnen, werden wir in immer geek-fernere Bevoelkerungsschichten vorstossen. Vor dem Hintergrund ist es einfach voellig illusorisch, anzunehmen, man koennte irgendwann einen Zustand erreichen, in dem die Leute nicht bloss eine Grenzlinie zeichnen, nicht bloss einen geschlossenen Grenz-Way ziehen (was schon etwas komplizierter ist), nicht bloss ein schoenes Netz von Multipolygonen mit gemeinsam genutzten Kanten aufziehen (was nochmal diffiziler ist), sondern auch noch eine schoene explizite Hierarchie in das alles einbauen. Solche komplizierten Schemata muessen ja auch pflegbar sein. Das hat nichts damit zu tun, dass unsere Mapper Idioten sind; sie sind halt in zunehmendem Masse einfach Durchschnittsmenschen mit durchschnittlichen Faehigkeiten, und dazu muss auch unser Datenmodell passen. Denn *sonst* passiert genau das, was ab und zu mal in Beschwerden an die Data Working Group hochkocht, dass irgendwo einer muehevoll alles ordentlich und korrekt getaggt hat und die ganzen Neulinge mit boesen Mails verscheucht, die ihm seine Gegend kaputt machen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Frederik Ramm frede...@remote.org wrote: Solche komplizierten Schemata muessen ja auch pflegbar sein. +1 Die ÖPNV Relationen sind das beste Beispiel dafür, wie sich ein als möglichst umfassend und stimmig befundenes Oxomoa Schema einfach nicht durchsetzt. Selbst die Spezialisten mappen das Schema in zig Varianten. Die meisten örtlichen Mapper hingegen setzen intuitiv an die Stelle des Haltestellen-Schildes ein busstop und fertig. Denn genau diese Vokabel haben sie im Englisch-Unterricht oder als muttersprachliches Kind als Bezeichnung dafür gelernt. Wird eine Bushaltestelle verlegt, dann wird das Schild versetzt oder temporär ein anderes aufgestellt und das originale als ungültig gekennzeichnet. Dass jede Richtung einzeln gemappt wird, wird noch nahezu jedem klar. Aber dass zusätzlich zum busstop an der Stelle des Schildes noch ein Punkt auf der Straße gesetzt werden muss, erschließt sich den meisten nicht. Wenn sich aus der Schildstandort und dem Straßenverlauf in der Realität ergibt, wo der Bus hält, dann sollte das auch in OSM möglich sein. Und das kann dann auch nahezu jeder, der Karten versteht als abgebildete Realität verstehen. Auch Umsteigehaltestellen (als Relation) zusammenzufassen, dürfte nahezu jeder verstehen, der schon einmal umgestiegen ist. Ws nutzt OSM ein komplizertes Schema, wenn es nur wenige anwenden können? Möglicherweise muss man seine Freiheit, etwas mappen zu dürfen dann aufgeben, wenn es mehrfach so viele Mapper aus- als einschließt. Ergo: Die Modelle müssen so einfach und suggestiv wie möglich sein. Wenn ein Modell zu kompliziert wird, führe es nur dann ein, wenn Du ein allgemeinverständliches Editor Plugin dafür liefern kannst. Das hat nichts damit zu tun, dass unsere Mapper Idioten sind; Richtig! Denn nicht jeder macht den Computer zu einem seiner Lebensmittelpunkte. Es gibt tausend andere Dinge neben Multipolygonen etc, die man tun kann und dennoch ein lebenswertes Leben gestalten. Auch OSM-Geeks sind nicht zwangläufig deswegen blöd, wenn sie keine Gebinde aus Hunderten von Blumen herstellen, keine Pferde flüstern, keine 20 Kinder täglich neu begeistern, keinen LKW mit Anhänger rückwärts in eine 20 cm breitere Einfahrt setzen oder aus dem Stand einen Salto machen können. Aber genau diese Leute brauchen wir, wenn sie als Hobby beispielsweise geocachen, wandern, Boot-fahren, angeln oder radfahren. Die jeweils Anderen sind eben anders aber deswegen nicht dumm. Zurück zum multipolygon und zur boundary. Das multipolygon ist ein geometrisches Objekt und hat zunächst einmal wenig mit OSM zu tun. Was wir erfassen, ist eine Grenze, also boundary. Von daher wird es sich wesentlich weniger Mappern erschließen, warum ich an ein multipolygon Landkreis X dranpappen soll anstatt an ein boundary. Denn schließlich bezeichne ich auch keine curve mit Kirchstraße. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächennetzwerk cont. (reply zu Re: Massenumbenennung Relationen von Multipolygon in Boundary)
Viel einfacher für Mapper und Datenverwerter sowohl beim Anlegen als auch für die zukünftige Pflege bei Daten im Vergleich zu einer site-relation als bunte Mischung aller möglichen Elemente und Bestandteile ist ein schlichtes Polygon, das die Gesamtfläche beschreibt. Bei umfriedeten Grundstücken kann man z.B. einen (im einfachsten Fall) way für Zaun/Mauer haben, der dann als outer einer Multipolygon-relation dient, die das Gesamtareal beschreibt. Alles Darinliegende (Schloßteich, Blumenrabatte, Mülltonnen und Hundekottütensp...) ist dann automatisch erstmal Bestandteil, sofern man es nicht explizit als inner way wieder ausschließt, eine Site braucht man dazu nicht. Ich würde in die site (falls man sie überhaupt benötigt für das, was man abbilden will) dann auch nicht unbedingt alle Einzelteile reintun, sondern dieses Gesamtobjekt. Für so was wie die Teiche in einem Schloßpark würde ich keine eigene site-Relation anlegen. Die von Dir beobachtete Verschachtelung, die Du gerne mit Relationen abbilden willst, ergibt sich bereits geometrisch aus den Daten, auch ohne jegliche Relation. Je einfacher man zum gewünschten Ergebnis kommt, um so besser. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
