Felder und äcker eintragen?

[Mirko_Küster]

@de_muur

Nein. Ich bin da ein anhaenger der Patch-Work-Fraktion. D.h. ich zerschneide auch grosse Waelder in handhabbare Teile. Da in “meinem Revier” auch andere taetig sind, habe ich schon haeufiger erlebt, wie jemand in 20km Entfernung von seiner eigentlich Aenderung was ausversehen kaputt gemacht. So grosse Elemente sind einfach nur unuebersichtlich und deshalb fuer die Zusammenarbeit vieler laien einfach nicht geeignet. Und wenn man einmal akzeptiert hat, dass man grundsaetzlich grosse Elemente manchmal zerschneiden muss, dann kann man das auch zum Wohle der Innenliegenden flaechen. Die zerschnittenen Flaechen markiere ich alle als outer-Polygone in einer gemeinsamen Relation. Falls ein Renderer das auswerten kann, dann erkennt er, dass die zusammengehoerne. und wenn er e nicht kann, so stellt er sie immerhin noch ordentlich als Einzelflaechen da.

Zerschnitten wird nur dann, wenn ich an eine Grenze stoße oder irgendwas getrennt werden muss. Es ist diese Atomisierung, vor allen bei Straßen, die ich gerade als suboptimal empfinde. Damit das irgendeiner etwas versaut muss man so oder so leben. Man müsste seinem Gebiet schon einen Schreibschutz verpassen. Verschlimmbesserungen würden auch beim setzen von einzelnen Bäumen passieren. Wenn da einer nicht sieht das die Fläche ein größerer Wald ist und das es irgendwo Probleme gibt, hat er sich das falsche Hobby ausgesucht. Es ist für mich logisch vor dem handeln zu schauen. Nur wird man auch mit Honks leben müssen. Das ist nunmal die Jedermann Karte.

Im gewissen Sinne ja. OSM sollte meiner Meinung nach nicht durch die Moeglichkeiten von JOSM definiert werden. So tauchen in JOSM durchaus auch Vorlagen auf, die nicht den Mapfeatures oder den Approvals entsprechen. Es ist natuerlich nicht verboten, sowas zu benutzen, aber im Sinne eines moeglichst konvergenten OSM verzichte ich darauf.

Wie schon geschrieben ist es mir völlig egal wie alles dahinter aussieht. Ich habe hier einen Haufen Daten die zu einer Karte werden sollen. Mein Job ist die Umsetzung. Wenn sich die Entwickler nicht einigen ist das schade. Nur kann man nicht ernsthaft verlangen bei jedem einzelnen Schritt eine riesige Recherche anzuleiern. Die endet dann ohnehin allzu oft mit wiedersprüchlichen Angaben. Letztendlich müsste man sich auch nur wieder selbst entscheiden. Und das wird im einzelnen genauso wenig einheitlich passieren. Die Chance das viele die einheitlichen Vorlagen in JOSM nutzen ist weitaus größer als das alle nach einer Recherche rein zufällig die gleiche Idee haben. Also kein einheitlicher Fahrplan, keine einheitliche Umsetzung möglich.

Anerkannt durch wen? Und die Nutzung ergibt sich ja haeufig erst dadurch, dass ein feature in JOSM eingebaut wird. Fuer meinen Geschmack ist das aber die falsche Vorgehensweise.

Durch Jammern ändert sich aber nichts. Multipolys wurden eingeführt und dementsprechend nutze ich die auch. Die Multis habe ich schon lange vor der Unterstützung in JOSM genutzt, eben weil ich sie im Wiki fand. In JOSM werden die ja erst seit kurzem unterstützt. Gleiches Problem wie einen Quote zuvor. Es ist deiner Ansicht nach vekehrt eine JOSM Vorlage zu nutzen, genauso aber ein Feature aus dem Wiki. An was soll man sich denn orientieren? An dem was deinem persöhnlichen Geschmack entspricht? Ok, dann überzeugst du hier vielleicht 5 Leute, bleiben noch immer 79995 Leute die ihr eigenes Ding machen und wovon viele irgendwelche unverbindlichen Richtlinen komkpß0lett ignorieren dürften. Wieder die gleiche Platte. Ohne klare Ansage ist jeder Versuch einer Vereinheitlichung definitiv schon im Ansatz gescheitert.

Naja, nur weil etwas dokumentiert und anerkannt ist, heisst das ja noch lange nicht, dass es gut ist. Und wenn ich etwas als schlecht erkenne, dann nutze ich es auch nicht. Unabhaenig davon ware es nateurlich schoen, wenn die multipolygon-Relationen ueberall sauber ausgewertet wuerden. Das ist aber nicht unbedingt eine Sache, dass die Entwickler das vergessen und man sie daran erinnern muss, z.T. gibt es auch druchaus handfeste technische Gruende, warum die Umsetzung scheitern kann. nebenbei bemerkt: Ich kenne kein einziges Tool, wo die multipoligon-Relationen wirklich komplett realisert worden sind. So aht Mapnik ja noch seine Probleme je nach Richtung der Polygone. Und auch Attribute muessen (faelschlicherweise) immer an das outer-Polygon geschrieben werden und werden nicht von der Relation selber uebernommen.

Woher soll ich denn wissen das dieses und jenes auf dem und dem Gerät vielleicht nicht fiunktioniert? Ich kann es nicht riechen. Ich bin Mapper, nicht Betatester, Entwickler oder was immer. Da hätte der Erfinder der Multipolys drauf achten müssen. Anscheinend hat er da geschlafen, die Kommunikation ist mal wieder gescheitert oder wie auch immer. Aber das kann doch dann nicht das Problem des Mappers sein. Wenn hier alles inkonsistent, inkompatibel usw. ist, muss man OSM leider den Bankrott erklären. Es gibts nichts verbindliches an was man sich sorgenfei halten könnte, einzig das wir Ways und Nodes zeichnen, danach gehen die Meinungen weit auseinander.

ICh denke eher, man muss sich damit abfinden, dass OSM nunmal nicht in Einerreihe maschiert wird, sondern man sich eher in mehr oder minder breiter Front in etwa in die gleiche Richtung bewegt. Wer mehr Praezision erwartet, duerfte auf absehbare zeit von OSM enttaeuscht werden.

Wobei das Schade ist. Das System könnte mit ein bisschen weniger Individualismus und etwas mehr Struktur zu einer großartigen Basis für freie und detailierte Geodaten werden. Grundkarte 5 Niveau wäre drin.

Yep, das ist ganz klar ein Bug im Validator. Allgemein bin ich ueber all die Qualitaetsverbesserunsgwerkzeuge nicht sonderlich gluecklich. Solange wir kaum/keine festen Regeln haben, kann man halt schwer entscheiden, was richtig oder falsch ist. Da kann dann ein Aussenstehender, der strickt nach dem Validator meint die Daten zu verbessern, schnell einiges an Schaden anrichten.

Wäre im grunde einfach zu lösen. Wege naher anderer ist nur für Objekte die dem Routing unterliegen relevant. Landuses etc, kann man generell aus der Prüfung herauslassen. Überschneidungen sind nur dann Überschneidungen, wenn sich die Wege kreuzen. Im Moment liegt aber bereits eine Überschneidung vor, wenn man die Flächen aneinander legt, die gleichen Nodes nutzt und so nur die die lückenlose Realität abbildet. Das muss doch auch auszuschließen sein.

Auch wenn du es so explizit nicht formuliert hast, so denke ich doch, von einer derartigen Optimierung sprechen zu koennen. So richtest du dich z.B. bei den Polygonen nach Mapnik und nicht nach der offiziellen Definition, nach der die Richtung egal waere. Und auch beim landuse=gras nutzt du eine Kennzeichnung, die vom Renderer dargestellt wird, aber in den offiziellen Feature-Listen nicht existiert. Auf der anderen Seite gibt es bei dir (soweit ich gesehen habe) z.B. kein Gestruepp/Buschland (natural=scrub), was Mapnik nun wieder nicht darstellet, obwohl es in den Mapfeatures definiert ist. Nun kenne ich deine Gegend nicht, aber ueberall wo ich bisher in Deutschland war, habe ich eigentlich Flaechen gesehen, die man am besten damit beschreiben koennte.

Mit Mapnik habe ich auch nur übernommen, weil es so in den Features stand. Und da die Richtung bei Landflächen ansonsten keine Relevanz hat, beißt sich das ander als z.B. Layer nicht. Ob ich nun zufällig gegen Uhrzeigersinn gezeichnet hätte oder deswegen einheitlich, es spielt keine wirkliche Rolle. Als ich anfing war landuse=gras noch offiziell, kam also auch zum Einsatz. Ist dann wohl vor kurzem wie üblich heimlich still und leise verschwunden. Mit dem Scrub tuhe ich mich ein wenig schwer, ist mir zu grob. Genauso wie mit den schon genannten Streuobstwiesen die man nirgends richtig einsortierten kann. Ebenso fehlen Alleen an Straßen die derzeit temporär einfach Waldstreifen sind. Ich hoffe da auf bessere Tags. Ansonsten kann man das ja noch immer ändern.