Schaut gut aus. Ich würde dann den Vorschlag von EvanE wirklich komplett so übernehmen: Unausgeklappt Thema + ShortDescription, Ausgeklappt: Ausführliche Anleitung. Wenns dann wirklich gut durchgezogen wird, dürfte man unausgeklappt den von geri-oc präferierten Schnelleinstieg haben. Und dennoch verzichtet man auf keine Information. Wirklich eine Top-Lösung.
Als “zwingend” hab ich das auch nicht formuliert.
Mir geht es darum, dass sich eine gewisse Struktur vom Grob- zum Feinmapping bereits im Guide wiederfindet.
Ich will niemand zu Mappings von Dingen zwingen für die er sich nicht interessiert. Ich habe nichts gegen Feuerwehrleute die Hydranten mappen. Ich finde es staunenswert in welcher Feinheit Hochspannungsstrecken gemappt sind, selbst durch Gebiete wo Siedlungen und Straßen nur grobgemappt sind und Wege fast noch völlig fehlen. Solche Spezialistenmappings behindern nicht die Weiterarbeit auf anderem Gebiet.
Anders ist das aber bei den “Kartenmalern mit Weiß-Phobie” die (ich nehm mal ein Beispiel) ihre landuse=farmland an irgendwelche Wege kleben, möglichst noch Relationen draus machen wo man erstmal 10 Extra-Fenster mit aufmachen muss um die überhaupt zu durchschauen. In solchen Gebieten, das ist meine Erfahrung, kommt das weitere Mapping ins Stocken, weil das abschreckend und verwirrend wirkt.
Eine nach groben Sat-Bildern als way gemappte Waldfläche (landuse=forest) kann ich, wenn bessere Sat-Bilder verfügbar sind, löschen und neu zeichnen. Aber nicht, wenn jemand ein Multipolygon draus gemacht hat und dieses gleich sinnigerweise mit anderen Flächenpolygonen verbunden hat - mit dem Argument, dass man ja Punkte nicht doppelt zeichnen soll weil sie so “Speicherplatz sparen”…
Dann sind wir uns einig 
Ich meinte ja nur, dass man nicht unbedingt DIESE Reihenfolge so vorschlagen. Nicht so detailliert. Vielleicht reicht wirklich ein Vorschlag:
- Straßen
- Große Flächen
- Häuser
- Hausnummern
- Sonstiges.
(auch diskutierbar…)
Mein persönlicher Dank geht an slhh, dank dir und deinem Beispiel habe ich die Elemente “NavFrame, NavContent” nun verstanden. 
Das ein/aufklappen ist ja bereits in dem Languages Template mit drin, das wird schon. Wenn nicht sagt noch mal bescheid.
Diese Struktur mag für Mapping von Städten sinnvoll sein; in Städten ist das Grobmapping aber größtenteils abgeschlossen und somit erübrigt sich dafür eine Anleitung. Dort gibt es i.d.R. auch genug OSM-Interessierte. Anders sieht dies in der Provinz aus. Ich weigere mich auch, anzuerkennen dass Feldwege (=Sonstiges?) für die Kartendarstellung unwichtiger sein sollen als Einzelhäuser und Hausnummern. Der am Ortsrand wohnende Hundehalter hat vielleicht viel mehr davon, und auch mehr Spaß beim Mappen von Wegen wo er mit seinem Hund rausgeht, als mit dem Zeichnen pupsi-kleiner Wohnhaushälften… natürlich darf er Wohnhäuser und Hausnummern mappen, damit behindert er keine anderen OSM-Arbeiter. Anders als wenn er 2qm Fläche braun anmalt weil das für ihn alles irgendwie “agricultural” ist.
Noch etwas:
Es gibt keinen Grund dass man das Mapping von Wegen aufgrund von GPS-Tracks höher bewertet als das von (hochauflösenden) Sat-Bildern. Im Gegenteil, die Mappings nach GPS-Tracks (erkenne ich immer an den vielen Wegpunkten) sind meist sehr viel ungenauer, besonders im Wald. Und es wäre wirklich toll, wenn zumindest alle highways mit tracktype=grade2 oder grade3 (feste Forstwirtschaftswege von 3-4m Breite) die man zu 99% im Sat-Bild sehen kann, auch gemappt würden, anstatt zu fordern diese erst mal mit dem GPS-Gerät abzulaufen, am besten gleich noch mehrfach zur Fehlerkorrektur (arrghh!). Feinkorrigieren kann man sie später nämlich immer noch…
Wie gesagt, nur ein diskussionswürdiges Beispiel. Ich würde es nur nicht so fein auflösen, wie du Aber andere können das gern auch anders sehen. Dafür ist die Diskussion ja da.
GPS vs. Luftbild: Hmm, das übliche zweischenidige Schwert. Beides gekonnt verkuppeln ist das gute Ergebnis. Sollten wir so schreiben ohne Wertung. Nur wollte ich damit (und das schrieb ich schon in der Diskussion) mit dem Neuschreiben des Beginners Guide ein Stück weit verhindern, dass Neumapper wahllos in irgendwelchen Gegenden Luftbilder mappen, ohne die Realität zu kennen. Deswegen würde ich für einen Neumapper immer erst die Realität empfehlen, anstelle virtuell zu schaufeln. Es wurde ja nun schon mehrfach in vielen Threads darauf aufmerksam gemacht, dass of Luftbilder abgezeichent wurden, obwohl sie falsch positioniert oder stark veraltet oder verkehrt interpretiert waren. Um den Neumappern ein Gefühl für einzelne Sachen zu geben, bin ich stark dafür, ihnen erst ein GPS-Track ans Herz zu legen und dann Luftbilder zur Hilfe zu nehmen. Wir haben jetzt gerade die Chance “Couchmapping” ein wenig einzudämmen. Auch wenn ich dir recht gebe: Erfahrene Mapper wissen um die Bedeutung aber auch Fehleranfälligkeit von Luftbildern, aber Neumapper unter umständen nicht. Ich will also den Beginners Guide quasi zur Erziehung nutzen, um von vornherein aufmerksame Mapper “auszubilden”
Verzeiht bitte die hochtrabenden Worte, mir fällt gerade nicht ein, wie mans besser formulieren kann
Ich bin nicht der Ansicht dass man “Couchmapping” per se eindämmen muss.
*Schlampiges *Mapping sollte man versuchen einzudämmen, egal ob von Couch- oder Feldmappern.
Ich mappe ausgiebig nach Sat-Bildern, als Vorbereitung wenn ich in Gegenden wandern möchte wo das Grobmapping noch sehr vage ist. Gerade habe ich 5 Moselseitentäler in Hunsrück und Eifel mit Bachverläufen und Wanderwegen gemappt. Natürlich hatte ich auch ein paar alte Tracks zur Überprüfung, aber das meiste war wohl “couchmapping”.
Man mag Luftbilder manchmal falsch interpretieren (wirklich falsch sind sie selten), aber ein Beginner’s Guide sollte m.E. Wissen vermitteln und Mut machen anstatt davor zu warnen. Wenn mal ein Bach als Weg eingezeichnet ist, ist das auch nicht so wild, das ist schnell korrigiert. Und jede Bach-Mäander durch eine 100m breite Wiese braucht man für die allermeisten Anwendungen vielleicht auch nicht aufzunehmen, auch wenn sich das auf einer Karte sehr hübsch macht. Den Wanderer interessiert doch nur, ist der Bach rechts oder links von mir, oder wo ist die nächste Brücke. Wir mappen doch für User. Und wer’s ganz genau braucht, kann’s später genauer nachzeichnen. Ich habe gefühlt in den letzten Monaten sämtliche Bäche in einem sehr wasserreichen 2000qm großen Gebiet nach Luftbild eingezeichnet, aus meinem Wissen dass da Bäche verlaufen und anhand historischer Karten. Fast alle haben gefehlt. Wahrscheinlich hat das bisher keiner gemacht weil jeder dachte, wenn, dann müsse es extragenau sein, oder er war sich unsicher welchen layer-Tag er dazuschreiben soll. Oder ist nach Mapping von 10km Bach von einem anderen User angepflaumt worden doch jetzt gefälligst alle Brücken dazu zu taggen, und nun macht er gar nix mehr, weil er nicht weiß: hat die Straße oder der Weg an der Stelle 'ne Brücke, oder sollte er besser 'ne Unterführung für den Bach taggen???
Richtig, du als erfahrener Mapper Ich ziehe mich mal aus dieser speziellen Diskussion zurück, da wir zwei komplett unterschiedlicher Meinung sind. Mich würden mal andere Meinungen interessieren
Zum Thema Bäche mappen fällt mir grad ein wie ich es in den Bergen gemacht habe: Unter Berücksichtigung der **Höhenlinien **zusammen mit den Luftbildern funktioniert es nahezu perfekt. Schließlich fließt da kühle Nass immer nur nach unten 
Ich bin ein erfahrener Kartenbenutzer. Als erfahrenen Mapper würde ich mich nicht bezeichnen. Ich muss immer noch dazu lernen wie man was mappt, und meine ersten “Bäche” waren gleich gut gemappt wie die von zuletzt. Nur meine Multipolygone sind heute (hoffentlich) sehr viel besser wartbar (und auch dazu waren die Anleitungen nahezu unbrauchbar).
Das ist überhaupt ein Gedanke den man OSM Neulingen nicht tief genug eintrichtern kann: Keine komplexen Strukturen mappen, alles so einfach und leicht änderbar halten wie möglich. Keinen “individuellen Stil” verwirklichen.
Sehe ich auch so. Auf dem Luftbild sehen viele Treckerspuren aus wie Feldwege, sind es aber nicht. Um Feldwege nach Luftbild zu mappen, braucht man eine Menge Erfahrung am Boden.
Für Deutschland trifft das zu, schon in Schweden oder Polen sieht es anders aus. Ich würde die Grundlagen des innerstädtischen Mappings nicht ausklammern.
In Hessen sieht man sie auf Luftbildern ganz gut, weil die Baumkronen die Wege selten verdecken. Hier im nahen Osten (Brandenburg) sind die Forstwege häufig verdeckt. und weichen auch von offensichtlichen “Wegschneisen” ab.
Für den Mapper ist es kein Drama, für den Wanderer-Kartennutzer, der in letzter Minute zum Zug eilt und sich auf den vermeintlichen Weg als Abkürzung verlassen hat, schon. Wie ich schon anderenorts schrub: Lieber etwas nicht mappen als es völlig falsch mappen.
Genau. Keine unnötigen MP-Konstruktionen. Immer dran denken, dass eine Karte nie “fertig” ist, weil die Realität stets im Wandel ist. Und der heutige OSM-Regionalfürst lebt nicht ewig.
Weitere Faustregeln, die ich für sinnvoll halte:
- Fläche nur mit Fläche verbinden, Weg nur mit Weg, Grenze nur mit Grenze.
- Keine Riesenflächen und keine ewig langen Highways. ZB bei Feldwegen nur von einer größeren Wegkreuzung bis zur nächsten - denn wenn jemand den Tracktype an einem Ende ändert, weil dort der Weg ausgebessert wurde, reißt er nicht versehentlich den ganzen Weg mit.
Da steckt noch eine ganze Menge CSS Gerödel hinter. Die Class=“*” müssen ja irgendwo definiert sein. Es ist natürlich praktisch, wenn das bereits zum Lieferumfang des MediaWikis gehört.
Ich denke dass Templates sinnvoller sind, als den HTML-Code mehrmals im Text zu wiederholen. Die Entwicklung eines Templates kann mühsam sein. Aber wenn es erst mal funktioniert, dann ist die Anwendung doch einiges einfacher als immer wieder den gleichen HTML-Code einzubauen.
Weiter will man eher eine Liste solcher ausklapbaren Punkte haben. Wenn es gut aussieht und auch noch praktisch ist, dann wollen andere das auch in ihrer Wiki-Seite einbauen. Das sind alles Gründe, dafür ein Template zu bauen. Weiter wünscht man sich natürlich eine schöne Gestaltung (Hintergrund, Einrückung, …) möglichst ohne sich jedes mal darum kümmern zu müssen.
Dein Beispiel bei den Grundlagen zeigt mir, dass es sinnvoll sein kann, eine weitere Stufe Einklappen im Text zu haben. Die Diskussion gehört eigentlich zu dem Punkt und sollte ebenfalls unter der Überschrift “Grundbegriffe …” enthalten sein. Wer den Text sich ansieht will nicht unbedingt auch die Diskussion dazu lesen.
Das wäre natürlich unbedeutend, wenn das nicht auch im "New Beginners’ guide" genutzt werden könnte. Auch dort gibt es neben Überschrift und Text eine weitere Kategorie, die nur auf Wunsch des Lesers angezeigt werden soll. Dabei handelt es sich um Dinge wie Details, weiterführende Informationen, Diskussionen, Links und ähnliches. Das will man nur sehen, wenn man mehr über das Thema wissen will.
Man braucht ein Template für das Aus-/Einklappen und ein weiteres für eine Liste mit solchen Elementen. Als Beispiel kann man sich die Lösung mit Tab (zeichnet einen Rahmen) und TabBar (macht eine horizontale Liste von Tabs) ansehen. Wie das mit einfachem Ausklappen in einem Template geht, kann man sich z.B. bei Template:Languages ansehen.
Edbert (EvanE)
Ja das ist auf eurer Diskussionsseite bereits sehr nützlich.
Für eine allgemeine Verwendung müssten mehr Eigenschaften (Überschrift, Farben, Strichbreiten, …) als Parameter angegeben werden können. Wie auch immer, das ist in guter Startpunkt für die Weiterentwicklung.
Edbert (EvanE)
Bei Euch vielleicht. Hier ist das ganz easy und geht ratzfatz. Und kommt erst mal mit nur 3 Klassen Wege aus. Jeder Anfänger der schon mal eine TK25 in der Hand hatte, kann das lernen.
Sollen Anfänger aus Deutschland etwa mit Mappings in Schweden und Polen beginnen, ohne 'ne Stadt dort gesehen zu haben? Muss man sie dazu motivieren? Ich denke nicht allzuviele werden von allein auf solche Ideen kommen (zum Glück)
Welcher Art Bäume habt Ihr denn, dass die’s schaffen die Forststraßen zu verdecken? Oder ist der Schotter bei Euch tarnfarben? Oder tagged Ihr Sumpfwege mit tracktype=grade2?
Und ich schrieb’s auch schon mal: Es lassen sich immer 1000 idiotische Beispiele konstruieren warum man am besten gar nichts mappt, und so sieht die Karte dann auch aus: leer. Wem das so lieber ist: bittesehr. Wer eine Karte mit einer Vollkaskoversicherung verwechselt, wird mit jeder reinfallen, auch mit der von OSM. 100% richtige Karten wird’s nie geben. Wer mit diesem Anspruch an die Karte(nerstellung) herangeht, soll’s gleich bleiben lassen. Die Fehler die ich so typischerweise korrigiere, sind völlig “unkritischer” Natur…
Einverstanden bis auf den letzten Satz. Der mag da gelten, wo auf 1km² landwirtschaftliche Fläche vielleicht 0,2km Feldwege kommen und noch weniger Kreuzungen. Hier gibt es davon aber die 20-fache Menge. Da mappt man keine Fuzzel-Wegstückchen von 200m - es sei denn, es ist nötig den Weg in Einzelteile zu zerschneiden, z.B. für eine Wanderweg-Relation.
@Taunide: Die wenigsten Forstwege hier sind grau geschottert. Der grüne Mittelstreifen ist fast obligatorisch, surface=sand oder dirt ist die Regel. Anders als in Hessen lässt man auch dicke Bäume dicht am Weg wachsen, so dass sich die Kronen fast berühren und dementsprechend die Sicht blockieren. Ob dann da drunter nur eine Schneise oder doch ein “Weg” wie oben beschrieben liegt, ist meistens kaum zu erkennen.
Sach ich doch 
Hier gilt es. Z.B. Landkreis Uckermark: 42 Einwohner/km². Bauchmäßig würde ich sagen, dass das durchschnittliche Feld hier 1 km² groß ist, und beim durchschnittlichen Feldweg zwischen zwei Kreuzungen mehr als ein Kilometer liegt. Aber Du hast schon recht: Daran, dass man in Hessen alle 200 Meter den Weg zerhacken würde, habe ich nicht gedacht. Wäre auch nicht das, was ich empfehlen würde. Aber nach 2 km darf man schon einen Schnitt machen, wenn es sich anbietet, oder?
Jetzt noch mal ganz im Ernst: Beim Beginners Guide sollte man durchaus in Betracht ziehen, dass schon in Deutschland regional ganz unterschiedliche Voraussetzungen existieren. Ich weiß, dass in hessischen Wäldern das Forstweg-Couchmapping ein Kinderspiel ist. Hier ist es das nicht. Und hier trifft man auch immer noch sandige Ortsverbindungsstraßen an, die mit Mühe tracktype 3 sind.
@Pfad-Finder: Danke, endlich einer, der mich versteht.
@Taunide: Warum sollten wir potentielle Schweden-Dauerbesucher vom Mappen ausschließen? Abgesehen davon sollten wir den Anspruch haben, möglichst ein international gültiges Dokument zu schaffen und nicht jede Übersetzung anders aussehen zu lassen
Das ist schon klar. Für optimale Ergebnisse müßte wohl auch noch jemand mit entsprechenden Rechten einige angepasste Klassen erstellen. Zum Beispiel wäre dies wohl nötig, wenn man show/hide übersetzen will. Der gleiche code erzeugt in der deutschen Wikipedia Ausklappen/Einklappen. Dann könnte man auch einige Voreinstellungen mit integieren, so dass der im Wiki zu verwendende HTML code möglichst einfach wird. Da die vorhandenen Klassen als Basis dienen können, sollte sich der dazu nötige Arbeitsaufwand in Grenzen halten.
Die Vorteile der Templates sind mir schon klar. Vor dem Entwicklungsaufwand würde ich nicht zurückschrecken. Die Frage ist aber, wie man den Textinhalt hineinbekommt.
Üblich ist wohl, diesen als Argument zu übergeben. Soweit mir bekannt, gibt es dann aber einige Einschränkungen der verwendbaren Syntaxelemente. Ist es wirklich sinnvoll, die Klappbox zu vereinfachen, deren Code man mit Copy&Paste erstellt, und dafür sich die Formatierung der eigentlichen Textinhalte zu erschweren? Ich denke nicht.
Eine weitere denkbare Lösung wäre, den Textinhalt jeder Box in eine eigene Unterseite auszulagern, die dann von dem Template wie ein weiteres Template eingelesen wird. Als Argument wäre dabei der Name der Unterseite zu übergeben. Dabei würden vermutlich die Formatierungseinschränkungen entfallen. Ist diese Verteilung des Textes aber nicht beim Schreiben zu hinderlich? Wo packen wir den einleitenden Satz hin? Wenn der als Argument übergeben wird, ist er vom Textinhalt der Box in den Sourcen total abgetrennt. Wenn der einleitende text mit auf die Unterseite kommt, brauchen wir dort wieder bedingten Text. Das macht die Handhabung auch nicht wirklich einfach.
Soweit mir bekannt, dürfte es auch nicht so einfach funktionieren, wenn der in meinem Beispiel verwendete HTML Code in drei Templates versteckt wird: Eines vor dem einleitenden Satz, einen nach diesem und eines am Ende des Blockinhalts, da dann HTML Konstrukte nicht innerhalb des Templates abgeschlossen sind. Vermutlich würde diese Vorgehensweise funktionieren, wenn man den Templateinhalt jeweils beim schreiben in den Artikel einsetzen lässt. Dann ist letztendlich der Sourcecode des Artikel genau so, als wenn man die HTML Zeilen direkt geschrieben hätte, und der Vorteil der leichten Modifizierbarkeit durch Templates wäre entfallen.
Meine Kenntnisse über die Wiki-Templates sind schon etwas veraltet. Falls eine der Einschränkungen inzwischen überholt sein sollte, wäre dies natürlich gut.
Die Einschränkungen bei der Syntax entfallen mit der von mir oben vorgeschlagenen Lösung, die aber ebenfalls einen Eingriff mit entsprechenden Rechten benötigt um einige bereits vorhandene Klassen im Wiki zur Verfügung zu stellen.
Die Funktionen werden hier erläutert.
Die Originalfunktion stammt von: http://openwetware.org/wiki/OpenWetWare:Toggle und sollte somit frei zugänglich sein.
Auf der Seite: http://wiki.zum.de/Hilfe:Verstecken_und_Anzeigen/mehr#Installation_der_Toggle-Funktion wird erläutert wie die Funktion in andere Wiki’s übernommen werden kann.
Diese Toggle-Funktion (aufrufbar in der o.g. Seite mt dem Befehl Popup (was nix mit einem Popup zu tun hat!)) kann alle möglichen Befehle ein- und ausblenden (Bilder, Tabellen, usw…). Anhand der gezeigten Beispiele im zum-wiki wird ersichtlich, dass wenn die Klassen im Wiki verfügbar gemacht wurden, damit noch wesentich mehr z.B. über Templates realisierbar ist.