Felder und äcker eintragen?

Communities Deutschland (Germany)
21

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.

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.

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.

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

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

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.

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. :smiley:

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.

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.

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.

22

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.

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.

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.

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.

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.

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.

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

23

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.

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.

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.

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.

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.

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.

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.

24

Hallo …,

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

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

25

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.

26

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.

27

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

28

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

@de_murr Auch hier gilt meine volle Zustimmung.

29

Hallo Mirko,

“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.

“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

30

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.

31

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

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 :sunglasses: . 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

32

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:

Oder was das Navi sagt… :wink:

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.

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

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

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. :wink:

33

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.

34

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.

35

Es würde schon reichen, grob zwischen Getreide, Obst und Gemüse zu unterscheiden.
Je mehr mitmachen, desto einfacher ist dann auch die Pflege der Karten. Wenn einmal alles gemappt ist, muss man nur noch solche Kleinigkeiten eintragen, was ja schließlich nicht mehr viel Arbeit ist. Das Projekt hat doch schließlich das Ziel, die aktuellste und genaueste Karte der Welt zu erstellen, oder irre ich mich da?