SE - config - setting #89
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/Spotter-VM#89
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Prosím o průzkum těchto settingů, pokud ještě nebyly označeny jako nepoužitelné
https://git.spotter.cz:8443/Spotter-Cluster/Spotter-Cluster/blob/master/sahana/srv/sahana/applications/eden/models/000_config.py
moje logovací jméno
tady asi nastavení pro mapy
tohle mě zajímá jestli s tím jde vylepšit nějaké fulltext hledání (?)
tohle by mohlo řešit to odlogování, ne?
další settingy ještě prozkoumám a dopíšu.
GeoNames - OK, nastavím. Jen pro ujištění - rozumím tedy, že máte vytvořený účet pro webové služby na http://www.geonames.org/export/web-services.html s tímto názvem, ano?
Mapy - Výchozí hodnoty jsou
settings.search.max_results = 200
asettings.gis.max_features = 2000
, což mi připadá jako celkem použitelné nastavení. Jak byste je chtěl změnit?SOLR - SOLR je indexovací systém běžící v samostatné serverové službě. Sahana podporuje pouze indexaci dokumentů (modul
doc
), což bylo implementováno v rámci něčího nadšení a evidentně to nikdo nepoužívá, protože ani nemůže, jelikož k tomu neexistují indexová schemata (obdoba databázových tabulek). Dají se použít výchozí, ale to pak není o moc víc efektivní než slušně optimalizovaný fulltext v databázi.Memcache - Memcache je in-memory data store, opět běžící v samostatné serverové službě. Můžete si to představit jako jednu velkou tlustou databázovou tabulku, ke které je přistupováno výhradně skrze primární klíč. Používá se, aby se odlehčilo databázi nebo souborovému systému. U session to má smysl pokud bude aplikace používána stovkami uživatelů zároveň (v jeden čas). S tím jak Web2py se session zachází (odlogovávání) to nepomůže.
Geonames.. ano, mám vytvořený účet s tímto loginem, heslo L0vegeonames
jsou tam k dispozici nějaké web services (neplacené a placené) a dataset PSČ
Vpodstatě bych rád věděl, zda by k něčemu pomohlo, že mají ke stažení dataset PSČ.. a co by to znamenalo, když by se tyto adresy použily lokálně v Sahana image.
Někde jsem četl, že Sahana umí detekovat adresy a pak jim podle toho přidává Lat Lon
na to je pak služba Geocoder (zapnutelná v konfiguraci mapy)
zdrojový kód tady https://github.com/alexreisner/geocoder
laicky si to představuji, že uživatel po napsání adresy do formuláře nahoře v liště v modulu Map dostane automaticky bod na mapě... (?) Což je celkem pěkná služba, pokud by nebyla závislá na externím serveru. (ještě nemluvím o mapovém podkladu, jen o vrstvě adres)
ostatní nevím..
je tam
#settings.gis.max_features = 1000
vy píšete
settings.gis.max_features = 2000
nevim kde se to projeví, tak se na to ptám... asi tedy ok(?)
ad SOLR... mé dřívější nápady o Sahaně se kdysi zabývaly myšlenkou fulltextového hledání napříč celou Sahanou. na wiki sahany tam byl nějaký hrubý blueprint. Poptal jsem k tomu analýzu a návrh řešení, na což jsem dostal odpověď že to je vzhledem ke struktuře modulů a kódů velmi těžké a proto to taky v Sahaně není. Hledá se vždy jen v rámci nějaké tabulky ..ale není to napříč moduly. Pokus vytvořit fulltext hledání byl plný kompromisů, který nakonec vypadal velmi nepoužitelně.
Já jakž-takž pochopil, že to není v Sahaně zrovna atraktivní úkol. Ale vlastně jsem také pojal nedůvěru k tvrzení mr. Skřivánka, protože ve mě převážilo přesvědčení, že jeho analýza Sahany nebyla až tak zkušená, nebo prostě říkal co se hodilo jeho zaměstnavateli.
Teď po vás nechci to používat, bude mi stačit potvrdit, že to teď nemá smysl řešit, protože by to bylo moc energie a málo muziky.
hledal jsem ten úplný soubor 000_config.py ..ten je v našem repozitáři kde?
pokusím se ještě rozklíčovat některé vlastnosti. Některé funkce jsem totiž na velmi krátkou dobu viděl, když jsem vyráběl vlastní pokusy, ale pak zas mi zmizely z dohledu... Na to jsem byl krátký.
Mapy -
#settings.gis.max_features = 1000
je pouze nějaká vzorová hodnota, která je uvedena jako příklad vconfig.py
(což je ten soubor, na který se ptáte). Výchozí hodnoty jsou v souborus3cfg.py
a tam jsou 2000. Projeví se to tak, že pokud na mapě vyzoomujete tak vysoko, že byste měl vidět více bodů než je tento limit, Sahana Vás zdrbe a ukáže jen počet prvků nastavený limitem.SOLR - Myslím, že tohle snad ani není problém řešitelný v Sahaně. Sahan v celém tom stacku sedí strašně vysoko a ani databázi si sama nijak neřeší, protože to za ni dělá We2py framework se svou vrstvou abstrakce a objektového zpracování. Sahana tak vlastně ani neví na jaké databázi jede a je jí to úplně jedno. SOLR je svým způsobem databáze, takže taková věc by musela být řešena přímo ve Web2py.
mentioned in commit
768d8b9680
super.. co se teoreticky stane, když bude hodnota #settings.gis.max_features = 8000 ? Zkolabuje to browser, budu čekat půl hodiny na načtení, nebo to zaplní paměť? Spekuluji, že tyhle limity byly nastavovány před pár lety, od té doby se dost změnilo co do výkonu. Teď jsme ve fázi experimentů, kdy potřebuji najít hranice Sahany, abych později nebyl překvapený. Nemusíte vysvětlovat, pokud to je rychlejší ověřit prakticky.
k settingům se vrátím, bude jich víc, děkuji,
Nastaveno
Očekávám nepatrně pomalejší načítání dat v důsledku zvětšení jejich objemu (na hodně pomalých internetech to bude znát víc) a delší čas potřebný k vykreslení více bodů. To už se děje na straně klienta, takže tam je to omezeno systémovými prostředky a stabilitou prohlížeče na klientské straně. Technické limity omezující množství prvků tu prakticky nejsou (resp. budou tak u milionů položek), takže jediným limitujícím faktorem je, jak dlouho je uživatel schopen čekat, než ho jeho systém opět pustí ke slovu. Případné další úpravy nebo potvrzení hodnot mi prosím dejte vědět, commitnu je.
Díky, budu to pozorovat, doma to bylo pomalé vždycky. Teď mi příjde, že okno mapy něco načte, ale po změně zoomu už se nic nezmění, Vypadá to jako by byl nějaký timeout, možná na webserveru. Ostatní prvky stránky reagují.
Docela jsem nepochopil proč tohle jejich řešení dělá takové problémy s načítáním většího množství dat. Od toho tam přeci je to shlukování bodu, ne? Ono to čte komplet všechno? LOL, Praktická zkušenost s jinými řešeními (mapy.cz, google a jiné mapy http://spotter.cz/cz/18-mapy.htm nekolabují když mají zobrazit jedno kolečko v kterém je číslo 3194 ...
Tady by se měli chlapci ze Sahany asi zamyslet co s tím :)
(nemusíte vysvětlovat... to by asi bylo na dlouho )
mentioned in issue #100
mentioned in issue #75
changed milestone to %2
mentioned in issue #223
closed