Đây là bước quan trọng nhất trong hệ thống bản đồ dạng Tile. Các ảnh Tile có thể có bất kỳ kích cỡ nào và chúng có thể chuyển đổi ở các quy mô khác nhau. Chúng có thể khác nhau trên cùng một tỷ lệ hoặc chúng có kích cỡ ngẫu nhiên. Tuy nhiên sẽ có hiệu quả nếu chọn các Tile cùng kích cỡ trên một hoặc mọi quy mô.
Có một cách tiếp cận để xác định kích thước Tile tối ưu. Đầu tiên chúng ta phải xem tác động của việc sử dụng nhiều hình ảnh để ảo hóa một map view đơn giản. Mỗi bức ảnh sẽ đi kèm với một số lượng chi phí. Có nhiều loại chi phí khác nhau, như chi phí đa tìm kiếm và đọc của tập tin hệ thống, sử dụng không đồng đều kích cỡ của các block, tiêu đề và các chi phí không gian lưu trữ với mỗi ảnh.
Các định dạng được các Web browser sử dụng nhiều là : PNG và JPEG, nhưng chúng cũng có một số nhược điểm sau. Bất kỳ hình ảnh được mã hóa nào cũng làm hao phí một không gian lưu trữ, có nghĩa là không gian không được dùng trực tiếp vào việc lưu trữ điêm ảnh. Nó chứa tiêu đề và siêu dữ liệu hình ảnh. Một vài ví dụ sau sẽ cho phép chúng ta kiểm tra hao phí bộ nhớ của các định dạng ảnh PNG và JPEG. Chúng ta tạo ra các hình ảnh có kích thước 1x1, 64x64, 128x128, 256x256, 512x512, 1024x1024, 2048x2048, 4096x4096 và 8192x8192 pixel. Sử dụng phân đoạn của NASA’s Blue Marble Next Generation như là nội dung gốc và cơ sở là ảnh 1x1 pixel ta có bảng sau :
36
rõ ràng chúng ta sẽ tiết kiệm được chi phí đối với những bức ảnh có kích thước lớn. Nhưng những hình ảnh rất lớn thì lại xuất hiện một vấn đề mới. Đó là thời gian chờ đợi để tải một bức ảnh 8192x8192 và hiển thì chúng lên màn hình là cả một vấn đề, đặc biệt là màn hình máy tính chỉ hiển thị được kích cỡ 1024x768. Chúng chỉ có thể hiển thị được 1.17% số điểm ảnh mà thôi. Ngoài ra hình ảnh rất lớn còn tiêu tốn bộ nhớ và không thể sử dụng trong các thiết bị nhớ trước đây. Có một yếu tố nữa cần phải chú ý khi tạo một bức ảnh JPEG cụ thể. Cơ sở của thuật toán nén JPEG là dựa trên block. Nó thường sử dụng 16x16 block của điểm ảnh như là đơn vị nén tối thiểu. Nếu số điểm ảnh không chia hết cho 16 trong mỗi chiều thì điểm ảnh đó sẽ tiêu biến trả lại giá trị rỗng cho điểm ảnh đó. Vì thế các ảnh JPEG có kích thước từ 1 đến 500 thì mỗi ảnh sẽ toàn là những điểm ảnh màu đen. Vì thế chúng ta nên chọn kích thước Tile là bội của 16. Và bức ảnh JPEG 1x1 cũng tương đương bức ảnh JPEG có kích cỡ 16x16.
Để xác định kích thước Tile phù hợp, chúng ta cần tạo ra một chức năng tối ưu hóa. Để tối ưu cả số ảnh cần thiết tạo nên map view ảo và số lượng điểm ảnh vô nghĩa. Điểm ảnh vô nghĩa là điểm ảnh được truyền đi và giải mã nhưng không được hiển thị. Cách tốt nhất để giảm thiểu số lượng điểm ảnh vô nghĩa đó là làm tất cả các Tile 1x1, và điều đó giúp chúng ta sẽ không phải giải mã bất kỳ điểm ảnh vô nghĩa nào. Tuy nhiên hao phí để lấy và giải mã hàng nghìn file ảnh cho mỗi map view ảo sẽ làm cho hệ thống bị quá tải. Chúng ta cần xác định kích thước thích hợp cho cả Tile và hệ thống. Đầu tiên chúng ta cần tìm một kích thước điển hình cho một map view ảo. Ví dụ chúng ta sử dụng màn hình kích thước 1024x768 pixel. Với kích thước này chúng ta có thể tạo ra vô số các map view ngẫu nhiên cho màn hình này. Với mỗi map view ngẫu nhiên, chúng ta sẽ tính toán số lượng Tile cần thiết để điền vào cái view đó và cả số lượng các điểm ảnh vô nghĩa. Chúng ta sẽ thực hiện việc tính toán này cho tất cả các kích thước Tile. Ví dụ chúng ta sẽ sử dụng các Tile có kích thước 16, 32, 64, 128, 256, 512, 1024 và 2048.
37
Một ví dụ về quy mô bản đồ, chúng ta sẽ sử dụng quy mô bản đồ mức 10. Với quy mô mày chúng ta sẽ có số lượng hàng là 1024 và số lượng cột là 512 ở đây có 2 tile ở mức thấp nhất. Mỗi Tile sẽ chứa 1024/360 (2,84) độ ở cả chiều ngang và chiều dọc. Để tạo ngẫu nhiên một map view là khá dễ dàng. Vì tất cả các map view có cùng tỷ lệ, chúng ta cần tạo ra một số lượng lớn các điểm trung tâm ngẫu nhiên. Các điểm trung tâm ngẫu nhiên sẽ nằm trong khoảng kinh độ -180 đến 180 và vĩ độ -90 đến 90. Có 2 cách thực hiện điều này. Trước tiên chúng ta cần hạn chế những điểm ngẫu nhiên nằm bên ngoài map view, thứ 2 chúng ta đơn giản là thực hiện tính toán mà không quan tâm nếu có những ô vuông xếp chồng lên nhau trong những tọa độ cho phép. Chúng ta sẽ lựa chọn phương thức sau. Nếu một ô vuông bị vượt ra ngoài khoảng -180 đến 180 và -90 đến 90 thì chúng ta sẽ tính toán những điểm ảnh vô nghĩa và các Tiled được truy cập nếu có các Tile và các điểm ảnh nằm trong không gian hợp pháp. Điều này hợp lý vì rất nhiều map client thực hiện việc xoay vòng ở khu vực ranh giới. Chúng kéo những bức ảnh và những điểm ảnh từ bản đồ phía bên kia sau đó điền trồng lên khu vực cũ.
Các thống kê về sự phụ thuộc kích thước của Tile và số Tile truy cập thường xuyên và số điểm ảnh vô nghĩa dẫn ta đến việc chọn lựa kích thước của Tile là 128x128. Tuy nhiên việc tính toán này chỉ thực hiện trên một số điểm ảnh. Chúng ta không quan tâm đến cách tính quan trọng được thực hiện trước để xác định tỷ lệ phần trăm chi phí cho mỗi kích thước Tile. Tính toán lại để tối ưu hóa và thay thế các điểm ảnh vô nghĩa với tổng số byte được truy cập mang lại một kết quả khác. Kết quả được thể hiện như sau:
38
Hình 3.1 Tổng số bit được truy cập với từng tile size [4]
Rõ ràng các Tile 16x16 là không hiệu quả. Chúng yêu cầu nhiều byte nhất để được truy cập, thậm trí các Tile 16x16 là tạo ra ít điểm ảnh vô nghĩa nhất. Kết quả của các điểm ảnh vô nghĩa là lớn khi mà kích thước điểm ảnh lớn. Vì thế theo biểu đồ trên, Tile có kích thước 128, 256 hoặc 512 là hợp lý nhất. Điều gì xảy ra nếu chúng ta quan tâm đến nhiều hơn một độ phân giải map view. Cho đến bây giờ, chúng ta chỉ có độ phân giải của map view là 1024x768. Hình sau cho thấy kết quả của độ phân giải map 640x480, 800x600, 1024x768, 1280x960, 1400x1050, và 1600x1200.
39
Hình 3.2 Các kích thước map view với tile size và tổng số byte được truy cập với ảnh JPEG [4]
Kết quả tương tự, nhìn vào khu vực tối ưu chúng ta xoay quanh khu vực 128, 256, và 512. Hình dưới chỉ ra kết quả cho kích thước ảnh PNG thay cho kích thước JPEG. Chúng ta có thể nhìn thấy kết quả của chi phí giảm trong ảnh PNG. Nhưng hình kế tiếp lại chỉ ra rằng ảnh JPEG có số byte được truy cập như là sự khác biệt từ một kích thước của một Tile đến một Tile khác. Trong hình này, chúng ta có thể thấy rằng dòng gần như đường thẳng từ 256 đến 512. Điều này cho thấy rằng có rất ít sự khác biệt giữa các kích thước Tile về tổng số byte truy cập
40
Hình 3.3 Các kích thước map view với tile size và tổng số byte được truy cập với ảnh PNG [4]
Hình 3.4 Kích thước map view với tile size và tổng số byte được truy cập khác nhau với ảnh JPEG [4]
Vì chúng ta đã chuyển từ việc quan tâm đến các pixel đến các byte hình ảnh nén, chúng ta cũng nên xem xét thời gian tính toán để giải nén các Tile hình ảnh nén. Thời
41
gian giải nén trung bình cho các Tile có kích thước khác nhau trong cả hai định dạng JPEG và PNG được biểu hiện bằng bảng sau:
Bảng 3.2 Thời gian giải nén ảnh [4]
Thời gian để giải nén các hình ảnh JPEG:
Hình 3.5 Thời gian giải nén ảnh JPEG [4] và thời gian để giải nén PNG:
42
Hình 3.6 Thời gian nén ảnh PNG [4]
Chúng ta sẽ hướng sự quan tâm của mình đến không gian nhỏ bao quanh Tile có kích thước 512. Trong thực tế điều này có nghĩa là trong khi mỗi Tile như là một phần của thế giới, độ phân giải map thực của mỗi Tile thay đổi cùng với kích thước của nó. Cả hai sự thiếu sót có thể được giải quyết bằng cách thay thế quy mô 10 cố định của map với một quy mô bản đồ được lựa chọn ngẫu nhiên. Quy mô bản đồ được lựa chọn ngẫu nhiên từ một phạm vi liên tục thay vì quy mô rời rạc cố đinh. Trong trường hợp này, chúng ta sẽ có quy mô các điểm ảnh từ không gian bao gồm Tiled để phù hợp với quy mô map view với quy mô được chọn ngẫu nhiên.
Kết luận, xem xét các kết quả trên chúng ta sẽ sử dụng 512x512 cho các kích thước Tile. Phân tích cho thấy 256x256 cũng sẽ là một lựa chọn tốt. Tuy nhiên, chúng ta nên xem xét điểm cuối cùng. Phải mất 4 Tile 256x256 để bao một không gian của một Tile 512x512. Vì vậy khi chúng ta tạo ra một số lượng Tile lớn, nếu chúng ta sử dụng Tile 256x256, chúng ta sẽ mất gấp 4 lần mục cơ sở dữ liệu hoặc 4 lần cho file ảnh Tile, và lập chỉ mục sẽ gấp 4 lần kích thước – đây sẽ là một chi phí đáng kể.