Samouczek dotyczący formatu KML 2.1

Ten samouczek został opracowany, aby zapoznać się z nowymi, ciekawymi funkcjami dostępnymi w KML 2.1. Jeśli interesuje Cię krótka prezentacja, zacznij od kliknięcia linków, aby przejrzeć przykłady w programie Google Earth. Jeśli chcesz dowiedzieć się więcej o nowych elementach KML, zapoznaj się z tekstem i przeanalizuj wartości, aby dowiedzieć się, jak te funkcje zwiększają elastyczność i możliwości nowej wersji Google Earth. Chętnie zobaczymy innowacyjne prezentacje i wycieczki utworzone za pomocą tych narzędzi. Szczegółowe informacje na temat omówionych tu elementów znajdziesz w materiałach referencyjnych dotyczących KML 2.1 i schematu KML 2.1.

Najciekawsze funkcje KML 2.1

• Regiony – regiony zapewniają szczegółowe funkcje i możliwości określania poziomu szczegółowości, który pozwala dostosować sposób wyświetlania danych w Google Earth. W połączeniu z NetworkLinks regiony umożliwiają strumieniowe przesyłanie bardzo dużych zbiorów danych, korzystając z „inteligentnego” wczytywania danych na różnych poziomach rozdzielczości (patrz sekcja Supernakładki). Możesz też symulować warstwy programu Google Earth za pomocą opcji Regiony.
• Teksturowane modele 3D – obiekty 3D można modelować w swoich współrzędnych i eksportować je jako pliki COLLADATM, a następnie importować do Google Earth i umieszczać na powierzchni Ziemi.
• Aktualizacje przyrostowe – teraz możesz stopniowo aktualizować dane wczytywane przez NetworkLinks – zmieniając, dodając i usuwając dane KML, które zostały wcześniej wczytane do Google Earth.
• Data/godzina ważności – możesz podać datę i godzinę, by dane były odświeżane w pamięci podręcznej, a dane były aktualne.
• Foldery opcji – aby zezwolić użytkownikowi na wybieranie tylko jednego elementu w folderze w danym momencie, użyj nowego elementu ListStyle do określenia opcji radioFolder.

Próbki fajne

• Wersje demonstracyjne prostych regionów
• Import zdjęć historycznych: MountainQ DOQQ, 1991 r. (bardzo duży zbiór danych, podzielony na podregiony ładowane przez NetworkLinks)
• Symbol uniwersytetu (model 3D COLLADA z teksturami; model oparty na rysunkach)
• Dynamiczna aktualizacja linków sieciowych
• Wymuś odświeżenie danych w określonym dniu lub o określonej godzinie (używa nowej funkcji daty ważności)
• Foldery w stylu radiowym

Sprawdź specyfikację

Oto kilka najważniejszych nowych funkcji, które pojawią się w plikach KML 2.1:

<Zmiana> <Utwórz> <Usuń> <expires> <LatLonAltBox> <listItemType> <ListStyle> <Lokalizacja> <maxLodPixels>

<minLodPixels <Orientacja> <s> <Model> <Region> <Skala> <targetHref> <Aktualizacja>

Praca z regionami

Regiony to nowa, zaawansowana funkcja KML, która umożliwia dodawanie do Google Earth bardzo dużych zbiorów danych bez szkody dla wydajności. Dane są wczytywane i rysowane tylko wtedy, gdy znajdują się w widoku użytkownika i zajmują określoną część ekranu. Za pomocą Regionów możesz udostępniać dane na różnych poziomach, aby były one wczytywane tylko wtedy, gdy dane wypełnią część ekranu wystarczającą do ich wyświetlenia.

Uwaga: w przypadku plików KML niektóre klasy są pobierane z klasy „parent”. Zajęcia z „podrzędnych” dziedziczą wszystkie elementy klasy nadrzędnej i dodają własne. Jest to typowa metoda w systemach zorientowanych na obiekty. Dla ułatwienia w tej sekcji znajduje się klasa nadrzędna zamiast wyświetlania wszystkich pochodnych klas podrzędnych. Przykład:

• Termin Funkcja oznacza dowolny element KML, który pochodzi z funkcji: Dokument, Folder, Nakładka naziemna, NetworkLink, Oznaczenie miejsca i Nakładka ekranu.
• Geometria określa każdy element geometryczny w formacie KML: punkt, wielokąt, liniowy rząd, linię, model lub wiele geometrii.
• Nakładka odnosi się do elementów pochodzących z nakładki: Grunt i Nakładka na ekran.

Diagram przedstawiający dziedziczenie elementów KML znajdziesz w dokumentacji KML.

Kluczowe pojęcia

Każda funkcja może zawierać region. Region wpływa na widoczność geometrii oznaczenia miejsca lub obrazu nakładki. Regiony określają zarówno przypisywanie, jak i poziom szczegółowości danych geometrycznych lub nakładek. Regiony są dziedziczone za pomocą hierarchii KML i mają wpływ na widoczność cech zdefiniowanych w hierarchii.

W tej sekcji opisano te kluczowe zagadnienia niezbędne do zrozumienia regionów:

• Pole ramki
• Poziom szczegółów
• Wysokość
• Zasięg zanikania
• Regiony Nest
• NetworkLinks w regionie

Pole ramki

Region zawiera element <LatLonAltBox>, który określa ramkę ograniczającą dane. Pole ograniczające to wolumin, który obejmuje zbiór obiektów lub punktów danych. Podobnie jak w przypadku elementu <LatLonBox> w GroundOverlay, <LatLonAltBox> w regionie ma granice północne, południowe, wschodnie i zachodnie. Jeśli dane zawarte w regionie mają wartość 3D lub wysokość 2D na wysokości, pole <LatLonAltBox> regionu musi również zawierać minimalną wysokość, <minAlheight> i maksymalną wysokość <maxAlheight>.

Obiekty powiązane z tą ramką ograniczającą są rysowane, gdy (1) obszar jest widoczny i (2) przewidywany rozmiar ekranu <LatLonAltBox> mieści się w określonym zakresie pikseli, zgodnie z opisem w sekcji Poziom szczegółów (LOD). Jeśli oba te warunki są spełnione, region jest określany jako „aktywny”.

Poziom szczegółów (LOD)

Drugą ważną kwestią w kontekście regionów jest opcja Poziom szczegółów, czyli inaczej LOD. Ekran komputera ma ograniczoną ilość miejsca, dlatego najlepiej skonfigurować go tak, aby duże ilości danych były wczytywane tylko wtedy, gdy jest dostatecznie dużo pikseli, by można było wyświetlić odpowiednią ilość danych. Gdy region zajmuje stosunkowo małą część ekranu (np. użytkownik ogląda go z dużej odległości lub płaski obszar), funkcja LOD umożliwia (zezwalanie autorowi KML) na wybranie zbioru danych o niższej rozdzielczości, aby zastępować dane o pełnej rozdzielczości. Zbiór danych o niższej rozdzielczości wczytuje się szybciej, a ponieważ zajmuje niewielką część ekranu, użytkownik nie jest w stanie ich odróżnić.

W regionie elementy <minLodPixels> i <maxLodPixels> pozwalają określić obszar ekranu (w pikselach kwadratowych). Aby dane były wyświetlane na ekranie, muszą zajmować obszar większy niż <minLodPixels> i mniej niż <maxLodPixels>. Gdy prognozowany rozmiar regionu przekracza te limity, nie jest on już widoczny, a region stanie się nieaktywny.

W szczególnych przypadkach, gdy chcesz, aby dane miały nieskończony rozmiar, określ wartość -1 (domyślnie) dla <maxLodPixels>.

Przykład 1: region dla nakładki naziemnej

Najpierw spójrzmy na prosty przykład, który tworzy region dla nakładki 2D na poziomie gruntu. W tym przykładzie użyto warstwy terenu zawierającej dane historyczne pokazujące część miasta Mountain View w 1991 roku. Gdy użytkownik powiększy obszar, nakładka stanie się widoczna. Oto, jak wygląda nakładka (gdy jest ona widoczna po raz pierwszy) – przykładowy plik zawiera również biały wiersz ułatwiający wyróżnienie nakładki:

W tym przykładzie <minLodPixels> ma wartość 128, co oznacza, że gdy pole zajmuje 128 pikseli kwadratowych, ekran jest widoczny na ekranie. (W przykładzie użyto wartości domyślnej -1 dla elementu <maxLodPixels>, co oznacza, że pozostanie ona widoczna pod kątem powiększenia pod tym kątem). Obraz używany w tej nakładce ma kwadrat o boku 256 pikseli.

Tak wygląda obraz, gdy użytkownik go powiększy:

Przechylony obraz wygląda tak, jakby był niewidoczny, ponieważ zajmuje mniej miejsca na ekranie niż wartość <minLodPixels>:

Element <LatLonAltBox> dla tych danych nie musi zawierać elementów <minAltitude> i <maxAltitude>, ponieważ dane są płaskie i są na poziomie gruntu. Ramka ograniczająca dane w elemencie <LatLonAltBox> regionu jest identyczna z granicami warstwy <LatLonBox> nakładki ziemi, jak widać w pliku KML poniżej:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
  <Document>
    <name>Flat Region</name>
    <Region>
      <LatLonAltBox>
        <north>37.430419921875</north>
        <south>37.41943359375</south>
        <east>-122.080078125</east>
        <west>-122.091064453125</west>
      </LatLonAltBox>
      <Lod>
        <minLodPixels>128</minLodPixels>
      </Lod>
    </Region>
    <GroundOverlay>
      <name>Mountain View DOQQ</name>
      <Icon>
        <href>files/image.JPEG</href>
      </Icon>
      <LatLonBox>
        <north>37.430419921875</north>
        <south>37.41943359375</south>
        <east>-122.080078125</east>
        <west>-122.091064453125</west>
      </LatLonBox>
    </GroundOverlay>
  <Document>
</kml>

Ponadto w pliku KML zwróć uwagę, że region jest bliźniaczym obrazem (lub geometrią), którego widoczność ma wpływ.

Po sprawdzeniu pliku KML kliknij link poniżej, aby wczytać nakładkę do Google Earth. Następnie poeksperymentuj z różnymi punktami widokowymi i obejrzyj film, gdy region będzie widoczny i niewidoczny, zależnie od wymaganej powierzchni ekranu. Pamiętaj, że jeśli przechylysz widok wystarczająco mocno lub jeśli widok jest dość powiększony, nakładka znika, ponieważ zajmuje za mało miejsca na ekranie, by spełnić wymóg <minLodPixels>.

Zobacz przykład w Google Earth (historicOverlay.kmz)

Wysokość

Przykład 2: region dla modelu 3D

Poniższy przykład pokazuje, jak utworzyć region zawierający obiekty 3D na poziomie gruntu. <LatLonAltBox> dla tego regionu zawiera wartość <maxAltitude> 300 metrów, ponieważ to jest wysokość budynku. Prawdopodobnie rozpoznasz te budynki jako kompleks Organizacji Narodów Zjednoczonych w Nowym Jorku.

Pamiętaj, że granice <LatLonAltBox> regionu nie muszą być takie same jak długość i szerokość geograficzna modelu. Współrzędne modelu zależą od jego lokalnego źródła, które może być odsunięte od rzeczywistego położenia modelu na Ziemi.

<?xml version='1.0' encoding='UTF-8'?>
<kml xmlns="http://earth.google.com/kml/2.1">
  <Document>
    <name>3D Region on ground</name>
    <Placemark>
      <name>United Nations Headquarters</name>
      <visibility>0</visibility>
      <Region>
        <Lod>
          <minLodPixels>128</minLodPixels>
        </Lod>
        <LatLonAltBox>
          <north>40.750683130314</north>
          <south>40.748162385230</south>
          <east>-73.966608428427</east>
          <west>-73.969476624071</west>
          <minAltitude>0</minAltitude>
          <maxAltitude>300</maxAltitude>
          <altitudeMode>absolute</altitudeMode>
        </LatLonAltBox>
      </Region>
      <Model>
        <altitudeMode>absolute</altitudeMode>
        <Location>
          <longitude>-73.967763927199</longitude>
          <latitude>40.749458312255</latitude>
          <altitude>0.406173708576</altitude>
        </Location>
        <Link>
          <href>models/un.dae</href>
        </Link>
      </Model>
    </Placemark>
  </Document>
</kml>

Kliknij poniższy link, aby wczytać plik do Google Earth. Ponownie poeksperymentuj z różnymi punktami widokowymi, aby zobaczyć, kiedy budynki staną się widoczne, a kiedy zostaną usunięte.

Zobacz przykład w Google Earth (unitedNations.kmz)

Przykład 3: Region dla nakładki 2D na wysokości

Ten przykład pokazuje, jak dodać nakładkę 2D do wyświetlania nad powierzchnią Ziemi na określonej wysokości. Ta technika jest przydatna w przypadku danych pokazujących prognozy pogody i wzorce ruchu lotniczego. W tym przykładzie widać niewielkie zachmurzenie na wysokości 100 000 m n.p.m.

Wartość <LatLonAltBox> regionu określa wartość 100 000 metrów zarówno dla elementów <minAltitude>, jak i <maxAltitude>. Wartość jest taka sama w przypadku obu elementów, ponieważ nakładka jest 2D i nie ma grubości. Element <altitudeMode> jest bezwzględny, co oznacza, że ta wartość jest uzależniona od poziomu morza.

Zauważ, że wartość <altitude> wartości GroundOverlay jest również 100 000 (czyli odpowiada wysokości wysokości ramki ograniczenia regionu) i <altitudeMode> obiektu GroundOverlay odpowiada wartości określonej dla wartości <altitudeMode> regionu.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
  <Document>
    <name>Flat Region at altitude</name>
    <GroundOverlay>
      <name>Cloud overlay</name>
      <Region>
        <LatLonAltBox>
          <north>33.75</north>
          <south>22.5</south>
          <east>-45</east>
          <west>-56.25</west>
          <minAltitude>100000</minAltitude>
          <maxAltitude>100000</maxAltitude>
          <altitudeMode>absolute</altitudeMode>
        </LatLonAltBox>
        <Lod>
          <minLodPixels>128</minLodPixels>
        </Lod>
      </Region>
      <Icon>
        <href>files/image.PNG</href>
      </Icon>
      <altitude>100000</altitude>
      <altitudeMode>absolute</altitudeMode>
      <LatLonBox>
        <north>33.75</north>
        <south>22.5</south>
        <east>-45</east>
        <west>-56.25</west>
      </LatLonBox>
    </GroundOverlay>
  </Document>
</kml>

Zobacz przykład w Google Earth (cloudRegion.kmz)

Zasięg zanikania

Możesz też określić zakres zanikania regionu, co pozwala płynnie przejść z trybu przezroczystego na nieprzezroczysty i z powrotem. Google Earth korzysta z parametru maxFadeExtent, aby określić, czy platforma ma być w pełni przezroczysta, czy nieprzejrzysta, gdy region osiąga maksymalny możliwy rozmiar. Dodatkowo stosowana jest zasada minFadeExtent, która wskazuje poziom zanikania, gdy region ma minimalny widoczny rozmiar. Zakresy zanikania są opcjonalne, ale zapobiegają efektowi „pop” między wierszami i wielokątami o różnych rozdzielczościach. Zanikanie jest bardzo kosztowne pod względem wydajności, więc nie należy ich używać na zdjęciach.

Uwaga: zakres zanikania dotyczy wszystkich obiektów z wyjątkiem ikon oznaczenia miejsca. Te ikony są rysowane, gdy zakres zanikania przekracza 0,5.

 

Poniższy przykład pokazuje, jak zakres zanikania wpływa na wiersz.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>Region in Placemark LineString</name>
  <description>
    The LineString corners mark the extent
    of the Region LatLonAltBox.
    The LineString minFadeExtent (at greatest range)
    is 1/4 of the maxFadeExtent (at closest range)..
  </description>
  <Placemark>
    <name>Region LineString</name>
    <LineString>
      <coordinates>
        22,50,0
        28,50,0
        28,45,0
        22,45,0
        22,50,0
      </coordinates>
    </LineString>
    <Region> 
      <LatLonAltBox> 
        <north>50</north> 
        <south>45</south> 
        <east>28</east> 
        <west>22</west> 
      </LatLonAltBox> 
      <Lod>
        <minLodPixels>128</minLodPixels> 
        <maxLodPixels>1024</maxLodPixels> 
        <minFadeExtent>128</minFadeExtent>
        <maxFadeExtent>512</maxFadeExtent>
      </Lod>
    </Region> 
  </Placemark>
</Document>
</kml>

Zobacz przykład w Google Earth (fadeLineString.json)

Regiony Nest

Regiony są powszechnie używane do zagnieżdżania, z większymi regionami powiązanymi z niższą rozdzielczością i mniejszymi regionami, ze względu na coraz bardziej szczegółowy poziom szczegółowości. Na poniższej ilustracji każdy region ma ustawiony limit LOD, który określa przewidywany rozmiar ekranu regionu w pikselach wymagany do aktywowania powiązanego regionu. W miarę zbliżania się punktu widzenia użytkownika regiony z bardziej szczegółowym poziomem szczegółowości (LOD) stają się aktywne, bo zajmują więcej miejsca na ekranie. Regiony z węższym poziomem zapełnienia zastępują te z mniejszym poziomem obciążenia.

Po aktywowaniu zagnieżdżonych regionów można

• Zbieraj dane powiązane z każdym regionem (jak w przykładzie Supernakładka poniżej).
• Zastąp dane poprzednio wczytanymi regionami nowymi (jak pokazano na poprzedniej ilustracji).

Element <LatLonAltBox> w regionie podrzędnym powinien być w całości zawarty w tagu <LatLonAltBox> jego regionu nadrzędnego. Hierarchia regionów jest dziedziczona za pomocą hierarchii folderów i linków sieciowych. Regiony zdefiniowane lokalnie mają pierwszeństwo przed regionami określonymi wyżej w hierarchii folderów. Poniższy przykład pokazuje, jak lokalny zakres regionu zastępuje region zdefiniowany wyżej w hierarchii. W tym przykładzie oznaczenie miejsca „ukraineRegion” dziedziczy region z dokumentu nadrzędnego. Folder „romaniaFolder” określa własny region używany przez oznaczenie miejsca „romaniaRegion”. Więcej informacji o korzystaniu z regionów w linkach sieciowych znajdziesz w kolejnej sekcji na temat inteligentnego wczytywania linków sieciowych opartych na regionach.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>Nested Regions</name>
  <Region>
    <LatLonAltBox>
      <north>56.25</north>
      <south>45</south>
      <east>33.75</east>
      <west>22.5</west>
    </LatLonAltBox>
    <Lod>
      <minLodPixels>128</minLodPixels>
      <maxLodPixels>1024</maxLodPixels>
    </Lod>
  </Region>
  <Placemark>
    <name>ukraineRegion</name>
    <LineString>
      <tessellate>1</tessellate>
      <coordinates>
        22.5,45,0
        33.75,45,0
        33.75,56.25,0
        22.5,56.25,0
        22.5,45,0
      </coordinates>
    </LineString>
  </Placemark> 
  <Folder>
    <name>romaniaFolder</name>
    <Region>
      <LatLonAltBox>
        <north>50.625</north>
        <south>45</south>
        <east>28.125</east>
        <west>22.5</west>
      </LatLonAltBox>
      <Lod>
        <minLodPixels>128</minLodPixels>
        <maxLodPixels>1024</maxLodPixels>
      </Lod>
    </Region>
    <Placemark>
      <name>romaniaRegion</name>
      <LineString>
        <tessellate>1</tessellate>
        <coordinates>
          22.5,45,0
          28.125,45,0
          28.125,50.625,0
          22.5,50.625,0
          22.5,45,0
        </coordinates>
      </LineString>
    </Placemark>
  </Folder>
</Document>
</kml>

„Inteligentne” ładowanie linków sieciowych opartych na regionach

Oparty na regionie region NetworkLink w powyższym przykładzie jest najskuteczniejszym sposobem publikowania bardzo dużego zbioru danych w programie Google Earth. Korzystając z opcji Regiony w połączeniu z usługą NetworkLink, możesz utworzyć hierarchię wskaźników, z których każdy wskazuje na określony podregion. Element <viewRefreshMode>, tak jak w tym pliku KML, zawiera opcję onRegion, która określa, że dane regionu mają być ładowane tylko wtedy, gdy region jest aktywny. Jeśli podasz zagnieżdżone regiony z wieloma poziomami szczegółowości, większe ilości danych będą ładowane tylko wtedy, gdy punkt widokowy wywoła następne wczytanie. Szczegółowa przykładowa sekcja znajduje się w sekcji Nakładki.

Część 1. Plik nadrzędny

Aby uruchomić ten przykład, zapisz pierwszą część w zwykły sposób. Zapisz drugą część jako romaniaRegion.json, aby NetworkLink mogła wczytać region, gdy stanie się aktywny.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>Nested Regions</name> 
  <Region>
    <LatLonAltBox>
      <north>56.25</north>
      <south>45</south>
      <east>33.75</east>
      <west>22.5</west>
    </LatLonAltBox>
    <Lod>
      <minLodPixels>128</minLodPixels>
      <maxLodPixels>1024</maxLodPixels>
    </Lod>
  </Region>
  <Placemark>
    <name>ukraineRegion</name>
    <LineString>
      <tessellate>1</tessellate>
      <coordinates>
        22.5,45,0
        33.75,45,0
        33.75,56.25,0
        22.5,56.25,0
        22.5,45,0
      </coordinates>
    </LineString>
  </Placemark> 
  <NetworkLink>
    <name>romania NetworkLink</name>
    <Region>
      <LatLonAltBox>
        <north>50.625</north>
        <south>45</south>
        <east>28.125</east>
        <west>22.5</west>
      </LatLonAltBox>
      <Lod>
        <minLodPixels>128</minLodPixels>
        <maxLodPixels>1024</maxLodPixels>
      </Lod>
    </Region>
    <Link>
      <href>romaniaRegion.kml</href>
      <viewRefreshMode>onRegion</viewRefreshMode>
    </Link>
  </NetworkLink>
</Document>
</kml>

Część 2. Plik NetworkLink z uwzględnieniem regionu

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>romania Document</name>
    <Region>
      <LatLonAltBox>
        <north>50.625</north>
        <south>45</south>
        <east>28.125</east>
        <west>22.5</west>
      </LatLonAltBox>
      <Lod>
        <minLodPixels>128</minLodPixels>
        <maxLodPixels>1024</maxLodPixels>
      </Lod>
    </Region>
  <Placemark>
    <name>romaniaRegion</name>
    <LineString>
      <tessellate>1</tessellate>
      <coordinates>
        22.5,45,0
        28.125,45,0
        28.125,50.625,0
        22.5,50.625,0
        22.5,45,0
      </coordinates>
    </LineString>
  </Placemark>
</Document>
</kml>

Superobrazy

P: Jak udostępnić zdjęcie o rozmiarze 47 MB?
A: jeden fragment naraz.

P: Co się stanie, jeśli tak zrobi każdy?
O: Jeśli używasz NetworkLinks związanych z regionem i podajesz w zdjęciach wiele poziomów szczegółów zgodnie z opisem w tym samouczku, nie ma problemu.

Z tej sekcji dowiesz się, jak utworzyć „nakładkę” (hierarchię) regionów i linków sieciowych, która służy do efektywnego wyświetlania dużego zestawu zdjęć. Kafelki o odpowiedniej rozdzielczości są ładowane w chwili pojawienia się fragmentów obszaru zdjęcia. Kafelki o wyższej rozdzielczości są ładowane w pobliżu punktu widokowego. Staraj się wyświetlać obraz o rozdzielczości 7008 na 6720 pikseli na ekranie 1024 na 768 pikseli. Co więcej, jeśli użytkownik znajduje się kilometry nad powierzchnią Ziemi, wszystkie dane mogą zostać przytłaczone do kilku pikseli, a wydajność będzie niestabilna. Supernakładki, tak jak nasz przykład firmy DOQQ z 1991 roku w Mountain View w Kalifornii, pozwalają wykorzystać sieci NetworkLink i umożliwić im: (1) sprawdzenie, czy dany region jest widoczny, oraz (2) sprawdzenie, czy jego przewidywany rozmiar jest odpowiedni dla obecnego punktu widokowego. Jeśli region jest aktywny (spełniają oba warunki), NetworkLink wczytuje dane powiązane z regionem. Jeśli region jest nieaktywny, żadne dane nie są wczytywane. Jeśli podzielisz oryginalny obraz na hierarchię zdjęć o większym stopniu szczegółowości, Google Earth wczyta obrazy, które najlepiej pasują do bieżącego widoku.

Aby zobaczyć, jak używana jest ta hierarchia obrazów, wczytaj ten przykładowy plik w Google Earth i poeksperymentuj, przybliżając lub oddalając interesujący Cię obszar: Widok historyczny Mountain View DOQQ.

 

Przykład użycia linków sieciowych dotyczących regionu do efektywnego ładowania bardzo dużego zbioru danych. Oryginalny obraz ma wymiary 7008 na 6720 pikseli. Widok skośny widoczny tutaj prezentuje tylko 5 małych kafelków, które będą reprezentować ten obraz. (Dodano białe ciągi znaków, aby wyróżnić fragmenty). Ta aplikacja prezentuje zdjęcia historyczne miasta Mountain View (z 1991 roku, DOQQ).

Przygotowywanie danych dla supernakładki

W przykładowym nakładce górnych oryginalny obraz Mountain View jest podzielony na setki małych obrazów obiektów. Te nakładki (czyli kafelki) są uporządkowane w 5-poziomowej hierarchii. Na potrzeby omawianej tu przykładowo użyto prostej trzypoziomowej hierarchii i zestawu 21 nakładek, ale zasady pozostają takie same. Pamiętaj, że to tylko jedno podejście do tworzenia hierarchii linków sieciowych zależnych od regionu oraz że istnieją inne sposoby implementacji tego mechanizmu.

Aby utworzyć nakładkę górną, musisz:

1. Przygotuj zdjęcia, dzieląc je na mniejsze porcje (zalecane 256 na 256 pikseli).
2. Utwórz pliki KML, które zostaną skonfigurowane dla regionów, linków i linków sieciowych, a w tym przypadku dla plików GroundOverlay.

Przygotowywanie zdjęć

Wybierz standardowy rozmiar swoich kafelków, czyli podzielone obrazy (o różnych rozdzielczościach), które Google Earth będzie wczytywać w miarę aktywowania powiązanych regionów. W przypadku kafelków użyjemy na przykład 256 na 256 pikseli, czyli wystarczająco małego rozmiaru, aby można było nim zarządzać.

1. Zacznij od oryginalnego obrazu w pełnej rozdzielczości. Podziel je na n kafelków, a następnie podziel każdy z nich na n kafelków.
   Kontynuuj dzielenie, aż znajdziesz kafelki o danym rozmiarze (w tym przykładzie są to 256 x 256 pikseli).
   
   Załóżmy, że oryginalny obraz ma wymiary 1024 na 1024 piksele.
   Poniższa hierarchia byłaby wynikiem podziału.

 

 

2. Dopasuj każdy kafelek w hierarchii do wybranego rozmiaru standardowego (np. 256 x 256 pikseli).
   Te kafelki z próbkowanymi fragmentami będą zawierać mniej szczegółów, ale będą powiązane z regionami, które są aktywne w większej liczbie punktów widokowych. W rezultacie utrata danych będzie niezauważalna dla użytkownika.

 

Poniższy diagram pokazuje, jak punkt widokowy i definicja zagnieżdżonych regionów określają, które kafelki są wczytywane. W dużych fragmentach tych zdjęć wykorzystane są 3 poziomy szczegółowości. Gdy użytkownik patrzy na region z największej odległości, Google Earth wyświetla widok miniatur. Widok jest rozciągany na całe pole LatLonAltBox (ale przewidywany rozmiar to 256 pikseli kwadratowych – rzeczywista utrata informacji wizualnych nie jest ograniczona). Gdy użytkownik powiększa widok, Region jest podzielony na 4 regiony. Każdy z tych 4 kafelków ma ten sam rozmiar co obraz miniatury, ale zawiera bardziej szczegółowe zdjęcia.

Jeśli użytkownik będzie nadal powiększał obszar, wyświetlane będą fragmenty zdjęć w pełnej rozdzielczości, w zależności od tego, jak daleko użytkownik do nich dotrze. Obszary na odległość obejmują mniej szczegółowe zdjęcia, które zostały wczytane jako pierwsze. W przykładzie Mountain View DOQQ włącz „Box” i sprawdź oznaczenia miejsc A i B, które korzystają z linii wzdłuż określonych regionów i jednocześnie wyświetlają wiele poziomów hierarchii.

Pamiętaj, że w przykładzie używane są te same wartości parametrów minLodPixels i MaxLodPixels we wszystkich regionach (na wszystkich poziomach hierarchii). To LatLonAltBox określa, który poziom hierarchii ma zostać załadowany, a które kafelki w regionie.

Przygotowywanie plików KML

Dla każdego obrazu przygotuj plik KML wiążący nakładkę na poziomie terenu z regionem i NetworkLink. Każdy plik KML w tym zestawie zawiera następujące elementy:

• Region (za pomocą parametrów LatLonAltBox, minLodPixels i maxLodPixels, aby program Google Earth mógł określić, czy region jest w danym momencie aktywny).
• Zbiór NetworkLinks do plików podrzędnych (kafelki na następnym poziomie hierarchii)
• nawierzchnia w tym regionie

W tym przykładzie pokazano plik KML najwyższego poziomu dla przykładowego pliku Mountain View DOQQ w Mountain View. W przypadku maxLodPixel określa wartość -1, która ma specjalne znaczenie „w przypadku rozmiaru nieskończonego”. Bez tej specyfikacji cała hierarchia może nie zostać uruchomiona.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
  <NetworkLink>
    <name>SuperOverlay: MV DOQQ</name>
    <Region>
      <LatLonAltBox>
        <north>37.44140625</north>
        <south>37.265625</south>
        <east>-121.9921875</east>
        <west>-122.16796875</west>
      </LatLonAltBox>
      <Lod>
        <minLodPixels>128</minLodPixels>
        <maxLodPixels>-1</maxLodPixels>
      </Lod>
    </Region>
    <Link>
      <href>http://mw1.google.com/mw-earth-vectordb/kml-samples/mv-070501/1.kml</href>
      <viewRefreshMode>onRegion</viewRefreshMode>
    </Link>
  </NetworkLink>
</kml>

W tym pliku widać region w przykładzie DOQQ w Mountain View (179.json). Ten plik zawiera 5 tagów href: 4 odnoszą się do 4 plików KML na następnym poziomie hierarchii obrazów, a 1 oznacza plik obrazu używany na potrzeby GroundOverlay tego kafelka.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
  <Document>
    <Region>
      <Lod>
        <minLodPixels>128</minLodPixels><maxLodPixels>-1</maxLodPixels>
      </Lod>
      <LatLonAltBox>
        <north>37.430419921875</north><south>37.41943359375</south>
        <east>-122.091064453125</east><west>-122.10205078125</west>
      </LatLonAltBox>
    </Region>
    <NetworkLink>
      <name>001120</name>
      <Region>
        <Lod>
          <minLodPixels>128</minLodPixels><maxLodPixels>-1</maxLodPixels>
        </Lod>
        <LatLonAltBox>
          <north>37.430419921875</north><south>37.4249267578125</south>
          <east>-122.0965576171875</east><west>-122.10205078125</west>
        </LatLonAltBox>
      </Region>
      <Link>
        <href>180.kml</href>
        <viewRefreshMode>onRegion</viewRefreshMode>
      </Link>
    </NetworkLink>
    <NetworkLink>
      <name>001121</name>
      <Region>
        <Lod>
          <minLodPixels>128</minLodPixels><maxLodPixels>-1</maxLodPixels>
        </Lod>
        <LatLonAltBox>
          <north>37.430419921875</north><south>37.4249267578125</south>
          <east>-122.091064453125</east><west>-122.0965576171875</west>
        </LatLonAltBox>
      </Region>
      <Link>
        <href>185.kml</href>
        <viewRefreshMode>onRegion</viewRefreshMode>
      </Link>
    </NetworkLink>
    <NetworkLink>
      <name>001122</name>
      <Region>
        <Lod>
          <minLodPixels>128</minLodPixels><maxLodPixels>-1</maxLodPixels>
        </Lod>
        <LatLonAltBox>
          <north>37.4249267578125</north><south>37.41943359375</south>
          <east>-122.0965576171875</east><west>-122.10205078125</west>
        </LatLonAltBox>
      </Region>
      <Link>
        <href>190.kml</href>
        <viewRefreshMode>onRegion</viewRefreshMode>
      </Link>
    </NetworkLink>
    <NetworkLink>
      <name>001123</name>
      <Region>
        <Lod>
          <minLodPixels>128</minLodPixels><maxLodPixels>-1</maxLodPixels>
        </Lod>
        <LatLonAltBox>
          <north>37.4249267578125</north><south>37.41943359375</south>
          <east>-122.091064453125</east><west>-122.0965576171875</west>
        </LatLonAltBox>
      </Region>
      <Link>
        <href>195.kml</href>
        <viewRefreshMode>onRegion</viewRefreshMode>
      </Link>
    </NetworkLink>
    <GroundOverlay>
      <drawOrder>5</drawOrder>
      <Icon>
        <href>179.JPEG</href>
      </Icon>
      <LatLonBox>
        <north>37.430419921875</north><south>37.41943359375</south>
        <east>-122.091064453125</east><west>-122.10205078125</west>
      </LatLonBox>
    </GroundOverlay>
  </Document>
</kml>

Wyświetlanie obiektów 3D

W KML 2.1 możesz importować modele 3D – takie jak budynki, mosty, pomniki i pomniki – w formacie pliku wymiany COLLADA. Modele są zdefiniowane niezależnie od Google Earth we własnej przestrzeni współrzędnej przy użyciu aplikacji, takich jak SketchUp, 3D Studio Max, Softimage XSI lub Maya. Model 3D zaimportowany do Google Earth jest tłumaczony, obracany i skalowany w celu dopasowania do układu współrzędnych. Elementów wczytanych do Google Earth można zmieniać położenie i rozmiar, korzystając z elementu <Update> – kolejnej nowej funkcji w KML 2.1.

Przykładowy model

Model jest używany w Google Earth tak samo jak każdy inny obiekt geometryczny (punkt, wiersz lub wielokąt). Oto prosty przykład pliku KML, który importuje model teksturowany.

Odwołanie do <Link> modelu może być absolutną lub względną specyfikacją pliku lub URL.

Aby wyświetlić ten model, wczytaj plik MackyBldg.kmz, który zawiera archiwum zawierające wszystkie niezbędne pliki tekstur i nakładek oraz plik doc.json zawierający model:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Placemark>
  <name>SketchUp Model of Macky Auditorium</name>
  <description>University of Colorado, Boulder; model created by Noël Nemcik.</description>
  <LookAt>
    <longitude>-105.2727379358738</longitude>
    <latitude>40.01000594412381</latitude>
    <altitude>0</altitude>
    <range>127.2393107680517</range>
    <tilt>65.74454495876547</tilt>
    <heading>-27.70337734057933</heading>
  </LookAt>
  <Model id="model_4">
    <altitudeMode>relativeToGround</altitudeMode>
    <Location>
      <longitude>-105.272774533734</longitude>
      <latitude>40.009993372683</latitude>
      <altitude>0</altitude>
    </Location>
    <Orientation>
      <heading>0</heading>
      <tilt>0</tilt>
      <roll>0</roll>
    </Orientation>
    <Scale>
      <x>1</x>
      <y>1</y>
      <z>1</z>
    </Scale>
    <Link>
      <href>files/CU Macky.dae</href>
    </Link>
  </Model>
</Placemark>
</kml>

Model jest położony geograficznie ze specyfikacją szerokości, długości i wysokości elementu zamówienia. W tym przykładzie użyto wartości domyślnych dla elementów Orientacja i Skala, które są podane tutaj dla kompletności.

Element Orientacja określa obrót modelu wokół osi x (przechylenie), y (rolka) i z (nagłówek). Oś y wskazuje północ i równolegle do linii długości geograficznej, a oś X kieruje na wschód i równolegle do linii szerokości geograficznej. Obroty są określane w stopniach, z dodatnimi obrotami jak na tym diagramie.

Tworzenie archiwum .kmz

Archiwum KMZ to zbiór plików używanych do tworzenia jednej prezentacji KML. To archiwum obejmuje wszystkie pliki lokalne, do których odwołuje się plik .json, takie jak obrazy, tekstury i modele. Archiwum KMZ to samodzielny pakiet, który nie musi być przechowywany na serwerze sieciowym. Można go łatwo przesłać pocztą e-mail i zapisać jako pojedynczą jednostkę. Google Earth może odczytywać pliki .json i .kmz bezpośrednio.

Plik doc.json i pliki lokalne, do których się odnoszą, są skompresowane w archiwum w formacie ZIP. Ten format można zastosować w wielu aplikacjach. WinZip w systemach Windows, Stuffit w systemach macOS i ZIP w systemach Linux lub macOS to popularne aplikacje do odczytu i zapisu formatu ZIP. Możesz też pracować z archiwami ZIP za pomocą przeglądarki Windows Explorer lub Mac Finder.

Po utworzeniu pliku .zip zmień rozszerzenie na .kmz.

Archiwum KMZ zawierające pełny model teksturowany dla budynku Macky zawiera te pliki:

• doc.json – plik KML pokazany powyżej, który importuje model COLLADA (.dae) i umieszcza go w Google Earth. Umieść ten plik w katalogu głównym pliku KMZ (ZIP).
• textures.txt – służy do mapowania ścieżek tekstur w pliku modelu (tutaj CU Macky.dae) na ścieżki w pliku KMZ. Umieść ten plik w katalogu głównym pliku KMZ (ZIP). Każda tekstura, do której odwołuje się plik CU Macky .dae, ma jeden wiersz w pliku textures.txt:

<kmz_file_path> <COLLADA_file_path> [<KML_ID_of_model>]

<kmz_file_path> to względna ścieżka w archiwum KMZ, w której znajduje się tekstura. Ta ścieżka jest zgodna z plikiem CU Macky.dae, który znajduje się w katalogu files/ w archiwum KMZ. Tekstury są przechowywane w katalogu files/, więc ścieżka <kmz_file_path> powinna zaczynać się od ../files/.

<COLLADA_file_path> to nazwa pliku tekstury dokładnie w takiej postaci, w jakiej występuje w pliku CU Macky .dae.

[KML_ID] to identyfikator modelu KML, który korzysta z tej tekstury. Tekstury mogą być używane przez wiele modeli. Ten parametr jest opcjonalny.

Oto fragment pliku textures.txt z przykładem:

<../files/CU-Macky---Center-StairsnoCulling.jpg> <CU-Macky---Center-StairsnoCulling.jpg> <model_4>
<../files/CU-Macky-4sideturretnoCulling.jpg> <CU-Macky-4sideturretnoCulling.jpg> <model_4>
<../files/CU-Macky-Back-NorthnoCulling.jpg> <CU-Macky-Back-NorthnoCulling.jpg> <model_4>

• files/ zawiera pliki COLLADA, które definiują geometrię, tekstury i materiały modelu. W przykładzie budynku Macky'ego ten katalog zawiera plik COLLADA (CU Macky.dae), a także liczne pliki zawierające obrazy JPEG służące do teksturowania budynku (CU-Macky-BrickwallnoCulling.jpg, CU-Macky--Center-StairsnoCulling.jpg, CU_Macky-EastdetaildoornoCulling.jpg).

Ten przykład pokazuje, jak uporządkować pliki w archiwum KMZ. Pliki możesz porządkować w dowolnej strukturze, która wydaje Ci się logiczna, podobnie jak w przypadku umieszczania ich w folderach i katalogach na komputerze. Warto na przykład umieścić wszystkie obrazy w katalogu images/. Odwołania względne (np. pliki, do których odwołuje się element <href> używany w linkach NetworkLink, Link, Nakładka/Icon i Model) są określane względem pliku doc.json. W przypadku dołączenia katalogu Obrazy specyfikacja <href> będzie taka: images/myBrickTexture.jpg, images/myMountainOverlay.png itd.).

Aktualizowanie danych ładowanych przez linki sieciowe

Aby stopniowo modyfikować dane ładowane przez NetworkLink, użyj elementu Update, który jest elementem podrzędnym elementu NetworkLinkControl. Aktualizacja może zawierać dowolną liczbę elementów Change, Create i Delete, które są przetwarzane w określonej kolejności.

Ilustracja poniżej przedstawia sekwencję zdarzeń.

1. NetworkLink wczytuje do Google Earth oryginalny plik KML. Element, który chcesz później zaktualizować, musi mieć jawny identyfikator na początku. Identyfikatory muszą być niepowtarzalne w obrębie danego pliku.
2. Kolejny NetworkLink ładuje drugi plik KML zawierający aktualizacje (dowolną kombinację zmian, tworzenia i usuwania) do wczytanych obiektów KML. Plik aktualizacji zawiera dwa odniesienia do oryginalnych danych KML:
3. Aby zlokalizować obiekty w Google Earth, element Update używa elementu targetHref do identyfikowania oryginalnego pliku, który definiuje obiekty do zmodyfikowania. Aby zidentyfikować obiekty, które mają zostać zmodyfikowane, lub kontener na nowe obiekty, elementy Change, Create i Delete(Zmień, Utwórz i Usuń) zawierają atrybut targetId, który odwołuje się do id tych obiektów.

Przykład zmiany

Przykład poniżej pokazuje zestaw przykładowych plików NetworkLink i KML. Aby uruchomić przykład:

1. Załaduj plik Point-load.json do Google Earth. Ten plik zawiera atrybut NetworkLink, który wczytuje pierwotny plik danych zawierający 2 punkty (Point.json).
2. Wczytaj plik Update-load.json do Google Earth. Ten plik zawiera drugi link NetworkLink, który wczytuje plik zawierający dane aktualizacji (nowa nazwa punkt123).

Pierwszy plik zawiera atrybut NetworkLink, który wczytuje plik danych zawierający 2 punkty. Oznaczenia miejsc zawierające te punkty mają przypisane identyfikatory. Trzeci plik zawiera inny element NetworkLink, który dodaje plik Update. Element Change modyfikuje nazwę oznaczenia miejsca point123.

Oto 4 pliki używane w tym przykładzie. Po pierwsze, jest to plik Point-load.json zawierający link sieciowy, który wczytuje oryginalny plik danych (Point.json).

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<NetworkLink>
  <name>Loads Point.kml</name>
  <Link>
    <href>http://developers.google.com/kml/documentation/Point.kml</href>
  </Link>
</NetworkLink>
</kml>

Oto plik Point.json, który zawiera dane oryginalne (2 punkty). Punkt o identyfikatorze „point123” to punkt, który będziemy modyfikować.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <Placemark id="pm123">
    <name>point123</name>
    <Point>
      <coordinates>-95.44,40.42,0</coordinates>
    </Point>
  </Placemark>
  <Placemark id="pm456">
    <name>point456</name>
	  <Point>
      <coordinates>-95.43,40.42,0</coordinates>
    </Point>
  </Placemark>
</Document>
</kml>

Kolejny jest plik NetworkLink (Update-load.json). Ten plik wczytuje plik zawierający informacje o aktualizacji.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<NetworkLink>
  <name>Update</name>
  <Link>
    <href>http://developers.google.com/kml/documentation/NetworkLinkControl-Update.kml</href></Link>
</NetworkLink>
</kml>

Na koniec plik KML (NetworkLinkControl-Update.json) zawierający informacje o aktualizacji:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<NetworkLinkControl>
  <Update>
    <targetHref>http://developers.google.com/kml/documentation/Point.kml</targetHref>
    <Change>
      <Placemark targetId="pm123">
        <name>Name changed by Update Change</name>
        <!-- coordinates remain the same -->
      </Placemark>
    </Change>
  </Update>
</NetworkLinkControl>
</kml>

Wygaśnięcie

Domyślnie dane są wczytywane tylko raz przez linki do Google Earth. Aby zapobiec wyświetlaniu nieaktualnych danych KML, możesz określić dla parametru RefreshMode wartość onExpire dla każdego danych ładowanych przez element <href> (w elemencie Link lub Ikona). Domyślnie nagłówki HTTP tracą ważność. Możesz też określić czas wygaśnięcia w pliku KML NetworkLinkControl. Czas jest wyrażony w formacie XML dateTime (zobacz XML Schema Part 2: Datatypes Second Edition). Jeśli określone są zarówno nagłówki HTTP, jak i czas ważności pliku KML, pierwszeństwo ma czas ważności pliku KML.

Przykład 1. Czas wygaśnięcia serwera HTTP

Ten przykład ma charakter poglądowy. Wyświetla ona GroundOverlay z ikoną, która ustawia RefreshMode na wartość onExpire. Ponieważ nie określono czasu ważności pliku KML, w tym przykładzie użyto czasu wygaśnięcia serwera HTTP.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>refreshMode onExpire</name>
  <Snippet maxLines="10">
    Image automatically reloads according to http
    server expiration.
  </Snippet>
  <GroundOverlay>
    <Icon>
      <href>http://www.someserver.com/image.jpeg</href>
      <refreshMode>onExpire</refreshMode>
    </Icon>
    <LatLonBox>
      <!-- from edit session in earth -->
      <!-- The roof of a building in the Presidio -->
      <north>37.80385180177469</north>
      <east>-122.4558710620651</east>
      <south>37.80337403503347</south>
      <west>-122.4564295653771</west>
    </LatLonBox>
  </GroundOverlay>
</Document>
</kml>

Przykład 2: przykład użycia daty ważności pliku KML

Poniższy przykład pokazuje oznaczenie miejsca w losowo wybranych współrzędnych. Ten przykład zawiera link z trybem RefreshMode o wartości onExpire. W takim przypadku datę i godzinę zakończenia określa się w skrypcie Pythona za pomocą nowego elementu KML <expires>. Czas ważności pliku KML ma pierwszeństwo przed czasem podanym w nagłówkach HTTP.

Oto link do pliku KML NetworkLink zawierający elementy <href> i <RefreshMode>:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <NetworkLink>
    <Link>
      <href>http://dev.someserver.com/cgi-bin/expires.py</href>
      <refreshMode>onExpire</refreshMode>
    </Link>
  </NetworkLink>
</Document>
</kml>

To jest skrypt Pythona, który ustawia czas wygaśnięcia [now + 11 sekund] i odświeża współrzędne oznaczenia miejsca:

#!/usr/bin/python

import random
import time

lat = random.random() * 180. - 90.
lon = random.random() * 360. - 180.

now = time.time()
future = time.gmtime(now + 11)
y = future[0]
mo = future[1]
d = future[2]
h = future[3]
mi = future[4]
s = future[5]
iso8601 = '%04d-%02d-%02dT%02d:%02d:%02dZ' % (y,mo,d,h,mi,s)

print 'Content-type: application/vnd.google-earth.kml+xml'
print

print '<?xml version=\"1.0\" encoding=\"UTF-8\"?>'
print '<kml xmlns=\"http://earth.google.com/kml/2.1\">'

# must be child of <kml>
print '<NetworkLinkControl>'
print '<expires>%s</expires>' % iso8601
print '</NetworkLinkControl>'

print '<Placemark>'
print '<name>placemark expires %s</name>' % iso8601
print '<Point>'
print '<coordinates>%f,%f,0</coordinates>' % (lon,lat)
print '</Point>'
print '</Placemark>'

print '</kml>'

Foldery z elementami w formacie radiowym

Możesz teraz tworzyć foldery z elementami w stylu radiowym za pomocą elementu ListStyle i określając typ elementu listy o wartości radioFolder. Poniższy przykład pokazuje zastosowanie nowego elementu stylu listy.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.1">
<Document>
  <name>ListStyle radiofolder</name>
  <Folder>
    <name>radioFolder Folder</name>
    <Style>
      <ListStyle>
        <listItemType>radioFolder</listItemType>            
      </ListStyle>          
    </Style>
    <Placemark>
      <name>north</name>
      <Point>
        <coordinates>-114,41.79,0</coordinates>
      </Point>
    </Placemark>
    <Placemark>
      <name>south</name>
      <Point>
        <coordinates>-114,41.78,0</coordinates>
      </Point>
    </Placemark>
  </Folder>    
</Document>  
</kml>

Folder i jego elementy podrzędne są w ten sposób wyświetlane w panelu Miejsca: