Hier steht was dazu: http://wiki.openstreetmap.org/index.php/Key:crossing mir fällt wieder Obelix ein… Gruß Jörk
Hallo zusammen, es freut mich, dass meine Frage eine so intensive Diskussion ausgelöst hat. Ich bin auch bereit an der Lösung des Problems mitzuarbeiten. (Ich kann allerdings nächste Woche nur wenig online sein.) Meiner Meinung nach sollten wir, bevor wir an inhaltliche Dinge gehen, einen gewissen Konsens über das strukturelle Vorgehen erzielen. Mir gefällt der Gedanke einer „Sitemap der deutschsprachigen Seiten“ sehr gut. Ich denke es wäre ein guter Service für alle Mapper, unabhängig ob Anfänger oder „Profis“. Das Problem wird aber sein, wo wir diese platzieren. Wenn ich an meine Anfänge zurückdenke, dann bin ich recht schnell auf die folgende Seite gestoßen: http://wiki.openstreetmap.org/index.php/Hauptseite Dann habe ich natürlich auch das folgende Thema gelesen: „Kartograf - Ich bin ein OSM-Kartograf, zeige mir Kartografie-Informationen.“ http://wiki.openstreetmap.org/index.php/De:Kartografieren Hier wäre IMHO eine gute Stelle um die Sitemap zu platzieren. Ein neuer Abschnitt mit ein wenig Erklärung und einem Link könnte eine Lösung sein. (Ich kann Wiki-Seiten bearbeiten, aber wie legt man im Wiki eine neue Seite an?) Andere Ideen, bessere Vorschläge, andere Lösungsansätze? (Ich frage bewusst nicht nach Kritik. Kritisieren kann jeder, aber besser machen, nur wenige!) Viele Grüße Siggi
Hallo zusammen, ich bin relativ neu dabei und versuche mich erstmal in die Systematik einzulesen ehe ich mir ein GPS-Gerät kaufe und mein Dorf in OSM aufnehme… Ich muss verstellen dass ich mehr als durcheinander bin. 
Es gibt diverse Dokumente und aktuelle Diskussionen und Tabellen und Methoden (die schon veraltet sind) usw, usw… So wie ich das sehe, kocht jeder sein eigenes Süppchen, weil kaum einer den Überblick hat. Wenn wir also tatsächlich eine schöne strukturierte Wiki-Seite mit den aktuellen Listen und Erklärungen und Methodiken zusammenstellen (zwingend auch auf Englisch), dann werden wir mit der Zeit wegen der schöneren Struktur eine Gewisse Methodik durchsetzen. Vorraussetzung ist, dass wir die beliebtesten & zugleich die zukunftsorientiersten Methoden beschreiben (diese Relationensache z.b., die ich nicht verstehe) und die aktuellen Diskussionen über neue Tags usw. beobachten. Ich sehe überhaupt kein Problem, eine neue Wiki-Seite oder ein quasi ausgegliedertes Wiki mit einer Gesamtübersicht zu erstellen und auf die Wiki-Dokumente aus denen man die hat (inklusive Import-Datum) zu referenzieren. Sie muss halt nur gepflegt werden. Irgendwann ist die Seite ein “Geheimtipp” wie man das Mapping macht und wird dann zum Hauptnachschlagewerk, und dann offiziell. Ein solches Nachschlagewerk brauch eine oder mehrere thematische Hierachien, einen aphabetischen Index, Beispiele in der MAP, eine untere Ebene die als Tag/Relation/what-ever-Ebene für einen schnellen Nachschlag und eine weitere UNTERSTE Ebene mit einem ausführlichen Erkären des Tagging, Alternativen und warum sie schlechter sind, sowie veraltete Varianten. Wer will sich die Arbeit machen? - Ohne sowas wirds für mich als Anfänger und viele neue richtig einzusteigen. Ich würde gerne mit euch über die Struktur einer solchen Seite diskutieren und dann mitarbeiten, sie aufzubauen. MFG Mark
Einen Gruß euch allen zusammen, bin das allererste Mal hier! Eine hochinteressante Diskussion. Weils um die basics geht, die mir, dem Neuling, die grundlegenden Überlegungen gut vermittelt. Viele davon “plagen” mich nun seit Wochen in denen ich versuche, mit OSM gehen zu lernen, Weil ich mich nicht blauäugig mit irgendwelchen unbedarften Änderungen einbringen und blamieren will. Zur Zeit habe ich das Problem, dass ich vor lauter theoretischer Überlegungen nicht und nicht zum praktischen Arbeiten gelange. Ein paar meiner bisherigen Überlegungen betr. Regeln und Systematik des geeigneten Attributierens (key/value Paare): Ich versuche schon die längste Zeit eine passende Analogie ähnliche gelagerter Problemstellungen herzustellen, um daraus verwendbare Strategien abzuleiten. Ein Szenario, das ich einigermassen gut kenne, ist das Bibliothekswesen (ähnlich gelagert der Fall der Dokumenten-Management Systeme). Da glaube ich, dass es zumindest einige Analogien gibt. Erlaubt mir kurz zu schildern: Es gibt (sozusagen in Layers von oben nach unten): (1) Die Präsentation (Formen der Suche). (2) Den Zugang. Wie findet der Suchvorgang zum Stück (die Katalogisierung). (3) Die beschlagworteten Kataloge (“Karteikärtchen”) (4) Der eigentliche materielle Bestand, der irgendwo physisch gehortet wird. Jedes Stück wird (im wesentlichen) nur mit einer ID (InventarNr o.ä.) versehen. Dazu gibts nur ganz wenige, jedoch “fixe” Grundregeln, d.h. ein ziemlicher Konsens in Fachkreisen der Bibliothekare weltweit: zu 4: Den Bestand NIE NIE NIE nach irgendwelchen thematischen Regeln ordnen (aufbewahren), kategorisieren oder indizieren. Geordnet wird, wenn schon erforderlich, nach anderen Erfordernissen wie zB Lichtschutz, klimatische Erfordernisse etc. Identifiziert (zB InvNr) wird völlig unthematisch, zB fortlaufend, ganz egal was für ein Objekt das ist. (“ewig”, ändert sich normal nie mehr) zu 3: Die wichtigste qualifizierte und verantwortungsvollste Tätigkeit (beim Neuzugang) ist die Beschlagwortung. Eher weniger, denn zuviel. (je besser erarbeitet, desto langlebiger; “mittelanglebig”) zu 2 und 1: Für verschiedene Benutzerkreise (public, akademisch, thematisch, …) können die unterschiedlichsten Kataloge und Zugangsverfahren erstellt werden, die im Wandel der Zeiten sich ständig ändern können und werden. Ich habe selbst bisher keine essentiellen Schlussfolgerungen für OSM daraus ableiten koennen. Ganz vage vielleicht diese: - ‘Markus B’ setzt sich öfters für bessere Regeln ein. Das sehe ich auch so, aber nur für die o.g. ‘lower levels’. Möglichst gut gewählte, aber so wenige wie nur irgendwie erforderlich, dafür weitgehend stringent. Das bedeutet für mich, dass ich es (zur Zeit) gar nicht gut finde, soviel Semantik im untersten level unterbringen zu wollen (zB die unendlich vielen key/value Paare), die schon dem physischen Objekt ‘aufgetaggt’ werden. - Analog etwa zwischen Beschlagwortung und Katalogisierung (obwohl die Analogie da am meisten hinkt, m.E.) sollte das semantische ‘taggen’ erst eine Ebene höher aufsetzen. Das würde ermöglichen, dass zu dem gleichen Objektbestand parallel mehrere Verfeinerungen und Auslegungen möglich sein können. Die “OSM Vermessungsingenieure” werden eine andere Sichtweise auf einen Bestand haben als etwa Radfahrer oder Routing-Programmersteller. Dann koennte man auch von ‘light-weight’ bis ‘complete’ mit unterschiedlichen Datenbasen und Geräten unterschiedlicher Leistungsfähigkeit arbeiten. Jetzt scheint das ja eher nicht möglich. - die Möglichkeiten zur Präsentation werden sich dann “wie von selbst” finden. Bisher ist das für thematische Aufbereiter (zB die cycle map) wahrscheinlich ein Horror, bei all der Diversität der Semantik schon im Bestand, geeignete Visualisierungen zu entwickeln, die auf Grund der Ambiguität der Auslegeung der key/value Paare eigentlich nie richtig sein KÖNNEN. - in diesem Sinne finde ich auch die Diskussion dieser Seite (Strukturierung der de:Beschreibungen, Anleitungen, etc) SEHR wertvoll. Weil sie das o.g. (2) Thema “Zugang” wesentlich bereichert. Fallen euch noch andere Analogie-Szenarios ein, wo man Anleihe nehmen könnte, dort bewährte Vorgehensweisen für OSM Anwendbarkeit zu überlegen ?? Oder bin ich komplett off-topic, weil das bestehende System nun einfach mal so zu nehmen ist wie es ist ?? Ist die Möglichkeit, Faktisches von Interpretationen trennen zu können bei OSM eigentlich nicht schon grundlegend vertan?? Danke, Rudolf
Liebe Forumsleser, weil mich nun schon die Schreibwut gepackt hat und ich auf die fast philosophischen Betrachtungen dieses Forums auch eingehen will, noch ein paar ungeordnete Ergänzungen zu meinem vorigen post:
Genau, das hat zum Zwecke der Kategorisierung fast immer das Problem der Überlappung bzw. Abgrenzung.
Das ist auch m.E. der groesste Schwachpunkt im System OSM. Wobei die Betonung in “willkürlich Schlüssel und Werte” auf Schlüssel liegt. Dass jeder Werte (weitgehend) frei einsetzen kann, das soll und muss ja so sein. Ich versuche wieder eine Analogie: Eine Problemdomäne der Wirklichkeit soll in einer Datenbank abgebildet werden. Man holt sich den besten DB-Designer, der auch die Problemdomäne versteht. Er wird im besten Fall die DB (das Meta-System) so generieren, dass alle Szenarios der Wirklichkeit ein Abbild finden können. Die Anwender füllen das Zeug und haben dabei alle Freiheiten AUSSER die, das Metasystem (die DB-Struktur - Tabellen, Felder, Relationen) zu verändern. Damit wird man die Wirklichkeit vielleicht nicht vollständig abbilden (“erschlagen”) können, aber, sagen wir 90% der Szenarios koennen damit beschrieben werden. Um an den Rest zu gelangen, ist inkrementelle Feinarbeit am Metasystem erforderlich. Ein Wildwuchs (jeder Anwender dürfte die DB-Struktur erweitern, i.e. OSM “Schlüssel erfinden”) führte aber in kürzester Zeit zum Disaster. OSM, in seinem sicher wohlgemeinten Ansatz der fast völligen Freiheit, ist m.E. um eine Spur zu weit gegangen. Ein zumindest im Ansatz flexibles, sowohl striktes als auch anpassbares, wohl deshalb so schnell erfolgreich geworden, uns allen bekanntes Beispiel ist das GPX Format: Die Grundschichtenstruktur ist striktest vorgegeben (XML, Topografix) und die Regeln sind beschrieben (in den .XSD’s) Damit ist der strukturellen Willkür ein Riegel vorgeschoben. Und dennoch gibt’s “Hintertürchen” die ich erfinden kann, wenn ich will: die Extension-Namensräume. Die behindern aber keinesfallls ein Programm, das diese nicht kennt. Und: Ich kann Extensions nur einführen, wenn ich die Regeln dazu wiederum exakt (im XSD) beschreibe und öffentlich hinterlege. So wird ein mehrschichtiges Metasystem aufgebaut, wobei sich jede höhere auf die feste Struktur der unteren Schicht verlassen kann. Gut, zugegeben: Auch GPX hat einige Schwächen. zB, dass der Extensions-content immer huckepack als payload mitgetragen werden muss und nicht ausgelagert liegen kann. Das OSM System (mit den freien keys) kommt mir aber vergleichsweise so vor, als ob jedermann und -frau zwar nicht XML, jedoch die GPX-Syntax (und nicht nur content) beliebig modifizieren dürfte. Dazu sind mir beim Studium der OSM Materie viele, viele solcher “Freiheiten” (wenn ganz böse formuliert: “Willkürakte”) untergekommen, worüber ich zehn weitere Beiträge füllen könnte. Was ich mit am schlimmsten finde: dass fast die selben Sachverhalte mal links (key), dann wieder rechts (value) stehen koennen. Wie die Renderer damit zurechtkommen, ist mir ein Rätsel. Und wenn dem nicht bald Einhalt geboten wird, wird diese Problematik exponentiell anwachsen - vermute ich. Und das später einmal wieder einzufangen - wie soll das gehen? Die Geister die ich rief… Welchen Ausweg aus der Malaise kann es geben? Dass man per Übereinkunft, also natuerlich nicht direktionistisch oder proprietär, sondern in gesitteter community Manier einen lieben, kleinen, schmalen, verständlichen Ruleset (Basiskatalog) schafft? Und diesen (etwa nach dem Schema der RFC’s) sanft inkrementell nur nach dringenden Bedürfnissen erweitert? just my thoughts und 'tschuldigung für den Diebstahl an Lesezeit! Und für konstruktiven Widerspruch bin ich nur dankbar!!! Rudolf
Hallo Rudolf, ich denke man kann es schon jetzt fast nicht einfangen. Es handelt sich um einen schrecklich ineffizienten evolutionären Prozess. ABER: Wir machen das als Hobby. Das bedeutet - wenn ein Schema oder eine Tagging-Variante eine kritische Masse erreicht hat (auf der Karte und in den Köpfen der Tagger und Logger) wird sich das Schema durchsetzen. Das hat natürlich garnichts mit einem systematischen Projekt zu tun. Aber was solls? An dem Naturell dieses Projektes können wir nichts bis garnichts ändern (zumindest nicht zu diesem Zeitpunkt). Du kannst das ganze hier als eine Art Brainstorming FÜR ein Schema sehen - ich halte es auch für ein Wunder, dass die darstellende Software es schafft halbwegs klar zu kommen! Hurray für die Entwickler - ihr habts drauf Was wir aber tun können, ist quasi eine Art Brandbeschleuniger für die Entwicklung zu einem guten Schema in die Community werfen. Dieser Brandbeschleuniger wäre eine gut strukturierte Wiki-Seite, die die angenommenen Proposals, häufig genutzte Tags, und sinnvolle Tags (die vielleicht noch garnicht benutzt werden). In einem 2. Schritt würde man mit behutsamen Proposals langsam das Schema in eine gute Richtung bewegen. Wenn wiederum ein großer Teil des Schemas in einem großen Teil der Karte benutzt wird, kann man das Schema strickter bindend machen. Entscheidend ist, dass wir eine akzeptierte Plattform für Nachschlagen und Anwenden von Tagging bereitstellen in Englisch und Deutsch, und wenns jemand kann vielleicht dann Französisch, Russisch, Chinesisch, und ne gängige indische Sprache - auf jeden Fall aber Englisch. Die Frage ist also: Wie sollte die Struktur aussehen? Und wie wenig müssen wir die bestehende ändern um dorthin zu kommen? Momentane Situation: 1.) Basis sind die physikalischen Daten - also die Positionen (z.B. von GPS, incl. Höhe?) 2.) Wenn ich die Systematik richtig verstanden habe werden mit Hilfe dieser Positionen können Objekte lokalisiert werden. 2a) Objekt Ort ist durch eine feste Position gegeben. 2b) Objekt Weg ist durch eine aufeinanderfolgende Reihung von Orten gegeben 2c) Objekt Fläche ist durch einen geschlossenen Weg gegeben (und einer Richtung, die innen und außen definiert, glaub ich) 3.) Können Objekte zu komplexeren Objekten zusammengesetzt werden, Das passiert über das Relationenkonstrukt. 4.) Alle Objekte und Teilobjekte von Objekten können Eigenschaften zugewiesen werden, die durch eine freie Kombination von einem “KEY” und einem “VALUE” definiert sind. 5.) Es können komplexe Bezüge, Hierachien, Querbezüge und ganze Ontologien mit Hilfe der KEY-VALUE-Beziehungen aufgebaut werden, weil: 5a.) Der VALUE auch als KEY auftauchen kann um so den VALUE näher zu beschreiben. 5b.) Der KEY gerne mal durch ein POSTIX : = attributiert wird 5c.) Der VALUE auch mal eine Menge/Liste sein (mit “;” separiert) kann. Effektiv gibt es zwischen der KEY-VALUE-Beziehung also eine N:N-Beziehung, da die Werte Frei gewählt werden können, und pro KEY mehrere Werte zugeteilt werden können. Da uns also die Syntax die volle Bandbreite an Abartigkeiten, die mir bisher in der Datenorganisation untergekommen ist bieten kann (Hierachien, Assoziationen und ganze Netze von Beziehungen) rettet uns nur die intuitive Semantik in den Köpfen der meisten Nutzer und der bereits abgesprochenen Wertebereiche und Key-Bedeutungen der Community. Mein Vorschlag: Wir versuchen mal die gängigste Art und Weise, wie Dinge tatsächlich getaggt werden herauszufinden und alles auf diese Sache so gut es irgend geht herunter zu brechen. Und nur in ganz speziellen Situationen sollten von den höheren Beschreibungsmöglichkeiten Gebrauch gemacht werden. Diese Art der Darstellung sollten wir dann in einem Wiki (oder sogar DEM Wiki) für die häufigen, wichtigen und passenden Tagging-Strategien aufarbeiten, so dass jeder neue leicht finden kann wie man was taggt - und damit das Schema systematisch durchsetzen, ohne andere in ihrer Tagging-Freiheit einzuschränken. Alleine durch eine überzeugende Methodik und gute Aufklärung der neuen, sollte sich ein gutes Schema durchsetzen lassen - es gibt für OSM soweit ichs sehe auch garkeinen anderen Weg. Für das BASIS-Schema würde ich folgendes vorschlagen: A) MÖGLICHST FESTE DEFINITION EINER OBJEKT-KEY-BEZIEHUNG: Es gibt KEYS für Orte, für Wege, für Flächen, für jede einzelne Relation und sie sind nur gültig in Zusammenhang mit diesen Objekten. B) UNTERSCHEIDUNG VON “WHAT_IS”-KEYS und “HOW_IS”-KEYS Wir unterscheiden Keys, die beschreiben von welcher Art das Objekt ist, und wie genau die Eigenschaften des Objekts sind. Ein “WHAT_IS”-KEY erzwingt bestimmte “HOW_IS”-KEYs. Bei einer Straßen-Brücke wird der maximale Gewicht der Fahrzeuge sein darf. C) EINFÜHRUNG VON MISSING-VALUES Siehe: http://forum.openstreetmap.org/viewtopic.php?id=1233 Unter Berücksichtung von F) könnte zusätzlich noch ein “SUPER:” stehen, der durch das übergeordnete Objekt gegeben wird. D) KEINE VALUES ALS KEYS - STATTDESSEN SUB-KEYS & ggf. SUB-VALUES E) ZUSAMMENFASSUNG THEMATISCH GLEICHER KEYS zu KEY:SUBKEY oder KEY = LISTE Warum haben wir 3 bis 7 KEYS, die beschreiben wer in eine Straße einfahren darf - klar: Weil OSM am Anfang und noch immer hauptsächlich auf Straßen Gewicht legt. Was spräche gegen eine Konstruktion: ALLOWEDVEHICLE:TYPES = all bzw. FOOT;BECYCLE; MOTORCAR ALLOWEDVEHICLE:MAXWEIGHT = 3,5T ALLOWEDVEHICLE:USER = all bzw. FORST; LANDWIRTSCHAFT;ANLIEGER (mir fallen gerade nicht die passenden Namen ein) ALLOWED:MINSPEED = 80 (Autobahnen) F) WERTESPEZIALISIERUNG KEYS die sich auf den Gleichen Sachverhalt beziehen, können bei Objekten und ihren Komponenten eingetagen werden, die Komponente hat dabei Vorrang vor dem Gesamtobjekt. Beispiel: Maximalgeschwindigkeit. Auf dem gesamten Autobahnnetz ungeschränkt - auf einzelnen Wegen aber schon. achselzuck Ich denke als erste Gedanke für ein Grundschema garnicht schlecht - nicht zu weit weg von aktuelle OSM und umsetzbar. Müsste halt ausgearbeitet werden. Wie gesagt - dann noch ein Wiki für die Propaganda Vielleicht hilfts. MfG Mark
Die Höhe wird in unseren Koordinaten nicht gespeichert (man kann sie höchstens als Tag an einen Punkt ranschreiben), weil Consumer-GPS keine verlässlichen Höhenangaben liefern und weil das manuelle Bearbeiten von Höheninformationen sonst (d.h. ohne Tags) einen wesentlich komplexeren Editor voraussetzt als unsere derzeitigen 2D-„Malprogramme“.
- Damit kann nicht ausgedrückt werden, dass etwa zu Fuß jeder rein darf, mit Auto aber nur Anlieger. 2. Die Semikolon-Trennung ist eigentlich im Datenmodell eher ein „Hack“, weil das auch in OSMs XML-Dateien als String mit Semikola (statt etwa als Kindelemente im XML-Baum) abgelegt und eigentlich von keiner Software (bisher) verstanden wird. 3. Das manuelle Bearbeiten von solchen Semikolon-Listen ist ziemlich unangenehm. Das nur als Einwurf. Ansonsten warte ich gerne einmal ab, was ihr euch so ausdenkt.
Hi Tordanik, danke für die Hinweise. Hoffe du wirfst auch in Zukunft weiter ein, damit wir uns nicht zuweit von der Machbarkeit wegdiskutieren. Was diese ALLOWEDVEHICLE angeht: Dann muss man sich eventuell für solche Fälle für komplexere Hierachien entscheiden. Vielleicht kommen wir aber wirklich nicht ohne die volle Komplexität aus. Bei uns gibts eine Straße für die gilt: (Anlieger frei - 3.5T) && (Forst&Landwirtschaft frei (unbeschränkt)) && 60km/h Um sowas zu beschreiben müssten KEY-VALUE-Beziehungen eventuell für eine Ausnahme referenzierbar sein. Das würde aber Eingeschaften von KEY-VALUE-Beziehungen einführen… Um ehrlich zu sein, ich hab keine Ahnung wie man ein schönes Schema dafür aufziehen kann. Eine möglichkeit wäre kombinierte Geltungsbereich zu beschreiben und diese zu kombinieren. FORST = Alle Forstfahrzeuge MOTOR = Alle MOTORFAHRZEUGE NOMOTOR = Fußgänger,Radfahrer,Pferde LAWI = alle Landwirtschaftler Verkehr MOTORCAR FOOT ect… diese Werte müssten dann zu den OBJEKT-KEY-Kombinationen hinterlegt sein. Außerdem brauchen wir dann noch Attribute des Geltungsbereichs. Also eine Struktur der Form :/:/ = WERT Die Geltungesbereiche sind Überlappende Mengen. Es gilt: Ein Schnitt spzialisiert die Werte einer einzelnen Menge, bei konkurrierenden Werten für Schnitte wird ein Schnitt-KEY erzwungen (und gegebenenfalls mit UNKNOWN getaggt…) Beispiel der oben genannten Straße: (Anlieger frei - 3.5T) && (Forst&Landwirtschaft frei (unbeschränkt)) && 60km/h ALLOWED::USAGE = YES //ist für alle erlaubt ALLOWED::MAXSPEED = 60km/h //FÜR ALLE 60km/h ALLOWED:MOTOR:USAGE = NO //ist nicht für Motorisierte Fahrzeuge erlaubt ALLOWED:ANLIEGER&MOTOR:USAGE = YES //für Anlieger mit Motor aber schon. ALLOWED:ANLIEGER&MOTOR:MAXWEIGHT = 3.5T //Die dürfen aber höchstens 3.5T haben ALLOWED:MOTOR&LAWI:USAGE = YES //für Landwirtschaftliche Fahrzeuge erlaubt ALLOWED:MOTOR&ANLIEGER&LAWI:WEIGHT = NO_BOUND //Erzwungen, weil nicht entschieden werden kann ob unbeschränkte Landwirtschaftliche Geräte oder die Anlieger-Gewichtsbeschränkung Vorrang hat. DAS ist natürlich Meilenweit weg vom bisherigen Schema und überhaupt was zu taggen ohne Software-Unterstützung zur Generierung der Schnitte und gültigen Werte reinster Gehingulasch. MfG Mark
Hallo Rudolf und herzlich willkommen im Forum. Ich sag nur Uff, “schwere Kost” die du uns da verpackt hast. Andererseits kann man doch erkennen das sich da ein “Fachmann in Sachen Struktur” gefunden hat. Ich kann die meisten deiner Argumente und Beschreibungen nachvollziehen. Wahrscheinlich solltest du dich einmal mit den “Machern” in GB “zusammensetzen”, denn das Forum ist wie kürzlich jemand schrieb (noch) eine Randgruppe 
Zugegeben diese Bezeichnung gefällt mir persönlich überhaupt nicht. Aber die Fakten sagen (noch) etwas anderes. In der Mailingliste ist mehr Traffic und scheinbar tummeln sich da auch häufiger die sogenannten “Macher”. Gruß Georg
Liebe Aktive, mir fehlt nach wie vor eine zentrale Datenbank, die alle Schlüssel erfasst… (und das geht wohl viiielen Mappern so…) Beispiel: ich suche einen Schlüssel, in den ich als Wert eine URL eintragen kann. Konkret: bei uns gibt es einen Naturlehrpfad, und dazu eine Broschüre als PDF. Als Suchbegriff für die Suche nach relevanten Schlüsseln fällt mir ein: - URL - Weblink - Website - Naturlehrpfad Aber gefunden habe ich nichts was passen könnte oder gar valide wäre… Sinnvoll wäre: {{Tag|url|http://}} + {{Tag|url:de:title|}} + {{Tag|url:de:description|}} + {{Tag|url:en:title|}} + {{Tag|url:en:description|*}} Gruss, Markus
Ich möchte hier mal meine unmaßgebliche Meinung dazu zum Besten geben. Obwohl ich nicht wirklich die hier gemachten Vorschläge gut nachvollziehen kann, so scheint mir aber mit der zunehmenden Detailliertheit bei der Datenerfassung der “typische Mapper” nicht mehr genügend berücksichtigt zu werden. Ich denke, dieser hat wenig Lust, sich bei jedem zugefügten Objekt für das Taggen mehr Zeit zu nehmen, als für die gesamte restliche Arbeit, die jeweils für neue Daten anfällt. Die Motivation der User sollte erhalten bzw. gefördert werden, das sollte wirklich für JEDEN gelten, für den Anfänger, Experten oder denen, die einfach nur wenig Zeit mitbringen . Meine Vorschläge: Wählbare Komplexität beim Taggen im Editor. Z.B. sollte sich jede “unscheinbare” kleine Auswahlbox erweitern lassen. Das können eine oder auch viele Erweiterungsstufen sein, je nachdem, wieviel Zeit, Lust, Kenntnis, Datenmaterial der jeweilige User gerade mitbringt. Sinnvoll halte ich die Erweiterungsmöglichkeiten der Tag-Eingaben, wenn sie in der Auswahl gleicher und auch unterschiedlichen Datenarten (Verknüpfungen) bestehen würde. Als weitere Verbesserung schlage ich vor, in den Auswahlboxen kleine Bitmaps zu integrieren. Das Auge isst ja bekanntlich mit, aber auch die Verständlichkeit der verschiedenen Möglichkeiten nähme zu. Die Bitmaps könnten durchaus kleine Fotos sein, wie zum Beispiel von den vielen unterschiedlichen Path- und Track-Typen. Evtl. noch eine “Feststellmöglichkeit” ermöglichen, Icons/Bilder nie/immer anzeigen, Detaillierung nie/immer gering (s.o.). Am Besten auch in den Editoren einen Link integrieren, der zur passenden Wikiseite führt. Grüsse Detlef
Hallo Detlef,
ja, ein Bild sagt mehr als 1000 Worte. Auch diese Bilder könnten in so einer zentralen Datenbank liegen, und von allen Editoren benutzt werden. Genauso wie die Regeln zu den Schlüsseln und ihren Werten. Wenn dem Kartografen dann auf eine intuitive Weise die jeweils passenden Bilder, Schlüssel und Regeln für die Schlüsselkombinationen und Werte angeboten werden, wäre das sehr hilfreich und zeitsparend. Wenn man nur noch anklicken muss gibts keine Tippfehler mehr. Man bekäme weitere Anregungen für Eigensschaften an die man noch nicht gedacht hatte, und gleichzeitig würde es viel Sucherei, und wenn nicht gefunden viele unklare Auszeichnungen ersparen. Gruss, Markus