[Talk-GB] Stratford imagery

[John Robert Peterson]

>  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 <chippy2005 at gmail.com>:
> 2009/12/10 Peter Miller <peter.miller at itoworld.com>:
>>
>> On 10 Dec 2009, at 14:18, Andy Allan wrote:
>>
>>> Hi Peter
>>>
>>> On Wed, Dec 9, 2009 at 9:20 PM, Peter Miller <peter.miller at itoworld.com
>>> > 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
> Talk-GB at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-gb
>