Hi, Dirk Stöcker wrote: > Dann fühle ich mich einfach mal angesprochen. Ich habe OSM vor > vielleicht anderthalb bis 2 Jahren kennengelernt, hielt es für > unausgereift und habe es ignoriert.
Ging mir beim Erstkontakt auch so. Karte war leer, Projekt uninteressant. [Arbeit an Merkaartor, JOSM, Tagwatch...] Find ich prima, so soll es sein. Und von jemandem, der Probleme normalerweise anpackt, wo er sie sieht, laesst man sich auch eher mal auf eines hinweisen, das er nicht loesen zu koennen glaubt. > Die nicht funktionierende OSMX-API stört mich und ich dachte darüber > nach vielleicht eine zweite Variante davon aufzusetzen. Aber oh Wunder, > findet sich natürlich nichts dazu im SVN (vielleicht ist es ja sogar > irgendwo drin, aber zu finden ist nichts). Warum schreibst Du "oh Wunder...natuerlich"? Das klingt so, als ob Du annimmst, dass Dir da jemand absichtlich was vorenthalten will? OSMXAPI ist von Etienne Cherdlu geschrieben, der auch Osmarender verbrochen hat. Es ist ein einer Programmiersprache gemacht, die angeblich ein moderner Dialekt von MUMPS ist. MUMPS ist eine Datenbank-Programmiersprache aus den 70er Jahren. Ich habe 80n gefragt, ob ich die Sourcen haben kann, und er sagte: "Gerne, aber Du muesstest Dir ca. eine Woche Zeit nehmen, um Dich von mir in eine etwas exotische Programmiersprache einweisen zu lassen". Warum es nicht im SVN ist, weiss ich nicht - 80n ist politisch ein sehr grosser GPL-Freund, also wird er bestimmt nichts geheimhalten wollen. Ich habe dann aber abgewunken und gedacht, so kompliziert ist es nun auch wieder nicht, das OSMXAPI vernuenftig in C auf einem PostGIS-Backend nachzubauen. Hab ich dann aber nie getan; anderes schien mir wichtiger. > Und Grundvoraussetzung > des ganzen Projekts ist der stabile Betrieb der zentralen Infrastruktur. > Und Du wirst mir ja wohl kaum sagen wollen, dass ich gleich die zentrale > API auch klonen soll? Oder meinst Du das? Naja. Die zentrale API ist in Ruby gemacht, und jeder, inkl. dem Admin, sagt, dass Ruby fuer diesen Betrieb - Daten aus SQL-Datenbank rausschaufeln, XML draus machen, ueber die Leitung schicken - absolut ungeeignet ist (wegen der schlechten String-Implementierung vor allem). Ich habe daher neulich, als ein nach eigenem Bekunden erfahrener C++-Programmierer fragte, was er sinnvolles tun koennte, empfohlen, er sollte doch mal den "map"-Call als Apache-Modul reimplementieren, und siehe da, er hats tatsaechlich gemacht, die Sache ist 10-15x so schnell und braucht einen Bruchteil des Speichers. (Das ist eines der Probleme im Moment, dass wir nur eine begrenzte Anzahl an parallelen API-Daemons laufen lassen koennen, weil man immer damit rechnen muss, dass ein speicheraufendiger map-Call kommt.) Ich habe das nicht genau verfolgt, aber ich rechne damit, dass diese Entwicklung in ein paar Monaten live gehen wird. Ich weiss, dass Du viele andere sinnvolle Sachen machst, aber da Du so konkret fragst: Fuer diese C++-Implementierung hat der Typ auch keinerlei Hilfe bekommen, er war einfach ein Aussenseiter, der sich da reingefressen hat, und das haettest Du sicherlich auch tun koennen, wenn Du es hinreichend wichtig gefunden haettest. Eine weitere Sache, die die Arbeitsgeschwindigkeit deutlich erhoehen wuerde, waere die Einrichtung von OSMXAPI-aehnlichen Mirrors, die aber (im Gegensatz zu OSMXAPI) die gesamte Palette der API-Leserequests koennen. Also einfach eine leicht modifizierte Version der normalen API aufsetzen, einen Job dahinter, der die minuetlichen Updates per Osmosis in die MySQL-Datenbank einspielt - alles kein Hexenwerk, "muss nur jemand machen" - und dann passen wir den JOSM so an, dass er seine Leserequests grundsaetzlich nicht aus der Masterdatenbank befriedigt, sondern aus einem der vorhandenen Mirrors. Die Datenbankperformance der Zentrale stuende dann hauptsaechlich fuer die Update-Requests zur Verfuegung. Warum wird das nicht gemacht? Nicht etwa, weil irgendein finsterer Neinsager in der OSM-Zentrale dagegen waere; nicht etwa, weil es politisch nicht gewuenscht waere oder technisch schwierig... es hat sich einfach bislang nicht "der richtige" dafuer gefunden, der die Zeit und die Initiative dafuer aufbringt. An wessen Adresse soll man also die Kritik daran richten, dass es solche Mirror-Server nicht gibt? "Die unfaehigen Admins sollten halt einfach sagen, was sie brauchen?" - "Die Foundation sollte jemanden einstellen, der das macht?" - Meiner bescheidenen Ansicht nach gibt es solche Server halt einfach nicht, weil es nicht *so* wichtig ist. Diejenigen im Projekt, die sowas machen *koennten*, tun es im Moment nicht, weil ihnen andere Sachen wichtiger erscheinen. Ist doch auch ihr gutes Recht. Ich kann doch nicht zu Dir sagen "verschwende doch keine Zeit mit Uebersetzungen von JOSM, wenn Du stattdessen einen API-Mirror bauen koenntest". Wenn die Performance der API wirklich *so* schlecht waere, dann wuerdest Du vermutlich von selber auf die Idee kommen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
