OpenStreetMap

Kolesár's diary

Recent diary entries

Restoring measurements from crashed database of Tower Collector

Posted by Kolesár on 29 July 2015 in English (English)

I’m an OpenCellID contributor. I use Tower Collector application on Android phones for recording cell data. I have recorded data for more than 500,000 locations.

One day one of my phones has shut down on a trip after 80 kilometers which I will never do again. I have checked Locus where the tracklog stopped: a few kilometers behind. Started Tower Collector, it showed zero locations! Oh my god. I had another trip previous day which was not uploaded yet.

This device was rooted, started root browser, checked the application’s data directory:

	/data/data/info.zamojski.soft.towercollector

In directory “databases” I have seen an empty measurements.db (a few kB), but there was another file: measurements.db.back with 600 kB! Made a backup copy of the whole directory and resumed my route.

At home I have checked the db. It is an sqlite database, but has been corrupted.

	sqlite> pragma integrity_check;
	Error: database disk image is malformed

I have made a dump of the database:

	echo .dump | sqlite3 measurements.db.back > measurements.sql

There were 2059 measurements for 76 cells, valuable data. How to restore them? Load back to Tower Collector. I did not have time for that for weeks, but continued collecting new data. I was frustrated because this phone did not remember the cells collected before the crash, displayed a most of cells as new. I have also missed the data from that two trips. Some weeks later I have tried to load data.

At first I have created a new database using the recovered data but I have failed many times. I replaced measurements.db with the new one, app crashed (SQLiteCantOpenDatabaseException). Checked directory and file permissions via Root Browser, it showed root as owner of every file, but later I have checked the same thing via adb and it showed totally different owners: every app has a userid and owner should be set correctly.

After setting owner for the database, I had another kind of crash: Tower Collector said “upgrading database” and crashed again. Stack trace had an SQL statement: “CREATE TABLE cells” which failed because cells table already existed. Why does it upgrade? I did not see any difference in schema of old and current database.

Then I started a different way. Prepared only data from the dump: kept only INSERT statements for the following tables:

	INSERT INTO "measurements" ...
	INSERT INTO "cells_archive" ...
	INSERT INTO "cells" ...

Uploaded this file via adb:

	adb push inserts.sql /data/data/info.zamojski.soft.towercollector/databases/inserts.sql

Then restored the last working measurements.db and logged in via adb:

	$ adb shell
	~ # cd /data/data/info.zamojski.soft.towercollector/databases
	# sqlite3 measurements.db

Here I had an almost empty database, only cells_archive table had 1227 rows. I have truncated this to make history clean:

	# DELETE FROM cells_archive;

Then I imported the SQL file just uploaded:

	# .read inserts.sql

Logged out and tested: app displayed 2059 measurements for 76 cells. Quickly uploaded to OpenCellID and checked newly uploaded measurements there.

Then I merged the new cells captured since the failure. Dumped cells_archive from the previously backed up version of measurements.db, replaced table name “cells_archive” to “cells”, loaded into the database using the same way and then deleted them. This database has a trigger which archives rows deleted from table “cells” to “cells_archive” ignoring duplicates.

I had seen 6176 cells before the crash. Since then there were 1227 new, merging resulted 6793 cells, 617 new. The rest were duplicates.

The last step was setting total number of locations to the sum measurements before and after crash:

UPDATE stats SET total_locations = 156440+29641 WHERE row_id=1;

Now I have a database which knows all cells and number of locations since I have started collecting data. I am happy.

Location: Nagyberény, Siófoki járás, Somogy, Southern Transdanubia, Transdanubia, 8656, Hungary

utak durva hibáinak kimutatása

Posted by Kolesár on 12 September 2014 in Hungarian (Magyar)

Eredetileg szögletes (nem szép ívekkel megrajzolt) vasútvonalakat kerestem, helyette durva hibákba botlottam. Készítettem egy postgresql függvényt, ami megmutatja, mi a legnagyobb törésszög a vonalban (GPL):

	CREATE OR REPLACE FUNCTION largestangle (
		geom geometry
	)
	RETURNS float
	AS
	$$
	DECLARE
		num integer;
		azimuth float;
		previous float;
		max float;
		angle float;

	BEGIN
		num := ST_NumPoints(geom)-1;
		max = 0;
		previous = null;
		FOR i IN 1..num LOOP
			azimuth = ST_Azimuth(ST_PointN(geom, i), ST_PointN(geom, i+1))*180/PI();
			IF previous IS NOT NULL THEN
				angle = azimuth-previous;
				if (angle<0) THEN angle = angle + 360; END IF;
				if (angle>180) THEN angle = angle - 360; END IF;
				angle = ABS(angle);
				if (angle>max) THEN max = angle; END IF;
			END IF;
			previous = azimuth;
		END LOOP;
		RETURN max;
	END;
	$$
	LANGUAGE 'plpgsql';

Kikerestem Magyarország vasútvonalai közül azokat, amelyekben két egymást követő pont között 100 foknál nagyobb törés van:

	SELECT osm_id, railway, largestangle(way)
	FROM planet_osm_line
	WHERE railway IS NOT NULL
	AND largestangle(way)>100
	ORDER BY largestangle(way) DESC

Az eredmény lesújtó:

	67238470;"light_rail";180
	121097646;"tram";180
	123907293;"platform";179.955851775949
	211273169;"rail";179.292086339494
	40764520;"rail";179.192081204579
	221864293;"rail";179.017371190472
	87763263;"rail";178.891823334706
	87975409;"rail";178.328305034132
	294593714;"rail";177.532887205442
	249158915;"rail";176.432827720348
	261528683;"rail";176.093856853854
	266535726;"rail";175.735610193293
	228949256;"rail";175.069038113852
	231714208;"rail";174.456231436573
	254601660;"rail";174.429655532425
	151982042;"rail";174.073601056486
	83250577;"abandoned";173.916391809453
	58680396;"tram";172.847818564358
	231156588;"rail";172.232675767268
	230505264;"rail";172.010225172665
	264239018;"disused";171.013974128316
	96583460;"rail";170.95014069881
	169139414;"rail";170.646584743656
	178696845;"tram";169.978759451508
	151987089;"rail";169.850101980453
	169139416;"rail";169.252730579368
	154513149;"platform";168.644987907461
	169139418;"rail";166.855496170685
	300210242;"rail";166.492269214075
	231714246;"rail";165.88889681817
	25717783;"rail";164.191851861276
	242217332;"rail";161.720967385473
	169015068;"tram";157.185985623234
	96621059;"rail";156.689293148707
	165028710;"rail";154.941354138393
	121097675;"construction";151.529941313625
	156546547;"rail";151.08146686337
	48655425;"platform";130.166176320385
	229989396;"rail";117.725075097282
	48655422;"platform";115.538929552111
	54308577;"abandoned";111.828437618505
	103336934;"disused";106.292185094081
	25720396;"tram";103.772617080563
	235480246;"platform";101.745332022293
	216724982;"platform";100.876472649506
	48655420;"platform";100.638820505008
	230507188;"platform";100.13953405001

A 180 fokosak azonos töréspontba tértek vissza, a többi pedig általában lapos Z alakban kétszer visszafordult. A 178 feletti első nyolcat gyorsan javítottam, a többit meghagyom a lelkes közösségnek.

Az első oszlopban szereplő azonosítót könnyen be lehet másolni JOSM-be a Fájl / Objektumok letöltése (Ctrl+Shift+O) paranccsal, az objektum típusát elég az első alkalommal beállítani vonalra, megjegyzi. A vonalak kijelölve megjelennek az irány-nyilak, ezen lehet meglátni, hogy hol törik meg hegyes szögben.

Ha nekiállsz, dobj egy üzenetet, hogy ne ütközzünk össze.

házszámozás tapasztalatai

Posted by Kolesár on 25 May 2014 in Hungarian (Magyar)

Kipróbáltam, milyen házszámokat gyűjteni kertvárosi környezetben, ahol előzőleg már megrajzolták műholdról az épületek körvonalait. Nyomtatva elvittem magammal egy A/4-es lapon egy körülbelül 15x15 háznyi területet.

A bejárás másfél óráig tartott, ebből egy órát mentem, fél órát álltam. A mozgás közbeni átlagsebességem gps szerint 3.3 km/h, teljes átlag 2.1 km/h. Izgalmas adat, hogy a nettó 2.2 km-es táv a gps szerint 3.8 km volt. A különbség egyik fele a GPSMAP 60 CSx szokásos kevergése, a másik pedig az oda-vissza újra megtett utakból ered.

114 házszámot gyűjtöttem, ezek között 13 új épület volt, amelyek egy része nem volt meg még műholdképen, mások meg ott voltak, csak általában fa takarásában. Ezeket helyben felrajzoltam a környező házakhoz képest papírra. Négy üres telken volt házszám, de nem volt épület, így itt a kapu közelébe helyezett node hordozza a házszámot.

Nem jártam be a teljes kinyomtatott területet, nem maradt több időm. Igyekeztem teljes utcákon végigmenni, ez a kiválasztott utcákra sikerült is, de terület-alapon szemlélve mégsem lett teljes a felmérés, mert az utcákat cikkcakkban jártam be, és egy helyen nem zártam be a háztömböt, a két hosszú oldala mellett csak az egyik rövidet jártam be, ezt majd pótolom.

Másik tanulság, hogy kertvárosban érdemes egyszerre nézni mindkét oldalt, felesleges lenne a bal és jobb oldalt külön felmérni. Figyelni kell viszont arra, hogy ne maradjon ki út a cikkcakk útvonal miatt. Szélesebb, nagyobb forgalmú utaknál nem lehet egyszerre mindkét oldalt figyelni, oda két bejárás tervezendő.

A házak felénél nem volt kiírva házszám. Sok segítséget jelentett, hogy Érden a szemeteskukákra kötelező felragasztani egy matricát, amin rajta van a pontos cím. Az esetek jelentős részében tehát a kuka pótolta a ki nem írt házszámot. Máshol egyértelmű volt a szomszédos házak száma alapján. A papíron zárójelbe tettem a házszámot, ha nem leolvasásból, hanem következtetésből származott.

Ha a ház faház volt, akkor ezt külön jelöltem a papíron és a feldolgozáskor building:material=wood címkét kaptak. Utóbb rájöttem, hogy felírhattam volna a szintek számát is, ez elmaradt.

Ha már végigmentem, felmértem a tűzcsapokat és a távvezeték-oszlopokat is. A tűzcsapokra fel volt írva egy háromjegyű sorszám (ez eléggé ritka), valamint a kerítésekre rögzített, tűzcsapot jelző táblára a nyomása is, így lett ref é fire_hydrant:pressure adat is. Külön nem írtam fel, de utóbb be tudtam azt is írni, hogy fire_hydrant:position=green, vagyis zöldfelületen volt a tűzcsap.

A távvezetékek oszlopain egyenként volt ötjegyű azonosító szám, ezen kívül felírtam az oszlopok anyagát is (beton, fém). Volt két transzformátor is, itt is felírtam a számot. Mivel oszlopokon voltak, az oszlop node-ján a ref az oszlop száma volt, így a trafó azonosítóját ref:transformer néven tároltam el.

Mivel szemmel láthatóan középfeszültségű vezetékek voltak (valószínűleg 20 kV), az oszlopok power=pole címkét kaptak, a vezeték pedig power=minor_line lett. Eddig sajnos nem különböztettem meg ezeket a nagyfeszültségű átviteli hálózattól, most már odafigyelek. Utóbbi 100 kV feletti, általában több vezetékből és magasabb fémoszlopokból áll, a címkézése power=tower és power=line. A mapnik megkülönbözteti vastagságban és nagyítási szintben is, fontos a különbség.

Talán nem kell mondanom, hogy a gps-el rögzített nyomvonal tökéletesen alkalmatlan térképezésre, nem is azért vittem, hanem útpontok gyors rögzítésére. A tűzcsapok és távvezeték-oszlopok kaptak saját útpontot. Még egy célra volt jó a gps, pontosabban az okostelefon: amikor szemmel láthatóan hiányzott egy ház a térképről és elsőre nem volt egyértelmű, hogy melyik az új, ami annyira friss hogy még nincs a műholdképen, akkor megnéztem Locusban, hogy hol is vagyok pontosan a térképen. Mivel a telekre úgysem mehettem be, az épületet már a többihez igazítva, szemre rajzoltam papírra.

Az A/4-es papír a házszámozáshoz elég nagy volt, de a tűzcsapok és elektromos vezetékek adatai már csak nagyon apró betűkkel fértek el rajta. Legközelebb nagyobb vagy több papírra fogok nyomtatni. A tűzcsap- és oszlopadatokat érdemes külön papíron, vagy a lap szélén, esetleg hátulján táblázatosan vezetni az útpontok növekvő számával, mert utólag nehéz összevadászni a papírról.

Nagyon praktikus, ha a papírt tartja valami kemény felület. Most egy szokásos A/5-ös jegyzetfüzetet vittem magammal, félbehajtottam rá az A/4-es térképet. Nem volt elég tartása és zavaró volt a félbehajtás is, jobb lett volna egy csíptetős műanyag lap, amiket konferenciákon szoktak osztogatni.

A feldolgozás kezdetén beszkenneltem a papírlapot, majd JOSM-ben a PicLayer kiegészítővel betettem háttérképként. Gyorsan be tudtam illeszteni a rajz mögé, teljesen jól illeszkedett. Így nem kellett kétfelé figyelnem, és abból sem származott hiba, hogy esetleg másik épületre másolom fel a papírra írt házszámot. Kifejezetten jól jött, hogy a papíron a házat jelentő felületre írtam a számot, így teljesen egyértelmű volt, hogy egy adott körvonalra milyen címkét tegyek.

Ma mindezt meg is szerkesztettem, már bent van az adatbázisban. http://www.openstreetmap.org/#map=17/47.42756/18.87227

A mapnik térkép nem jeleníti meg a tűzcsapokat és a transzformátorokat, de a távvezeték és oszlopai látszanak a Szövő utca mentén.

András

Location: Fenyves-Parkváros, Érd, Érdi járás, Pest megye, Közép-Magyarország, 2030, Magyarország