Idee: Komponentenbassierte OSM-Seite um projekte zusammenzufassen

Communities Deutschland (Germany)
1

Hy,

Jeder kennt vermutlich das problem dass man für spezielle OSM-Kerten jeweils auf spezielle seiten gehen muss, jedes mal mit lesezeichen suchen,…

Also Hauptseite für mapping, suchen,… . Dann noch spezielle routingseite für routenberechnung und diverse seiten für fehlersuche in OSM-Daten, spezielle overlays,…

Vieles wird vermutlich nie auf die hautpseite kommen, da einfach der bedarf an speziellen karten, overlays,… nicht hoch genug ist. Außerdem hab ich mitbekommen, das die Hauptseite rein für mapping und einfache karte/suche da ist, aber eigentlich nicht für den endbenutzer konzipiert ist.

Meine Lösungsidee wäre ein eigenes Portal, welches vom Aussehen dem standardportal gerne ähneln darf, aber in Grundzügen nur ein Framework ist welches die Grundfunktionalitäten bereitsstellt. Darauf aufbauend können dann komponenten/plugins aktiviert werden die neue layer, overlays, editoren, suchportale, anzeige der suchergebnisse,… aktivieren.

Die Standardseite besitzt also alles wichtige plugins für Endbenutzer, und jeder mit einem OSM-Account, oder auch nur aktivierte Cookies kann dann nach seinen geschmack einzelne komponenten aktivieren oder deaktiveren, oder auch eigene einbinden. Ein mapper der sich also für hausnummern interressiert könnte dann einen debug overlay dafür einbinden, ein anderer eine overlay dass OpenStreetBugs pois angezeigt werden, oder dass eine Routing-Engine genutzt werden kann.

Ich wollte mal fragen wie das interresse daran aussieht, und ob auch ein paar mitmachen würden. Ich kann Js, aber nicht so gut dass ich das alleine sauber machen könnte. Das ganze wäre aber eine idee, endlich den urwald an seiten etwas zu sammeln.

mfg, pointhi

2

Ich glaub das Ganze ist weniger ein technisches Problem als ein menschlich-politisches.

Erst mal ist nicht klar wozu “die Hauptseite” überhaupt gut ist. Soll sie eine vernünftige Vorstellung der GeoDatenbank sein (die .de Seite geht in die Richtung) oder nur eine ansprechende aber eigentlich irreführende Kartenseite? Bei der aktuellen .org Seite ist die Diskussion nicht abgeschlossen ob sie überhaupt für jemanden taugt und falls ja für welche Gruppe. :slight_smile:

Dann ist da noch die Frage was überhaupt auf “die Hauptseite” drauf darf. Auf der einen Seite sind die Anforderungen jetz schon so hoch, daß viele Spezialkarten und -dienste ausgeschlossen sind (weltweite Abdeckung auf eigene Kosten, minütliche Updates), auf der anderen Seite gibt es immer wieder die Forderung, nur offene Dienste aufzunehmen und die irreführend benannte opencyclemap zu entfernen.

Letztendlich zeigt sich auch immer wieder, daß einfach die Leute, die den Daumen auf den Servern haben einfach tun was sie wollen (iD, redesign). Von daher ist es erst mal relativ egal welche technischen Framworks oder Websiteideen jemand anders entwickelt, insbesondere wenn die Ideen aus Deutschland kommen scheinen sie äußerst geringes Gewicht zu haben. :-I

bye, Nop

3

Ich hatte nicht die idee die hauptseite durch diese idee irgendwann zu ersetzen, sondern eine eigenständige seite zu entwickeln, die deshalb benutzt wird, weil sie vorteile bietet. Durch ein framework ist es auserdem möglich, neue ideen schnell und unkomplizierter zu testen. Es ist nicht schön, wenn man für jede idee eine neue seite aufbauen muss, besonders wenn sie minimal sind.

4

Ich hab’ mir da für mich selbst schonmal was gebastelt. Vielleicht kriege ich das nächstes Jahr zumindest ansatzweise Release-tauglich (geplant war “Weihnachten” (2373)). #guterVorsatz
Ganz so Modular wie du es dir wohl vorstellst (und ich es mir wünschen würde) ist es (noch?) nicht, aber zumindest die Base-Layer kann man sich per Cookie selbst einstellen. Ein grosses Problem dabei ist die Verlinkung, die dadurch oft nicht möglich ist.

Ich würde mir das so vorstellen, dass von dieser Leaflet-basierten “Portal-Seite” beliebige Skripte eingebunden werden können, und der Benutzer sich eine entsprechende Liste in ein Cookie schreiben kann. Was diese Modul-Skripte machen ist dann deren Problem, welche Kombination der Module genutzt wird Problem des Nutzers. Klingt das so wie du es meintest?

Zu der Frage die Nop hier eben eingebracht hat: Ich fände es gut, wenn jemand™ die osm.de-Willkommensseite weiter verbessern würde, aber imo gehört diese Diskussion in einen anderen Thread. Dahinter sollte es dann imo soetwas wie pointhi es vorgeschlagen hat geben, was man ja unabhängig davon entwickeln und worüber man hier diskutieren kann.

5

Das ist gut. Hast du eine demoseite/github projekt?

Ich hab ein wenig erfahrung mit plugin-systeme. Meine Idee wäre dass man einsprungpunkte an bestimmten stellen im code hinzufügt (load/unload/search/…), und zugriff auf spezielle funktionen gibt (layer hinzufügen,…). Die OSM-Hauptseite hat viel code den man dafür wiederverwenden kann. Die einzelnen komponenten die geladen werden werden dann über cookies oä. definiert. Die frage ist wie umfangreich das system werden soll (z.b. ob komponenten auch eigene einsprungpunkte definieren können,…)

mfg, pointhi

6

Das klingt richtig gut! Ich habe ein paar schöne Karten erst über irgendwelche tief vergrabenen Threads im Forum gefunden. Eine Seite, auf der man einen Überblick hat, ist klasse. Mir persönlich ist es nicht so wichtig, ob die Karten dort open source sind oder nur halb. Zuerst dachte ich, mir selber würde eine Seite à la Opera Schnellwahl völlig reichen, einfach mit kleinen Vorschaukarten, aber wenn es eine “interaktive” Liste wird wie eben skizziert, ist das ja noch besser. Ich kann da zwar nichts beisteuern, aber ich freue mich sehr, wenn’s was wird.

7

Das klang vielleicht etwas fertiger als es ist: Mit “ansatzweise Release-tauglich” meinte ich “vorzeigbar”. Ich will erst noch ein paar Dinge verbessern und muss mir auch noch über so unnützes Zeug wie Lizenzen, API-Usage-Policys und Sicherheit Gedanken machen. Ausserdem hab’ ich momentan nicht so viel Zeit. Nächstes Jahr bestimmt™

Zumindest von meiner Seite wäre es nur etwas, um eine solche Liste zu nutzen. Das oben angesprochene Layer-Cookie bei mir ist ein JSON aus Name des Layers, Tile-Adresse, maximalem Zoomlevel und “attribution”. Woraus dieses Cookie gefüllt wird will nicht mein Problem sein.