Hruške, jabuke, jablane, čežane.

Geodetska uprava Republike Slovenije daje na uporabo nekatere “brezplačne” geodetske podatke. Uporaba ni čisto brez omejitev, ampak so pa na voljo takoj, brez križev z birokracijo. Tudi čisto brezplačni niso, vsaj ne za komercialno rabo – od vas bojo podatki zahtevali najmanj to, da nejasne pogoje uporabe, v katerih je nepooblaščena uporaba celo zagrožena z globo, pregleda pravniško oko.

Če prepustimo pravniške zadeve pravnikom, nam ostane še tehnični del, ki pa v sebi skriva prav toliko nejasnosti. Geodetski podatki, ki so na voljo, so namreč zapisani v Slovenskem prostorskem referenčnem sistemu, bodisi D48/GK ali D96/TM. Spletne aplikacije po večini uporabljajo WGS84, ki je uporaben za celotno Zemljo, a je zato na lokalnem nivoju nekoliko manj natančen. WGS84 sicer uporablja tudi standard GPS, ki ga poznate iz raznih garminov in nekoliko dražjih telefonov. Za pretvarjanje iz enega prostorskega referenčnega sistema v drugega sicer obstajajo “recepti”, ki v sebi skrivajo 7 parametrov, s katerimi opišemo transformacije.

Transformacija iz D48/GK - neuspešno

Ob uporabi napačnih vrednosti parametrov se seveda transformacija izvede narobe, kot rezultat pa so potem meje občine ali države na zemljevidu, ko jih primerjaš z npr. Google maps, zamaknjene. Seveda “ročno” popravljanje odpade: če na eni strani države še ujameš pravo koordinato, se ti na drugem koncu sfiži. Zato je potrebno poznati pravih 7 vrednosti parametrov. No, za te transformacije sicer obstaja register, ki ga vzdržuje European Petroleum Survey Group – EPSG. V tem registru je zbrano malo morje informacij o prostorskih referenčnih sistemih, vendar se izkaže, da je točnost teh podatkov včasih vprašljiva.

V starih časih, preden so “izumili” Greenwich, oz. se dogovorili, da je nulti poldnevnik Greenwich, so za nulti poldnevnik jemali marsikaj. Nekateri “veliki imperiji” so vzeli sedež imperija – Italija je vzela Rim, Nemčija Berlin, Francija Pariz, Anglija pa London, oz. natančneje del Londona, poimenovan Greenwich. Kasneje je Greenwich – predvsem zaradi svoje razširjenosti za pomorsko navigacijo – postal tudi mednarodni referenčni poldnevnik.

Transformacija iz D48/GK - zmaga!

No, ker so bili v uporabi različni poldnevniki, se je moralo izvesti tudi prehod na novi standard – Greenwich. Za Slovenijo, takrat sicer Avstro-Ogrsko, je geodetske podatke urejal Militärgeographisches institut oz. MGI. Za referenčni poldnevnik je MGI vzel otok Hierro, ki je najzahodnejši del “Starega sveta”, ki so ga poznali do Kolumbovega podviga. Po razpadu Avstro-Ogrske je na njenem območju nastalo več držav, ki so nasledile dediščino MGI. Te države so kasneje tudi izvedle prehod na Greenwich kot referenčni poldnevnik, a pri tem je prišlo do neskladja – Avstrija je za poldnevnik Hierro vzela, da leži na 17° 40′ 00″ zahodno, medtem ko sta Jugoslavija in Madžarska privzeli, da je Hierro na 17° 39′ 46” zahodno. Pri tem je nastalo za 14” razlike, kar je ravno okrog 300m in dovolj, da meje območja na Google maps izgledajo popolnoma napačno.

Zakaj je do te “napake” prišlo in kdo je kriv je zdaj že vseeno, važno pa je, da smo dobili prave parametre, tako da zdaj transformacija deluje, da so podatki v WGS84 in da se projekcije pokrijejo. No, sicer še vedno nisem stoodstotno prepričan, da je to prava transformacija, ampak sodeč po odstopanjih je kar blizu. Za transformacijo sem vzel WKT za SRS 3787, zraven pa pri 6. parametru odštel 14 (za 14 sekund), da se odstopanje popravi.

So you want to use Ned Batchelder’s coverage.py and don’t want to install another Django app, don’t want to patch Django files or you just can’t wait for bug #4501 to be resolved.

Me too.

So I took a couple of minutes and put together this very very DRY-ish djangocoverage module, which binds together coverage.py with Django. It is based on a bit aged Siddharta Govindaraj’s snippet. Initially I intended to monkeypatch Django from manage.py, but finding out about TEST_RUNNER setting, I made a saner decision and provided a test runner.

import coverage

def coverage_decorator(func, omit_prefixes=None):
 "Decorator for Django's built in test runner"
 def _inner_coverage(*args, **kwargs):
 from django.conf import settings
 c = coverage.coverage()
 c.erase()
 c.start()

 retval = func(*args, **kwargs)

 c.stop()

 coverage_dir = getattr(settings, 'COVERAGE_DIR', './coverage_results')
 c.html_report(directory=coverage_dir, omit_prefixes=omit_prefixes)
 return retval
 return _inner_coverage

def coverage_test_runner(*args, **kwargs):
 "Test runner you can put in your application's settings file"
 from django.test import simple
 return coverage_decorator(simple.run_tests)(*args, **kwargs)

What you want to do is put djangocoverage.py somewhere where Python can find it and put “TEST_RUNNER=’djangocoverage.coverage_test_runner’” line into your settings.py.

Then, running tests is the same as it was. If you’re already using custom test runner, then you can easily integrate coverage.py using decorator, if you haven’t yet been using coverage.py. HTML report is written out in ./coverage_report, and you can also adjust that via COVERAGE_DIR setting. Hope you find it helpful.

Že dlje časa sem imel v mislih, da bi zbral skupaj drobce kode, ki sem jih potreboval za manjše projekte v Djangu, jih uredil in dal ven kot Slovenski localflavor modul za Django framework. No, ta čas je končno tu, saj sem zaradi prejšnjega blogposta potreboval spisat algoritem, ki zna preverit, če je EMŠO pravilna, za to pa sem uporabil kar Django forms.

Koda se nahaja na GitHubu, projektu pa je ime django-localflavor-sl. Vsake toliko časa bom pogledal, če je kak “fork” in kodo združil.

Some time ago, when me and Jure were hacking Prevoz a bit, there was a question of handling a complex form. One could split a form into smaller subforms and validate each separately, use a SuperForm or override a lengthy method, that spits out HTML.

We eventually figured that subclassing did just the thing we needed and did the “happy-djangoinan-dance”.

Ko folk razmišlja o skupnem gostovanju, je včasih težko obiti dejstvo, da je Python razmeroma požrešen, kar se tiče porabe RAM-a. Na Webfactionu je en ukaz, s katerim lahko izračunamo, koliko RAMa posamezen program uporablja. Sam sem jo nekoliko spremenil, da prikazuje samo Python:

ps -u username -o pid,rss,command | grep -v awk | \\
  awk '/python/ {print $0 ; sum+=$2} END {print "Total", sum}'

Django lahko prek FastCGI poganjamo na dva načina, z večimi nitmi in z večimi procesi. Če ga poganjamo z večimi procesi (prefork), je izpis zgornjega ukaza sledeč:

 6646  4320 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6647  3788 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6648  3800 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6649  9604 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6650  9608 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
 6651  8512 python prevoz/manage.py runfcgi method=prefork host=127.0.0.1 port=34001
Total 39632

Če ga poganjamo večnitno (threaded) pa sledeč:

 6747 10236 python prevoz/manage.py runfcgi method=threaded host=127.0.0.1 port=34001
Total 10236

Pri tem gre omeniti, da sem pred merjenjem trikrat pognal ukaz httrack 127.0.0.1 -c10, ki prezrcali celotno stran, projekt, ki sem ga uporabil za testiranje, pa je bil razmeroma enostaven. Django pa je bil na FastCGI priklenjen prek flup r2347 in LigHTTPd spletnega strežnika.

Z večnitnim načinom lahko tako prihranimo precej RAM-a, velja pa omeniti, da Python v osnovi ni večniten in se bo pravzaprav naenkrat obravnaval le en zahtevek, čeprav bo vmes prihajalo do preklopov med nitmi.