En aquel Imperio, el Arte de la Cartografía logró tal Perfección que el Mapa de una sola Provincia ocupaba toda una Ciudad, y el Mapa del Imperio, toda una Provincia. Con el tiempo, estos Mapas Desmesurados no satisficieron y los Colegios de Cartógrafos levantaron un Mapa del Imperio, que tenía el Tamaño del Imperio y coincidía puntualmente con él. Menos Adictas al Estudio de la Cartografía, las Generaciones Siguientes entendieron que ese dilatado Mapa era Inútil y no sin Impiedad lo entregaron a las Inclemencias del Sol y los Inviernos. En los Desiertos del Oeste perduran despedazadas Ruinas del Mapa, habitadas por Animales y por Mendigos; en todo el País no hay otra reliquia de las Disciplinas Geográficas.
[Del rigor en la ciencia, Jorge Luis Borges]

2011-09-29

Sistemas de referência na norma WMS 1.3.0

O excerto que se segue foi traduzido da versão 1.3.0 da OpenGIS® Web Map Server Implementation Specification.
Só diz respeito à utilização de sistemas de referência e não dispensa a consulta do documento original... As omissões estão assinaladas com [...] e no fim do texto está um excerto do glossário utilizado. 

O objetivo era perceber exatamente que tipo de identificadores de CRS são válidos num serviço WMS. Isto porque na prática se encontram situações em que o namespace EPSG é usado de forma abusiva, i.e. para que o XML esteja formalmente correto só que depois o código do sistema de referência não consta da base de dados EPSG. Um exemplo para Portugal "ESPG:102164".

O segundo objetivo ainda não ficou claro e era perceber se a norma ISO19111 prevê uma representação dos CRS em WKT.

De caminho, ficaram clarificada algumas das minhas dúvidas sobre as ordens de eixos, a utilização da Pseudo Plate Carrée (e utilização de dimensões temporais e amostrais).

[...]
6.7 Sistemas de coordenadas
6.7.1 Introdução

Esta Norma usa duas classes de sistemas de coordenadas: o sistema de coordenadas do mapa [Map CS] aplicável à representação cartográfica gerada pelo WMS; e o sistema de referência por coordenadas da camada [Layer CRS] para uma caixa envolvente [Bounding Box] aplicada aos dados geográficos representados no mapa.
Durante uma operação de representação cartográfica, um WMS converte ou transforma informação geográfica do Layer CRS para o Map CS. Além disso, uma camada pode ter associado um sistema de coordenadas vertical, temporal ou outros.

6.7.2 Sistema de Coordenadas do Mapa [Map CS]
O sistema de coordenadas do mapa [Map CS] é o sistema de referência por coordenadas para o mapa produzido por um WMS. Um mapa WMS é uma malha retangular de pixeis visualizada no ecrã do computador (ou um ficheiro digital que poderia ser visualizado).
O Map CS tem um eixo horizontal denotado i, e um eixo vertical denotado j. Os eixos i e j devem ter valores inteiros não negativos. A origem (i,j) = (0,0) é o pixel no canto superior esquerdo do mapa; i aumenta para a direita e j aumenta para baixo.
O anexo B.2 define o Map CS utilizando a terminologia ISO 19111. O Map CS é identificado pela etiqueta "CRS:1".

A orientação usual do Map CS será tal que o eixo i é paralelo ao eixo leste-oeste do Layer CRS e aumenta para leste, e o eixo j é paralelo ao eixo norte-sul do Layer CRS e aumenta para sul. Esta orientação não será possível em alguns casos: por exemplo, numa projeção ortográfica sobre o Polo Sul. A convenção a ser seguida é que, sempre que possível, leste será para a direita e norte será para o topo do Map CS.

Os parâmetros WIDTH e HEIGHT utilizados no pedido GetMap (ver 7.3.3.8) e, por inclusão, no pedido GetFeatureInfo (ver 7.4.3.3) correspondem a i e j da seguinte forma:
  • WIDTH denota o tamanho da imagem do mapa em pixeis ao longo do eixo i (isto é, WIDTH-1 é o valor máximo de i).
  • HEIGHT denota o tamanho da imagem do mapa em pixeis ao longo do eixo j (isto é, HEIGHT-1 é o valor máximo de j).
Os parâmetros I e J utilizados no pedido GetFeatureInfo (ver 7.4.3.7) denotam valores inteiros ao longo dos eixos i e j, respetivamente, do Map CS.

6.7.3 Sistema de Referência por Coordenadas da Camada (Layer CRS)
6.7.3.1 Introdução

O sistema de referência por coordenadas da camada de dados (Layer CRS) é um sistema de referência por coordenadas horizontal para a informação geográfica que serve como fonte para a produção do mapa. Como discutido abaixo, são possíveis muitos Layer CRS.

O Layer CRS aparece nas seguintes entidades relevantes para o WMS:
  • o elemento <BoundingBox> nos metadados do serviço (ver 7.2.4.6.8);
  • o parâmetro CRS no pedido GetMap (ver 7.3.3.5);
  • o parâmetro CRS incluído no pedido de mapa do pedido GetFeatureInfo (ver 7.4.3.3).

Um WMS deve suportar pelo menos um CRS, e os mapas gerados por diferentes servidores só podem ser sobrepostos se todos os servidores selecionados têm pelo menos um CRS em comum.

Esta Norma não obriga a que seja suportado qualquer Layer CRS. Em vez disso, apenas define a forma como os CRS são identificados e discute vários Layer CRS opcionais, nesta cláusula e no anexo B. Os fornecedores de serviços de mapas podem utilizar os CRS mais úteis e apropriados para sua área geográfica ou comunidade de informação.

Para maximizar a interoperabilidade entre servidores, os fornecedores de serviços de mapas devem também suportar a utilização de coordenadas geográficas em sistemas de coordenadas geocêntricos como "CRS:84" (ver 6.7.3.2), "EPSG:4326" (ver 6.7.3.3) ou outros sistemas baseados em ITRF.

Cada Layer CRS tem um identificador que é uma cadeia de caracteres. São permitidos dois tipos de identificadores de Layer CRS - etiqueta e URL:
  • etiqueta: O identificador inclui um prefixo que identifica um namespace, dois pontos, um código numérico ou alfanumérico, e em alguns casos, uma vírgula seguida por parâmetros adicionais. Esta Norma define três namespaces: CRS, e EPSG e AUTO2, como discutido abaixo.
  • URL: O identificador é um URL totalmente qualificado que referencia um ficheiro acessível ao público, contendo uma definição do CRS conforme com a norma ISO 19111.

O Layer CRS tem dois eixos, denotados x e y. O eixo x é o primeiro eixo na definição do CRS, o eixo y é o segundo eixo. Dependendo do CRS particular, o eixo x pode ou não ter orientação oeste-leste, e o eixo y pode ou não ter orientação sul-norte. Quando é feita a projeção da informação geográfica do Layer CRS para o Map CS, a operação de representação cartográfica WMS deve ter em conta a origem, ordem e orientação dos eixos no Layer CRS.

As coordenadas devem ser listados na ordem definida pelo CRS, e deve ser mapeadas de forma adequada para os eixos i e j do Map CS, se necessário, trocando a ordem dos eixos durante a operação de projeção. Muitos sistemas de referência por coordenadas projetados têm uma ordem de eixos diferente de (Easting, Northing), i.e., (M, P) em que M é a distância à meridiana e P é a distância à perpendicular. Por exemplo, o sistema EPSG:2393 usado na Finlândia segue a ordem (P,M). Os CRS geográficos EPSG seguem a norma ISO 6709 e listam sempre a latitude antes da longitude.

A maioria dos sistemas de referência por coordenadas são orientados com um eixo positivo para leste positivo (easting ou M) e o outro eixo positivo para norte (northing ou P). Estes eixos podem ser convenientemente mapeados para os eixos i e j da caixa envolvente. No entanto, alguns CRS têm coordenadas crescentes noutras direções. Por exemplo, o sistema EPSG:2051 utilizado na África do Sul tem eixos crescentes para oeste e sul. Os testes de validação dos pedidos quando as áreas indicadas na caixa envolvente devem reconhecer e lidar com a orientação positiva dos eixos do CRS.
Num CRS geográfico, a latitude terá valores dentro do intervalo [-90, 90] e a longitude terá valores no intervalo [-180, 180] graus (ou equivalente, se a definição do CRS estiver numa unidade diferente). Ver o ponto 7.3.5 para o caso particular em que se pretende projetar um Layer CRS geográfico para o Map CS. Quando o código CRS especifica um sistema de referência geográfico 2D com eixos numa unidade diferente de graus (ou em graus não decimais), a representação deve ser convertida para graus decimais.

NOTA:
O uso de CRS geográficos em que a ordem dos eixos apresenta a longitude antes da latitude difere da convenção histórica. Os utilizadores no setor marítimo e aeronáutico podem esperar representações na forma latitude, longitude: uma representação diferente pode ter implicações de segurança, sobretudo em situações de emergência. Embora esta Norma não especifique interfaces com utilizadores humanos, os programadores de interfaces para utilizadores humanos são advertidos de que todas as referências a valores de latitude e longitude (e.g. em caixas de entrada de dados e na leitura da posição do cursor) devem mostrar os valores de latitude antes dos valores de longitude.

6.7.3.2 CRS namespace
O namespace identificado pelo prefixo "CRS" refere-se aos sistemas de referência por coordenadas definidos no Anexo B desta Norma. Essas definições do Anexo B estão na forma especificada pela norma ISO 19111. O anexo B define, no namespace "CRS", sistemas de referência geográficos para os data WGS 84, NAD27 e NAD83.
A etiqueta "CRS" inclui o prefixo "CRS", os dois pontos, e um código numérico ou alfanumérico.
EXEMPLO
"CRS:84" refere-se a valores de longitude e latitude em WGS84, expressos em graus decimais, com longitude no intervalo de -180 a +180 graus e latitude no intervalo de -90 graus a 90 graus.

6.7.3.3 EPSG namespace
O prefixo de namespace "EPSG" refere-se ao registry do European Petroleum Survey Group (EPSG), que define identificadores numéricos para muitos sistemas de referência por coordenadas. Para cada identificador de CRS existem definições associadas relativas ao datum geodésico, projeção cartográfica e dados do sistema de referência.
A etiqueta "EPSG" inclui o prefixo "EPSG", os dois pontos, e um código numérico.
EXEMPLO
"EPSG:4326" refere-se a coordenadas geodésicas WGS84: primeiro a latitude, depois a longitude. Ou seja, neste CRS o eixo x corresponde à latitude, e o eixo y corresponde à longitude.
[...]
6.7.3.5 Informação geográfica com um CRS indefinido
Um servidor pode fornecer informação geográfica bidimensional cujo sistema de referência é indefinido. Por exemplo, um mapa histórico desenhado à mão pode representar uma área da Terra, mas não utilizar um CRS moderno, ou uma fotografia aérea pode não estar exatamente precisamente geo-referenciadas. Esta informação gráfica deve ser tratada como uma imagem, e a etiqueta "CRS:1" (utilizada para o Map CS) deve ser usada quando se declarar o Layer CRS deste tipo de objetos. Os clientes não devem tentar sobrepor uma camada para a qual CRS=CRS:1 com outra camada.

6.7.4 Caixas envolventes
Os valores da caixa envolvente (Bounding Box) especificam a porção da Terra a ser mapeada, designadamente através de dois pares de coordenadas no Layer CRS especificado. O primeiro par especifica os valores mínimos das coordenadas, o segundo especifica os valores máximos das coordenadas, sempre no Layer CRS identificado.
Para a maioria dos CRS com eixos crescentes para leste e para norte, estes valores serão o canto inferior esquerdo e o canto superior direito da área de interesse; contudo, em alguns CRS, os valores mínimos e máximos podem corresponder a outros pontos. Por exemplo, quando se utilizam coordenadas geográficas para descrever uma área situada sobre o Polo, ou quando o Layer CRS tem eixos com orientação crescente diferente de leste e norte. A ordem pela qual são listadas as ordenadas de cada par é a definidos pelo Layer CRS; x corresponde ao primeiro eixo do Layer CRS e y ao segundo eixo. Esta ordem não pode coincidir com a dos eixos i,j no Map CS. Os valores das coordenadas da caixa envolvente são expressos nas unidades definidas para o CRS Layer.

As seguintes entidades relevantes para o WMS utilizam valores de caixa envolvente:
  • o elemento <BoundingBox> nos metadados do serviço (ver 7.2.4.6.8);
  • o parâmetro BBOX no pedido GetMap (ver 7.3.3.6);
  • o parâmetro BBOX incluído no pedido de mapa do pedido GetFeatureInfo (ver 7.4.3.3).
Uma caixa envolvente não deve ter área zero.

EXEMPLO 1
Um elemento de metadados <BoundingBox> para uma camada de dados que represente a toda a Terra no Layer CRS CRS:84 é escrito como
<BoundingBox CRS="CRS:84" minx="-180" miny="-90" maxx="180" maxy="90">.
Neste CRS, um parâmetro BBOX solicitando um mapa de toda a Terra é escrito como
BBOX =- 180, -90,180,90.

EXEMPLO 2
Uma <BoundingBox> representando a toda a Terra no Layer CRS EPSG:4326 é escrita como
<BoundingBox CRS="EPSG:4326" minx="-90" miny="-180" maxx="90" maxy="180">.
Neste CRS, um parâmetro BBOX solicitando um mapa de toda a Terra é escrito como:
BBOX =- 90, -180,90,180.

6.7.5 Sistema de referência por coordenadas vertical (Vertical CRS)


Alguns dados geográficos podem estar disponíveis a altitudes múltiplas (por exemplo, concentrações de ozono a diferentes altitudes na atmosfera). Um WMS pode anunciar as altitudes disponíveis nos seus metadados de serviço, e a operação GetMap inclui um parâmetro opcional para solicitar uma dada altitude. Um valor de altitude ou profundidade é um número cujas unidades (bem como a direção de incremento) são declaradas através de um CRS unidimensional. Dependendo do contexto, valores de elevação pode aparecer como um único valor, uma lista de valores ou um intervalo de valores, conforme especificado no anexo C.

Um servidor pode declarar, no máximo, um CRS vertical para cada camada de dados. Para os fins desta Norma, os CRS horizontal e vertical são tratados como elementos de metadados independentes e como parâmetros do pedido independentes.

O pedido de um mapa a uma altitude específica inclui um valor de altitude, mas não inclui o identificador CRS vertical (o identificador do CRS horizontal está incluído junto com a caixa envolvente horizontal nos parâmetros do pedido).
Quando fornecer informação altitudinal, um servidor deve declarar um valor de altitude por omissão nos metadados do serviço, e um servidor deve responder com o valor por omissão, caso este tenha sido declarado e o pedido enviado pelo cliente não inclua um valor de altitude.

Dois tipos de identificadores de CRS Vertical são permitidos - identificadores "etiqueta" e "URL":
  • Etiqueta: O identificador inclui um prefixo que identifica um namespace, dois pontos, e um código numérico ou alfanumérico. O Anexo B.6 define um CRS vertical opcional chamado "CRS:88" com base no Datum Vertical norte-americano de 1988. Se o prefixo de namespace é "EPSG", então o CRS vertical é uma dos definidos na base de dados do European Petroleum Survey Group.
  • URL: O identificador é um URL totalmente qualificado que referencia um ficheiro acessível ao público, contendo uma definição do CRS conforme com a norma ISO 19111.

Se a altitude for a componente vertical de um CRS tridimensional, o identificador do CRS Vertical será o do CRS tridimensional.


6.7.6 Sistema de coordenadas temporal (Temporal CS)
Alguns dados geográficos podem estar disponíveis para vários períodos de tempo (por exemplo, um mapa meteorológico horário). Um WMS pode anunciar os períodos de tempo disponíveis nos seus metadados de serviço, e a operação GetMap inclui um parâmetro opcional para solicitar um período de tempo particular. O formato da cadeia de caracteres a utilizar para especificar um período de tempo é especificado no anexo D.
Dependendo do contexto, os valores de tempo pode aparecer como um único valor, uma lista de valores ou um intervalo, conforme especificado no anexo C. Quando fornecer informação temporal, um servidor deve declarar um valor por omissão nos metadados do serviço, e um servidor deve responder com o valor por omissão, caso este tenha sido declarado e o pedido do cliente não inclua um valor.


6.7.7 Outros sistemas de coordenadas
Alguns dados geográficos podem estar disponíveis noutras dimensões (por exemplo, imagens de satélite em diferentes bandas de comprimento de onda). Outras dimensões para além das quatro dimensões do espaço-tempo são chamadas de "dimensões amostrais". Um WMS pode anunciar as dimensões amostrais disponíveis nos seus metadados de serviço, e a operação GetMap inclui um mecanismo para solicitar valores dimensionais. Cada dimensão amostral tem um nome e um ou mais valores válidos. A declaração e o uso de dimensões amostrais são especificados no Anexo C.3.3.

7 Operações Web Map Service[...]
7.2 GetCapabilities (obrigatório)[...]
7.2.4 Resposta ao pedido GetCapabilities[...]
7.2.4.6 Propriedades de Layer[...]
7.2.4.6.7 CRS
Cada camada está disponível em um ou mais Layer CRS. O ponto 6.7.3 discute o Layer CRS. A fim de indicar que Layer CRS estão disponíveis, cada elemento <layer> deve ter pelo menos um elemento <CRS> declarado explicitamente ou herdado de uma <layer> hierarquicamente superior. O elemento <layer> situado na raiz deve incluir uma sequência de zero ou mais elementos <CRS> listando todos os CRS que são comuns aos <layer> hierarquicamente inferiores. Uma camada-filha pode opcionalmente adicionar um ou mais CRS à lista herdada de uma camada-mãe. Qualquer duplicação deve ser ignorada pelos clientes.
Quando uma camada está disponível em vários CRS, a lista de valores de CRS disponíveis deve ser representado como uma sequência de elementos <CRS>, cada um dos quais contém apenas um único CRS.

EXEMPLO
<CRS>CRS:84</CRS><CRS>EPSG:26718</CRS>.

7.2.4.6.8 BoundingBox
Os metadados do serviço WMS devem declarar uma ou mais caixas envolventes (conforme definido em 6.7.4) para cada camada.
Um elemento de metadados referente a uma caixa envolvente pode ser declarado explicitamente ou pode ser herdado de uma camada superior. Em XML, o elemento de metadados <BoundingBox> inclui os seguintes atributos:
  • CRS indica o Layer CRS a que se aplica uma dada caixa envolvente.
  • minx, miny, maxx, maxy indica os limites da caixa envolvente, nas unidades e a segundo a ordem de eixos do CRS especificado.
  • resx e resy (opcional) indicam a resolução espacial dos dados que compõem a camada, nas unidades e segundo a ordem de eixos do CRS especificado.
O elemento de metadados <BoundingBox> tem a seguinte relação com o parâmetro BBOX definido no ponto 7.3.3.6. O elemento de metadados <BoundingBox> especifica o intervalo válido de coordenadas para a camada como um todo. O parâmetro BBOX, por outro lado, especifica qual a área deve ser representada no mapa. A área BBOX pode ou não sobrepor-se, conter, ou ser contida dentro da área BoundingBox.

Uma camada pode ter vários elementos <BoundingBox>, mas cada um deles deve indicar um CRS diferente. Uma camada herda todos os valores <BoundingBox> definido pelas camadas hierarquicamente superiores. A <BoundingBox> herdada de uma camada superior é substituída por qualquer declaração para o mesmo CRS na camada hierarquicamente inferior. Uma <BoundingBox> na camada inferior para um novo CRS que não tenha sido declarada numa camada superior é adicionada à lista de caixas envolventes da camada inferior. Uma dada camada não deve conter mais de uma <BoundingBox> para cada CRS suportado.

NOTA:
A Norma não inclui qualquer provisão para caixas envolventes espacialmente disjuntas. Considere-se, por exemplo, um conjunto de dados que abranja duas áreas geográficas separadas por alguma distância. O servidor não pode fornecer duas caixas envolventes diferentes na mesma camada usando o mesmo CRS para descrever separadamente as áreas. Para lidar com este tipo de situação, o servidor pode: definir uma única caixa envolvente que inclua ambas as áreas; ou definir duas camadas separadas em que cada uma tem um nome distinto e também uma caixa envolvente distinta.
Uma camada não deve fornecer uma <BoundingBox> para um CRS que não suporte. Por outro lado, uma camada pode suportar um CRS para o qual não forneça uma <BoundingBox>: um servidor que tenha a capacidade de transformar dados geográficos para diferentes CRS pode optar por não fornecer uma <BoundingBox> explícita para cada um dos CRS disponíveis para cada camada. O servidor deve, contudo, pelo menos fornecer uma <BoundingBox>, no CRS nativo da camada de dados (isto é, no CRS em que a camada é armazenada na base de dados do servidor).
O elemento <EX_GeographicBoundingBox> (ver 7.2.4.6.6) é conceptualmente semelhante a uma <BoundingBox> em que o atributo CRS="CRS:84" está implícito. No entanto, o elemento <EX_GeographicBoundingBox> não deve ser utilizado como um substituto para <BoundingBox CRS="CRS:84">. Se o servidor pretende fornecer informação relativa à caixa envolvente no CRS:84, então deve ser incluído nos metadados do serviço um elemento <BoundingBox> separado designando explicitamente o CRS:84.
Se o Layer CRS é "CRS:1" (ou seja, o Map CS, ver B.2), então as unidades da caixa envolvente são dadas em pixeis, a origem é no canto superior esquerdo, o primeiro eixo (x) cresce para a direita, e o segundo eixo (y) cresce para baixo.
[...]
7.2.4.8 Herança de propriedades da camada
A Tabela 7 resume o modo como as propriedades de um elemento <layer> são herdadas pelos elementos <layer> hierarquicamente inferiores. Uma propriedade: pode não ser herdada; pode ser herdada tal como definida no elemento-pai; pode ser substituída, se o elemento-filho a redefine; pode ser herdada e adicionada se o elemento-filho também a define.
Na Tabela 7, a coluna "Número" indica o número de vezes que cada elemento pode aparecer numa camada, seja explicitamente seja através de herança. Assim, é mais restritiva do que as restrições impostas pelo esquema em E.1. O significado dos valores nesta coluna é o seguinte:
  • 1: aparece exatamente uma vez em cada camada.
  • 0 / 1: aparece uma vez ou não aparece.
  • 0+ : aparece zero ou mais vezes.
  • 1+ : aparece uma ou mais vezes.
A coluna "Herança" indica se e como o elemento é herdado por camadas-filhas. O significado dos valores nesta coluna é o seguinte:
  • Não: Não herdada. Se o elemento é definido como sendo obrigatória por esta Norma, então cada elemento <layer> deve incluir esse elemento.
  • Substituir: O valor pode ser herdado do elemento <layer> hierarquicamente superior e omitido pelo elemento <layer> hierarquicamente inferior, mas se for especificado pelo elemento-filho, então o valor herdado do elemento-pai é ignorado.
  • Adicionar: O valor pode ser herdado do elemento <layer> hierarquicamente superior e omitido pelo elemento <layer> hierarquicamente inferior. "Adicionar" só é relevante para os elementos que podem aparecer mais de uma vez. O elemento-filho herda quaisquer valores fornecidos pelo pai e acrescenta quaisquer valores próprios para a lista. Qualquer definição duplicada adicionada pelo elemento-filho pode ser ignorada.
Tabela 7 - Herança de propriedades da camada
Elemento,Número,Herança,(Comentário)
CRS,1+,adicionar,(Pode ser 0 somente se o valor é herdado a partir de um elemento <layer> superior, ver 7.2.4.6.6 através 7.2.4.6.8.)
EX_GeographicBoundingBox,1,substituir,(Pode ser 0 somente se o valor é herdado de um elemento <layer> superior;. Ver 7.2.4.6.6 a 7.2.4.6.8)
BoundingBox,1+,substituir,(Pode ser 0 somente se o valor é herdado de um elemento <layer> superior;. Ver 7.2.4.6.6 a 7.2.4.6.8)
[...]
7.3 GetMap (obrigatório)[...]
7.3.3 Parâmetros do pedido[...]
7.3.3.5 CRS
O parâmetro CRS do pedido GetMap define qual é o Layer CRS (ver 6.7.3) que se aplica aos valores do parâmetro BBOX. O valor do parâmetro CRS num pedido a um dado servidor deve ser um dos valores definidos, nos metadados de serviço, num elemento <CRS> definido ou herdado pela camada solicitada. O mesmo CRS é aplicado a todas as camadas de um único pedido.
Um servidor WMS não é obrigado a suportar todos os CRS possíveis, mas deve anunciar nos seus metadados de serviço quais os CRS que oferece e deve aceitar pedidos de todos os CRS anunciados. Se um pedido contém um CRS não oferecido por um dado servidor, o servidor deve lançar uma exceção de serviço (code="InvalidCRS").

Os clientes não são obrigados a suportar todos os CRS possíveis. Se um cliente e servidor não suportam um qualquer CRS comum, o cliente poderá, a seu critério: cessar a comunicação com o servidor; ou procurar um fornecedor de serviços intermédio que execute transformações de coordenadas; ou permitir ao utilizador escolher outra via alternativa.

Esta Norma não define um mecanismo que permita aos clientes a solicitar explicitamente a reprojeção ou transformação de coordenadas. Ou seja, existe apenas um único parâmetro CRS no pedido, e por isso não é possível especificar um CRS origem para selecionar a informação geográfica e um CRS destino para a representação cartográfica do mapa. Contudo, pode ocorrer uma reprojeção implícita, se o servidor oferece vários CRS mas internamente armazena a informação geográfica num CRS particular.
Se o servidor WMS declarou CRS=CRS:1 para uma dada camada, como discutido no ponto 6.7.3.5, então a camada não tem um CRS bem definido e não deve ser mostrado em conjunto com outras camadas. Neste caso, o cliente deve especificar CRS=CRS:1 no pedido GetMap e, caso contrário, o servidor pode emitir uma exceção de serviço. Quando este CRS=CRS:1 é usado num pedido, o parâmetro BBOX é expresso em pixeis.

7.3.3.6 BBOX

O parâmetro obrigatório BBOX permite a um cliente solicitar uma determinada caixa envolvente. As caixas envolventes são definidas no ponto 6.7.4. O valor do parâmetro BBOX num pedido GetMap é uma lista de números reais separados por vírgulas (ver 6.5) na forma de "minx, miny, maxx, maxy". Estes valores especificam o X mínimo, Y mínimo, X máximo e Y máximo da região pretendida, no Layer CRS do pedido. As unidades, ordenação e direção do incremento dos eixos X e Y são como definidos pelo Layer CRS (ver 6.7.3) Os quatro valores da caixa envolvente indicam os limites exteriores da região. A relação da caixa envolvente com a matriz de pixeis do mapa é que a caixa envolvente contorna "por fora" os pixeis do mapa, em vez de atravessar os centros dos pixeis limítrofes do mapa. Neste contexto, cada pixel individual representa uma área no terreno.

Se um pedido contém uma BBOX inválida (por exemplo, uma caixa cujo X mínimo é maior ou igual à X máximo, ou cujo Y mínimo é maior ou igual ao Y máximo) o servidor deve lançar uma excepção de serviço.
Se um pedido contém uma BBOX cuja área não se sobrepõe com o elemento <BoundingBox> dos metadados do serviço para a camada solicitada, o servidor deve retornar conteúdo vazio (ou seja, um mapa em branco ou um ficheiro gráfico sem elementos gráficos) para esse mapa. Quaisquer características total ou parcialmente contidas na caixa envolvente serão devolvidas no formato adequado.
Se os valores da caixa envolvente não essão definidos para o CRS em causa (por exemplo latitudes superiores a 90 graus no CRS:84), o servidor deve retornar conteúdo vazio para as áreas fora do intervalo válido para o CRS.
Se o servidor WMS declarou que uma camada não é "subsettable" (i.e. que a uma dada camada não pode ser solicitada informação com uma caixa envolvente diferente da declarada para um dado CRS), como descrito em 7.2.4.7.5, então o cliente deve especificar exatamente os valores da caixa envolvente declarada no pedido GetMap e, caso contrário, o servidor pode emitir uma exceção de serviço.
[...]
7.3.5 Projeção de CRS geográficos para o Map CS

Quando o parâmetro CRS especifica um sistema de referência por coordenadas geográficas (por exemplo CRS:84 ou EPSG:4326), os dados espaciais são projetados internamente usando o método de operação sobre coordenadas Pseudo Plate Carrée e subsequentemente transformados para o sistema de referência em coordenadas-imagem com o eixo i paralelo e proporcional à longitude e o eixo j paralelo e proporcional à latitude, de modo a permitir a visualização em ecrã.
Os eixos da imagem são de escala variável, porque os incrementos de latitude e longitude não são ambos consistentes em termos lineares. A informação geográfica é projetada durante a operação de representação cartográfica utilizando uma projeção equidistante cilíndrica modificada:
  • Os valores mínimos e máximos de longitude e latitude solicitados (min_lon, min_lat, max_lon, max_lat) são determinados a partir do parâmetro BBOX, tendo em conta a ordem do eixos x e y especificado pelo parâmetro CRS.
  • A distância angular (max_lon - min_lon) em graus é dimensionada para o número de pixeis especificado pelo parâmetro WIDTH.
  • A distância angular (max_lat - min_lat) em graus é dimensionada para o número de pixeis especificado pelo parâmetro HEIGHT.
  • O mapa é produzido com longitude paralela ao eixo i e latitude paralela ao eixo j.
[...]
Anexo B (normativo)
Definições de sistemas de referência por coordenadas (CRS)
B.1 Introdução
Este anexo define vários sistemas de coordenadas, incluindo o Map CS (ver 6.7.2), e vários Layer CRS no namespace "CRS" (ver 6.7.3.2) e namespace AUTO2 (ver 6.7.3.4), e um CRS Vertical (ver 6.7.5).
Os Layer CRS no namespace "EPSG" são definidos pelo European Petroleum Survey Group, como descrito em 6.7.3.3.
Todos os Layer CRS e CRS Vertical definidos neste anexo (ou por outra autoridade, como o EPSG) são opcionais; a escolha de quais os CRS a suportar fica ao critério do fornecedor de WMS. No entanto, é obrigatório o suporte ao Map CS definido no ponto B.2, porque esse sistema de coordenadas se aplica ao mapa gerados pelo WMS.
As definições deste Anexo utilizam o formato tabular conforme à norma ISO 19111 (Tabelas B.1 a B.5) ou as representações em WKT (Well Known Text) conformes à norma ISO 19125.
[...]


Extracto do glossário usado na tradução
    en,pt,description
    "atribute","atributo",
    "bounding box","caixa envolvente"
    "character string","cadeia de caracteres"
    "character","carácter"
    "class","classes"
    "contains","contem"
    "coordinate reference system","sistema de referência por coordenadas",[CRS]
    "coordinate system","sistema de coordenadas",[CS]
    "depth","profundidade"
    "disjoint","disjunto"
    "easting","distância à meridiana",[M]
    "elevation","altitude"
    "entity","entidade"
    "feature","característica"
    "file","ficheiro"
    "grid","malha"
    "identifier","identificador"
    "label","etiqueta"
    "Layer CRS","sistema de referência por coordenadas da camada",[Layer CRS]
    "layer","camada"
    "Map CS","sistema de coordenadas do mapa",[Map CS]
    "map service","serviço de mapas"
    "map","mapa"
    "norting","distância à perpendicular",[P]
    "overlay","sobreposição"
    "portrayal","representação cartográfica"
    "provider","fornecedor"
    "representation","representação"
    "request","pedido"
    "server","servidor"
    "service","serviço"

2011-09-26

Plate Carrée

Eu bem sabia que não ia ser assim tão simples...

Projeção equiretangular com elipses de deformação de Tissot [Fonte: Wikipedia]

Vou tentar não perder muito tempo com isto.


Para o sistema "Plate Carrée", todas as referências consultadas são consistentes quanto aos valores dos seguintes parâmetros:
  • Paralelo padrão: 0º (Equador)
  • Longitude de origem: 0º (Greenwich)
  • Falso M: 0 m
  • Falso P: 0 m
As diferentes interpretação/implementação parecem surgir quanto ao método de projeção utilizado:
Como referido aqui:
"Most libraries only implement the spherical version this projection. The rules for deriving a spherical radius from the ellipsoid defined for a coordinate system vary between libraries, causing some confusion and mixed results."

(ver também Plate Carree: Geoserver and ArcIMS Compatibility)

Por exemplo, no software ArcGis a projeção Plate Carrée é usada numa dos CRS pré-definidos sob a designação "Sphere_Plate_Carree" - caso em que surge associada a uma esfera de raio 6371000 m.
No registry EPSG, este valor de raio encontra associado a um registo deprecated (urn:ogc:def:ellipsoid:EPSG::7035) e substituído pelo urn:ogc:def:ellipsoid:EPSG::7048 - Esfera autálica ou equivalente correspondente ao elipsoide GRS 1980, com raio 6371007 m.


Para tentar reduzir a confusão...

No registry EPSG os únicos sistemas de referência por coordenadas (CRS) atualmente válidos com alguma relação com o nome "Plate Carrée" são os seguintes:

CRS epsg:4088 (World Equidistant (Sphere)) 
É a versão esférica, associada um datum não especificado sobre esfera equivalente ao elipsoide GRS 1980. Segundo a recomendação do EPSG, a usar apenas quando o datum geodésico é desconhecido.
CRS epsg:4087 (WGS84 / World Equidistant Cylindrical)
É a versão elipsoidal da projeção, associada ao CRS geodésico WGS84 (urn:ogc:def:crs:EPSG::4326).

Os CRS epsg:32662 e epsg:32663 foram ambos descontinuados e substituídos pelo epsg:4087.
(ainda se encontram referências dispersas pela internet, e.g. aqui)


2011-09-19

On induction, Bertrand Russell


[...] But the real question is: Do any number of cases of a law being fulfilled in the past afford evidence that it will be fulfilled in the future? If not, it becomes plain that we have no ground whatever for expecting the sun to rise to-morrow, or for expecting the bread we shall eat at our next meal not to poison us, or for any of the other scarcely conscious expectations that control our daily lives. It is to be observed that all such expectations are only probable; thus we have not to seek for a proof that they must be fulfilled, but only for some reason in favour of the view that they are likely to be fulfilled.
Now in dealing with this question we must, to begin with, make an important distinction, without which we should soon become involved in hopeless confusions. Experience has shown us that, hitherto, the frequent repetition of some uniform succession or coexistence has been a cause of our expecting the same succession or coexistence on the next occasion [...].
[...] We know that all these rather crude expectations of uniformity are liable to be misleading. The man who has fed the chicken every day throughout its life at last wrings its neck instead, showing that more refined views as to the uniformity of nature would have been useful to the chicken.
[no original]
[existem (pelo menos) duas traduções portuguesas - António Sérgio - Desidério Murcho]

2011-09-15

Beautiful visualization, O'Reilly

lido aos bocados pela internet... se cada autor colocar o seu capítulo online...

Table of Contents

Ch. 1: On Beauty, Noah Iliinsky

Ch. 3: Wordle. Jonathan Feinberg
 As word clouds mais bonitas do planeta.
O código para construir a visualização não está disponível, mas o de análise de texto sim.
E depois a interface alternativa do Wordle permite indicar frequências.

Ch. 6: Flight Patterns: A Deep Dive. Aaron Koblin with Valdean Klump
Dados de tráfego aéreo, processados no Processing e visualizados no Google Maps inter alia.

Ch. 9: The Big Picture: Search and Discovery. Todd Holloway
Ch. 12: Turning a Table into a Tree: Growing Parallel Sets into a Purposeful Project. Robert Kosara
Ch. 13: The Design of “X by Y”. Moritz Stefaner
Ch. 14: Revealing Matrices. Maximilian Schich
Ch. 17: Immersed in Unfolding Complex Systems. Lance Putnam et al.

2011-09-09

Sistemas de quadrículas na diretiva INSPIRE

Os sistemas de quadrículas constituem a forma mais simples de sistema de referência indireta (em que cada célula tem um identificador único  muito simples.

Este é um excerto dos aspetos mais relevantes da versão 3.0.1 do documento D2.8.I.2 INSPIRE Specification on Geographical Grid Systems – Guidelines


INSPIRE Geographical grid systems form a geo-referencing framework for the themes where grids with fixed and unambiguously defined location of equal-area grid cells are needed. 
A geographical grid is associated with predefined  resolutions and a coding system for identifying individual cells. 
The grid [...] is intended more for statistical reporting purposes [...].

Requisitos:
  1. The Grid_ETRS89-LAEA [...] shall be used as a geo-referencing framework for the themes where grids with fixed and unambiguously defined locations of equal-area grid cells are needed.
  2. For identification of an individual resolution level the cell size in metres shall be appended ([e.g.] Grid_ETRS89-LAEA_100K).
  3. The reference point of a grid cell for grids based on ETRS89-LAEA shall be the lower left corner of the grid cell. 
  4. [...] the grid  points of all grids based on ETRS89-LAEA shall coincide with grid points at Grid_ETRS89-LAEA [i.e. para quadrículas que não sejam recursivamente coerentes].
Identificadores:




Notas finais:
  • Um dos documentos técnicos de base citado na especificação, apresenta um link errado... O correto é European Reference Grids
  • Os ficheiros vetoriais da Grid_ETRS89-LAEA encontram-se disponível para download  na EEA (alternativa: seguir o permalink da página de acesso à última versão).

Sistemas de referência na diretiva INSPIRE

Este é um excerto dos aspetos mais relevantes da versão 3.1 do documento D2.8.I.1 INSPIRE Specification on Coordinate Reference Systems - Guidelines

Coordinate reference systems (hereafter: CRS) play a specific role that is quite different from the other themes [...] the CRS specification does not concern a downloadable or viewable thematic data set. Rather, it presents a basic functionality allowing the harmonised and interoperable geographic localisation of spatial objects defined by the other INSPIRE thematic data  specifications.

The accuracy of the data sets resulting from transformations and conversion formulas are out of scope of the theme CRS. The accuracy of the data sets must be documented by the data set provider according to all the aspects that contribute to it, namely the original data accuracy and the accuracy of the conversions, transformations and other aspects involved with the management of the data.  

Requisitos gerais
    1. For 3D and 2D CRS and horizontal component of compound CRS, the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas within its geographical scope.
    2. The International Terrestrial Reference System (ITRS) or other geodetic coordinate reference systems compliant with ITRS shall be used in areas that are outside the geographical scope of ETRS89.
    3. For the computation of latitude, longitude and ellipsoidal height, and for the computation of plane coordinates using a suitable mapping projection, the parameters of the GRS80 ellipsoid shall be used.
    4. For representation with plane coordinates [the following systems shall be used]:
      • Lambert Azimuthal Equal Area (ETRS89-LAEA);
      • Lambert Conformal Conic (ETRS89-LCC);
      • Transverse Mercator (ETRS89-TMzn)[where <<zn>> denotes the zone]
    5. [If other CRS are also used,] they shall be well documented to allow the conversion to geographic coordinates and an identifier shall be created, according to ISO 19111 and ISO 19127.
    6. For the vertical component on land, the European Vertical Reference System (EVRS) shall be used to express gravity-related heights within its geographical scope. 
    7. Other vertical reference systems related to the Earth gravity field shall be used to express gravity-related heights in areas that are outside the geographical scope of EVRS.
    8. For the vertical component in the free atmosphere, barometric pressure, converted to height using ISO 2533:1975 International Standard Atmosphere shall be used. [The vertical component in the free ocean is to be refined].
    Requisitos e recomendações para serviços de rede:
    1. For [...] view network service [...] at least the coordinate reference systems for two-dimensional geodetic coordinates (latitude, longitude) shall be available.
    2. [For transformations services, at least ETRS89-LAEA, ETRS89-LCC, ETRS89-TMzn]
    Identificadores INSPIRE:

    Identifier Type of coordinates
    ETRS89-XYZ Cartesian coordinates in ETRS89 in space (X,Y,Z)
    ETRS89-GRS80h Geodetic (geographic) coordinates and ellipsoidal height in ETRS89 on the GRS80 ellipsoid (Latitude, Longitude, Ellipsoidal height)
    ETRS89-GRS80 Geodetic (geographic) coordinates in ETRS89 on the GRS80 (Latitude, Longitude)
    EVRS Height in EVRS (H)
    LAT Depth of the sea floor, where there is an appreciable tidal range (D)
    MSL Depth of the sea floor, in marine areas without an appreciable tidal range, in open oceans and effectively in waters that are deeper than 200m (D)
    ISA Pressure coordinate in the free atmosphere (P)
    PFO Pressure coordinate in the free ocean (P)
    ETRS89-LAEA ETRS89 coordinates projected into plane coordinates by the Lambert Azimuthal Equal Area projection (Y,X)
    ETRS89-LCC ETRS89 coordinates projected into plane coordinates by the Lambert Conformal Conic projection (N,E)
    ETRS89-TMzn18 ETRS89 coordinates projected into plane coordinates by the Transverse Mercator projection (N,E)

    Notas finais
    • Apesar de a especificação definir a forma de identificar os CRS, não há qualquer referência a uma autoridade que funcione como register dos CRS e/ou a um registry que disponibilize online a documentação relevante sobre os CRS e respectivas transformações.
    • Um dos documentos técnicos de base citado na especificação (embora com um link errado...) - Map Projections for Europe - apresenta identificadores ligeiramente diferentes (pp:110-125), que omitem a data de realização do ETRS. Não obstante, no registry CRS-EU já surgem (pelo menos como alias) os vários identificadores possíveis e também os códigos EPSG correspondentes.
    Dúvidas em relação às recomendações de visualização

    Embora isso esteja for do âmbito estrito duma especificação sobre CRS, as Guidelines tecem algumas considerações sobre a visualização de informação geográfica (em aplicações web) que não são totalmente claras:

    The Mercator cylindrical spherical is the most interoperable in the field of view services. Several commercial services on the Internet use this CRS. It is fully compatible with good Internet practices. Parameters have to be defined once for the whole world (continental Europe and overseas territories).
    Esta referência a uma "Mercator cylindrical spherical" é, aparentemente, uma referência ao CRS epsg:3857 (WGS84 / Pseudo-Mercator).
      For the rendering of spatial information for INSPIRE View Services, and in the case where there is a need to use projected coordinates, one of the most intuitive is the "Plate-Carrée" projection. Parameters have to be defined once for the whole world (continental Europe and overseas territories). This assumption does not exclude other map projections with similar features.
      Esta referência à projeção quadrada "Plate Carrée" é de novo algo ambígua, uma vez que o termo é utilizado com sentidos diferentes em fontes diferentes.
      No sentido mais estrito, o termo é usado para o desenvolvimento esférico de uma projeção equidistante cilíndrica (método EPSG:1029) em que o paralelo padrão é o equador, o meridiano de referência é Greenwich e os valores de falso M e falso P são ambos de 0 m.
      Na consulta à base de dados EPSG, o único CRS consistente com a definição anterior é o CRS epsg:4088 (World Equidistant (Sphere)).

      No ponto 7.3.5 da especificação OGC WMS 1.3.0, surge também uma referência ao método Pseudo Plate Carrée (i.e. em para efeitos de visualização que os valores de latitude e longitude são tratados como coordenadas XY): quando é um mapa em coordenadas geográficas é pedido a um servidor WMS, a extensão geográfica da imagem é determinada através dos valores do parâmetro BBOX (em latitude e longitude) do pedido e as coordenadas imagem do mapa são obtidas "esticando" o resultado em função para os valores dos parâmetros de WIDTH e HEIGHT (em pixeis) do pedido.



      The equirectangular projection allows overlaying the existing view services in “Plate-Carrée” while being conformal. Whereas the cost of re-projecting into equirectangular is lower than for the Mercator cylindrical spherical, parameters have  to be defined separately for continental Europe and overseas territories.

      Este parágrafo é também um pouco confuso, dado que a designação "equirectangular projection" é um alias de "equidistant cylindrical projection" e sendo a designação "Plate Carrée" reservada para a instância das anteriores em que o paralelo padrão é o equador. Ou seja, vou admitir que, na primeira frase, se estará sempre a falar do CRS epsg:4088 e meramente a referir que este é conforme.


      A segunda frase é também confusa: "Whereas the cost of re-projecting into equirectangular is lower than for the Mercator cylindrical spherical" pode ser uma mera referência ao facto que que as fórmulas de projeção da Plate Carrée são extremamente simples e têm um menor custo computacional. Contudo, não se percebe a indicação de que tenham de ser definidos parâmetros diferentes para o continente Europeu e territórios ultramarinos, dado que a Plate Carrée é aplicável a todo o mundo. Enfim...

      However, if the data are stored in geographic coordinates there is no need for re-projecting.
      Este é o último parágrafo e, para mim, igualmente enigmático dado que se passa de uma discussão sobre a representação cartográfica de serviços WMS para uma observação sobre a forma de armazenamento. A única interpretação que me ocorre é trivial: se os dados estiverem armazenados num CRS geodésico, não é necessário reprojetá-los porque só é preciso projetá-los uma vez... mas esta interpretação é completamente pateta, por isso deve estar a escapar-me qualquer coisa... help...

      Seja como for, creio que, independentemente da bondade e dos pergaminhos históricos da projeção quadrada, não fará sentido perder ou complicar o acesso ao universo de dados e funcionalidades disponíveis no Google Maps, Bing Maps, Yahoo Maps, OpenStreetMap ou SAPO Mapas: e todos estes serviços assentam numa visualização em CRS epsg:3857 (WGS84 / Pseudo-Mercator).

      Por isso e para terminar, não valerá muito a pena perder tempo a destrinçar as questões relativas à Plate Carrée.

      2011-07-26

      INSPIRE Network Services Performance Guidelines

      A qualidade de serviço para os geowebservices INSPIRE é definida em termos de 8 critérios com diferentes possíveis métricas e indicadores (ver INSPIRE Network Services Performance Guidelines):

      A) Desempenho
      1) Definição
      O desempenho do serviço representa a rapidez com que um pedido de serviço pode ser concluído.
      2) Indicadores possíveis
      a) Rendimento (throughput) é o número de pedidos ao serviço respondidos num determinado intervalo de tempo.
      b) Tempo de resposta é o tempo necessário para completar um pedido ao serviço.
      c) Latência é o atraso de ida e volta entre o envio de um pedido e receção da resposta.
      d) Tempo de execução é o tempo gasto pelo serviço para processar a sua sequência de atividades.
      e) Tempo de transação é o tempo necessário à execução duma transação completa pelo serviço. O tempo de transação depende da definição de transação.
      Em geral, um serviço de alto desempenho proporciona um rendimento maior, tempo de resposta menor, menor latência, menor tempo de execução e menor tempo de transação.

      B) Confiabilidade
      1) Definição
      Os serviços devem ser fornecidos com alta confiabilidade. Confiabilidade representa a capacidade do serviço para executar suas funções requeridas sob condições estabelecidas por um intervalo de tempo especificado. A confiabilidade é a medida geral de um serviço para manter a sua qualidade de serviço.
      2) Indicadores possíveis
      A métrica básica de confiabilidade é o tempo:
      a) Tempo até a falha.
      b) Intervalos de tempo entre falhas (período).
      c) Falhas acumuladas num dado período de tempo.
      d) Falhas observadas num determinado intervalo de tempo.

      C) Capacidade
      1) Definição
      Os serviços devem ser fornecidos com a capacidade necessária. Capacidade é o limite do número de pedidos simultâneos que devem ser respondidos com desempenho garantido.
      2) Indicadores possíveis
      Número máximo de pedidos simultâneas com os critérios de desempenho acima definidos.

      D) Disponibilidade
      1) Definição
      O serviço deve estar pronto (isto é, disponível) para consumo imediato, com uma probabilidade definida.
      2) Indicadores possíveis
      Percentagem de tempo que o sistema se encontra disponível (uptime).

      E) Segurança
      1) Definição
      Segurança é o aspeto da qualidade do serviço que garante a confidencialidade e o não-repúdio por meio da autenticação das partes envolvidas, criptografia de mensagens e controle de acessos.
      2) Indicadores possíveis
      A segurança pode ser avaliada através de um conjunto de características diferentes:
      a) Autenticação: os utilizadores (ou outros serviços) que podem aceder ao serviço devem ser autenticados, sempre que aplicável.
      b) Autorização: os utilizadores (ou outros serviços) devem ser autorizadas de forma a que só eles possam aceder a serviços protegidos, sempre que aplicável.
      c) Confidencialidade: os dados devem ser tratados corretamente para que somente utilizadores autorizados (ou outros serviços) possam aceder ou modificar os dados, sempre que aplicável.
      d) Responsabilidade: o fornecedor pode ser responsabilizado pelos seus serviços.
      e) Rastreabilidade e auditabilidade: deve ser possível reconstituir o histórico de um serviço, quando um pedido seja atendido.
      f) Encriptação de dados: os dados devem ser encriptados, sempre que necessário.
      g) Não-repúdio: um utilizador não pode negar o pedido de um serviço ou de dados, após este pedido ter sido efetuado.

      F) Conformidade (Regulatory)

      1) Definição
      Aspeto da qualidade do serviço relativa à conformidade com as regras de implementação, legislação, etc. e o cumprimento das normas e do acordo de nível de serviço estabelecido.
      2) Indicadores possíveis
      Segundo a diretiva INSPIRE, as Regras de Implementação de um serviço incluem obrigatoriamente, Especificações Técnicas e Critérios Mínimos de Desempenho.
      Para os critérios de desempenho, a conformidade será alcançado com o cumprimento dos limites ou medidas incluídas nas Regras de Implementação de cada tipo de serviço.

      G) Interoperabilidade

      1) Definição
      Os serviços devem ser interoperáveis entre diferentes ambientes de desenvolvimento utilizáveis na sua implementação.
      2) Indicadores possíveis
      Os utilizadores (ou outros serviços) de um serviço não necessitam conhecer a linguagem de programação, sistema operativo, etc., do serviço consumido.

      2011-06-28

      Geographical names

      Para ir completando...

      2011-05-18

      FAO Land Cover Classification System

      Documentos "normativos":
      • ISO/DIS 19144-1 - a norma já foi publicada como ISO 19144-1:2009
      • ISO/DIS 19144-2 Geographic information - Classification systems -- Part 2: Land Cover Meta Language (LCML) 
      Informação Genérica
        • Introdução ao problema das classificações de LULC no 2nd EARSEL Workshop (from 28-30 September 2006 in Bonn, Germany) [e não acredito que queiram mesmo usar Prolog no LCCS versão 3... :-S ]
        • NEW CONCEPT ON LAND COVER / LAND USE INFORMATION SYSTEM IN SPAIN.
        • Apresentação sobre o LCCS 3
        • A ler mais tarde com atenção [o que é que eu já li deste autor? generalização cartográfica ?]
        • HLANDATA project - Methodology specification for the harmonization of the available datasets
        • What is LCCS
        • Translation of the CORINE Land Cover nomenclature to the Land Cover Meta Language using LCCS3
        Projectos europeus, internacionais et al.

          • Global Land Cover 2000 - Legend

            2011-05-17

            WMS Servers

            Depois do recente lançamento do Mapserver 6.0.0 e do Geoserver 2.1.0 - e agora que são ambos WMS 1.3.0. compliant - continua a ser interessante ver os resultados do benchmarking realizado com as versões anteriores:

            • Desempenho "similar" para cenários de baixa carga de pedidos, maiores diferenças de desempenho à media que aumenta a carga de pedidos simultâneos;
            • Bottlenecks a nível de hardware: o tempo de acesso ao disco é o primeiro ponto crítico, a seguir o CPU (tradução simplista - disco suficiente, memória quanta possível?...)
            • Bottlenecks a nível de software: nos servidores de mapas Java ao nível da rasterização com anti-aliasing
            • Bottlenecks (?) a nível de OS: ver o muito melhor desempenho do Mapserver no servidor Red Hat vs. Windows (slides 66 e seguintes).

            2011-05-16

            Global Biodiversity Information Facility

            Alguns recursos relacionados com a GBIF:

            Metadata Harvesting (OAI-PMH)

            Pesquisa de recursos sobre metadata harvesting

            [interessa sobretudo a recolha selectiva de registos de metadados, de modo a que um mesmo registo possa ser exposto por diferentes serviços agregadores sem que haja duplicação e/ou inconsistência no conteúdo]

            Open Archives Initiative - Protocol for Metadata Harvesting
            Data Providers are repositories that expose structured metadata via OAI-PMH.
            Service Providers then make OAI-PMH service requests to harvest that metadata. OAI-PMH is a set of six services that are invoked within HTTP.

            Especificação > OAI-PMH Version 2.0 Specification

            Resource Item Record(s)
            Exemplo de registo:
            <header>
              <identifier>oai:arXiv:cs/0112017</identifier>
              <datestamp>2002-02-28</datestamp>
              <setSpec>cs</setSpec>
              <setSpec>math</setSpec>
            </header>
            <metadata>
            ...
            </metadata>
            <about> 
              <provenance
                  xmlns="http://www.openarchives.org/OAI/2.0/provenance" 
                  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
                  xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/provenance
                  http://www.openarchives.org/OAI/2.0/provenance.xsd">
                <originDescription harvestDate="2002-02-02T14:10:02Z" altered="true">
                  <baseURL>http://the.oa.org</baseURL>
                  <identifier>oai:r2:klik001</identifier>
                  <datestamp>2002-01-01</datestamp>
                  <metadataNamespace>http://www.openarchives.org/OAI/2.0/oai_dc/</metadataNamespace>
                </originDescription>
              </provenance>
            </about>

            [...]If a record is no longer available then it is said to be deleted[...].
            Repositories must declare one of three levels of support for deleted records[...]:
            no - the repository does not maintain information about deletions.
            persistent - the repository maintains information about deletions with no time limit.

            transient - the repository does not guarantee that a list of deletions is maintained persistently or consistently.
            If a repository does not keep track of deletions then such records will simply vanish from responses and there will be no way for a harvester to discover deletions through continued incremental harvesting.

            [...]
            A set is an optional construct for grouping items for the purpose of selective harvesting. Repositories may organize items into sets. Set organization may be flat, i.e. a simple list, or hierarchical. Multiple hierarchies with distinct, independent top-level nodes are allowed.[...]
            Selective harvesting allows harvesters to limit harvest requests to portions of the metadata available from a repository.
            The OAI-PMH supports selective harvesting with two types of harvesting criteria [...]: datestamps and set membership.

            Tutorial > XML Schemas and Support for Multiple Record Formats in OAI-PMH

            Implementações > GeoNetwork 2.6.3
            Multiple harvesting and hierarchiesCatalogues that provide UUIDs for metadata (for example GeoNetwork and a CSW server) can be harvested several times without having to take care about metadata overlap.
            This allows the possibility to perform a thematic search and a metadata belonging to multiple searches is harvested only once and not duplicated.
            This mechanism allows the GeoNetwork harvesting type to be combined with other GeoNetwork nodes to perform hierarchical harvesting.
            This way a metadata can be harvested from several nodes. For example, consider this scenario:
                Node (A) has created metadata (a)
                Node (B) harvests (a) from (A)
                Node (C) harvests (a) from (B)
                Node (D) harvests from both (A), (B) and (C)
            In this scenario, Node (D) will get the same metadata (a) from all 3 nodes (A), (B), (C). The metadata will flow to (D) following 3 different paths but thanks to its UUID only one copy will be stored. When (a) will be changed in (A), a new version will flow to (D) but, thanks to the change date, the copy in (D) will be updated with the most recent version.

            [obviamente, para que isto funcione, um registo harvested nunca é editável por quem o recolheu]


            Exemplos >

            Implementações > ESRI Geoportal 9.3.1
            Open Archives Initiative (OAI)
            Required Fields
                    URL/Host: URL of the server that host the metadata repository or clearinghouse
                    OAI Set: name of the set or database from which you want to harvest
                    OAI Meta Prefix: prefix of the metadata records stored in the OAI database that you want to harvest
            Optional Fields
                    Max Documents to Harvest: the maximum number of documents that will be harvested. If left blank, every document in the repository will be harvested, assuming no other criteria have been set
                    From/Until Date: date range can be used to harvest metadata records that have been updated or created in a specified period. Specifying only the "from" date, implies an "until" date of today
            [aparentemente a especificação de um set é obrigatória nesta implementação]

            2011-05-11

            Metadados (Perfil MIG)

            Síntese de apontadores para o perfil MIG
            (por parsing dos resultados do Google)


            ORDER TITLE SORT OBS
            12 MIG- Metadados para Informação Geográfica scrif.igeo.pt/webmig/docs/ImplementacaoMetadados.pdf - Similar
            4 MIG- Metadados para Informação Geográfica scrif.igeo.pt/webmig/docs/IntroducaoNorma19115.pdf - Similar
            14 Curso “MIG– Metadados de Informação Geográfica” scrif.igeo.pt/webmig/docs/xml_xsl.pdf - Similar
            76 EquipaMIG scrif.igeo.pt/webmig/EquipaMIG.aspx - Cached - Similar
            70 Boas Práticas de Documentação snig.igeo.pt/.../PerfilMIG.../Boas_Pr_ticas_de_Documenta__o.htm - Cached - Similar
            34 Definição do Perfil snig.igeo.pt/.../PerfilMIG.../Regras_Para_a_Defini__o_do_Perfil.htm - Cached - Similar
            94 Extensão Geográfica snig.igeo.pt/.../PerfilMIG...e.../Extens_o_Geogr_fica.htm - Cached - Similar
            10 Publicação através do MIGEditor snig.igeo.pt/.../Publica__o_atrav_s_do_MIG_Editor.htm - Cached - Similar
            90 Sistema Nacional de Informação Geográfica snig.igeo.pt/eventos/JornadasMAOT/SNIG-IGP.pdf - Similar
            92 Member State Report: Portugal, 2010 snig.igeo.pt/Inspire/documentos/.../M.../INSPIREReportPortugal2010.pdf
            72 2ª Reunião GT M&R do CO- SNIG snig.igeo.pt/Inspire/documentos/.../M&R2010/recomendacoes.pdf
            86 Draft INSPIRE Monitoring Indicators (D5.2) snig.igeo.pt/inspire/documentos/.../RelatorioINSPIREPortugal_2010.pdf
            80 Relatório Estado Membro: Portugal, 2010 snig.igeo.pt/Inspire/documentos/.../RelatorioINSPIREPortugal2010v2.pdf
            58 Reunião Gestores de Metadados Anexos I e II snig.igeo.pt/Inspire/documentos/.../ReuniaoGestoresMetadados20101021.pdf
            62 GeoPortal do SNIG snig.igeo.pt/inspire/documentos/agueda/DF.pdf
            60 Sistema Nacional de Informação Geográfica snig.igeo.pt/inspire/documentos/COSNIG/.../2%20SNIG%20Plano.pdf
            88 Directiva INSPIRE – Temas dos snig.igeo.pt/inspire/documentos/COSNIG/reuniao1/3%20M&R.pdf - Similar
            74 Implementação da Directiva INSPIRE no INAG snig.igeo.pt/inspire/documentos/ESIG2008/AnaMariano_INAG.pdf
            42 SNIG: Geoportal GeoWebServices (GWS) e Metadados Henrique Silva snig.igeo.pt/inspire/documentos/ESIG2010/HS.pdf
            68 Monitorização dos CDG e Serviços - 2011 Orientações Gerais ... snig.igeo.pt/Inspire/documentos/GTM&RCOSNIG/.../orientacoes.pdf
            84 Entidades formalmente responsáveis pela produção de CDG snig.igeo.pt/Inspire/documentos/GTM&RCOSNIG/.../reuniao5GTM&R.ppt
            50 O Sistema Nacional de Informação Geográfica snig.igeo.pt snig.igeo.pt/inspire/documentos/iGOV/iGOV_RPJ.pdf
            36 Metadados Henrique Silva snig.igeo.pt/Inspire/documentos/JIIDE2010/HS.pdf
            48 Metadados: Normas, Produção, Publicação e Pesquisa Jornadas ... snig.igeo.pt/Inspire/documentos/JIIDE2010/workshopHS.pdf
            24 Estado da Implementação do INSPIRE no IGP snig.igeo.pt/inspire/documentos/Ordem_Engenheiros/HS.pdf
            52 SNIG e a Directiva INSPIRE snig.igeo.pt/inspire/documentos/WorkshopRedeInspire/HS.pdf
            30 Formação - Inspire snig.igeo.pt/Inspire/formacao.asp - Cached
            2 MIGEditor - Ajuda MIGEditor - Confluence snig.igeo.pt/migeditor/display/HELP/MIG+Editor - Cached - Similar
            16 1. Introdução ao MIG... snig.igeo.pt/migeditor/download/attachments/.../HELP-105351-76.pdf?...
            46 Descrição dos Elementos ou Entidades snig.igeo.pt/Portal/.../PerfilMIG.../Descri__o_dos_Elementos.htm - Cached - Similar
            66 Harvesting snig.igeo.pt/Portal/docs/.../Harvesting_de_metadados.htm - Cached - Similar
            64 Identificador Único snig.igeo.pt/portal/docs/...webhelp/Identificador__nico.htm - Cached - Similar
            18 Perfil MIG1.2 snig.igeo.pt/Portal/docs/PerfilMIG_WebHelp/index.htm - Cached - Similar
            96 ISO 19115:2003 - Metadados para Informação Geográfica snig.igeo.pt/Portal/docs/PerfilMIG...e.../ISO_19115.htm - Cached - Similar
            22 Ensino e Formação - Destaques snig.igeo.pt/portal/index.php?option=com_content... - Cached
            32 Metadados snig.igeo.pt/portal/index.php?option=com_content... - Cached
            26 Aplicações snig.igeo.pt/portal/index.php?option=com...id... - Cached - Similar
            28 Editores de metadados snig.igeo.pt/portal/index.php?option=com...id... - Cached - Similar
            38 Edição e Publicação de Metadados snig.igeo.pt/portal/index.php?option=com...id... - Cached - Similar
            8 Formação MIG snig.igeo.pt/portal/index.php?option=com...view... - Cached - Similar
            56 SNIG snig.igeo.pt/portal/index.php?view=newsfeed...id... - Cached
            54 Novidades e Eventos www.igeo.pt/eventos/boletim/Newsletter_2007_08.htm - Cached
            78 Novidades e Eventos www.igeo.pt/eventos/boletim/Newsletter_2007_10.htm - Cached
            6 MIG– Edição e Visualização de Metadados www.igeo.pt/eventos/comunicacoes/.../Metadados_GisPlanet05.pdf - Similar
            40 Instituto Geográfico Português, Rosário Gaspar 1 www.igeo.pt/eventos/comunicacoes/Lisboa/BPM_IGP_RGaspar.pdf
            44 Slide 1 - Instituto Geográfico Português www.igeo.pt/eventos/comunicacoes/Oeiras/MIG_P.ppt - Similar
            20 Formulário de Inscrição em Formação MIG www.igeo.pt/instituto/cegig/mig/formacao/formacaomig.asp
            82 Fórum SNIG • Vendo Tópico - Publicação dos Metadados no SNIG www.igeo.pt/phpbb3/viewtopic.php?f=25&t=451 - Cached