Bevor man jemandem unterstellt, er würde rein gar nichts zu den OSM-Daten beitragen, sollte man vielleicht mal ins Profil gucken.
http://www.openstreetmap.org/user/abalakov/edits
Jeder sollte seine Interessenschwerpunkte in OSM selbst wählen dürfen.
Jedem eine faire Chance.
Gruß
tippeltappel
Du könntest auch einfach OSMF Mitglied werden …
Wenn du damit ein Problem hast, dann frag ich mich, was dich daran gehindert hat eine Alternative zur Verfügung zu stellen. Immerhin bist du seit mehr als einem Jahr dabei…
hast Recht, nehme ich zurück, in der germany.html (Komplett-Version vom 10.12.2010 mit allen Mappern ) war er doch drin.
Mich würde jetzt wirklich interessieren wie Du das anders machen willst?
Dezentrale Datenbank ist meiner Meinung nach ein Widerspruch in sich selbst.
Kannst Du ein Beispiel nennen, wo derartiges gemacht wird?
Ähm ich behaupte jeder größere Suchdienst macht so etwas! OSM macht es aber ähnlich. Hier werden auch Planetfiles gezogen um die Daten auf vielen Servern vorhalten zu können.
Eine Schritt-für-Schritt-Anleitung für einen eigenen OSM-Server gibt es hier. Für einen Fork oder für ein Art Dezentralisierung – wobei man sich noch was für die Synchronisierung überlegen muss, sofern man die will.
Ist wirklich nicht schwierig. Und man braucht für die Minimalauststattung gar nicht mal so 'nen fetten Rechner.
Ich habe mich anscheinend falsch ausgedrückt 
Mich interessiert, wie es Bikeman2000 schaffen will, ohne dass jemand die Kontrolle über alle Daten hat, eine Datenbank zu verwalten.
Dass man die Daten über mehrere Server bereitstellen kann, ist schon klar. Es wird aber immer jemanden geben, der entscheidet, wer was machen darf (Administrator).
Es dürfte kein Problem sein, z.B. die Zugangsdaten zentral zu verwalten und die Edits über die bounding boxen dem jeweiligen regionalen Server zuzuordnen.
Die Daten dann von verschiedenen regionalen Servern zusammenzufügen, sollte ebenfalls kein Problem sein.
Über die Bounding boxen? Und bei Edits, die sich über den Bereich mehrerer Regionaler Server erstrecken? Auch API-Anfragen über mehrere Server stell ich mir nicht ganz trivial vor.
Der prinzipiell gemäßigte Stil Deiner Argumentation stimmt mich versöhnlich.
Ablehnern jedoch pauschal die Befriedigung von “Rachegelüsten” zu unterstellen, geht in meinen Augen zu weit.
Der leidende Otto-Normalmapper kann kein Argument sein.
Klar. Gemeinschaftssinn ist eine gute und wichtige Sache.
Darauf zu pochen und ihn gewissermaßen einzufordern, erzeugt Druck.
Als Pädagoge weiß man, daß man den Druck, den man erzeugt, gut abwägen muß.
Wenn die Dosierung falsch ist, erzeugt der Druck genau das Gegenteil von dem, was man erreichen möchte.
In diesem Fall ein trotziges Nein und die Verweigerung der Daten.
Die Geschichte mit den nicht erreichten inaktiven Mappern ist ein zweischneidiges Schwert.
Wenn man an einem verwilderten Schrebergarten vorbei kommt in dem das Obst an Büschen und Bäumen hängt, kann man auch nicht einfach reingehen und ernten. Das ist Diebstahl.
Bei jemandem, der ernsthaft in Not ist, nennt man das Mundraub.
Und in Köln gibt es den schönen Begriff “fringsen”.
(http://de.wikipedia.org/wiki/Joseph_Frings)
In der OSM-Communitiy ist aber niemand in Not und die nicht genehmigte Übernahme der Daten ist wohl schwerlich mit Mundraub zu vergleichen.
Es sollte allen daran gelegen sein, einen sauberen Schnitt zu machen. Nur so ist gewährleistet, daß die Daten ohne Angst vor rechtlichen Konsequenzen genutzt werden können. Dem Verlust der erarbeiteten Zusatzinformationen kann man entgehen, wenn man sich von seinen Einträgen Sicherheitskopien erstellt. Die werden das erneute Einarbeiten der Daten erleichtern.
Und wenn man beim Editieren von Daten erkennen könnte, ob der Ersteller der neuen Lizenz schon zugestimmt hat oder nicht, dann würde das die Entscheidung erleichtern, ob man an dem Objekt arbeiten möchte oder nicht. Der Mißbrauch dieser Info würde aber leider auch erleichtert.
Gruß
tippeltappel
Und da sind wir schon wieder beim Problem der Kontrolle. Ich denke kaum, dass Du willst, dass jeder in den Zugangsdaten beliebig herumpfuschen kann (“den User lösche ich, weil der gefällt mir nicht”, “der andere darf die nächsten 3 Tage nichts machen, weil er meine Argumente auf der Mailingliste widerlegt hat”, …).
Echtzeit-Synchronisierung der verschiedenen Datenserver, die weltweit verteilt sind, ist technisch wahrscheinlich lösbar, die finanziellen Kosten sind aber sicher beträchtlich.
Ähm kann es sein das es sich bei der Anleitung nicht um einen API Server, sondern lediglich um einen Mapserver handelt? Ich glaube der API Server läuft zwar auf Postgres aber nicht auf Postgis, oder?
Dann hast Du die gleichen Möglichkeiten, wie heute auch schon neu anmelden und weitermachen. Und wenn der Anmelde-Server ganz abgeschaltet wird, sind immer noch die Geodaten da, weil dezentral vorhanden. Das macht die Community viel weniger erpressbar.
Wer redet denn hier von Echtzeitsynchronisierung ? Wenn es alle halbe Stunde oder Stunde synchronisiert wird, reicht es mit Sicherheit auch. Was ich hier an denke, ist nichts anderes als der Urgedanke des Internet.
Gruß
Volker
moin moin,
unabhängig davon, welche anwendung auf dem sql-server läuft:
jeder postgis-server ist ein 100%-ger postgresql-server. postgis ist “nur” eine zusätzliche komponente, die aber nicht “stört”.
gruss
walter
Ich sehe aber jetzt nicht den Unterschied zur momentanen Situation.
Nachdem die Nichtzustimmer nach Lizenzwechsel ausgeschlossen werden, können sie mit dem letzten Planet-File weitermachen.
Warum ist die Community in dem einen Fall erpressbar und im anderen nicht?
OK. Echtzeitsynchronisierung ist sicher ein unnötiger Luxus.
Selbst beim Internet gibt es meiner Meinung nach eine Kontrolle namens ICANN, denn ohne der Verwaltung von den verschiedenen DNS-Servern wüsste kein Bit wohin es eigentlich hinsoll.
Tschau, Andreas
Über seeds, ip-Adresse und die Daten dezentral in einem p2p Netzwerk abgelegt; Nachteil ist nur die nötige Redundanz um alle Daten auch immer online zu haben, das liesse sich aber mit einerr Handvoll echten Servern lösen die Kopien der kompletten Datenbank puffern.
Im Prinzip das, nur dass keine Adressinformationen sondern Geoinformationen so verwaltet werden. Nicht geographisch sondern mathematisch verteilt: jeder client speichert die Daten lokal die andere bei ihm am schnellsten wiederfinden, das ganze aus Gründen der Erreichbarkeit entsprechend redundant; Damit wäre die Datenbank komplett dezentralisiert.
Interessanter Ansatz :-).
Ich habe bis jetzt das Ganze nur kurz überfliegen können und hoffe, dass ich demnächst etwas genauer drauf schauen kann. Ist der Bezug zu OSM von Dir spontan entstanden und wird an der Umsetzung bereits gearbeitet?
Tschau, Andreas