is it possible to store UAV images incrementally into Rasterlite2 in real-time and serve them through WMSLite for dynamic visualization

[Ke Song]

I want to implement a system that stores UAV (Unmanned Aerial Vehicle) images which was been georeferencing on-the-fly, and insert the dom into Rasterlite2 incrementally   in real-time. These images represent different sections of an area. Concurrently, I aim to publish these images through WMSLite for dynamic visualization, enabling users to pan, zoom in/out, and explore the area's coverage in realtime too. Is it possible, or some advise

[a.fu...@lqt.it]

Hi,

your questions are quite general and not very detailed,
and so my answers will also be quite vague.

Rastrlite2 is designed to archive raster maps as they are
generally understood in the GIS world.
That is, sets of many images that form a mosaic arranged
in a well-ordered manner on a regular grid.
(see the attached figure)

in the case of aerial or satellite imagery it's expected
that all the images were taken by always flying at the
same altitude, at a strictly constant speed and
scrupulously following the direction of one of
the cartographic axes.

in short, we expect these to be images that are
not only georeferenced but also orthorectified.
see https://en.wikipedia.org/wiki/Orthophoto

I'm not entirely sure if your UAV footage meets
these requirements.

Second concern: you are talking about a real-time
application.
I suppose this implies great speed in receiving and
processing many images in a short time following a
continuous data flow.
RasterLite2 works in the opposite way; it prefers
a single initial loading phase after which it's
possible to pan & zoom very quickly.
I don't think it would fit well in a very dynamic
context.

Last point: WMSLite is simply a WEB component
implementing the WMS protocol.
see https://en.wikipedia.org/wiki/Web_Map_Service

You can use it for pan & zoom operations, but it's
not enough on its own.
Some kind of WEB-app interacting on the user side
is also needed.

I hope this general information can be useful to you.

best regards,
Sandro

[Ke Song]

Thank you for your reply, sorry for the  vague question. Your consern is quite my question.
Firstly, the UAV image is  orthorectified.
Secondly, the image produnce frequency is 2 second one images.
Thirdly, I'm planning using openlayer along with WMSLite to pan and zoom.
Is it possible to put every image into the same coverage but different section, and build overviews in the backgroud, so it can meet the realtime scenary. If not, have any other ways to do that?

[a.fu...@lqt.it]

On Sun, 26 May 2024 04:13:26 -0700 (PDT), Ke Song wrote:
> Thank you for your reply, sorry for the  vague question. Your consern
> is quite my question.
> Firstly, the UAV image is  orthorectified.
> Secondly, the image produnce frequency is 2 second one images.
> Thirdly, I'm planning using openlayer along with WMSLite to pan and
> zoom.
>

In general it seems like a reasonable scenario; however, I still
have a concerns:

I'm afraid that fully processing an image in just 2 seconds
won't be possible. presumably it will take more time to create
all the scaled levels of the multiresolution pyramid which are
essential to support quick and efficient zoom & pan.
The time required obviously depends greatly on the size of the
individual images.

> Is it possible to put every image into the same coverage but
> different
> section,
>

Certainly yes, Rasterlite2 works exactly this way.
Each image is considered an independent section.

> and build overviews in the backgroud, so it can meet the
> realtime scenary. If not, have any other ways to do that?
>

no, this is definitely impossible.
RasterLite2 stores images inside a SQLite DB which
unfortunately does not support concurrent access.
In other words, there cannot be a foreground and a
background because SQLite requires having a single
connection active in writing at every single moment.

All this is guaranteed by a system mechanism based
on file locking and timeouts.
There are options available that allow concurrent writes,
but the end result is that timeouts are simply lengthened.
In the end you don't increase the overall speed at all by
using two concurrent processes.

bye Sandro

[Ke Song]

Oh, I see, thank you