Dann sag’s ich jetzt halt: Ich halte es für Grundfalsch, für dieselbe Sache mal ein Polygon mit Tags, mal mehrere Polygone mit Tags und eine Sammelrelation und mal eine Relation die wie ein Polygon interpretiert wird und Polygone ohne Tags zu verwenden.
Es wäre sinnvoller (und nicht allzu schwer) Objekte zu definieren, die alle drei Fälle auf verständliche Art ohne Wechsel der Perspektive darstellen können. Beispiel hab’ ich unter “maximale Größe eines MP” schon gepostet.
bye
Nop
Soweit ich weis, ist das Ziel ist nicht mehr die Produktion einer Datenbank zur Darstellung einer langweiligen, nur aus 5 Linientypen und sonst nur leeren Flächen bestehenden Autokarte, sondern die möglichst gute und realitätsnahe Abbildung der Realität auf die Datenbank. Da braucht man nun mal auch komplexere Strukturen, das bei deren Einsatz der Benutzer möglichst gut unterstützt werden sollte, ist natürlich auch klar.
Nein, man braucht keine sonderlich komplexe Struklturen. Davon hat keiner was. Je einfacher die Strukturen gehalten werden, um so leichter kommen damit die Mapper zurecht und umso leichter ist dann auch die automatische Auswertung. Alles, was uebermaessig kompliziert eingetragen wird, ist reines Ausleben des Spieltriebs von Geeks, die sich am Ende darueber freuen, wenn ihre Eintragungen trotz ihrer Komplexitaet noch von der einen oder anderen Anwendung als korrekt erkannt wird.
Da denken wir doch mal kurz drueber nach und stellen erstaunt fest, dass die gewuenschte Alternative rein logisch unmoeglich ist:
Da man einem Mapper nicht vorschreiben kann, welchen Editor er nutzt, kann man auch nicht sicherstellen, dass er bei bestimmten Aenderungen gewarnt wird.
Im Prinzip kann man seine Aenderungen ja auch in einem ASCII-Editor, und die API kann ja nur ueberpruefen, ob die hochgeladene Aenderung syntaktisch korrekt ist, aber nicht ob der Mapper wusste, was er da tat.
Gruss
Torsten
Nein, das ist kein Spieltrieb, weil zum Teil gibt es Situationen wo man mit komplexeren Strukturen, z.B. Relationen weiter kommt, als mit einfachen Objekten/Tags, wo sich man entweder entscheiden muß, weil die Tags kollidieren, oder man sich notgedrungen Konstruktionen wie z.B. highway=service + service:kerb:left:height=0.10 ausdenken muß, was bei highway=residential dann residential:kerb:left:height=0.03 ist. Jemand anderes hat vielleicht nur kerb=lowered an den Weg getaggt, weil er das einfacher fand. Wirklich zielführend sind beide Varianten nicht, weil bei der einfachen kerb=lowered fehlen Informationen, und die andere kann man bei ausreichender Tagwertevielfalt nicht mehr pratikabel verarbeiten, was aber ja das ist, was du gerne machen möchtest. Weil den Rollirouter interessieren die linken Bürgersteifhöhen bestimmt ganz brennend. Die einzige halbwegs saubere Lösung ist dann hier z.B. der gefürchtete straßenbeleitende Fuß-/Radweg (, ja, die noch bessere Variante alles als Fläche zu taggen ist aus Aufwands- und GPS-Präzisionsgründen unpraktikabel).
Zusätzlich benutzt dann wie im Moment der Nächste service=, um wie ja der Name klar sagt, die Art der Dienstleistung anzugeben, weil was hat denn service= für sich allein genommen, mit Straßen zu tun? Ja, genau nichts! Die Verbindungen zwischen den Keys, stellt also nur der Mensch her. In OSM sollte also aus diesem Grund der Keyname für sich alleine alles Notwendige eindeutig genug aussagen, aber an der Nichtbeachtung dieser Tatsache kranken im Moment diverse Taggingvorschläge und etablierte Tags. Das gibt dann also langfristig eine lustige Tagsuppe aus verschiedenen Interpretertionen implizierter Bedeutung ausgehend von anderen Nachbartags.
Gut, wir haben ja die “eindeutigen” Tagkategorien, wie z.B. highway=* (Ah, das sind also alles Straßen, bis auf z.B. highway=traffic_lights, das ist amenity=, ach nee, das ist besser power=, weil ich ja elektrisch…) oder emergency=* (siehe z.B. die AED-Diskussion…). War schon lustig, wo sich auf der Mailingliste damals die Bude wegen der Liste falsch geschriebener Straßennamen gemeldet hat, die erst mal alle name=-Tags von highway= als Straßennamen extrahiert hatten und so 70000 Fehler gefunden hatten, am Ende waren es dann noch etwas über 1000 potentieller (nur automatische Syntaxprüfung) Fehler.
Prizipiell macht ein konkreter Tag ja nur eine 1:1-Zuordnung oder 1:n für einen Key, aber das hilft eben nicht, wenn man eigentlich 1:n für einen speziellen Key haben möchte, wo man sich ja im Moment oft mit Sachen wie cuisine=chinese;kebab;pizza;fish behilft. Der Nächste taggt das gleiche als cuisine=chinese;kebab;fish;pizza und der Übernächste als cuisine=pizza;fish;chinese;kebab. Viel Spaß bei der großflächigen Auswertung! Insbesondere auch, wenn z.B. bei spezialisierten Kliniken schon mal so 10 Werte für healthcare:speciality=* geben kann. (Naja, die Compuetrindustrie muß ja auch von was leben…)
So das reicht fürs erste erst mal, gibt natürlich auch noch eine genauer Erläuterung zum Kategorieproblem, aber das kommt ein andermal.