Felder und äcker eintragen?

de_muur · 2009-02-18T13:52:17.000Z

Mirko KÃ¼ster:

Aussehen könnte. Mangels einheitlicher Vorgehensweise, kann man nicht auf ein Ziel hin arbeiten.

Viele Wege fuehren nach Rom, Hauptsache man kommt ans Ziel.

Da fehlen sogar noch Parkflächen. Links und rechts der Wendelsteiner Straße sind ebenfalls Parkflächen. Es fehlt da noch ähnlich des Footways ein Tag. parking=booth/left/right/no. Die Buchten im Dichterviertel sind der typischen DDR Arbeiterviertel Bauweise geschuldet. Da wurde vor jedem Block eine Parkbucht für 5 bis 15 Fahrzeuge gebaut. Dazu kommen einzelne Garagenanlagen in der Nähe. Großflächige Parkgelegenheiten gibt es nicht. Das gibt bei der heutigen Autodichte immer wieder Probleme. Deswegen habe ich die Buchten alle markiert, bevor der Auswärtige mangels Überblick wie üblich irgendwo auf der Hauptstraße den Verkehr behindert.

amenity=parking sehe ich nicht unbedingt für Anliegerverkehr. Aber ok, ich kenne die Lage vor Ort nicht, mir viel das nur in der Karte auf, dass man da nahezu ueberall parken kann/soll.

Hier ein Ausschnitt aus meinem oben geposteten Gebiet.

Fuer meinen Geschmack koennten die einzelnen Gebiete kleiner zugeschnitten sein. Dann braucht man auch nur in Ausnahmefaellen die multipolygon-Relationen. Auch wenn es prinzipiell ordentlich markiert ist, in der Praxis halte ich solche Konstrukte naemlich fuer zu kompliziert und damit fuer zu fehleranfaellig. Dem urspruenglichen Ersteller ist (zumindest anfangs) zwar ganz klar, welche Gebiete letztendlich wo mit dazugehoeren, fuer einen Aussenstehenden (oder fuer den Ersteller nach einiger Zeit) ist das aber manchmal nur schwer zu durchschauen. Wenn es ordentliche Luftbilder gibt, dann probiere ich basierend darauf jedes Feld als einzelne Flaeche in OSM einzutragen. Das macht zwar erstmal eine ziemliche Arbeit, aber hey wir sind ja Tausende von Leuten, die sich die Arbeit teilen. Im Ergebnis erhaelt man dann aber eine ordentliche Grundlage fuer weitere Verfeinerungen (z.B. Einzeichnen von Graeben und Knicks, Unterscheidung von Aeckern und Weiden). Gruss Torsten

Rundling · 2009-02-18T14:10:43.000Z

de_muur wrote: Fuer meinen Geschmack koennten die einzelnen Gebiete kleiner zugeschnitten sein. Dann braucht man auch nur in Ausnahmefaellen die multipolygon-Relationen.

Jetzt fallen gleich die schwarzen Raben vom Himmel und zerpflücken Dir Deine Argunmente … Warte nur ein Weilchen …

Mirko_Küster · 2009-02-18T14:17:45.000Z

de_muur:

amenity=parking sehe ich nicht unbedingt für Anliegerverkehr. Aber ok, ich kenne die Lage vor Ort nicht, mir viel das nur in der Karte auf, dass man da nahezu ueberall parken kann/soll.

Ist eben kein Anlieger. Das Wohngebiet ist generell 30 Zone (alles maxspeed 30) aber es sind alles öffentliche Straßen mit Rechts vor Links, auch die Zufahrten zwischen den einzelnen Wöhnblöcken. Ich kann und will dort auch nichts taggen, was es in der Realität nicht gibt. Sollte unwahrscheinlicherweise die Schilderseuche einzug halten, wird das natürlich geändert. Aber bis dahin ist das so nur die Wiedergabe der realen Vorlage. Gleiches hatten wir ja schon bei den Feldwegen. Da stehen hier bei max. einem Prozent enstprechende Schilder. Der Rest hat kein agri etc. also wird das auch nicht getaggt. Hier vertraut man auf gesunden Menschenverstand und nicht auf die Schildbürger. Sollte dann dennoch ein Porschefahrer über einen Grade 4 abkürzen wollen, kann ich da nur owned sagen.

de_muur:

Wenn es ordentliche Luftbilder gibt, dann probiere ich basierend darauf jedes Feld als einzelne Flaeche in OSM einzutragen.

So habe ich anfangs begonnen und bin dann auf Multis umgestiegen. Ich fasse die Gebiete zwischen Straßen oder einem Fluß in Rastern zusammen. Dabei sollte ein Raster nie mehr als 500 Nodes im Outer haben. Getrennt durch einen Puffer, z.B. die Trasse der Straße. Darin alles was die Landwirtschaft durchschneidet. Der Grund war einfach. War in der Praxis nicht gerade schön. Wenn ich alles aneinander lege, habe ich dort großflächig das Überschneidungsproblem. War sehr undurchsichtig und schwierig zu bearbeiten. Mit einem Multipoly habe ich das nicht. Die berühren sich nur selbst oder die puffernde Trasse, welche die Raster trennt. So liegt innerhalb alles frei. Ich kann jederzeit einen inner hinzufügen, löschen oder ändern, ohne das ich mich um die angrenzenden Fläche sorgen muss. Das Problem der Pflege hast du so oder so. Eben durch eine fehlende einheitliche Vorgehensweise. Jeder macht es irgendwie anders. Man muss sich je nach Region und Bearbeiter also immer auf andere Umstände einstellen. Ich mache Multipolygon Raster. Ein anderer klatscht alles an die Wege, der nächste zieht um jeden Straßenblock ein Residential und wieder ein anderer legt Layer übereinender.

de_muur · 2009-02-18T17:27:34.000Z

Mirko KÃ¼ster:

Ist eben kein Anlieger.

Ich meine nicht die rechtliche Beschraenkung (gesperrt, Anlieger frei), sondern dass faktisch nur Leute dort parken, die auch genau dahin wollen. Was nuetzt es einem in der Karte, wenn da alle 100m eine Parkmoeglichkeit eingegtragen ist?

Wenn ich alles aneinander lege, habe ich dort großflächig das Überschneidungsproblem.

Kannst du das weiter erlaeutern? Wenn ich alles nebeneinanderlege, dann ueberschneidet sich da doch nichts.

War sehr undurchsichtig und schwierig zu bearbeiten.

Das mit dem schwieriger (im Sinne von aufwendiger) glaube ich. Aber undurchsichtig finde ich es nicht, da man ja immer alles im Blick hat. Bei groesseren Outer-Polygonen hat man das umschliessende Polygon haeufig gar nicht mehr auf dem Schirm, wenn man im Inneren was aendert. Da ist einem Fremden dann schnell nicht mehr klar, wie sich seine Aenderungen ein paar Kilometer weiter noch auswirken.

wieder ein anderer legt Layer übereinender.

Es gibt sicherlich verschiedene Wege, wie man ein und die selbe Sache in OSM eintragen kann. Und dann gibt es aber noch offensichtliche Fehler Gruss Torsten

Mirko_Küster · 2009-02-18T18:13:43.000Z

de_muur:

Ich meine nicht die rechtliche Beschraenkung (gesperrt, Anlieger frei), sondern dass faktisch nur Leute dort parken, die auch genau dahin wollen. Was nuetzt es einem in der Karte, wenn da alle 100m eine Parkmoeglichkeit eingegtragen ist?

Dahin wollen und frei sind zwei Kisten. Manchmal ist hier vorne alles zu, inklusive halbseitig Straße, hinter der Kurve ist aber frei. Das weiß ich, da ich hier wohne, der Auswärtige aber nicht. Der soll ja die Parkmöglichkeiten finden und nicht stundenlang suchen, am besten da wo nichts mit Parken ist. Die ganz raus zu lassen wäre auch wieder nicht richtig. Wer nicht alles abklappert sieht teilweise nur beidseitiges Parkverbot an den Straßen und fährt garnicht erst rein, parkt dann irgendwo wild.

Kannst du das weiter erlaeutern? Wenn ich alles nebeneinanderlege, dann ueberschneidet sich da doch nichts.

Nicht neben. Schau dir mal das Bild an. Ich nutze bei Landflächen die selben Knoten um Daten zu sparen und um Löcher zu vermeiden. Das nebeneinander habe ich auch probiert. War in der Praxis aber ebenso unschön und brachte die doppelte Datenenmenge an Knoten und zusätzliche Areas durch einzelne Äcker. Die spare ich durch einen großen Acker als Outer ein. Ich nutze immer das was die meiste Fläche besetzt als Outer. Draußen sind das die Äcker. Darin als Inner alles andere.

Das mit dem schwieriger (im Sinne von aufwendiger) glaube ich. Aber undurchsichtig finde ich es nicht, da man ja immer alles im Blick hat. Bei groesseren Outer-Polygonen hat man das umschliessende Polygon haeufig gar nicht mehr auf dem Schirm, wenn man im Inneren was aendert. Da ist einem Fremden dann schnell nicht mehr klar, wie sich seine Aenderungen ein paar Kilometer weiter noch auswirken.

Das Problem habe ich doch bei Relationen generell. 500 km Bundesstraße habe ich auch nicht mit einmal am Schirm. Outer wird doch komplett herunter geladen, der Rest darin wird aufgelistet, fehlendes als “unvollständig”. Ich mache doch keine 50 km breiten Teile. Den Rest kann man wie üblich nachladen und sieht alles gelistete auch dargestellt. Und wenn sich etwas im inneren ändert dann ist doch gerade bei der Umstzung kein Konflikt zu erwarten. Das sind ja eigenständige Flächen innerhalb einer großen Fläche, die verbindet nur ein Multipolygon mit der Rolle inner. Wenn ich nicht über einen anderen Inner hinweg zeichne, wirkt sich das nirgends aus. Fläche gegen den Uhrzeigersinn zeichnen, dem Multipolygon hinzufügen, role inner vergeben. Es ändert sich einzig die Anzahl dem Member der jeweiligen Relation, ansonsten nichts. Im grunde ist es ja im Moment auch vollkommen egal wie. Solange nicht eindeutig geklärt ist wie genau, kann jeder probieren wie er will. Für mich persöhnlich hat sich das durchgesetzt. Sollte man sich wieder erwarten offiziell auf etwas anderes einheitliches einigen, habe ich kein Problem das dann auch entsprechend anzupassen. Im Moment bin ich ohnehin Einzellkämpfer. Für die Ecke hat sich 4 Jahre lang keiner interessiert. Wird sich so schnell auch in Zukunft nicht ändern. 99% dort sind von mir. Beschwert hat sich auch noch keiner. Mal schauen was die Zukunft bringt.

Es gibt sicherlich verschiedene Wege, wie man ein und die selbe Sache in OSM eintragen kann. Und dann gibt es aber noch offensichtliche Fehler

Es gibt doch kein richtig und falsch. Ich persöhnlich sehe das auch als Fehler. Aber da wirst du immer einen Finden der das gut findet und anderen auch noch so beibringt. Solange das nicht offiziell und unwiderlegbar als böse gilt, wird auch das weiter praktiziert.

de_muur · 2009-02-19T07:24:41.000Z

Mirko KÃ¼ster:

Nicht neben. Schau dir mal das Bild an. Ich nutze bei Landflächen die selben Knoten um Daten zu sparen und um Löcher zu vermeiden.

So habe ich das ja auch verstanden. Aber wenn ich zwei Flaechen an den Grenzen die selben Knoten nutzen lasse, dann ueberschneidet sich da doch immer noch nichts, damit liegen sie doch weiterhin nebeneinander.

War in der Praxis aber ebenso unschön und brachte die doppelte Datenenmenge an Knoten und zusätzliche Areas durch einzelne Äcker. Die spare ich durch einen großen Acker als Outer ein. Ich nutze immer das was die meiste Fläche besetzt als Outer. Draußen sind das die Äcker. Darin als Inner alles andere.

Mit dem Argument koennte man logisch fortgesetzt auch ganz Deutschland als landuse=farm eintragen. Dann hat man schon mal eine Menge Daten gespart und waere zu xx% auch schon richtig. Letztendlich hat ein Acker hier mit einem in 2km Entfernung aber keinen Zusammenhang, so dass ich es als falsch empfinde, sie in der Datenbank als ein Element zusammenzufassen.

Das Problem habe ich doch bei Relationen generell. 500 km Bundesstraße habe ich auch nicht mit einmal am Schirm.

Auch da macht es ja immer wieder Probleme. allerdings passiert da nichts schlimemres, als dass die Relation kaputt geht. Jedes einzelne Mitglied ist fuer sich genommen ja ein korrekter Eintrag. Bei den multipolygon-Relation stimmt das leider nicht, ohne die Relation sind die outer-Polygone fehlerhaft, da sie eine Landnutzung an Stellen definieren, wo sie so in Wirklichkeit gar nicht ist.

Outer wird doch komplett herunter geladen, der Rest darin wird aufgelistet, fehlendes als “unvollständig”.

Das mag ja bei deinem Lieblingseditor so sein. Wenn ein anderer in “dein Revier” kommt, benutzt er aber vielleicht einen ganz anderen Editor.

Ich mache doch keine 50 km breiten Teile.

Andere Leute tun das aber mit den selben Argumenten wie bei dir.

Wenn ich nicht über einen anderen Inner hinweg zeichne, wirkt sich das nirgends aus.

Bei Mapnik und Osmarender vielleicht nicht, aber die Garminkarten bekommen deine Gegend mit all den ueberlagernden Elemente nicht mehr sauber dargestellt. (Sie kenne auch die multipolygon-Relation nicht, aber selbst die Zeichenprioritaet klappt da nicht mehr.)

Im grunde ist es ja im Moment auch vollkommen egal wie. Solange nicht eindeutig geklärt ist wie genau, kann jeder probieren wie er will. Für mich persöhnlich hat sich das durchgesetzt. Sollte man sich wieder erwarten offiziell auf etwas anderes einheitliches einigen, habe ich kein Problem das dann auch entsprechend anzupassen. Im Moment bin ich ohnehin Einzellkämpfer. Für die Ecke hat sich 4 Jahre lang keiner interessiert. Wird sich so schnell auch in Zukunft nicht ändern. 99% dort sind von mir. Beschwert hat sich auch noch keiner. Mal schauen was die Zukunft bringt.

Ich habe auch bestimmt nicht vor, dir vorzuschreiben, wie du was zu machen hast. Einerseits bin ich gerne bereit, von der Zeichentechnik anderer zu lernen. (Mein eigener Stil hat sich im Laufe der Zeit durchaus weiterentwickelt. und ich denke, dass dieser prozess auch noch nicht abgeschlossen ist.) Auf der anderen Seite betrachte ich solche Diskussionen auch als Lobby-Arbeit, damit sich auch ohne verbindliche Vorgaben ein einheitliches Vorgehen bei OSM weitgehend durchsetzt. So setze ich ich als Massstab fuer “korrektes” Tagging die englischen Mapfeatures an. Die scheinen mir am Besten von der Gemeinschaft kontrolliert, und bei der deutschen Uebersetzung gibt es z.T. schon deutliche Abweichungen. Fuer weitere Details halte ich mich dann an die entsprechenden Wiki-Seiten, auch da bevorzugt die englischsprachige Version. Daraus wuerden sich fuer dein Gebiet folgende “Probleme” ergeben: - landuse=gras gibt es nicht, stattdessen waere wohl landuse=meadow angebracht. - die Richtung der inner-Polygone sollte egal sein (das mit dem Gegendenuhrzeigersinn ist allein ein Hack fuer Mapnik) - der Rand eines inner-Polygon sollte nicht den Rand des outer-Polygon beruehren (steht so allerdings nur auf der Diskussionsseite) Trotzallem sieht dein Gebiet bei Mapnik und Osmarender sehr gut aus. Offensichtlich ist dein Stil auf diese Ausgaben hin erfolgreich optimiert. Gruss Torsten

Mirko_Küster · 2009-02-19T12:35:12.000Z

de_muur:

So habe ich das ja auch verstanden. Aber wenn ich zwei Flaechen an den Grenzen die selben Knoten nutzen lasse, dann ueberschneidet sich da doch immer noch nichts, damit liegen sie doch weiterhin nebeneinander.

Technisch liegen die Linien aufeinander, das geleiche wie wenn ich Flächen direkt an die Straßen hänge. Selektieren geht dann nur über Tastenklombination oder temporäres rausziehen eines virtuellen Knoten. Genau das wollte ich aber wo es nur geht vermeiden. Es sollte frei liegen um direkt angeklickt werden zu können.

Mit dem Argument koennte man logisch fortgesetzt auch ganz Deutschland als landuse=farm eintragen. Dann hat man schon mal eine Menge Daten gespart und waere zu xx% auch schon richtig. Letztendlich hat ein Acker hier mit einem in 2km Entfernung aber keinen Zusammenhang, so dass ich es als falsch empfinde, sie in der Datenbank als ein Element zusammenzufassen.

Könnte man, war aber nie das Ziel. Ziel war es das ganze an geeigneten Stellen zusammen zu fassen ohne zu riesig zu werden, keine Verbindung mit Objekten, Daten einsparen und leichtes selektieren ohne Überschneidungen. Im grunde schon. Solange wir nicht fein nach Operator Bauer, Flurstück, Roggen, Weizen, Mais etc. unterscheiden, ist das alles nur schlichter Acker. In meinem Fall könnte ich da noch weiter gehen. Das ist alles Überschwemmungsfläche, zwischen Unstrut und Flutkanal eingedämmter Polder. Desshalb auch die Mahlbusen und Schöpfwerke am Kanal.

Auch da macht es ja immer wieder Probleme. allerdings passiert da nichts schlimemres, als dass die Relation kaputt geht. Jedes einzelne Mitglied ist fuer sich genommen ja ein korrekter Eintrag. Bei den multipolygon-Relation stimmt das leider nicht, ohne die Relation sind die outer-Polygone fehlerhaft, da sie eine Landnutzung an Stellen definieren, wo sie so in Wirklichkeit gar nicht ist.

Dann muss man die Multis lassen, wenn es am User scheitert. Bei großen Waldflächen hat man auch keine Wahl. Die sind um einiges größer als meine Raster. Nur wie willst du ohne Multi große Wälder mit teilweise mehreren Teilen und vielen innenliegenden Flächen umsetzen? Das läuft dann wieder auf natural=water layer=1 hinaus.

Das mag ja bei deinem Lieblingseditor so sein. Wenn ein anderer in “dein Revier” kommt, benutzt er aber vielleicht einen ganz anderen Editor.

Also nutze ich die Funktionen von JOSM nicht, weil andere Entwickler bei ihren Tools nichts entsprechendes anbieten? Dann kann ich auch nicht Detailreich mappen, weil Potlatch sich sonst schnell mal aufhängt. Das ist für mich ehrlich gesagt die Baustelle der jeweiligen Entwickler. Die Nutzung verbreiteter und anerkannter Features sollte nicht am Entwicklungsstau einzelner swcheitern

Andere Leute tun das aber mit den selben Argumenten wie bei dir.

Da habe ich keinen Einfluss drauf. Ohne einheitliche Regelungen wie gesagt auch nicht zu ändern.

Bei Mapnik und Osmarender vielleicht nicht, aber die Garminkarten bekommen deine Gegend mit all den ueberlagernden Elemente nicht mehr sauber dargestellt. (Sie kenne auch die multipolygon-Relation nicht, aber selbst die Zeichenprioritaet klappt da nicht mehr.)

Auch die Cycle Map hat da anscheinend Propbleme. Nur ich nutze hier ein dokumentiertes und anerkanntes Feature und kein Proposal oder gar Eigenkreation. Auch hier ist das die Baustelle der Entwickler. Da gibts nur zwei Wege. Entweder schaffe ich die Multis ab, oder ich erinnere die Entwickler daran, solche Features endlich zu unterstützen. Ich habe kein Garmin, kann das jetzt nicht nachvollziehen.

Ich habe auch bestimmt nicht vor, dir vorzuschreiben, wie du was zu machen hast. Einerseits bin ich gerne bereit, von der Zeichentechnik anderer zu lernen. (Mein eigener Stil hat sich im Laufe der Zeit durchaus weiterentwickelt. und ich denke, dass dieser prozess auch noch nicht abgeschlossen ist.) Auf der anderen Seite betrachte ich solche Diskussionen auch als Lobby-Arbeit, damit sich auch ohne verbindliche Vorgaben ein einheitliches Vorgehen bei OSM weitgehend durchsetzt.

Der Prozess hat nie ein Ende. Ich probiere im Schnitt jede Woche mal etwas anderes aus. So bin ich letztendlich auch zu den Multis gekommen. Sollte etwas besseres kommen, wird auch da wieder probiert. Du wirst 80.000 + X Leute ohne klare Ansage nie auf eine Linie bekommen. Grundsätzlich sind sich ja alle einig. Wir malen eine freie Weltkarte. Im Detail geht es dann aber doch weit auseinander. Teilweise arbeiten hier grundverschiedene Leute zusammen. Das fängt beim Puristen an der sich am liebsten alles selber strickt und mit einem Atari online geht und endet beim Web 2.0 Junkie der ohne GUI komplett geliefert ist. Idealisten die nur reine freie Software nutzen und kommerziell hassen, Pragmatiker die das Ziel vor Augen haben und denen die Geschichte oder der Hintergrund der Software egal ist usw. Also alles Individuen mit eigenen Vorstellungen. Man muss entscheiden was richtig und was falsch ist. Ansonsten wird immer aus der Reihe getanzt. Wenn wir uns einigen ist das zwar irgendwo ein Fortschritt. Nur müsstest du noch 79998 andere überzeugen, die ungeachtet unserer Einigkeit ihr eigenes Ding durchziehen. Ich hoffe du hast dir die nächsten zwei Jahrtausende nichts vorgenommen.

So setze ich ich als Massstab fuer “korrektes” Tagging die englischen Mapfeatures an. Die scheinen mir am Besten von der Gemeinschaft kontrolliert, und bei der deutschen Uebersetzung gibt es z.T. schon deutliche Abweichungen. Fuer weitere Details halte ich mich dann an die entsprechenden Wiki-Seiten, auch da bevorzugt die englischsprachige Version.

Der nächste hält sich an die deutschen und baut deine Arbeit danach um. Da haben wir es wieder. Also altes Lied, bringt das Wiki auf einen Stand, ansonsten ist alles vergebens.

Daraus wuerden sich fuer dein Gebiet folgende “Probleme” ergeben: - landuse=gras gibt es nicht, stattdessen waere wohl landuse=meadow angebracht. - die Richtung der inner-Polygone sollte egal sein (das mit dem Gegendenuhrzeigersinn ist allein ein Hack fuer Mapnik) - der Rand eines inner-Polygon sollte nicht den Rand des outer-Polygon beruehren (steht so allerdings nur auf der Diskussionsseite)

Ob Wiese, Weide oder Flur. Ohne richtige Unterscheidung alles nur Gras. Kann man in meadow umtaggen, nur sagt das auch nicht viel mehr aus. Interesannt wird es erst wenn wir richtige konkrete Tags hätten. Streuobstwiesen etc. Mit dem Linksherum ist in der Tat nach der Empfehlung für Mappnik. Und da dort die Richtungen im Moment keine Rolle spielen, tut das im Moment auch nicht weh. Ausser Adrian Monk, dürfte es keinen stören. Mit dem Rand kenne ich, wird ja auch angemeckert. Nur ohne Multi meckert er genauso über nahe Wege oder überlappende Flächen. Ich möchte aber nicht den Validator befriedigen, sondern die Realität abbilden und da beginnt der Grünstreifen des Feldweges direkt an der Trasse der Landstraße, nicht Validatorfeundlich mit 15m Abstand. Und oft spart es Unmengen an Daten, wenn man auch ein Objekt am Rand als innner nutzt, anstatt mit tausend zusätzlichen Nodes um die Fläche herum zu gehen. Irgendwo hast immer etwas was irgendwo anschließt. Bliebe wirklich nur jede Fläche einzeln zu zeichnen.

Trotzallem sieht dein Gebiet bei Mapnik und Osmarender sehr gut aus. Offensichtlich ist dein Stil auf diese Ausgaben hin erfolgreich optimiert.

Dabei ist das ja garnicht für die Renderer optimiert. Ich habe nur das genutzt was die offiziellen Features vorsehen und im einzelnen so umgesetzt, das es für mich optimal zu bearbeiten ist. Das es so anscheinend auch super mit Renderern klappt, ist da nur ein positiver Effekt.

de_muur · 2009-02-20T10:24:45.000Z

Mirko KÃ¼ster:

Bei großen Waldflächen hat man auch keine Wahl. Die sind um einiges größer als meine Raster. Nur wie willst du ohne Multi große Wälder mit teilweise mehreren Teilen und vielen innenliegenden Flächen umsetzen? Das läuft dann wieder auf natural=water layer=1 hinaus.

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.

Also nutze ich die Funktionen von JOSM nicht, weil andere Entwickler bei ihren Tools nichts entsprechendes anbieten? Dann kann ich auch nicht Detailreich mappen, weil Potlatch sich sonst schnell mal aufhängt.

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.

Die Nutzung verbreiteter und anerkannter Features sollte nicht am Entwicklungsstau einzelner swcheiter

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.

Auch die Cycle Map hat da anscheinend Propbleme. Nur ich nutze hier ein dokumentiertes und anerkanntes Feature und kein Proposal oder gar Eigenkreation. Auch hier ist das die Baustelle der Entwickler. Da gibts nur zwei Wege. Entweder schaffe ich die Multis ab, oder ich erinnere die Entwickler daran, solche Features endlich zu unterstützen. Ich habe kein Garmin, kann das jetzt nicht nachvollziehen.

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.

Man muss entscheiden was richtig und was falsch ist. Ansonsten wird immer aus der Reihe getanzt.

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.

Ich möchte aber nicht den Validator befriedigen, sondern die Realität abbilden und da beginnt der Grünstreifen des Feldweges direkt an der Trasse der Landstraße, nicht Validatorfeundlich mit 15m Abstand.

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.

Dabei ist das ja garnicht für die Renderer optimiert. Ich habe nur das genutzt was die offiziellen Features vorsehen und im einzelnen so umgesetzt, das es für mich optimal zu bearbeiten ist. Das es so anscheinend auch super mit Renderern klappt, ist da nur ein positiver Effekt.

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. Also auch wenn du es nicht vorsetzlich so machst, so scheint die Entwicklung deines Mappings doch daran ausgerichtet, wie anschliessend das Ergebniss bei den Renderern aussieht. Ist ja auch ein legitimer Ansatz. Gruss Torsten

Mirko_Küster · 2009-02-20T12:45:19.000Z

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.

Markus_B · 2009-02-22T23:34:50.000Z

Hallo …,

rurseekatze:

ich bin zur Zeit damit besch?ftigt, in der Oberpfalz Stra?en, W?lder, usw. von der Luftbildern abzuzeichnen.

Schön dass du mitmachst! Die Arbeit in der Oberpfalz ist richtig erfolgreich.

landwirtschaftlich genutzte Fl?chen wie ?cker, Weiden, Felder nie als Fl?che

Da sprichst Du ein Grundproblem an… Wir erfüllen ja zwei Aufgaben, die direkt zusammenhängen: 1. Geo-Daten sammeln 2. daraus eine Karte zeichnen Eine Karte erfüllt nur dann ihren Zweck, wenn die wesentlichen Daten schnell und sicher erkannt werden können. Deshalb ist eine Karte immer generalisiert. Beispielsweise lässt man alle Flächen weiss, die keine wesentliche Information zeigen. In Mitteleuropa also “landwirtschaftliche Flächen”, also alles was weder Wasser, Siedlung oder Wald ist, und hebt nur besondere Flächen hervor, beispielsweise Friedhof, Park, Sportplatz. Wenn man nun jeden Acker einfärben, oder gar je nach Fruchtfolge unterschiedlich darstellen würde, bekäme man einen gräuslichen Fleckenteppich als Karte, in der das Auge nicht mehr fähig wäre, das Wesentliche vom Unwesentlichen zu unterscheiden. Anders ist es natürlich in einer Spezialkarte. So unterscheidet das Forstministeium einzelne Baumarten im Wald, und das Landwirtschaftsministerium Getreide von Futtermittel und Weide von Brachland etc. Das ist dann aber in jeder Saison anders und es ist unsinnig, wenn wir Städter versuchen würden Fruchtfolgen nach Luftbildern zu dokumentieren. Also bitte: keine “landwirtschaftlichen Flächen” eintragen. Gruss, Markus

Mirko_Küster · 2009-02-22T23:58:09.000Z

Markus B:

Anders ist es natürlich in einer Spezialkarte. So unterscheidet das Forstministeium einzelne Baumarten im Wald, und das Landwirtschaftsministerium Getreide von Futtermittel und Weide von Brachland etc. Das ist dann aber in jeder Saison anders und es ist unsinnig, wenn wir Städter versuchen würden Fruchtfolgen nach Luftbildern zu dokumentieren. … Also bitte: keine “landwirtschaftlichen Flächen” eintragen.

Deswegen sind Datenbank und Renderer zwei verschiednene Kisten. Die Datenbank kann erstmal alles an Informationen haben. Die Renderer entscheiden dann was dargestellt wird und was nicht. So wie die Layer der LVA. Die können weiße Topos genauso wie Grundkarte Landwirtschaft. Wenn einer eine spezielle Topo möchte, kann er die Landnutzung nach seiner Vorstellung darstellen oder auch ganz ausblenden. Also alles was möglich ist auch eintragen. Die Darstellung ist Renderersache. Ansonsten bräuchten wir die Tags nicht.

de_muur · 2009-02-23T07:15:39.000Z

Markus B:

Deshalb ist eine Karte immer generalisiert. Beispielsweise lässt man alle Flächen weiss, die keine wesentliche Information zeigen. In Mitteleuropa also “landwirtschaftliche Flächen”, also alles was weder Wasser, Siedlung oder Wald ist, und hebt nur besondere Flächen hervor, beispielsweise Friedhof, Park, Sportplatz.

Nein. Die Standard-Flaecheninformation in OSM ist nicht “landwirtschaftliche Nutzflaeche” sondern “ich weiss nicht, was da ist”. Insofern ist ersteres auch eine wesentliche Information. Das das nachher in der Karte brauchbar dargestellt wird, braucht den Mapper dabei nicht interessieren. Ggf. koennen die Renderer die Information in der Anzeige ja auch weglassen, wobei ich aber nicht das Gefuehl habe, dass Mapnik oder Osmarender mit der jetzigen Darstellung einen schlechten Job machen. Also von mir die Bitte, alle Nutzungen moeglichst flaechendeckend einzutragen. Gruss Torsten PS: Nach der etwas laengeren Diskussion zwischen mir und Mirko wird das hier sowieso kaum noch einer lesen.

sabmatt54 · 2009-02-23T08:50:10.000Z

de_muur:

PS: Nach der etwas laengeren Diskussion zwischen mir und Mirko wird das hier sowieso kaum noch einer lesen.

Da irrst du, ich habs gelesen und bin der gleichen Meinung! Als ich mit OSM anfing, war ich mir nicht sicher, ob es Sinn macht, alle möglichen Gegebenheiten und Informationen zu taggen. Mittlerweile stehe ich auf dem Standpunkt, dass möglichst viel aufgenommen werden sollte. Die Interessen sind so vielschichtig, dass sich keiner anmaßen sollte zu bestimmen, was wichtig oder unwichtig ist. OSM kann für alle möglichen Aufgabengebiete interessant sein. Als viel bedeutender finde ich es darauf zu achten, dass gleiche Gegebenheiten an verschiedenen Orten möglichst einheitlich getaggt werden. Gruß Matthias

Rundling · 2009-02-23T09:15:09.000Z

sabmatt54 wrote: Die Interessen sind so vielschichtig, dass sich keiner anmaßen sollte zu bestimmen, was wichtig oder unwichtig ist.

@sabmatt54 Danke. Klare Worte, klare Linie, so wollen/sollten wir es machen.

de_muur wrote: Also von mir die Bitte, alle Nutzungen moeglichst flaechendeckend einzutragen.

@de_murr Auch hier gilt meine volle Zustimmung.

Markus_B · 2009-02-25T19:40:06.000Z

Hallo Mirko,

Mirko Küster:

Datenbank und Renderer sind zwei verschiednene Kisten

“Im Prinzip ja - aber…” - den Nutzer interessiert nur das was er nutzen kann, also das was in der Karte erscheint. - Karte und die darin dargestellten Daten sind ein Ganzes, sie machen nur gemeinsam Sinn. - “der Renderer” weiss nicht was der Datensammler meint, sondern stellt einfach mal alles dar was häufig vorkommt. Deshalb brauchen wir dringend eine effiziente Kommunikation zwischen Datensammler, “Renderer” und Nutzer. Denn alles was in der Karte erscheint und diese dadurch unleserlich macht, beeinträchtigt ihren Wert.

Also alles was möglich ist auch eintragen

“im Prinzip ja…” Zumindest wenn es geografisch genau und passend beschrieben ist. “aber…” Es macht keinen Sinn, einfach alles was “irgendwie nicht Wald oder Bebauung oder See” ist, als “Landwirtschaft” einzurahmen und auszuzeichnen. Das erinnert mich an Kindermalbücher, wo umrandete Flächen ausgemalt werden sollen. In den Anfangszeiten von OSM war das alles nicht wesentlich, da war man froh, je mehr Daten zusammenkamen. Heute haben wir aber einen hohen Abdeckungsgrad erreicht - und da wird differenzierende Qualität immer wesentlicher. Gruss, Markus

Mirko_Küster · 2009-02-25T19:57:00.000Z

Markus B:

“der Renderer” weiss nicht was der Datensammler meint, sondern stellt einfach mal alles dar was häufig vorkommt.

Falsch! Der Renderer stellt nur das dar, was irgendwann mal vorgeschlagen wurde. Sollte die Mehrheit sich irgendwann gegen die Darstellung in der Slippy entscheiden, ist der entsprechende Style in eine Sekunde entfernt und die Äcker verschwinden mit dem nächsten Rendervorgang. Datenerfassung und Darstellung sind hier unabhängig. Es ist der komplett falsche Weg sich an die Renderer anzupassen, umgekehrt wird ein Schuh daraus. Im Moment ist vieles unbrauchbar. Nur fange ich jetzt nicht an Millionen von POIs zu löschen, nur weil man noch immer keine Lösung für die Darstellung hat. Da könntest du deine Seezeichen auch gleich einstampfen. Die brauchen 99% der üblichen Kartennutzer genausowenig.

Stefan_Rothe · 2009-02-26T15:12:17.000Z

Markus B:

den Nutzer interessiert nur das was er nutzen kann, also das was in der Karte erscheint. Karte und die darin dargestellten Daten sind ein Ganzes, sie machen nur gemeinsam Sinn.

Richtig! Und** nur** der Renderer bestimmt was in der Karte dargestellt wird. Deshalb gibt es verschiedene Renderer fuer unterschiedliche Kartentypen.

Markus B:

“der Renderer” weiss nicht was der Datensammler meint, sondern stellt einfach mal alles dar was häufig vorkommt.

Falsch! “Der Renderer” stellt genau das dar, was seine Coder ihm aufgetragen haben. Verschiedene Renderer stellen ganz verschiedene Inhalte dar, die uebrigens nicht mal zwingend alle aus der Datenquelle OSM kommen muessen. Und dieselben Inhalte werden u.U. in verschiedenen Renderern ganz unterschiedlich dargestellt, die Cyclemap ist hierfuer ein ganz hervorragendes Beispiel.

Grundsaetzlich gilt: OSM selbst ist “nur” eine Geodatenbank. Da kann und soll alles rein was sich spatial kodieren laesst und von seiner Art her fuer eine Ablage in einer oeffentlich zugaenglichen und nicht geschuetzten Umgebung geeignet ist. Ob das derzeit irgendwo “zu sehen” ist interessiert erstmal gar nicht. Nur was in der Datenbank drin ist kann auch ueberhaupt irgendwann mal dargestellt werden. Und wenn morgen jemand landwirtschaftliche Flaechen darstellen will, um zum Beispiel geeignete Aussenlandestellen fuer Segelflugzeuge zu markieren (mal ein bewusst extremes Beispiel) dann wird er evtl gern auf bereits heute gespeicherte Landklasseninformationen in OSM zurueckgreifen und diese mit Zusatzinformationen (evtl aus einer anderen, eigenen Datenquelle) verschneiden wollen. Immer daran denken: OSM Daten koennen auch unproblematisch in GIS Systemen wie GRASS und QGIS verwendet werden, wo die Einsatzzwecke ueberhaupt nicht “Mainstream” sein muessen (wir sie uns also im Zweifel gar nicht vorstellen koennen).

Alles was mit der Darstellung zu tun hat ist nicht die Baustelle von OSM als Datenbank sondern die Baustelle der einzelnen Renderer. Denn die entscheiden

was dargestellt wird
wie etwas dargestellt wird
und (nicht unwichtig) was weggelassen wird.

Zusammen mit den (anzeige-) geraetespezifischen Stildateien entstehen dann erst die optimalen Karten fuer den Einsatz im Wandergarmin, im Autonavi und auf dem Computerbildschirm oder auf Papier.

Ein sehr schoenes Beispiel fuer eine ziemlich unerwartete Verwendung von OSM Daten ist uebrigens die Nutzung der OSM Strassendaten im X-Plane Flugsimulator . Ein anderer Entwickler von X-Plane Sceneries ueberlegt derzeit, genau die Landklasseninformationen aus OSM fuer sein Projekt zu nutzen, weil diese Daten in einigen Laendern eben sonst nicht frei erhaeltlich sind. Fuer den ist es sehr wichtig dass moeglichst viele Landflaechen in OSM definiert sind.

Beste Gruesse,
Stefan

TEL0000 · 2009-02-26T20:37:49.000Z

Aufgrund des Datenbankumzugs vom Forum ist mein Post verloren gegangen. Vieles wurde mittlerweile schon gesagt, aber ich kopieren meinen alten Post trotzdem nochmal hier rein:

Markus B:

den Nutzer interessiert nur das was er nutzen kann, also das was in der Karte erscheint.

Oder was das Navi sagt…

Markus B:

Karte und die darin dargestellten Daten sind ein Ganzes, sie machen nur gemeinsam Sinn.

Das stimmt so nicht…
Die Karte macht natürlich ohne Datenbank keinen Sinn, dass stimmt schon.
Aber die Datenbank macht auch ohne Onlinekarte sinn, da sie für vieles mehr verwendet werden kann.

Markus B:

“der Renderer” weiss nicht was der Datensammler meint, sondern stellt einfach mal alles dar was häufig vorkommt.
Deshalb brauchen wir dringend eine effiziente Kommunikation zwischen Datensammler, “Renderer” und Nutzer.

Wenn die Datenbank gut dokumentiert ist, dann weiß der Datensammler was er eintragen kann, und der Renderer was er rendern kann.

Markus B:

Denn alles was in der Karte erscheint und diese dadurch unleserlich macht, beeinträchtigt ihren Wert.

Was der jeweilige Renderer dann rendert, das ist die Sache des Renderers.

Markus B:

Es macht keinen Sinn, einfach alles was “irgendwie nicht Wald oder Bebauung oder See” ist, als “Landwirtschaft” einzurahmen und auszuzeichnen.
Das erinnert mich an Kindermalbücher, wo umrandete Flächen ausgemalt werden sollen.

Felder und Äcker sollen natürlich nur Felder und Äcker kennzeichnen, und nicht alles was nicht in irgendeine andere Kategorie passt, da hast du natürlich Recht.

PS: Ich bin mir durchaus bewusst, dass die struktur der Daten und deren Dokumentation noch nicht ausreichend ist, aber daran arbeiten wir ja.

rurseekatze · 2009-03-01T21:13:37.000Z

Ich denke auch, man sollte so viele Daten wie möglich sammeln, also auch, was auf einem Acker angebaut wird oder ob es ein Laub- oder Nadelwald ist, etc.
Ob und wie man es dann auf der Karte darstellt, ist dann eine andere Sache. So kann man auf Straßenkarten einfach nur leere Flächen anzeigen und auf Wanderkarten o.ä. genaueres zur Bepflanzung einzeichnen.

rab · 2009-03-01T21:50:13.000Z

Auf so einem Acker wächst nicht jedes Jahr die selbe Frucht.
Bei all den Daten die wir hier einbringen muß man sich schon mal fragen ob und wie diese in Zukunft gepflegt werden sollen.