Derzeit wohl nicht anders machbar, aber auf die Dauer sehe ich in einem solchen Verfahren keinen Sinn. Allein schon um in Städten das Mappen übersichtlicher zu gestalten müsste eine Methode gefunden werden wie man mehrere Objekte an einem Node/Way taggen kann, wenn sie sich auch wirklich einen Node/Way teilen (wie es bei dieser Uhr der Fall wäre)
Naja, mir geht es eigentlich weniger um den Renderer. Ich möchte einfach die Realität so abbilden, wie sie ist. Das ist auch ein Anspruch, den andere hier im Forum immer wieder äußern.
Wenn irgendein Laden und eine Poststelle an exakt der gleichen Stelle vorhanden sind, dann will ich das auch in OSM so mappen. Das geht aber nicht. Ich muss Nodes nebeneinander setzen und zwar sowei auseinander, dass ich sie noch editieren kann.
Wenn sich eine Koordinate als ungenau erweist und verschoben werden muss, dann möchte ich nicht jedesmal ganze Node-Wolken verschieben müssen. 
Wie das nachher dargstellt wird und ob die Icons dann ordentlich nebeneinander liegen, ist mir erstmal wurscht. Das soll der Renderer erledigen und über kurz oder lang geht es sowieso nur noch im selektiv abschaltbaren Objekten (=Ebenen). Das statische Rendern aller Objekte (oder genau der Objekte, die der Programmierer des Renderers für sinnvoll hält) in eine Ebene wird nicht mehr lange Bestand haben - auch nicht bei den Standard-Renderern.
Nicht jeder der mal OSM benutzen möchte, wird sich dafür seinen eigenen Renderer installieren, wie das im Moment notwendig ist.
Ich hoffe, dass möglichst viele Briefkästen, Kanaldeckel und Hundebeutelspender gemappt werden. Dann steigt der Druck für neue Wege bei den Renderern. Aber jetzt sind wir schon wieder beim Grundsätzlichen. 
Genau so sehe ich das auch.
Aber im Moment gibt das Tagging es nicht her. Deswegen zur Zeit prinzipiell zwei (oder mehr) Nodes.
Detlef
Es ist möglich mehrere Objekte sauber getrennt an einen Node zu taggen…
Dazu muss man zwar Relationen missbrauchen, aber Programme die Relationen auswerten müssten die Objekte dennoch problemlos zuordnen können, da die Tags in der Hirarchie der Relationen klar den Nodes zugeordnet werden.
Folgendes Beispiel:
Node12345
- keine Tags, oder nur gemeinsame Tags
Relation1
- Getaggt mit den Tags für Objekt1
- hat Node12345 als Mitglied (und zwar nur den einen Node)
Relation2
- Getaggt mit den Tags für Objekt2
- hat ebenfalls nur Node12345 als Mitglied
Wenn es nach mir ginge, dann würde das Tagging von Nodes und Ways komplett abgeschafft, und für jedes Objekt eine Relation erstellt werden. Dann stellen Ways und Nodes nur die Geografie dar, und die Relationen die damit verbundenen Objekte. Das würde auch alle Probleme mit übereinander liegenden Ways, aneinander grenzenden Flächen, und so weiter, lösen.
Der Informatiker freut sich über eine vollständig normalisierte Datenbank. Leider blickt kein Mensch mehr durch, was jetzt eigentlich wo getaggt ist und ob er schon alle Relationen gefunden hat, die da mit reinspielen können. Ganz abgesehen von den Problemen wenn dasselbe Tag in mehreren Relationen vorkommt.
Zusammengehörende Tags an einem Node kapiert man wenigstens. Ich würde mal erwarten, daß unsere Software irgendwann mit nahe zusammenliegenden/aufeinanderliegenen Nodes besser umgehen kann - professionelle Navisoftware arbeitet grade dran.
bye
Nop
Stimmt. Das entspricht eigentlich genau dem Konzept,wie ich es mir vorstelle.
Aber:
Dieses ganze Relationsgefummel müsste von den Mapping-Programmen komlpett gekapselt werden. Und zwar so, dass auch Nichtinformatiker durchblicken.
Mir sind (trotz Informatiker) Relationen auch zu kompliziert. Aus diesem Grund habe ich noch keine angelegt und bestehende Relationen fasse ich nicht an. Das hat weniger mit grundsätzlichen Versändnisproblemen zu tun sondern ich hatte einfach bisher keine Lust, mir das reinzuziehen.
Das würde bedeuten, ein schlechtes Konzept per Software zu kaschieren. Das geht eine gewisse Zeit gut, dann bricht es zusammen. So wie man unstrukturierte Programme und Datenbanken irgendwann nicht mehr gepflegt bekommt bzw. der Pflegeaufwand Richtung Unendlich geht.
Detlef
Ich hab nicht behauptet, dass die Programme zur Zeit damit gut umgehen würden. Ein solches Konzept müsste natürlich ein Umdenken in der Programmstruktur zur Folge haben.
Potlatch ist da mal ein relativ gutes Beispiel wie das zuweisen der Relationen aussehen könnte. Dort erstellt man einfach eine Relation, und fügt die sozusagen wie einen Tag hinzu. Mit einem Klick darauf kann man dann die Tags der Relation bearbeiten. Beim hovern wird angezeigt was zur relation dazugehört. Sehr übersichtlich also…
Wenn das tagging von den Ways und Nodes getrennt wird, dann haben wir weniger durcheinander als jetzt. Das Konzept, die Linien und Nodes vom Tagging zu trennen, und Objekte per Relationen zu erfassen, wäre (zumindest wenn viele Details gemappt werden) viel einfacher zu verstehen, als das bestehende Konzept.
Solange Du nur eine Relation anschaust, wirkt es immer einfach. Der Spaß beginnt bei mehreren Relationen, die die gleichen Tags mit unterschiedlichen Werten haben.
Mit den Relationen ist eine Super Idee. Ich durfte heute schon dreimal meine Arbeit in die Tonne kippen, weil ich versuchte aus einem elendig langem und frei erfundenem Radweg, real existierende Wohnstraßen zu machen. Wenn da nur nicht gleich eine Relation dranhängen würde, die von Bayern bis an die Ostsee reicht.
In der Zwischenzeit fummeln da natürlich andere dran herum, die Version ändert sich und das ganze wird dann einfach abgewiesen. Da hilft auch kein händisches änder der Version, die API m,erkt auch unterschiede bei Wegen. Wenn nun jeder Kleinmist auch noch an einer Relation hängen würde, behindert sich jeder gegenseitig. Es ist dann reine Glückssache, einen Zeitpunkt zu erwischen, wo man exklusiv daran arbeitet. Ich versuche es dann mal morgen um 6 Uhr. Vielleicht habe ich ja Glück…
Also alles, bloß keine Relationskonstrukte für jeglichen Kleinscheiß. So wie das jetzt ist ist das auch gut so. Und gerade bei komplexen Dingen steigt keine Sau mehr durch. Viele trauen sich schon jetzt kaum an einfache Relationen heran oder versauen einiges beim Versuch damit zu arbeiten.
Das stimmt. Und irgendwann mappen nur noch ein paar wenige Informatiker. Mit steigender Komplexität wird die Anzahl der Mapper abnehmen.
Andererseits habe ich hier gerade versucht ein kleines Einkaufszentrum mit ein paar wenigen separaten Läden zu mappen. Da kommen ganz schnell mal 10 Nodes auf kleinstem Raum zusammen (eigentlich alle mit der gleichen Koordinate). Zumindest in Potlatch reicht der maximal Zoom schon nicht mehr aus. Und in JOSM sieht das auch nicht viel übersichtlicher aus.
Also so wie das jetzt ist, ist es eben leider nicht gut.
Detlef
Ich denke mal, dass Relationen im kleinen Massstab (Maximal Stadtgroesse) nicht so grosse Probleme machen duerften wie Relationen die ueber mehrere Bundeslaender gehen. Da die Wahrscheinlichkeit der Gleichzeitigen Bearbeitung stark sinken duerfte.
Aber meint ihr echt, dass Relationen so schwer zu verstehen sind fuer den Otto-Normal-Mapper?
Jau!
warum muß alles so kompliziert gemacht werden?
reicht es nicht aus, das zb. so zu gestallten:
amenity restaurant, biergarten yes
amenity hotel, restaurant yes
amenity einkaufszentrum, blumenladen yes usw.
mfg lutz
Ja!
Sowas wie hier? http://www.openstreetmap.org/?lat=51.18447&lon=11.92808&zoom=16&layers=B000FTF
Da habe ich eher das Problem mit den noch nicht vorhandenen Schlüsseln. In dem Fall fehlte mir die Spielothek, Modeschmuck, Juwelier, reine Lebensmittel wie Schokoladenverkauf… Und dann ist da noch ein Problem. Einige seit Ewigkeiten vorhandenen Schlüssel werden selbst weit und breit alleinstehend seit Jahren nicht gerendert. Und das bringt uns zum Hauptproblem.
Bei den Renderern schleift es einfach gewaltig. Es ist doch klar, dass dort keine Lösung kommt. Man hat daran schlicht noch nicht gerabeitet, so wie man es versäumt die Features auf dem aktuellen Stand zu halten.
Vieles ließe sich schon mit biligsten Mitteln lösen. Ein Beispiel. Aussischtspunkt, Infotafel, Bank auf 4 Quadratmetern. Der Punkt und die Bank hat einen Namen. Malt man hier für die Renderer, müsste man bescheißen. Wenn es dumm läuft braucht es 50m Abstand. Ist das erfassen vor Geodaten? Nein das ist liederliches hinklatschen wie das bei handelsüblichen Karten der Fall ist und OSM praktitisch überflüssig macht, da wir uns hier einen der riesen Vorteile von OSM selbst verbauen.
In dem Fall könnte man alles wunderbar an einen Node pappen. Die Software muss es nur richtig verwerten. Entweder malt sie sich für die Kombination eine Hilfstabelle in denen die Icons nebeneinander gelegt werden, oder man hinterlegt für den Anfang grafisch fertige Iconbalken an, die bei auftreten der Kombinationen gleich so gerendert werden können. Die Renderules sind ja quasi schon halbe Stylesheets. Und jetzt sage keiner, dass es so nicht geht. Das habe ich selbst mit meinen dürftigen Programmierkenntnissen dutzende male in PHP für Webseiten umgesetzt.
Wenn man daran wirklich nachweislich gearbeitet hat, das ganze wirklich aus rein technischen Gründen scheitern sollte, dann kann man sich mal über anderweitige Lösungen unterhalten. Ich bin aber definitiv nicht bereit, das aussitzen von Problemen auf dem Rücken der Mapper auszutragen. Schon garnicht in die Richtung mit komplizierten Hilfskonstrukten, die ein mitmachen für jeden zunichte machen wird.
Es arbeiten nicht auf einmal mehr Leute an einem Objekt, nur weil es als Relation getaggt wird…
Zur Zeit sind Relationen für Neueinsteiger schwer zu verstehen. Das wundert mich auch nicht. Es ist ein totales Tagging-Durcheinander. Vor allem bei Multipolygonen. Wenn man dort einfach die Relation taggen würde, dann wär das viel leichter zu verstehen.
Bei größeren Relationen in aktivem Gebiet habe ich quasi alle 5 Minuten einen Konflikt. Das merkt man erst seit API 0.6, da man hier schon an der Versionsnummer scheitert. Früher griff da höchstens nur Precondition.
Ich musste gestern händisch das modify aus dem File nehmen, die Relation also unangetastet lassen. Anderfalls wäre keine Bearbeitung möglich gewesen. Und bei immer mehr Mappern und noch mehr Relationen steigt die Gefahr sich zu behindern immer mehr. Das geht definitiv nicht gut.
Es scheitert schon an einfachen Relationen. Entweder lassen die viele gleich ganz sein und behelfen sich anders, oder es wird aus Unwissenheit versaut. Egal wie man den Mist nun nennen möge, viele werden sich nicht mehr rantrauen.
Definitiv. Der Otto-Normal-Mapper denkt maximal in Nodes und Wegen und Flächen. Ein bischen Geometrie hat jeder in der Schule mitbekommen. Relationen sind dagegen eine abstraktes Gebilde.
Neben dem Verständnisproblem kommt dazu noch die nicht gerade trivale Handhabung im Mapping-Tool.
Wie gesagt, ich habe nichts gegen Relationen als Organisationsobjekt in der Datenbank. Aber was habe ich als Mapper damit zu tun, wie die Datenbank organisiert ist?
Wir könnten ja mal einen Umfrage starten, welche Ausbildung die Mapper haben, die aktiv mit Relationen arbeiten. Und wieviel Prozent der Mapper das überhaupt sind.
Detlef
Verständnisfrage: Was meinst du mit “Relation taggen”?
Detlef
Na statt dem Way die Tags mitzugeben, einfach die Tags in die Relation schreiben. Das Problem ist nur, dass es momentan nicht gerendert wird.
Genauso wie es keine logischen Verknüpfungen oder Vererbungen gibt. Relationen sind einfach gesagt noch zu dumm um mehr damit anzustellen. Keine Software könnte derzeit unterscheiden ob denn nun die Landstraße, die Fahrradroute oder die Busrelation Priorität in der Darstellung hat. Deswegen taggen wir ja die Priorität Hardcode an den Weg, in dem Fall die Landstraße. Die road Relation ist derzeit nur tote Materie und nur für spezielle Auswertungen tauglich. Und auch dort beklagt man Darstellungsprobleme mit mancher Software. Die Cycle Map pennt ja bis heute bei Multipolygonen.
Mit Relationen hat man derzeit also rein garnichts gekonnt. Ob nun verdeckte POI’S oder Relationen, an beidem müsste man erstmal arbeiten um Probleme zu lösen.