Como trabalhar com regiões

Regiões são um elemento KML avançado que permite o acréscimo de conjuntos de dados muito grandes ao Google Earth sem sacrificar o desempenho. Os dados são carregados e desenhados somente quando estão dentro da visualização do usuário e ocupam determinada parte da tela. Usando regiões, é possível fornecer níveis separados de detalhes para os dados, de modo que detalhes precisos sejam carregados somente quando os dados preencherem uma parte da tela grande o suficiente para que os detalhes fiquem visíveis.

Principais conceitos

Qualquer elemento pode conter uma região. Uma região afeta a visibilidade da geometria de um marcador ou a imagem de uma superposição. As regiões definem o comportamento de opções e de nível de detalhes da geometria ou superposição afetada. As regiões são herdadas por meio da hierarquia KML e afetam a visibilidade dos elementos definidos mais abaixo na hierarquia.

Esta seção descreve os seguintes conceitos importantes, que são necessários para entender as regiões:

Herança

Em KML, algumas classes são derivadas de uma classe "base". As classes derivadas herdam todos os elementos de sua classe base e adicionam alguns elementos específicos. Essa é uma técnica comum de sistemas orientados a objetos. Para conveniência, esta seção se refere à classe base, em vez de listar todas as classes derivadas. Por exemplo:

  • O termo Feature refere-se a qualquer elemento KML derivado de Feature: Document, Folder, GroundOverlay, NetworkLink, PhotoOverlay, Placemark e ScreenOverlay.
  • Geometry refere-se a qualquer elemento geométrico em KML: Point, Polygon, LinearRing, LineString, Model, MultiGeometry.
  • Overlay refere-se aos elementos derivados de Overlay: GroundOverlay, PhotoOverlay e Screen Overlay.

Consulte a Referência de KML para ver um diagrama que mostra a herança nesses elementos KML.

Caixa delimitadora

Uma região tem um elemento <LatLonAltBox> que define uma caixa delimitadora para seus dados. Caixa delimitadora é um volume que cerca um conjunto de objetos ou pontos de dados. Assim como <LatLonBox> em um GroundOverlay, o elemento <LatLonAltBox> em uma região tem limites Norte, Sul, Leste e Oeste. Se os dados contidos pela região forem 3D, ou 2D em altitude, o elemento <LatLonAltBox> da região também precisará incluir uma altitude mínima, <minAltitude>, e uma altitude máxima, <maxAltitude>.

Objetos associados a essa caixa delimitadora são desenhados quando (1) a região entra na visualização e (2) o tamanho projetado na tela de <LatLonAltBox> se enquadra na faixa de pixel especificada para essa região, conforme descrito em Nível de detalhes (LOD). Quando ambas as condições são atendidas, diz-se que a região está "ativa".

Nível de detalhes (LOD)

O segundo conceito importante relacionado às regiões é o Nível de detalhes ou LOD. Como a tela de um computador tem uma quantidade limitada de espaço, é mais eficiente configurar as coisas de modo que grandes quantidades de dados sejam carregadas somente quando houver pixels suficientes para exibir os dados de forma adequada. Quando a região está ocupando uma parte relativamente pequena da tela (talvez porque o usuário a esteja visualizando de uma grande distância ou porque seja uma área plana sendo visualizada de forma oblíqua), o mecanismo LOD permite que você (o autor do KML) especifique um conjunto de dados com resolução inferior para ser substituído pelos dados de resolução completa. Esse conjunto de dados de resolução inferior é carregado de forma mais rápida e, como ocupa uma pequena parte da tela, o usuário não pode sentir a diferença.

Em uma região, os elementos <minLodPixels> e <maxLodPixels> permitem especificar uma área da tela (em pixels quadrados). Quando seus dados são projetados na tela, eles precisam ocupar uma área da tela superior a <minLodPixels> e inferior a <maxLodPixels> para ficarem visíveis. Quando o tamanho projetado da região sai desses limites, eles não ficam mais visíveis, e a região torna-se inativa.

Em uma situação especial em que você queira que os dados fiquem ativos com um tamanho infinito, especifique -1 (o padrão) para <maxLodPixels>.

Exemplo 1: região para uma superposição de solo

Primeiro, vamos analisar um exemplo simples que constrói uma região para uma superposição 2D no nível do solo. Este exemplo usa uma superposição de solo contendo dados históricos que mostram uma parte de Mountain View, Califórnia, em 1991. À medida que o usuário aumenta o zoom na área, a superposição se torna visível. Veja a aparência da superposição quando ela se torna visível pela primeira vez (o arquivo de exemplo também inclui um LineString branco para destacar melhor a superposição):

Neste exemplo, <minLodPixels> é 128, o que significa que GroundOverlay entra na visualização quando ocupa 128 pixels quadrados na tela. O exemplo usa o valor padrão de -1 para <maxLodPixels>, o que significa que permanecerá visível à medida que o usuário ampliar o zoom nesse ângulo. A imagem usada para essa superposição é de 256 pixels quadrados.

Veja a aparência da imagem à medida que o usuário amplia o zoom:

E veja qual é a aparência da imagem inclinada antes de ficar invisível, pois consome menos espaço na tela que o valor de <minLodPixels>:

<LatLonAltBox> para esses dados não precisa incluir os elementos <minAltitude> e <maxAltitude>, pois os dados são simples e estão no nível do solo. A caixa delimitadora para os dados no elemento <LatLonAltBox> da região é idêntica aos limites de <LatLonBox> da superposição de solo, como mostra o arquivo KML abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Além disso, no arquivo KML, observe que a região é irmã da imagem (ou geometria) cuja visibilidade é afetada.

Agora que você teve tempo para examinar o arquivo KML, clique no link a seguir para carregar a superposição no Google Earth. Em seguida, experimente pontos de vista diferentes e observe quando a região entra e sai da visualização, dependendo da área da tela que ela exige. Se você inclinar suficientemente a visualização ou se afastar o zoom um pouco, a superposição desaparecerá, pois ocupa pouco espaço na tela para atender aos requisitos de <minLodPixels>.

Veja o exemplo no Google Earth (historicOverlay.kmz)

Altitude

Exemplo 2: região para um modelo 3D

O exemplo a seguir mostra como construir uma região que contém objetos 3D no nível do solo. O <LatLonAltBox> para essa região contém um elemento <maxAltitude> de 300 metros, que é a altura do edifício. Você provavelmente reconhece esses edifícios como o complexo das Nações Unidas na cidade de Nova York.

É importante perceber que os limites de <LatLonAltBox> da região não correspondem necessariamente aos limites de longitude e latitude do modelo. As coordenadas do modelo são relativas a seu local de origem, que pode estar distante da posição real do modelo na Terra.

<?xml version='1.0' encoding='UTF-8'?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Clique no link a seguir para carregar o arquivo no Google Earth. Novamente, experimente com pontos de vista diferentes para ver quando os edifícios se tornam visíveis e quando são removidos da visualização.

Veja o exemplo no Google Earth (unitedNations.kmz)

Exemplo 3: região para uma superposição 2D em altitude

Este exemplo mostra como você adicionaria uma superposição 2D para ser exibida acima da superfície da Terra em uma altitude especificada. Essa técnica é útil para os dados que mostram frentes meteorológicas e padrões de tráfego aéreo. Aqui, o exemplo mostra uma pequena nuvem a uma altitude de 100.000 metros acima do nível do mar.

O elemento <LatLonAltBox> da região especifica um valor de 100.000 metros para os elementos <minAltitude> e <maxAltitude>. O valor é o mesmo para ambos os elementos, uma vez que a superposição é 2D e não tem espessura. <altitudeMode> é absoluta, o que significa que esse valor é relativo ao nível do mar.

Observe que o valor de <altitude> do GroundOverlay também é 100.000 (ou seja, corresponde ao valor de altitude da caixa delimitadora da região), e o <altitudeMode> de GroundOverlay corresponde ao valor especificado para o <altitudeMode> da região.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Veja o exemplo no Google Earth (cloudRegion.kmz)

Extensão de esmaecimento

Também é possível especificar uma extensão de esmaecimento para a região, o que permite a transição de um objeto de transparente para opaco e vice-versa. O Google Earth usa maxFadeExtent para determinar o intervalo de totalmente transparente para totalmente opaco quando a região está em seu tamanho máximo visível e usa minFadeExtent para determinar o intervalo de esmaecimento quando a região está em seu tamanho mínimo visível. As variações de esmaecimento são opcionais, mas impedem o efeito "abertura" entre LineStrings ou polígonos de resoluções diferentes. O esmaecimento prejudica muito o desempenho e não deve ser usado com imagens.

Observação: o intervalo de esmaecimento se aplica a todos os objetos, exceto ícones de marcadores. Esses ícones são desenhados quando o intervalo de esmaecimento é superior a 0,5.

O exemplo a seguir ilustra como a extensão de esmaecimento afeta LineString.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Veja o exemplo no Google Earth (fadeLineString.kml)

Como aninhar regiões

Um uso comum das regiões é aninhá-las com as regiões maiores associadas à resolução mais aproximada e com as regiões menores, em regiões associadas a níveis cada vez mais precisos de detalhes. Na figura a seguir, cada região tem um conjunto de limites de LOD que especifica o tamanho de tela projetada da região em pixels necessário para a região associada ficar ativa. À medida que o ponto de vista do usuário se aproxima, as regiões com níveis de detalhes (LOD) mais precisos ficam ativas, pois a região ocupa mais espaço na tela. As regiões com LOD mais precisos substituem as regiões carregadas anteriormente por LODs mais aproximados.

À medida que regiões aninhadas sucessivas se tornam ativas, elas podem

  • Acumular dados associados a cada região (como no exemplo de Super-sobreposição descrito abaixo)
  • Substituir os dados da região carregada anteriormente por dados novos (conforme ilustrado na figura anterior)

Um elemento <LatLonAltBox> em uma região filha deve estar totalmente no <LatLonAltBox> de sua região pai. As regiões são herdadas por meio da hierarquia de pastas e NetworkLinks. Regiões definidas localmente têm precedência sobre regiões definidas em locais superiores na hierarquia de pastas. O exemplo a seguir ilustra como o escopo local de uma região substitui uma região definida em um local superior na hierarquia. Neste exemplo, o marcador "ukraineRegion" herda a região de seu documento pai. A pasta "romaniaFolder" especifica sua própria região, que é usada pelo marcador "romaniaRegion". Consulte a próxima seção sobre Carregamento "inteligente" de links de rede baseados em região para ver mais exemplos de como usar as regiões em links de rede para obter a eficiência máxima.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Carregamento "inteligente" de links de rede baseados em região

O link de rede baseado em região mostrado no exemplo anterior é a forma mais eficiente de publicar um conjunto de dados muito grande no Google Earth. Usando as regiões em conjunto com NetworkLinks, é possível criar uma hierarquia de ponteiros, cada uma apontando para uma sub-região específica. <viewRefreshMode>, como mostra o arquivo KML a seguir, tem uma opção onRegion, que especifica o carregamento dos dados da região somente quando a região está ativa. Se você fornecer regiões aninhadas com vários níveis de detalhe, quantidades maiores de dados serão carregadas somente quando o ponto de vista do usuário disparar o próximo carregamento. A seção a seguir sobre Super-sobreposições fornece um exemplo detalhado.

Parte 1: arquivo pai

Para executar esse exemplo, salve a primeira parte como de costume. Salve a segunda parte como romaniaRegion.kml, de modo que o NetworkLink possa carregar a região quando ela se tornar ativa.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Parte 2: arquivo de links de rede baseados em região

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Super-sobreposições

P: Como posso compartilhar uma imagem de 47 MB com o mundo?
R: Uma parte por vez.

P: O que acontece se todos tentarem fazer isso?
R: Se você usar links de rede baseados em regiões e fornecer vários níveis de detalhes para suas imagens, conforme descrito neste tutorial, não há problemas!

Esta seção descreve como criar uma "super-sobreposição", uma hierarquia de regiões e links de rede que pode ser usada ​​para atender de forma eficiente um conjunto grande de imagens. Blocos de resolução apropriada são carregados à medida que partes da área de imagens entram na visualização, com blocos de resolução superior carregados à medida que o ponto de visualização fica mais próximo. É um desperdício de esforço tentar exibir uma imagem de 7008 por 6720 pixels em uma tela de 1024 por 768. Além disso, se o usuário estiver quilômetros acima da superfície da Terra, todos esses dados poderão ser confinados em alguns poucos pixels, e o desempenho será prejudicado. Super-sobreposições, como nosso exemplo que mostra um DOQQ de Mountain View, Califórnia, em 1991, permitem que você aproveite os NetworkLinks e sua capacidade de determinar (1) se uma região específica está dentro da visualização e (2) se seu tamanho projetado é apropriado ao ponto de vista atual. Se a região estiver "ativa" (ambas as condições forem atendidas), o link de rede carregará os dados associados à região. Se a região estiver inativa, nenhum dado será carregado. Se você subdividir a imagem original em uma hierarquia de imagens com níveis cada vez maiores de detalhes, o Google Earth poderá carregar a imagem que melhor atenda à visualização atual.

Para ver como essa hierarquia de imagens é usada, carregue esse arquivo de amostra no Google Earth e tente ampliar e reduzir o zoom na área de interesse: Mountain View Historial DOQQ .

Exemplo do uso de links de rede baseados em região para carregar um conjunto de dados muito grande de forma eficiente. A imagem original é de 7008 por 6720 pixels. A visualização oblíqua mostrada aqui carrega apenas cinco blocos pequenos para representar essa imagem. Linestrings brancas foram adicionadas para destacar os limites dos blocos. Esse aplicativo mostra a apresentação de imagens históricas da cidade de Mountain View (um DOQQ de 1991).

Como preparar seus dados para uma super-sobreposição

Na amostra de super-sobreposição, a imagem original de Mountain View é subdividida em centenas de pequenos elementos GroundOverlays. Essas superposições, ou blocos, são organizadas em uma hierarquia de cinco níveis. Para fins de exemplo, a discussão aqui usa uma hierarquia simples de três níveis e um conjunto de 21 superposições, mas os princípios envolvidos são os mesmos. Essa é apenas uma abordagem para a criação de uma hierarquia de links de rede baseados em região. Há outras maneiras de implementar esse mecanismo.

Para criar uma super-sobreposição, é necessário

  1. Preparar as imagens, subdividindo-as em pedaços gerenciáveis ​​(o recomendado é 256 por 256 pixels) e
  2. Criar os arquivos KML que configuram regiões, links, links de rede, e, nesse caso, arquivos contendo os GroundOverlays.

Preparar as imagens

Escolha um tamanho padrão para seus blocos, que são as imagens subdivididas (de resoluções variadas) carregadas pelo Google Earth à medida que suas regiões associadas se tornam ativas. Para fins de exemplo, usaremos 256 por 256 pixels para nossos blocos, que é um tamanho pequeno o suficiente para ser gerenciável.

  1. Comece com a imagem original, de resolução completa. Subdivida-a em n blocos e, em seguida, subdivida cada um desses blocos em n blocos.
    Continue subdividindo até que você tenha blocos de um determinado tamanho (no nosso exemplo, 256 por 256 pixels).

    Vamos supor que nossa imagem original seja de 1024 por 1024 pixels.
    A hierarquia a seguir resultaria após a subdivisão.

     

  2. Reconfigure cada bloco na hierarquia para o tamanho padrão escolhido (por exemplo, 256 por 256 pixels).
    Esses blocos reconfigurados terão menos detalhes, mas estarão associados a regiões ativas em pontos de visualização
    mais distantes; portanto, a perda em detalhes não será percebida pelo usuário.

O diagrama abaixo mostra como o ponto de visão e a definição das regiões aninhadas determinam quais blocos serão realmente carregados. Três níveis de detalhes são fornecidos para essa amostra de imagem grande. Quando o usuário observa a região de uma distância maior, o Google Earth exibe a visualização em miniatura. Essa visualização é esticada em todo o elemento LatLonAltBox. Porém, como o tamanho projetado é pequeno (256 pixels quadrados), não há perda real de informações visuais. À medida que o usuário amplia o zoom na cena, a região é dividida em quatro regiões. Cada um desses quatro "blocos" tem o mesmo tamanho que a imagem em miniatura, mas fornece imagens mais detalhadas.

Se o usuário continuar a aumentar o zoom na área, partes da imagem com resolução completa entrarão na visualização, dependendo da proximidade do usuário com relação a elas. Áreas distantes mantêm menos imagens detalhadas que no primeiro carregamento. No exemplo Mountain View DOQQ, ative "Caixas" e verifique os Marcadores A  e B, que usam LineStrings em torno das regiões e mostram diversos níveis de hierarquia por vez.

Observe que o exemplo usa os mesmos valores para minLodPixels e maxLodPixels para todas as regiões (em todos os níveis da hierarquia). É LatLonAltBox que determina qual nível de hierarquia deve ser carregado e quais blocos dentro da região.

Preparar os arquivos KML

Para cada imagem, prepare um arquivo KML que associe a superposição de solo a uma região e a um NetworkLink. Cada arquivo KML nesse conjunto tem os seguintes elementos:

  • uma região, com os elementos LatLonAltBox, minLodPixels e maxLodPixels para que o Google Earth possa determinar se a região está ativa em algum momento determinado
  • um conjunto de NetworkLinks para os arquivos filho (os blocos no próximo nível da hierarquia)
  • a superposição de solo para essa região

Esta amostra mostra o arquivo KML de nível superior para o exemplo Mountain View DOQQ. Para maxLodPixels, ela especifica -1, que tem o significado especial "ativar o tamanho infinito". Sem essa especificação, toda a hierarquia talvez nunca seja disparada.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

O arquivo a seguir mostra uma região no exemplo de Mountain View DOQQ (179.kml). Esse arquivo contém cinco tags href: quatro se referem aos quatro arquivos KML no próximo nível de hierarquia de imagem, e um se refere ao arquivo de imagem utilizado para a GroundOverlay para esse bloco.

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<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>

Enviar comentários sobre…

Keyhole Markup Language