Pan Jacek Radzikowski napisał:

>>> Praktycznie każdy serwis serwujący mapy rastrowe korzysta z podziału na
>>> kafelki. Wektorowo mogą być wysyłane dane dodatkowe (np. informacje o
>>> infrastrukturze, mapa dróg), ale jeśli to są informacje które nie
>>> zmieniają się zbyt często to taniej pod względem wydajności jest
>>> przerobić je na raster i wyświetlać jako warstwę na mapie bazowej.
>>
>> Ale ja tam nie widzę tych kafelków! Kiedyś były wyraźne przy ładowniu.
>> Wszystko wygląda na wektorowe. O, proszę, budynki są 3D! Jak się
>> przesuwa bardzo przybliżoną mapę, to widać raz jedną, raz drugą ścianę
>> domu. Ale nie w każdym miejscu. Kafle są oczywiście w widoku ze zdjęciem
>> satelitarnym, ale też mają warstwę 3D budynków robioną już po strronie
>> przeglądarki.
>
> Budynki to jest kolejna warstwa, wektorowa. W Google Earth były wysyłane
> jako KML i renderowane w aplikacji.
> W Google Maps zdjęcia z powietrza i mapa z drogami jest wysyłana jako
> kafelki (n.p ten:
> https://www.google.com/maps/vt/pb=!1m4!1m3!1i15!2i93
47!3i12538!2m3!1e0!2sm!3i385078492!3m7!2sen!5e1105!1
2m4!1e68!2m2!1sset!2sRoadmap!4e0!5m1!1e0!23i4112264)
,

Oglądam teraz Warszawę i nie widzę niczego rastrowego (na mapach z ulicami,
nie na zdjęciach). Ponadto przy kolejnych wejściach na to samo miejsce mam
różnie. Poprzednio widziałem płaski Pałac Kultury, teraz jest 3D. To się
pokrywa z zeznniami znajomego robiącego w guglu -- zmiany wprowadza się tam
stopniowo, przy okazji restartu każdego serwerka, których sa jakieś miliony.
Więc mozna różnie trafić. Ze trzy tygodnie temu czytałem, że ma się coś
zmienić w mapach Google. Może to właśnie to. Ten Waszyngton z podanego wyżej
linka też u mnie wygląda jakoś inaczej.

> a widzę że warstwa 3d jest ściągana w jakimś formacie binarnym (być może
> skompresowany KML) i renderowana po stronie klienta. W każdym razie nic
> nie stoi na przeszkodzie żeby kafelki rastrowe i dane wektorowe były
> przedstawione na tej samej mapie.

Mam pewne podejrzenia, że przy większym oddaleniu są grafiki rastrowe,
a przy maksymalnym zbliżeniu nie ma ich wcale. Ale nie wiem, czy słuszne.

--
Jarek

do góry

On 07/14/17 16:42, Jarosław Sokołowski wrote:
> Oglądam teraz Warszawę i nie widzę niczego rastrowego (na mapach z ulicami,
> nie na zdjęciach). Ponadto przy kolejnych wejściach na to samo miejsce mam
> różnie. Poprzednio widziałem płaski Pałac Kultury, teraz jest 3D. To się
> pokrywa z zeznniami znajomego robiącego w guglu -- zmiany wprowadza się tam
> stopniowo, przy okazji restartu każdego serwerka, których sa jakieś miliony.
> Więc mozna różnie trafić. Ze trzy tygodnie temu czytałem, że ma się coś
> zmienić w mapach Google. Może to właśnie to. Ten Waszyngton z podanego wyżej
> linka też u mnie wygląda jakoś inaczej.
>
>> a widzę że warstwa 3d jest ściągana w jakimś formacie binarnym (być może
>> skompresowany KML) i renderowana po stronie klienta. W każdym razie nic
>> nie stoi na przeszkodzie żeby kafelki rastrowe i dane wektorowe były
>> przedstawione na tej samej mapie.
>
> Mam pewne podejrzenia, że przy większym oddaleniu są grafiki rastrowe,
> a przy maksymalnym zbliżeniu nie ma ich wcale. Ale nie wiem, czy słuszne.

Mam wrażenie że mówimy o tym samym.
Informacje na mapie (poza zdjęciami) rozpoczynają żywot jako dane
wektorowe. Te które nie zmieniają się zbyt często są przepuszczane przez
rasteryzator i serwowane jako kafelki. Tak wygląda sieć dróg i ikonki
POI. Część informacji, jak np. współrzędne POI żeby można było kliknąć,
zawsze jest wysyłana w postaci wektorowej.

Budynki 3D też są wyrenderowane, ale dodatkowo widzę że też są pobierane
dane binarne, najprawdopodobniej uproszczone 3D.
Tutaj masz przykład kafelka mapy z zaznaczonymi POI i obrysem 3D
budynku:
https://www.google.com/maps/vt/pb=!1m4!1m3!1i20!2i29
9892!3i401121!2m3!1e0!2sm!3i385078456!3m7!2sen!5e110
5!12m4!1e68!2m2!1sset!2sRoadmap!4e0!5m1!1e0!23i41122
64
Na tym podkładzie najprawdopodobniej są renderowane przez WebGL
dodatkowe ikonki POI i budynki.

Google pewnie ma swoje narzędzia i swój proces tworzenia map, więc
możemy tylko zgadywać jak dokładnie mają to zaimplementowane, ale gdybyś
chciał się pobawić w domu i zbudować swój serwer map, albo nawet tylko
poczytać jak to jest robione, to polecam projekt OpenLayers. Wielka
kobyła, ale jest w nim wszystko: od wstępnej obróbki danych rastrowych i
wektorowych, po obsługę wyświetlania w przeglądarce.

Jest też cała masa innych darmowych narzędzi do rasteryzacji danych
wektorowych: http://wiki.openstreetmap.org/wiki/Rendering


Jacek.

do góry

Pan Jacek Radzikowski napisał:

> Informacje na mapie (poza zdjęciami) rozpoczynają żywot jako dane
> wektorowe. Te które nie zmieniają się zbyt często są przepuszczane przez
> rasteryzator i serwowane jako kafelki. Tak wygląda sieć dróg i ikonki
> POI. Część informacji, jak np. współrzędne POI żeby można było kliknąć,
> zawsze jest wysyłana w postaci wektorowej.

Tylko po co właściwie serwować coś oprócz zdjęć jako grafikę rastrową?
W prapoczątkach Google Maps wszystko było rastrowe, taki był stan techniki.
Łącze też miałem dużo słabsze i widać było jak przy zbliżaniu pikseloza
powoli wypełnia się szczegółami. Gdy zaczęto dokładać wektorowe elementy,
to być może nie wszyscy je widzieli. Jakaś strata, ale nie całkowita.
Teraz przeglądarki mogą więcej, więc jaki jest sens dawania rastrowego
kafelka z dwiema ulicami na krzyż zamiast po prostu wykreślić te ulice?

--
Jarek

do góry

On 07/14/17 17:49, Jarosław Sokołowski wrote:
> Pan Jacek Radzikowski napisał:
>
>> Informacje na mapie (poza zdjęciami) rozpoczynają żywot jako dane
>> wektorowe. Te które nie zmieniają się zbyt często są przepuszczane przez
>> rasteryzator i serwowane jako kafelki. Tak wygląda sieć dróg i ikonki
>> POI. Część informacji, jak np. współrzędne POI żeby można było kliknąć,
>> zawsze jest wysyłana w postaci wektorowej.
>
> Tylko po co właściwie serwować coś oprócz zdjęć jako grafikę rastrową?
> W prapoczątkach Google Maps wszystko było rastrowe, taki był stan techniki.
> Łącze też miałem dużo słabsze i widać było jak przy zbliżaniu pikseloza
> powoli wypełnia się szczegółami. Gdy zaczęto dokładać wektorowe elementy,
> to być może nie wszyscy je widzieli. Jakaś strata, ale nie całkowita.
> Teraz przeglądarki mogą więcej, więc jaki jest sens dawania rastrowego
> kafelka z dwiema ulicami na krzyż zamiast po prostu wykreślić te ulice?


Nie wiem jak to dokładnie jest zrobione, ale bazując na tym co widzę że
jest ciągnięte i jak działają inne podobne systemy, pobawię się trochę
we wróżkę.

Myślę że słowami kluczowymi są tutaj wydajność i dostępność.
Wygenerowanie takiego takiego kafelka z obrazem jest względnie tanie, a
wysłanie go praktycznie nic nie kosztuje.
Wysłanie danych wektorowych, gdyby chcieć je mieć zawsze aktualne,
wymaga przeszukiwania bazy danych przy każdy odwołaniu, co jest bardzo
drogie. W praktyce pewnie to jest zrobione tak, że mają je
"zrasteryzowane", w sensie że są pogrupowane w "kafelki" odpowiadające z
grubsza kafelkom rastrowym, ale za to wymagania na oprogramowanie po
stronie klienta są nieco większe niż dla obrazków.

Należy też pamiętać że są na świecie rejony gdzie powolny dialup jest
luksusem, a stary 486 to może być szczyt marzeń. Więc nie mogą sobie
pozwolić żeby odciąć tych klientów od usług.

Jacek.

do góry

Pan Jacek Radzikowski napisał:

>> Tylko po co właściwie serwować coś oprócz zdjęć jako grafikę rastrową?
>> W prapoczątkach Google Maps wszystko było rastrowe, taki był stan techniki.
>> Łącze też miałem dużo słabsze i widać było jak przy zbliżaniu pikseloza
>> powoli wypełnia się szczegółami. Gdy zaczęto dokładać wektorowe elementy,
>> to być może nie wszyscy je widzieli. Jakaś strata, ale nie całkowita.
>> Teraz przeglądarki mogą więcej, więc jaki jest sens dawania rastrowego
>> kafelka z dwiema ulicami na krzyż zamiast po prostu wykreślić te ulice?
>
> Nie wiem jak to dokładnie jest zrobione, ale bazując na tym co widzę że
> jest ciągnięte i jak działają inne podobne systemy, pobawię się trochę
> we wróżkę.
>
> Myślę że słowami kluczowymi są tutaj wydajność i dostępność.
> Wygenerowanie takiego takiego kafelka z obrazem jest względnie tanie, a
> wysłanie go praktycznie nic nie kosztuje.
> Wysłanie danych wektorowych, gdyby chcieć je mieć zawsze aktualne,
> wymaga przeszukiwania bazy danych przy każdy odwołaniu, co jest bardzo
> drogie. W praktyce pewnie to jest zrobione tak, że mają je
> "zrasteryzowane", w sensie że są pogrupowane w "kafelki" odpowiadające z
> grubsza kafelkom rastrowym, ale za to wymagania na oprogramowanie po
> stronie klienta są nieco większe niż dla obrazków.
>
> Należy też pamiętać że są na świecie rejony gdzie powolny dialup jest
> luksusem, a stary 486 to może być szczyt marzeń. Więc nie mogą sobie
> pozwolić żeby odciąć tych klientów od usług.

Moja szklana kula mówi co innego. Postać wektorowa powinna być lepsza
dla dialupowych łącz. Ponadto dla takich speców jak google, co jak co,
ale przeszukiwanie bazy danych powinno być tanie.

Może nie jest w najgorszym stanie ta moja kula, bo z grubsza pokrywa
się to z tym, co widzę. Przy dużych zbliżeniach jednak są to wektory.
A w oddaleniu serwowane są rastry -- bo po pierwsze i tak by nie było
widać szczegółów pomniejszonych wektorów, po drugie dużo by ich było
(ech, te dialupy), a po trzecie nie ma co przeliczać tego, czego i tak
nie widać (486). Można by było zhierarchizować ten opis wektorowy i
przy oddalonym widoku nie przekazywać na przykład dokładnego przebiiegu
każdej ulicy, ale to wcale nie wygląda na zadanie trywialne. Więc się
w takich okolicznościach przyrody tradycyjnie serwuje bitmapy.

--
Jarek

do góry

On 07/14/17 21:55, Jarosław Sokołowski wrote:
> Pan Jacek Radzikowski napisał:

>> Należy też pamiętać że są na świecie rejony gdzie powolny dialup jest
>> luksusem, a stary 486 to może być szczyt marzeń. Więc nie mogą sobie
>> pozwolić żeby odciąć tych klientów od usług.
>
> Moja szklana kula mówi co innego. Postać wektorowa powinna być lepsza
> dla dialupowych łącz. Ponadto dla takich speców jak google, co jak co,
> ale przeszukiwanie bazy danych powinno być tanie.

Jakie tanie by nie było, zawsze będzie droższe niż pobranie statycznego
pliku.


> Może nie jest w najgorszym stanie ta moja kula, bo z grubsza pokrywa
> się to z tym, co widzę. Przy dużych zbliżeniach jednak są to wektory.
> A w oddaleniu serwowane są rastry -- bo po pierwsze i tak by nie było
> widać szczegółów pomniejszonych wektorów, po drugie dużo by ich było
> (ech, te dialupy), a po trzecie nie ma co przeliczać tego, czego i tak
> nie widać (486). Można by było zhierarchizować ten opis wektorowy i
> przy oddalonym widoku nie przekazywać na przykład dokładnego przebiiegu
> każdej ulicy, ale to wcale nie wygląda na zadanie trywialne. Więc się
> w takich okolicznościach przyrody tradycyjnie serwuje bitmapy.

Wektory szybciej się ściągną, ale słaby komputer nie poradzi sobie z ich
narysowaniem.

Ten przykład kafelka który ostatni podesłałem był na prawie największym
zbliżeniu. Strona pobrała kafelek z wyrenderowanym obrazem mapy.
A jak teraz jeszcze raz się przyjrzałem na konsoli developerskiej chrome
jakie pliki są ściągane przy pełnym przeładowaniu mapy (po wyczyszczeniu
cache) na maksymalnym zbliżeniu to widzę same pliki png i ani jednego
wektorowego.
Chyba musimy nasze szklane kule wysłać razem na wódkę, żeby uzgodniły
zeznania :)

Jacek.

do góry

Dnia Fri, 14 Jul 2017 23:49:31 +0200, Jarosław Sokołowski napisał(a):
> Tylko po co właściwie serwować coś oprócz zdjęć jako grafikę rastrową?
> W prapoczątkach Google Maps wszystko było rastrowe, taki był stan techniki.
> Łącze też miałem dużo słabsze i widać było jak przy zbliżaniu pikseloza
> powoli wypełnia się szczegółami. Gdy zaczęto dokładać wektorowe elementy,
> to być może nie wszyscy je widzieli. Jakaś strata, ale nie całkowita.
> Teraz przeglądarki mogą więcej, więc jaki jest sens dawania rastrowego
> kafelka z dwiema ulicami na krzyż zamiast po prostu wykreślić te ulice?

Biorac pod uwage zamilowanie googla do wielkich dyskow, ilosc
korzystajacych osob, czestosc zmian, ilos elementow na mapie ... to
moze ma sens. Po co obciazac te tysiace komputerow
A przy graficznym formacie tekstowym kto wie co mniej danych
transmituje :-)

J.

do góry

Dnia Fri, 14 Jul 2017 16:21:43 -0400, Jacek Radzikowski napisał(a):
> Budynki to jest kolejna warstwa, wektorowa. W Google Earth były wysyłane
> jako KML i renderowane w aplikacji.
> W Google Maps zdjęcia z powietrza i mapa z drogami jest wysyłana jako
> kafelki (n.p ten:
> https://www.google.com/maps/vt/pb=!1m4!1m3!1i15!2i93
47!3i12538!2m3!1e0!2sm!3i385078492!3m7!2sen!5e1105!1
2m4!1e68!2m2!1sset!2sRoadmap!4e0!5m1!1e0!23i4112264)
,

> a widzę że warstwa 3d jest ściągana w jakimś formacie binarnym (być może
> skompresowany KML) i renderowana po stronie klienta.

A jaascript sobie radzi z formatami binarnymi, czy cos innego uzywaja?

J.

do góry

W dniu 2017-07-14 o 20:48, Jarosław Sokołowski pisze:
>
> Po kliknięciu w firefoksie w "Informacje o stronie" (albo po prostu Ctrl I)
> mamy listę mediów, a wśród nich kafelki, z jakich składa się mapa. Można
> je zapisać na dysku w oryginale. Mają 512x512px.

Pół roku temu (przenosząc się z XP na W7) zrezygnowałem z Firefoxa na
rzecz Opery - podobno mniej się muli jak się wiele okien na raz otworzy.

W menu znalazłem:
- Wyświetl źródło strony - kilkaset linii html - nie wiem czy tam bym
się doszukał. A nawet jak bym się doszukał to czy umiałbym taki jeden
kafelek ściągnąć.
- Narzędzia dla programistów - otwiera okno z zakładkami między innymi
Elements, Sources.
Nie umiem się w tym na szybko rozeznać, ale to pozostanie moim problemem
- jest oczywiste, że nie jestem programistą :).

> Serio. Wget może być za cienki, ale curlem powinno dać się zaemulować
> działanie normalnej przeglądarki. Albo napisać to w całości w jakimś
> pythonie.

O Pythonie też się kiedyś chciałbym czegoś dowiedzieć. Ja niestety, w
temacie programowania, jestem samoukiem, który gdzieś w okolicy 1995 (po
pobieżnym poznaniu Algola, Basica, Pascala, Lispa, Prologa, Fortha, C i
C++) nie miał już czasu być choć trochę na bieżąco (może też nie za
bardzo zdawałem sobie sprawę jak wiele się naokoło zmienia).
P.G.

do góry

Dnia 14.07.2017 Jacek Radzikowski <j...@s...die.die.die.piranet.org> napisał/a:
>
> Da się to zrobić, ale jest to nieco bardziej skomplikowane niż jedno
> wywołanie curla. Obrazy rastrowe przeznaczone do wyświetlania w różnych
> skalach są przechowywane jako drzewo "kafelków" przeskalowanych do
> odpowiednich rozdzielczości. Te kafelki mają stałe rozmiary, np.
> 256x256px albo 512x512px.
>

Tych wywołań będzie dużo więcej. Ustawiamy wygląd, powiększenie i
wywołujemy narzędzia developerskie w Chrome - Ctrl + Shift + I.
Przesuwamy się po mapie. W zakładce Network mamy wszystkie zapytania.
Dalej - Copy > Copy All as cURL.

Zostaje "tylko" połączyć.

> Na samym szczycie masz kafelek z mapą w małej skali (czyli mało
> szczegółów), pokazującej cały pokryty obszar. To jest skala "0" w
> terminologii aplikacji mapowej. Na następnym poziome ten sam obszar jest
> przedstawiony w dwukrotnie wyższej rozdzielczości i podzielony na 4
> (bądź 2, jeśli jest stosunek boków jest 2:1) kafelki. To jest skala "1".
> Na poziomie "2" znów masz obraz o dwukrotnie większej rozdzielczości niż
> na poziomie "1", i na każdy kafelek z "1" przypadają 4 z poziomu "2". W
> ten sposób tworzysz kolejne poziomy kafelków aż dojdziesz do obrazu
> (-ów, bo może być to być wiele zeskanowanych arkuszy map) o pełnej
> rozdzielczości. To będzie twoja mapa o największej skali (czyli
> najwięcej szczegółów).
> Poziom z którego pobiera się obrazki jest określony przez wielkość
> "zoomu", a współrzędne kafelków do pobrania oblicza się na podstawie
> współrzędnych widoku wyświetlanego na ekranie.
>
> Można ręcznie wyliczyć linki do kafelków i ściągnąć je curlem czy
> wgetem. Np. dla OpenStreetMap url ma następujący format:
> http://tile.openstreetmap.org/$zoom/$kolumna/$wiersz
.png, gdzie
> $zoom, $kolumna i $wiersz to odpowiednio poziom w drzewku, kolumna i
> wiersz w arkuszu kafelków. Arkusz o najmniejszej skali pokazujący cały
> glob to http://tile.openstreetmap.org/0/0/0.png, kolejne są na
> http://tile.openstreetmap.org/1/0/0.png,
> http://tile.openstreetmap.org/1/0/1.png, itd.
> Jak już ściągniesz wszystkie obrazy kafelków wystarczy je połączyć i
> masz gotowy obrazek.

Mapy opierają się na:
https://en.wikipedia.org/wiki/Web_Mercator

Do google maps są odpowiednie API. Przykładowo do map statycznych.
https://developers.google.com/maps/documentation/sta
tic-maps/intro

Inny dostęp wiąże się już raczej z łamaniem TOS.
Wystarczy wyszukać na githubie google+maps+tiles. Jest tego mnóstwo.

Pierwszy z brzegu najprostszy - curl + Imagemagick.
https://github.com/repohub/tile_downloader

Zmieniamy tylko w tym skrypcie nieaktualne serwery
# if [[ $4 == "s" ]]; then
# curl -s "https://khm0.google.com/kh/v=142&x=$x&y=$y&z=$z" -o "$y+$x.png"
# else
curl -s "http://mt1.google.com/vt/lyrs=m@146&hl=de&x=$x&y=$y
&z=$z" -o "$y+$x.png"
#fi

W przypadku domyślnego pythona w wersji 3 zamieniamy na python2.
http://manialabs.wordpress.com/2013/01/26/converting
-latitude-and-longitude-to-map-tile-in-mercator-proj
ection/

do góry