> We should try to get this large redundancy when flying again So what you are saying is that I should take *more* photos ... noone has ever said that to me before ... there is always a first for everything.
The outcomes that I'm hearing from this is -- higher altitude; more image overlap; the less oblique the better Areas where I put effort into that arn't really so important: lens geometry (i chose a prime lense that I knew was very planar); sheer resulution, I could have taken a slightly higher altitude without a problem. Question -- is it within our licencing to recitfy to yahoo imagery? because if it is, we could use SIFT to automate it. JR 2009/12/15 Tim Waters <[email protected]>: > 2009/12/10 Peter Miller <[email protected]>: >> >> On 10 Dec 2009, at 14:18, Andy Allan wrote: >> >>> Hi Peter >>> >>> On Wed, Dec 9, 2009 at 9:20 PM, Peter Miller <[email protected] >>> > wrote: >>> >>>> Thanks Andy, your wiki page is very useful and it is also good to >>>> see the >>>> imagery in Potlatch. Is the location of image encoded in the image >>>> somehow, >>>> or how else does PotLatch know where to load it? >>> >>> They are made into 256x256 tiles, with the same z/x/y.png notation as >>> the main tileserver. It's the same way that the out-of-copyright maps >>> work too. The !'s in the url on the wikipage are placeholders for >>> potlatch to put in the tile numbers. For example, >>> >>> http://gravitystorm.dev.openstreetmap.org/imagery/stratford/14/8113/5397.png >> >> Thanks. That is very neat. >> >>> >>>> When I tried warping the images I did feel that the algorithm used >>>> by warper >>>> was possibly a bit suspect - the warping suddenly went completely >>>> wrong as >>>> one added more control points in a rather counter-intuitive way. >>> >>> I'd discussed this with a few people over beers, and the problem >>> appears to be that the warper's algorithm is assuming that you start >>> with a fairly "flat" image, and doesn't take into account that the >>> plane of the image might not be horizontal. It's for warping maps, >>> after all, and we're semi-abusing it by warping photos instead. An >>> extra control point or two can send it off wildly (as it tries to >>> figure out how exactly a map sheet would end up stretched so) and of >>> course it gets worse the further from vertical the photo is. >>> >> >> So there is certainly a nice job for someone to sort out a suitable >> algorithm that will work in practical situations when one doesn't >> necessarily even have height data and certainly has distortions of >> various sorts. The idea of associating 'ways' on the image to 'ways' >> on the map sounds very neat assuming that one has a skeleton road >> structure in place (which one could of course get from old OS maps if >> necessary). I think it would then work a treat - certainly much better >> than Warper currently manages. > > I also agree would be great to be able to use linear features to > rectifty, it's on my list! > > But I just thought I'd make you aware of the "advanced options" > feature on Warper - by default, the algorithm changes based on the > number of control points - you can override this behaviour. > > [You can also have a go at using the "Thin Plate Spline" method, which > is best with lots of points - although ymmv and there may be a bug > (mainly because no one uses it!). But essentially it gives a better > warp when theres more points and treats the points as fixed - worth > trying it offline with the command line GDAL tools if you have the > time. ] > > **For all methods, the more points, the better.** > > Orthorectification is another thing though - thank god the photo's > were in a relatively flat area! > > More generally as you know, in the world of aerial photography, > there's usually extensive overlap (up to 60%?) for photos over areas > and so you really shouldn't worry if 20% of the oblique image is > unusable. We should try to get this large redundancy when flying again > :) > > > Cheers, > > Tim > > _______________________________________________ > Talk-GB mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-gb > _______________________________________________ Talk-GB mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-gb
