| 00:23.42 | BabelO | good night |
| 01:36.39 | *** join/#htc-linux l33tlinuxh4x0r (i=Brice@adsl-144-143-75.rmo.bellsouth.net) |
| 01:45.41 | *** part/#htc-linux l33tlinuxh4x0r (i=Brice@adsl-144-143-75.rmo.bellsouth.net) |
| 02:34.22 | *** join/#htc-linux swc666 (n=no@24.143.67.18) |
| 02:39.44 | swc666 | omgwtfroflmfaobrb |
| 02:40.45 | swc666 | i think i just summed up my weekend with 17 letters |
| 03:25.33 | *** join/#htc-linux ndavey (n=neil@pc075650.workstation.griffith.edu.au) |
| 04:29.42 | *** join/#htc-linux joschkopf79 (n=joschi@ACADC35B.ipt.aol.com) |
| 05:02.58 | *** join/#htc-linux joschkop179 (n=joschi@ACADC35B.ipt.aol.com) |
| 05:18.42 | *** join/#htc-linux goxboxlive (n=goxboxli@195.159.97.196) |
| 06:21.57 | *** join/#htc-linux BabelO (n=Fabrice@unaffiliated/babelo) |
| 06:51.54 | *** join/#htc-linux rob_w|laptop (n=rob@p549B9D94.dip0.t-ipconnect.de) |
| 06:56.57 | *** join/#htc-linux kiozen (n=kiozen@p5492A691.dip0.t-ipconnect.de) |
| 08:16.05 | *** join/#htc-linux BabelO_ (n=fcr@unaffiliated/babelo) |
| 09:08.11 | BabelO_ | hi |
| 09:10.30 | kiozen | BabelO_: morning :) |
| 09:19.50 | goxboxlive | hi |
| 09:39.13 | *** join/#htc-linux patoche (n=patoche@77.197.38.195) |
| 09:47.53 | *** join/#htc-linux ndavey (n=neil@60-240-227-199-vic-pppoe.tpgi.com.au) |
| 10:02.53 | BabelO_ | goxboxlive: did you try to integrate camera in hh kernel ? |
| 10:06.26 | *** join/#htc-linux rmoravcik (n=rmoravci@ip-89-102-255-171.karneval.cz) |
| 10:14.09 | goxboxlive | BabelO_: no, i dont think there is any cam driver yet. AFAIK nobody is working on it. |
| 10:14.28 | BabelO_ | goxboxlive: do i have to buy an universal ? :) |
| 10:24.02 | goxboxlive | BabelO_: if ytou want to waste your money, then yes :-) |
| 10:24.09 | goxboxlive | otherwise, no. |
| 10:25.42 | BabelO_ | goxboxlive: i ve not the same waf that kiozen, mine is a little more high :) |
| 10:25.54 | BabelO_ | goxboxlive: i have to look at n800 before ;) |
| 10:26.11 | goxboxlive | BabelO_: I have tried to use Qtopie as main phone on both universal and mio, but they both lack important support so i cant use them as my everyday phone. One particular important task i need is support for syncing my calandar and tasks with a exchnage server. |
| 10:26.33 | *** join/#htc-linux Marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 10:27.01 | goxboxlive | has n800 phone support? Isent it just a surf board/pda? (n810) |
| 10:27.07 | BabelO_ | goxboxlive: i understand this, but there is only one plugin these day which can sync with a microsoft exchange server |
| 10:27.18 | BabelO_ | goxboxlive: else you have to sync your gmail with exchange |
| 10:27.22 | BabelO_ | then your phone with gmail ;) |
| 10:28.14 | kiozen | yes WAF is a bad thing :) |
| 10:28.47 | BabelO_ | goxboxlive: no phone support on n800 but a 800x480 display, wifi + bt + fm radio +usb host , a good gadget . And usefull in car if you want children keep quite :) |
| 10:32.13 | kiozen | BabelO_: did you buy a new monitor together with your new pc ? |
| 10:34.01 | BabelO_ | kiozen: no i ve already one from next year, acer 2216WD , the good point for me is that i can use it as tv |
| 10:34.52 | kiozen | BabelO_: hm, looking for a good 24'' |
| 10:36.40 | BabelO_ | kiozen: ah :)Swiss customers run our application on 30" :) they are crazy |
| 10:37.10 | kiozen | 30'' would be fine too, where is one? |
| 10:38.27 | BabelO_ | kiozen: http://www.ldlc.com/fiche/PB00059008.html |
| 10:39.29 | BabelO_ | kiozen: enough ? 2560 x 1600 pixels |
| 10:39.33 | kiozen | <PROTECTED> |
| 10:39.39 | *** join/#htc-linux the_sys0p (i=the_sys0@gateway/tor/x-10ebd5f278159b77) |
| 10:39.43 | kiozen | pixels yes, but contrast is low |
| 10:39.54 | BabelO_ | mine is only 1680x1050, i think cr2 had a better resultion on his laptop |
| 10:40.04 | BabelO_ | yes |
| 10:40.50 | cr2 | hi |
| 10:40.50 | kiozen | got 1920x1200 |
| 10:41.02 | kiozen | but it's not that much fun on 17'' |
| 10:41.07 | cr2 | BabelO_: Poids 12 kilogramme(s) |
| 10:41.07 | kiozen | hi dr2 |
| 10:41.14 | kiozen | hi cr2 |
| 10:41.30 | kiozen | don't care about the weight ;) |
| 10:41.46 | kiozen | my table can push 80kg |
| 10:42.03 | BabelO_ | hi cr2 |
| 10:42.15 | kiozen | cr2: cool doc you found |
| 10:42.29 | kiozen | but it boils down to ellips=intl |
| 10:42.54 | cr2 | kiozen: ED50 and WGS84 give 2 different results |
| 10:43.12 | cr2 | kiozen: all other 8 are more or less the same |
| 10:43.23 | kiozen | could it be that the conversion ED50 -> wgs84 with 3 coef only ist too dirty? |
| 10:43.26 | cr2 | i.e. very close to these 2 |
| 10:43.51 | kiozen | I have the same problem with GK/Potsdam -> WGS84 |
| 10:43.55 | cr2 | qgis does not list any weird 7 param towgs84= data |
| 10:44.22 | kiozen | that's why I have to use that BETA2007 file for correction |
| 10:44.35 | cr2 | do you know any 7 param values for ED50 -> WGS84 ? |
| 10:44.36 | kiozen | without the error is ~100m to the west |
| 10:44.48 | kiozen | no |
| 10:44.51 | cr2 | ok, that may be. |
| 10:45.03 | cr2 | hmm. something to look for. |
| 10:45.18 | kiozen | the param differ on location |
| 10:45.18 | cr2 | i still don't understand why such things happen. |
| 10:45.44 | cr2 | convert to geocentric and back, if the performance does not matter. |
| 10:45.46 | cr2 | ok. |
| 10:45.47 | kiozen | gdal seems to use 3 param transform with these old datums |
| 10:46.00 | kiozen | 7 param would be more precise |
| 10:46.20 | cr2 | yes |
| 10:46.31 | cr2 | but it's still an approximation |
| 10:47.00 | kiozen | as long as the error is < 1m I am fine, but 100m is too much |
| 10:47.45 | kiozen | guess I have to bug the proj4 mailing list this afternoon :) |
| 10:48.17 | cr2 | ok. |
| 10:48.21 | kiozen | I have tested the other UTM grid points. They all have the expected easting / northing |
| 10:49.44 | kiozen | thus referencing is ok, it's just the UTM ED50 -> LongLat WGS84 conversion |
| 10:50.23 | cr2 | i don't understand why proj4 is so wgs84-centric |
| 10:50.47 | cr2 | the spherical troubles also come from that area. |
| 10:52.05 | kiozen | because every doe joe is using wgs84 |
| 10:52.27 | kiozen | a bit like M$ ;) |
| 10:52.43 | cr2 | hehe. |
| 10:53.05 | cr2 | i'm for geocentric. |
| 10:53.26 | cr2 | it's the only physically sensible coordinate system. |
| 10:53.44 | cr2 | and every gps receiver must support it. |
| 10:54.02 | kiozen | ok, once we gained world domination we can do geocentric :) |
| 10:54.09 | cr2 | :) |
| 10:54.26 | kiozen | #ifdef WORLD_DOMINATION ... |
| 10:54.39 | cr2 | galileo was wrong after all :) |
| 10:54.41 | *** join/#htc-linux ImCoKeMaN (n=imcokema@pool-72-70-180-20.hrbgpa.fios.verizon.net) |
| 10:56.37 | BabelO_ | cr2: i use your method to create maps for roadmap, works fine ;) |
| 10:57.46 | cr2 | BabelO: we need a tool for simplifying the polylines. they have excessive amount of nodes. |
| 10:58.10 | BabelO_ | cr2: yes, i also think i need 4Gb on my computer ;) |
| 10:58.15 | cr2 | BabelO_: for polygons it's v.dissolve from grass. |
| 10:58.21 | BabelO_ | have to wait two month |
| 10:58.30 | cr2 | ok. |
| 10:58.53 | cr2 | i think gpsbabel had it implemented |
| 10:59.01 | cr2 | but only for gpx tracks. |
| 10:59.23 | BabelO_ | cr2: i ve tried to do bigger map from .rus sources, is it possible to add elevation like kiozen do ? |
| 11:00.05 | BabelO_ | cr2: it is a good point like latest igo, when you are in alp for example, GPS never see you on the correct road :( |
| 11:00.43 | kiozen | BabelO_: there are scripts out there to convert elevation data into Garmin img format. |
| 11:01.10 | cr2 | kiozen: isn't it 2D by definition ? |
| 11:01.32 | kiozen | gradients ;) |
| 11:01.47 | cr2 | ok. |
| 11:01.58 | kiozen | but the new maps have DEM to do relief shading on the device |
| 11:02.14 | cr2 | i think mkgmap has a rectangular polygon clipper now. |
| 11:02.27 | cr2 | in java ;) |
| 11:02.36 | BabelO_ | kiozen: do you try garmin in Alp, on very small road ? my gps on artemis switch from current road to another on the other side of the mountain :( ( it is tomtom) |
| 11:03.13 | kiozen | Never had a problem, the receiver of the 60SCx is realy good |
| 11:03.40 | kiozen | It only failes on very small gaps |
| 11:03.57 | kiozen | but you won't get there by car :) |
| 11:05.36 | cr2 | sticking to road is bad anyway |
| 11:07.29 | kiozen | not if you have a normal car |
| 11:12.43 | BabelO_ | :) |
| 11:13.30 | BabelO_ | kiozen: do you found how to disable static nav ? |
| 11:13.38 | BabelO_ | kiozen: did you try sirf tools in wince ? |
| 11:14.15 | kiozen | no, didn't manage, the wince tool is my last hope, but no Loox at the moment |
| 11:15.01 | kiozen | lunch time :) |
| 11:16.45 | BabelO_ | me too :) |
| 11:17.23 | *** join/#htc-linux patoche (n=root@77.197.38.195) |
| 11:46.26 | goxboxlive | is there any diffrents in SIRF protcol than in NMEA protocol? |
| 11:46.41 | goxboxlive | With my MIO i can choose to either use sirf or nmea |
| 11:46.59 | goxboxlive | with nmea data smaps out, but with sirf it freezes |
| 11:51.57 | kiozen | goxboxlive: nmea is text based, sirf is binary |
| 11:52.22 | kiozen | nmea is some what standard, sirf is proprietary, but it can control the chipset |
| 11:53.03 | kiozen | you have to switch from nmea to sirf by nmea command |
| 11:53.17 | kiozen | that will change baudrate, too |
| 11:53.28 | goxboxlive | kiozen: ok, but why does it freeze when i set it to sirf? |
| 11:53.34 | kiozen | most likely this will fsck you connection |
| 11:54.04 | kiozen | it's the same with my gps mouse |
| 11:54.31 | kiozen | nmea -> sirf is ok, but sirf -> nmea freezes |
| 11:55.40 | kiozen | it's a mess :) |
| 12:00.51 | goxboxlive | ok, thx |
| 12:02.15 | kiozen | welcome :) |
| 12:07.45 | *** join/#htc-linux rmoravci1 (n=rmoravci@gtsgw.ttc.cz) |
| 12:36.03 | cr2 | BabelO_: to work with static navigation is just sending a message |
| 12:36.44 | cr2 | i guess the message can be sent just with echo. |
| 12:37.19 | cr2 | or you can modify sirfmon. |
| 12:37.36 | cr2 | hm. where is my old sirfmon source... |
| 12:37.40 | BabelO_ | cr2: i read many thing and try it on artemis, first i try sirf tools without sucess, and on some artivle they say that 4800 baud is for nmea and 57600 switch to sirf, but i think it is wrong |
| 12:38.16 | BabelO_ | cr2: and it seem than nobody can switch off staticnav |
| 12:39.42 | cr2 | BabelO_: the 4800 and 57600 are standard. after reset |
| 12:40.06 | cr2 | the command is know, but it's the firmware that must honor it. |
| 12:40.44 | cr2 | the sirf3 firmware is included into athena update, but i don't know how to disassemble it properly. |
| 12:49.51 | *** join/#htc-linux rmoravci1 (n=rmoravci@gtsgw.ttc.cz) |
| 13:10.26 | *** join/#htc-linux patoche (n=patoche@77.197.38.195) |
| 13:20.14 | *** join/#htc-linux CVirus (n=GoD@196.205.192.125) |
| 13:24.15 | *** join/#htc-linux CVirus (n=GoD@196.205.192.125) |
| 13:45.39 | *** join/#htc-linux redelf (n=walter@62.13.173.86) |
| 13:46.32 | redelf | hi all |
| 14:01.05 | *** join/#htc-linux ellisway (n=ellis@homealone.good1.com) |
| 14:03.56 | *** join/#htc-linux GPFerror (n=gpferror@76.187.41.132) |
| 14:12.43 | kiozen | cr2: the trick is to add +towgs84=-87.000,-98.000,-121.000 to the projection |
| 14:13.15 | kiozen | however this is not stored in the file :( |
| 14:13.37 | kiozen | on problem less, one more |
| 14:23.12 | cr2 | kiozen: ok, that must have been some weird datum shift. i'm wondering why it's not in the qgis epsg db. |
| 14:23.42 | cr2 | many other such transforms have +towgs84 there. |
| 14:23.44 | kiozen | no it's a general pproblem of ED50->WGS84 |
| 14:23.59 | cr2 | ok. |
| 14:24.12 | kiozen | even datum Potsdam needs those factors |
| 14:24.29 | kiozen | they are stored in BETA2007 for each location in DE |
| 14:25.10 | cr2 | i guess most non-wgs84 datums need it, but some include the values, but others not. |
| 14:26.03 | cr2 | kiozen: i've tested GT yesterday |
| 14:26.44 | kiozen | and? |
| 14:26.45 | cr2 | kiozen: the Coord. format is too strict, it didn't let me even add one extra space between lat and long. |
| 14:27.11 | kiozen | there is a regex in GeomMath.cpp |
| 14:27.11 | cr2 | then there was some warning about missing metadata. |
| 14:27.29 | kiozen | s/GeomMath/GeoMath |
| 14:27.46 | cr2 | but otherwise it works ok. |
| 14:27.51 | kiozen | metadata? |
| 14:28.03 | cr2 | yes, i think so. |
| 14:28.15 | cr2 | but it seemed to be harmless. |
| 14:28.35 | kiozen | just pastbin if you can |
| 14:28.51 | cr2 | so only load/restore the GCPs is missing now. |
| 14:29.13 | cr2 | i need to do it again, then will paste the message |
| 14:30.09 | kiozen | let's try this +wktext to get the +towgs84 key into the file :) |
| 14:32.16 | cr2 | <PROTECTED> |
| 14:34.24 | kiozen | the problem is that this stuff is not stored in the resulting file |
| 14:34.39 | kiozen | and +wktext does not work either |
| 14:35.38 | cr2 | you may use the [][] WKT projection string, but it's _very_ userunfriendly. |
| 14:36.23 | kiozen | it seems that gdal_translate / gdalwarp purges this information |
| 14:36.36 | cr2 | i have a similar problem with google sphere. |
| 14:37.05 | cr2 | because it misses the +ellps |
| 14:37.23 | cr2 | and the latest proj4 says 'ellps' is obligatory |
| 14:37.48 | kiozen | holly-fuckin-dooley! |
| 14:37.57 | kiozen | so close |
| 14:43.27 | cr2 | kiozen: mentioned here : http://www.bias-project.org.uk/ASDARcourse/unit3_slides.pdf |
| 14:43.49 | cr2 | search for ED50 |
| 14:45.59 | *** join/#htc-linux dcordes (n=snoopdog@unaffiliated/dcordes) |
| 14:46.58 | kiozen | but not the trick how to get it into the file. gdal_translate purges the +towgs84 |
| 14:47.16 | dcordes | good day |
| 14:47.59 | kiozen | hi dcordes |
| 14:58.52 | cr2 | kiozen: why do you need it in gdal_translate ? |
| 14:59.52 | kiozen | gdalwarp uses the projection of the GCPs in the source file. the -t_srs parameter is ingnored |
| 15:00.12 | kiozen | thus i have to add the projection right from the beginning |
| 15:00.25 | cr2 | kiozen: ok |
| 15:00.43 | cr2 | hm. but it works for spherical mercator. |
| 15:01.05 | cr2 | well, it does not use towgs84, that's true. |
| 15:01.51 | kiozen | maybe I can add that information later on, I am just writing an email to the gdal list |
| 15:01.58 | cr2 | ok. |
| 15:02.14 | cr2 | warp to +proj=merc datum=WGS84 |
| 15:02.21 | cr2 | it works everywhere :) |
| 15:02.35 | *** join/#htc-linux bernt (n=bernt@dslb-084-061-207-174.pools.arcor-ip.net) |
| 15:02.52 | cr2 | and you can afford it with 2m/pix |
| 15:03.02 | cr2 | you are rotating the picture anyway |
| 15:05.40 | kiozen | cr2: it will make the map look misserable |
| 15:06.22 | kiozen | and rotation will be gone if I align the scan to the utm grid |
| 15:06.55 | kiozen | my colleague doing the scan just did not know ;) |
| 15:06.56 | cr2 | ok, it's a matter of taste. |
| 15:07.23 | kiozen | more a matter of what you are able to read on a pda with sunlight |
| 15:07.36 | cr2 | i'll take some image quality loss over datum shift PITA |
| 15:08.05 | cr2 | if you put the picture quality over all, then you may follow what ozi does |
| 15:08.22 | kiozen | once we figure it out it's no PITA and we have the quality |
| 15:08.25 | cr2 | i.e. do not warp at all, and cs2cs for each gps point. |
| 15:09.11 | kiozen | do you think that is DAU proof? |
| 15:09.25 | cr2 | ok, with some description in help how to do it. |
| 15:09.35 | cr2 | yes, but it costs cpu time=power. |
| 15:10.07 | kiozen | do you read "help" |
| 15:10.09 | kiozen | ? |
| 15:10.10 | kiozen | :) |
| 15:10.28 | cr2 | i know how to use gdal* |
| 15:10.45 | kiozen | once the map is referenced it should not cost more or less |
| 15:10.53 | cr2 | but afaig it's a PITA :) |
| 15:11.14 | cr2 | referenced != warped |
| 15:11.14 | kiozen | yes, agreed until we know how to do this in a DAU proof way |
| 15:11.37 | kiozen | no one wants to warp the map on the fly |
| 15:11.39 | cr2 | don't forget about the equal m/pix |
| 15:11.58 | kiozen | yes that part is still missing |
| 15:12.08 | cr2 | warp means quality loss. even more for the 8bit paletted images. |
| 15:12.50 | cr2 | there will be some m/pix differences even for the very good maps, because of the GCP quality. |
| 15:12.52 | kiozen | sure but IMHO it's the only way to go with scanned maps |
| 15:12.58 | cr2 | but at 2m/pix it's marginal. |
| 15:13.09 | cr2 | ok. |
| 15:13.59 | cr2 | there are many enhancements and improvements we can do later. |
| 15:14.23 | cr2 | load/save is a must :) |
| 15:17.06 | kiozen | yes punching in the same GCPs over and over sucks. |
| 15:19.32 | cr2 | handtyping the coordinates is even more painful. |
| 15:21.16 | kiozen | qlandkarte-> right mouse click on the map -> copy to clipboard :P |
| 15:21.36 | kiozen | you just have to use the right tool chain |
| 15:25.34 | *** part/#htc-linux redelf (n=walter@62.13.173.86) |
| 15:28.01 | cr2 | that assumes you have an .img for that area, and this .img is properly georeferenced too. |
| 15:28.32 | kiozen | don't we have this always ;) |
| 15:29.22 | kiozen | but agreed the str_to_deg should be more open minded |
| 15:31.19 | *** join/#htc-linux redelf (n=nobody@62.13.173.86) |
| 16:03.29 | kiozen | cr2: svn up (load / save gcps) |
| 16:03.45 | cr2 | ok. |
| 16:03.57 | cr2 | btw, USGS DRG Color Palette |
| 16:04.09 | cr2 | http://www.isgs.uiuc.edu/nsdihome/browse/igq/product_001/samplemetadata/drg.txt |
| 16:04.53 | cr2 | compiling |
| 16:06.36 | kiozen | it's less the palette more the algo mapping colors to a fixed value |
| 16:07.23 | kiozen | i wonder if gimp can do this |
| 16:07.23 | cr2 | yes. |
| 16:07.24 | cr2 | .gct ? |
| 16:08.20 | kiozen | ? |
| 16:09.03 | cr2 | i think gimp palette is called palette.gct |
| 16:09.11 | kiozen | ah |
| 16:09.19 | cr2 | then you can reduce the colormap to this loaded palette. |
| 16:13.06 | *** join/#htc-linux TimRiker (n=timr@68-27-168-105.area1.spcsdns.net) |
| 16:16.06 | cr2 | nice :) |
| 16:16.21 | cr2 | need to do more testing in the evening. |
| 16:16.34 | kiozen | yes, please :) |
| 16:17.12 | cr2 | 2 questions. |
| 16:17.28 | kiozen | hm |
| 16:17.29 | cr2 | can i see the warped result ? |
| 16:17.40 | cr2 | immediately |
| 16:18.25 | cr2 | can you add one more text column to the GCPs -> proj. should be empty/unused for now. |
| 16:18.43 | cr2 | otherwise i use qgis to look at the warped file. |
| 16:18.51 | kiozen | go to the "Create map collection from GeoTiff" dialog |
| 16:19.09 | kiozen | create a qmap for the warped tiles |
| 16:19.21 | kiozen | this will add it to the map list, |
| 16:19.24 | cr2 | ok, so it's not a side -by-side |
| 16:19.34 | kiozen | now you can load the warped map by double clcik |
| 16:19.46 | cr2 | and if i want to add more gcps i need to reload. |
| 16:19.54 | cr2 | ok. |
| 16:19.54 | kiozen | no, so far only one canvas |
| 16:20.12 | cr2 | ok. |
| 16:20.44 | kiozen | but the dialogs will keep their data until you close them |
| 16:21.05 | kiozen | to get back to referencing simply reload the tif |
| 16:21.53 | cr2 | good. |
| 16:22.19 | cr2 | one more thing came to my mind. |
| 16:22.31 | *** join/#htc-linux amon_ (n=amon@p508EF3EB.dip.t-dialin.net) |
| 16:22.43 | cr2 | referencing by 2 GCPs. gdalwarp can't do it, qgis can. |
| 16:23.02 | cr2 | it's very simple math. |
| 16:24.12 | BabelO_ | ok i get a n800 now ;) |
| 16:24.18 | cr2 | and the alg order choice. square pixels, affine, quadratic, tps. |
| 16:24.33 | cr2 | BabelO_: not 810 ? |
| 16:24.41 | kiozen | cr2: is it worth the the work? you always know 3 points. |
| 16:25.53 | cr2 | kiozen: unfortunately not. the easiest thing probably is to create the third/forth "virtual" points. |
| 16:25.56 | BabelO_ | cr2: no, price is too much ;) and the difference between this two device is not what i look for |
| 16:26.42 | cr2 | kiozen: and the square pixel transform is useful for the scanned GK sheets. |
| 16:26.50 | cr2 | BabelO_: ok. |
| 16:27.09 | *** join/#htc-linux jeanseb (n=jeanseb@88.164.32.155) |
| 16:27.27 | kiozen | cr2: let's see if that is getting a problem in the future |
| 16:27.32 | cr2 | kiozen: add the text column, i'll take care of the extra math. eventually. |
| 16:27.38 | kiozen | there are still more urgent things |
| 16:27.43 | cr2 | agreed. |
| 16:27.49 | BabelO_ | cr2: can i send you somes patch for BA ? |
| 16:28.00 | cr2 | BabelO_: yes. |
| 16:28.21 | cr2 | i need to commit some n560 patches too. and update the wiki... |
| 16:30.12 | cr2 | kiozen: another thing is how we are going to treat the sheet margins. |
| 16:30.31 | cr2 | kiozen: to create a good mosaic, they need to be chopped off. |
| 16:31.04 | kiozen | the files have to be made perfect befor referencing |
| 16:31.11 | cr2 | but then some clip by polygon is needed. |
| 16:31.25 | cr2 | i've not really understood how to do it in gimp. |
| 16:32.03 | *** join/#htc-linux rob_w|laptop (n=rob@p549B9D94.dip0.t-ipconnect.de) |
| 16:32.22 | kiozen | I would prefer it to have all scanns stitched together, then converted to 8bit and then referenced |
| 16:32.46 | cr2 | it's not always possible. |
| 16:33.18 | cr2 | i've created such 24000x24000 file in gimp, and it's unpleasant to deal with. |
| 16:33.45 | kiozen | :) |
| 16:33.47 | cr2 | 70% of it is transparent. |
| 16:34.00 | BabelO_ | cr2: i try to add backup battery after my patch revert, and i send patch to you |
| 16:34.09 | cr2 | BabelO_: ok. |
| 16:34.36 | kiozen | ah, no, if the tiles are not together you do single files, but then borders are no problem |
| 16:35.04 | cr2 | kiozen: all i tell you are the practical issues i've had in real life, not just to bash you :) |
| 16:35.20 | kiozen | I know ;) |
| 16:35.40 | cr2 | kiozen: i've scanned an A3 album with about 200 pages some time ago. |
| 16:35.53 | cr2 | more than a half a year actually. |
| 16:35.55 | kiozen | long nights :) |
| 16:36.33 | cr2 | it's still not georeferenced because of margins, a bit random sheet rotation, nonlinear printing, etc ... |
| 16:36.52 | cr2 | but i'm close :) |
| 16:37.23 | kiozen | referencing 200 sheets ? puhhhhhhh |
| 16:37.54 | kiozen | I am happy if I get this hiking map into my Loox |
| 16:39.22 | cr2 | that's why i want 2 GCPs first :) |
| 16:41.57 | kiozen | can you write a command line app that does the trick? |
| 16:42.27 | kiozen | it's no problem to change the command executed on only 2 GCPs |
| 16:42.50 | kiozen | alternatively I could create a third artificial one |
| 16:44.29 | cr2 | i think that adding the third virtual is the easiest way to go. |
| 16:44.48 | cr2 | teaching gdal to deal with 2 GCPs is not easy. |
| 16:45.22 | cr2 | the TPS has a separate transformer object from the usual polynomial transformer. |
| 16:47.16 | cr2 | ah, it's called .gpl not .gct |
| 16:47.36 | cr2 | http://physos.net/~physos/new_kde.gpl |
| 16:47.37 | kiozen | ok I keep that 3rd artificial point in mind |
| 16:47.57 | cr2 | ok. |
| 16:49.21 | cr2 | Place this file in your ~/.gimp-2.x/palettes |
| 16:49.58 | cr2 | ls /usr/share/gimp/2.0/palettes |
| 17:01.37 | *** join/#htc-linux pH5 (n=ph5@e178202147.adsl.alicedsl.de) |
| 17:02.26 | *** join/#htc-linux Raven_coda (n=Raven_co@64.50.35.182) |
| 17:23.49 | *** join/#htc-linux the_sys0p (i=the_sys0@gateway/tor/x-81b3c22dccb0ec83) |
| 17:40.09 | *** part/#htc-linux BabelO_ (n=fcr@unaffiliated/babelo) |
| 17:44.09 | *** join/#htc-linux LunohoD_ (n=alex@e180072147.adsl.alicedsl.de) |
| 17:58.15 | *** join/#htc-linux Marex (n=marex@vasut.kolej.mff.cuni.cz) |
| 18:14.16 | *** join/#htc-linux rob_w (n=bob@Mb0cb.m.pppool.de) |
| 19:09.38 | *** join/#htc-linux CVirus (n=GoD@196.205.192.125) |
| 19:14.55 | *** join/#htc-linux kiozen (n=kiozen@rgnb-4db1db99.pool.einsundeins.de) |
| 19:18.21 | *** join/#htc-linux dcordes_ (n=snoopdog@unaffiliated/dcordes) |
| 19:21.37 | Marex | cr2, ping |
| 19:28.08 | cr2 | hi Marex |
| 19:28.54 | Marex | cr2, hi |
| 19:29.00 | Marex | how's N560 ? |
| 19:29.20 | Marex | I was just wondering why there are no machines supported in mainline ... noone upstreamed anything yet ? |
| 19:31.12 | cr2 | they are not ready. |
| 19:31.29 | cr2 | get the kernel from hh.org CVS and compile it. |
| 19:31.35 | cr2 | let me know if it works for you. |
| 19:32.59 | Marex | cr2, they are not ready for quite some time now |
| 19:33.00 | Marex | :/ |
| 19:33.24 | Marex | cr2, yea, I guess I will continue on the -hh kernel |
| 19:33.44 | Marex | anyway ... Im going to hack on Beetles a bit now ... just for fun |
| 19:36.21 | cr2 | will be nice too. i have a sable |
| 19:42.18 | kiozen | cr2: how did you do the scaling? |
| 19:44.10 | *** join/#htc-linux swc666 (n=no@24.143.67.18) |
| 19:48.03 | cr2 | kiozen: scaling ? |
| 19:48.38 | kiozen | cr2: of the files, to have a common scale |
| 19:48.59 | kiozen | I added the second file i have |
| 19:50.32 | cr2 | -tr |
| 19:51.18 | kiozen | ok |
| 19:51.18 | cr2 | gdalwarp -srcnodata 255 -dstnodata 255 -te $xmin0 $ymin0 $xmax0 $ymax0 -tr $tr $tr AusgabedateiM.tif AusgabedateiG.tif |
| 19:51.58 | cr2 | i'm also setting the bounding box here. |
| 19:55.31 | *** join/#htc-linux CVirus (n=GoD@196.205.192.125) |
| 19:56.55 | kiozen | cr2: doesn't really matter :), I get more errors because reference point errors and scanning skews |
| 19:57.55 | cr2 | why do you get errors ? |
| 20:00.10 | kiozen | partly because the map was folded, and if the ref point is not set to the exact pixel |
| 20:00.47 | kiozen | but I would say the errors by the folded map are the worst |
| 20:01.10 | kiozen | does you mail box digest ~6MB? |
| 20:01.11 | cr2 | ok, you mean calibration errors, not the gdal errors. |
| 20:01.22 | kiozen | yes calibration |
| 20:01.27 | cr2 | don't think so. |
| 20:01.41 | kiozen | moment... |
| 20:02.21 | cr2 | the GCP icons don't get many signals. like delete, name update |
| 20:02.43 | kiozen | yes still some quirks :) |
| 20:03.25 | cr2 | btw, even if i delete the GCPs the add counter increases. |
| 20:03.35 | kiozen | yes that is ok |
| 20:04.06 | cr2 | yes, it's not a problem, just an observation. |
| 20:04.25 | kiozen | to hard to do it "the right way" ;) |
| 20:04.50 | kiozen | cr2: http://www.qlandkarte.org/seite1_300dpi.tif |
| 20:04.58 | kiozen | cr2: http://www.qlandkarte.org/seite2_300dpi.tif |
| 20:05.44 | kiozen | GCPs sent by mail |
| 20:05.53 | cr2 | ok, downloading. |
| 20:06.23 | cr2 | got them. |
| 20:10.53 | cr2 | you may add -co zlevel=9 |
| 20:11.16 | cr2 | hmm. the gcp proj is obviously lost with .gcp format. |
| 20:11.27 | cr2 | and the gcp label. |
| 20:12.51 | kiozen | oh you are right, second... |
| 20:13.12 | kiozen | cr2: +proj=utm +zone=33 +ellps=intl +towgs84=-87.000,-98.000,-121.00 +wktext +units=m +no_defs |
| 20:15.14 | kiozen | label names aren't really needed, just double click on the list and the gcp is centered |
| 20:15.59 | cr2 | loading ref.tif and overlaying .gpx |
| 20:16.30 | cr2 | Referenzsystem des Layers: |
| 20:16.31 | cr2 | +proj=utm +zone=33 +ellps=intl +units=m +no_defs |
| 20:16.37 | cr2 | says qgis, btw. |
| 20:17.45 | kiozen | yes I know but this: +towgs84=-87.000,-98.000,-121.00 would be the important part |
| 20:19.24 | cr2 | hmm. |
| 20:21.03 | cr2 | GT says 'failed to load' |
| 20:21.18 | cr2 | the track in qgis does not match. |
| 20:22.23 | kiozen | you used GT to reference? |
| 20:22.57 | cr2 | yes. |
| 20:23.36 | cr2 | i've loaded your .gcp file and added the proj given above. |
| 20:24.00 | kiozen | funny that is exactly what I do |
| 20:24.10 | cr2 | ok, i'll try again. |
| 20:24.24 | *** join/#htc-linux diogene31_ (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) |
| 20:24.49 | kiozen | svn up to make sure we are in sync |
| 20:24.52 | cr2 | ok. |
| 20:25.07 | cr2 | maybe i've picked the file from yesterday. |
| 20:25.13 | cr2 | they have the same name it seems |
| 20:25.27 | cr2 | seite1_300dpi.tif.1 |
| 20:25.28 | cr2 | yes. |
| 20:26.07 | kiozen | svn up again, else you cant edit gcps |
| 20:26.35 | kiozen | yes it's the same file but a bit smaller to get rid of distortions at the borders |
| 20:27.40 | cr2 | ok, now the gcps match the grid crosses |
| 20:28.47 | cr2 | hm,i'm wondering if the % can be reused for QProgressBar |
| 20:28.52 | cr2 | there must be some trick. |
| 20:31.09 | kiozen | hm, gdal tools are not very wrapper friendly |
| 20:32.17 | kiozen | people programming commandline tools do not think about GUIs and wrapers. |
| 20:32.41 | kiozen | this is the reason why I hate to wrap commandline tools. (e.g. gpsbabel) |
| 20:32.57 | cr2 | agreed. |
| 20:33.07 | cr2 | GT says failed to load again. |
| 20:33.52 | cr2 | qgis has an offset because of the missing towgs84= |
| 20:34.07 | kiozen | hm, no idea yet, you use seite1_300dpi_ref.tif? |
| 20:34.22 | cr2 | yes. |
| 20:34.38 | cr2 | how can i get a more detailed info on load failure ? |
| 20:36.10 | kiozen | having a debug version of gdal :) |
| 20:36.17 | kiozen | send me the file via mail |
| 20:37.47 | cr2 | sent |
| 20:39.44 | cr2 | i can load my mercator map without any problems. |
| 20:39.53 | kiozen | cr2: loads perfectly here |
| 20:40.05 | *** part/#htc-linux swc666 (n=no@24.143.67.18) |
| 20:40.27 | kiozen | strange |
| 20:41.03 | kiozen | you have it in the same path as the qmap file? |
| 20:41.39 | cr2 | um. no ;) |
| 20:42.06 | kiozen | hehe |
| 20:42.21 | kiozen | yes I know, I should fix that |
| 20:43.32 | cr2 | ok, loaded now. |
| 20:43.46 | cr2 | the dialog should enforce the .qmap extension. |
| 20:44.10 | kiozen | fixed 1 min ago :) |
| 20:44.36 | kiozen | svn up ;) |
| 20:44.41 | cr2 | hm. get the same 100m offset like in qgis ? |
| 20:44.44 | cr2 | ok. |
| 20:45.13 | cr2 | IMap::~IMap() |
| 20:45.13 | cr2 | "+proj=utm +zone=33 +ellps=intl +units=m +no_defs " |
| 20:45.13 | cr2 | 282717 5.16209e+06 287082 5.15557e+06 |
| 20:45.32 | cr2 | seems logical. |
| 20:46.11 | kiozen | uncomment line 52 in CMapFile.cpp |
| 20:46.22 | cr2 | speed: inf km/h |
| 20:46.26 | cr2 | for the track :) |
| 20:46.49 | kiozen | '*%&@ Garmin killed the timestamps |
| 20:47.39 | *** join/#htc-linux Zoolooc (n=fredsiba@nrbg-4dbf8f30.pool.einsundeins.de) |
| 20:48.15 | cr2 | should not do in saved .gpx |
| 20:48.49 | cr2 | you may consider to add Track->Load |
| 20:49.15 | cr2 | ok, with +towgs84 it works. |
| 20:49.29 | cr2 | as expected. |
| 20:49.47 | kiozen | yes it's the same as with the BETA2007 stuff |
| 20:50.08 | kiozen | GK->WGS84 has the same problem |
| 20:50.21 | cr2 | yes. |
| 20:51.07 | kiozen | thus the question is: How to get this +towgs84 into the damn file |
| 20:52.10 | cr2 | imho it's some gdal_* bug |
| 20:52.30 | cr2 | towgs84 is an internal proj4 weirdness |
| 20:53.07 | cr2 | if gdal* drops it, it should warp the file respectively. |
| 20:53.45 | cr2 | the gdalinfo shows just |
| 20:53.48 | cr2 | <PROTECTED> |
| 20:54.07 | cr2 | <PROTECTED> |
| 20:54.14 | cr2 | <PROTECTED> |
| 20:54.14 | cr2 | <PROTECTED> |
| 20:54.19 | cr2 | which is ok. |
| 20:54.41 | cr2 | the problem is that the pixels are not warped in the same way. |
| 20:56.02 | cr2 | i should not give a fsck how proj4 converts the proj1/datum1 -> proj2/datum2 |
| 20:56.43 | cr2 | and if it says the geotiff has proj2/datum2, i should not care about wgs84. |
| 21:00.47 | cr2 | yes, GK3/DHDN does not define +towgs84 too. |
| 21:00.59 | cr2 | so it will probably suffer too. |
| 21:02.09 | cr2 | but it defines +datum=potsdam |
| 21:02.15 | kiozen | tried to warp the gcped file to EPSG:32633 |
| 21:02.16 | cr2 | proj4 is weird :) |
| 21:02.34 | kiozen | same error but: |
| 21:02.52 | cr2 | but your gcps are using +towgs |
| 21:03.07 | kiozen | http://pastebin.ca/937094 |
| 21:03.21 | cr2 | so you should run cs2cs +to +init=epsg:32633 for the gcps. |
| 21:03.34 | kiozen | haven't tried it with towgs84, moment |
| 21:03.39 | cr2 | that's why i'm for including the pre-gcp proj |
| 21:04.05 | cr2 | s/pre/per/ |
| 21:05.06 | kiozen | crud, same error |
| 21:05.27 | cr2 | what do you get from |
| 21:05.44 | cr2 | cs2cs -f "%.6f" +proj=utm +zone=33 +ellps=intl +units=m +no_defs +to +init=epsg:32633 |
| 21:05.45 | cr2 | ? |
| 21:05.57 | cr2 | ah |
| 21:06.08 | cr2 | sorry , forgot the towgs on the left side |
| 21:06.26 | cr2 | otherwise these two are equivalent |
| 21:07.48 | kiozen | you mean converting the UTM/ED50 points to UTM/WGS84 and then do the warping? |
| 21:12.21 | cr2 | yes |
| 21:12.43 | kiozen | that works :) but is not user friendly |
| 21:13.01 | cr2 | you'll miss the grid crosses, but they are irrelevant for geotiff anyway. |
| 21:14.02 | cr2 | btw, you may draw the grid for checking the calibration, like ozi does it. |
| 21:17.52 | kiozen | hm, have to sleep about it. Maybe I get an idea of how to make it user friendly |
| 21:18.36 | kiozen | it's more ore less bypassing a bug :/ |
| 21:19.25 | cr2 | ok. |
| 21:19.57 | kiozen | enough for today :) |
| 21:20.18 | cr2 | good night :) |
| 21:21.15 | kiozen | night :) |
| 22:04.17 | *** join/#htc-linux patoche (n=pat@lns-bzn-53-82-65-33-249.adsl.proxad.net) |
| 22:14.51 | *** join/#htc-linux hlbot (n=adm@iclem.net) |
| 22:14.51 | *** join/#htc-linux diogene31_ (n=rj@mur31-2-82-243-122-54.fbx.proxad.net) [NETSPLIT VICTIM] |
| 22:14.51 | *** join/#htc-linux skodde (n=skodde@unaffiliated/skodde) [NETSPLIT VICTIM] |
| 22:14.51 | *** join/#htc-linux Winkie (n=urmom@ur.fa.gs) [NETSPLIT VICTIM] |
| 22:14.51 | *** join/#htc-linux tg (n=tg@x-net.hu) [NETSPLIT VICTIM] |
| 22:14.51 | *** join/#htc-linux swetland (n=swetland@sunnyvale.frotz.net) [NETSPLIT VICTIM] |
| 22:19.29 | *** join/#htc-linux swc666 (n=no@24.143.67.18) |
| 22:27.32 | swc666 | can someone answer this for me... I have a build environment set up on a machine and can successfully compile a kernel for my Uni using the instructions on the hh site for UniversalKernel how to. My question is this: I want to be able to test a single driver module on an SD Card kernel that is already installed using the same kernel version.. |
| 22:28.12 | swc666 | in other words just a couple of tweaks to the driver code and then be able to make the module and copy it to the phone. Can this be done without having to boot the kernel I made? |
| 22:31.05 | *** join/#htc-linux CVirus (n=GoD@196.205.192.125) |
| 22:33.32 | *** join/#htc-linux SuN (n=SuN@82-170-225-106.ip.telfort.nl) |
| 22:56.37 | *** part/#htc-linux swc666 (n=no@24.143.67.18) |
| 23:19.55 | Marex | cr2, hi |
| 23:20.05 | Marex | cr2, wanna test some patches for 65xx ? |
| 23:26.01 | cr2 | Marex: it's too late. can you post them ? |
| 23:26.15 | Marex | cr2, right after I finish them |
| 23:26.37 | cr2 | don't forget that beetles have 2 mmc/sd controllers asic3+pxamci |
| 23:26.43 | cr2 | sable only one. |
| 23:26.46 | cr2 | asic3 |
| 23:26.55 | Marex | ahh ... jeez |
| 23:27.07 | Marex | yea, I know it has two holes ;D |
| 23:27.21 | Marex | but I never thought they could remove one on better model ... ah oh well |
| 23:29.10 | cr2 | sable has miniSD only |
| 23:29.21 | cr2 | maybe because it has wifi. |
| 23:30.04 | Marex | ah I see ... |
| 23:30.14 | Marex | they might be using pxamci for SDIO wifi |
| 23:30.25 | cr2 | no |
| 23:30.27 | Marex | they do it like that on loox n560 too :/ |
| 23:30.31 | cr2 | wifi already works. |
| 23:30.41 | cr2 | loox has 54mbit acx100 |
| 23:30.49 | cr2 | sable only 22mbit |
| 23:31.13 | Marex | ok, I see |
| 23:31.13 | cr2 | 54mbit is the newer 125[01] chip |
| 23:31.46 | cr2 | Marex: the phone at protocol is decoded by lkcl |
| 23:32.15 | cr2 | and the gps chip uses asic3-spi |
| 23:32.28 | cr2 | it's the same chip as in moko1 phone |
| 23:32.31 | Marex | so there is not much to hack as I see |
| 23:32.41 | cr2 | asic3-spi |
| 23:32.46 | cr2 | make phone really work. |
| 23:32.58 | cr2 | and sdio for asic3 |
| 23:33.07 | cr2 | to make it work on 2.6.24+ |
| 23:33.39 | cr2 | resume had some issues afair. |
| 23:34.36 | dcordes_ | cr2, good night |
| 23:54.42 | Marex | cr2, something's screwed with asic3 leds :/ |