Trabalhar com o datasets.xml Arquivo

\[ Esta página será apenas de interesse para ERDDAP™ administradores. \]

Depois de ter seguido o ERDDAP™ instruções de instalação , você deve editar o datasets.xml arquivo em Toca a brincar. /content/erddap/ para descrever os conjuntos de dados que seu ERDDAP™ instalação irá servir.

Você pode ver um exemplo datasets.xml em GitHub .

- Não.

Introdução

Um conjunto necessário

Configurar um conjunto de dados ERDDAP™ não é apenas uma questão de apontar para o diretório ou URL do conjunto de dados. Você tem que escrever um pedaço de XML para datasets.xml que descreve o conjunto de dados.

Para conjuntos de dados gradeados, a fim de fazer o conjunto de dados conforme ERDDAP 's estrutura de dados para dados gradeados, você tem que identificar um subconjunto das variáveis do conjunto de dados que compartilham as mesmas dimensões. ( Porquê? Como? )
Os metadados atuais do conjunto de dados são importados automaticamente. Mas se você quiser modificar esses metadados ou adicionar outros metadados, você precisa especificá-lo em datasets.xml . E ERDDAP™ precisa de outros metadados, incluindo atributos globais (como infoUrl , instituição, sourceUrl , resumo e título) e atributos variáveis (como long\_name e unidades) . Assim como os metadados que estão atualmente no conjunto de dados adicionam informações descritivas para o conjunto de dados, os metadados solicitados por ERDDAP™ adiciona informações descritivas ao conjunto de dados. Os metadados adicionais são uma boa adição ao seu conjunto de dados e ajudam ERDDAP™ fazer um trabalho melhor de apresentar seus dados aos usuários que não estão familiarizados com isso.
ERDDAP™ precisa que você faça coisas especiais com o longitude, latitude, altitude (ou profundidade) , e variáveis de tempo .

Se você comprar essas ideias e gastar o esforço para criar o XML para datasets.xml , você tem todas as vantagens de ERDDAP™ , incluindo:

Busca de texto completo para conjuntos de dados
Procurar conjuntos de dados por categoria
Formulários de acesso de dados ( * datasetID * .html) para que você possa solicitar um subconjunto de dados em vários formatos de arquivo diferentes
Formulários para solicitar gráficos e mapas ( * datasetID * .)
Serviço de Mapa Web ( WMS ) para conjuntos de dados gradeados
RESTful acesso aos seus dados

Fazendo a datasets.xml leva um esforço considerável para os primeiros conjuntos de dados, mas fica mais fácil . Após o primeiro conjunto de dados, você pode frequentemente reutilizar muito do seu trabalho para o próximo conjunto de dados. Felizmente, ERDDAP™ vem com dois Ferramentas para ajudá-lo a criar o XML para cada conjunto de dados datasets.xml . Se ficares preso, vê o nosso seção sobre como obter suporte adicional .

Variáveis em datasets.xml

A partir de ERDDAP™ versão 2.29.0, datasets.xml é agora (opcionalmente) processado por um Segmento Substituto . Isso tem muitos usos, incluindo definir valores privados (como senhas) usando variáveis de ambiente. Isso pode ser desativado, configurando enableEnvParsing para false no setup.xml.

Provedor de dados Formulário

Quando um provedor de dados vem a você esperando adicionar alguns dados ao seu ERDDAP , pode ser difícil e demorado para coletar todos os metadados (informações sobre o conjunto de dados) necessário para adicionar o conjunto de dados ERDDAP . Muitas fontes de dados (por exemplo, arquivos .csv, Arquivos do Excel, bancos de dados) não tem metadados internos, então ERDDAP™ tem um formulário de provedor de dados que reúne metadados do provedor de dados e dá ao provedor de dados alguma outra orientação, incluindo ampla orientação para Dados em Bancos de Dados . As informações apresentadas são convertidas em datasets.xml formato e depois enviado para o ERDDAP™ administrador (tu) e escrito (apêndice) para Diretriz de grande porte /logs/dataProviderForm.log . Assim, o formulário semi-automatiza o processo de obtenção de um conjunto de dados em ERDDAP , mas o ERDDAP™ administrador ainda tem que completar o datasets.xml chunk e lidar com a obtenção do arquivo de dados (S) do provedor ou conectando ao banco de dados.

A submissão de arquivos de dados reais de fontes externas é um enorme risco de segurança, portanto ERDDAP™ não lida com isso. Você tem que descobrir uma solução que funciona para você e o provedor de dados, por exemplo, e-mail (para arquivos pequenos) , puxar da nuvem (por exemplo, DropBox ou Google Drive) , um site de sftp (com senhas) , ou tênis Rede (uma pen drive USB ou disco rígido externo) . Você provavelmente só deve aceitar arquivos de pessoas que você conhece. Você precisará verificar os arquivos para vírus e tomar outras precauções de segurança.

Não há ligação. ERDDAP™ para o formulário de fornecedor de dados (por exemplo, no ERDDAP™ Página inicial) . Em vez disso, quando alguém lhe diz que eles querem ter seus dados servidos por seu ERDDAP , você pode enviar-lhes um e-mail dizendo algo como: Sim, nós podemos colocar seus dados em ERDDAP . Para começar, preencha o formulário nohttps://yourUrl/erddap/dataProviderForm.html (ou http:// se https:// não está habilitado) . Depois de terminares, contacto-te para resolveres os pormenores finais. Se você só quer olhar para o formulário (sem encher) , você pode ver o formulário em ERD ' ERDDAP : Introdução , Parte 1 , Parte 2 , Parte 3 e Parte 4 . Estas ligações ERD ERDDAP™ enviar informações para mim, não você, então não envie informações com eles a menos que você realmente queira adicionar dados ao ERD ERDDAP .

Se você quiser remover o Formulário de Provedor de Dados do seu ERDDAP™ , posto

<dataProviderFormActive>false</dataProviderFormActive>

em seu arquivo setup.xml.

O impulso para isto foi NOAA 2014 Acesso público aos resultados da pesquisa (PARR) directiva , que requer tudo NOAA dados ambientais financiados através de dólares contribuintes ser disponibilizado através de um serviço de dados (não apenas arquivos) dentro de 12 meses de criação. Assim, há maior interesse em usar ERDDAP™ para disponibilizar conjuntos de dados através de um serviço ASAP. Precisávamos de uma forma mais eficiente de lidar com um grande número de provedores de dados.

Feedback/Sugestões? Este formulário é novo, então por favor e-mail erd dot data at noaa dot gov se você tem algum feedback ou sugestões para melhorar isso.

Ferramentas

ERDDAP™ vem com dois programas de linha de comando que são ferramentas para ajudá-lo a criar o XML para cada conjunto de dados que você deseja ERDDAP™ servir. Uma vez que você tenha configurado ERDDAP™ e executar (pelo menos uma vez) , você pode encontrar e usar estes programas no Toca a brincar. /webapps/erddap/WEB-INF diretório. Existem scripts de shell Linux/Unix (com a extensão .sh) e scripts do Windows (com a extensão .bat) para cada programa. \[ No Linux, execute essas ferramentas como o mesmo usuário (Tomcat?) Isso vai correr Tomcat. \] Quando você executar cada programa, ele fará perguntas. Para cada pergunta, digite uma resposta e, em seguida, pressione Enter. Ou pressione ^C para sair de um programa a qualquer momento.

O programa não funciona?

Se você conseguir um programa desconhecido (ou similar) mensagem de erro, o problema é provavelmente que o sistema operacional não conseguiu encontrar Java . Você precisa descobrir onde Java está em seu computador, em seguida, editar a referência java no arquivo .bat ou .sh que você está tentando usar.
Se você receber um arquivo jar não encontrado ou classe não encontrada mensagem de erro, então Java não encontrou uma das classes listadas no arquivo .bat ou .sh que você está tentando usar. A solução é descobrir onde está o arquivo .jar e editar a referência java para ele no arquivo .bat ou .sh.
Se você estiver usando uma versão de Java que é muito velho para um programa, o programa não será executado e você verá uma mensagem de erro como Exceção na linha "principal" java.lang.UnsupportedClassVersionError: alguns/classe/nome : Versão principal não suportada.minor um pouco de madeira
A solução é atualizar para a versão mais recente de Java e certifique-se de que o arquivo .sh ou .bat para o programa está usando-o.

As ferramentas imprimem várias mensagens diagnósticas:

A palavra "ERROR" é usada quando algo correu tão mal que o procedimento não foi concluído. Embora seja irritante para obter um erro, o erro força você a lidar com o problema.
A palavra "ARNING" é usada quando algo correu mal, mas o procedimento foi capaz de ser concluído. São muito raros.
Qualquer outra coisa é apenas uma mensagem informativa. Você pode adicionar \-verbose ao Gerar conjuntos de dadosXml ou DasDds linha de comando para obter mensagens informativas adicionais, que às vezes ajuda a resolver problemas.

As duas ferramentas são uma grande ajuda, mas você ainda deve ler todas essas instruções nesta página cuidadosamente e tomar decisões importantes você mesmo.

Gerar conjuntos de dadosXml

Gerar conjuntos de dadosXml é um programa de linha de comando que pode gerar um rascunho áspero do conjunto de dados XML para quase qualquer tipo de conjunto de dados.

Nós STRONGLY RECOMEND que você usa GenerateDatasets Xml em vez de criar pedaços de datasets.xml por mão porque:

Gerar conjuntos de dados Xml funciona em segundos. Fazer isto à mão é pelo menos uma hora de trabalho, mesmo quando você sabe o que está fazendo.
Gerar conjuntos de dados Xml faz um trabalho melhor. Fazer isso à mão requer amplo conhecimento de como ERDDAP™ funciona. É improvável que você faça um trabalho melhor à mão. (Bob Simons sempre usa GerrateDatasets Xml para o primeiro rascunho, e ele escreveu ERDDAP .)
Gerar conjuntos de dados Xml sempre gera um pedaço válido de datasets.xml . Qualquer pedaço de datasets.xml que você escreve provavelmente terá pelo menos alguns erros que impedem ERDDAP™ de carregar o conjunto de dados. Muitas vezes leva as pessoas horas para diagnosticar esses problemas. Não percas tempo. Deixe Gerar Conjuntos de dados Xml faz o trabalho duro. Então você pode refinar o .xml à mão se quiser.

Quando você usa o GerarDatasets Programa Xml:

No Windows, a primeira vez que você executa GenerateDatasetsXml, você precisa editar o arquivo GenerateDatasetsXml.bat com um editor de texto para mudar o caminho para o java. exe arquivo para que o Windows possa encontrar Java .
Gerar conjuntos de dados Xml pede primeiro para especificar o EDDType (Erd Dap Dataset Tipo) do conjunto de dados. Ver Lista de Tipos de Conjunto de Dados (neste documento) para descobrir qual é o tipo apropriado para o conjunto de dados em que você está trabalhando. Além dos EDDTypes regulares, há também alguns Tipos Especiais/Pseudo Dataset (por exemplo, um que rasteja um catálogo THREDDS para gerar um pedaço de datasets.xml para cada um dos conjuntos de dados no catálogo) .
Gerar conjuntos de dados Xml então faz uma série de perguntas específicas para esse EDDType. As perguntas reúnem as informações necessárias para ERDDAP™ para acessar a fonte do conjunto de dados. Para entender o que ERDDAP™ está pedindo, veja a documentação para o EDDType que você especificou clicando no mesmo tipo de conjunto de dados no Lista de Tipos de Conjunto de Dados .

Se você precisar inserir uma string com caracteres especiais (por exemplo, caracteres do espaço branco no início ou fim, caracteres não-ASCII) , entrar em Corda de estilo JSON (com caracteres especiais escapou com caracteres \) . Por exemplo, para inserir apenas um caractere de aba, digite "\t" (com aspas duplas circundantes, que dizem ERDDAP™ que esta é uma corda de estilo JSON.

Muitas vezes, uma de suas respostas não será o que GenerateDatasetsXml precisa. Você pode tentar novamente, com respostas revisadas para as perguntas, até GerarDatasets Xml pode encontrar e entender com sucesso os dados de origem.
Se você responder corretamente às perguntas (ou suficientemente corretamente) , Gerar conjuntos de dados Xml se conectará à fonte do conjunto de dados e recolherá informações básicas (por exemplo, nomes variáveis e metadados) . Para conjuntos de dados que são de local NetCDF .nc e arquivos relacionados, GerarDatasets Xml muitas vezes imprimir a estrutura semelhante ao ncdump do arquivo depois que ele lê primeiro o arquivo. Isso pode lhe dar informações para responder às perguntas melhor em um loop subsequente através do GerrateDatasetsXml.
Gerar conjuntos de dados Xml irá então gerar um rascunho áspero do conjunto de dados XML para esse conjunto de dados.
InformaÃ§Ãμes diagnósticas e o rascunho áspero do conjunto de dados XML serÃ¡ escrito para Diretriz de grande porte /logs/GenerateDatasetsXml.log .
O rascunho áspero do conjunto de dados XML será escrito para Diretriz de grande porte /logs/GenerateDatasetsXml.out .

"0 ficheiros" Mensagem de erro

Se você executar GerarDatasets Xml ou DasDds , ou se você tentar carregar um EDDGrid De...Files ou EDDTableDe... Dataset de arquivos em ERDDAP™ , e você recebe uma mensagem de erro "0 files" indicando que ERDDAP™ encontrado 0 arquivos correspondentes no diretório (quando você acha que existem arquivos correspondentes nesse diretório) :

Verifique se você especificou o nome completo do diretório. E se você especificou o nome do arquivo da amostra, certifique-se de especificar o nome completo do arquivo, incluindo o nome completo do diretório.
Verifique se os arquivos estão realmente nesse diretório.
Verifique a ortografia do nome do diretório.
Verifique o arquivoNameRegex. É realmente, muito fácil cometer erros com regexes. Para fins de teste, tente o regex .\* que deve corresponder a todos os nomes de arquivos. (Veja isto documentação e tutorial do regex .)
Verifique se o usuário que está executando o programa (por exemplo, user=tomcat (?) para Tomcat / ERDDAP ) tem permissão 'read' para esses arquivos.
Em alguns sistemas operacionais (por exemplo, SELinux) e dependendo das configurações do sistema, o usuário que executou o programa deve ter permissão de 'leitura' para toda a cadeia de diretórios que levam ao diretório que tem os arquivos.
Se você tem problemas que você não pode resolver, suporte de solicitação com o máximo de informação possível. Da mesma forma, se parece que o EDDType apropriado para um determinado conjunto de dados não funciona com esse conjunto de dados, ou se não houver nenhum EDDType apropriado, por favor, apresente um questão sobre GitHub com os detalhes (e um arquivo de amostra se relevante) .

Você precisa editar a saída de GerarDatasets Xml para torná-lo melhor.

- Não. O Reino Unido datasets.xml MADE BE Gerar conjuntos de dados Xml não é perfeito. Você deve ler e identificar o XML antes de usá-lo em um público ERDDAP . Gerar conjuntos de dados RELAÇÕES de Xml sobre um monte de regras de THUMB quando não estão sempre em ordem. Você é irresponsável por ter encontrado a corrreta do XML que você gostaria de ERDDAP ' datasets.xml FILE.
  
  (Fato divertido: não estou gritando. Por razões legais históricas, as reclamações devem ser escritas em todos os bonés.)

A saída de GerarDatasetsXml é um rascunho áspero. Você quase sempre precisará editá-lo. Fizemos e continuamos a fazer um enorme esforço para fazer a saída o mais pronta possível, mas há limites. Muitas vezes, as informações necessárias simplesmente não estão disponíveis a partir dos metadados de origem.

Um problema fundamental é que estamos a pedir um programa de computador (Gerar conjuntos de dadosXml) para fazer uma tarefa onde, se você deu a mesma tarefa para 100 pessoas, você obteria 100 resultados diferentes. Não há nenhuma resposta "direita". Obviamente, o programa é mais próximo de ler a mente de Bob. (não é seu) , mas mesmo assim, não é um programa AI abrangente, apenas um monte de heurísticas cobbled juntos para fazer uma tarefa semelhante a AI. (Esse dia de um programa de IA pode vir, mas ainda não chegou. Se / quando isso acontecer, nós humanos podem ter problemas maiores. Tenha cuidado com o que deseja.)

Para fins informativos, a saída mostra a fonte globalAttributes e fonte variávelAttributes como comentários. ERDDAP™ combina sourceAttributes e addAttributes (que têm precedência) para fazer o combinado Atributos que são mostrados ao usuário. (E outros atributos são automaticamente adicionados a variáveis longitude, latitude, altitude, profundidade e tempo quando ERDDAP™ realmente faz o conjunto de dados) .
Se você não gosta de um sourceAttribute, substituí-lo adicionando um addAttribute com o mesmo nome, mas um valor diferente (ou nenhum valor, se você quiser removê-lo) .
Todos os addAttributes são sugestões geradas por computador. Edite-os! Se você não gosta de um addAttribute, mude-o.
Se você quiser adicionar outros addAttributes Acrescente-os.
Se você quiser mudar um destinationName Muda-a. Mas não mudes. sourceName S.
Você pode alterar a ordem do dataVariable s ou remover qualquer um deles.
- Você pode então usar DasDds (ver abaixo) para testar repetidamente o XML para esse conjunto de dados para garantir que o conjunto de dados resultante aparece como você quer ERDDAP .
- Sinta-se livre para fazer pequenas mudanças no datasets.xml chunk que foi gerado, por exemplo, fornecer um melhor infoUrl , resumo ou título.

não adicionar nomes padrão

Se você incluir \-doNotAddStandardNames como um parâmetro de linha de comando quando você executar gerar Conjuntos de dados Xml, gerar Conjuntos de dados Xml não vai adicionar standard\_name ao addAttributes para quaisquer variáveis que não as variáveis denominadas latitude, longitude, altitude, profundidade ou tempo (que tem óbvio standard\_name S) . Isso pode ser útil se você estiver usando a saída de gerar Conjuntos de dados Xml diretamente em ERDDAP™ sem editar a saída, porque gerar Conjuntos de dados Xml muitas vezes adivinha standard\_name incorretamente. (Note que sempre recomendamos que você edite a saída antes de usá-la em ERDDAP .) Usando este parâmetro terá outros efeitos relacionados menores porque o adivinhado standard\_name é frequentemente usado para outros fins, por exemplo, para criar um novo long\_name , e para criar as configurações colorBar.

Scripting

Como uma alternativa para responder as perguntas interativamente no teclado e looping para gerar conjuntos de dados adicionais, você pode fornecer argumentos de linha de comando para responder a todas as perguntas para gerar um conjunto de dados. Gerar conjuntos de dados Xml irá processar esses parâmetros, escrever a saída para o arquivo de saída e sair do programa.

Para configurar isso, primeiro use o programa em modo interativo e escreva suas respostas. Aqui está um exemplo parcial: Digamos que você execute o script: ./GenerateDatasetsXml.sh Em seguida, digite: EDDTableFromAsciiFiles Em seguida, digite: /u00/data/ Em seguida, digite: .\*\.asc Em seguida, digite: /u00/data/sampleFile.asc Em seguida, digite: ISO-8859-1

Para executar isso de forma não interativa, use esta linha de comando: ./GenerateDatasetsXml.sh EDDTableFromAsciiFiles /u00/data/ .\*\.asc /u00/data/sampleFile.asc ISO-8859-1 Basicamente, lista todas as respostas na linha de comando. Isso deve ser útil para conjuntos de dados que mudam com freqüência de uma forma que exige a reinicialização de GerarDatasets Xml (notadamente EDDGrid A partir de três) .

Detalhes:

Se um parâmetro contém um espaço ou algum caractere especial, então codifique o parâmetro como um Corda de estilo JSON , por exemplo, "meu parâmetro com espaços e dois \n linhas".
Se você quiser especificar uma string vazia como parâmetro, use: nada
Se você quiser especificar o valor padrão de um parâmetro, use: default
Gerar conjuntos de dados Xml suporta um -i conjuntos de dados XmlName # Nome parâmetro linha de comando que insere a saída no especificado datasets.xml arquivo (o padrão é Toca a brincar. /conteúdo/erddap/ datasets.xml ) . Gerar conjuntos de dados Xml procura duas linhas em conjuntos de dados XmlName:

        <!-- Begin GenerateDatasetsXml #*tagName someDatetime* -->

        <!-- End GenerateDatasetsXml #*tagName someDatetime* -->

e substitui tudo entre essas linhas com o novo conteúdo, e muda o datado.

O interruptor -i só é processado (e mudanças datasets.xml são apenas feitos) se você executar GerarDatasets Xml com argumentos de linha de comando que especificam todas as respostas para todas as perguntas para um loop do programa. (Veja 'Scripting' acima.) (O pensamento é: Este parâmetro é para uso com scripts. Se você usar o programa no modo interativo (digitando informações no teclado) , é provável que você gere alguns pedaços incorretos de XML antes de gerar o que você quer.)
Se as linhas Iniciar e Final não forem encontradas, então essas linhas e o novo conteúdo são inseridos logo antes</erddapDatasets>.
Há também um -I (capital i) interruptor para fins de teste que funciona o mesmo que -i, mas cria um arquivo chamado datasets.xml Data de início e não faz mudanças para datasets.xml .
Não execute GenerateDatasets Xml com -i em dois processos ao mesmo tempo. Há uma chance de apenas um conjunto de mudanças será mantido. Pode haver sérios problemas (por exemplo, arquivos corrompidos) .

Se você usar "GenerateDatasetsXml -verbose", ele imprimirá mais mensagens diagnósticas do que o habitual.

Tipos Especiais/Pseudo Dataset

Em geral, as opções EDDType em GerarDatasets Combinação Xml dos tipos EDD descritos neste documento (ver o Lista de Tipos de Conjunto de Dados ) e gerar um datasets.xml chunk para criar um conjunto de dados de uma fonte de dados específica. Existem algumas exceções e casos especiais:

EDDGrid De Erddap

Este EDDType gera todo o datasets.xml chunks necessário para fazer EDDGrid De Erddap conjuntos de dados de todos os EDDGrid datasets em um remoto ERDDAP . Você terá a opção de manter o original datasetID S (que pode duplicar alguns datasetID já está em seu ERDDAP ) ou gerar novos nomes que serão únicos (mas geralmente não são tão legíveis como humanos) .

EDDTable FromErddap

Este EDDType gera todo o datasets.xml chunks necessário para fazer EDDTable FromErddap datasets de todos os conjuntos de dados EDDTable em um remoto ERDDAP . Você terá a opção de manter o original datasetID S (que pode duplicar alguns datasetID já está em seu ERDDAP ) ou gerar novos nomes que serão únicos (mas geralmente não são tão legíveis como humanos) .

EDDGrid A partir de três

Este EDDType gera todo o datasets.xml pedaços necessários para todos os EDDGrid A partir de conjuntos de dados que ele pode encontrar rastejando recursivamente através de um THREDDS (Subscrição) catálogo. Existem muitas formas de URLs de catálogo THREDDS. Esta opção REQUIRES um URL THREDDS .xml com /catalog/ nele, por exemplo, https://oceanwatch.pfeg.noaa.gov/thredds/catalog/catalog.xmlou https://oceanwatch.pfeg.noaa.gov/thredds/catalog/Satellite/aggregsatMH/chla/catalog.xml
(um catálogo .html relacionado está em https://oceanwatch.pfeg.noaa.gov/thredds/Satellite/aggregsatMH/chla/catalog.html, que não é aceitável para EDDGrid FromThreddsCatalog (em inglês). Se você tiver problemas com EDDGrid De Thredds Catálogo:

Certifique-se de que a URL que você está usando é válida, inclui /catalog/, e termina com /catalog.xml .
Se possível, use um endereço IP público (por exemplo,https://oceanwatch.pfeg.noaa.gov) na URL, não um endereço IP numérico local (por exemplo,https://12.34.56.78) . Se o THREDDS for apenas acessível através do endereço IP numérico local, você pode usar [<convertToPublicSourceUrl>] (# Convert to publicsourceurl) Então... ERDDAP™ os usuários veem o endereço público, embora ERDDAP™ recebe dados do endereço numérico local.
Se você tem problemas que você não pode resolver, verificar as dicas de solução de problemas .
O código de baixo nível para isso agora usa o Unidata netcdf-java catálogo rastreador código (Thredds. aulas de catálogo) para que possa lidar com todos os catálogos THREDDS (que pode ser surpreendentemente complexo) Graças a Unidata para esse código.

EDDGrid LonPM180 De ErddapCatalog

Este EDDType gera o datasets.xml para fazer EDDGrid LonPM180 conjuntos de dados de todos os EDDGrid conjuntos de dados em um ERDDAP que têm valores de longitude maiores que 180.

Se possível, use um endereço IP público (por exemplo,https://oceanwatch.pfeg.noaa.gov) na URL, não um endereço IP numérico local (por exemplo,https://12.34.56.78) . Se o ERDDAP™ é apenas acessível através do endereço IP numérico local, você pode usar [<convertToPublicSourceUrl>] (# Convert to publicsourceurl) Então... ERDDAP™ os usuários veem o endereço público, embora ERDDAP™ recebe dados do endereço numérico local.

EDDGrid Lon0360 De ErddapCatalog

Este EDDType gera o datasets.xml para fazer EDDGrid Lon0360 conjuntos de dados de todos os EDDGrid conjuntos de dados em um ERDDAP que têm valores de longitude menos de 0.

Se possível, use um endereço IP público (por exemplo,https://oceanwatch.pfeg.noaa.gov) na URL, não um endereço IP numérico local (por exemplo,https://12.34.56.78) . Se o ERDDAP™ é apenas acessível através do endereço IP numérico local, você pode usar [<convertToPublicSourceUrl>] (# Convert to publicsourceurl) Então... ERDDAP™ os usuários veem o endereço público, embora ERDDAP™ recebe dados do endereço numérico local.

EDDs De Ficheiros

Dado um diretório de início, isso atravessa o diretório e todos os subdiretórios e tenta criar um conjunto de dados para cada grupo de arquivos de dados que ele encontra.

Isso pressupõe que quando um conjunto de dados é encontrado, o conjunto de dados inclui todos os subdiretórios.
Se um conjunto de dados for encontrado, diretórios de irmãos semelhantes serão tratados como conjuntos de dados separados (por exemplo, diretórios para os anos 90, os anos 2000, os anos 2010, gerarão conjuntos de dados separados) . Eles devem ser fáceis de combinar à mão - basta alterar o primeiro conjunto de dados<fileDir> para o diretório pai e excluir todos os conjuntos de dados de irmãos subsequentes.
Isso só vai tentar gerar um pedaço de datasets.xml para o tipo mais comum de extensão de arquivo em um diretório (não contando .md5, que é ignorado) . Então, dado um diretório com 10 .nc arquivos e arquivos 5.txt, um conjunto de dados será gerado para o .nc arquivos apenas.
Isso pressupõe que todos os arquivos em um diretório com a mesma extensão pertencem ao mesmo conjunto de dados. Se um diretório tiver alguns .nc arquivos com dados SST e alguns .nc arquivos com dados de clorofila, apenas uma amostra .nc arquivo será lido (SST? clorofila?) e apenas um conjunto de dados será criado para esse tipo de arquivo. Esse conjunto de dados provavelmente não será carregado por causa de complicações de tentar carregar dois tipos de arquivos no mesmo conjunto de dados.
Se houver menos de 4 arquivos com a extensão mais comum em um diretório, isso assume que eles não são arquivos de dados e apenas pula o diretório.
Se houver 4 ou mais arquivos em um diretório, mas isso não pode gerar com sucesso um pedaço de datasets.xml para os arquivos (por exemplo, um tipo de arquivo não suportado) , isto vai gerar um EDDTable De Nomes de Arquivo dataset para os arquivos.
No final dos diagnósticos que isso escreve para o arquivo de log, pouco antes do datasets.xml chunks, isso imprimirá uma tabela com um resumo de informações recolhidas atravessando todos os subdiretórios. A tabela irá listar cada subdiretório e indicar o tipo mais comum de extensão de arquivo, o número total de arquivos, e que tipo de conjunto de dados foi criado para esses arquivos (se houver) . Se você é confrontado com uma estrutura de arquivo complexa, profundamente aninhada, considere executar GerrateDatasets Xml com EDDType=EDDsFromFiles apenas para gerar esta informação,
Esta opção pode não fazer um grande trabalho de adivinhar o melhor EDDType para um determinado grupo de arquivos de dados, mas é rápido, fácil e vale a pena tentar. Se os arquivos de origem são adequados, ele funciona bem e é um bom primeiro passo na geração do datasets.xml para um sistema de arquivos com lotes de subdiretórios, cada um com arquivos de dados de diferentes conjuntos de dados.

EDDTable FromEML e EDDTable FromEMLBatch

Estes EDDType especial gera o datasets.xml para fazer um EDDTable FromAsciiFiles dataset de cada uma das tabelas descritas em um Idioma de Metadados Ecológicos Arquivo XML. A variante "Batch" funciona em todos os arquivos EML em um diretório local ou remoto. Por favor, veja o separado documentação para EDDTableFromEML .

EDDTable FromInPort

Este EDDType especial gera o datasets.xml para fazer um EDDTable FromAsciiFiles dataset da informação em um inport-xml ficheiro. Se você pode obter acesso ao arquivo de dados de origem (o arquivo inport-xml deve ter pistas para onde encontrá-lo) , você pode fazer um conjunto de dados de trabalho ERDDAP .

Os seguintes passos descrevem como usar GerarDatasets Xml com um arquivo inport-xml para obter um conjunto de dados de trabalho em ERDDAP .

Uma vez que você tenha acesso ao arquivo inport-xml (ou como uma URL ou um arquivo local) : executar GerarDatasets Xml, especifique EDDType=EDDTableFromInPort, especifique o URL inport-xml ou nome de arquivo completo, especifique qualChild=0, e especifique as outras informações solicitadas (se sabe) . (Neste ponto, você não precisa ter o arquivo de dados de origem ou especificar seu nome.) A configuração queChild=0 diz GerarDatasets Xml para escrever as informações para Todos do<entidade-atributo-informação><entidade> está no arquivo inport-xml (se houver algum) . Ele também imprime um resumo de informações de fundo, incluindo todos os listados no arquivo inport-xml.
Olhe através de toda a informação (incluindo as informações de fundo que GeramDatasets Impressões de Xml) e visite o download de (S) para tentar encontrar o arquivo de dados de origem (S) . Se você puder encontrá-lo (eles) , baixar o (eles) em um diretório acessível ERDDAP . (Se você não consegue encontrar nenhum arquivo de dados de origem, não há nenhum ponto no processo.)
Executar Geração Conjuntos de dados Xml outra vez. Se o arquivo de dados de origem corresponder a um dos arquivos inport-xml<entidade-atributo-informação><entidade>'s, especifique qualChild= Que a Entidade é Entidade (Por exemplo, 1, 2, 3, ...) . ERDDAP™ tentará combinar os nomes das colunas no arquivo de dados de origem para nomes nas informações da entidade e solicitará aceitar/rejeitar/fixar quaisquer discrepâncias. Ou, se o arquivo inport-xml não tiver nenhum<entidade-atributo-informação><entidade>'s, especifique qualChild=0.
No pedaço de datasets.xml que foi feito por GenerateDatasets Xml, revise o [global< addAttributes > (Atributos globais) como necessário / desejado.
No pedaço de datasets.xml que foi feito por GenerateDatasetsXml, adicione/revise o [< dataVariable > (#datavariable) informação conforme necessário/desejado para descrever cada uma das variáveis. Certifique-se de identificar adequadamente cada variável Não.< sourceName > (Nome de fonte) (como aparece na fonte) , Não.< destinationName > (Nome de destino) (que tem mais limitações em caracteres permitidos do que sourceName ) , Não.<Unidades> (#units) (especialmente se for um variável time ou timestamp onde as unidades precisam especificar o formato) e Não.< missing\_value > (#missing_value) ,
Quando você está perto de terminar, use repetidamente o DasDds ferramenta para ver rapidamente se a descrição do conjunto de dados é válida e se o conjunto de dados aparecer ERDDAP™ como queiras.

Seria ótimo se grupos usando o InPort para documentar seus conjuntos de dados também usarem ERDDAP™ para disponibilizar os dados reais:

ERDDAP™ é uma solução que pode ser usada agora para que você possa cumprir NOAA ' Acesso público aos resultados da pesquisa (PARR) requisitos Neste momento, não em algum momento vago no futuro.
ERDDAP™ torna os dados reais disponíveis para os usuários, não apenas os metadados. (O que é bom metadados sem dados?)
ERDDAP™ suporta metadados (notavelmente, as unidades de variáveis) , ao contrário de algum outro software de servidor de dados que está sendo considerado. (O que é bom os dados sem metadados?) Usar software que não suporta metadados é convidar os dados a serem mal interpretados e mal utilizados.
ERDDAP™ é software livre e de código aberto ao contrário de algum outro software que está sendo considerado. Desenvolvimento contínuo ERDDAP™ já está pago. Suporte para ERDDAP™ os usuários são livres.
ERDDAP A aparência pode ser facilmente personalizada para refletir e destacar seu grupo (não ERD ou ERDDAP ) .
ERDDAP™ oferece uma maneira consistente de acessar todos os conjuntos de dados.
ERDDAP™ pode ler dados de muitos tipos de arquivos de dados e de bancos de dados relacionais.
ERDDAP™ pode lidar com grandes conjuntos de dados, incluindo conjuntos de dados onde os dados de origem estão em muitos arquivos de dados.
ERDDAP™ pode escrever dados para muitos tipos de arquivos de dados, a pedido do usuário, incluindo tipos de arquivos de dados científicos como netCDF, ESRI .csv, e ODV .txt .
ERDDAP™ pode fazer gráficos personalizados e mapas de subconjuntos dos dados, com base nas especificações do usuário.
ERDDAP™ pode lidar com conjuntos de dados não-dados, como coleções de arquivos de imagem, vídeo ou áudio.
ERDDAP™ foi instalado e usado em mais de 60 instituições em todo o mundo .
ERDDAP™ é listado como um dos servidores de dados recomendados para uso dentro NOAA no NOAA Diretiva de Acesso aos Dados , ao contrário de algum outro software sendo considerado.
ERDDAP™ é um produto de NMFS / NOAA , então usá-lo dentro NMFS e NOAA deve ser um ponto de orgulho para NMFS e NOAA .

Por favor. ERDDAP™ uma tentativa. Se você precisar de ajuda, por favor publique uma mensagem no ERDDAP™ Grupo Google.

addFillValueAtributos

Esta opção especial EDDType não é um tipo de conjunto de dados. É uma ferramenta que pode adicionar atributos \_FillValue a algumas variáveis em alguns conjuntos de dados. Ver addFillValueAtributos .

encontrar Duplicado Tempo

Esta opção especial EDDType não é um tipo de conjunto de dados. Em vez disso, ele diz GerarDatasets Xml para pesquisar através de uma coleção de grade .nc (e relacionados) arquivos para encontrar e imprimir uma lista de arquivos com valores de tempo duplicados. Quando olha para os valores do tempo, converte-os das unidades originais para "seconds since 1970-01-01" no caso de arquivos diferentes usar diferentes cadeias de unidades. Você precisa fornecer o diretório inicial (com ou sem o barramento) , o nome do arquivo expressão regular (por exemplo, .\\ .nc ) , e o nome da variável de tempo nos arquivos.

Não.

Esta opção especial EDDType não é um tipo de conjunto de dados. Em vez disso, ele diz GerarDatasets Xml para imprimir um Não. impressão de um .nc , .nc ml, ou .hdf ficheiro. Ele realmente usa o netcdf-java's NCdump , que é uma ferramenta mais limitada do que a versão C do NCdump. Se você usar esta opção, GerarDatasetsXml irá pedir-lhe para usar uma das opções: "-h" (Cabeçalho) "C" (coordena vars) "vall" (padrão) , "-v var1;var2", "-v var1 (0,0:10,0:20) ". Isso é útil porque, sem ncdump é difícil saber o que está em um .nc , .nc ml, ou .hdf arquivo e, portanto, que EDDType você deve especificar para GerarDatasets Xml. Para um .nc arquivo ml, isso imprimirá a saída ncdump para o resultado do .nc alterações de arquivo ml aplicadas ao subjacente .nc ou .hdf ficheiro.

DasDds

DasDds é um programa de linha de comando que você pode usar depois de ter criado uma primeira tentativa no XML para um novo conjunto de dados datasets.xml . Com DasDds, você pode repetidamente testar e refinar o XML. Quando você usa o programa DasDds:

No Windows, a primeira vez que você executar DasDds, você precisa editar os DasDds. arquivo de morcego com um editor de texto para mudar o caminho para o java. exe arquivo para que o Windows possa encontrar Java .
DasDds pede para você datasetID para o conjunto de dados em que você está trabalhando.
DasDds tenta criar o conjunto de dados com isso datasetID .
- DasDds sempre imprime muitas mensagens diagnósticas. Se você usar "DasDds -verbose", DasDds imprimirá mais mensagens diagnósticas do que o habitual.
- Para segurança, a DasDds sempre exclui todas as informações de conjunto de dados em cache (arquivos) para o conjunto de dados antes de tentar criar o conjunto de dados. Este é o equivalente a definir uma bandeira dura Assim, para conjuntos de dados agregados, você pode querer ajustar o arquivoNameRegex temporariamente para limitar o número de arquivos que o construtor de dados encontra.
- Se o conjunto de dados não carregar (por qualquer razão) , DasDds vai parar e mostrar-lhe a mensagem de erro para o primeiro erro que ele encontra. Não tente adivinhar qual é o problema. Leia a mensagem ERROR com cuidado.
  Se necessário, leia as mensagens diagnósticas anteriores para encontrar mais pistas e informações também.
- Faça uma mudança no XML do conjunto de dados para tentar resolver esse problema
  e deixe DasDds tentar criar o conjunto de dados novamente.
- Se você resolver repetidamente cada problema, você vai eventualmente resolver todos os problemas
  e o conjunto de dados irá carregar.
Todos os DasDds saída (diagnósticos e resultados) são escritos para a tela e para Diretriz de grande porte /logs/DasDds.log .
Se o DasDds pode criar o conjunto de dados, o DasDds irá mostrar-lhe o Não. (Estrutura de atributos de conjuntos de dados) , .dds (Descritor de Dados Estrutura) e .timeGaps (lacunas de tempo) informações para o conjunto de dados em sua tela escrevê-los para Diretriz de grande porte /logs/DasDds.out .
Muitas vezes, você vai querer fazer uma pequena mudança no XML do conjunto de dados para limpar os metadados do conjunto de dados e reprimir DasDds.

Bônus Ferramenta de terceiros: ERDDAP - Não.

ERDDAP -lint é um programa de Rob Fuller e Adam Leadbetter do Irish Marine Institute que você pode usar para melhorar os metadados de seu ERDDAP™ conjuntos de dados. ERDDAP -lint "contém regras e uma aplicação web estática simples para executar alguns testes de verificação contra o seu ERDDAP™ servidor. Todos os testes são executados no navegador da web." Como o Ferramenta de lint Unix/Linux, você pode editar as regras existentes ou adicionar novas regras. Ver ERDDAP - Não. para mais informações.

Esta ferramenta é especialmente útil para conjuntos de dados que você criou há algum tempo e agora quer trazer up-to-date com suas preferências atuais de metadados. Por exemplo, versões iniciais do GerrateDatasets Xml não fez nenhum esforço para criar global creator\_name , creator\_email , criador\_type, ou creator\_url metadados. Você pode usar ERDDAP -inclinar para identificar os conjuntos de dados que não possuem esses atributos de metadados.

Graças a Rob e Adam para criar esta ferramenta e torná-la disponível para o ERDDAP™ comunidade.

A estrutura básica do datasets.xml Arquivo

As tags necessárias e opcionais permitidas em um datasets.xml arquivo (e o número de vezes que podem aparecer) são mostrados abaixo. Na prática, o seu datasets.xml terá muitos<tags do dataset> e somente usar as outras tags dentro<erddapDatasets> conforme necessário.

<?xml version="1.0" encoding="ISO-8859-1" ?>
<erddapDatasets>
   <angularDegreeUnits>...</angularDegreeUnits> 
   <angularDegreeTrueUnits>...</angularDegreeTrueUnits> 
   <cacheMinutes>...</cacheMinutes> 
   <commonStandardNames>...</commonStandardNames> 
   <convertInterpolateRequestCSVExample /> 
   <convertInterpolateDatasetIDVariableList /> 
   <convertToPublicSourceUrl /> 
   <decompressedCacheMaxGB>...</decompressedCacheMaxGB> 
   <decompressedCacheMaxMinutesOld>...</decompressedCacheMaxMinutesOld> 
   <drawLandMask>...</drawLandMask> 
   <emailDiagnosticsToErdData>...</emailDiagnosticsToErdData> 
   <graphBackgroundColor>...</graphBackgroundColor> 
   <ipAddressMaxRequests>...</ipAddressMaxRequests> 
   <ipAddressMaxRequestsActive>...<ipAddressMaxRequestsActive> 
   <ipAddressUnlimited>...<ipAddressUnlimited> 
   <loadDatasetsMinMinutes>...</loadDatasetsMinMinutes> 
   <loadDatasetsMaxMinutes>...</loadDatasetsMaxMinutes> 
   <logLevel>...</logLevel> 
   <nGridThreads>...</nGridThreads> 
   <nTableThreads>...</nTableThreads> 
   <palettes>...</palettes> 
   <partialRequestMaxBytes>...</partialRequestMaxBytes> 
   <partialRequestMaxCells>...</partialRequestMaxCells> 
   <requestBlacklist>...</requestBlacklist> 
   <slowDownTroubleMillis>...</slowDownTroubleMillis> 
   <subscriptionEmailBlacklist>...</subscriptionEmailBlacklist> 
   <unusualActivity>...</unusualActivity> 
   <updateMaxEvents>...</updateMaxEvents> 

   <standardLicense>...</standardLicense> 
   <standardContact>...</standardContact> 
   <standardDataLicenses>...</standardDataLicenses> 
   <standardDisclaimerOfEndorsement>...</standardDisclaimerOfEndorsement> 
   <standardDisclaimerOfExternalLinks>...</standardDisclaimerOfExternalLinks> 
   <standardGeneralDisclaimer>...</standardGeneralDisclaimer> 
   <standardPrivacyPolicy>...</standardPrivacyPolicy> 
   <startHeadHtml5>...</startHeadHtml5> 
   <startBodyHtml5>...</startBodyHtml5> 
   <theShortDescriptionHtml>...</theShortDescriptionHtml> 
   <endBodyHtml5>...</endBodyHtml5> 

   <user username="..." password="..." roles="..." /> 

   <dataset>...</dataset> 
</erddapDatasets>

É possível que outras codificações sejam permitidas no futuro, mas por enquanto, somente ISO-8859-1 é recomendado.

XI.

Nova versão 2.25 é suporte para XInclude. Isso requer que você esteja usando o analisador SAX<useSaxParser>true</useSaxParser> em seu setup.xml. Isso pode permitir que você escreva cada conjunto de dados em seu próprio arquivo, em seguida, incluí-los todos no principal datasets.xml , reutilizar partes de definições de conjuntos de dados, ou ambos. Se você quiser ver um exemplo, EDDTestDataset.java define o XInclude para reutilizar definições variáveis.

- Não.

Notas

Trabalhar com o datasets.xml arquivo é um projeto não trivial. Por favor, leia todas essas notas cuidadosamente. Depois de escolher um tipo de conjunto de dados , por favor, leia a descrição detalhada dele cuidadosamente.

Escolhendo o Tipo de Conjunto de Dados

Na maioria dos casos, há apenas um ERDDAP™ tipo de dataset que é apropriado para uma determinada fonte de dados. Em alguns casos (por exemplo, .nc arquivos) , há algumas possibilidades, mas geralmente um deles é definitivamente melhor. A primeira e maior decisão que você deve tomar é: é apropriado tratar o conjunto de dados como um grupo de arrays multidimensionais (se assim vir o EDDGrid tipos de conjuntos de dados ) ou como uma tabela de dados semelhante a banco de dados (se assim vir o Tipos de conjunto de dados EDDTable ) .

Servindo os dados como é

Normalmente, não há necessidade de modificar a fonte de dados (por exemplo, converter os arquivos para algum outro tipo de arquivo) assim ERDDAP™ pode servir. Uma das suposições de ERDDAP™ é que a fonte de dados será usada como é. Normalmente isto funciona bem. Algumas exceções são:

Bases de Dados Relacionais e Cassandra - ... ERDDAP™ pode servir dados diretamente de bases de dados relacionais e Cassandra. Mas para problemas de segurança, balanceamento de carga e desempenho, você pode optar por configurar outro banco de dados com os mesmos dados ou salvar os dados para NetCDF v3 .nc arquivos e têm ERDDAP™ servir os dados da nova fonte de dados. Ver EDDTable FromDatabase e EDDTable FromCasandra .
Não suportado fontes de dados -- ERDDAP™ pode suportar um grande número de tipos de fontes de dados, mas o mundo está cheio de 1000 (milhões?) de diferentes fontes de dados (notavelmente, estruturas de arquivos de dados) . Se ERDDAP™ não suporta sua fonte de dados:
- Se a fonte de dados for NetCDF .nc arquivos, você pode usar NcML para modificar os arquivos de dados on-the-fly, ou usar NCO para modificar permanentemente os arquivos de dados.
- Você pode escrever os dados para um tipo de fonte de dados que ERDDAP™ suportes. NetCDF -3 .nc arquivos são uma boa, recomendação geral porque eles são arquivos binários que ERDDAP™ pode ler muito rapidamente. Para dados tabulares, considere armazenar os dados em uma coleção de .nc arquivos que usam CF Geometrias de amostragem discretas (DSG) Estruturas de dados Ragged Array contíguas e assim pode ser tratada com ERDDAP ' EDDTable FromNcCFFiles ). Se eles são logicamente organizados (cada um com dados para um pedaço de espaço e tempo) , ERDDAP™ pode extrair dados deles muito rapidamente.
- Você pode solicitar que o suporte para essa fonte de dados seja adicionado ERDDAP™ enviando um e-mail para Chris. John no noaaa.gov.
- Você pode adicionar suporte para essa fonte de dados escrevendo o código para lidar com ele mesmo. Ver o ERDDAP™ Guia do programador
Velocidade... ERDDAP™ pode ler dados de algumas fontes de dados muito mais rápido do que outros. Por exemplo, leitura NetCDF v3 .nc arquivos é rápido e ler arquivos ASCII é mais lento. E se houver um grande (> 1000) ou enorme (> 100 000) número de arquivos de dados de origem, ERDDAP™ responderá a alguns pedidos de dados lentamente. Normalmente, a diferença não é perceptível para os seres humanos. No entanto, se você pensar ERDDAP™ é lento para um determinado conjunto de dados, você pode optar por resolver o problema, escrevendo os dados para uma configuração mais eficiente (geralmente: alguns, bem estruturados, NetCDF v3 .nc arquivos) . Para dados tabulares, consulte este conselho .

Olá.

Muitas vezes é mais fácil gerar o XML para um conjunto de dados, fazendo uma cópia de uma descrição de conjunto de dados de trabalho em dataset.xml e, em seguida, modificá-lo.

Codificação de caracteres especiais

Desde então datasets.xml é um arquivo XML, você MUST & nbsp; "&", "<", and ">" in any content as "&", "<«, and ">» (em inglês). Errado:<Título Tempo e marés<- Sim. Certo.<Título Tempo & Tides<- Sim.

XML não tolera erros de sintaxe

Depois de editar o arquivo dataset.xml, é uma boa ideia verificar se o resultado é XML bem formado colando o texto XML em um verificador XML como xmlvalidação .

Dicas de resolução de problemas

Outras formas de diagnosticar problemas com conjuntos de dados
Além dos dois principais Ferramentas ,
- Não. é um arquivo de log com todos ERDDAP As mensagens de diagnóstico.
O Relatório diário tem mais informações do que a página de status, incluindo uma lista de conjuntos de dados que não carregaram e as exceções (erros) eles geraram.
O Página de status é uma maneira rápida de verificar ERDDAP 's status de qualquer navegador web. Inclui uma lista de conjuntos de dados que não carregaram (embora não as exceções relacionadas) e tarefaTermos estatísticas (mostrar o progresso de EDDGrid Entendido. e EDDTableCopy conjuntos de dados e qualquer EDDGrid Dos quartos ou Tabela EDD dos arquivos conjuntos de dados que usam Cache De Url (mas não cache Tamanho GB) ) .
Se ficares preso, vê o nosso seção sobre como obter suporte adicional .

Variáveis especiais

** A longitude, latitude, altitude, profundidade, pressão e tempo (LLAT) variável destinationName s são especiais.**
Em geral:
- As variáveis LLAT são conhecidas por ERDDAP™ se a variável eixo (para EDDGrid conjuntos de dados) ou variável de dados (para conjuntos de dados EDDTable) destinationName é "longitude", "latitude", "altitude", "profundidade", ou "time" .
- Encorajamos fortemente você a usar esses nomes padrão para essas variáveis sempre que possível. Nenhum deles é necessário. Se você não usar esses nomes variáveis especiais, ERDDAP™ Não reconhecerá o seu significado. Por exemplo, as variáveis LLAT são tratadas especialmente por Make A Graph ( * datasetID * .) : se a variável X Axis for "longitude" e a variável Y Axis for "latitude", você terá um mapa (usando uma projeção padrão, e com uma máscara de terra, limites políticos, etc.) em vez de um gráfico.
- ERDDAP™ adicionará automaticamente lotes de metadados para variáveis LLAT (por exemplo, " ioos\_category ", unidades ", e vários atributos relacionados a padrões como "\_CoordinateAxisType") .
- ERDDAP™ automaticamente, on-the-fly, adicionar lotes de metadados globais relacionados aos valores LLAT do subconjunto de dados selecionado (por exemplo, "geospatial\_lon\_min") .
- Os clientes que suportam esses padrões de metadados poderão aproveitar os metadados adicionados para posicionar os dados no tempo e no espaço.
- Os clientes acharão mais fácil gerar consultas que incluam variáveis LLAT porque os nomes da variável são os mesmos em todos os conjuntos de dados relevantes.
Para a variável "longitude" e a variável "latitude":
- Use o destinationName s "longitude" e "latitude" somente se o unidades são graus\_east e graus\_north, respectivamente. Se seus dados não atenderem a esses requisitos, use diferentes nomes de variáveis (por exemplo, x, y, lonRadians, latRadians) .
- Se você tiver dados de longitude e latitude expressos em diferentes unidades e assim com diferentes destinationName s, por exemplo, lonRadians e latRadians, Faça um gráfico ( * datasetID * .) fará gráficos (por exemplo, série de tempo) em vez de mapas.
Para a variável "altitude", "presure", ou "depth":
- Use o destinationName "altitude" para identificar a distância dos dados acima do nível do mar (valores positivos="up") . Opcionalmente, você pode usar "altitude" para distâncias abaixo do nível do mar se os valores forem negativos abaixo do mar (ou se você usar, por exemplo, Não.<Nome do anúncio scale\_factor " type="int">- 1</att> (#scale_factor) converter valores de profundidade em valores de altitude.
- Use o destinationName "profundidade" para identificar a distância dos dados abaixo do nível do mar (valores positivos="down") .
- Alternativamente, para elevações definidas pelos níveis de pressão do ar (como Isosbars ) , você deve definir o destinationName para "pressão". Isso suporta unidades em "hPa", "Pa", e "mbar" (valores positivos="down") .
- Um conjunto de dados pode ter apenas uma variável "altitude", "pressão", ou "profundidade".
- Para essas variáveis "altitude" e "profundidade", o unidades deve ser "m", "meter", ou "meters". Se as unidades diferentes (por exemplo,) , você pode usar Não.<Nome do anúncio scale\_factor " alguns Valor </att> (#scale_factor) E...<att name="units">meters</att> (#units) converter as unidades em metros.
- Se seus dados não atenderem a esses requisitos, use um diferente destinationName (por exemplo, acimaGround, distância Toque no peito) .
- Se você sabe o CRS vertical, especifique-o nos metadados, por exemplo, "EPSG:5829" (altura instantânea acima do nível do mar) , "EPSG:5831" (profundidade instantânea abaixo do nível do mar) , ou "EPSG:5703" (NAVD88 altura) .
Pelo "time" variável:
- Use o destinationName "time" somente para variáveis que incluam toda a data+hora (ou data, se é tudo o que há) . Se, por exemplo, houver colunas separadas para data e horaOfDay, não use o nome variável "time" .
- Ver unidades para mais informações sobre as unidades atributo por tempo e variáveis timeStamp.
- A variável de tempo e relacionada Tempo Variáveis do carimbo são únicos em que eles sempre convertem valores de dados do formato de hora da fonte (o que quer que seja) em um valor numérico (segundos desde 1970-01-01T00:00:00Z) ou um valor de string (ISO 8601:2004 (E) formato) , dependendo da situação.
- Quando um usuário solicita dados de tempo, eles podem solicitá-lo especificando o tempo como um valor numérico (segundos desde 1970-01-01T00:00:00Z) ou um valor de string (ISO 8601:2004 (E) formato) .
- ERDDAP™ tem um utilitário para Converter um numérico Tempo para / de um tempo de corda .
- Ver Como? ERDDAP Lidas com o tempo .

Por que apenas duas estruturas básicas de dados?

Uma vez que é difícil para clientes humanos e clientes de computador lidar com um conjunto complexo de possíveis estruturas de conjuntos de dados, ERDDAP™ usa apenas duas estruturas básicas de dados:
- um estrutura de dados gradeada (por exemplo, para dados de satélite e dados de modelo) e
- um estrutura de dados tabular (por exemplo, para dados no local, estação e trajetória) .
Certamente, nem todos os dados podem ser expressos nessas estruturas, mas muito dele pode. Os quadros, em especial, são estruturas de dados muito flexíveis (olhar para o sucesso de programas de banco de dados relacional) .
Isso torna as consultas de dados mais fáceis de construir.
Isso faz com que as respostas de dados tenham uma estrutura simples, o que torna mais fácil atender os dados em uma variedade mais ampla de tipos de arquivos padrão (que muitas vezes apenas suportam estruturas de dados simples) . Esta é a principal razão pela qual montamos ERDDAP™ Por aqui.
Isto, por sua vez, torna muito fácil para nós (ou qualquer pessoa) para escrever software cliente que funciona com tudo ERDDAP™ conjuntos de dados.
Isso torna mais fácil comparar dados de diferentes fontes.
Estamos muito cientes de que, se você estiver acostumado a trabalhar com dados em outras estruturas de dados, você pode inicialmente pensar que essa abordagem é simplista ou insuficiente. Mas todas as estruturas de dados têm negociações. Nenhuma é perfeita. Mesmo as estruturas do-it-all têm suas desvantagens: trabalhar com eles é complexo e os arquivos só podem ser escritos ou lidos com bibliotecas de software especiais. Se aceitar ERDDAP 's abordagem suficiente para tentar trabalhar com ele, você pode descobrir que tem suas vantagens (notavelmente o suporte para vários tipos de arquivos que podem segurar as respostas de dados) . O ERDDAP™ apresentação de slides (em especial estruturas de dados slide ) fala muito sobre esses problemas.
E mesmo que esta abordagem pareça estranha para você, a maioria ERDDAP™ clientes nunca vai notar -- eles vão simplesmente ver que todos os conjuntos de dados têm uma estrutura simples agradável e eles serão gratos que eles podem obter dados de uma grande variedade de fontes retornadas em uma ampla variedade de formatos de arquivo.

Dimensões

E se as variáveis de grade no conjunto de dados de origem não compartilham as mesmas variáveis de eixo?
Em EDDGrid datasets, todas as variáveis de dados (Compartilhar) todas as variáveis do eixo. Então, se um conjunto de dados de origem tiver algumas variáveis com um conjunto de dimensões e outras variáveis com um conjunto diferente de dimensões, você terá que fazer dois conjuntos de dados em ERDDAP . Por exemplo, você pode fazer um ERDDAP™ dataset intitulado "Algumas Título (na superfície) " para manter variáveis que apenas usam \[ Tempo \] \[ latitude \] \[ longitude \] dimensões e fazer outro ERDDAP™ dataset intitulado "Algumas Título (em profundidades) " para manter as variáveis que usam \[ Tempo \] \[ altitude \] \[ latitude \] \[ longitude \] . Ou talvez você possa alterar a fonte de dados para adicionar uma dimensão com um único valor (por exemplo, altitude=0) para tornar as variáveis consistentes.

ERDDAP™ não lida com conjuntos de dados mais complicados (por exemplo, modelos que usam uma malha de triângulos) Bem. Você pode servir esses conjuntos de dados em ERDDAP™ criando dois ou mais conjuntos de dados ERDDAP™ (para que todas as variáveis de dados em cada novo conjunto de dados compartilhem o mesmo conjunto de variáveis de eixo) , mas não é isso que os usuários querem. Para alguns conjuntos de dados, você pode considerar fazer uma versão regular do conjunto de dados e oferecer isso além dos dados originais. Alguns software cliente só pode lidar com uma grade regular, por isso, fazendo isso, você atinge clientes adicionais.

Dados de grade projetados

Alguns dados gradeados têm uma estrutura complexa. Por exemplo, nível de satélite 2 ("uma longa faixa") os dados não usam uma projeção simples. Modelos (e outros) muitas vezes trabalham com dados gradeados em várias projeções não cilíndricas (por exemplo, conic, polar stereographic, tripolar) ou em redes não estruturadas (uma estrutura de dados mais complexa) . Alguns usuários finais querem esses dados como é, então não há perda de informações. Para esses clientes, ERDDAP™ pode servir os dados, como é, apenas se o ERDDAP™ administrador quebra o conjunto de dados original em alguns conjuntos de dados, com cada parte incluindo variáveis que compartilham as mesmas variáveis de eixo. Sim, isso parece estranho para as pessoas envolvidas e é diferente da maioria OPeNDAP servidores. Mas... ERDDAP™ enfatiza tornar os dados disponíveis em muitos formatos. Isso é possível porque ERDDAP™ usa/requer uma estrutura de dados mais uniforme. Embora seja um pouco estranho (ou seja, diferente do esperado) , ERDDAP™ pode distribuir os dados projetados.

\[ Sim. ERDDAP™ poderia ter requisitos mais soltos para a estrutura de dados, mas manter os requisitos para os formatos de saída. Mas isso levaria à confusão entre muitos usuários, particularmente novatos, já que muitos pedidos aparentemente válidos para dados com diferentes estruturas seriam inválidos porque os dados não se encaixariam no tipo de arquivo. Continuamos a voltar ao design do sistema atual. \]

Alguns usuários finais querem dados em uma projeção cilíndrica lat lon como Equirectangular / carrée de placa ou Mercator) para facilitar-de-uso em diferentes situações. Para estas situações, encorajamos o ERDDAP™ administrador para usar algum outro software ( NCO ? Matlab ? R? IDV? ...?) para re-projetar os dados em uma geografia (Equirectangular projeção/placa carrée) ou outra projeção cilíndrica e servir essa forma dos dados em ERDDAP™ como um conjunto de dados diferente. Isso é semelhante ao que as pessoas fazem quando convertem dados de nível de satélite 2 em dados de nível 3. Uma dessas ferramentas é NCO que oferece opções de extensão para dados de reciclagem.

GIS e dados de reprojeção

Uma vez que o mundo do GIS é muitas vezes orientada para o mapa, os programas do GIS geralmente oferecem suporte para reprojetar os dados, ou seja, traçar os dados em um mapa com uma projeção diferente.

Atualmente, ERDDAP™ não tem ferramentas para reprojetar dados. Em vez disso, recomendamos que você use uma ferramenta externa para fazer uma variante do conjunto de dados, onde os dados foram reprojetados de sua forma original em um retangular (longitude de latitude) array adequado para ERDDAP .

Em nossa opinião, o CF/ DAP O mundo é um pouco diferente do mundo do GIS e funciona a um nível ligeiramente inferior. ERDDAP™ reflete isso. Em geral, ERDDAP™ é projetado para trabalhar principalmente com dados (não mapas) e não quer mudar (por exemplo, reprojeto) esses dados. Para ERDDAP™ , dados gradeados é frequentemente / geralmente / preferencialmente associado com valores de lon lat e uma projeção cilíndrica, e não os valores x,y de alguma projeção. Em qualquer caso, ERDDAP™ não faz nada com a projeção dos dados; apenas passa os dados através, como é, com sua projeção atual, sobre a teoria de que uma reprojeção é uma mudança significativa para os dados e ERDDAP™ não quer estar envolvido com mudanças significativas. Além disso, os usuários subsequentes podem reprojetar ingênuamente os dados novamente, o que não seria tão bom como apenas fazer uma reprojeção. (Então, se o ERDDAP™ administrador quer oferecer os dados em uma projeção diferente, multa; basta reprojetar os dados off-line e oferecer que como um conjunto de dados diferente em ERDDAP . Muitos conjuntos de dados baseados em satélite são oferecidos como o que a NASA chama Nível 2 (Natação) e como Nível 3 (Projeção equirectar) versões.) Quando ERDDAP™ faz mapas (diretamente ou via WMS ou KML) , ERDDAP™ atualmente só oferece para fazer mapas com a projeção de carrée Equirectangular / placa que, felizmente, é aceito pela maioria dos programas de mapeamento.

Nós encorajamos ERDDAP™ administradores para usar algum outro software ( NCO ? Matlab ? R? IDV? ...?) para re-projetar os dados em uma geografia (Equirectangular projeção/placa carrée) ou outra projeção cilíndrica e servir essa forma dos dados em ERDDAP™ como um conjunto de dados diferente. Isso é semelhante ao que as pessoas fazem quando convertem dados de nível de satélite 2 em dados de nível 3. Uma dessas ferramentas é NCO que oferece opções de extensão para dados de reciclagem.

Esperamos que ERDDAP™ terá ferramentas embutidas para oferecer mapas com outras projeções no futuro. Também esperamos ter melhores conexões com o mundo do GIS no futuro (diferente da corrente WMS serviço) . É terrível que neste mundo "moderno" as ligações entre a CF/ DAP O mundo e o mundo do SIG ainda são tão fracos. Ambas as coisas estão na lista Para Fazer. (Se você quiser ajudar, notavelmente com a conexão ERDDAP™ para MapServer, por favor envie um e-mail para Chris. John em noaaa.gov .)

Tipos de dados

ERDDAP™ suporta os seguintes tipos de dados (os nomes são sensíveis a casos; 'u' prefixo significa "não assinado"; o número muitos dos nomes em outros sistemas é o número de bits) :

bytes

bytes assinou valores inteiros com um intervalo de -128 a 127. Em outros sistemas, isso às vezes é chamado de int8. Isso é chamado de "tinyint" por SQL e Cassandra. ERDDAP™ converte booleano de algumas fontes (por exemplo, SQL e Cassandra) em bytes em ERDDAP™ com um valor de 0=false, 1=true, e 127= missing\_value .

O que é?

O que é? tem valores inteiros não assinados com um intervalo de 0 a 255. Em outros sistemas, isso às vezes é chamado de uint8.

curto

curto assinou valores inteiros com um intervalo de -32768 a 32767. Em outros sistemas, isso é às vezes chamado int16. Isso é chamado de "smallint" por SQL e Cassandra.

- Não.

- Não. tem valores inteiros não assinados com um intervalo de 0 a 65535. Em outros sistemas, isso é às vezes chamado de uint16.

- Não.

- Não. assinou valores inteiros com um intervalo de -2147483648 para 2147483647. Em outros sistemas, isso é às vezes chamado int32. Isto chama-se "integer" | numérico (?) " por SQL e "int" por Cassandra.

*

***** tem valores inteiros não assinados com um intervalo de 0 a 4294967295. Em outros sistemas, isso às vezes é chamado de uint32.

longo

longo assinou valores inteiros com uma gama de -9223372036854775808 a 9223372036854775807. Em outros sistemas, isso às vezes é chamado de int64. Isto chama-se "bigint | numérico (?) " por SQL e "bigint" por Cassandra. Como muitos tipos de arquivos não suportam dados longos, seu uso é desencorajado. Quando possível, use o dobro em vez (ver abaixo) .

ulongo

ulongo tem valores inteiros não assinados com um intervalo de 0 a 18446744073709551615 Em outros sistemas, isso é às vezes chamado de uint64. Como muitos tipos de arquivos não suportam dados longos, seu uso é desencorajado. Quando possível, use o dobro em vez (ver abaixo) .

flutuar

flutuar é um flutuador IEEE 754 com uma gama de aproximadamente +/- 3.402823466e+38. Em outros sistemas, isso às vezes é chamado de float32. Isto chama-se "real | flutuar (?) | decimal (?) | numérico (?) " por SQL e "float" por Cassandra. O valor especial NaN significa não-um-Number. ERDDAP™ converte valores de infinito positivos e negativos para NaN.

duplo

duplo é um IEEE 754 duplo com uma gama de aproximadamente +/- 1.7976931348623157E+308. Em outros sistemas, isso é às vezes chamado float64. Isto é chamado de "precisão dupla | flutuar (?) | decimal (?) | numérico (?) " por SQL e "double" por Cassandra. O valor especial NaN significa não-um-Number. ERDDAP™ converte valores de infinito positivos e negativos para NaN.

Charlie.

Charlie. é um único, 2-byte (16 bits) Característica Unicode UCS-2 variando de \u0000 (#) através de \uffff (#65535) . \uffff A definição é não-um-Character, análoga a um valor duplo de NaN. O uso de char é desencorajado porque muitos tipos de arquivo não suportam chars ou apenas suportam 1-byte chars (ver abaixo) . Considere usar String em vez disso. Os usuários podem usar variáveis de carvão para fazer gráficos. ERDDAP™ converterá os caracteres em seu número de ponto de código Unicode, que pode ser usado como dados numéricos.

String

String é uma sequência de 0 ou mais, 2-byte (16 bits) Unicode UCS-2 caracteres . ERDDAP™ usa/interpreta uma string de 0 comprimento como um valor ausente. ERDDAP™ não suporta uma verdadeira cadeia nula. O comprimento de corda máxima teórica é 2147483647 caracteres, mas há provavelmente vários problemas em vários lugares, mesmo com Strings um pouco mais curtos. Uso ERDDAP 's String for SQL's character, varchar, caractere variando, binário, varbinário, intervalo, array, multiset, xml, e qualquer outro tipo de dados de banco de dados que não se encaixa de forma limpa com qualquer outro ERDDAP™ tipo de dados. Uso ERDDAP "S String for Cassandra" e qualquer outro tipo de dados Cassandra que não se encaixa de forma limpa com qualquer outro ERDDAP™ tipo de dados.

Antes ERDDAP™ v2.10, ERDDAP™ não apoiou tipos inteiros não assinados internamente e ofereceu suporte limitado em seus leitores de dados e escritores.

Limitações do tipo de dados

Você pode pensar em ERDDAP™ como um sistema que tem conjuntos de dados virtuais, e que funciona lendo dados de uma fonte de dados em um modelo de dados interno e escrevendo dados para vários serviços (por exemplo,(OPeN)DAP, WMS ) e tipos de arquivo em resposta às solicitações do usuário.

Cada leitor de entrada suporta um subconjunto dos tipos de dados que ERDDAP™ suportes. Então, ler dados em ERDDAP As estruturas de dados internas não são um problema.
Cada escritor de saída também suporta um subconjunto de tipos de dados. Isso é um problema porque ERDDAP tem que apertar, por exemplo, dados longos em tipos de arquivos que não suportam dados longos.

Abaixo estão explicações das limitações (ou nenhum) de vários escritores de saída e como ERDDAP™ lida com os problemas. Tais complicações são uma parte inerente de ERDDAP O objetivo de fazer sistemas diferentes interoperáveis.

ASCII

ASCII (.csv, .tsv , etc.) arquivos de texto -
- Todos os dados numéricos são escritos através da sua representação String (com valores de dados ausentes aparecendo como strings de 0 comprimento) .
- Embora ERDDAP™ escreve valores longos e longos corretamente para arquivos de texto ASCII, muitos leitores (por exemplo, programas de planilha) não pode lidar corretamente com valores longos e longos e convertê-los em valores duplos (com perda de precisão em alguns casos) .
- Os dados de caracteres e caracteres são escritos via JSON Strings, que lidam com todos os caracteres Unicode (notavelmente, os caracteres "unusual" além do ASCII #127, por exemplo, o personagem Euro aparece como "\u20ac") .

JSON

JSON ( .json , .jsonlCSV , etc.) arquivos de texto -
- Todos os dados numéricos são escritos através da sua representação String.
- Os dados de caracteres e caracteres são escritos como caracteres JSON, que lidam com todos os caracteres Unicode (notavelmente, os caracteres "unusual" além do ASCII #127, por exemplo, o personagem Euro aparece como "\u20ac") .
- Os valores perdidos para todos os tipos de dados numéricos aparecem como nulos.

.nc 3 arquivos

.nc 3 arquivos não suportam nativamente qualquer tipo de dados inteiros não assinados. Antes de CF v1.9, CF não apoiou tipos inteiros não assinados. Para lidar com isto, ERDDAP™ 2.10+ segue o padrão NUG e sempre adiciona um atributo "\_Unsigned" com um valor de "true" ou "false" para indicar se os dados são de uma variável não assinada ou assinada. Todos os atributos inteiros são escritos como atributos assinados (por exemplo, byte) com valores assinados (por exemplo, um ubyte actual\_range o atributo com valores 0 a 255, aparece como um atributo byte com valores 0 a -1 (o inverso do valor do complemento dos dois do valor out-of-range). Não há nenhuma maneira fácil de saber quais (assinados) atributos inteiros devem ser lidos como atributos não assinados. ERDDAP™ suporta o atributo "\_Unsigned" quando lê .nc 3 ficheiros.
.nc 3 arquivos não suportam os tipos de dados longos ou longos. ERDDAP™ lida com isso convertendo-os temporariamente para ser variáveis duplas. O dobro pode representar exatamente todos os valores até +/- 9,007,199,254,740,992 que é 2^53. Esta é uma solução imperfeita. Unidata recusa fazer uma pequena atualização para .nc 3 para lidar com isso e problemas relacionados, citando .nc 4 (uma grande mudança) como a solução.
A especificação CF (antes de v1.9) disse que suporta um tipo de dados de carvão, mas não é claro se o carvão é destinado apenas como os blocos de construção de matrizes de carvão, que são efetivamente Strings. Perguntas para sua lista de discussão renderam apenas respostas confusas. Por causa dessas complicações, é melhor evitar variáveis de caridade em ERDDAP™ e use variáveis de corda sempre que possível.
Tradicionalmente, .nc 3 arquivos apenas suportados strings com ASCII codificado (7 bits, #0 - #127) personagens. NUG (e ERDDAP ) estender (início ~ 2017) incluindo o atributo "\_Encoding" com um valor de "ISO-8859-1" (uma extensão de ASCII que define todos os 256 valores de cada caractere de 8 bits) ou "UTF-8" para indicar como os dados String são codificados. Outras codificações podem ser legais, mas são desencorajadas.

.nc 4 arquivos

.nc 4 arquivos suportam todos ERDDAP Os tipos de dados.

Arquivos NCCSV

Os arquivos NCCSV 1.0 não suportam nenhum tipo de dados inteiros não assinados. NCCSV 1.1+ arquivos suporte todos os tipos de dados inteiros não assinados.

DAP

(OPeN)DAP (.das, .dds, arquivos .asc ASCII e arquivos binários .dods) - Não.
- (OPeN)DAPmanipula curto, ushort, int, uint, flutuar e valores duplos corretamente.
- (OPeN)DAPtem um tipo de dados "byte" que define como não assinado, enquanto historicamente, THREDDS e ERDDAP™ ter tratado "byte" como assinado em seu(OPeN)DAPserviços. Para lidar com isto melhor, ERDDAP™ 2.10+ segue o padrão NUG e sempre adiciona um atributo "\_Unsigned" com um valor de "true" ou "false" para indicar se os dados são o que ERDDAP™ chamadas byte ou ubyte. Todos os atributos byte e ubyte são escritos como atributos "byte" com valores assinados (por exemplo, um ubyte actual\_range o atributo com valores 0 a 255, aparece como um atributo byte com valores 0 a -1 (o inverso do valor do complemento dos dois do valor out-of-range). Não há nenhuma maneira fácil de saber quais atributos "byte" devem ser lidos como atributos ubyte.
- (OPeN)DAPnão suporta longos assinados ou não assinados. ERDDAP™ lida com isso, convertendo-os temporariamente para serem variáveis e atributos duplos. Os dobros podem representar exatamente todos os valores até 9,007,199,254,740,992 que é 2^53. Esta é uma solução imperfeita. OPeNDAP (a organização) recusa fazer uma pequena atualização para DAP 2.0 para lidar com isso e problemas relacionados, citando DAP 4 (uma grande mudança) como a solução.
- Porque...(OPeN)DAPnão tem nenhum tipo de dados de carvão separado e tecnicamente só suporta caracteres 1-byte ASCII (#0 - #127) em Strings, as variáveis de dados de carvão aparecerão como Strings de 1 caracteres em(OPeN)DAP.das, .dds, e .dods respostas.
- Tecnicamente, o(OPeN)DAPespecificação apenas suporta strings com caracteres codificados ASCII (#0 - #127) . NUG (e ERDDAP ) estender (início ~ 2017) incluindo o atributo "\_Encoding" com um valor de "ISO-8859-1" (uma extensão de ASCII que define todos os 256 valores de cada caractere de 8 bits) ou "UTF-8" para indicar como os dados String são codificados. Outras codificações podem ser legais, mas são desencorajadas.

Tipo de dados Comentários

Devido ao mau suporte para dados longos, longos e de caridade em muitos tipos de arquivos, desencorajamos o uso desses tipos de dados em ERDDAP . Quando possível, use o dobro em vez de longo e ulong, e use String em vez de char.
Metadata - Porque(OPeN)DAPAs respostas .das e .dds não suportam atributos ou tipos de dados longos ou longos (e em vez mostrar-lhes como duplos) , você pode em vez disso querer usar ERDDAP 's representação tabular de metadados como visto na http ... info / * datasetID * Página web .html (por exemplo, https://coastwatch.pfeg.noaa.gov/erddap/info/cwwcNDBCMet/index.html ) (que você também pode obter em outros tipos de arquivo, por exemplo, .csv, .htmlTable , .itx , .json , .jsonlCSV1 , .jsonlCSV , .jsonlKVP , .mat , .nc , .nccsv , .tsv , .xhtml ) ou o .nccsv Resposta de metadados (por exemplo, https://coastwatch.pfeg.noaa.gov/erddap/tabledap/cwwcNDBCMet.nccsvMetadata Embora .nccsv Metadata só está disponível para conjuntos de dados tabulares) , ambos suportam todos os tipos de dados (notavelmente, longo, ulongo e char) .

Arquivos de mídia

Nem todos os dados são arrays de números ou texto. Alguns conjuntos de dados consistem ou incluem arquivos de mídia, como imagens, arquivos de áudio e vídeo. ERDDAP™ tem alguns recursos especiais para tornar mais fácil para os usuários obter acesso a arquivos de mídia. É um processo de dois passos:

Faça cada arquivo acessível através de sua própria URL, através de um sistema que suporta solicitações de intervalo byte. A maneira mais fácil de fazer isso é colocar os arquivos em um diretório que ERDDAP™ tem acesso. (Se eles estão em um recipiente como um .zip arquivo, descompactá-los, embora você pode querer oferecer o .zip arquivo para usuários também.) Então, faça um EDDTable De Nomes de Arquivo dataset para tornar esses arquivos acessíveis via ERDDAP™ , nomeadamente através ERDDAP ' "files" sistema .

Todos os arquivos tornados acessíveis via EDDTableFromFileNames e ERDDAP ' "files" suporte ao sistema pedidos de intervalo . Normalmente, quando um cliente (por exemplo, um navegador) faz um pedido para uma URL, ele recebe todo o arquivo como a resposta. Mas com uma solicitação de intervalo byte, a solicitação especifica uma variedade de bytes do arquivo, e o servidor só retorna esses bytes. Isto é relevante aqui porque os leitores de áudio e vídeo em navegadores só funcionam se o arquivo pode ser acessado através de solicitações de intervalo byte.

Opcional: Se você tem mais de um conjunto de dados com arquivos de mídia associados, você pode fazer apenas um EDDTableFromFileNames que tem uma subpasta para cada grupo de arquivos. A vantagem é que quando você deseja adicionar novos arquivos de mídia para um novo conjunto de dados, tudo que você precisa fazer é criar uma nova pasta e colocar os arquivos nessa pasta. A pasta e os arquivos serão automaticamente adicionados ao conjunto de dados EDDTableFromFileNames.

Opcional: Se você tiver um conjunto de dados que inclui referências a arquivos de mídia, adicione-o ERDDAP . Por exemplo, você pode ter um arquivo .csv com uma linha por cada vez que alguém viu uma baleia e uma coluna que inclui o nome de um arquivo de imagem relacionado a esse avistamento. Se o nome do arquivo de imagem é apenas o nome do arquivo, por exemplo, Img20141024T192403Z, não uma URL completa, então você precisa adicionar Arquivos de arquivos Url e/ou arquivoAccessSuffix atributos para os metadados para isso dataVariable que especifica a baseURL e sufixo para esses nomes de arquivo. Se você fez os arquivos acessíveis via EDDTableFromFileNames, a URL estará no formulário BaseUrl /erddap / arquivos / * datasetID * / Por exemplo,

        <att name="fileAccessBaseUrl">*someBaseURL*</a>  
        <att name="fileAccessSuffix">.png</a>

Se houver um .zip ou outro arquivo de recipiente com todos os arquivos de mídia relacionados a uma variável de dados, recomendamos que você também torne esse arquivo acessível aos usuários (ver o passo 1 acima) e depois identificá-lo com um arquivoAccessArchive Url. atributo.

\[ Começar ERDDAP™ V1.82 \] Se você fizer o primeiro passo acima (ou ambos os passos) , então quando um usuário vê o ERDDAP™ "files" sistema para esse conjunto de dados (ou pede para ver um subconjunto do conjunto de dados através de um .htmlTable pedido, se você fez o segundo passo) , ERDDAP™ mostrará um ícone '?' à esquerda do nome do arquivo. Se o usuário pairar sobre esse ícone, eles verão um pop-up mostrando a imagem, ou um leitor de áudio, ou um leitor de vídeo. Os navegadores suportam apenas um número limitado de tipos de

imagem (geralmente .gif, .jpg, e .png) ,
áudio (geralmente .mp3, .ogg, e .wav) e
arquivos de vídeo (geralmente .mp4, .ogv, e . Webm) .

O suporte varia com diferentes versões de diferentes navegadores em diferentes sistemas operacionais. Então, se você tem uma escolha de que tipo de arquivo para oferecer, faz sentido oferecer esses tipos.

Ou, se um usuário clicar no nome de arquivo mostrado em um ERDDAP™ página web, seu navegador irá mostrar a imagem, áudio ou arquivo de vídeo como uma página web separada. Isto é principalmente útil para ver uma imagem muito grande ou vídeo dimensionado para tela cheia, em vez de em um pop-up.

Trabalhando com arquivos AWS S3

Serviço Web da Amazon (AWS) é um vendedor de computação em nuvem serviços. S3 é um sistema de armazenamento de objetos oferecido pela AWS. Em vez do sistema hierárquico de diretórios e arquivos de um sistema de arquivos tradicional (como um disco rígido em seu PC) , S3 oferece apenas "buckets" que possuem "objetos" (Vamos chamá-los. "files" ) .

Para arquivos ASCII (por exemplo, .csv) , ERDDAP™ pode trabalhar com os arquivos nos baldes diretamente. A única coisa que você precisa fazer é especificar o<fileDir> para o conjunto de dados usando um formato específico para o balde AWS, por exemplo,https://bucketName.s3.aws-region.amazonaws.com/subdirectory/. Você não deve usar<cacheDeUrl> . Veja abaixo os detalhes.

Mas para arquivos binários (por exemplo, .nc , .grib, .bufr, e .hdf arquivos) , você precisa usar o<cacheDeUrl> sistema descrito abaixo. ERDDAP , netcdf-java (que ERDDAP™ usa para ler dados desses arquivos) , e outros softwares de dados científicos são projetados para trabalhar com arquivos em um sistema de arquivos tradicional que oferece nível de bloco acesso a arquivos (que permite ler pedaços de um arquivo) , mas S3 apenas oferece nível de arquivo (objeto) acesso a arquivos (que só permite ler todo o arquivo) . AWS oferece uma alternativa para S3, Loja de bloco elástico (EBS) ), que suporta o acesso de nível de bloco a arquivos, mas é mais caro do que S3, por isso raramente é usado para armazenamento em massa de grandes quantidades de arquivos de dados. (Então, quando as pessoas dizem armazenar dados na nuvem (S3) é barato, geralmente é uma comparação de maçãs a laranjas.)

S3 Buckets

O conteúdo de um balde. Chaves. Objetos. Delimitadores.
Tecnicamente, baldes S3 não são organizados em uma estrutura hierárquica de arquivos como um sistema de arquivos em um computador. Em vez disso, os baldes contêm apenas "objetos" (arquivos) , cada um dos quais tem uma "chave" (um nome) . Um exemplo de uma chave nesse balde noaa-goes17 é

ABI-L1b-RadC/2019/235/22/OR\\_ABI-L1b-RadC-M6C01\\_G17\\_s20192352201196\\_e20192352203569\\_c20192352204013.nc

O URl correspondente para esse objeto é

https://noaa-goes17.s3.us-east-1.amazonaws.com/ABI-L1b-RadC/2019/235/22/OR\_ABI-L1b-RadC-M6C01\_G17\_s20192352201196\_e20192352203569\_c20192352204013.nc

AWS suporta uma pequena variação de como essa URL é construída, mas ERDDAP™ requer este formato específico: https://bucketName.s3.region.amazonaws.com/key

A partir de ERDDAP v2.29, você agora pode usar o s3: Formato URI em vez da URL do balde. Este é o formato usado pelo AWS s3 cli . s3: Nome do balde / chave chave

O região para o S3 URI pode ser especificado de uma das três maneiras:

O região no usuário Tomcat ~/.aws/config perfil
O AWS_DEFAULT_REGION variável de ambiente
O aws.região Variável JVM (em setenv.sh para Tomcat)

É prática comum, como com este exemplo, fazer nomes-chave parecer um caminho hierárquico mais um nome de arquivo, mas tecnicamente eles não são. Como é comum e útil, ERDDAP™ trata chaves com /'s como se eles são um caminho hierárquico mais nome de arquivo, e esta documentação irá se referir a eles como tal. Se as chaves de um balde não usam /'s (por exemplo, uma chave como ABI-Lib.2018.052.22.OR\_ABI-L1b-RadM2-M3C10\_G16\_s20180522247575), então ERDDAP™ vai apenas tratar toda a chave como um nome de arquivo longo.

Privado vs Public Buckets - ... O administrador do balde S3 pode tornar o balde e seu conteúdo público ou privado. Se público, qualquer arquivo no balde pode ser baixado por qualquer pessoa usando a URL para o arquivo. Amazon tem um Dados abertos programa que hospeda conjuntos de dados públicos (incluindo dados de NOAA , NASA e USGS) gratuitamente e não cobra para que ninguém baixe os arquivos desses baldes. Se um balde é privado, os arquivos no balde são acessíveis apenas aos usuários autorizados e AWS cobra uma taxa (geralmente pago pelo proprietário do balde) para baixar arquivos para um computador não-AWS S3. ERDDAP™ pode trabalhar com dados em baldes públicos e privados.

Credenciais AWS

Para fazer isso ERDDAP™ pode ler o conteúdo de baldes privados, você precisa de credenciais AWS e você precisa armazenar um arquivo de credenciais no lugar padrão assim ERDDAP™ pode encontrar as informações. Veja o SDK AWS para Java 2.x documentação: Definir credenciais padrão . (A opção de armazenar os valores como Java parâmetros de linha de comando em \[ Toca a brincar. \] /bin/setenv.sh pode ser uma boa opção.)

AWS / arquivos /

/arquivos/sistema -- O ERDDAP™ /arquivos/sistema permite que os usuários baixem os arquivos de origem para um conjunto de dados. Recomendamos que você ligue isso para todos os conjuntos de dados com arquivos de origem porque muitos usuários querem baixar os arquivos de origem originais.
- Se os arquivos estiverem em um balde S3 privado, o pedido do usuário para baixar um arquivo será tratado por ERDDAP™ , que irá ler os dados do arquivo e, em seguida, transmiti-lo ao usuário, aumentando assim a carga em seu ERDDAP™ , usando largura de banda de entrada e saída, e fazendo você (o ERDDAP™ administrador) pagar a taxa de entrada de dados para AWS.
- Se os arquivos estiverem em um balde público S3, o pedido do usuário para baixar um arquivo será redirecionado para a URL AWS S3 para esse arquivo, para que os dados não fluam através ERDDAP™ , reduzindo assim a carga em ERDDAP . E se os arquivos estão em um Amazon Open Data (grátis) balde público, então você (o ERDDAP™ administrador) não terá que pagar qualquer taxa de entrada de dados para AWS. Assim, há uma grande vantagem servindo dados de público (não privado) baldes S3, e uma enorme vantagem para servir dados da Amazon Open Data (grátis) baldes.

ERDDAP também suporta credenciais anônimas para baldes públicos. Para usar credenciais anônimas, adicione <useAwsAnonymous> verdadeiro </useAwsAnonymous> para o seu setup.xml.

Pontos finais personalizados S3

Para armazenamento de objetos compatíveis S3 não hospedados pela Amazon, você precisa configurar o endpoint_url junto com especificando seu balde/chave usando um s3: URI.

O endpoint_url pode ser especificado de uma das três maneiras:

O endpoint_url no usuário Tomcat ~/.aws/config perfil
O AWS_ENDPOINT_URL variável de ambiente
O aws.pt Url. Variável JVM (em setenv.sh para Tomcat)

Para uma lista completa de variáveis de configuração S3, Veja a documentação do Amazonas .

Certificados auto-assinados Para baldes S3 auto-apresentados, você muitas vezes terá certificados SSL auto-assinados. Para ERDDAP para ler a partir desses baldes, você precisa adicionar sua cadeia de certificados à loja de confiança JVM na $JAVA_HOME/jre/lib/security/cacerts . Além disso, ERDDAP usa o Tempo de execução comum de AWS para acessar o balde assíncrono. Isso aumenta o desempenho, mas também requer que seus certificados auto-assinados sejam adicionados à sua loja de confiança específica do sistema operacional. Se você quiser evitar fazer isso, você pode desativar o AWS CRT com <useAwsCrt> falso </useAwsCrt> em seu setup.xml.

ERDDAP™ e AWS S3 Buckets

** ERDDAP™ e AWS S3 Buckets**
Felizmente, depois de muito esforço, ERDDAP™ tem uma série de recursos que permitem lidar com os problemas inerentes de trabalhar com o nível de bloco S3 acesso a arquivos de uma forma razoavelmente eficiente:

\[ Disclaimer: Trabalhar com baldes AWS S3 é muito trabalho extra. AWS é um enorme ecossistema de serviços e recursos. Há muito para aprender. Leva tempo e esforço, mas é possível. Sê paciente e vais trabalhar. Olhar / pedir ajuda ( Documentação da AWS , sites como Overflow em pilha , e o regular ERDDAP™ opções de suporte ) se / quando você ficar preso. \]
Pode ser difícil até descobrir a estrutura do diretório e nomes de arquivos dos arquivos em um balde S3. ERDDAP™ tem uma solução para este problema: EDDTableFromFileNames tem um especial \\\* a partir de opção que permite fazer um conjunto de dados EDDTableFromFileNames que permite aos usuários navegar o conteúdo de um balde S3 (e arquivos de download) através do conjunto de dados "files" opção. Há um exemplo deste abaixo .
ERDDAP™ pode ler dados de arquivos de dados compactados externamente , por isso é bom se os arquivos em S3 são armazenados como .gz , .gzip , .bz2 , .Z, ou outros tipos de arquivos de dados externamente compactados, que podem dramaticamente (2 - 20X) corte nos custos de armazenamento de arquivos. Muitas vezes não há pena de tempo para usar arquivos compactados externamente, desde o tempo salvo, transferindo um arquivo menor de S3 para ERDDAP aproximadamente equilibra o tempo extra necessário para ERDDAP™ para descomprimir o arquivo. Para usar esse recurso, você só precisa ter certeza de que o conjunto de dados<fileNameRegex> permite o tipo de arquivo comprimido (por exemplo, adicionando ( | .gz ) ao fim do regex) .
Para o caso mais comum, onde você tem um ERDDAP™ instalado em seu PC para teste / desenvolvimento e onde o conjunto de dados tem arquivos de dados binários que são armazenados como objetos em um balde S3, uma abordagem para obter o conjunto de dados em ERDDAP™ é:
1. Crie um diretório no seu PC para armazenar alguns arquivos de dados de teste.
2. Baixe dois arquivos de dados da fonte para o diretório que você acabou de criar.
3. Uso Gerar conjuntos de dadosXml para gerar o pedaço de datasets.xml para o conjunto de dados baseado nos dois arquivos de dados locais.
4. Verifique se esse conjunto de dados funciona conforme desejado DasDds e/ou seu local ERDDAP .
  
  As seguintes etapas fazem uma cópia desse conjunto de dados (que receberá dados do balde S3) em um público ERDDAP .
5. Copie o pedaço de datasets.xml para o conjunto de dados para o datasets.xml para o público ERDDAP™ que servirá os dados.
6. Criar um diretório no público ERDDAP 's disco rígido local para segurar um cache de arquivos temporários. O diretório não usará muito espaço em disco (veja cacheSizeGB abaixo) .
7. Alterar o valor do conjunto de dados<fileDir> tag para que ele aponta para o diretório que você acabou de criar (mesmo que o diretório esteja vazio) .
8. Adicionar um Cache De Url tag que especifica o nome do balde do conjunto de dados e prefixo opcional (ou seja, diretório) em específico Aws S3 URL Formato que ERDDAP™ requerimento .
9. Adicionar um [<cacheSizeGB>] (#cachefromurl) tag to the dataset's xml (por exemplo, 10 é um bom valor para a maioria dos conjuntos de dados) para contar ERDDAP™ para limitar o tamanho do cache local (ou seja, não tente guardar todos os arquivos remotos) .
10. Veja se isso funciona em público ERDDAP . Note que a primeira vez ERDDAP™ carrega o conjunto de dados, levará muito tempo para carregar, porque ERDDAP™ precisa baixar e ler todos os arquivos de dados.

Se o conjunto de dados é uma enorme coleção de arquivos de dados gradeados enormes, isso levará muito tempo e será impraticável. Em alguns casos, para arquivos de dados gradeados, ERDDAP™ pode extrair as informações necessárias (por exemplo, o ponto de hora para os dados em um arquivo de dados gradeado) do nome do arquivo e evitar este problema. Ver Agregação via Nomes de arquivo .

Opcionalmente (mas especialmente para conjuntos de dados EDDTableFromFiles) , você pode adicionar um NTreads tag to the dataset to tell ERDDAP usar mais de 1 thread ao responder ao pedido de dados de um usuário. Isso minimiza os efeitos do atraso que ocorre quando ERDDAP™ lê arquivos de dados de (remoto) AWS S3 baldes no cache local e (talvez) descomprimir-os.

AWS S3 Dados abertos

Como parte de NOAA ' Programa de Big Data , NOAA tem parcerias com cinco organizações, incluindo AWS, "para explorar os benefícios potenciais de armazenar cópias de observações-chave e saídas de modelos na nuvem para permitir a computação diretamente sobre os dados sem exigir mais distribuição". AWS inclui os conjuntos de dados que recebe NOAA como parte de seu programa para oferecer acesso público a uma grande coleção de Dados abertos no AWS S3 de qualquer computador, seja uma instância de computação da Amazon (um computador alugado) na rede AWS ou seu próprio PC em qualquer rede. O exemplo abaixo assume que você está trabalhando com um conjunto de dados publicamente acessível.

Acessando arquivos em um balde AWS S3

Para um balde de dados S3 privado, o proprietário do balde deve lhe dar acesso ao balde. (Veja a documentação da AWS.)

Em todos os casos, você precisará de uma conta AWS porque o SDK AWS para Java (que ERDDAP™ usa para recuperar informações sobre o conteúdo de um balde) requer credenciais de conta AWS. (mais sobre este abaixo)

ERDDAP™ só pode acessar baldes AWS S3 se você especificar o [<cacheDe Url>] (#cachefromurl) (ou<fileDir>) em um formato específico: https://bucketName.s3.aws-region.amazonaws.com/prefix/
Onde?

O baldeNome é a forma curta do nome do balde, por exemplo, noaa-goes17 .
A aws-region, por exemplo, us-east-1, é da coluna "Region" em uma das tabelas de Pontos finais de serviço AWS onde o balde está realmente localizado.
O prefixo é opcional. Se presente, deve terminar com '/' .

Por exemplo,https://noaa-goes17.s3.us-east-1.amazonaws.com/ABI-L1b-RadC/
Este formato URL é uma das recomendações AWS S3: ver Acesso a um balde e esta descrição de prefixos . ERDDAP™ requer que você combine a URL do balde e o prefixo opcional em uma URL, a fim de especificar<cacheDeUrl> (ou<fileDir>) onde os arquivos estão localizados.

Teste público AWS S3 Buckets

Para baldes públicos, você pode e deve testar a URL do balde do diretório AWS S3 em seu navegador, por exemplo, https://noaa-goes17.s3.us-east-1.amazonaws.com Se a URL do balde estiver correta e apropriada para ERDDAP , ele retornará um documento XML que tem (parcial) listagem do conteúdo daquele balde. Infelizmente, a URL completa (i.e., URL do balde mais prefixo) que ERDDAP™ quer para um determinado conjunto de dados não funciona em um navegador. AWS não oferece um sistema para navegar na hierarquia de um balde facilmente em seu navegador. (Se isso estiver errado, por favor envie um e-mail para Chris. John no noaaa.gov. Caso contrário, Amazon, por favor, adicione suporte para isso!)

Visualizando o conteúdo de um balde

baldes S3 muitas vezes contêm um par de categorias de arquivos, em um par de subdiretórios pseudo, que poderiam se tornar um par de ERDDAP™ conjuntos de dados. Para fazer o ERDDAP™ datasets, você precisa saber o diretório inicial para<cacheDeUrl> (ou<fileDir>) e o formato dos nomes de arquivos que identificam esse subconjunto de arquivos. Se você tentar visualizar todo o conteúdo de um balde em um navegador, S3 irá apenas mostrar-lhe os primeiros 1000 arquivos, o que é insuficiente. Atualmente, a melhor maneira para você ver todos os conteúdos de um balde é fazer um EDDTable De Nomes de Arquivo conjunto de dados (no seu PC ERDDAP™ e/ou em seu público ERDDAP ) , que também lhe dá uma maneira fácil de navegar na estrutura do diretório e baixar arquivos. O<fileDir> para isso será a URL que você fez acima, por exemplo,https://noaa-goes17.s3.us-east-1.amazonaws.com. \[ Por que o AWS S3 não oferece uma maneira rápida e fácil para alguém fazer isso sem uma conta AWS? \] Note que quando eu faço isso no meu PC em uma rede não-Amazon, parece que a Amazon retarda a resposta a um truque (cerca de 100 (?) arquivos por chunk) após os primeiros pedaços (de 1000 arquivos por pedaço) são baixados. Uma vez que os baldes podem ter um grande número de arquivos (noaa-goes17 tem 26 milhões) , recebendo todo o conteúdo de um balde pode tomar EDDTableDeFileNames várias horas (Por exemplo, 12!) para terminar. \[ Amazon, é verdade?! \]

Fazendo uma tabela EDD FromFileNames Dataset with a AWS S3 Bucket

Se você tem um nome de balde, mas não já tem uma lista de arquivos no balde S3 ou o prefixo que identifica a localização dos arquivos relevantes no balde, use as instruções abaixo para fazer um conjunto de dados EDDTableFromFileNames para que você possa navegar na hierarquia de diretório do balde S3 via ERDDAP ' "files" sistema.

Abra uma conta AWS ERDDAP™ usa o SDK AWS para Java para obter informações do balde da AWS, então você precisa criar e ativar uma conta AWS . É um grande trabalho, com muitas coisas para aprender.
Coloque suas credenciais AWS onde ERDDAP™ pode encontrá-los. Siga as instruções no Configurar Credenciais AWS e Região para o Desenvolvimento Então... ERDDAP™ (especificamente, o SDK AWS para Java ) será capaz de encontrar e usar suas credenciais AWS. Se ERDDAP™ não pode encontrar as credenciais, você verá uma Java.lang. IllegalArgumentException: arquivo de perfil não pode ser erro nulo em ERDDAP O arquivo log.txt.

Dica para Linux e Mac OS: o arquivo de credenciais deve estar no diretório inicial do usuário que está executando Tomcat (e ERDDAP ) (para este parágrafo, vamos assumir user=tomcat) em um arquivo chamado ~/.aws/credentials . Não assuma que ~ é /home/tomcat -- realmente use cd ~ para descobrir onde o sistema operacional pensa ~ para usuário=tomcat é. Crie o diretório se não existir. Além disso, depois de colocar o arquivo de credenciais no lugar, certifique-se de que o usuário e grupo para o arquivo são tomcat e, em seguida, use credenciais chmod 400 para se certificar de que o arquivo é somente leitura para user=tomcat.

Criar a URL do balde no formato que ERDDAP™ requerimento , por exemplo, https://noaa-goes17.s3.us-east-1.amazonaws.com e (para baldes públicos) testá-lo em um navegador para certificar-se de que retorna um documento XML que tem uma listagem parcial do conteúdo daquele balde.
Uso Gerar conjuntos de dadosXml para criar um EDDTable De Nomes de Arquivo dataset:
- Para o diretório Iniciar, use esta sintaxe: \\\ deOnTheFly, O que foi? por exemplo, \\\*deOnTheFly,https://noaa-goes17.s3.us-east-1.amazonaws.com/
- Nome de arquivo regex? .
- Recursivo? verdadeiro
- recarregar Todas as NMinutes? 10080
- infoUrl ?https://registry.opendata.aws/noaa-goes/
- instituição? NOAA
- Sumário? Nada. ( ERDDAP™ criará um resumo decente automaticamente.)
- título? Nada. ( ERDDAP™ criará um título decente automaticamente.) Como de costume, você deve editar o XML resultante para verificar a correção e fazer melhorias antes do pedaço de conjuntos de dados usá-lo em datasets.xml .
Se você seguir as instruções acima e carregar o conjunto de dados em ERDDAP , você criou um conjunto de dados EDDTableFromFiles. Como exemplo, e para tornar mais fácil para qualquer pessoa navegar e baixar arquivos dos baldes AWS Open Data, criamos conjuntos de dados ETableDDFromFileNames (veja a lista em https://upwell.pfeg.noaa.gov/erddap/search/index.html?searchFor=awsS3Files\_ ) para quase todos os AWS S3 Abrir baldes de dados . \[ Os poucos baldes que não incluímos ou têm um grande número de arquivos no diretório raiz (mais do que pode ser baixado em uma quantidade razoável de tempo) , ou não permitir acesso público (Não deviam ser todos públicos?) , ou são os baldes do Requester Pays (por exemplo, Sentinel) . \]
Se você clicar no "files" link para um desses conjuntos de dados, você pode navegar na árvore de diretórios e arquivos nesse balde S3. Por causa do caminho\\\*deOnTheFly EDDTableDeFiles funciona, essas listagens de diretórios estão sempre perfeitamente atualizadas porque ERDDAP™ Atinge-os. Se você clicar na árvore de diretório para um nome de arquivo real e clicar no nome do arquivo, ERDDAP™ irá redirecionar seu pedido para AWS S3 para que você possa baixar o arquivo diretamente de AWS. Você pode então inspecionar esse arquivo.

Problemas? Se o seu EDDTableFromFiles não carregar ERDDAP™ (ou DasDds) , veja no arquivo log.txt para uma mensagem de erro. Se vires uma Java.lang. IllegalArgumentException: arquivo de perfil não pode ser erro nulo, o problema é que o AWS SDK para Java (usado por ERDDAP ) Não está a encontrar o ficheiro das credenciais. Veja as instruções de credenciais acima.

É lamentável que a AWS não simplesmente permita que as pessoas usem um navegador para ver o conteúdo de um balde público.

Então você pode fazer ERDDAP™ conjuntos de dados que dão aos usuários acesso aos dados nos arquivos.
Veja as instruções em ERDDAP™ e S3 Buckets (acima) . Para a amostra EDDTableFromFileNames conjunto de dados que você fez acima, se você fizer um pouco poking ao redor com o diretório e nomes de arquivo na árvore de diretório, fica claro que os nomes de diretório de nível superior (por exemplo, ABI-L1b-RadC) corresponder ao que ERDDAP™ chamaria conjuntos de dados separados. O balde com que você está trabalhando pode ser semelhante. Você pode então prosseguir criando conjuntos de dados separados em ERDDAP™ para cada um desses conjuntos de dados, usando, por exemplo, https://noaa-goes17.s3.us-east-1.amazonaws.com/ABI-L1b-RadC/
como o<cacheDeUrl>. Infelizmente, para este exemplo particular, os conjuntos de dados no balde todos parecem ser conjuntos de dados de nível 1 ou nível 2, que ERDDAP™ não é particularmente bom , porque o conjunto de dados é uma coleção mais complicada de variáveis que usam diferentes dimensões.

Arquivos NcML

Arquivos NcML permitem que você especifique mudanças on-the-fly em uma ou mais fonte original NetCDF (v3 ou v4) .nc , .grib, .bufr, ou .hdf (v4 ou v5) arquivos, e depois ter ERDDAP™ tratar o .nc arquivos de ml como os arquivos de origem. ERDDAP™ conjuntos de dados irão aceitar .nc arquivos de ml sempre .nc arquivos são esperados. Os arquivos NcML MUST ter a extensão .nc ml. Ver Unidata Documentação NcML . NcML é útil porque você pode fazer algumas coisas com ele (por exemplo, fazendo diferentes mudanças em arquivos diferentes em uma coleção, incluindo adicionar uma dimensão com um valor específico para um arquivo) , que você não pode fazer com ERDDAP ' datasets.xml .

Mudanças em um .nc O último tempo do arquivo mlModified fará com que o arquivo seja recarregado sempre que o conjunto de dados for recarregado, mas muda para o subjacente .nc arquivos de dados não serão notados diretamente.
Dica: NcML é\*Muito bem.\*sensível à ordem de alguns itens no arquivo NcML. Pense em NcML como especificando uma série de instruções na ordem especificada, com a intenção de alterar os arquivos de origem (o estado no início/top do arquivo NcML) para os arquivos de destino (o estado no final / fundo do arquivo NcML) .

Uma alternativa para NcML é o NetCDF Operadores ( NCO ) . A grande diferença é que NcML é um sistema para fazer mudanças na-the-fly (para que os arquivos de origem não sejam alterados) Considerando que NCO pode ser usado para fazer alterações (ou novas versões de) os ficheiros. Ambos NCO e NcML são muito, muito flexíveis e permitem que você faça quase qualquer mudança que você pode pensar nos arquivos. Para ambos, pode ser um desafio descobrir exatamente como fazer o que você quer fazer -- Verifique a web para exemplos semelhantes. Ambos são ferramentas úteis para preparar o netCDF e HDF arquivos para uso com ERDDAP , nomeadamente, para fazer mudanças além do que ERDDAP O sistema de manipulação pode fazer.

Exemplo #1: Adicionando uma dimensão de tempo com um único valor Aqui está uma .nc arquivo de ml que cria uma nova dimensão externa (tempo, com 1 valor: 1041379200) e adiciona essa dimensão à variável pic no arquivo chamado A2003001.L3m\_DAY\_PIC\_pic\_4km .nc :

    <netcdf xmlns='https://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2'>
      <variable name='time' type='int' shape='time' />
      <aggregation dimName='time' type='joinNew'>
        <variableAgg name='pic'/>
        <netcdf location='A2003001.L3m\\_DAY\\_PIC\\_pic\\_4km.nc' coordValue='1041379200'/>
      </aggregation>
    </netcdf>

Exemplo #2: Alterando um Valor de Tempo Existente Às vezes a fonte .nc arquivo já tem uma dimensão de tempo e valor de tempo, mas o valor está incorreta (para os seus propósitos) . Isto é... .nc arquivo ml diz: para o arquivo de dados chamado "19810825230030-NCEI...", para a variável dimensão "time" , definir as unidades atribuem a ser 'segundos desde 1970-01T00:00:00Z' e definir o valor do tempo para ser 367588800.

    <netcdf xmlns='https://www.unidata.ucar.edu/namespaces/netcdf/ncml-2.2'
      location="19810825230030-NCEI-L3C\\_GHRSST-SSTskin-AVHRR\\_Pathfinder-PFV5.3\\_NOAA07\\_G\\_1981237\\_day-v02.0-fv01.0.nc">
      <variable name="time">
        <attribute name='units' value='seconds since 1970-01-01T00:00:00Z' />
        <values>367588800</values>
      </variable>
    </netcdf>

NetCDF Operadores ( NCO )

"Os operadores netCDF ( NCO ) compõem uma dúzia de programas autônomos, linha de comando que levam o netCDF \[ v3 ou v4 \] , HDF \[ v4 ou v5 \] , \[ .grib, .bufr, \] e/ou DAP arquivos como entrada, em seguida, operar (por exemplo, derivar novos dados, estatísticas de computação, impressão, hiperslab, manipular metadados) e produzir os resultados para exibir ou arquivos em formatos de texto, binário ou netCDF. NCO ajudas análise de dados científicos grelhados. O estilo de shell-command NCO permite aos usuários manipular e analisar arquivos de forma interativa, ou com scripts expressivos que evitam alguns ambientes de programação de nível superior." (do NCO Página inicial) .

Uma alternativa a NCO é NcML . A grande diferença é que NcML é um sistema para fazer mudanças na-the-fly (para que os arquivos de origem não sejam alterados) Considerando que NCO pode ser usado para fazer alterações (ou novas versões de) os ficheiros. Ambos NCO e NcML são muito, muito flexíveis e permitem que você faça quase qualquer mudança que você pode pensar nos arquivos. Para ambos, pode ser um desafio descobrir exatamente como fazer o que você quer fazer -- Verifique a web para exemplos semelhantes. Ambos são ferramentas úteis para preparar o netCDF e HDF arquivos para uso com ERDDAP , nomeadamente, para fazer mudanças além do que ERDDAP O sistema de manipulação pode fazer.

Por exemplo, você pode usar NCO para tornar as unidades da variável de tempo consistentes em um grupo de arquivos onde eles não eram consistentes originalmente. Ou, você pode usar NCO para aplicar scale\_factor e add\_offset em um grupo de arquivos onde scale\_factor e add\_offset tem valores diferentes em arquivos de origem diferentes. (Ou agora você pode lidar com esses problemas em ERDDAP™ via via via via EDDGrid A partir de NcFilesUnpacked , que é uma variante de EDDGrid FromNcFiles que descompacta dados embalados e padroniza valores de tempo em um nível baixo, a fim de lidar com um arquivos de coleção que têm diferentes scale\_factor e add\_offset , ou unidades de tempo diferentes.)

NCO é Livre e Open Source Software que usa o GPL 3.0 licença.

Exemplo #1: Tornando as unidades consistentes EDDGrid Dos Ficheiros e Tabela EDD De Arquivos insistem que as unidades para uma determinada variável sejam idênticas em todos os arquivos. Se alguns dos arquivos são trivialmente (não funcionalmente) diferente de outros (por exemplo, unidades de tempo de "segundos desde 1970-01-01 00:00 UTC" versus "seconds since 1970-01-01T00:00:00Z" , você pode usar NCO ' ncatted . para alterar as unidades em todos os arquivos para ser idêntico com nco/ncatted -a unidades, time,o,c,'seconds since 1970-01T00:00Z' \* .nc
\[ Para muitos problemas como este em EDDTableDe... Arquivos conjuntos de dados, você agora pode usar padronizar O quê? para contar ERDDAP para padronizar os arquivos de origem como eles são lidos ERDDAP . \]

Limites ao tamanho de um conjunto de dados

Você verá muitas referências a "2 bilhões" abaixo. Mais precisamente, que é uma referência a 2,147,483,647 (2 - 1 - 2 - 2 - 3 - 2 - 3 - 3 - 2 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 2 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 2 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 3 - 2 -) , que é o valor máximo de um inteiro assinado de 32 bits. Em algumas linguagens de computador, por exemplo Java (que ERDDAP™ está escrito em) , esse é o maior tipo de dados que pode ser usado para muitas estruturas de dados (por exemplo, o tamanho de um array) .

Para valores de string (por exemplo, para nomes variáveis, nomes de atributos, valores de atributos de caracteres e valores de dados de caracteres) , o número máximo de caracteres por corda ERDDAP™ é ~ 2 bilhões. Mas em quase todos os casos, haverá pequenos ou grandes problemas se uma corda exceder um tamanho razoável (por exemplo, 80 caracteres para nomes variáveis e nomes de atributos, e 255 caracteres para a maioria dos valores de atributos e valores de dados) . Por exemplo, páginas da web que exibem nomes variáveis longos serão desconfortavelmente largos e nomes variáveis longas serão truncados se excederem o limite do tipo de arquivo de resposta.

Para conjuntos de dados gradeados:

O número máximo de axisVariable s é ~ 2 bilhões. O número máximo de dataVariable s é ~ 2 bilhões. Mas se um conjunto de dados tiver variáveis >100, será complicado para os usuários usarem. E se um conjunto de dados tiver 1 milhão de variáveis, seu servidor precisará de muita memória física e haverá outros problemas.
O tamanho máximo de cada dimensão ( axisVariable ) é ~ 2 bilhões de valores.
Acho que o número total máximo de células (o produto de todos os tamanhos de dimensão) é ilimitado, mas pode ser ~9e18.

Para conjuntos de dados tabulares:

O número máximo de dataVariable s é ~ 2 bilhões. Mas se um conjunto de dados tiver variáveis >100, será complicado para os usuários usarem. E se um conjunto de dados tiver 1 milhão de variáveis, seu servidor precisará de muita memória física e haverá outros problemas.
O número máximo de fontes (por exemplo, arquivos) que pode ser agregado é ~ 2 bilhões.
Em alguns casos, o número máximo de linhas de uma fonte individual (por exemplo, um arquivo, mas não um banco de dados) é ~ 2 bilhões de linhas.
Acho que não há outros limites.

Para conjuntos de dados gradeados e tabulares, existem alguns limites internos no tamanho do subconjunto que pode ser solicitado por um usuário em um único pedido (muitas vezes relacionados com >2 bilhões de algo ou ~9e18 de algo) , mas é muito mais provável que um usuário atinja os limites específicos do tipo de arquivo.

NetCDF versão 3 .nc arquivos são limitados a 2GB bytes. (Se isto é realmente um problema para alguém, avise-me: Eu poderia adicionar suporte para o NetCDF versão 3 .nc Extensão de 64 bits ou NetCDF Versão 4, que aumentaria o limite significativamente, mas não infinitamente.)
Navegadores falham após apenas ~500MB de dados, então ERDDAP™ limita a resposta a .htmlTable solicitações para ~400MB de dados.
Muitos programas de análise de dados têm limites semelhantes (por exemplo, o tamanho máximo de uma dimensão é frequentemente ~2 bilhões de valores) , então não há razão para trabalhar duro para se locomover os limites específicos do tipo de arquivo.
Os limites específicos do tipo de arquivo são úteis na medida em que impedem pedidos ingênuos para quantidades verdadeiramente enormes de dados (por exemplo, "dar-me todo este conjunto de dados" quando o conjunto de dados tem 20TB de dados) , que levaria semanas ou meses para baixar. Quanto mais tempo o download, mais provável ele falhará por uma variedade de razões.
Os limites específicos do tipo de arquivo são úteis na medida em que forçam o usuário a lidar com subconjuntos razoavelmente grandes (por exemplo, lidar com um grande conjunto de dados gradeado através de arquivos com dados de um ponto de tempo cada) .

Mudar para ACDD-1.3

Nós (notadamente Gerar conjuntos de dadosXml ) recomendar atualmente Versão ACDD 1.3 , que foi ratificado no início de 2015 e que é referido como "ACDD-1.3" no atributo Convenções globais. Antes de ERDDAP™ versão 1.62 (lançado em junho de 2015) , ERDDAP™ usado/recomendado o original, versão 1.0, do NetCDF Atribua a Convenção para o Descobrimento de Dados que foi referido como " Unidata Dataset Discovery v1.0" nas Convenções globais e Metadata\_Conventions atributos.

Se seus conjuntos de dados usar versões anteriores do ACDD, nós RECOMENDAR que você mudar para ACDD-1.3. Não é difícil. ACDD-1.3 é altamente compatível com a versão 1.0. Para alternar, para todos os conjuntos de dados (exceto EDDGrid FromErddap e EDDTable Conjuntos de dados da Erddap) :

Remover o global recém-despregado Metadata\_Conventions atributo adicionando (ou alterando o existente Metadata\_Conventions atributos)

        <att name="Metadata\\_Conventions">null</att>

para o conjunto de dados global< addAttributes > 2. Se o conjunto de dados tem um atributo Convenções no global< addAttributes >, mudar tudo " Unidata Dataset Discovery v1.0" faz referência a "ACDD-1.3". Se o conjunto de dados não tiver um atributo Conventions no global< addAttributes >, então adicione um que se refere a ACDD-1.3. Por exemplo,

        <att name="Conventions">COARDS, CF-1.6, ACDD-1.3</att>

3. Se o conjunto de dados tem um global standard\_name\_vocabulary atributo, altere o formato do valor para, por exemplo,

        <att name="standard\\_name\\_vocabulary">CF Standard Name Table v65</att>

Se a referência for a uma versão mais antiga do Tabela de nomes padrão CF . é provavelmente uma boa ideia mudar para a versão atual (65, como escrevemos isto) , uma vez que novos nomes padrão são adicionados a essa tabela com versões subseqüentes, mas os nomes padrão antigos raramente são depreciados e nunca removidos. 4. Embora ACDD-1.0 incluiu atributos globais para creator\_name , creator\_email , creator\_url , Gerar conjuntos de dadosXml não os adicionou automaticamente até algum momento em torno ERDDAP™ V1.50. Esta é uma informação importante:

creator\_name permite aos usuários saber/citar o criador do conjunto de dados.
creator\_email informa aos usuários o endereço de e-mail preferido para entrar em contato com o criador do conjunto de dados, por exemplo, se eles têm perguntas sobre o conjunto de dados.
creator\_url dá aos usuários uma maneira de descobrir mais sobre o criador.
ERDDAP™ usa todas essas informações ao gerar documentos de metadados FGDC e ISO 19115-2/19139 para cada conjunto de dados. Esses documentos são frequentemente usados por serviços de busca externos.

Adicione esses atributos ao conjunto de dados global< addAttributes >

        <att name="creator\\_name">NOAA NMFS SWFSC ERD</att>  
        <att name="creator\\_email">erd.data@noaa.gov</att>  
        <att name="creator\\_url">https://www.pfeg.noaa.gov</att>  

É isso. Espero que não tenha sido muito difícil.

Zarr

Como versão 2.25 ERDDAP™ pode ler local Arquivos de Zarr usando EDDTable De NcFiles e EDDGrid A partir de NcFiles .

(A partir de agosto 2019) Podemos facilmente estar errados, mas ainda não estamos convencidos de que Zarr , ou sistemas semelhantes que quebram arquivos de dados em pedaços menores, são grandes soluções para o problema de ERDDAP™ ler dados armazenados em serviços de nuvem como Amazon AWS S3. Zarr é uma grande tecnologia que mostrou sua utilidade em uma variedade de situações, não temos certeza de que ERDDAP +S3 será uma dessas situações. Principalmente estamos dizendo: antes de nos apressarmos para fazer o esforço para armazenar todos os nossos dados em Zarr, vamos fazer alguns testes para ver se é realmente uma solução melhor.

Os problemas com o acesso aos dados na nuvem são latência (o lag para primeiro obter dados) e acesso de nível de arquivo (em vez de acesso ao nível do bloco) . Zarr resolve o problema de acesso de nível de arquivo, mas não faz nada sobre latência. Comparado a apenas baixar o arquivo (para que possa ser lido como um arquivo local com acesso de nível de bloco) , Zarr pode até exacerbar o problema de latência porque, com Zarr, ler um arquivo agora envolve uma série de várias chamadas para ler diferentes partes do arquivo (cada um com seu próprio lag) . O problema de latência pode ser resolvido paralelamente às solicitações, mas essa é uma solução de nível superior, não dependente de Zarr.

E com Zarr (como com bases de dados relacionais) , perdemos a conveniência de ter um arquivo de dados ser um arquivo simples, único que você pode facilmente verificar a integridade de, ou fazer / baixar uma cópia de.

ERDDAP™ (a partir de v2) tem um sistema para manter uma cache local de arquivos de uma fonte de URL (por exemplo, S3) (veja [<cacheDeUrl> e<cacheMaxGB>] (#cachefromurl) ). E o novo [<NThreads>] (#nthreads) deve minimizar o problema de latência, paralelando a recuperação de dados em um alto nível.<cacheDeUrl> parece funcionar muito bem para muitos cenários. (Não temos certeza de quão benéfico<nThreads> é sem mais testes.) Admitimos que não fizemos testes de tempo em uma instância AWS com uma boa conexão de rede, mas testamos com sucesso com várias fontes de URL remotas de arquivos. E ERDDAP '<cacheFromUrl> funciona com qualquer tipo de arquivo de dados (por exemplo, .nc , .hdf , .csv, .jsonlCSV ) , mesmo que externamente comprimido (por exemplo, .gz ) , sem quaisquer alterações nos arquivos (por exemplo, reescrevendo-os como coleções de Zarr) .

É provável que diferentes cenários favorecerão diferentes soluções, por exemplo, só precisam ler parte de um arquivo uma vez (Zarr vai ganhar) , vs. precisa ler todo um arquivo uma vez, vs. precisa ler parte ou todo um arquivo repetidamente (<cacheFromUrl> vai ganhar).

Principalmente estamos dizendo: antes de nos apressarmos para fazer o esforço para armazenar todos os nossos dados em Zarr, vamos fazer alguns testes para ver se é realmente uma solução melhor.

- Não.

Lista de conjuntos de dados de tipos

Se você precisar de ajuda para escolher o tipo de conjunto de dados certo, consulte Escolhendo o Tipo de Conjunto de Dados .

Os tipos de conjuntos de dados caem em duas categorias. ( Porquê? )

EDDGrid

** EDDGrid ** datasets lidar com dados gradeados.
Em EDDGrid conjuntos de dados, variáveis de dados são arrays multidimensionais de dados.
Deve haver uma variável de eixo para cada dimensão. As variáveis de eixo devem ser especificadas na ordem em que as variáveis de dados as usam.
Em EDDGrid datasets, todas as variáveis de dados (Compartilhar) todas as variáveis do eixo. ( Porquê? E se não o fizerem? ) Novo em ERDDAP™ versão 2.29.0 com EDDGrid FromNcFiles é suporte experimental para variáveis de dados que não suportam todas as variáveis do eixo (ou como alguns chamaram dados 1D e 2D no mesmo conjunto de dados) .
Valores de dimensão classificados - Em tudo EDDGrid conjuntos de dados, cada dimensão deve estar em ordem ordenada (Ascendente ou descendente) . Cada um pode ser espaçado irregularmente. Não pode haver laços. Esta é uma exigência do Padrão de metadados CF . Se os valores de qualquer dimensão não estiverem em ordem ordenada, o conjunto de dados não será carregado e ERDDAP™ identificará o primeiro valor não ousado no arquivo de log, Diretriz de grande porte /logs/log.txt .

Algumas subclasses têm restrições adicionais (nomeadamente, EDDGrid AggregateExistingDimension exige que a dimensão externa (esquerda, primeira) seja ascendente.

Valores de dimensão não variados quase sempre indicam um problema com o conjunto de dados de origem. Isso ocorre mais comumente quando um arquivo mal nomeado ou inadequado está incluído na agregação, o que leva a uma dimensão de tempo não autorizada. Para resolver este problema, veja a mensagem de erro no ERDDAP™ arquivo log.txt para encontrar o valor de tempo ofensivo. Em seguida, procure nos arquivos de origem para encontrar o arquivo correspondente (ou um antes ou um após) Isso não pertence à agregação.

Veja a descrição mais completa do EDDGrid modelo de dados .
O EDDGrid tipos de conjuntos de dados são:
- EDDGrid A partir deAudioFiles agrega dados de um grupo de arquivos de áudio locais.
- EDDGrid A partir de lida com dados gradeados de DAP servidores.
- EDDGrid Tabela DED permite converter um conjunto de dados tabular em um conjunto de dados gradeado.
- EDDGrid De Erddap lida com dados gradeados de um remoto ERDDAP .
- EDDGrid De Etopo apenas lida com os dados de topografia ETOPO incorporados.
- EDDGrid Dos quartos é a superclasse de todos EDDGrid De aulas.
- EDDGrid A partir deMergeIRFiles agrega dados de um grupo de MergeIR local .gz arquivos.
- EDDGrid A partir de NcFiles agrega dados de um grupo de locais NetCDF (v3 ou v4) .nc e arquivos relacionados.
- EDDGrid A partir de NcFilesUnpacked é uma variante se EDDGrid FromNcFiles que também agrega dados de um grupo local NetCDF (v3 ou v4) .nc e arquivos relacionados, que ERDDAP™ desempacotar a um nível baixo.
- EDDGrid LonPM180 modifica os valores de longitude de uma criança EDDGrid de modo que eles estão no intervalo -180 a 180.
- EDDGrid Lon0360 modifica os valores de longitude de uma criança EDDGrid de modo que eles estão no intervalo 0 a 360.
- EDDGrid SideBySide agrega dois ou mais EDDGrid conjuntos de dados lado a lado.
- EDDGrid Dimensão existente agregada agrega dois ou mais EDDGrid conjuntos de dados, cada um dos quais tem uma gama diferente de valores para a primeira dimensão, mas valores idênticos para as outras dimensões.
- EDDGrid Entendido. pode fazer uma cópia local de outro EDDGrid 's dados e serve dados da cópia local.
Tudo EDDGrid datasets suportam uma configuração nThreads, que diz ERDDAP™ quantos threads usar ao responder a uma solicitação. Ver NTreads documentação para detalhes.

Tabela de EDD

Tabela de EDD datasets lidar com dados tabulares.
Os dados tabulares podem ser representados como uma tabela de banco de dados com linhas e colunas. Cada coluna (uma variável de dados) tem um nome, um conjunto de atributos e armazena apenas um tipo de dados. Cada linha tem uma observação (ou grupo de valores relacionados) . A fonte de dados pode ter os dados em uma estrutura de dados diferente, uma estrutura de dados mais complicada e / ou vários arquivos de dados, mas ERDDAP™ precisa ser capaz de achatar os dados de origem em uma tabela semelhante a banco de dados, a fim de apresentar os dados como um conjunto de dados tabular aos usuários de ERDDAP .
Veja a descrição mais completa do Modelo de dados EDDTable .
Os tipos de conjuntos de dados da EDDTable são:
- EDDTableDe todos os conjuntos de dados é um conjunto de dados de nível superior que tem informações sobre todos os outros conjuntos de dados em seu ERDDAP .
- EDDTable FromAsciiFiles agrega dados de vírgula, tab-, ponto-, ou arquivos de dados tabulares ASCII separados por espaço.
- EDDTable De AsciiService é a superclasse de todas as classes EDDTableFromAsciiService....
- EDDTable De ASciiServiceNOS lida com dados de alguns dos NOAA NOS serviços web.
- EDDTable FromAudioFiles agrega dados de um grupo de arquivos de áudio locais.
- Tabela de EDD TolsXmlFiles agrega dados de um conjunto de Estação de Tempo Automático (AWS) Arquivos XML.
- EDDTable FromCasandra lida com dados tabulares de uma tabela Cassandra.
- EDDTable FromColumnarAsciiFiles agrega dados de arquivos de dados ASCII tabular com colunas de dados de largura fixa.
- EDDTable FromDapSequence lida com dados tabulares de DAP servidores de sequência.
- EDDTable FromDatabase lida com dados tabulares de uma tabela de banco de dados.
- Tabela de EDD EDDGrid permite criar um conjunto de dados EDDTable a partir de um EDDGrid conjunto de dados.
- EDDTable FromErddap lida com dados tabulares de um remoto ERDDAP .
- EDDTable De Nomes de Arquivo cria um conjunto de dados a partir de informações sobre um grupo de arquivos no sistema de arquivos do servidor, mas não serve dados dentro dos arquivos.
- Tabela EDD dos arquivos é a superclasse de todas as classes EDDTableDe...Files.
- EDDTable FromHttpGet é ERDDAP O único sistema de importação de dados, bem como a exportação de dados.
- Tabela de EDD Hyrax Arquivos (DEPRIEDADE) agrega dados de arquivos com várias variáveis com dimensões compartilhadas servidas por uma Hyrax OPeNDAP servidor .
- EDDTable De InvalidCRAFiles agrega dados de NetCDF (v3 ou v4) .nc arquivos que usam um específico, inválido, variante do CF DSG Contiguous Ragged Array (CRA) arquivos. Embora ERDDAP™ suporta este tipo de arquivo, é um tipo de arquivo inválido que ninguém deve começar a usar. Grupos que atualmente usam este tipo de arquivo são fortemente encorajados a usar ERDDAP™ para gerar arquivos CF DSG CRA válidos e parar de usar esses arquivos.
- EDDTable FromJsonlCSVFiles agrega dados de JSON Linhas arquivos CSV .
- EDDTable FromMultidimNcFiles agrega dados de NetCDF (v3 ou v4) .nc arquivos com várias variáveis com dimensões compartilhadas.
- EDDTable FromMqtt constrói um conjunto de dados baseado em mensagens MQTT. Note que a documentação está em uma página dedicada. Note que existem muitas semelhanças com EDDTable FromHttpGet .
- EDDTable De NcFiles agrega dados de NetCDF (v3 ou v4) .nc arquivos com várias variáveis com dimensões compartilhadas. É bom continuar usando este tipo de conjunto de dados para conjuntos de dados existentes, mas para novos conjuntos de dados recomendamos usar EDDTableFromMultidimNcFiles em vez disso.
- EDDTable FromNcCFFiles agrega dados de NetCDF (v3 ou v4) .nc arquivos que usam um dos formatos de arquivo especificados pelo CF Geometrias de amostragem discretas (DSG) convenções. Mas para arquivos usando uma das variantes multidimensionais CF DSG, use EDDTable FromMultidimNcFiles Em vez disso.
- EDDTable De NccsvFiles agrega dados de NCCSV Arquivos ASCII .csv.
- EDDTable FromNOS (DEPRIEDADE) lida com dados tabulares de servidores XML NOS.
- EDDTable FromOBIS lida com dados tabulares de servidores OBIS.
- EDDTable FromParquetFiles lida com dados de Parquete .
- Tabela de EDD SOS lida com dados tabulares de SOS servidores.
- EDDTable FromThreddsFiles (DEPRIEDADE) agrega dados de arquivos com várias variáveis com dimensões compartilhadas servidas por uma TERCEIROS OPeNDAP servidor .
- Tabela de EDD WFS Arquivos (DEPRIEDADE) faz uma cópia local de todos os dados de uma ArcGIS MapaServer WFS servidor para que os dados possam então ser re-servados rapidamente para ERDDAP™ usuários.
- EDDTable agregados pode fazer um conjunto de dados EDDTable de um grupo de conjuntos de dados EDDTable.
- EDDTableCopy pode fazer uma cópia local de muitos tipos de conjuntos de dados EDDTable e, em seguida, reserve os dados rapidamente a partir da cópia local.

- Não.

Descrições detalhadas de tipos de conjuntos de dados

EDDGrid A partir de

** EDDGrid A partir de** manipula variáveis de grade de DAP servidores.

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode coletar as informações que você precisa para ajustar isso ou criar seu próprio XML para um EDDGrid Dataset FromDap analisando os arquivos DDS e DAS do conjunto de dados de origem no seu navegador (adicionando .das e .dds ao sourceUrl Por exemplo, https://thredds1.pfeg.noaa.gov/thredds/dodsC/satellite/BA/ssta/5day.dds ) .
EDDGrid FromDap pode obter dados de qualquer variável multidimensional de uma DAP servidor de dados. (Anteriormente... EDDGrid FromDap foi limitado a variáveis designadas como "grid", mas isso não é mais um requisito.)
Valores de dimensão classificados - Os valores para cada dimensão devem estar em ordem ordenada (Ascendente ou descendente) . Os valores podem ser espaçados de forma irregular. Não pode haver laços. Esta é uma exigência do Padrão de metadados CF . Se os valores de qualquer dimensão não estiverem em ordem ordenada, o conjunto de dados não será carregado e ERDDAP™ identificará o primeiro valor não ousado no arquivo de log, Diretriz de grande porte /logs/log.txt .

EDDGrid Do esqueleto de DNA XML

<dataset type="EDDGridFromDap" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaWMS>...</accessibleViaWMS> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <nThreads>...</nThreads> 
      <dimensionValuesInMemory>...</dimensionValuesInMemory> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <addAttributes>...</addAttributes> 
      <axisVariable>...</axisVariable> 
      <dataVariable>...</dataVariable> 
    </dataset>

EDDGrid Tabela DED

** EDDGrid Tabela DED** permite converter um conjunto de dados tabulares EDDTable em um EDDGrid conjunto de dados gradeados. Lembre-se que ERDDAP™ trata conjuntos de dados como conjuntos de dados gradeados (subclasses de EDDGrid ) ou conjuntos de dados tabulares (subclasses de EDDTable) .

Normalmente, se você tiver dados em grade, você apenas configurou um EDDGrid conjunto de dados diretamente. Às vezes isso não é possível, por exemplo, quando você tem os dados armazenados em um banco de dados relacional que ERDDAP™ só pode acessar via EDDTableFromDatabase. EDDGrid A classe FromEDDTable permite remediar essa situação.
Obviamente, os dados no conjunto de dados EDDTable subjacente devem ser (basicamente) dados gradeados, mas em uma forma tabular. Por exemplo, o conjunto de dados EDDTable pode ter dados CTD: medições de corrente para leste e para o norte, em várias profundidades, em várias vezes. Uma vez que as profundidades são as mesmas em cada ponto do tempo, EDDGrid A FromEDDTable pode criar um conjunto de dados em grade com um tempo e uma dimensão de profundidade que acessa os dados através do conjunto de dados EDDTable subjacente.
Gerar conjuntos de dados Xml... Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode reunir as informações que você precisa para melhorar o rascunho áspero.
Fonte Atributos -- Tal como acontece com todos os outros tipos de conjuntos de dados, EDDGrid FromTable tem a ideia de que existem fontes globaisAttributes e global global addAttributes (especificado em datasets.xml ) , que são combinados para fazer a combinação global Atributos, que são o que os usuários vêem. Para fontes globaisAttributes, EDDGrid A FromEDDTable usa a combinação global Atributos do conjunto de dados EDDTable subjacente. (Se pensares nisso por um minuto, faz sentido.)

Da mesma forma, para cada axisVariable ' dataVariable ' addAttributes , EDDGrid FromEDDTable usa a variável combinada Atributos do conjunto de dados EDDTable subjacente como EDDGrid Fonte da variávelEDDTableAttributes. (Se pensares nisso por um minuto, faz sentido.)

Como consequência, se a Tabela EDD tiver bons metadados, o EDDGrid FromEDDTable muitas vezes precisa muito pouco addAttributes metadados - apenas alguns ajustes aqui e ali.

dataVariable - Sim. axisVariable s... A tabela EDD subjacente tem apenas dataVariable S. Um EDDGrid Dataset da TabelaEDD terá alguns axisVariable S (criado a partir de alguns dos EDDTable dataVariable S) e alguns dataVariable S (criada a partir da tabela EDD restante dataVariable S) . Gerar conjuntos de dadosXml fará um palpite sobre o qual EDDTable dataVariable deve tornar-se EDDGrid Tabela DED axisVariable s, mas é apenas um palpite. Você precisa modificar a saída de GerarDatasetsXml para especificar qual dataVariable se tornará axisVariable s, e em que ordem.
eixoValues -- Não há nada sobre o EDDTable subjacente para contar EDDGrid FromEDDTable os valores possíveis do axisVariable s na versão gradeada do conjunto de dados, então você deve fornecer essas informações para cada axisVariable através de um desses atributos:
- eixoValues -- permite especificar uma lista de valores. Por exemplo, <Nome do att="axisValues" Tipo="doubleList" \>2, 2.5, 3, 3.5, 4</att> Note o uso de um tipo de dados mais a lista de palavras. Além disso, o tipo de lista (por exemplo, duplo) , DEVE corresponder aos dados Tipo da variável na tabela EDD e EDDGrid Conjuntos de dados da TabelaEDD.
- eixoValuesStartStrideStop -- permite especificar uma sequência de valores regularmente espaçados especificando os valores de início, passada e parada. Aqui está um exemplo que é equivalente ao eixoValues exemplo acima: <Nome do anúncio: Tipo="doubleList" \>2, 0.5, 4</att> Novamente, note o uso de um tipo de dados de lista. Além disso, o tipo de lista (por exemplo, duplo) , DEVE corresponder aos dados Tipo da variável na tabela EDD e EDDGrid Conjuntos de dados da TabelaEDD.

Atualizações... Assim como não há como EDDGrid FromEDDTable para determinar o eixoValues da tabela EDD inicialmente, não há também nenhuma maneira confiável para EDDGrid FromEDDTable para determinar a partir da tabela EDD quando o eixoValues mudou (notavelmente, quando há novos valores para a variável de tempo) . Atualmente, a única solução é mudar o atributo eixoValues em datasets.xml e recarregar o conjunto de dados. Por exemplo, você pode escrever um script para

Pesquisar datasets.xml para datasetID = o conjunto de dadosID " assim você está trabalhando com o conjunto de dados correto.
Pesquisar datasets.xml para a próxima ocorrência de o viáveissourceName
então você está trabalhando com a variável correta.
Pesquisar datasets.xml para a próxima ocorrência de

        <att name="axisValuesStartStrideStop" type="doubleList">

para que você saiba a posição inicial da tag. 4. Pesquisar datasets.xml para a próxima ocorrência de

        </att>

para que você conheça a posição final dos valores do eixo. 5. Substitua o antigo início, passo, pare os valores com os novos valores. 6. Contactar URL da bandeira para o conjunto de dados para contar ERDDAP™ para recarregar o conjunto de dados.

Isto não é ideal, mas funciona.

precisão -- Quando EDDGrid FromEDDTable responde ao pedido de dados de um usuário, ele move uma linha de dados da tabela de resposta EDDTable para a EDDGrid grade de resposta. Para fazer isso, ele tem que descobrir se os valores "axis" em uma determinada linha na tabela correspondem a alguma combinação de valores de eixo na grade. Para tipos de dados inteiros, é fácil determinar se dois valores são iguais. Mas para carros e dobras, isso traz o problema horrível de números de ponto flutuante não combinando exatamente . (por exemplo, 0,2 versus 0,199999999999996) . Para (tentar tentar) Trata disto. EDDGrid FromTable permite especificar um atributo de precisão para qualquer um dos axisVariable s, que especifica o número total de dígitos decimais que devem ser idênticos.
- Por exemplo,<att name="precision" type="int">5</att>
- Para diferentes tipos de variáveis de dados, existem diferentes valores de precisão padrão. Os padrões são geralmente apropriados. Se eles não forem, você precisa especificar valores diferentes.
- Para axisVariable que são tempo ou tempo Variáveis do carimbo , o padrão é de precisão completa (uma correspondência exata) .
- Para axisVariable s que são flutuadores, a precisão padrão é 5.
- Para axisVariable s que são duplos, a precisão padrão é 9.
- Para axisVariable s que têm tipos de dados inteiros, EDDGrid FromEDDTable ignora o atributo de precisão e sempre usa a precisão completa (uma correspondência exata) .
- ATENÇÃO! Ao fazer a conversão de um pedaço de dados tabular em um pedaço de dados gradeados, se EDDGrid FromEDDTable não pode corresponder a um valor EDDTable "axis" a um dos esperados EDDGrid Valores do eixo da TabelaEDD, EDDGrid FromEDDTable silenciosamente (sem erro) desperdiça os dados dessa linha da tabela. Por exemplo, pode haver outros dados (não na grade) no conjunto de dados EDDTable. (E se esticar > 1, não é óbvio para EDDGrid De Tabela quais valores de eixo são valores desejados e quais são os que devem ser ignorados por causa do passo.) Então, se os valores de precisão são muito altos, o usuário verá valores ausentes na resposta de dados quando os valores de dados válidos realmente existem.

Por outro lado, se os valores de precisão são definidos muito baixos, os valores "axis" da EDDTable que não devem corresponder EDDGrid Valores do eixo da TabelaDED (erroneamente) Combinado.

Esses problemas potenciais são horríveis, porque o usuário obtém os dados errados (ou valores ausentes) quando eles devem obter os dados certos (ou pelo menos uma mensagem de erro) . Isto não é uma falha EDDGrid Da Tabela. EDDGrid FromTable não pode resolver este problema. O problema é inerente à conversão de dados tabulares em dados gradeados (a menos que outras suposições possam ser feitas, mas não podem ser feitas aqui) . Cabe a você, o ERDDAP™ administrador, para teste seu EDDGrid Da Tabela DED cuidadosamente para garantir que os valores de precisão sejam definidos para evitar esses problemas potenciais.

lacunas

lacunas - ... Este é um tipo muito incomum de conjunto de dados. Desde os tipos de consultas que podem ser feitas (manuseado por) um EDDGrid conjunto de dados (relacionados com as gamas e eixos do axisVariable S) são muito diferentes dos tipos de consultas que podem ser feitas (manuseado por) um conjunto de dados EDDTable (apenas relacionado às gamas de algumas variáveis) , o desempenho de EDDGrid Os conjuntos de dados da FromEDDTable variam muito dependendo da solicitação exata que é feita e da velocidade do conjunto de dados EDDTable subjacente. Para pedidos que tenham um valor de passo > 1, EDDGrid FromEDDTable pode pedir a tabela EDD subjacente para um pedaço relativamente grande de dados (como se estivéssemos) e, em seguida, peneirar os resultados, mantendo os dados de algumas linhas e desperdiçando os dados de outros. Se ele tiver que peneirar através de muitos dados para obter os dados que ele precisa, a solicitação levará mais tempo para preencher.

Se EDDGrid FromEDDTable pode dizer que haverá grandes lacunas (com linhas de dados indesejados) entre as linhas com dados desejados, EDDGrid A FromEDDTable pode optar por fazer vários sub-requisitos para a EDDTable subjacente em vez de um grande pedido, ignorando assim as linhas indesejadas de dados nas grandes lacunas. A sensibilidade para esta decisão é controlada pelo gapThreshold valor como especificado no<gapThreshold> tag (default=1000 linhas de dados de origem) . Definir lacunaAtenção de um número menor levará ao conjunto de dados (em geral) mais sub-requisitos. Definir lacunaAtenção de um número maior levará ao conjunto de dados (em geral) menos sub-requisitos.

Se gapThreshold é definido muito pequeno, EDDGrid A FromEDDTable operará mais lentamente porque a sobrecarga de várias solicitações será maior do que o tempo salvo, obtendo alguns dados em excesso. Se o gapThreshold estiver muito grande, EDDGrid A FromEDDTable operará mais lentamente porque tanto excesso de dados será recuperado da EDDTable, apenas para ser descartado. (Como Goldilocks descobriu, o meio é "apenas certo".) A sobrecarga para diferentes tipos de conjuntos de dados EDDTable varia muito, então a única maneira de saber a melhor configuração real para o seu conjunto de dados é através de experimentação. Mas você não vai ficar muito errado aderindo ao padrão.

Um exemplo simples é: Imagine um EDDGrid Da Tabela com apenas um axisVariable (tempo, com um tamanho de 100000) Um dataVariable (temperatura) , e a lacuna padrãoThreshold de 1000.

Se um usuário solicitar temperatura \[ 0💯5000 \] , o passo é 100 assim o tamanho da lacuna é 99, o que é menos do que o gapThreshold. Então... EDDGrid A FromTable fará apenas um pedido à EDDTable para todos os dados necessários para a solicitação (equivalente à temperatura \[ 0:5000 \] ) e jogar fora todas as linhas de dados que não precisa.
Se um usuário solicitar temperatura \[ 0:2500:5000 \] , esse passo é 2500 assim o tamanho da lacuna é 2499, que é maior do que o gapThreshold. Então... EDDGrid A FromTable fará solicitações separadas à EDDTable que são equivalentes à temperatura \[ 0 \] , temperatura \[ 2500 \] , temperatura \[ 5000. \] .

A cálculo do tamanho da lacuna é mais complicada quando há vários eixos.

Para cada solicitação de usuário, EDDGrid FromEDDTable imprime mensagens diagnósticas relacionadas a isso no - Não. ficheiro.

Se...<logLevel> (#loglevel) em datasets.xml está definido para info, isto imprime uma mensagem como \* nOuterAxes=1 de 4 nOuterRequests=22 Se nOuterAxes=0, gapThreshold não foi excedido e apenas um pedido será feito para EDDTable. Se nOuterAxes>0, gapThreshold foi excedido e nOuterRequests será feita para EDDTable, correspondente a cada combinação solicitada do nOuterAxes mais esquerdo. Por exemplo, se o conjunto de dados tiver 4 axisVariable e dataVariable como a oriente \[ Tempo \] \[ latitude \] \[ longitude \] \[ profundidade \] , o mais esquerdo (Primeiro) variável eixo é tempo.
Se<logLevel> em datasets.xml é definido para todos, informações adicionais são escritas para o arquivo log.txt.

EDDGrid Esquema de tabelas XML

<dataset type="EDDGridFromEDDTable" datasetID\="..." active\="..." >
    <accessibleTo>...</accessibleTo> 
    <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
    <accessibleViaWMS>...</accessibleViaWMS> 
    <reloadEveryNMinutes>...</reloadEveryNMinutes> 
    <updateEveryNMillis>...</updateEveryNMillis> 
    <gapThreshold>...</gapThreshold> 
    <defaultGraphQuery>...</defaultGraphQuery> 
    <fgdcFile>...</fgdcFile> 
    <iso19115File>...</iso19115File> 
    <onChange>...</onChange> 
    <addAttributes>...</addAttributes> 
    <axisVariable>...</axisVariable> 
    <dataVariable>...</dataVariable> 
    <dataset>...</dataset> 
</dataset>

EDD ERDDAP

** EDDGrid De Erddap** lida com dados gradeados de um remoto ERDDAP™ servidor. EDDTable FromErddap lida com dados tabulares de um remoto ERDDAP™ servidor.

EDDGrid FromErddap e EDDTableFromErddap se comportam de forma diferente de todos os outros tipos de conjuntos de dados em ERDDAP .
Como outros tipos de conjuntos de dados, esses conjuntos de dados obtêm informações sobre o conjunto de dados da fonte e mantê-lo na memória.
Como outros tipos de conjuntos de dados, quando ERDDAP™ pesquisas para conjuntos de dados, exibe o formulário de acesso de dados ( * datasetID * .html) , ou exibe o formulário Make A Graph ( * datasetID * .) , ERDDAP™ usa a informação sobre o conjunto de dados que está na memória.
EDDGrid FromErddap e EDDTable FromErddap são a base para grades/clusters/federações de ERDDAP s, que eficientemente distribuir o uso da CPU (principalmente para fazer mapas) , uso de memória, armazenamento de dataset e uso de largura de banda de um grande data center.

Redirecionar

Ao contrário de outros tipos de conjuntos de dados, quando ERDDAP™ recebe um pedido de dados ou imagens desses conjuntos de dados, ERDDAP redirecionamentos o pedido ao remoto ERDDAP™ servidor. O resultado é:
- Isto é muito eficiente. (CPU, memória e largura de banda) , porque de outra forma
  1. O composto ERDDAP™ tem que enviar o pedido para o outro ERDDAP™ (que leva tempo) .
  2. O outro ERDDAP™ tem que obter os dados, reformatar e transmitir os dados para o composto ERDDAP .
  3. O composto ERDDAP™ tem de receber os dados (usando largura de banda) , reformatar (usando CPU e memória) , e transmitir os dados ao usuário (usando largura de banda) . Redirecionando o pedido e permitindo o outro ERDDAP™ para enviar a resposta diretamente ao usuário, o composto ERDDAP™ gasta essencialmente nenhum tempo de CPU, memória ou largura de banda no pedido.
- O redirecionamento é transparente para o usuário, independentemente do software cliente (um navegador ou qualquer outro software ou ferramenta de linha de comando) .
Você pode dizer ERDDAP™ não redirecionar quaisquer solicitações de usuário, definindo<redirecionar>false</redirect>, mas isso nega a maioria das vantagens do tipo de conjunto de dados... FromErddap (notavelmente, dispersando a carga na extremidade dianteira ERDDAP™ para o remoto / backend ERDDAP ) .

Subscrições

Normalmente, quando um EDDGrid FromErddap e EDDTable De Erddap são (re) carregado em seu ERDDAP , eles tentam adicionar uma assinatura ao conjunto de dados remoto através do remoto ERDDAP Sistema de assinatura por e-mail/URL. Assim, sempre que o conjunto de dados remoto muda, o remoto ERDDAP™ contactos conjunto de dados URL da bandeira em seu ERDDAP™ de modo que o conjunto de dados local é recarregado ASAP e de modo que o conjunto de dados local está sempre perfeitamente atualizado e imita o conjunto de dados remoto. Então, a primeira vez que isso acontece, você deve obter um e-mail solicitando que você valide a assinatura. No entanto, se o local ERDDAP™ não pode enviar um e-mail ou se o remoto ERDDAP 's sistema de assinatura de e-mail/URL não está ativo, você deve enviar e-mail para o remoto ERDDAP™ administrador e solicitar que ele/ela adicione manualmente [<em Mudança> (#onchange #) ...</onChange> tags para todos os conjuntos de dados relevantes para chamar o seu conjunto de dados conjunto de dados URLs de bandeira . Veja o seu ERDDAP™ relatório diário para uma lista de setDataset Bandeira URLs, mas basta enviar os para EDDGrid FromErddap e EDDTableDe conjuntos de dados Erddap para o remoto ERDDAP™ Administrador.

Isto não está a funcionar? Seus conjuntos de dados locais não estão em sincronia com os conjuntos de dados remotos? Várias coisas devem funcionar corretamente para que este sistema funcione para que seus conjuntos de dados permaneçam atualizados. Verifique cada uma dessas coisas em ordem:

Tu és ERDDAP™ deve ser capaz de enviar e-mails. Consulte as configurações de e-mail em seu setup.xml.
Em geral (mas nem sempre) , seu ERDDAP '<baseUrl> e<baseHttpsUrl> não tem um número de porta (por exemplo, :8080, :8443) . Se o fizerem, usem um proxy para remover a porta do Url.
Em seu setup.xml,<assinaToRemoteErddapDataset> deve ser definido como verdadeiro.
Quando o seu EDD local... O conjunto de dados do FromErddap é recarregado, ele deve enviar uma solicitação para o remoto ERDDAP™ para se inscrever no conjunto de dados remoto. Olhe em log.txt para ver se isto está acontecendo.
Você deve obter um e-mail pedindo-lhe para validar o pedido de assinatura.
Você deve clicar no link nesse e-mail para validar o pedido de assinatura.
O controle remoto ERDDAP™ deve dizer que a validação foi bem sucedida. A qualquer momento, você pode solicitar um e-mail do remoto ERDDAP™ com uma lista de suas assinaturas pendentes e válidas. Ver o formulário Sistema de segurança Url. /erddap/subscriptions/list.html .
Quando o conjunto de dados remoto muda (por exemplo, obtém dados adicionais) , o remoto ERDDAP™ deve tentar entrar em contato com o flagURL em seu ERDDAP . Você não pode verificar isso, mas você pode perguntar ao administrador do remoto ERDDAP™ para verificar isto.
Tu és ERDDAP™ deve receber um pedido para definir esse flagURL. Olhe em seu log.txt para "setDatasetFlag.txt?" pedido (S) e veja se há uma mensagem de erro associada aos pedidos.
Tu és ERDDAP™ deve então tentar recarregar esse conjunto de dados (talvez não imediatamente, mas ASAP) .

Máximo actualizado (Tempo) ?

EDDGrid /TableFromErddap datasets só muda suas informações armazenadas sobre cada conjunto de dados de origem quando o conjunto de dados de origem é "recarregar" e algumas mudanças de metadados (por exemplo, a variável de tempo actual\_range ) , gerando assim uma notificação de assinatura. Se o conjunto de dados de origem tiver dados que mudam frequentemente (por exemplo, novos dados a cada segundo) e usa o "update" sistema para notar mudanças freqüentes nos dados subjacentes, o EDDGrid /TableFromErddap não será notificado sobre essas mudanças frequentes até que o próximo conjunto de dados "recarregar", de modo que o EDDGrid /TableFromErddap não estará perfeitamente atualizado. Você pode minimizar esse problema alterando o conjunto de dados de origem<reloadEveryNMinutes> para um valor menor (60? 15?) para que haja mais notificações de assinatura para dizer o EDDGrid /TableFromErddap para atualizar suas informações sobre o conjunto de dados de origem.

Ou, se o seu sistema de gerenciamento de dados souber quando o conjunto de dados de origem tem novos dados (por exemplo, através de um script que copia um arquivo de dados no lugar) , e se isso não é super frequente (por exemplo, a cada 5 minutos, ou menos frequentes) Há uma solução melhor:

Não use<updateEveryNMillis> para manter o conjunto de dados de origem atualizado.
Defina o conjunto de dados de origem<reloadEveryNMinutes> para um número maior (1440?) .
Tenha o script em contato com o conjunto de dados de origem URL da bandeira logo após ele copia um novo arquivo de dados no lugar.

Isso levará ao conjunto de dados de origem perfeitamente atualizado e fará com que ele gere uma notificação de assinatura, que será enviada para a EDDGrid /TableFromErddap conjunto de dados. Isso vai liderar o EDDGrid /TableFromErddap dataset para estar perfeitamente atualizado (bem, dentro de 5 segundos de novos dados sendo adicionados) . E tudo o que será feito de forma eficiente (sem recargas de dados desnecessários) .

Não. addAttributes , axisVariable ou dataVariable

Ao contrário de outros tipos de conjuntos de dados, EDDTableFromErddap e EDDGrid Os conjuntos de dados do FromErddap não permitem que o global<addAttributes>,< axisVariable > ou< dataVariable > seções no datasets.xml para esse conjunto de dados. O problema é que permitir que aqueles levariam a inconsistências:

Digamos que foi permitido e você adicionou um novo atributo global.
Quando um usuário pergunta a você ERDDAP™ para os atributos globais, o novo atributo aparecerá.
Mas quando um usuário pergunta a você ERDDAP™ para um arquivo de dados, seu ERDDAP™ redireciona o pedido para a fonte ERDDAP . Isso. ERDDAP™ é inconsciente do novo atributo. Então, se ele criar um arquivo de dados com metadados, por exemplo, um .nc arquivo, os metadados não terão o novo atributo.

Há duas soluções:

Convencer o administrador da fonte ERDDAP™ para fazer as mudanças que você deseja aos metadados.
Em vez de EDDTableFromErddap, use EDDTable FromDapSequence . Ou em vez de EDDGrid FromErddap, use EDDGrid A partir de . Esses tipos EDD permitem que você se conecte eficientemente a um conjunto de dados em um remoto ERDDAP™ (mas sem redirecionar solicitações de dados) e eles permitem que você inclua global<addAttributes>,< axisVariable > ou< dataVariable > seções no datasets.xml . Uma outra diferença: você precisará se inscrever manualmente no conjunto de dados remoto, de modo que o conjunto de dados em seu ERDDAP™ será notificado (através do URL da bandeira ) quando houver alterações no conjunto de dados remoto. Assim, você está criando um novo conjunto de dados, em vez de vincular a um conjunto de dados remoto.

Outras notas

Por razões de segurança, EDDGrid FromErddap e EDDTable De Erddap não apoiar o [<acessível para> (Acessível a) tag e não pode ser usado com conjuntos de dados remotos que exigem login (porque eles usam [<acessível para> (Acessível a) ). Ver ERDDAP ' sistema de segurança para restringir o acesso a alguns conjuntos de dados a alguns usuários.
Começar com ERDDAP™ v2.10, EDDGrid FromErddap e EDDTableFromErddap apoiar o [<acessívelViaFiles>] (#acessível através de arquivos) tag. Ao contrário de outros tipos de conjuntos de dados, o padrão é verdadeiro, mas os arquivos do conjunto de dados serão acessíveis apenas se o conjunto de dados de origem também tiver<acessívelViaFiles> definido como true.
Você pode usar o Gerar conjuntos de dados Programa Xml para fazer o datasets.xml chunk para este tipo de conjunto de dados. Mas você pode fazer esses tipos de conjuntos de dados facilmente à mão.

EDDGrid esqueleto de Erddap XML

EDDGrid esqueleto de Erddap O conjunto de dados XML é muito simples, porque a intenção é apenas imitar o conjunto de dados remoto que já é adequado para uso em ERDDAP :

<dataset type="EDDGridFromErddap" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> 
      <accessibleViaFiles>...</accessibleViaFiles> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <nThreads>...</nThreads> 
      <dimensionValuesInMemory>...</dimensionValuesInMemory> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <redirect>true(default)|false</redirect> 
  </dataset>

EDDTable FromErddap esqueleto XML

O esqueleto XML para um conjunto de dados EDDTableFromErddap é muito simples, porque a intenção é apenas imitar o conjunto de dados remoto, que já é adequado para uso em ERDDAP :

<dataset type="EDDTableFromErddap" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <redirect>true(default)|false</redirect> 
  </dataset>

EDDGrid De Etopo

** EDDGrid De Etopo** apenas serve o ETOPO1 Global 1-Minute Gridded Elevation Data Set (Superfície do gelo, grade registrada, binária, 2byte int: etopo1\_ice\_g\_i2 .zip ) que é distribuído com ERDDAP .

Apenas dois. datasetID s são suportados para EDDGrid FromEtopo, para que você possa acessar os dados com valores de longitude -180 a 180, ou valores de longitude 0 a 360.
Nunca há sub tags, uma vez que os dados já estão descritos dentro ERDDAP .
Então as duas opções para EDDGrid Os conjuntos de dados do FromEtopo são (literalmente) :

      <!-- etopo180 serves the data from longitude -180 to 180 -->
      <dataset type="EDDGridFromEtopo" datasetID="etopo180" /> 
      <!-- etopo360 serves the data from longitude 0 to 360 -->
      <dataset type="EDDGridFromEtopo" datasetID="etopo360" /> 

EDDGrid Dos quartos

** EDDGrid Dos quartos** é a superclasse de todos EDDGrid De aulas. Não podes usar EDDGrid Dos Ficheiros directamente. Em vez disso, use uma subclasse de EDDGrid FromFiles para lidar com o tipo de arquivo específico:

EDDGrid A partir deMergeIRFiles lida com dados de grade Mergeir .gz arquivos.
EDDGrid A partir deAudioFiles agrega dados de um grupo de arquivos de áudio locais.
EDDGrid A partir de NcFiles lida com dados de grade GRIB .grb arquivos, HDF (v4 ou v5) .hdf arquivos, .nc ml arquivos, e NetCDF (v3 ou v4) .nc arquivos. Isso pode funcionar com outros tipos de arquivo (por exemplo, BUFR) , nós apenas não testamos - por favor envie-nos alguns arquivos de amostra se você estiver interessado.
EDDGrid A partir de NcFilesUnpacked é uma variante de EDDGrid FromNcFiles que lida com dados de gradeado NetCDF (v3 ou v4) .nc e arquivos relacionados, que ERDDAP™ desempacotar a um nível baixo.

Atualmente, nenhum outro tipo de arquivo é suportado. Mas geralmente é relativamente fácil adicionar suporte para outros tipos de arquivo. Contacte-nos se tiver um pedido. Ou, se seus dados estão em um formato de arquivo antigo que você gostaria de se afastar, recomendamos converter os arquivos para ser NetCDF v3 .nc arquivos. NetCDF é um formato binário amplamente suportado, permite acesso aleatório rápido aos dados, e já é suportado por ERDDAP .

De Detalhes de Arquivos

As seguintes informações aplicam-se a todas as subclasses de EDDGrid Dos Ficheiros.

Agregação de uma dimensão existente

Todas as variações de EDDGrid FromFiles pode agregar dados de arquivos locais, onde cada arquivo tem 1 (ou mais) valores diferentes para a esquerda (Primeiro) dimensão, geralmente \[ Tempo \] , que será agregado. Por exemplo, as dimensões podem ser \[ Tempo \] \[ altitude \] \[ latitude \] \[ longitude \] , e os arquivos podem ter os dados para um (ou alguns) valor de tempo (S) por arquivo. O conjunto de dados resultante aparece como se todos os dados do arquivo tivessem sido combinados. As grandes vantagens da agregação são:

O tamanho do conjunto de dados agregado pode ser muito maior do que um único arquivo pode ser convenientemente (~2GB) .
Para dados quase em tempo real, é fácil adicionar um novo arquivo com o mais recente pedaço de dados. Você não precisa reescrever todo o conjunto de dados.

Os requisitos para agregação são:

Os arquivos locais não precisam ter o mesmo dataVariable S (como definido no conjunto de dados datasets.xml ) . O conjunto de dados terá dataVariable s definido em datasets.xml . Se um determinado arquivo não tiver um dado dataVariable , ERDDAP™ adicionará valores ausentes conforme necessário.
Todos os dataVariable s DEVE usar o mesmo axisVariable s/dimensão (como definido no conjunto de dados datasets.xml ) . Os arquivos serão agregados com base no primeiro (mais à esquerda) dimensão, ordenado em ordem ascendente.
Cada arquivo MAY tem dados para um ou mais valores da primeira dimensão, mas não pode haver nenhuma sobreposição entre arquivos. Se um arquivo tem mais de um valor para a primeira dimensão, os valores devem ser classificados em ordem ascendente, sem laços.
Todos os arquivos DEVE ter exatamente os mesmos valores para todas as outras dimensões. A precisão dos testes é determinada por Jogos de Vestir .
Todos os arquivos DEVE ter exatamente o mesmo unidades metadados para todos axisVariable e dataVariable S. Se este é um problema, você pode ser capaz de usar NcML ou NCO para corrigir o problema.

Agregação através de nomes de arquivo ou metadados globais

Todas as variações de EDDGrid FromFiles também pode agregar um grupo de arquivos adicionando um novo leftmost (Primeiro) dimensão, geralmente tempo, com base em um valor derivado de cada nome de arquivo ou do valor de um atributo global que está em cada arquivo. Por exemplo, o nome do arquivo pode incluir o valor do tempo para os dados no arquivo. ERDDAP™ então criaria uma nova dimensão do tempo.

Ao contrário do recurso semelhante em THREDDS, ERDDAP™ sempre cria um axisVariable com valores numéricos (conforme exigido por CF) , nunca Valores de caracteres (que não são permitidos por CF) . Também, ERDDAP™ irá classificar os arquivos na agregação com base no numérico axisVariable valor que é atribuído a cada arquivo, de modo que a variável eixo sempre terá valores ordenados conforme exigido por CF. A abordagem THREDDS de fazer um tipo lexicográfico baseado nos nomes de arquivos leva a agregações onde os valores do eixo não são classificados (que não é permitido por CF) quando o nome do arquivo é diferente do derivado axisVariable valores.

Criar uma dessas agregaçãos ERDDAP™ , você vai definir uma nova esquerda (Primeiro) axisVariable com um especial, pseudo< sourceName >, que diz ERDDAP™ onde e como encontrar o valor para a nova dimensão de cada arquivo.

O formato para o pseudo sourceName que recebe o valor de um nome de arquivo (apenas nome de arquivo.ext) é \\\ fileName, dados Tipo , Extrato , capturaGrupoNumber*
O formato para o pseudo sourceName que recebe o valor do nome do caminho absoluto de um arquivo é \\\ pathName, dados Tipo , Extrato , capturaGrupoNumber* \[ Para isso, o nome do caminho sempre usa '/' como o personagem separador de diretório, nunca ''. \]
O formato para o pseudo sourceName que obtém o valor de um atributo global é \\\ global: atributos Nome , dados Tipo , Extrato , capturaGrupoNumber*
Este pseudo sourceName opção funciona de forma diferente dos outros: em vez de criar uma nova esquerda (Primeiro) axisVariable , isto substitui o valor da corrente axisVariable com um valor extraído do nome do arquivo (apenas nome de arquivo.ext) . O formato é \\\ substituir De FileName, dados Tipo , Extrato , capturaGrupoNumber*

As descrições das peças que você precisa fornecer são:

atributos Nome -- o nome do atributo global que está em cada arquivo e que contém o valor da dimensão.
dados Tipo - ... Isso especifica o tipo de dados que será usado para armazenar os valores. Veja a lista padrão de dados Tipos que ERDDAP™ suportes, exceto que String não é permitido aqui desde variáveis de eixo em ERDDAP™ não pode ser variáveis de corda.

Há um pseudo dataType adicional, timeFormat= string TimeFormat , que diz ERDDAP™ que o valor é um String timeStamp unidades adequadas para tempos de cadeia . Na maioria dos casos, o stringTimeFormat que você precisa será uma variação de um desses formatos:

yyyy-MM-dd «T'HH:mm:ss.SSSZ -- que ISO 8601:2004 (E) formato de data time. Você pode precisar de uma versão encurtada disto, por exemplo, yyyy-MM-dd 'T'HH: mm: ss ou yyyy-MM-dd .
yyyyyMMddHHmmss.SSS -- que é a versão compacta do formato de hora de data ISO 8601. Você pode precisar de uma versão encurtada disto, por exemplo, yyyyyMMddHHmmss ou yyyyyMMdd.
M/d/yyyyyy H:mm:ss.SSS -- que é o formato de data slash dos EUA. Você pode precisar de uma versão encurtada deste, por exemplo, M/d/yyyyy .
yyyyDDDHHmmssSSS - que é o ano mais o dia acolchoado zero do ano (por exemplo, 001 = 1 de janeiro de 365 = 31 de dezembro em um ano não-leap; isso é às vezes erroneamente chamado de data Juliana) . Você pode precisar de uma versão encurtada deste, por exemplo, yyyyyDDD .

Se você usar esse pseudo dataType, adicione isso à nova variável< addAttributes >

        <att name="units">seconds since 1970-01-01T00:00:00Z</att>

Se você quiser mudar todos os valores de tempo, mude o valor do tempo em unidades, por exemplo, 1970-01T12:00Z.

Extrato - ... Este é o expressão regular ( tutorial ) que inclui um grupo de captura (em parênteses) que descreve como extrair o valor do nome do arquivo ou do valor do atributo global. Por exemplo, dado um nome de arquivo como S19980011998031.L3b\_MO\_CHL .nc , grupo de captura #1, "\ \dtutorial ", na expressão regular S (\ \dtutorial ) \ \dtutorial \.L3b.\* irá capturar os primeiros 7 dígitos após 'S': 1998001.
capturaGrupoNumber - ... Este é o número do grupo de captura (dentro de um par de par) na expressão regular que contém a informação de interesse. É geralmente 1, o primeiro grupo de captura. Às vezes você precisa usar grupos de captura para outros fins no regex, então o número importante do grupo de captura será 2 (o segundo grupo de captura) ou 3 (o terceiro) , etc.

Um exemplo completo de um axisVariable que faz um conjunto de dados agregado com um novo eixo de tempo que recebe os valores de tempo do nome do arquivo de cada arquivo é

      <axisVariable>
        <sourceName>\\*\\*\\*fileName,timeFormat=yyyyDDD,S(\\d{7})\\.L3m.\\*,1</sourceName>
        <destinationName>time</destinationName>
      </axisVariable>

Quando você usa os dados pseudo "timeFormat=" Tipo, ERDDAP™ adicionará 2 atributos ao axisVariable para que pareçam vir da fonte:

    <att name="standard\\_name">time</att>  
    <att name="units">seconds since 1970-01-01T00:00:00Z</att>  

Neste caso, ERDDAP™ criará um novo eixo nomeado "time" com valores duplos (segundos desde 1970-01-01T00:00:00Z) extraindo os 7 dígitos após 'S' e antes ".L3m" no nome do arquivo e interpretando aqueles como valores de tempo formatados como yyyyDDD.

Você pode substituir o tempo de base padrão (1970-01T00:00:00) adicionando um Adicionar ao cesto que especifica um atributo diferente de unidades com um tempo de base diferente. Uma situação comum é: há grupos de arquivos de dados, cada um com um composto de 1 dia de um conjunto de dados de satélite, onde você quer que o valor do tempo seja meio-dia do dia mencionado no nome do arquivo (o tempo centralizado de cada dia) e quer a variável long\_name para ser "Centered Time". Um exemplo que faz isso é:

      <axisVariable>
        <sourceName>\\*\\*\\*fileName,timeFormat=yyyyDDD,S(\\d{7})\\.L3m.\\*,1</sourceName>
        <destinationName>time</destinationName>
        <addAttributes>
          <att name="long\\_name">Centered Time</att>
          <att name="units">seconds since 1970-01-01T12:00:00Z</att>
        </addAttributes>
      </axisVariable>

Nota horas=12 no tempo de base, que adiciona 12 horas em relação ao tempo de base original de 1970-01T00:00Z.

Um exemplo completo de um axisVariable que faz um conjunto de dados agregado com um novo eixo "run" (com valores int) que obtém os valores de execução do atributo global "runID" em cada arquivo (com valores como "r17\_global", onde 17 é o número de execução) é

      <axisVariable> 
        <sourceName>\\*\\*\\*global:runID,int,(r|s)(\\d+)\\_global,2</sourceName>
        <destinationName>run</destinationName>
        <addAttributes>
          <att name="ioos\\_category">Other</att>
          <att name="units">count</att>
        </addAttributes>
      </axisVariable>

Observe o uso do grupo de captura número 2 para capturar os dígitos que ocorrem após 'r' ou 's', e antes "\_global". Este exemplo também mostra como adicionar atributos adicionais (por exemplo, ioos\_category e unidades) para a variável eixo.

Arquivos compactados externamente

Datasets que são subconjuntos de EDDGrid Dos Ficheiros e Tabela EDD O FromFiles pode servir dados diretamente de arquivos de dados compactados externamente, incluindo .tgz , .tar .gz , .tar .gzip , .gz , .gzip , .zip , .bz2 , e arquivos .Z.
Isso funciona surpreendentemente bem!
Na maioria dos casos, a desaceleração relacionada à descompressão de arquivos de dados pequenos e médios é menor. Se você precisa economizar espaço em disco, recomendamos fortemente usar este recurso, especialmente para arquivos mais antigos que raramente são acessados.
Poupe dinheiro!
Esta é uma das poucas características ERDDAP™ que lhe oferece uma chance de economizar muito dinheiro (embora com o custo de desempenho ligeiramente reduzido) . Se a razão de compressão é, por exemplo, 6:1 (às vezes será muito maior) , então os arquivos de dados do conjunto de dados só precisarão de 1/6 o espaço de disco. Então, talvez você pode começar com 1 RAID (de um determinado tamanho) em vez de 6 RAIDS (do mesmo tamanho) . Isso é uma enorme economia de custos. Esperemos que a capacidade de comprimir alguns arquivos em uma coleção (os mais velhos?) e não comprimir outros (os mais novos?) , e para mudar isso a qualquer momento, vamos minimizar a desvantagem para comprimir alguns dos arquivos (acesso mais lento) . E se a escolha é entre armazenar os arquivos na fita (e só acessível mediante pedido, após um atraso) vs armazená-los comprimido em um RAID (e acessível via ERDDAP ) , então há uma enorme vantagem de usar compressão para que os usuários sejam interativos e (relativamente) acesso rápido aos dados. E se isso pode salvá-lo de comprar um RAID adicional, este recurso pode salvá-lo sobre $30,000.
Para todos EDDGrid FromFiles subclasses, se os arquivos de dados têm uma extensão indicando que eles são arquivos compactados externamente (Atualmente: .tgz , .tar .gz , .tar .gzip , .gz , .gzip , .zip , .bz2 , ou .Z) , ERDDAP™ irá decomprimir os arquivos para o diretório de cache do conjunto de dados quando lê-los (se eles já não estiverem em cache) . O mesmo é verdadeiro para o arquivo binário (por exemplo, .nc ) subclasses de EDDTableFromFiles.
Para EDDTableFromFiles subclasses para arquivos não binários (por exemplo, .csv) , arquivos de dados com uma extensão indicando que eles são arquivos compactados externamente serão descomprimidos on-the-fly como o arquivo é lido.
REQUISIÇÃO: Se o tipo de arquivo compactado externamente usado (por exemplo, .tgz ou .zip ) suporta mais de 1 arquivo dentro do arquivo compactado, o arquivo compactado deve conter apenas 1 arquivo.
REQUISIÇÃO: Este recurso assume que o conteúdo dos arquivos compactados externamente não muda, de modo que um arquivo descomprimido em cache pode ser reutilizado. Se alguns ou todos os arquivos de dados de um conjunto de dados forem alterados, não comprima esses arquivos. Isso é consistente com o uso comum, uma vez que as pessoas normalmente não comprimir arquivos que às vezes precisam mudar.
<fileNameRegex> Para fazer isso funcionar, o conjunto de dados<fileNameRegex> deve corresponder aos nomes dos arquivos compactados. Obviamente, regexes como .\corresponderá a todos os nomes de arquivos. Se você especificar um tipo de arquivo específico, por exemplo, .\\\ .nc , então você precisa modificar o regex para incluir a extensão de compressão também, por exemplo, .\ \\ .nc \\ .gz (se todos os arquivos serão Alguma coisa? .nc .gz arquivos) .
É bom se seu conjunto de dados inclui uma mistura de arquivos compactados e não compactados. Isso pode ser útil se você acredita que alguns arquivos (por exemplo, arquivos mais antigos) será usado menos frequentemente e, portanto, seria útil para economizar espaço em disco comprimindo-os. Para fazer isto funcionar, o<fileNameRegex> deve corresponder aos nomes dos arquivos compactados e não compactados, por exemplo, .\ou .\\\ .nc ( | \\ .gz ) (onde o grupo de captura no final disso especifica que .gz é opcional.
É bom se você comprimir ou descomprimir arquivos específicos na coleção a qualquer momento. Se o conjunto de dados não usar [<updateEveryNMillis>] (#updateeverynmillis #) , definir o conjunto de dados bandeira para contar ERDDAP™ para recarregar o conjunto de dados e assim notar as alterações. Curiosamente, você pode usar diferentes algoritmos de compressão e configurações para arquivos diferentes no mesmo conjunto de dados (por exemplo, .bz2 para arquivos raramente usados, .gz para arquivos não frequentemente usados, e nenhuma compressão para arquivos usados com freqüência) , apenas certifique-se de que o regex suporta todas as extensões de arquivo que estão em uso, por exemplo, .\*\\ .nc ( | \\ .gz | \\ .bz2 ) .
Naturalmente, as razões de compressão e as velocidades para os diferentes algoritmos de compressão variam com o arquivo de origem e as configurações (por exemplo, nível de compressão) . Se você quiser otimizar este sistema para seus arquivos, faça um teste dos diferentes métodos de compressão com seus arquivos e com uma variedade de configurações de compressão. Se você quiser um confiável bom (não necessariamente o melhor) configuração, vamos ligeiramente recomendar gzip ( .gz ) . gzip não faz o menor arquivo compactado (é razoavelmente perto) , mas compreende o arquivo muito rapidamente e (mais importante para ERDDAP™ usuários) decomprime o arquivo muito rapidamente. Além disso, gzip software vem padrão com cada instalação Linux e Mac OS e está prontamente disponível para Windows através de ferramentas gratuitas como 7Zip e Linux add-ons como Git Bash. Por exemplo, para comprimir um arquivo de origem no .gz versão do arquivo (mesmo nome de arquivo, mas com .gz apêndice) , uso (em Linux, Mac OS e Git Bash)
gzip * sourceName *
Para decomprimir um .gz arquivo de volta para o original, use Armazém * sourceName .gz *
Para comprimir cada um dos arquivos de origem no diretório e seus subdiretórios, recursivamente, use gzip - O quê? DirectorName
Descomprimir cada um dos .gz arquivos em diretório e seus subdiretórios, recursivamente, use Armazém -r DirectorName
Não comprima externamente ( gzip ) arquivos que já estão internamente compactados! Muitos arquivos já têm dados compactados internamente. Se você gzip esses arquivos, os arquivos resultantes não serão muito menores (<5%) e ERDDAP™ desperdiçará tempo descomprimindo-os quando precisar lê-los. Por exemplo:
- arquivos de dados: por exemplo, .nc 4, .hdf 5 arquivos: Alguns arquivos usam compressão interna; alguns não. Como dizer: as variáveis compactadas têm atributos "\_ChunkSize". Além disso, se um grupo de gradeados .nc ou .hdf arquivos são todos os tamanhos diferentes, eles provavelmente internamente comprimido. Se eles são todos do mesmo tamanho, eles não são internamente comprimidos.
- arquivos de imagem: por exemplo, .gif, .jpg, e .png
- arquivos de áudio: por exemplo, .mp3 e .ogg.
- arquivos de vídeo: por exemplo, .mp4, .ogv e .webm.

Um caso estranho infeliz: arquivos de áudio .wav são enormes e não internamente compactados. Seria bom comprimir ( gzip ) eles, mas geralmente você não deve porque se você fizer, os usuários não serão capazes de reproduzir os arquivos compactados em seu navegador.

Caso de teste: compressão (com gzip ) um conjunto de dados com 1523 gradeado .nc arquivos.
- Os dados nos arquivos de origem foram esparsos (muitos valores perdidos) .
- O espaço total do disco foi de 57 GB antes da compressão para 7 GB depois.
- Um pedido de muitos dados a partir de 1 ponto de hora é<1 s antes e depois da compressão.
- Um pedido para 1 ponto de dados para 365 pontos de tempo (a pior situação caso) foi de 4 s a 71 s.

Para mim que é um trade-off razoável para qualquer conjunto de dados, e certamente para conjuntos de dados que são raramente usados.

Compressão interna versus externa -- Comparado com a compressão interna do arquivo oferecido por .nc 4 e .hdf 5 arquivos, ERDDAP 's abordagem para arquivos binários compactados externamente tem vantagens e desvantagens. A desvantagem é: por uma vez lido de uma pequena parte de um arquivo, compressão interna é melhor porque EDDGrid FromFiles só precisa descomprimir alguns pedaços (S) do arquivo, não todo o arquivo. Mas... ERDDAP A abordagem tem algumas vantagens:
- ERDDAP™ suporta compressão de todos os tipos de arquivos de dados (binário e não binário, por exemplo, .nc 3 e .csv) não apenas .nc 4 e .hdf 4.
- Se a maior parte de um arquivo precisa ser lido mais de uma vez em um curto período de tempo, então economiza tempo para descomprimir o arquivo uma vez e lê-lo muitas vezes. Isto acontece em ERDDAP™ quando um usuário usa Make-A-Graph para o conjunto de dados e faz uma série de pequenas mudanças no gráfico.
- A capacidade de ter arquivos compactados e não arquivos compactados na mesma coleção, permite que você controle mais sobre quais arquivos são compactados e que não são. E este controle adicionado vem sem realmente modificar o arquivo de origem (já que você pode comprimir um arquivo com, por exemplo, .gz e, em seguida, descomprimir-o para obter o arquivo original) .
- A capacidade de mudar a qualquer momento se um determinado arquivo é comprimido e como é comprimido (diferentes algoritmos e configurações) dá-lhe mais controle sobre o desempenho do sistema. E você pode facilmente recuperar o arquivo não comprimido original a qualquer momento.

Embora nenhuma abordagem seja um vencedor em todas as situações, é claro que ERDDAP 's capacidade de servir dados de arquivos compactados externamente faz compressão externa uma alternativa razoável para a compressão interna oferecida por .nc 4 e .hdf 5. Isso é significativo dado que a compressão interna é uma das principais razões pelas quais as pessoas escolhem usar .nc 4 e .hdf 5.

Cache descomprimido

ERDDAP™ faz uma versão descomprimida de qualquer binário comprimido (por exemplo, .nc ) arquivo de dados quando ele precisa ler o arquivo. Os arquivos descomprimidos são mantidos no diretório do conjunto de dados dentro Diretriz de grande porte /decomprimido / . Arquivos descomprimidos que não foram usados recentemente serão excluídos para liberar espaço quando o tamanho do arquivo cumulativo é >10GB. Você pode mudar isso configurando<descomprimidoCacheMaxGB> (padrão=10) em conjuntos de dados Xml.xml, por exemplo,

        <decompressedCacheMaxGB>40</decompressedCacheMaxGB>

Além disso, os arquivos descomprimidos que não foram usados nos últimos 15 minutos serão excluídos no início de cada grande recarga de conjunto de dados. Você pode mudar isso configurando<descompactadoCacheMaxMinutesOld> (default=15) em conjuntos de dados Xml.xml, por exemplo,

        <decompressedCacheMaxMinutesOld>60</decompressedCacheMaxMinutesOld>

Números maiores são agradáveis, mas o tamanho cumulativo dos arquivos descomprimidos pode causar Diretriz de grande porte para ficar sem espaço em disco, o que causa problemas graves.

Porque descomprimir um arquivo pode levar uma quantidade significativa de tempo (0,1 a 10 segundos) , conjuntos de dados com arquivos compactados podem se beneficiar de definir o conjunto de dados [<NThreads>] (#nthreads) definição para um número maior (2? 3? 4?) . As desvantagens para números ainda maiores (Por exemplo, 5? 6? 7?) estão diminuindo os retornos e o pedido de um usuário pode então usar uma alta porcentagem dos recursos do sistema, diminuindo significativamente o processamento dos pedidos de outro usuário. Assim, não há nenhuma configuração nThreads ideal, apenas consequências diferentes em situações diferentes com configurações diferentes.

Valores de dimensão classificados

Os valores para cada dimensão devem estar em ordem ordenada (ascendendo ou descendo, exceto para o primeiro (mais à esquerda) dimensão que deve ser crescente) . Os valores podem ser espaçados de forma irregular. Não pode haver laços. Esta é uma exigência do Padrão de metadados CF . Se os valores de qualquer dimensão não estiverem em ordem ordenada, o conjunto de dados não será carregado e ERDDAP™ identificará o primeiro valor não ousado no arquivo de log, Diretriz de grande porte /logs/log.txt .

Directoria

Os arquivos MAY estar em um diretório, ou em um diretório e seus subdiretórios (recorrentemente) . Se houver um grande número de arquivos (por exemplo, >1,000) , o sistema operacional (e assim EDDGrid Dos quartos) irá operar muito mais eficientemente se você armazenar os arquivos em uma série de subdiretórios (um por ano, ou um por mês para conjuntos de dados com arquivos muito frequentes) , para que nunca haja um grande número de arquivos em um determinado diretório.

<cacheDe Url>

Tudo EDDGrid FromFiles e todos os conjuntos de dados EDDTableFromFiles suportam um conjunto de tags que contam ERDDAP™ para baixar e manter uma cópia de todos os arquivos de um conjunto de dados remoto, ou um cache de alguns arquivos (baixado conforme necessário) . Isto pode ser incrivelmente útil. Ver cache Documentação de Url .

Diretórios remotos e solicitações de intervalo HTTP

(AKA Byte Serving, Byte Range Requests, Accept-Ranges http Cabeçalho)
EDDGrid De NcFiles, EDDTableFromMultidimNcFiles, EDDTableFromNcFiles, e ETableDDFromNcCFFiles, pode às vezes servir dados de .nc arquivos em servidores remotos e acessados via HTTP se o servidor suporta Servir Byte através de solicitações de intervalo HTTP (o mecanismo HTTP para byte servindo) . Isso é possível porque netcdf-java (que ERDDAP™ usos para ler .nc arquivos) suporta a leitura de dados de remoto .nc arquivos através de solicitações de intervalo HTTP.

Não faças isso! É horrivelmente ineficiente e lento. Em vez disso, use o [<cacheDeUrl> sistema] (#cachefromurl) .

Acesso ERDDAP™ datasets como arquivos através de solicitações de intervalo byte -- Virando isto por aí, dado que você pode (em teoria) pensar em um conjunto de dados em ERDDAP™ como um gigante .nc arquivo por anexar " .nc " à base OPen DAP URL para um determinado conjunto de dados (por exemplo,https://myserver.org/erddap/griddap/datasetID.nce também adicionando um ?query depois disso para especificar um subset) , é talvez razoável perguntar se você pode usar netcdf-java, Ferret , ou algum outro NetCDF software cliente para ler dados via Pedidos de Intervalo HTTP ERDDAP . A resposta é não, porque não há realmente um enorme " .nc " ficheiro. Se você quiser fazer isso, em vez de fazer uma dessas opções:

Uso(OPeN)DAPsoftware cliente para se conectar aos serviços de griddap oferecidos por ERDDAP . Isso é o que DAP (e assim ERDDAP ) foi projetado para. É muito eficiente.
Ou, baixe o arquivo de origem (S) do "files" sistema (ou um arquivo subconjunto através de um .nc ? consulta) para o seu computador e usar netcdf-java, Ferret , ou algum outro NetCDF software cliente para ler o (Agora) arquivo local (S) .

InformaÃ§Ãμes de arquivo Cached

Quando um EDDGrid O conjunto de dados do FromFiles é primeiro carregado, EDDGrid FromFiles lê informações de todos os arquivos relevantes e cria tabelas (uma linha para cada arquivo) com informações sobre cada arquivo válido e cada "mau" (diferente ou inválido) ficheiro.

As tabelas também são armazenadas no disco, como NetCDF v3 .nc arquivos em Diretriz de grande porte /dataset/ último2CharsOfDatasetID / * datasetID * / em arquivos nomeados: tabela de dados .nc (que contém uma lista de nomes de diretório únicos) , arquivo Quadro .nc (que contém a tabela com as informações de cada arquivo válido) , Arquivos ruins .nc (que segura a tabela com as informações de cada arquivo ruim) .
Para acelerar o acesso a um EDDGrid Conjunto de dados de Ficheiros (mas à custa de usar mais memória) Você pode usar [<arquivoTableInMemory>true</fileTableInMemory> (#filetableinmemory) para contar ERDDAP™ para manter uma cópia das tabelas de informações do arquivo na memória.
A cópia das tabelas de informações do arquivo no disco também é útil quando ERDDAP™ é desligado e reiniciado: salva EDDGrid FromFiles de ter que reler todos os arquivos de dados.
Quando um conjunto de dados é recarregado, ERDDAP™ só precisa ler os dados em novos arquivos e arquivos que mudaram.
Se um arquivo tem uma estrutura diferente dos outros arquivos (por exemplo, um tipo de dados diferente para uma das variáveis, ou um valor diferente para o " unidades "Atributo) , ERDDAP adiciona o arquivo à lista de arquivos "bad". InformaÃ§Ãμes sobre o problema com o arquivo serÃ¡ escrito para o Diretriz de grande porte /logs/log.txt arquivo.
Você nunca deve precisar excluir ou trabalhar com esses arquivos. Uma exceção é: se você ainda está fazendo alterações em um conjunto de dados datasets.xml configuração, você pode querer excluir esses arquivos para forçar ERDDAP™ para reler todos os arquivos desde que os arquivos serão lidos / interpretados de forma diferente. Se você precisar excluir esses arquivos, você pode fazê-lo quando ERDDAP™ está a correr. (Em seguida, definir um bandeira para recarregar o conjunto de dados ASAP.) No entanto, ERDDAP™ geralmente percebe que o datasets.xml informações não correspondem ao arquivo InformaÃ§Ãμes da tabela e exclui as tabelas de arquivos automaticamente.
Se você quiser encorajar ERDDAP™ para atualizar as informações do conjunto de dados armazenados (por exemplo, se você acabou de adicionar, remover ou alterar alguns arquivos no diretório de dados do conjunto de dados) , use o sistema de bandeira à força ERDDAP™ para atualizar as informações de arquivo em cache.

Pedidos de manuseio

Quando a solicitação de um cliente para dados for processada, EDDGrid O FromFiles pode olhar rapidamente na tabela com as informações de arquivo válidas para ver quais arquivos têm os dados solicitados.

Atualizando as informações do arquivo Cached

Sempre que o conjunto de dados é recarregado, as informações de arquivo em cache são atualizadas.

O conjunto de dados é recarregado periodicamente conforme determinado pelo<reloadEveryNMinutes> nas informações do conjunto de dados datasets.xml .
O conjunto de dados é recarregado o mais rápido possível sempre ERDDAP™ detecta que você adicionou, removido, Tocava (para alterar o último arquivo Tempo modificado) , ou mudou um arquivo de dados.
O conjunto de dados é recarregado o mais rápido possível se você usar o sistema de bandeira .

Quando o conjunto de dados é recarregado, ERDDAP™ compara os arquivos disponíveis atualmente às tabelas de informações de arquivo em cache. Novos arquivos são lidos e adicionados à tabela de arquivos válidos. Os arquivos que já não existem são retirados da tabela de arquivos válidos. Os arquivos onde o timestamp do arquivo mudou são lidos e suas informações são atualizadas. As novas tabelas substituem as mesas antigas na memória e no disco.

Arquivos ruins

A tabela de arquivos ruins e as razões que os arquivos foram declarados ruins (arquivo corrompido, variáveis ausentes, etc.) é enviado para o e-mail Tudo Para endereço de e-mail (Provavelmente.) sempre que o conjunto de dados é recarregado. Você deve substituir ou reparar esses arquivos o mais rápido possível.

Variáveis em falta

Se alguns dos arquivos não têm alguns dos dataVariable s definido no conjunto de dados datasets.xml Chuck, não faz mal. Quando EDDGrid FromFiles lê um desses arquivos, ele atuará como se o arquivo tivesse a variável, mas com todos os valores ausentes.

Problemas de FTP / Conselhos

Se você FTP novos arquivos de dados para o ERDDAP™ servidor enquanto ERDDAP™ está correndo, há a chance de que ERDDAP™ será recarregar o conjunto de dados durante o processo FTP. Acontece mais frequentemente do que você pode pensar! Se acontecer, o arquivo parecerá válido (tem um nome válido) , mas o arquivo ainda não é válido. Se ERDDAP™ tenta ler dados desse arquivo inválido, o erro resultante fará com que o arquivo seja adicionado à tabela de arquivos inválidos. Isto não é bom. Para evitar este problema, use um nome de arquivo temporário quando FTP'ing o arquivo, por exemplo, ABC2005 .nc \_TEMP . Então, o teste fileNameRegex (ver abaixo) irá indicar que este não é um arquivo relevante. Depois que o processo FTP é completo, renomeie o arquivo para o nome correto. O processo de renomeação fará com que o arquivo se torne relevante em um instante.

"0 ficheiros" Mensagem de erro

Se você correr Gerar conjuntos de dadosXml ou DasDds , ou se você tentar carregar um EDDGrid A partir de...Files dataset in ERDDAP™ , e você recebe uma mensagem de erro "0 files" indicando que ERDDAP™ encontrado 0 arquivos correspondentes no diretório (quando você acha que existem arquivos correspondentes nesse diretório) :

Verifique se os arquivos estão realmente nesse diretório.
Verifique a ortografia do nome do diretório.
Verifique o arquivoNameRegex. É realmente, muito fácil cometer erros com regexes. Para fins de teste, tente o regex .\* que deve corresponder a todos os nomes de arquivos. (Veja isto documentação e tutorial do regex .)
Verifique se o usuário que está executando o programa (por exemplo, user=tomcat (?) para Tomcat / ERDDAP ) tem permissão 'read' para esses arquivos.
Em alguns sistemas operacionais (por exemplo, SELinux) e dependendo das configurações do sistema, o usuário que executou o programa deve ter permissão de 'leitura' para toda a cadeia de diretórios que levam ao diretório que tem os arquivos.

EDDGrid esqueleto deFiles XML

O esqueleto XML para todos EDDGrid FromFiles subclasses é:

<dataset type="EDDGridFrom...Files" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaWMS>...</accessibleViaWMS> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <matchAxisNDigits>...</matchAxisNDigits> 
      <nThreads>...</nThreads> 
      <dimensionValuesInMemory>...</dimensionValuesInMemory> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <fileDir>...</fileDir> <-- The directory (absolute) with the
        data files. -->
      <recursive>true|false</recursive> 
      <pathRegex>...</pathRegex> 
      <fileNameRegex>...</fileNameRegex> <-- 0 or 1. A
        regular expression (tutorial) describing valid data
        file names, for example, ".\\.nc" for all .nc files. -->
      <accessibleViaFiles>true|false(default)</accessibleViaFiles>
        
      <metadataFrom>...</metadataFrom> <-- The file to get
        metadata from ("first" or "last" (the default) based on file's
        lastModifiedTime). -->
      <fileTableInMemory>...</fileTableInMemory> 
      <cacheFromUrl>...</cacheFromUrl> 
      <cacheSizeGB>...</cacheSizeGB> 
      <addAttributes>...</addAttributes> 
      <axisVariable>...</axisVariable> 
      <dataVariable>...</dataVariable> 
  </dataset>

EDD * De áudioFiles

** EDDGrid A partir deAudioFiles** e EDDTable FromAudioFiles agregar dados de uma coleção de arquivos de áudio locais. (Estes apareceram primeiro ERDDAP™ v1.82.) A diferença é que EDDGrid FromAudioFiles trata os dados como um conjunto de dados multidimensional (geralmente com 2 dimensões: \[ início de arquivo Tempo \] e \[ decaída Tempo dentro de um arquivo \] ) , enquanto EDDTableFromAudioFiles trata os dados como dados tabulares (geralmente com colunas para o início do arquivoTime, o elapsedTime com o arquivo, e os dados dos canais de áudio) . EDDGrid FromAudioFiles exige que todos os arquivos têm o mesmo número de amostras, então se isso não for verdade, você deve usar EDDTableFromAudioFiles. Caso contrário, a escolha de que tipo EDD usar é inteiramente sua escolha. Uma vantagem de EDDTableFromAudioFiles: você pode adicionar outras variáveis com outras informações, por exemplo, stationID Estação Type. Em ambos os casos, a falta de uma variável de tempo unificada torna mais difícil trabalhar com os dados desses tipos de EDD, mas não havia nenhuma boa maneira de configurar uma variável de tempo unificada.

Veja as superclasses desta classe. EDDGrid Dos quartos e Tabela EDD dos arquivos , para informações gerais sobre como esta classe funciona e como usá-la.

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Uma vez que os arquivos de áudio não têm metadados além das informações relacionadas com a codificação dos dados de som, você terá que editar a saída de GenerateDatasets Xml para fornecer informações essenciais (por exemplo, título, resumo, creator\_name , instituição, história) .

Detalhes:

Há um grande número de formatos de arquivos de áudio. Atualmente, ERDDAP™ pode ler dados da maioria dos arquivos .wav e .au. Atualmente não pode ler outros tipos de arquivos de áudio, por exemplo, .aiff ou .mp3. Se você precisar de suporte para outros formatos de arquivos de áudio ou outras variantes de .wav e .au, por favor envie um e-mail para Chris. John em noaaa.gov . Ou, como uma solução que você pode usar agora, você pode converter seus arquivos de áudio em PCM\_ ASSINAR (para dados inteiros) ou PCM\_FLOAT (para dados de ponto flutuante) Arquivos .wav para que ERDDAP™ pode trabalhar com eles.
Atualmente, ERDDAP™ pode ler arquivos de áudio com o que Java 's classe AudioFormat chama PCM\_FLOAT, PCM\_SIGNED, PCM\_UNSIGNED, ALAW e codificações ULAW. ERDDAP™ converte valores PCM\_UNSIGNED (por exemplo, 0 a 255) em valores assinados (por exemplo, -128 a 128) reorganizando os bits nos valores de dados. ERDDAP™ converte ALAW e ULAW codificado de seu formato de byte nativo codificado em curto (Intérprete) valores. Desde então Java quer bigEndian = dados verdadeiros, ERDDAP™ rearranja os bytes de dados armazenados com bigEndian=false (pequeno endiano) para ler os valores corretamente. Para todas as outras codificações (PCM) , ERDDAP™ lê os dados como é.
Quando ERDDAP™ lê dados de arquivos de áudio, ele converte os metadados de áudio disponíveis do arquivo em atributos globais. Isso sempre incluirá (com valores de amostra mostrados)

String audioBigEndian "false"; //true ou false em áudio Canais 1; String audioEncoding "PCM\_SIGNED"; float audioFrameRate 96000.0; //por segundo int audioFrameSize 2; //# de dados bytes per frame float audioSampleRate 96000.0; //por segundo int audioSampleSizeInBits 16; //# de bits por canal por amostra

Para ERDDAP Os propósitos, um quadro é sinônimo de uma amostra, que é os dados para um ponto no tempo. Os atributos em ERDDAP™ terá as informações descrevendo os dados como estava nos arquivos de origem. ERDDAP™ muitas vezes mudou isso ao ler os dados, por exemplo, PCM\_UNSIGNED, ALAW e ULAW dados codificados são convertidos para PCM\_SIGNED, e bigEndian=false dados são convertidos para bigEndian=true data (que é como Java quer lê-lo) . No final, valores de dados em ERDDAP™ será sempre o PCM codificado valores de dados (ou seja, amostras digitalizadas simples da onda sonora) .

Quando ERDDAP™ lê dados de arquivos de áudio, lê todo o arquivo. ERDDAP™ pode ler até cerca de 2 bilhões de amostras por canal. Por exemplo, se a taxa de amostragem for de 44,100 amostras por segundo, 2 bilhões de amostras se traduz em cerca de 756 minutos de dados sonoros por arquivo. Se você tem arquivos de áudio com mais do que essa quantidade de dados, você precisa dividir os arquivos em pedaços menores para que ERDDAP™ pode lê-los.
Porque... ERDDAP™ lê arquivos de áudio inteiros, ERDDAP™ deve ter acesso a uma grande quantidade de memória para trabalhar com grandes arquivos de áudio. Ver ERDDAP configurações de memória . Novamente, se este é um problema, uma solução que você pode usar agora é quebrar os arquivos em pedaços menores para que ERDDAP™ pode lê-los com menos memória.
Alguns arquivos de áudio foram escritos incorretamente. ERDDAP™ faz um pequeno esforço para lidar com tais casos. Mas em geral, quando há um erro, ERDDAP™ vai jogar uma exceção (e rejeitar esse arquivo) ou (se o erro é indetectável) ler os dados (mas os dados serão incorretos) .
ERDDAP™ não verificar ou alterar o volume do som. Idealmente, dados de áudio inteiros são dimensionados para usar toda a gama do tipo de dados.
Arquivos de áudio e leitores de áudio não têm sistema para valores ausentes (por exemplo, -999 ou Float.NaN) . Então os dados de áudio não devem ter nenhum valor ausente. Se houver valores ausentes (por exemplo, se você precisar alongar um arquivo de áudio) , use uma série de 0's que serão interpretados como perfeito silêncio.
Quando ERDDAP™ lê dados de arquivos de áudio, sempre cria uma coluna chamada de decaída Tempo com o tempo para cada amostra, em segundos (armazenados como duplos) , em relação à primeira amostra (que é atribuído decorrido Tempo = 0,0) . Com EDDGrid FromAudioFiles, isso se torna a variável de eixo elapsedTime.
EDDGrid FromAudioFiles exige que todos os arquivos têm o mesmo número de amostras. Então, se isso não for verdade, você deve usar EDDTableFromAudioFiles.
Para EDDGrid FromAudioFiles, recomendamos que você configure [<DimensionValuesInMemory>] (#valores de dimensão em memória) ao falso (como é recomendado por GenerateDatasets Xml) , porque a dimensão do tempo muitas vezes tem um grande número de valores.
Para EDDGrid FromAudioFiles, você deve quase sempre usar o EDDGrid Sistema FromFiles para Agregação via Nomes de arquivo , quase sempre extraindo a data de início da gravação Hora dos nomes dos ficheiros. Por exemplo,

    <sourceName>\\*\\*\\*fileName,"timeFormat=yyyyMMdd'\\_'HHmmss",aco\\_acoustic\\.(\\[0-9\\]{8}\\_\\[0-9\\]{6})\\.wav,1</sourceName>

Gerar conjuntos de dados Xml vai encorajar isso e ajudá-lo com isso.

Para EDDTableFromAudioFiles, você deve quase sempre usar o sistema EDDTableFromFiles para \\\*fileNome pseudo sourceName S para extrair informações do nome do arquivo (quase sempre a data de início Tempo para a gravação) e promovê-lo para ser uma coluna de dados. Por exemplo,

    <sourceName>\\*\\*\\*fileName,aco\\_acoustic\\.(\\[0-9\\]{8}\\_\\[0-9\\]{6})\\.wav,1</sourceName>

O formato de tempo deve então ser especificado como o atributo unidades:<nome do att="units">yyyMMdd'\_'Hmmss</att>

EDDGrid A partir deMergeIRFiles

** EDDGrid A partir deMergeIRFiles** agrega dados de local, Mergeir arquivos, que são do Missão de Medição de Chuva Tropical (TRMM) , que é uma missão conjunta entre a NASA e a Agência de Exploração Aeroespacial do Japão (JAXA) . Mergulho Arquivos IR podem ser baixados a partir de NASA .

EDDGrid FromMergeIRFiles.java foi escrito e contribuiu para o ERDDAP™ projeto de Jonathan Lafite e Philippe Makowski da R.Tech Engenharia (Licença: copyrighted open source) .

EDDGrid FromMergeIRFiles é um pouco incomum:

EDDGrid O FromMergeIRFiles suporta arquivos de dados de origem compactados ou não compactados, em qualquer combinação, no mesmo conjunto de dados. Isso permite que você, por exemplo, comprima arquivos antigos que raramente são acessados, mas descompacte novos arquivos que são frequentemente acessados. Ou, você pode alterar o tipo de compressão do original . Z, por exemplo, .gz .
Se você tiver versões compactadas e não compactadas dos mesmos arquivos de dados no mesmo diretório, certifique-se de que<fileNameRegex> para o seu conjunto de dados corresponde aos nomes de arquivo que você deseja que ele combine e não combina com nomes de arquivo que você não quer que ele combine.
Arquivos de dados de origem não compactados devem ter nenhuma extensão de arquivo (ou seja, não "." no nome do arquivo) .
Os arquivos de dados de origem compacta devem ter uma extensão de arquivo, mas ERDDAP™ determina o tipo de compressão inspecionando o conteúdo do arquivo, não olhando para a extensão do arquivo (por exemplo, ".Z") . Os tipos de compressão suportados incluem "gz", "bzip2", "xz", "lzma", "snappy-raw", "snappy-framed", "pack200", e "z". Quando ERDDAP™ lê arquivos compactados, descomprime on-the-fly, sem escrever para um arquivo temporário.
Todos os arquivos de dados de origem devem usar o sistema de nomes de arquivos original: i.e., merg\_ Sim. \_4km-pixel (Onde? Sim. indica o tempo associado aos dados no arquivo) , mais uma extensão de arquivo se o arquivo for compactado.

Veja a superclasse desta classe. EDDGrid Dos quartos , para informações gerais sobre como esta classe funciona e como usá-la.

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

EDDGrid A partir de NcFiles

** EDDGrid A partir de NcFiles** agrega dados de local, gradeado, GRIB .grb e .grb2 arquivos, HDF (v4 ou v5) .hdf arquivos, .nc ml arquivos, NetCDF (v3 ou v4) .nc arquivos, e Zarr arquivos (a partir da versão 2.25) . Os arquivos Zarr têm um comportamento ligeiramente diferente e exigem o fileNameRegex ou o pathRegex para incluir "zarr".

Novo em ERDDAP™ versão 2.29.0 é suporte experimental para variáveis de dados que não suportam todas as variáveis do eixo (ou como alguns chamaram dados 1D e 2D no mesmo conjunto de dados) . Por favor, acesse o GitHub (discussões ou questões) com feedback e bugs.

Isso pode funcionar com outros tipos de arquivo (por exemplo, BUFR) Não o testámos, por favor envie-nos alguns ficheiros de amostra.

Para arquivos GRIB, ERDDAP™ fará um arquivo de índice .gbx a primeira vez que lê cada arquivo GRIB. Então os arquivos GRIB devem estar em um diretório onde o "usuário" que executou Tomcat tem permissão de leitura + gravação.
Veja a superclasse desta classe. EDDGrid Dos quartos , para obter informações sobre como esta classe funciona e como usá-la.
Começar com ERDDAP™ v2.12, EDDGrid De NcFiles e EDDGrid A partir de NcFiles Unpacked pode ler dados de "estruturas" em .nc 4 e .hdf 4 ficheiros. Para identificar uma variável que é de uma estrutura, a< sourceName > deve usar o formato: Design de moda | Nome do membro , por exemplo, group1/myStruct | MyMember.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

Grupos em arquivos Nc Gridded

Os arquivos Netcdf4 podem conter grupos. ERDDAP™ apenas faz um conjunto de dados das variáveis em um grupo e todos os seus grupos-mãe. Você pode especificar um nome de grupo específico em GerarDatasets Xml (omit the trailing slash) , ou use "" para ter GerarDatasets Xml pesquisa todos os grupos para as variáveis que usam a maioria das dimensões, ou usam " \[ raiz raiz \] " ter GenerateDatasets apenas procurar variáveis no grupo raiz.

A primeira coisa que GenerateDatasetsXml faz para este tipo de conjunto de dados depois de responder às perguntas é imprimir a estrutura tipo ncdump do arquivo de amostra. Então, se você digitar algumas respostas patetas para o primeiro loop através de GerarDatasets Xml, pelo menos será capaz de ver se ERDDAP™ pode ler o arquivo e ver quais dimensões e variáveis estão no arquivo. Então você pode dar melhores respostas para o segundo loop através de GerarDatasetsXml.

EDDGrid A partir de NcFilesUnpacked

** EDDGrid A partir de NcFilesUnpacked** é uma variante de EDDGrid A partir de NcFiles que agrega dados de local, gradeado NetCDF (v3 ou v4) .nc e arquivos relacionados. A diferença é que esta classe descompacta cada arquivo de dados antes EDDGrid FromFiles olha para os arquivos:

Desbloqueia variáveis que são embaladas com scale\_factor e/ou add\_offset .
Ele converte \_FillValue e missing\_value valores para ser NaN's (ou MAX\_VALUE para tipos de dados inteiros) .
Converte valores de tempo e timestamp para "seconds since 1970-01-01T00:00:00Z" .

A grande vantagem desta classe é que ela fornece uma maneira de lidar com diferentes valores de scale\_factor , add\_offset , \_FillValue, missing\_value , ou unidades de tempo em arquivos de origem diferentes em uma coleção. Caso contrário, você teria que usar uma ferramenta como NcML ou NCO para modificar cada arquivo para remover as diferenças para que os arquivos possam ser tratados EDDGrid De NcFiles. Para que esta classe funcione corretamente, os arquivos devem seguir os padrões CF para os atributos relacionados.

Se tentar fazer um EDDGrid A partir de NcFiles Desempacotado de um grupo de arquivos com os quais você anteriormente tentou e não conseguiu usar EDDGrid De NcFiles, cd a Diretriz de grande porte /dataset/ último2Cartas / * datasetID * / Onde? último2Cartas é as últimas 2 letras do datasetID , e excluir todos os arquivos nesse diretório.
Começar com ERDDAP™ v2.12, EDDGrid De NcFiles e EDDGrid A partir de NcFiles Unpacked pode ler dados de "estruturas" em .nc 4 e .hdf 4 ficheiros. Para identificar uma variável que é de uma estrutura, a< sourceName > deve usar o formato: Design de moda | Nome do membro , por exemplo, group1/myStruct | MyMember.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

Os arquivos Netcdf4 podem conter grupos. Ver esta documentação .

A primeira coisa que GenerateDatasetsXml faz para este tipo de conjunto de dados depois de responder às perguntas é imprimir a estrutura semelhante a ncdump do arquivo de amostra antes é desembalado. Então, se você digitar algumas respostas patetas para o primeiro loop através de GerarDatasets Xml, pelo menos será capaz de ver se ERDDAP™ pode ler o arquivo e ver quais dimensões e variáveis estão no arquivo. Então você pode dar melhores respostas para o segundo loop através de GerarDatasetsXml.

EDDGrid LonPM180

** EDDGrid LonPM180** modifica os valores de longitude de uma criança (fechado) EDDGrid dataset que tem alguns valores de longitude maiores que 180 (por exemplo, 0 a 360) para que eles estejam no intervalo -180 a 180 (Longitude Plus ou Minus 180, daí o nome) .

Isso fornece uma maneira de fazer conjuntos de dados que têm valores de longitude maiores que 180 em conformidade / com OGC serviços (por exemplo, WMS no servidor ERDDAP ) , desde tudo OGC serviços exigem valores de longitude dentro de -180 a 180.
Trabalhar perto de uma descontinuidade causa problemas, independentemente de a descontinuidade estar em longitude 0 ou em longitude 180. Este tipo de conjunto de dados permite evitar esses problemas para todos, oferecendo duas versões do mesmo conjunto de dados: um com valores de longitude na faixa 0 a 360 ("Pacificêntrico"?) , um com valores de longitude na faixa -180 a 180 ("Atlanticentric"?) .
Para conjuntos de dados infantis com todos os valores de longitude maiores que 180, todos os novos valores de longitude são simplesmente 360 graus inferiores. Por exemplo, um conjunto de dados com valores de longitude de 180 a 240 se tornaria um conjunto de dados com valores de longitude de -180 a -120.
Para conjuntos de dados infantis que têm valores de longitude para todo o globo (aproximadamente 0 a 360) , o novo valor de longitude será reorganizado para ser (aproximadamente) -180 a 180: Os valores originais de 0 a quase 180 são inalterados. Os valores originais de 180 a 360 são convertidos para -180 a 0 e deslocados para o início do array de longitude.
Para conjuntos de dados infantis que abrangem 180 mas não cobrem o globo, ERDDAP™ insere valores ausentes conforme necessário para fazer um conjunto de dados que cobre o globo. Por exemplo, um conjunto de dados infantis com valores de longitude de 140 a 200 se tornaria um conjunto de dados com valores de longitude de -180 a 180. Os valores da criança de 180 a 200 se tornariam -180 a -160. Novos valores de longitude seriam inseridos de -160 a 140. Os valores de dados correspondentes serão \_FillValues. Os valores da criança de 140 a quase 180 seriam inalterados. A inserção de valores ausentes pode parecer estranha, mas evita vários problemas que resultam de ter valores de longitude que saltam de repente (por exemplo, de -160 a 140) .
Em Gerar conjuntos de dadosXml , há um "tipo de conjunto de dados" especial, EDDGrid LonPM180 FromErddapCatalog, que permite gerar o datasets.xml para EDDGrid Conjuntos de dados LonPM180 de cada um dos EDDGrid conjuntos de dados em um ERDDAP que têm valores de longitude maiores que 180. Isso facilita a oferta de duas versões desses conjuntos de dados: o original, com valores de longitude na faixa 0 a 360, e o novo conjunto de dados, com valores de longitude no intervalo -180 a 180.

O conjunto de dados da criança dentro de cada EDDGrid Conjunto de dados LonPM180 será um EDDGrid Dataset FromErddap que aponta para o conjunto de dados original. O novo conjunto de dados datasetID será o nome do conjunto de dados original mais "\_LonPM180". Por exemplo,

    <dataset type="EDDGridLonPM180" datasetID="erdMBsstdmday\\_LonPM180" active="true">
      <dataset type="EDDGridFromErddap" datasetID="erdMBsstdmday\\_LonPM180Child">
        <!-- SST, Aqua MODIS, NPP, 0.025 degrees, Pacific Ocean, Daytime 
          (Monthly Composite) minLon=120.0 maxLon=320.0 -->
        <sourceUrl>https://coastwatch.pfeg.noaa.gov/erddap/griddap/erdMBsstdmday
        </sourceUrl>
      </dataset>
    </dataset> 

Coloque o EDDGrid Conjunto de dados LonPM180 abaixo o conjunto de dados original em datasets.xml . Isso evita alguns possíveis problemas.

Alternativamente, você pode substituir o EDDGrid Dataset de criança FromErddap com o conjunto de dados original datasets.xml . Então, haverá apenas uma versão do conjunto de dados: aquela com valores de longitude dentro de -180 a 180. Nós desencorajamos isso porque há momentos em que cada versão do conjunto de dados é mais conveniente.

Se você oferecer duas versões de um conjunto de dados, por exemplo, uma com longitude 0 a 360 e uma com longitude -180 a 180:
- Você pode usar o opcional [<acessível Viajando WMS ></acessível Viajando WMS > (#acessível através de) com o conjunto de dados 0-360 para desativar forçosamente WMS serviço para esse conjunto de dados. Então, apenas a versão LonPM180 do conjunto de dados será acessível através WMS .
- Existem algumas maneiras de manter o conjunto de dados LonPM180 atualizado com mudanças no conjunto de dados subjacente:
  - Se o conjunto de dados da criança é um EDDGrid A partir do conjunto de dados Erddap que refere um conjunto de dados no mesmo ERDDAP™ , o conjunto de dados LonPM180 tentará se inscrever diretamente no conjunto de dados subjacente para que ele esteja sempre atualizado. As assinaturas diretas não geram e-mails pedindo que você valide a assinatura - a validação deve ser feita automaticamente.
  - Se o conjunto de dados da criança não for um EDDGrid Dataset FromErddap que está no mesmo ERDDAP™ , o conjunto de dados LonPM180 tentará usar o sistema de assinatura regular para se inscrever no conjunto de dados subjacente. Se você tem o sistema de assinatura em seu ERDDAP™ ligado, você deve obter e-mails pedindo-lhe para validar a assinatura. Por favor.
  - Se você tem o sistema de assinatura em seu ERDDAP™ desligado, o conjunto de dados LonPM180 pode, por vezes, ter ultrapassado metadados até que o conjunto de dados LonPM180 seja recarregado. Então, se o sistema de assinatura é desligado, você deve definir o [<recarregar Cada NMinutes> (#reloadeverynminutes) configuração do conjunto de dados LonPM180 para um número menor, de modo que é mais provável capturar mudanças no conjunto de dados da criança mais cedo.
Para conjuntos de dados com longitude máxima > 360, use a seguinte configuração opcional para definir o valor máximo e o conjunto de dados será corrigido para -180 a 180.

    <maxSourceLon>540</maxSourceLon>

EDDGrid esqueleto LonPM180 XML

<dataset type="EDDGridLonPM180" datasetID\="..." active\="..." >
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaWMS>...</accessibleViaWMS> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <nThreads>...</nThreads> 
      <dimensionValuesInMemory>...</dimensionValuesInMemory> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <dataset>...</dataset> 
  </dataset>

EDDGrid Lon0360

** EDDGrid Lon0360** modifica os valores de longitude de uma criança (fechado) EDDGrid dataset que tem alguns valores de longitude inferior a 0 (por exemplo, -180 a 180) para que eles estejam no intervalo 0 a 360 (daí o nome) .

Trabalhar perto de uma descontinuidade causa problemas, independentemente de a descontinuidade estar em longitude 0 ou em longitude 180. Este tipo de conjunto de dados permite evitar esses problemas para todos, oferecendo duas versões do mesmo conjunto de dados: um com valores de longitude na faixa -180 a 180 ("Atlanticentric"?) . um com valores de longitude na faixa 0 a 360 ("Pacificêntrico"?) ,
Para conjuntos de dados infantis com todos os valores de longitude inferior a 0, todos os novos valores de longitude são simplesmente 360 graus mais elevados. Por exemplo, um conjunto de dados com valores de longitude de -180 a -120 se tornaria um conjunto de dados com valores de longitude de 180 a 240.
Para conjuntos de dados infantis que têm valores de longitude para todo o globo (aproximadamente -180 a 180) , o novo valor de longitude será reorganizado para ser (aproximadamente) 0 a 360: Os valores originais -180 a 0 são convertidos para 180 a 360 e deslocados para o final do array de longitude. Os valores originais de 0 a quase 180 são inalterados.
Para conjuntos de dados infantis que abrangem lon=0 mas não cobrem o globo, ERDDAP™ insere valores ausentes conforme necessário para fazer um conjunto de dados que cobre o globo. Por exemplo, um conjunto de dados infantis com valores de longitude de -40 a 20 se tornaria um conjunto de dados com valores de longitude de 0 a 360. Os valores da criança de 0 a 20 seriam inalterados. Novos valores de longitude seriam inseridos de 20 a 320. Os valores de dados correspondentes serão \_FillValues. Os valores da criança de -40 a 0 se tornariam 320 a 360. A inserção de valores ausentes pode parecer estranha, mas evita vários problemas que resultam de ter valores de longitude que saltam de repente (por exemplo, de 20 a 320) .
Em Gerar conjuntos de dadosXml , há um "tipo de conjunto de dados" especial, EDDGrid Lon0360 De ErddapCatalog, que permite gerar o datasets.xml para EDDGrid Conjuntos de dados Lon0360 de cada um dos EDDGrid conjuntos de dados em um ERDDAP que têm valores de longitude maiores que 180. Isso facilita a oferta de duas versões desses conjuntos de dados: o original, com valores de longitude na faixa 0 a 360, e o novo conjunto de dados, com valores de longitude no intervalo -180 a 180.

O conjunto de dados da criança dentro de cada EDDGrid Conjunto de dados Lon0360 será um EDDGrid Dataset FromErddap que aponta para o conjunto de dados original. O novo conjunto de dados datasetID será o nome do conjunto de dados original mais "\_Lon0360". Por exemplo,

    <dataset type="EDDGridLon0360" datasetID="erdMBsstdmday\\_Lon0360" active="true">
      <dataset type="EDDGridFromErddap" datasetID="erdMBsstdmday\\_Lon0360Child">
        <!-- SST, Aqua MODIS, NPP, 0.025 degrees, Pacific Ocean, Daytime 
          (Monthly Composite) minLon=-40.0 maxLon=20.0 -->
        <sourceUrl>https://coastwatch.pfeg.noaa.gov/erddap/griddap/erdMBsstdmday
        </sourceUrl>
      </dataset>
    </dataset> 

Coloque o EDDGrid Conjunto de dados Lon0360 abaixo o conjunto de dados original em datasets.xml . Isso evita alguns possíveis problemas.

Alternativamente, você pode substituir o EDDGrid Dataset de criança FromErddap com o conjunto de dados original datasets.xml . Então, haverá apenas uma versão do conjunto de dados: aquela com valores de longitude dentro de 0 a 360. Nós desencorajamos isso porque há momentos em que cada versão do conjunto de dados é mais conveniente.

Se você oferecer duas versões de um conjunto de dados, por exemplo, uma com longitude 0 a 360 e uma com longitude -180 a 180:
- Você pode usar o opcional [<acessível Viajando WMS ></acessível Viajando WMS > (#acessível através de) com o conjunto de dados de 0 a 360 para desativar com força WMS serviço para esse conjunto de dados. Então, apenas a versão -180 a 180 do conjunto de dados será acessível via WMS .
- Existem algumas maneiras de manter o conjunto de dados Lon0360 atualizado com mudanças no conjunto de dados subjacente:
  - Se o conjunto de dados da criança é um EDDGrid A partir do conjunto de dados Erddap que refere um conjunto de dados no mesmo ERDDAP™ , o conjunto de dados Lon0360 tentará se inscrever diretamente no conjunto de dados subjacente para que ele esteja sempre atualizado. As assinaturas diretas não geram e-mails pedindo que você valide a assinatura - a validação deve ser feita automaticamente.
  - Se o conjunto de dados da criança não for um EDDGrid Dataset FromErddap que está no mesmo ERDDAP™ , o conjunto de dados Lon0360 tentará usar o sistema de assinatura regular para se inscrever no conjunto de dados subjacente. Se você tem o sistema de assinatura em seu ERDDAP™ ligado, você deve obter e-mails pedindo-lhe para validar a assinatura. Por favor.
  - Se você tem o sistema de assinatura em seu ERDDAP™ desligado, o conjunto de dados Lon0360 pode, por vezes, ter ultrapassado metadados até que o conjunto de dados Lon0360 seja recarregado. Então, se o sistema de assinatura é desligado, você deve definir o [<recarregar Cada NMinutes> (#reloadeverynminutes) configuração do conjunto de dados Lon0360 para um número menor, de modo que é mais provável capturar mudanças no conjunto de dados da criança mais cedo.

EDDGrid esqueleto Lon0360 XML

<dataset type="EDDGridLon0360" datasetID\="..." active\="..." >
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaWMS>...</accessibleViaWMS> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <nThreads>...</nThreads> 
      <dimensionValuesInMemory>...</dimensionValuesInMemory> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <dataset>...</dataset> 
  </dataset>

EDDGrid SideBySide

** EDDGrid SideBySide** agrega dois ou mais EDDGrid conjuntos de dados (as crianças) lado a lado.

O conjunto de dados resultante tem todas as variáveis de todos os conjuntos de dados da criança.
O conjunto de dados dos pais e todos os conjuntos de dados da criança DEVE ter diferentes datasetID S. Se algum nome em uma família for exatamente o mesmo, o conjunto de dados falhará em carregar (com a mensagem de erro que os valores do eixo agregado não estão em ordem ordenada) .
Todas as crianças devem ter os mesmos valores-fonte para axisVariable S \[ 1+ \] (por exemplo, latitude, longitude) . A precisão dos testes é determinada por Jogos de Vestir .
As crianças podem ter diferentes valores-fonte para axisVariable S \[ 0 \] (por exemplo, tempo) , mas eles são geralmente em grande parte o mesmo.
O conjunto de dados dos pais parece ter todo o axisVariable S \[ 0 \] valores-fonte de todas as crianças.
Por exemplo, isso permite combinar um conjunto de dados de origem com um componente u do vetor e outro conjunto de dados de origem com um componente v do vetor, para que os dados combinados possam ser servidos.
As crianças criadas por este método são mantidas em privado. Eles não são conjuntos de dados acessíveis separadamente (por exemplo, por solicitações de dados do cliente ou por arquivos de bandeira ) .
Os metadados e configurações globais para o pai vêm dos metadados globais e configurações para a primeira criança.
Se houver uma exceção ao criar a primeira criança, o pai não será criado.
Se houver uma exceção ao criar outras crianças, isso envia um e-mail para e-mail Tudo Para (como especificado em setup.xml ) e continua com as outras crianças.

EDDGrid esqueleto de SideBySide XML

<dataset type="EDDGridSideBySide" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaWMS>...</accessibleViaWMS> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <matchAxisNDigits>...</matchAxisNDigits> 
      <nThreads>...</nThreads> 
      <dimensionValuesInMemory>...</dimensionValuesInMemory> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <dataset>...</dataset> 
  </dataset>

EDDGrid Dimensão existente agregada

** EDDGrid Dimensão existente agregada** agrega dois ou mais EDDGrid datasets cada um dos quais tem uma gama diferente de valores para a primeira dimensão, mas valores idênticos para as outras dimensões.

Por exemplo, um conjunto de dados de crianças pode ter 366 valores (para 2004) para a dimensão do tempo e outra criança pode ter 365 valores (para 2005) para a dimensão do tempo.
Todos os valores para todas as outras dimensões (por exemplo, latitude, longitude) Deve ser idêntico para todas as crianças. A precisão dos testes é determinada por Jogos de Vestir .
Valores de dimensão classificados - Os valores para cada dimensão devem estar em ordem ordenada (Ascendente ou descendente) . Os valores podem ser espaçados de forma irregular. Não pode haver laços. Esta é uma exigência do Padrão de metadados CF . Se os valores de qualquer dimensão não estiverem em ordem ordenada, o conjunto de dados não será carregado e ERDDAP™ identificará o primeiro valor não ousado no arquivo de log, Diretriz de grande porte /logs/log.txt .

O conjunto de dados dos pais e o conjunto de dados da criança DEVE ter diferentes datasetID S. Se algum nome em uma família for exatamente o mesmo, o conjunto de dados falhará em carregar (com a mensagem de erro que os valores do eixo agregado não estão em ordem ordenada) .
Atualmente, o conjunto de dados da criança DEVE ser um EDDGrid A partir do conjunto de dados e DEVE ter os valores mais baixos da dimensão agregada (geralmente os valores de tempo mais antigos) . Todas as outras crianças devem ser conjuntos de dados quase idênticos (diferindo apenas nos valores para a primeira dimensão) e são especificados por apenas seus sourceUrl .
O conjunto de dados agregado recebe seus metadados da primeira criança.

O Gerar conjuntos de dados Programa Xml pode fazer um rascunho áspero do datasets.xml para um EDDGrid AggregateExistingDimension baseado em um conjunto de arquivos servidos por um Hyrax ou servidor THREDDS. Por exemplo, use esta entrada para o programa (o "/1988" na URL torna o exemplo mais rápido) :

  EDDType? EDDGridAggregateExistingDimension  
  Server type (hyrax, thredds, or dodsindex)? hyrax  
  Parent URL (for example, for hyrax, ending in "contents.html";  
    for thredds, ending in "catalog.xml")  
  ? https://opendap.jpl.nasa.gov/opendap/ocean\\_wind/ccmp/L3.5a/data/  
    flk/1988/contents.html  
  File name regex (for example, ".\\*\\.nc")? month.\\*flk\\.nc\\.gz  
  ReloadEveryNMinutes (for example, 10080)? 10080  

Você pode usar o resultado< sourceUrl > tags ou excluí-los e descompactar< sourceUrl > tag (para que novos arquivos sejam notados cada vez que o conjunto de dados é recarregado.

EDDGrid esqueleto AggregateExistingDimension XML

<dataset type="EDDGridAggregateExistingDimension" datasetID\="..."
        active\="..." >
      <dataset>...</dataset> 
      <sourceUrl>...</sourceUrl> 
      <sourceUrls serverType="..." regex="..." recursive="true"
        pathRegex\=".\"
        >https://someServer/someDirectory/someSubdirectory/catalog.xml</sourceUrls>
        
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaWMS>...</accessibleViaWMS> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <matchAxisNDigits>...</matchAxisNDigits> 
      <nThreads>...</nThreads> 
      <dimensionValuesInMemory>...</dimensionValuesInMemory> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
  </dataset>

EDDGrid Entendido.

** EDDGrid Entendido.** faz e mantém uma cópia local de outra EDDGrid 's dados e serve dados da cópia local.

EDDGrid Entendido. (e para dados tabulares, EDDTableCopy ) é muito fácil de usar e muito eficaz solução para alguns dos maiores problemas com a utilização de dados de uma fonte de dados remota:
Acessar dados de uma fonte de dados remota pode ser lento.
- Pode ser lento porque é inerentemente lento (por exemplo, um tipo ineficiente de servidor) ,
- porque é esmagado por muitos pedidos,
- ou porque seu servidor ou o servidor remoto é de largura de banda limitada.
O conjunto de dados remoto é por vezes indisponível (novamente, por uma variedade de razões) .
Basear-se em uma fonte para os dados não escala bem (por exemplo, quando muitos usuários e muitos ERDDAP s utilizá-lo) .
Como funciona... EDDGrid Copiar resolve esses problemas automaticamente fazendo e mantendo uma cópia local dos dados e servindo dados da cópia local. ERDDAP™ pode servir os dados da cópia local muito, muito rapidamente. E fazer uma cópia local alivia o fardo no servidor remoto. E a cópia local é um backup do original, que é útil no caso de algo acontecer ao original.

Não há nada de novo sobre fazer uma cópia local de um conjunto de dados. O que é novo aqui é que esta classe faz\*Fácil.\*criar e\*manter\*uma cópia local de dados de uma\*variedade\*de tipos de fontes de dados remotas e\*adicionar metadados\*ao copiar os dados.

Chunks of Data... EDDGrid Copiar faz a cópia local dos dados solicitando pedaços de dados do remoto<dataset> . Haverá um pedaço para cada valor da esquerda (Primeiro) variável de eixo. EDDGrid Copiar não depende dos números de índice do conjunto de dados remotos para o eixo -- aqueles podem mudar.

AVISO: Se o tamanho de um pedaço de dados é tão grande (> 2 GB) que causa problemas, EDDGrid A cópia não pode ser usada. (Desculpe, esperamos ter uma solução para este problema no futuro.)

\[ Uma alternativa a EDDGrid Entendido. Se os dados remotos estiverem disponíveis através de arquivos transferíveis, não um serviço web, use cache Opção de FromUrl para EDDGrid Dos quartos , que faz uma cópia local dos arquivos remotos e serve os dados dos arquivos locais. \]
Arquivos locais -- Cada pedaço de dados é armazenado em um separado NetCDF arquivo em um subdiretório de Diretriz de grande porte /cópia / * datasetID * / (como especificado em setup.xml ) . Os nomes de arquivos criados a partir de valores de eixo são modificados para torná-los seguros de nome de arquivo (por exemplo, hífens são substituídos por "x2D") - Isto não afecta os dados.
Novos dados - ... Cada vez EDDGrid Copiar é recarregado, ele verifica o remoto<dataset> para ver quais pedaços estão disponíveis. Se o arquivo para um pedaço de dados já não existir, um pedido para obter o pedaço é adicionado a uma fila. ERDDAP 's taskThread processa todas as solicitações filadas para pedaços de dados, one-by-one. Você pode ver estatísticas para a atividade do Thread na tarefa Página de status e no Relatório diário . (Sim. ERDDAP™ poderia atribuir várias tarefas para este processo, mas isso usaria muitos da largura de banda, memória e tempo de CPU da fonte de dados remotos, e muitos dos locais ERDDAP 's largura de banda, memória e tempo de CPU, nenhum dos quais é uma boa ideia.)

NOTA: A primeira vez EDDGrid A cópia está carregada. (se tudo correr bem) lotes de pedidos de pedaços de dados serão adicionados à fila do taskThread, mas nenhum arquivo de dados local será criado. Assim, o construtor vai falhar, mas tarefaThread continuará a trabalhar e criar arquivos locais. Se tudo correr bem, a tarefaThread fará alguns arquivos de dados locais e a próxima tentativa de recarregar o conjunto de dados (em ~ 15 minutos) terá sucesso, mas inicialmente com uma quantidade muito limitada de dados.

NOTA: Depois que o conjunto de dados local tem alguns dados e aparece em seu ERDDAP , se o conjunto de dados remoto for temporariamente ou permanentemente não acessível, o conjunto de dados local continuará funcionando.

AVISO: Se o conjunto de dados remoto é grande e/ou o servidor remoto é lento (É esse o problema, não é?!) , levará muito tempo para fazer uma cópia local completa. Em alguns casos, o tempo necessário será inaceitável. Por exemplo, transmitindo 1 TB de dados sobre uma linha T1 (0.15 GB/s) leva pelo menos 60 dias, em condições ideais. Além disso, ele usa muita largura de banda, memória e tempo de CPU nos computadores remotos e locais. A solução é enviar um disco rígido para o administrador do conjunto de dados remotos para que ele / ele pode fazer uma cópia do conjunto de dados e enviar o disco rígido de volta para você. Use esses dados como um ponto de partida e EDDGrid Copiar irá adicionar dados a ele. (Essa é uma maneira Serviço de nuvem EC2 da Amazon lida com o problema, mesmo que seu sistema tenha muita largura de banda.)

ATENÇÃO: Se um determinado valor para a esquerda (Primeiro) variável do eixo desaparece do conjunto de dados remoto, EDDGrid Copiar não exclui o arquivo copiado local. Se você quiser, você pode excluí-lo sozinho.

Grid Verificação de CópiaFonte Dados

O datasets.xml para este conjunto de dados pode ter uma tag opcional

    <checkSourceData>true</checkSourceData>

O valor padrão é verdadeiro. Se / quando você configurá-lo para false, o conjunto de dados nunca irá verificar o conjunto de dados de origem para ver se há dados adicionais disponíveis.

apenas

Você pode dizer EDDGrid Copie para fazer uma cópia de um subconjunto do conjunto de dados de origem, em vez de todo o conjunto de dados de origem, adicionando uma tag no formulário<somente de acordo com o alguns Valor </onlySince> para o conjunto de dados datasets.xml Chuck. EDDGrid Copiar só irá baixar os valores de dados relacionados aos valores da primeira dimensão (geralmente a dimensão do tempo) que são maiores do que alguns Valor . alguns Valor pode ser:

Um tempo relativo especificado via now- NUnits . Por exemplo,<somente de acordo com o now- 2 anos</onlySince> diz ao conjunto de dados para apenas fazer cópias locais dos dados para dados onde os valores da dimensão externa (geralmente valores de tempo) estão dentro dos últimos 2 anos (que é reavaliado cada vez que o conjunto de dados é recarregado, que é quando procura novos dados para copiar) . Ver now- NUnits Descrição da sintaxe . Isso é útil se a primeira dimensão tiver dados de tempo, o que normalmente faz.

EDDGrid Copiar não exclui arquivos de dados locais que têm dados que, ao longo do tempo, se tornam mais antigos do que now- NUnits . Você pode excluir esses arquivos a qualquer momento se você optar por. Se você fizer, recomendamos fortemente que você definir um bandeira depois de excluir os arquivos para contar EDDGrid Copie para atualizar a lista de arquivos em cache.
Um ponto fixo no tempo especificado como uma string ISO 8601 yyyy-MM-ddTHH:mm:ssZ . Por exemplo,<onlySince>2000-01-01T00:00:00</onlySince> diz ao conjunto de dados apenas para fazer cópias locais de dados onde o valor da primeira dimensão é \>=2000-01T00:00:00Z . Isso é útil se a primeira dimensão tiver dados de tempo, o que normalmente faz.
Um número de ponto flutuante. Por exemplo,<somente após>946684800.0</onlySince> . As unidades serão as unidades de destino da primeira dimensão. Por exemplo, para dimensões do tempo, as unidades em ERDDAP™ sempre "seconds since 1970-01-01T00:00:00Z" . Então 946684800.0 "seconds since 1970-01-01T00:00:00Z" é equivalente a 2000-01-01T00:00:00Z. Esta é sempre uma opção útil, mas é especialmente útil quando a primeira dimensão não tem dados de tempo.

EDDGrid Copiar Uso recomendado

Criar<dataset> entrada (o tipo nativo, não EDDGrid Entendido.) para a fonte de dados remota. Faça funcionar corretamente, incluindo todos os metadados desejados.
Se for muito lento, adicione o código XML para embrulhá-lo em um EDDGrid Copiar conjunto de dados.
- Use um diferente datasetID (talvez mudando o datasetID do velho datasetID ligeiramente) .
- Entendido.<acessível Para>,<reloadEveryNMinutes> e<onChange> do remoto EDDGrid XML para o EDDGrid Cópia é XML. (Seus valores para EDDGrid Copiar matéria; seus valores para o conjunto de dados interno tornam-se irrelevantes.)
ERDDAP™ fará e manterá uma cópia local dos dados.

ATENÇÃO: EDDGrid Copiar assume que os valores de dados para cada pedaço nunca mudam. Se / quando eles fizerem, você precisa excluir manualmente os arquivos de chunk em Diretriz de grande porte /cópia / * datasetID * / que mudou e bandeira o conjunto de dados a ser recarregado para que os pedaços excluídos serão substituídos. Se você tiver uma assinatura por e-mail para o conjunto de dados, você receberá dois e-mails: um quando o conjunto de dados primeiro recarrega e começa a copiar os dados, e outro quando o conjunto de dados carrega novamente (automaticamente) e detecta os novos arquivos de dados locais.
Todos os valores do eixo devem ser iguais. Para cada um dos eixos, exceto o mais esquerdo (Primeiro) , todos os valores devem ser iguais para todas as crianças. A precisão dos testes é determinada por Jogos de Vestir .
Configurações, Metadados, Variáveis -- EDDGrid Copiar usa configurações, metadados e variáveis do conjunto de dados de origem fechada.
Alterar os metadados - ... Se você precisar mudar qualquer addAttributes ou alterar a ordem das variáveis associadas ao conjunto de dados de origem:
1. Alterar addAttributes para o conjunto de dados de origem datasets.xml , como necessário.
2. Apague um dos arquivos copiados.
3. Definir um bandeira para recarregar o conjunto de dados imediatamente. Se você usar uma bandeira e tiver uma assinatura por e-mail para o conjunto de dados, você receberá dois e-mails: um quando o conjunto de dados primeiro recarrega e começa a copiar os dados, e outro quando o conjunto de dados carregar novamente (automaticamente) e detecta os novos arquivos de dados locais.
4. O arquivo excluído será regenerado com os novos metadados. Se o conjunto de dados de origem estiver indisponível, o EDDGrid O conjunto de dados de cópia obterá metadados do arquivo regenerado, já que é o arquivo mais jovem.

EDDGrid esqueleto de cópia XML

<dataset type="EDDGridCopy" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaFiles>true|false(default)</accessibleViaFiles>
        
      <accessibleViaWMS>...</accessibleViaWMS> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <matchAxisNDigits>...</matchAxisNDigits> 
      <fileTableInMemory>...</fileTableInMemory> 
      <checkSourceData>...</checkSourceData> 
      <onlySince>...</onlySince> 
      <dataset>...</dataset> 
  </dataset>

EDDTable FromCasandra

EDDTable FromCasandra lida com dados de um Cassandra mesa. Cassandra é uma base de dados NoSQL.

ERDDAP™ pode trabalhar com Cassandra v2 e v3 sem alterações ou diferenças na configuração. Temos testado com Cassandra v2 e v3 de Apache . É provável que ERDDAP™ também pode trabalhar com Cassandra baixado de DataStax.
Para agosto de 2019 - maio de 2021, tivemos dificuldade em fazer Cassandra trabalhar com o AdoptOpenJdk Java v8. Ele jogou uma EXCEPÇÃO\_ACCESS\_VIOLATION). Mas agora (Maio 2021) , esse problema foi: podemos usar com sucesso Cassandra v2.1.22 e AdoptOpenJdk jdk8u292-b10.

Quadro 1

Cassandra não suporta "joins" da maneira que os bancos de dados relacionais fazem. Um. ERDDAP™ EDDTableFromCassandra dataset maps para um (talvez um subconjunto de um) Mesa Cassandra.

Cassandra datasets.xml

ERDDAP™ vem com a Cassandra Java driver, então você não precisa instalá-lo separadamente.
Leia cuidadosamente todas as informações deste documento sobre EDDTableFromCassandra. Alguns dos detalhes são muito importantes.
A Cassandra Java driver é destinado a trabalhar com Apache Cassandra (1.2+) e DataStax Enterprise (3.1+) . Se você estiver usando o Apache Cassandra 1.2.x, você deve editar o arquivo cassandra.yaml para cada nó para definir start\_native\_transport: true, então reinicie cada nó.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo (especialmente [<partição KeySourceNames>] (#partitionkeysourcenames) ). Você pode coletar a maioria das informações que você precisa para criar o XML para um conjunto de dados EDDTableFromCasandra contatando o administrador Cassandra e pesquisando a web.

Gerar conjuntos de dados Xml tem duas opções especiais para EDDTableFromCassandra:

Se você entrar "!!!LIST!!!" (sem as citações) para o espaço-chave, o programa exibirá uma lista de espaços-chave
Se você entrar em um espaço-chave específico e, em seguida, entrar "!!!LIST!!!" (sem as citações) para o nome da tabela, o programa exibirá uma lista de tabelas nesse espaço-chave e suas colunas.

Sensibilidade de caso

Caso-insensível Keyspace e Nomes de Tabela - A Cassandra trata nomes de espaço-chave e tabelas de uma forma insensível a casos. Por causa disso, você deve nunca usar uma palavra reservada (mas com um caso diferente) como um espaço-chave Cassandra ou nome de tabela.
Nomes de coluna sensível a casos -- Por padrão, Cassandra trata nomes de colunas de forma insensível a casos. Se você usar uma das palavras reservadas de Cassandra como um nome de coluna (Por favor, não!) , você precisa usar

        <columnNameQuotes>"<columnNameQuotes>

em datasets.xml para este conjunto de dados de modo que Cassandra e ERDDAP™ tratará os nomes das colunas de forma sensível ao caso. Isso provavelmente será uma enorme dor de cabeça para você, porque é difícil determinar as versões sensíveis a casos dos nomes das colunas -- Cassandra quase sempre exibe os nomes das colunas como todos os casos inferiores, independentemente do caso verdadeiro.

Trabalhe em estreita colaboração com o administrador Cassandra, que pode ter experiência relevante. Se o conjunto de dados não carregar, leia o mensagem de erro cuidadosamente para descobrir o porquê.

Cassandra<conexão Propriedade >

Cassandra tem propriedades de conexão que podem ser especificadas em datasets.xml . Muitos deles afetarão o desempenho da Cassandra... ERDDAP™ ligação. Infelizmente, as propriedades Cassandra devem ser definidas programaticamente em Java Então ERDDAP™ deve ter código para cada propriedade ERDDAP™ suportes. Atualmente, ERDDAP™ suporta estas propriedades: (Os padrões mostrados são o que vemos. Os padrões do seu sistema podem ser diferentes.)

Opções gerais
<conexão Nome do imóvel compressão " nenhum | LZ4 | Snappy </conexão Propriedade (case-insensitive, default=none)
(Conselho de compressão geral: use 'none' se a conexão entre Cassandra e ERDDAP™ é local / rápido e usar 'LZ4' se a conexão é remota / lenta.)
<conexão Nome do imóvel credenciais " nome de usuário/password </conexão Propriedade (Isso é literal. '/' )
<conexão Nome do imóvel métricas " verdadeiro | falso </conexão Propriedade (2021-01-25 foi default=true, agora ignorado e sempre falso)
<conexão Nome do imóvel porto " um livro </conexão Propriedade (padrão para protocolo binário nativo=9042)
<conexão Nome do imóvel sr. " verdadeiro | falso </conexão Propriedade (default=false)
(A minha rápida tentativa de usar o ssl falhou. Se conseguires, diz-me como fizeste.)
Opções de consulta
<conexão Nome do imóvel consistência Nível " Todos | qualquer um | cada um | local | local | local\_serial | um | - Sim. | serial | três | dois. </conexão Propriedade (case-insensitive, default=ONE)
<conexão Nome do imóvel Feche o tamanho " um livro </conexão Propriedade (predefinição:5000)
(Não definir fetchSize para um valor menor.)
<conexão Nome do imóvel SérieConsistência " Todos | qualquer um | cada um | local | local | local\_serial | um | - Sim. | serial | três | dois. </conexão Propriedade (case-insensitive, default=SERIAL)
Opções de soquete
<conexão Nome do imóvel Tempo de conexão " um livro </conexão Propriedade (predefinição:5000)
(Não definir conexão TimeoutMillis para um valor menor.)
<conexão Nome do imóvel manter vivo " verdadeiro | falso </conexão Propriedade <conexão Nome do imóvel Leia o TimeoutMillis " um livro </conexão Propriedade (O padrão de leitura da CassandraTimeoutMillis é 12000, mas ERDDAP™ muda o padrão para 120000. Se Cassandra está jogando leituraTimeouts, aumentando isso pode não ajudar, porque Cassandra às vezes os joga antes desta vez. O problema é mais provável que você esteja armazenando muitos dados por partição Combinação de chaves.)
<conexão Nome do imóvel receber o tamanho do buffer " um livro </conexão Propriedade (Não está claro o que o padrão recebeBufferSize é. Não ponhas isto num pequeno valor.)
<conexão Nome do imóvel Por favor. " um livro </conexão Propriedade <conexão Nome do imóvel TcpNo. " verdadeiro | falso </conexão Propriedade (default=null)

Se você precisar definir outras propriedades de conexão, consulte nosso seção sobre como obter suporte adicional .

Para uma dada inicialização do Tomcat, o ConnectionProperties é usado apenas na primeira vez que um conjunto de dados é criado para uma dada URL Cassandra. Todas as recargas desse conjunto de dados e todos os conjuntos de dados subseqüentes que compartilham a mesma URL usarão essas conexões originaisProperties.

CQL

The Cassandra Query Language (CQL) é superficialmente como SQL, a linguagem de consulta usada por bancos de dados tradicionais. Porque... OPeNDAP Os pedidos de dados tabulares foram projetados para imitar solicitações de dados tabulares SQL, é possível para ERDDAP™ para converter solicitações de dados tabulares em CQL Bound/PreparedStatements. ERDDAP™ registra a declaração em - Não. como declaração como texto: O estatuto
A versão da declaração que você vê será uma representação de texto da declaração e só terá "?" onde os valores de restrição serão colocados.
Não tão simples... Infelizmente, o CQL tem muitas restriÃ§Ãμes sobre quais colunas podem ser consultadas com que tipos de constrangimentos, por exemplo, colunas de partiÃ§Ã£o podem ser constrangidas com = e IN, portanto ERDDAP™ envia algumas restrições para Cassandra e aplica todas as restrições depois que os dados são recebidos da Cassandra. Para ajudar ERDDAP™ lidar eficientemente com Cassandra, você precisa especificar [<partição KeySourceNames>] (#partitionkeysourcenames) ,<clusterColumnSourceNames>] (Nomes de fonte) E...<indexColumnSourceNames>] (#indexcolumnsourcenames) em datasets.xml para este conjunto de dados. Estas são as formas mais importantes de ajudar ERDDAP™ trabalhar de forma eficiente com Cassandra. Se não contares ERDDAP™ esta informação, o conjunto de dados será dolorosamente lento em ERDDAP™ e usar toneladas de recursos Cassandra.

<partição KeySourceNames >

Porque as chaves de partição desempenham um papel central em tabelas Cassandra, ERDDAP™ precisa saber a sua sourceName s e, se relevante, outras informações sobre como trabalhar com eles.

Você precisa especificar uma lista separada por vírgula de nomes de colunas de código-fonte de partição em datasets.xml via via via via<partição KeySourceNames>. Exemplo simples,

        <partitionKeySourceNames>station, deviceid<partitionKeySourceNames>

Exemplo mais complexo,

        <partitionKeySourceNames>deviceid=1007, date/sampletime/1970-01-01<partitionKeySourceNames>

Chaves de partição TimeStamp -- Se uma das colunas de partição é uma coluna de timestamp que tem uma versão mais grossa de outra coluna de timestamp, especifique isso via *partiçãoKeySourcName/otherColumnSourceName/ time\_precision *
Onde? time\_precision é um dos time\_precision strings usadas em outros lugares ERDDAP . A trilha Z no time\_precision string é o padrão, então não importa se o time\_precision termina em Z ou não. Por exemplo, ERDDAP™ irá interpretar data / hora do almoço / 1970-01-01 como "Os conjuntos para data podem ser construídos a partir de restrições no tempo de amostra usando este time\_precision " A conversão real de restrições é mais complexa, mas essa é a visão geral. Use isso sempre que for relevante. Permite ERDDAP™ trabalhar de forma eficiente com Cassandra. Se esta relação entre colunas existe em uma tabela Cassandra e você não conta ERDDAP™ , o conjunto de dados será dolorosamente lento em ERDDAP™ e usar toneladas de recursos Cassandra.
Único Chaves de partição de valor -- Se queres um ERDDAP™ dataset para trabalhar com apenas um valor de uma chave de partição, especifique partiçãoKeySourceName=valor . Não use citações para uma coluna numérica, por exemplo, deviceid=1007 Use citações para uma coluna String, por exemplo, stationid="Point Pinos"
Dataset Default Ordenar Ordem -- A ordem da chave de partição< dataVariable > datasets.xml determina a ordem de classificação padrão dos resultados de Cassandra. Naturalmente, os usuários podem solicitar uma ordem de classificação diferente para um determinado conjunto de resultados por afinação & orderBy (" lista de variáveis separadas por vírgula ") até ao fim da sua consulta.
Por padrão, Cassandra e ERDDAP™ tratar nomes de colunas de forma insensível. Mas se você definir colunaNomeQuotes para ", ERDDAP™ tratará os nomes das colunas Cassandra de uma forma sensível ao caso.

<partição KeyCSV >

Se isso for especificado, ERDDAP™ vai usá-lo em vez de pedir Cassandra para a partição InformaÃ§Ãμes-chave cada vez que o conjunto de dados Ã© recarregado. Isso fornece a lista de valores-chave de partição distintos, na ordem em que eles serão usados. Os tempos devem ser especificados como segundos desde 1970-01T00:00:00Z. Mas há também duas maneiras alternativas especiais para especificar tempos (cada codificado como uma string) :

tempo (AISO8601 Tempo) (MAY ser codificado como uma string)
"tempos (anISO8601StartTime, strideSeconds, stopTime) " (Deve ser codificado como uma string)
Pare! O tempo pode ser um ISO8601 Tempo ou um " now- nUnits" tempo (por exemplo, " now- 3 minutos) . Pare! O tempo não tem que ser um jogo exato do início Tempo + x strideSeconds. Uma linha com umas vezes () valor é expandido em várias linhas antes de cada consulta, então a lista de partição As chaves podem estar sempre prontas. Por exemplo,

    <partitionKeyCSV>
    deviceid,date
    1001,"times(2014-11-01T00:00:00Z, 86400, 2014-11-02T00:00:00Z)"
    1007,"time(2014-11-07T00:00:00Z)"
    1008,time(2014-11-08T00:00:00Z)
    1009,1.4154912E9
    </partitionKeyCSV>

expande nesta tabela de combinações de teclas de partição:

    deviceid,date
    1001,1.4148E9
    1001,1.4148864E9
    1007,1.4153184E9
    1008,1.4154048E9
    1009,1.4154912E9 

<clusterColumnSourceNames >

Cassandra aceita restrições SQL-como em colunas de cluster, que são as colunas que formam a segunda parte da chave primária (após a chave de partição (S) ) . Então, é essencial que você identifique essas colunas via<clusterColumnSourceNames>. Isso permite ERDDAP™ trabalhar de forma eficiente com Cassandra. Se houver colunas de cluster e você não conta ERDDAP , o conjunto de dados será dolorosamente lento em ERDDAP™ e usar toneladas de recursos Cassandra.

Por exemplo,<clusterColumnSourceNames> myClusterColumn1, myClusterColumn2 </clusterColumnSourceNames>
Se uma tabela Cassandra não tiver colunas de cluster, não especifique<clusterColumnSourceNames>, ou especifique-o sem valor.
Por padrão, Cassandra e ERDDAP™ tratar nomes de colunas de forma insensível. Mas se você definir colunaNomeQuotes para ", ERDDAP™ tratará os nomes das colunas Cassandra de uma forma sensível ao caso.

<indexColumnSourceNames >

Cassandra aceita '=' restrições em colunas de índice secundário, que são as colunas que você criou explicitamente índices para via

    CREATE INDEX *indexName* ON *keyspace.tableName* (*columnName*);

(Sim, os parênteses são necessários.)
Então, é muito útil se você identificar essas colunas via<indexColumnSourceNames>. Isso permite ERDDAP™ trabalhar de forma eficiente com Cassandra. Se houver colunas de índice e você não conta ERDDAP , algumas consultas serão desnecessariamente, dolorosamente lentas em ERDDAP™ e usar toneladas de recursos Cassandra.

Por exemplo,<indexColumnSourceNames> myIndexColumn1, myIndexColumn2 </indexColumnSourceNames>
Se uma tabela Cassandra não tiver colunas de índice, não especifique<indexColumnSourceNames>, ou especifique-o sem valor.
Os índices Cassandra não são como índices de banco de dados. Índices Cassandra só ajudam com '=' restrições. E eles são apenas recomendado para colunas que têm muito menos valores distintos do que valores totais.
Por padrão, Cassandra e ERDDAP™ tratar nomes de colunas de forma insensível. Mas se você definir colunaNomeQuotes para ", ERDDAP™ tratará os nomes das colunas Cassandra de uma forma sensível ao caso.

<maxRequestFraction >

Quando ERDDAP™ (re) carrega um conjunto de dados, ERDDAP™ recebe de Cassandra a lista de combinações distintas das teclas de partição. Para um conjunto de dados enorme, o número de combinações será enorme. Se você quiser evitar que os pedidos dos usuários solicitem a maioria ou todo o conjunto de dados (ou mesmo um pedido que pede ERDDAP™ para baixar a maioria ou todos os dados, a fim de filtrar ainda mais) Você pode dizer ERDDAP™ apenas para permitir solicitações que reduzem o número de combinações por algum valor através<maxRequestFraction>, que é um número de ponto flutuante entre 1e-10 (o que significa que o pedido não pode precisar de mais de 1 combinação em um bilhão) e 1 (o padrão, o que significa que a solicitação pode ser para todo o conjunto de dados) . Por exemplo, se um conjunto de dados tem 10000 combinações distintas das teclas de partição e maxRequestFraction é definido para 0.1, então solicitações que precisam de dados de 1001 ou mais combinações gerarão uma mensagem de erro, mas solicitações que precisam de dados de 1000 ou menos combinações serão permitidas.

Geralmente, quanto maior o conjunto de dados, menor você deve definir<maxRequestFraction>. Então você pode configurá-lo para 1 para um pequeno conjunto de dados, 0,1 para um conjunto de dados de tamanho médio, 0,01 para um grande conjunto de dados e 0,0001 para um conjunto de dados enorme.

Esta abordagem está longe de ser perfeita. Isso levará a alguns pedidos razoáveis sendo rejeitados e alguns pedidos demasiado grandes sendo permitidos. Mas é um problema difícil e esta solução é muito melhor do que nada.

Cassandra subsetVariables

Como com outros conjuntos de dados EDDTable, você pode especificar uma lista separada por vírgulas< dataVariable > destinationName s em um atributo global chamado " subsetVariables " identificar variáveis que tenham um número limitado de valores. O conjunto de dados terá então uma página web .subset e mostrará listas de valores distintos para essas variáveis em listas suspensas em muitas páginas da web.

Incluindo apenas variáveis de partição e colunas estáticas na lista é STRONGLY E NCO URAGED. Cassandra será capaz de gerar a lista de combinações distintas muito rapidamente e facilmente cada vez que o conjunto de dados é recarregado. Uma exceção é chaves de partição do timestamp que são versões grossas de alguma outra coluna do timestamp -- é provavelmente melhor deixá-los fora da lista de subsetVariables uma vez que há um grande número de valores e eles não são muito úteis para os usuários.

Se você incluir a chave não-partição, variáveis não-estáticas na lista, provavelmente será Muito bem. computacionalmente caro para Cassandra cada vez que o conjunto de dados é recarregado, porque ERDDAP™ tem que olhar através de cada linha do conjunto de dados para gerar as informações. Na verdade, a consulta provavelmente falhará. Assim, exceto para conjuntos de dados muito pequenos, este é STRONGLY DISCOURAGED.

Cassandra DataTypes

Porque há alguma ambiguidade sobre a qual Tipos de dados Cassandra mapa a que ERDDAP™ tipos de dados, você precisa especificar um [<dataType>] (# Datatype #) tag para cada [< dataVariable > (#datavariable) para contar ERDDAP™ que dataType usar. O padrão ERDDAP™ dados Tipos (e os tipos de dados Cassandra mais comuns correspondentes) são:

booleano (booleano) , que ERDDAP™ então armazena como bytes
bytes (int, se o intervalo for -128 a 127)
curto (int, se o intervalo for -32768 a 32767)
- Não. (int, contador?, varint?, se o intervalo for -2147483648 para 2147483647)
longo (bigint, contra?, varint?, se o intervalo for -92233720368575808 a 92233720368575807)
flutuar (flutuar)
duplo (duplo, decimal (com possível perda de precisão) , timestamp)
Charlie. (ascii ou texto, se eles nunca têm mais de 1 caractere)
String (ascii, texto, varchar, inet, uuid, timeuuid, blob, mapa, conjunto, lista?)

Cassandra vezes é um caso especial: uso ERDDAP Dados duplos Tipo.

Se você especificar um string dataType em ERDDAP™ para um mapa Cassandra, conjunto ou lista, o mapa, conjunto ou lista em cada linha Cassandra será convertido para uma única string em uma única linha na ERDDAP™ mesa. ERDDAP™ tem um sistema alternativo para listas; veja abaixo.

tipo Listas... ERDDAP É...<dataType>] (# Datatype #) tag para Cassandra dataVariable s pode incluir o regular ERDDAP™ dados Tipos (ver acima) mais vários dataTypes especiais que podem ser usados para colunas de lista Cassandra: booleanList, byteList, ubyteList, shortList, ushortList, intList, uintList, longList, ulongList, floatList, doubleList, charList, StringList. Quando uma dessas colunas de lista está nos resultados que estão sendo passados para ERDDAP™ , cada linha de dados de origem será expandida para lista. tamanho () linhas de dados em ERDDAP ; dados simples Tipos (por exemplo,) nessa linha de dados de origem será lista duplicada. tamanho () tempos. Se os resultados contiverem mais de uma variável lista, todas as listas em uma determinada linha de dados DEVE ter o mesmo tamanho e DEVE ser listas "paralelas", ou ERDDAP™ gerará uma mensagem de erro. Por exemplo, para medições de correntes de um ADCP, profundidade \[ 0 \] , u \[ 0 \] , vCurrent \[ 0 \] e zCurrent \[ 0 \] são todos relacionados, e profundidade \[ 1 \] , u \[ 1 \] , vCurrent \[ 1 \] e zCurrent \[ 1 \] estão todos relacionados, ... Alternativamente, se você não quiser ERDDAP™ para expandir uma lista em várias linhas no ERDDAP™ tabela, especifique String como o dataVariable Dados Digite assim a lista inteira será representada como uma corda em uma linha em ERDDAP .

Dados da Cassandra TimeStamp

Os dados do timestamp da Cassandra estão sempre conscientes dos fusos horários. Se você inserir dados do timestamp sem especificar um fuso horário, Cassandra assume que o timestamp usa o fuso horário local.

ERDDAP™ suporta dados do timestamp e sempre apresenta os dados no Zulu /GMT fuso horário. Então, se você inserir dados do timestamp em Cassandra usando um fuso horário diferente de Zulu /GMT, lembre-se de que você precisa fazer todas as consultas para dados do timestamp em ERDDAP™ usando o Zulu /GMT fuso horário. Então não se surpreenda quando os valores do timestamp que saem de ERDDAP são deslocados por várias horas por causa do interruptor de fuso horário de local para Zulu - Hora da GMT.

Em ERDDAP ' datasets.xml , no< dataVariable > tag para uma variável timestamp, conjunto

          <dataType>double</dataType>

e em< addAttributes Conjunto

          <att name="units">seconds since 1970-01-01T00:00:00Z</att>

Sugestão: Se os dados são um intervalo de tempo, é útil ter os valores do timestamp referem-se ao centro do intervalo de tempo implícito (por exemplo, noon) . Por exemplo, se um usuário tem dados para 2010-03-26T13:00Z de outro conjunto de dados e eles querem os dados mais próximos deste conjunto de dados Cassandra que tem dados para cada dia, em seguida, os dados para 2010-03-26T12:00Z (representando dados Cassandra para essa data) é obviamente o melhor (em oposição à meia-noite antes ou depois, onde é menos óbvio que é melhor) .
ERDDAP™ tem um utilitário para Converter um numérico Tempo para / de um tempo de corda .
Ver Como? ERDDAP™ Lidas com o tempo .

Nulls inteiros

Cassandra suporta nulls em Cassandra int ( ERDDAP™ - Não.) e grande ( ERDDAP™ longo) colunas, mas ERDDAP™ não suporta nulas verdadeiras para qualquer tipo de dados inteiro. Por padrão, as nulas de inteiro Cassandra serão convertidas em ERDDAP™ para 2147483647 para colunas int, ou 9223372036854775807 para colunas longas. Estes aparecerão como "NaN" em alguns tipos de arquivos de saída de texto (por exemplo, .csv) , "" em outros tipos de arquivos de saída de texto (por exemplo, .htmlTable ) , e o número específico (2147483647 para valores int ausentes) em outros tipos de arquivos (por exemplo, arquivos binários como .nc e esteira) . Um usuário pode procurar por linhas de dados com esse tipo de valor ausente, referindo-se a "NaN", por exemplo, "&windSpeed=NaN".

Se você usar algum outro valor inteiro para indicar valores ausentes em sua tabela Cassandra, por favor, identifique esse valor em datasets.xml :

<att name="missing\_value" type="int"\>-999</att>

Para colunas de ponto flutuante Cassandra, nulls são convertidos para NaNs em ERDDAP . Para tipos de dados Cassandra que são convertidos para Strings em ERDDAP™ , nulls se convertem em Strings vazios. Isso não deve ser um problema.

"WARNING: Re-preparing já preparado consulta"

"WARNING: Re-preparing já preparado consulta" em Toca a brincar. /logs/catalina.out (ou algum outro arquivo de log Tomcat)
A documentação da Cassandra diz que há problemas se a mesma consulta for feita em um PreparedStatement duas vezes (ou mais) . (Veja isto Relatório de bug .) Para evitar fazer Cassandra louco, ERDDAP™ caches todos os estados preparados para que ele possa reutilizá-los. Esse cache é perdido se/quando Tomcat/ ERDDAP™ é reiniciado, mas eu acho que está tudo bem porque os estados preparados estão associados a uma dada sessão (entre Java e Cassandra) , que também está perdido. Então, você pode ver essas mensagens. Não sei outra solução. Felizmente, é um aviso, não um erro (embora Cassandra ameaça que pode levar a problemas de desempenho) .

Cassandra afirma que os estados preparados são bons para sempre, então ERDDAP Os estados preparados em cache nunca devem ficar fora de data/inválidos. Se isso não é verdade, e você tem erros sobre certos estados preparados sendo fora de data / inválido, então você precisa reiniciar ERDDAP™ para limpar ERDDAP O cache dos estados preparados.

Segurança Cassandra

Ver Protegendo Cassandra

Ao trabalhar com Cassandra, você precisa fazer as coisas com segurança e segurança, o mais seguro possível para evitar permitir que um usuário malicioso danifique sua Cassandra ou obtenha acesso aos dados que eles não devem ter acesso. ERDDAP™ tenta fazer as coisas de uma forma segura, também.

Nós encorajamos você a configurar ERDDAP™ para se conectar a Cassandra como um usuário Cassandra que só tem acesso ao relevante mesa de mesa (S) e só tem privilégios LER.
Nós encorajamos você a configurar a conexão de ERDDAP™ para Cassandra para que
- sempre usa SSL,
- somente permite conexões de um endereço IP (ou um bloco de endereços) e de um ERDDAP™ usuário e
- apenas transfere senhas em seu formulário de hasshed MD5.
\[ PROBLEMAS CONHECIDOS \] A conexãopropriedades (incluindo a senha!) são armazenados como texto simples em datasets.xml . Não encontramos uma maneira de permitir ao administrador inserir a senha Cassandra durante ERDDAP 's startup in Tomcat (que ocorre sem entrada do usuário) , então a senha deve ser acessível em um arquivo. Para tornar isso mais seguro:
Tu. (o ERDDAP™ administrador) deve ser o proprietário de datasets.xml e têm acesso READ e WRITE.
Faça um grupo que inclua apenas user=tomcat. Use chgrp para fazer que o grupo para datasets.xml , com apenas privilégios LER.
Use chmod para atribuir privilégios o-rwx (não LER ou WRITE acesso para "outros" usuários) para datasets.xml .
Quando entrar ERDDAP™ , a senha e outras propriedades de conexão são armazenadas em "privado" Java variáveis.
Os pedidos dos clientes são analisados e verificados para validade antes de gerar os pedidos CQL para Cassandra.
Os pedidos de Cassandra são feitos com CQL Bound/PreparedStatements, para evitar a injeção de CQL. Em qualquer caso, Cassandra é inerentemente menos suscetível à injeção de CQL do que bancos de dados tradicionais são para Injeção de SQL .

Velocidade de Cassandra

A Cassandra pode ser rápida ou lenta. Há algumas coisas que você pode fazer para torná-lo rápido:

Em geral - A natureza do CQL é que as consultas são declarativa . Eles apenas especificam o que o usuário quer. Eles não incluem uma especificação ou dicas para como a consulta deve ser tratada ou otimizada. Então não há maneira de ERDDAP™ para gerar a consulta de tal forma que ajuda Cassandra otimizar a consulta (ou de qualquer forma especifica como a consulta deve ser tratada) . Em geral, cabe ao administrador Cassandra configurar as coisas (por exemplo, índices) para otimizar para certos tipos de consultas.
Especificando as colunas do timestamp que estão relacionadas com as teclas de partição do timestamp do coarser-precision via [<partição KeySourceNames>] (#partitionkeysourcenames) é a maneira mais importante de ajudar ERDDAP™ trabalhar de forma eficiente com Cassandra. Se este relacionamento existe em uma mesa Cassandra e você não conta ERDDAP™ , o conjunto de dados será dolorosamente lento em ERDDAP™ e usar toneladas de recursos Cassandra.
Especificando as colunas de cluster através de [<clusterColumnSourceNames>] (Nomes de fonte) é a segunda maneira mais importante de ajudar ERDDAP™ trabalhar de forma eficiente com Cassandra. Se houver colunas de cluster e você não conta ERDDAP , um grande subconjunto das possíveis consultas para dados será desnecessariamente, dolorosamente lento em ERDDAP™ e usar toneladas de recursos Cassandra.
Fazer Índices para Variáveis Comunicamente Restritas -- Você pode acelerar algumas consultas criando índices para colunas Cassandra que muitas vezes são limitados com restrições "=".

Cassandra não pode fazer índices para lista, definir ou mapear colunas.

Especificando as colunas de índice através de [<indexColumnSourceNames>] (#indexcolumnsourcenames) é uma maneira importante de ajudar ERDDAP™ trabalhar de forma eficiente com Cassandra. Se houver colunas de índice e você não conta ERDDAP , algumas consultas para dados serão desnecessariamente, dolorosamente lentas em ERDDAP™ e usar toneladas de recursos Cassandra.

Cassandra Stats

Mensagens diagnósticas "Cassandra stats" - ... Para cada ERDDAP™ consulta de usuário para um conjunto de dados Cassandra, ERDDAP™ imprimirá uma linha no arquivo de log, Diretriz de grande porte /logs/log.txt, com algumas estatísticas relacionadas à consulta, por exemplo,

        \\* Cassandra stats: partitionKeyTable: 2/10000=2e-4 < 0.1 nCassRows=1200 nErddapRows=12000 nRowsToUser=7405  

Usando os números no exemplo acima, isso significa:

Quando ERDDAP™ último (re) carregou este conjunto de dados, disse Cassandra ERDDAP™ que havia 10000 combinações distintas das chaves de partição. ERDDAP™ cacheou todas as combinações distintas em um arquivo.
Devido às restrições do usuário, ERDDAP™ identificou 2 combinações dos 10000 que podem ter os dados desejados. Então... ERDDAP™ fará 2 chamadas para Cassandra, uma para cada combinação das teclas de partição. (É o que a Cassandra exige.) Claramente, é problemático se um grande conjunto de dados tem um grande número de combinações das chaves de partição e uma determinada solicitação não reduz drasticamente isso. Você pode exigir que cada pedido reduza o espaço chave através da configuração [<maxRequestFraction>] (#maxrequestfraction) . Aqui, 2/10000=2e-4, que é menos do que o maxRequestFraction (0.1) , então o pedido foi permitido.
Depois de aplicar as restrições nas teclas de partição, colunas de cluster e colunas de índice que foram enviados por ERDDAP™ , Cassandra retornou 1200 linhas de dados para ERDDAP™ no Resultado.
O resultado conjunto deve ter sido dados Tipo... algum tipo Lista colunas (com uma média de 10 itens por lista) Porque ERDDAP™ expandiu as 1200 linhas de Cassandra em 12000 linhas em ERDDAP .
ERDDAP™ sempre aplica todas as restrições do usuário aos dados da Cassandra. Neste caso, as restrições que Cassandra não tinha tratado reduziram o número de linhas para 7405. Esse é o número de linhas enviadas para o usuário.

O uso mais importante dessas mensagens de diagnóstico é certificar-se de que ERDDAP™ está fazendo o que você acha que está fazendo. Se não for (por exemplo, não está reduzindo o número de combinações distintas como esperado?) , então você pode usar as informações para tentar descobrir o que está errado.

Pesquisa e experiência para encontrar e definir melhor [<conexãoProperty>] (#cassandra-connectionproperty) 's.
Verifique a velocidade da conexão de rede entre Cassandra e ERDDAP . Se a conexão for lenta, veja se você pode melhorá-la. A melhor situação é quando ERDDAP™ está em execução em um servidor anexado ao mesmo (rápido) mudar como o servidor executando o nó Cassandra para o qual você está conectando.
Por favor, seja paciente. Leia as informações aqui e na documentação Cassandra cuidadosamente. Experimento. Vê o teu trabalho. Se a Cassandra... ERDDAP™ conexão ainda é mais lenta do que você espera, inclua o esquema da sua mesa Cassandra e seu ERDDAP™ pedaço de datasets.xml e ver o nosso seção sobre como obter suporte adicional .
Se tudo o resto falhar, considerar armazenar os dados em uma coleção de NetCDF v3 .nc arquivos (especialmente .nc arquivos que usam CF Geometrias de amostragem discretas (DSG) Estruturas de dados Ragged Array contíguas e assim pode ser tratada com ERDDAP ' EDDTable FromNcCFFiles ) . Se eles são logicamente organizados (cada um com dados para um pedaço de espaço e tempo) , ERDDAP™ pode extrair dados deles muito rapidamente.

EDDTable FromCasandra esqueleto XML

<dataset type="EDDTableFromCassandra" datasetID\="..." active\="..." >
      <ipAddress>...</ipAddress>
        
      <connectionProperty name="name">value</connectionProperty>
        
      <keyspace>...</keyspace> 
      <tableName>...</tableName> 
      <partitionKeySourceNames>...<partitionKeySourceNames>
        
      <clusterColumnSourceNames>...<clusterColumnSourceNames>
        
      <indexColumnSourceNames>...<indexColumnSourceNames> 
      <maxRequestFraction>...<maxRequestFraction>
        
      <columnNameQuotes>...<columnNameQuotes> 
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <addAttributes>...</addAttributes> 
      <dataVariable>...</dataVariable> 
  </dataset>

EDDTable FromDapSequence

EDDTable FromDapSequence manipula variáveis dentro de seqüências de 1 e 2 níveis de DAP servidores como DAP PERGUNTA (nohttps://www.pmel.noaa.gov/epic/software/dapper/, agora descontinuado) .

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo. Você pode coletar as informações que você precisa, olhando para os arquivos DDS e DAS do conjunto de dados de origem em seu navegador ( adicionando .das e .dds ao sourceUrl (um exemplo foihttps://dapper.pmel.noaa.gov/dapper/epic/tao\_time\_series.cdp.dds).
Uma variável está em DAP se a resposta .dds indica que a estrutura de dados que segura a variável é uma "sequência" (caso insensível) .
Em alguns casos, você verá uma sequência dentro de uma sequência, uma sequência de 2 níveis - EDDTableFromDapSequence lida com isso também.

EDDTable FromDapSequence esqueleto XML

<dataset type="EDDTableFromDapSequence" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <outerSequenceName>...</outerSequenceName>
        
      <innerSequenceName>...</innerSequenceName>
        
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <sourceCanConstrainStringEQNE>true|false</sourceCanConstrainStringEQNE>
      <sourceCanConstrainStringGTLT>true|false</sourceCanConstrainStringGTLT>
      <sourceCanConstrainStringRegex>...</sourceCanConstrainStringRegex>
      <skipDapperSpacerRows>...</skipDapperSpacerRows>
        
      <addAttributes>...</addAttributes> 
      <dataVariable>...</dataVariable> 
    </dataset>

EDDTable FromDatabase

EDDTable FromDatabase lida com dados de uma tabela de banco de dados relacional ou vista.

Uma Tabela ou Vista

Se os dados que você deseja servir estão em duas ou mais tabelas (e assim precisa de um JOIN para extrair dados de ambas as tabelas ao mesmo tempo) , você precisa fazer um denormalização (já se juntou) tabela ou vista com todos os dados que você deseja disponibilizar como um conjunto de dados ERDDAP .

Para bases de dados grandes e complexas, pode fazer sentido separar vários pedaços como tabelas desnormalizadas, cada um com um tipo diferente de dados, que se tornará conjuntos de dados separados em ERDDAP .

Fazer uma tabela desnormalizada para uso em ERDDAP™ Pode parecer uma ideia maluca para ti. Por favor, confia em nós. Há várias razões por que ERDDAP™ trabalhos com tabelas desnormalizadas:

É muito mais fácil para os usuários. Quando ERDDAP™ apresenta o conjunto de dados como uma, simples, denormalizada, tabela única, é muito fácil para qualquer pessoa entender os dados. A maioria dos usuários nunca ouviu falar de tabelas normalizadas, e muito poucos entendem chaves, chaves estrangeiras, ou tabela se junta, e quase certamente não sabem os detalhes dos diferentes tipos de junções, ou como especificar o SQL para fazer uma união (ou múltiplas uniões) corretamente. Usar uma tabela desnormalizada evita todos esses problemas. Esta razão justifica apenas o uso de uma tabela única desnormalizada para a apresentação de um conjunto de dados para ERDDAP™ usuários.
Mesas normalizadas (várias tabelas relacionadas por colunas-chave) são ótimos para armazenar dados em um banco de dados. Mas mesmo em SQL, o resultado que é retornado ao usuário é desnormalizado (se juntar) mesa única. Então parece razoável apresentar o conjunto de dados aos usuários como uma tabela única enorme, desnormalizada, da qual eles podem então solicitar subconjuntos (por exemplo, me mostre linhas da tabela onde a temperatura> 30) .
Você pode fazer alterações para ERDDAP™ sem mudar suas mesas. ERDDAP™ tem alguns requisitos que podem ser diferentes de como você configurou seu banco de dados. Por exemplo, ERDDAP™ requer que os dados do timestamp sejam armazenados em campos "timestamp com fuso horário". Fazendo uma tabela/visão separada para ERDDAP™ , você pode fazer essas mudanças quando você faz a tabela denormalizada para ERDDAP . Assim, você não precisa fazer nenhuma mudança em suas tabelas.
ERDDAP™ recriará algumas das estruturas das tabelas normalizadas. Você pode especificar quais colunas de dados vêm das tabelas 'outro' e, portanto, tem um número limitado de valores distintos. ERDDAP™ irá recolher todas as diferentes combinações de valores nestas colunas e apresentá-los aos usuários em um especial . subset página web que ajuda os usuários a selecionar rapidamente subconjuntos do conjunto de dados. Os valores distintos para cada coluna também são mostrados em listas suspensas nas outras páginas do conjunto de dados.
Uma tabela desnormalizada faz com que os dados sejam entregues de você para o ERDDAP Administrador fácil. Você é o especialista para este conjunto de dados, então faz sentido que você tome as decisões sobre quais tabelas e quais colunas para se juntar e como se juntar a eles. Então não tens de nos entregar. (ou pior, os usuários finais) várias tabelas e instruções detalhadas para como se juntar a eles, você só tem que nos dar acesso à tabela denormalizada.
Uma tabela desnormalizada permite um acesso eficiente aos dados. A forma desnormalizada é geralmente mais rápida de acesso do que a forma normalizada. Juntas podem ser lentas. As múltiplas uniões podem ser muito lentas.

Para obter os dados de duas ou mais tabelas no banco de dados ERDDAP™ , há três opções:

Opção recomendada: Você pode criar um arquivo de valor de vírgula ou separador com os dados da tabela desnormalizada. Se o conjunto de dados é enorme, então faz sentido criar vários arquivos, cada um com um subconjunto coeso da tabela desnormalizada (por exemplo, dados de um intervalo de tempo menor) .

A grande vantagem aqui é que ERDDAP™ será capaz de lidar com solicitações de usuário para dados sem qualquer esforço adicional pelo seu banco de dados. Então... ERDDAP™ Não será um fardo na sua base de dados ou um risco de segurança. Esta é a melhor opção em quase todas as circunstâncias porque ERDDAP™ geralmente pode obter dados de arquivos mais rápido do que de um banco de dados (se convertermos os arquivos .csv para .nc Arquivos CF) . (Parte da razão é que ERDDAP +files é um sistema somente leitura e não precisa lidar com fazer mudanças ao fornecer ACIDENTE (Atômica, Consistência, Isolamento, Durabilidade) .) Além disso, você provavelmente não precisará de um servidor separado, pois podemos armazenar os dados em um de nossos RAIDs e acessá-lo com um existente ERDDAP™ em um servidor existente.

Ok Opção: Você configurou um novo banco de dados em um computador diferente com apenas a tabela desnormalizada. Uma vez que esse banco de dados pode ser um banco de dados de código livre e aberto como MariaDB, MySQL e PostgreSQL, esta opção não precisa custar muito.

A grande vantagem aqui é que ERDDAP™ será capaz de lidar com solicitações de usuário para dados sem qualquer esforço adicional pelo seu banco de dados atual. Então... ERDDAP™ Não será um fardo na sua base de dados actual. Isso também elimina muitas preocupações de segurança desde ERDDAP™ não terá acesso ao seu banco de dados atual.

Opção desactivada: Podemos ligar ERDDAP™ para o seu banco de dados atual. Para fazer isso, você precisa:
- Crie uma tabela separada ou vista com a tabela denormalizada de dados.
- Criar um usuário "erddap" que tenha acesso somente leitura a apenas a tabela denormalizada (S) .

Esta é uma opção se os dados mudam muito frequentemente e você quer dar ERDDAP™ usuários acesso instantâneo a essas mudanças; no entanto, mesmo assim, pode fazer sentido usar a opção de arquivo acima e periodicamente (a cada 30 minutos?) substituir o arquivo que tem os dados de hoje. As enormes desvantagens desta abordagem são que ERDDAP™ solicitações de usuários provavelmente colocarão um fardo insuportavelmente grande em seu banco de dados e que o ERDDAP™ conexão é um risco de segurança (embora possamos minimizar/gerir o risco) .

Fazendo a tabela denormalizada ou vista para ERDDAP™ é uma boa oportunidade para fazer algumas mudanças que ERDDAP™ necessidades, de uma forma que não afeta suas tabelas originais:

Mude a data e os campos/colunas do timestamp para usar os dadosTipo que os Correios chamam timestamp com fuso horário (ou o equivalente em seu banco de dados) . Os timestamps sem informações do fuso horário não funcionam corretamente em ERDDAP .
Faça índices para as colunas que os usuários frequentemente pesquisam.
Estar muito consciente de o caso dos nomes de campo/coluna (por exemplo, use todos os minúsculos) quando você digitá-los.
Não use palavras reservadas para a tabela e para os nomes de campo/coluna.

Se você precisar de ajuda para fazer a tabela ou visualização desnormalizada, entre em contato com o administrador do banco de dados. Se você quiser falar sobre toda essa abordagem ou estrategizar como melhor fazê-lo, por favor envie um e-mail para Chris. John em noaaa.gov .

banco de dados em datasets.xml

É difícil criar o correto datasets.xml informações necessárias para ERDDAP™ estabelecer uma conexão com a base de dados. Sê paciente. Seja metódico.

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

Gerar conjuntos de dados Xml tem três opções especiais para EDDTableFromDatabase:

Se você entrar "!!!LIST!!!" (sem as citações) para o nome do catálogo, o programa exibirá uma lista dos nomes do catálogo.
Se você entrar "!!!LIST!!!" (sem as citações) para o nome de esquema, o programa irá exibir uma lista dos nomes de esquema.
Se você entrar "!!!LIST!!!" (sem as citações) para o nome da tabela, o programa exibirá uma lista de tabelas e suas colunas. A primeira entrada "!!!LIST!!!" que você faz é a que será usada.

Leia cuidadosamente todas as informações deste documento sobre EDDTableFromDatabase.
Você pode coletar a maioria das informações que você precisa para criar o XML para um conjunto de dados EDDTableFromDatabase, contatando o administrador do banco de dados e pesquisando a web.
Embora os bancos de dados muitas vezes tratem nomes de colunas e nomes de tabela de uma forma insensível a casos, eles são sensíveis a casos em ERDDAP . Então, se uma mensagem de erro do banco de dados diz que um nome de coluna é desconhecido (por exemplo, "Unknown identificador= ' coluna\_nome ') mesmo sabendo que existe, tente usar todas as capitais, por exemplo, COLUMN , que é muitas vezes a versão verdadeira, sensível a caso do nome da coluna.
Trabalhe em estreita colaboração com o administrador do banco de dados, que pode ter experiência relevante. Se o conjunto de dados não carregar, leia o mensagem de erro cuidadosamente para descobrir o porquê.

Driver JDBC

[JDBC Driver e<driverName> (#jdbc-driver) - ... Você deve obter o arquivo JDBC 3 ou JDBC 4 apropriado para o seu banco de dados e Ponham-no. Toca a brincar. /webapps/erddap/WEB-INF/lib depois de instalar ERDDAP . Então, em seu datasets.xml para este conjunto de dados, você deve especificar o<driverName> para este driver, que é (Infelizmente,) diferente do nome do arquivo. Pesquisar na web para o driver JDBC para o seu banco de dados e o driverNome que Java precisa usá-lo.
- Para MariaDB, tente https://mariadb.com/kb/en/about-the-mariadb-java-client/
  O<driverNome> para usar em datasets.xml (ver abaixo) é provavelmente org.mariadb.jdbc. Driver.
- Para MySQL e Amazon RDS, tente https://dev.mysql.com/downloads/connector/j/
  O<driverNome> para usar em datasets.xml (ver abaixo) provavelmente é com.mysql.jdbc. Driver.
- Para Oracle Tenta https://www.oracle.com/database/technologies/appdev/jdbc-downloads.html . O<driverNome> para usar em datasets.xml (ver abaixo) é provavelmente oracle.jdbc.driver. Oracle Driver.
- Para Postgresql, temos o driver JDBC 4 de https://mvnrepository.com/artifact/org.postgresql/postgresql
  O<driverNome> para usar em datasets.xml (ver abaixo) é provavelmente org.postgresql. Driver.
- Para SQL Server, você pode obter o driver JTDS JDBC de https://jtds.sourceforge.net . O<driverNome> para usar em datasets.xml (ver abaixo) é provavelmente net.sourceforge.jtds.jdbc. Driver.

Depois de colocar o driver JDBC .jar em ERDDAP™ lib diretório, você precisa adicionar uma referência a esse arquivo .jar nos arquivos de script .bat e/ou .sh para GerarDatasets Xml, DasDds e ArchiveADataset que estão no Toca a brincar. /webapps/erddap/WEB-INF/ diretório; caso contrário, você receberá um ClassNotFoundException quando executar esses scripts.

Infelizmente, o JDBC Ã© por vezes a fonte de problemas. No seu papel de intermediário entre ERDDAP™ e o banco de dados, às vezes faz mudanças sutis no banco de dados padrão/genérico SQL solicitar que ERDDAP™ cria, causando problemas (por exemplo, relacionados com identificadores de maiúscula / minúscula e relacionados com data/hora fusos horários ) . Por favor, seja paciente, leia as informações aqui cuidadosamente, verifique o seu trabalho e veja nosso seção sobre como obter suporte adicional .

Banco de dados<conexão Propriedade >

Não.<conexãoProperty>] (#database-connectionproperty) - ... No datasets.xml para seu conjunto de dados, você deve definir várias conexões etiquetas de propriedade para contar ERDDAP™ como se conectar ao seu banco de dados (por exemplo, para especificar o nome de usuário, senha, conexão ssl e tamanho de busca ) . Estes são diferentes para cada situação e são um pouco difíceis de descobrir. Procure na web exemplos de usar um driver JDBC para se conectar ao seu banco de dados. O<conexãoProperty> nomes (por exemplo, "usuário", "password", e "sl") , e alguns dos valores de conexãoProperty podem ser encontrados procurando na web para "propriedades de conexão JDBC banco de dados Tipo " (por exemplo, Oracle , MySQL, Amazon RDS, MariaDB, PostgreSQL) .

Citações para Nomes e Sensibilidade de Caso

Citações para nomes de campo/cor; Sensibilidade de caso - Por padrão, EDDTableFromDatabase coloca aspas duplas padrão ANSI-SQL em torno de nomes de campo / coluna em declarações SELECT, caso você tenha usado uma palavra reservada como nome de campo / coluna, ou um caracter especial em um nome de campo / coluna. As citações duplas também frustram certos tipos de ataques de injeção SQL. Você pode dizer ERDDAP™ para usar ", ', ou nenhuma cotação via<colunaNomeQuotes> em datasets.xml para este conjunto de dados.

Para muitos bancos de dados, usar qualquer tipo de citações faz com que o banco de dados trabalhe com nomes de campo/coluna de uma forma sensível ao caso (em vez da forma insensível do caso de banco de dados padrão) . Os bancos de dados geralmente exibem nomes de arquivo/coluna como todos os casos superiores, quando na realidade a forma sensível do caso é diferente. Em ERDDAP™ , por favor, sempre trate nomes de colunas de banco de dados como caso sensível.

Pela Maria DB, você precisa executar o banco de dados com \--sql-mode=ANSI\_QUOTES .
Para MySQL e Amazon RDS, você precisa executar o banco de dados com \--sql-mode=ANSI\_QUOTES .
Oracle suporta aspas duplas padrão ANSI-SQL por padrão .
PostgreSQL suporta aspas duplas padrão ANSI-SQL por padrão.

Não use uma palavra reservada para um banco de dados, catálogo, esquema ou nome da tabela. ERDDAP™ não coloca citações à sua volta.

Se possível, use todos os casos inferiores para banco de dados, catálogo, esquema, nomes de tabelas e nomes de campo ao criar a tabela de banco de dados (ou vista) e quando se referem aos nomes de campo/coluna em datasets.xml em ERDDAP . Caso contrário, você pode obter uma mensagem de erro dizendo que o banco de dados, catálogo, esquema, tabela e / ou campo não foi encontrado. Se você receber essa mensagem de erro, tente usar a versão sensível ao caso, a versão em maiúscula e a versão em minúscula do nome ERDDAP . Um deles pode funcionar. Se não, você precisa alterar o nome do banco de dados, catálogo, esquema e / ou tabela para todos os minúsculos.

Banco de dados<dados Tipo >

Banco de dados Não.<dataType>] (# Datatype #) Etiquetas... Porque há alguma ambiguidade sobre a qual tipos de dados de banco de dados mapa a que ERDDAP™ tipos de dados, você precisa especificar um [<dataType>] (# Datatype #) tag para cada [< dataVariable > (#datavariable) para contar ERDDAP™ que dataType usar. Parte do problema é que diferentes conjuntos de dados usam termos diferentes para os vários tipos de dados -- então sempre tente combinar as definições, não apenas os nomes. Veja a descrição do padrão ERDDAP™ dados Tipos , que inclui referências aos tipos de dados SQL correspondentes. Data e timestamp são casos especiais: uso ERDDAP Dados duplos Tipo.

Data de início

Algumas colunas de data de banco de dados não têm fuso horário explícito. Tais colunas são problemas para ERDDAP . Bancos de dados suportam o conceito de uma data (com ou sem tempo) sem um fuso horário, como uma gama aproximada de tempo. Mas... Java (e assim ERDDAP ) só lida com data + hora instantânea com um fuso horário. Então você pode saber que os dados do horário de data são baseados em um fuso horário local (com ou sem horário de verão) ou o GMT/ Zulu fuso horário, mas Java (e ERDDAP ) Não. Nós originalmente pensamos que poderíamos trabalhar em torno deste problema (por exemplo, especificando um fuso horário para a coluna) , mas o banco de dados+JDBC+ Java interações fizeram desta uma solução não confiável.

Então... ERDDAP™ requer que você armazene todos os dados de data e data na tabela de banco de dados com um tipo de dados de banco de dados que corresponde ao tipo JDBC "timestamp com fuso horário" (idealmente, que usa o GMT/ Zulu fuso horário) .
Em ERDDAP ' datasets.xml , no< dataVariable > tag para uma variável timestamp, conjunto

<dataType>double</dataType>

e em< addAttributes Conjunto

          <att name="units">seconds since 1970-01-01T00:00:00Z</att>

Sugestão: Se os dados são um intervalo de tempo, é útil ter os valores do timestamp referem-se ao centro do intervalo de tempo implícito (por exemplo, noon) . Por exemplo, se um usuário tem dados para 2010-03-26T13:00Z de outro conjunto de dados e eles querem os dados mais próximos de um conjunto de dados de banco de dados que tem dados para cada dia, em seguida, os dados do banco de dados para 2010-03-26T12:00Z (representando dados para essa data) é obviamente o melhor (em oposição à meia-noite antes ou depois, onde é menos óbvio que é melhor) .
ERDDAP™ tem um utilitário para Converter um numérico Tempo para / de um tempo de corda .
Ver Como? ERDDAP Lidas com o tempo .

Nulls inteiros

Bancos de dados suportam nulls em inteiro (int, smallint, smallint) colunas, mas ERDDAP™ não suporta nulas verdadeiras. Nulls de banco de dados serão convertidos em ERDDAP™ 127 para colunas byte, 255 para colunas ubyte, 32767 para colunas curtas, 65535 para colunas ushort, 2147483647 para colunas int, 4294967295 para colunas uint, 9,223,372,036,854,775,807 para colunas longas, ou 18446744073709551615 para colunas ulongas. Se você usar esses padrões, identifique os missing\_value s para os usuários do conjunto de dados em ERDDAP™ com

<att name="\_FillValue" type="int"\>2147483647</att>

<att name="\_FillValue" type="short"\>32767</att>

Alternativamente, você pode usar o " missing\_value « atributo em vez de "\_FillValue". Gerar conjuntos de dados Xml adiciona automaticamente esses atributos \_FillValue quando gera o sugerido datasets.xml para conjuntos de dados de banco de dados.

Para colunas de ponto flutuante de banco de dados, nulls são convertidos para NaNs em ERDDAP . Para tipos de dados de banco de dados que são convertidos para strings em ERDDAP™ , nulls se convertem em Strings vazios.

Segurança da base de dados

Ao trabalhar com bancos de dados, você precisa fazer as coisas com segurança e segurança para evitar permitir que um usuário malicioso danifique seu banco de dados ou obtenha acesso aos dados que não devem ter acesso. ERDDAP™ tenta fazer as coisas de uma forma segura, também.
- Considere replicar, em um computador diferente, as tabelas de banco de dados e banco de dados com os dados que você deseja ERDDAP™ servir. (Sim, para bancos de dados comerciais como Oracle , isso envolve taxas de licenciamento adicionais. Mas para bases de dados de código aberto, como PostgreSQL, MySQL, Amazon RDS e MariaDB, isso não custa nada.) Isso lhe dá um alto nível de segurança e também impede ERDDAP™ solicitações de desacelerar o banco de dados original.
- Nós encorajamos você a configurar ERDDAP™ para se conectar ao banco de dados como um usuário de banco de dados que só tem acesso ao relevante banco de dados (S) e só tem privilégios LER.
- Nós encorajamos você a configurar a conexão de ERDDAP™ ao banco de dados para que
  - sempre usa SSL,
  - somente permite conexões de um endereço IP (ou um bloco de endereços) e de um ERDDAP™ usuário e
  - apenas transfere senhas em seu formulário de hasshed MD5.
- \[ PROBLEMAS CONHECIDOS \] A conexãopropriedades (incluindo a senha!) são armazenados como texto simples em datasets.xml . Não encontramos uma maneira de permitir ao administrador inserir a senha do banco de dados durante ERDDAP 's startup in Tomcat (que ocorre sem entrada do usuário) , então a senha deve ser acessível em um arquivo. Para tornar isso mais seguro:
- Tu. (o ERDDAP™ administrador) deve ser o proprietário de datasets.xml e têm acesso READ e WRITE.
- Faça um grupo que inclua apenas user=tomcat. Use chgrp para fazer que o grupo para datasets.xml , com apenas privilégios LER.
- Use chmod para atribuir privilégios o-rwx (não LER ou WRITE acesso para "outros" usuários) para datasets.xml .
- Quando entrar ERDDAP™ , a senha e outras propriedades de conexão são armazenadas em "privado" Java variáveis.
- Os pedidos de clientes são analisados e verificados para validade antes de gerar os pedidos SQL para o banco de dados.
- As solicitações ao banco de dados são feitas com SQL PreparedStatements, para evitar Injeção de SQL .
- As solicitações ao banco de dados são enviadas com execução Query (não executarEstado) para limitar pedidos para ser somente leitura (assim tentou injeção SQL para alterar o banco de dados vai falhar por esta razão, também) .

SQL

Porque... OPeNDAP Os pedidos de dados tabulares foram projetados para imitar solicitações de dados tabulares SQL, é fácil para ERDDAP™ para converter solicitações de dados tabulares em simples SQL PreparedStatements. Por exemplo, o ERDDAP™ pedido

    time,temperature&time>=2008-01-01T00:00:00Z&time&lt;=2008-02-01T00:00:00Z

será convertido em SQL PreparedStatement

    SELECT "time", "temperature" FROM *tableName*  
    WHERE "time" >= 2008-01-01T00:00:00Z AND "time" &lt;= 2008-02-01T00:00:00Z  

ERDDAP™ pedidos com &distinct () e/ou orderBy ( variáveis variáveis ) irá adicionar DISTINCT e/ou ORDER BY variáveis variáveis para a instrução SQL preparada. Em geral, isso irá retardar muito a resposta do banco de dados. ERDDAP™ logs the PreparedStatement in - Não. como

    statement=*thePreparedStatement*

Esta será uma representação de texto do PreparadStatement, que pode ser ligeiramente diferente do PreparadStatement real. Por exemplo, no PreparedStatement, os tempos são codificados de uma maneira especial. Mas na representação de texto, eles aparecem como ISO 8601 data times.

Velocidade do banco de dados

Os bancos de dados podem ser lentos. Há algumas coisas que você pode fazer:
- Em geral - A natureza do SQL é que as consultas são declarativa . Eles apenas especificam o que o usuário quer. Eles não incluem uma especificação ou dicas para como a consulta deve ser tratada ou otimizada. Então não há maneira de ERDDAP™ para gerar a consulta de tal forma que ajuda o banco de dados a otimizar a consulta (ou de qualquer forma especifica como a consulta deve ser tratada) . Em geral, cabe ao administrador do banco de dados configurar as coisas (por exemplo, índices) para otimizar para certos tipos de consultas.

Defina o tamanho da Fetch

Bancos de dados retornam os dados para ERDDAP™ em pedaços. Por padrão, bancos de dados diferentes retornam um número diferente de linhas nos pedaços. Muitas vezes este número é muito pequeno e muito ineficiente. Por exemplo, o padrão para Oracle São 10! Leia a documentação do JDBC para o driver do JDBC do seu banco de dados para encontrar a propriedade de conexão definida para aumentar isso, e adicione isso à descrição do conjunto de dados no datasets.xml . Por exemplo, Para MySQL e Amazon RDS, use

        <connectionProperty name="defaultFetchSize">10000</connectionProperty>

Para MariaDB, atualmente não há como mudar o tamanho da busca. Mas é um recurso solicitado, então procure a web para ver se isso foi implementado. Para Oracle , uso

        <connectionProperty name="defaultRowPrefetch">10000</connectionProperty>

Para PostgreSQL, use

        <connectionProperty name="defaultRowFetchSize">10000</connectionProperty>

mas sinta-se livre para mudar o número. Definir o número muito grande causará ERDDAP™ usar muita memória e ser mais propenso a ficar sem memória.

Properidades de conexão

Cada banco de dados tem outras propriedades de conexão que podem ser especificadas em datasets.xml . Muitos deles afetarão o desempenho do banco de dados para ERDDAP™ ligação. Por favor, leia a documentação para o driver JDBC do seu banco de dados para ver as opções. Se você encontrar propriedades de conexão que são úteis, envie um e-mail com os detalhes para erd dot data at noaa dot gov .

Faça uma mesa... Você provavelmente terá respostas mais rápidas se você periodicamente (Todos os dias? sempre que houver novos dados?) gerar uma tabela real (da mesma forma como você gerou o VIEW) e contar ERDDAP™ para obter dados da tabela em vez da VIEW. Uma vez que qualquer pedido à tabela pode então ser cumprido sem JOINing outra tabela, a resposta será muito mais rápida.
Vácuo da tabela - MySQL e Amazon RDS responderão muito mais rápido se você usar QUADRO OPTIMIZE . Maria Maria Maria DB responderá muito mais rápido se você usar QUADRO OPTIMIZE . PostgreSQL vai responder muito mais rápido se você VACUÍDIO a mesa. Oracle não tem ou precisa de um comando analógico.
Fazer Índices para Variáveis Comunicamente Restritas -- Você pode acelerar muitas / mais consultas criando índices no banco de dados para as variáveis (que bases de dados chamam "colunas") que são frequentemente limitados na consulta do usuário. Em geral, estas são as mesmas variáveis especificadas por [< subsetVariables > (#subsetvariables) e/ou as variáveis de latitude, longitude e tempo.

Use a associação de conexão

Normalmente, ERDDAP™ faz uma conexão separada ao banco de dados para cada solicitação. Esta é a abordagem mais confiável. A alternativa mais rápida é usar um DataSource que suporta o pool de conexões. Para configurá-lo, especifique (por exemplo)

        <dataSourceName>java:comp/env/jdbc/postgres/erddap</dataSourceName>

ao lado< sourceUrl ><driverName>, e<conexão Propriedade>. E em Toca a brincar. /conf/context.xml, definir um recurso com a mesma informação, por exemplo,

        <Resource  
        name="jdbc/postgres/erddap" auth="Container" type="javax.sql.DataSource"  
        driverClassName="org.postgresql.Driver"  
        url="*jdbc:postgresql://somehost:5432/myDatabaseName*"  
        username="*myUsername*" password="*myPassword*"  
        initialSize="0" maxActive="8" minIdle="0" maxIdle="0" maxWait="-1"/>  

InformaÃ§Ãμes gerais sobre o uso de um DataSource https://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html . Ver Tomcat DataSource informações e Exemplos de Tomcat DataSource ou pesquisar a web para exemplos de usar o DataSources com outros servidores de aplicativos.

Se tudo o resto falhar, considerar armazenar os dados em uma coleção de NetCDF v3 .nc arquivos (especialmente .nc arquivos que usam CF Geometrias de amostragem discretas (DSG) Estruturas de dados Ragged Array contíguas e assim pode ser tratada com ERDDAP ' EDDTable FromNcCFFiles ) . Se eles são logicamente organizados (cada um com dados para um pedaço de espaço e tempo) , ERDDAP™ pode extrair dados deles muito rapidamente.

EDDTableDo esqueleto da base de dados XML

<dataset type="EDDTableFromDatabase" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
        
      <driverName\>...</driverName>
        
      <connectionProperty name="name">value</connectionProperty>
        
      <dataSourceName>...</dataSourceName> 
      <catalogName>...</catalogName>
        
      <schemaName>...</schemaName> 
      <tableName>...</tableName> 
      <columnNameQuotes><columnNameQuotes> 
      <orderBy>...</orderBy> 
      <sourceCanOrderBy>no(default)|partial|yes</sourceCanOrderBy>
        
      <sourceCanDoDistinct>no(default)|partial|yes</sourceCanDoDistinct>
        
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <addAttributes>...</addAttributes> 
      <dataVariable>...</dataVariable> 
  </dataset>

Tabela de EDD EDDGrid

**Tabela de EDD EDDGrid ** permite criar um conjunto de dados EDDTable a partir de qualquer EDDGrid conjunto de dados.

Algumas razões comuns para fazer isso são:
- Isso permite que o conjunto de dados seja consultado com OPeNDAP restrições de seleção, que é um tipo de "coração por valor" (que um usuário pode ter solicitado) .
- O conjunto de dados é inerentemente um conjunto de dados tabular.
O valor do atributo global "maxAxis0" (geralmente de tipo="int") , (o padrão é 10) será usado para limitar o número de eixos \[ 0 \] (geralmente o "time" eixo) valores do anexo EDDGrid dataset que pode ser acessado por solicitação de dados. Se você não quiser que haja qualquer limite, especifique um valor de 0. Esta configuração é importante porque, caso contrário, seria muito fácil para um usuário pedir EDDTableFrom EDDGrid para analisar todos os dados do conjunto de dados. Isso levaria muito tempo e quase certamente falharia com um erro de timeout. Este é o cenário que o torna seguro ter EDDTableFrom EDDGrid conjuntos de dados em seu ERDDAP sem medo de que eles levarão a um uso irracional de recursos de computação.
Se o anexo EDDGrid é um EDDGrid De Erddap e o ERDDAP™ é o mesmo ERDDAP , então EDDTable De EDDGrid usará sempre a versão atualmente disponível do conjunto de dados referenciado diretamente. Esta é uma maneira muito eficiente para EDDTableDe EDDGrid para acessar os dados gradeados.
Esta classe é...<recarregar Cada NMinutes> (#reloadeverynminutes) é o que conta. O anexo EDDGrid '<reloadEveryNMinutes> é ignorado.
Se um valor para [<updateEveryNMillis>] (#updateeverynmillis #) é fornecido para este conjunto de dados, é ignorado. O anexo EDDGrid '<updateEveryNMillis> é o que importa.
Gerar conjuntos de dadosXml tem uma opção para dataset type=EDDTableFrom EDDGrid que pede a URL de um ERDDAP (geralmente o mesmo ERDDAP ) (terminando em "/erddap/") e uma expressão regular. Gerar conjuntos de dados Xml irá então gerar o XML para uma tabela EDDFrom EDDGrid conjunto de dados para cada conjunto de dados gradeado no ERDDAP™ que tem datasetID que corresponde à expressão regular (use .\* para combinar tudo datasetID s para conjuntos de dados gradeados) .

O pedaço de XML que é gerado pela GenerateDatasetsXml para cada conjunto de dados inclui:

A datasetID que é o EDDGrid ' datasetID mais "\_AsATable".
Um novo atributo global de resumo que é o EDDGrid 's sumário mais um novo primeiro parágrafo descrevendo o que este conjunto de dados é.
Um novo atributo global de título que é o EDDGrid O título mais ", (Como uma tabela) ".
Um novo atributo global maxAxis0 com um valor de 10.

Tabela de EDD EDDGrid esqueleto XML

<dataset type="EDDTableFromEDDGrid" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <addAttributes>...</addAttributes> 
      <dataset>...</dataset> 
    </dataset>

EDDTable De Nomes de Arquivo

EDDTable De Nomes de Arquivo cria um conjunto de dados de informações sobre um grupo de arquivos no sistema de arquivos do servidor, incluindo uma URL para cada arquivo para que os usuários possam baixar os arquivos via ERDDAP ' "files" sistema . Ao contrário de todos os Tabela EDD dos arquivos subclasses, este tipo de conjunto de dados não serve dados de dentro dos arquivos.

EDDTableFromFileNames é útil quando:
- Você tem um grupo de arquivos que você deseja distribuir como arquivos inteiros porque eles não contêm "dados" da mesma forma que os arquivos de dados regulares têm dados. Por exemplo, arquivos de imagem, arquivos de vídeo, documentos do Word, arquivos de planilha do Excel, arquivos de apresentação do PowerPoint, ou arquivos de texto com texto não estruturado.
- Você tem um grupo de arquivos que têm dados em um formato que ERDDAP™ Ainda não consigo ler. Por exemplo, um formato binário específico de projeto, personalizado.

EDDTable FromFileNames Data

Os dados em um conjunto de dados EDDTableFromFileNames é uma mesa que ERDDAP™ cria on-the-fly com informações sobre um grupo de arquivos locais. Na tabela, há uma linha para cada arquivo. Quatro atributos especiais no datasets.xml para este conjunto de dados determinar quais arquivos serão incluídos neste conjunto de dados:

arquivo Dir.

<fileDir> -- Isso especifica o diretório de origem no sistema de arquivos do servidor com os arquivos para este conjunto de dados. Os arquivos que estão localizados no sistema de arquivos do servidor no<fileDir> aparecerá na coluna url deste conjunto de dados dentro de um diretório virtual chamadohttps://serverUrl/erddap/files/datasetID/. Por exemplo, se o datasetID O que é? RSS T, e o<fileDir> é /home/data/mur/ , e esse diretório tem um arquivo chamado jplMU RSS T20150103000000.png, então a URL que será mostrada aos usuários para esse arquivo será https://serverUrl/erddap/jplMURSST/jplMURSST20150103000000.png.

Além de usar um diretório local para o<fileDir>, você também pode especificar a URL de uma página web remota, como diretório. Isso funciona com:

Conjuntos de dados não agregados em THREDDS, por exemplo, https://data.nodc.noaa.gov/thredds/catalog/aquarius/nodc\\_binned\\_V3.0/monthly/ \[ 2020-10-21 Este servidor não está mais disponível de forma confiável. \]
Conjuntos de dados não agregados Hyrax , por exemplo, https://podaac-opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/
A maioria das listas de diretórios como Apache, por exemplo, https://www1.ncdc.noaa.gov/pub/data/cmb/ersst/v5/netcdf/

a partir de

\\\* a partir de - ... Para alguns baldes S3 enormes (como noaa-goes17, que tem 26 milhões de arquivos) , pode levar ERDDAP™ até 12 horas para baixar todas as informações sobre o conteúdo do balde (e depois há outros problemas) . Para se locomover, há uma maneira especial de usar<fileDir> em EDDTableFromFileNames para fazer um conjunto de dados com o diretório e nomes de arquivos de um balde AWS S3. O conjunto de dados não terá a lista de todos os diretórios do balde S3 e nomes de arquivos que um usuário pode pesquisar através de solicitações para o conjunto de dados. Mas o conjunto de dados terá os nomes de diretórios e arquivos on-the-fly se o usuário atravessar a hierarquia de diretórios com o conjunto de dados "files" opção. Assim, isso permite aos usuários navegar na hierarquia de arquivos e arquivos do balde S3 através do conjunto de dados "files" sistema. Para fazer isso, em vez de especificar a URL do balde S3 como o "Iniciar diretório" (em Gerar conjuntos de dados Xml) ou<fileDir> (em datasets.xml ) , use:

\\*\\*\\*fromOnTheFly,*theS3BucketUrl*

por exemplo:

\\*\\*\\*fromOnTheFly,https://noaa-goes17.s3.us-east-1.amazonaws.com/

Veja a documentação para trabalhando com S3 Buckets em ERDDAP™ , nomeadamente a descrição do formato específico que deve ser usado para a URL do balde S3. E ver estes detalhes e um exemplo de usar\\\*deOnTheFly.

recursivo

<recursivo> -- Arquivos em subdiretórios de<fileDir> com nomes que correspondem<fileRegex> aparecerá nos mesmos subdiretórios nos "files" URL se<recursivo> é definido como verdadeiro. O padrão é falso.
Não.<Caminhos-de-ferro (#) - ... Se recursive=true, Apenas nomes de diretório que correspondem ao pathRegex (default=.\*") será aceito. Se recursive=false, isso é ignorado. Isso raramente é usado, mas pode ser muito útil em circunstâncias incomuns. (Veja isto documentação e tutorial do regex .)

ficheiroRegex

<fileRegex> -- Apenas os nomes de arquivo onde todo o nome do arquivo (não incluindo o nome do diretório) corresponder a<fileRegex> será incluído neste conjunto de dados. Por exemplo, jplMU RSS T.{14}\.png . (Veja isto documentação e tutorial do regex .)

De Nomes de arquivo Conteúdo da tabela de dados

Na tabela, haverá colunas com:

Url... A URL que os usuários podem usar para baixar o arquivo via ERDDAP ' "files" sistema .
Nome... O nome do arquivo (sem um nome de diretório) .
último Modificado... O tempo que o arquivo foi modificado pela última vez (armazenados como duplos com "seconds since 1970-01-01T00:00:00Z" ) . Esta variável é útil porque os usuários podem ver se/quando o conteúdo de um determinado arquivo foi alterado. Esta variável é uma Tempo Variável do carimbo , para que os dados possam aparecer como valores numéricos (segundos desde 1970-01-01T00:00:00Z) ou um valor de string (ISO 8601:2004 (E) formato) , dependendo da situação.
tamanho... O tamanho do arquivo em bytes, armazenado como duplos. Eles são armazenados como duplos, porque alguns arquivos podem ser maiores do que ints permitir e longs não são suportados em alguns tipos de arquivo de resposta. O dobro dará o tamanho exato, mesmo para arquivos muito grandes.
colunas de adição definidas pelo ERDDAP™ administrador com informações extraídas do nome do arquivo (por exemplo, o tempo associado aos dados no arquivo) com base em dois atributos que você especifica nos metadados para cada coluna/ dataVariable :
- ExtratoRegex -- Isto é... expressão regular ( tutorial ) . Todo o regex deve corresponder a todo o nome do arquivo (não incluindo o nome do diretório) . O regex deve incluir pelo menos um grupo de captura (uma seção de uma expressão regular que é fechada por parênteses) que ERDDAP™ usa para determinar qual seção do nome do arquivo para extrair para se tornar dados.
- extrato Grupo... Este é o número do grupo de captura (#1 é o primeiro grupo de captura) na expressão regular. O padrão é 1. Um grupo de captura é uma seção de uma expressão regular que é fechada por parênteses.

Aqui estão dois exemplos:

            <dataVariable>
                <sourceName>time</sourceName>
                <destinationName>time</destinationName>
                <dataType>String</dataType>
                <addAttributes>
                    <att name="extractRegex">jplMURSST(.{14})\\.png</att>
                    <att name="extractGroup" type="int">1</att>
                    <att name="units">yyyyMMddHHmmss</att>
                </addAttributes>
            </dataVariable>

            <dataVariable>
                <sourceName>day</sourceName>
                <destinationName>day</destinationName>
                <dataType>int</dataType>
                <addAttributes>
                    <att name="extractRegex">jplMURSST.{6}(..).{6}\\.png</att>
                    <att name="extractGroup" type="int">1</att>
                    <att name="ioos\\_category">Time</att>
                </addAttributes>
            </dataVariable> 

No caso da variável tempo, se um arquivo tiver o nome jplMU RSS T20150103000000.png, o extratoRegex irá combinar o nome do arquivo, extrair os caracteres que correspondem ao primeiro grupo de captura ("20150103000000000") como dataType=String, então use o unidades adequadas para tempos de cadeia para analisar as cadeias de caracteres em valores de dados de tempo (2015-01-03T00:00:00) .

No caso da variável dia, se um arquivo tiver o nome jplMU RSS T20150103000000.png, o extratoRegex irá combinar o nome do arquivo, extrair os caracteres que correspondem ao primeiro grupo de captura ("03") como...<dataType>] (# Datatype #) \=int, produzindo um valor de dados de 3.

Outras informações

Não!<updateEveryNMillis>] (#updateeverynmillis #) - ... Este tipo de conjunto de dados não precisa e não pode usar o<updateEveryNMillis> tag porque as informações servidas pela EDDTableFromFileNames estão sempre perfeitamente atualizadas porque ERDDAP™ consulta o sistema de arquivos para responder a cada solicitação de dados. Mesmo que haja um grande número de arquivos, esta abordagem deve funcionar razoavelmente bem. Uma resposta pode ser lenta se houver um grande número de arquivos e o conjunto de dados não foi consultado por um tempo. Mas por vários minutos depois disso, o sistema operacional mantém as informações em um cache, então as respostas devem ser muito rápidas.
Você pode usar o Gerar conjuntos de dados Programa Xml para fazer o datasets.xml chunk para este tipo de conjunto de dados. Você pode adicionar / definir colunas adicionais com informações extraídas do nome do arquivo, como mostrado acima.

EDDTable Do esqueleto dos nomes de arquivo XML

<dataset type="EDDTableFromFileNames" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <fileDir>...</fileDir>
      <recursive>...</recursive> 
      <pathRegex>...</pathRegex> 
      <fileNameRegex>...</fileNameRegex>
      <addAttributes>...</addAttributes> 
      <dataVariable>...</dataVariable> 
  </dataset>

Tabela EDD dos arquivos

Tabela EDD dos arquivos é a superclasse de todas as classes EDDTableDe...Files. Você não pode usar EDDTableFromFiles diretamente. Em vez disso, use uma subclasse de EDDTableFromFiles para lidar com o tipo de arquivo específico:

EDDTable FromAsciiFiles agrega dados de vírgula, tab-, ponto-, ou arquivos de dados tabulares ASCII separados por espaço.
EDDTable FromAudioFiles agrega dados de um grupo de arquivos de áudio locais.
Tabela de EDD TolsXmlFiles agrega dados de um conjunto de Estação de Tempo Automático (AWS) Arquivos XML.
EDDTable FromColumnarAsciiFiles agrega dados de arquivos de dados ASCII tabular com colunas de dados de largura fixa.
Tabela de EDD Hyrax Arquivos (DEPRIEDADE) agrega dados com várias variáveis, cada uma com dimensões compartilhadas (por exemplo, tempo, altitude (ou profundidade) , latitude, longitude) e servido por um Hyrax OPeNDAP servidor .
EDDTable De InvalidCRAFiles agrega dados de NetCDF (v3 ou v4) .nc arquivos que usam um específico, inválido, variante do CF DSG Contiguous Ragged Array (CRA) arquivos. Embora ERDDAP™ suporta este tipo de arquivo, é um tipo de arquivo inválido que ninguém deve começar a usar. Grupos que atualmente usam este tipo de arquivo são fortemente encorajados a usar ERDDAP™ para gerar arquivos CF DSG CRA válidos e parar de usar esses arquivos.
EDDTable FromJsonlCSVFiles agrega dados de JSON Linhas arquivos CSV .
EDDTable FromMultidimNcFiles agrega dados de NetCDF (v3 ou v4) .nc (ou .nc ml ) arquivos com várias variáveis, cada uma com dimensões compartilhadas (por exemplo, tempo, altitude (ou profundidade) , latitude, longitude) .
EDDTable De NcFiles agrega dados de NetCDF (v3 ou v4) .nc (ou .nc ml ) arquivos com várias variáveis, cada uma com dimensões compartilhadas (por exemplo, tempo, altitude (ou profundidade) , latitude, longitude) . É bom continuar usando este tipo de conjunto de dados para conjuntos de dados existentes, mas para novos conjuntos de dados recomendamos usar EDDTableFromMultidimNcFiles em vez disso.
EDDTable FromNcCFFiles agrega dados de NetCDF (v3 ou v4) .nc (ou .nc ml ) arquivos que usam um dos formatos de arquivo especificados pelo CF Geometrias de amostragem discretas (DSG) convenções. Mas para arquivos usando uma das variantes multidimensionais CF DSG, use EDDTable FromMultidimNcFiles Em vez disso.
EDDTable De NccsvFiles agrega dados de NCCSV Arquivos ASCII .csv.
EDDTable FromParquetFiles lida com dados de Parquete .
EDDTable FromThreddsFiles (DEPRIEDADE) agrega dados de arquivos com várias variáveis com dimensões compartilhadas servidas por uma TERCEIROS OPeNDAP servidor .
Tabela de EDD WFS Arquivos (DEPRIEDADE) faz uma cópia local de todos os dados de uma ArcGIS MapaServer WFS servidor para que os dados possam então ser re-servados rapidamente para ERDDAP™ usuários.

Atualmente, nenhum outro tipo de arquivo é suportado. Mas geralmente é relativamente fácil adicionar suporte para outros tipos de arquivo. Contacte-nos se tiver um pedido. Ou, se seus dados estão em um formato de arquivo antigo que você gostaria de se afastar, recomendamos converter os arquivos para ser NetCDF v3 .nc arquivos (e especialmente .nc arquivos com o CF Geometrias de amostragem discretas (DSG) Estrutura contígua de dados Ragged Array -- ERDDAP™ pode extrair dados deles muito rapidamente) . NetCDF é um formato binário amplamente suportado, permite acesso aleatório rápido aos dados, e já é suportado por ERDDAP .

Detalhes deFiles

As seguintes informações aplicam-se a todas as subclasses de EDDTableFromFiles.

Agregação

Esta classe agrega dados de arquivos locais. Cada arquivo contém (relativamente) pequena tabela de dados.

O conjunto de dados resultante aparece como se todas as tabelas do arquivo tivessem sido combinadas (todas as linhas de dados do arquivo #1, mais todas as linhas do arquivo #2, ...) .
Os arquivos nem todos têm que ter todas as variáveis especificadas. Se um determinado arquivo não tiver uma variável especificada, ERDDAP™ adicionará valores ausentes conforme necessário.
As variáveis em todos os arquivos DEVE ter os mesmos valores para add\_offset , missing\_value , \_Fill Valor , scale\_factor e unidades atributos (se houver) . ERDDAP™ verifica, mas é um teste imperfeito -- se houver valores diferentes, ERDDAP não sabe qual é correto e, portanto, quais arquivos são inválidos. Se este é um problema, você pode ser capaz de usar NcML ou NCO para corrigir o problema.

Arquivos compactados

Os arquivos de dados de origem para todas as subclasses EDDTableFromFiles podem ser compactados externamente (por exemplo, .tgz , .tar .gz , .tar .gzip , .gz , .gzip , .zip , .bz2 , ou .Z) . Ver Documentação de arquivos compactados externamente .

InformaÃ§Ãμes de arquivo Cached

Quando um conjunto de dados EDDTableFromFiles é carregado pela primeira vez, EDDTableFromFiles lê informações de todos os arquivos relevantes e cria tabelas (uma linha para cada arquivo) com informações sobre cada arquivo válido e cada "mau" (diferente ou inválido) ficheiro.
- As tabelas também são armazenadas no disco, como NetCDF v3 .nc arquivos em Diretriz de grande porte /dataset/ último2CharsOfDatasetID / * datasetID * / em arquivos nomeados: tabela de dados .nc (que contém uma lista de nomes de diretório únicos) , arquivo Quadro .nc (que contém a tabela com as informações de cada arquivo válido) , Arquivos ruins .nc (que segura a tabela com as informações de cada arquivo ruim) .
- Para acelerar o acesso a um conjunto de dados EDDTableFromFiles (mas à custa de usar mais memória) , você pode usar Não.<arquivoTableInMemory>true</fileTableInMemory> (#filetableinmemory)
  para contar ERDDAP™ para manter uma cópia das tabelas de informações do arquivo na memória.
- A cópia das tabelas de informações do arquivo no disco também é útil quando ERDDAP™ é desligado e reiniciado: economiza tabela EDD FromFiles de ter que reler todos os arquivos de dados.
- Quando um conjunto de dados é recarregado, ERDDAP™ só precisa ler os dados em novos arquivos e arquivos que mudaram.
- Se um arquivo tem uma estrutura diferente dos outros arquivos (por exemplo, um tipo de dados diferente para uma das variáveis, ou um valor diferente para o " unidades "Atributo) , ERDDAP adiciona o arquivo à lista de arquivos "bad". InformaÃ§Ãμes sobre o problema com o arquivo serÃ¡ escrito para o Diretriz de grande porte /logs/log.txt arquivo.
- Você nunca deve precisar excluir ou trabalhar com esses arquivos. Uma exceção é: se você ainda está fazendo alterações em um conjunto de dados datasets.xml configuração, você pode querer excluir esses arquivos para forçar ERDDAP™ para reler todos os arquivos desde que os arquivos serão lidos / interpretados de forma diferente. Se você precisar excluir esses arquivos, você pode fazê-lo quando ERDDAP™ está a correr. (Em seguida, definir um bandeira para recarregar o conjunto de dados ASAP.) No entanto, ERDDAP™ geralmente percebe que o datasets.xml informações não correspondem ao arquivo InformaÃ§Ãμes da tabela e exclui as tabelas de arquivos automaticamente.
- Se você quiser encorajar ERDDAP™ para atualizar as informações do conjunto de dados armazenados (por exemplo, se você acabou de adicionar, remover ou alterar alguns arquivos no diretório de dados do conjunto de dados) , use o sistema de bandeira à força ERDDAP™ para atualizar as informações de arquivo em cache.

Pedidos de manuseio

ERDDAP™ solicitações de dados tabular podem colocar restrições em qualquer variável.
Quando o pedido de dados de um cliente for processado, o EDDTableFromFiles pode olhar rapidamente na tabela com as informações de arquivo válidas para ver quais arquivos podem ter dados relevantes. Por exemplo, se cada arquivo de origem tiver os dados para um buoy de localização fixa, o EDDTableFromFiles pode determinar de forma muito eficiente quais arquivos podem ter dados dentro de um determinado intervalo de longitude e intervalo de latitude.
Como a tabela de informações de arquivo válida inclui o valor mínimo e máximo de cada variável para cada arquivo válido, EDDTableFromFiles muitas vezes pode lidar com outras consultas de forma bastante eficiente. Por exemplo, se alguns dos buoys não têm um sensor de pressão de ar, e um cliente solicita dados para airPressure!=NaN, EDDTableFromFiles pode determinar eficientemente quais buoys têm dados de pressão de ar.

Atualizando as informações do arquivo Cached

Sempre que o conjunto de dados é recarregado, as informações de arquivo em cache são atualizadas.

O conjunto de dados é recarregado periodicamente conforme determinado pelo<reloadEveryNMinutes> nas informações do conjunto de dados datasets.xml .
O conjunto de dados é recarregado o mais rápido possível sempre ERDDAP™ detecta que você adicionou, removido, Tocava (para alterar o último arquivo Tempo modificado) , ou mudou um arquivo de dados.
O conjunto de dados é recarregado o mais rápido possível se você usar o sistema de bandeira .

Quando o conjunto de dados é recarregado, ERDDAP™ compara os arquivos disponíveis atualmente à tabela de informações de arquivo em cache. Novos arquivos são lidos e adicionados à tabela de arquivos válidos. Os arquivos que já não existem são retirados da tabela de arquivos válidos. Os arquivos onde o timestamp do arquivo mudou são lidos e suas informações são atualizadas. As novas tabelas substituem as mesas antigas na memória e no disco.

Arquivos ruins

A tabela de arquivos ruins e as razões que os arquivos foram declarados ruins (arquivo corrompido, variáveis ausentes, valores de eixo incorretos, etc.) é enviado para o e-mail Tudo Para endereço de e-mail (Provavelmente.) sempre que o conjunto de dados é recarregado. Você deve substituir ou reparar esses arquivos o mais rápido possível.

Variáveis em falta

Se alguns dos arquivos não têm alguns dos dataVariable s definido no conjunto de dados datasets.xml Chuck, não faz mal. Quando EDDTableFromFiles lê um desses arquivos, ele atuará como se o arquivo tivesse a variável, mas com todos os valores ausentes.

Dados em tempo real

EDDTableFromFiles trata pedidos de dados muito recentes como um caso especial. O problema: Se os arquivos que compõem o conjunto de dados forem atualizados com frequência, é provável que o conjunto de dados não seja atualizado sempre que um arquivo for alterado. Então EDDTableFromFiles não estará ciente dos arquivos alterados. (Você poderia usar o sistema de bandeira Mas isto pode levar a ERDDAP™ recarregar o conjunto de dados quase continuamente. Então, na maioria dos casos, não recomendamos.) Em vez disso, EDDTableFromFiles lida com isso pelo seguinte sistema: Quando ERDDAP™ recebe um pedido de dados nas últimas 20 horas (por exemplo, há 8 horas até Agora) , ERDDAP™ irá pesquisar todos os arquivos que têm quaisquer dados nas últimas 20 horas. Assim, ERDDAP™ não precisa ter dados perfeitamente atualizados para todos os arquivos, a fim de encontrar os dados mais recentes. Você ainda deve definir [<recarregar Cada NMinutes> (#reloadeverynminutes) a um valor razoavelmente pequeno (por exemplo, 60) Mas não tem de ser minúsculo (por exemplo, 3) .
- Não recomendado organização de dados quase em tempo real nos arquivos: Se, por exemplo, você tem um conjunto de dados que armazena dados para várias estações (ou bóia, ou trajetória, ...) por muitos anos, você pode organizar os arquivos para que, por exemplo, há um arquivo por estação. Mas então, cada vez que novos dados para uma estação chega, você tem que ler um arquivo velho grande e escrever um arquivo novo grande. E quando ERDDAP™ recarrega o conjunto de dados, percebe que alguns arquivos foram modificados, então ele lê esses arquivos completamente. Isso é ineficiente.
- Recomendado organização de dados quase em tempo real nos arquivos: Armazene os dados em pedaços, por exemplo, todos os dados para uma estação/compra/trajectória por um ano (ou um mês) . Então, quando um novo dado chega, apenas o arquivo com este ano. (ou mês) os dados são afetados.
- Melhor: Uso NetCDF v3 .nc arquivos com uma dimensão ilimitada (Tempo) . Então, para adicionar novos dados, você pode apenas anexar os novos dados sem ter que ler e reescrever todo o arquivo. A mudança é feita de forma muito eficiente e essencialmente atomicamente, então o arquivo nunca está em um estado inconsistente.
- Caso contrário: Se você não / não pode usar .nc arquivos com uma dimensão ilimitada (Tempo) , então, quando você precisa adicionar novos dados, você tem que ler e reescrever todo o arquivo afetado (esperançosamente pequeno porque tem apenas um ano de (ou mês) valor de dados) . Felizmente, todos os arquivos para anos anteriores (ou meses) para que a estação permaneça inalterada.

Em ambos os casos, quando ERDDAP™ recarrega o conjunto de dados, a maioria dos arquivos são inalterados; apenas alguns, pequenos arquivos mudaram e precisam ser lidos.

Directoria

Os arquivos podem estar em um diretório, ou em um diretório e seus subdiretórios (recorrentemente) . Se houver um grande número de arquivos (por exemplo, >1,000) , o sistema operacional (e, assim, EDDTableDeFiles) irá operar muito mais eficientemente se você armazenar os arquivos em uma série de subdiretórios (um por ano, ou um por mês para conjuntos de dados com arquivos muito frequentes) , para que nunca haja um grande número de arquivos em um determinado diretório.

Diretórios remotos e solicitações de intervalo HTTP

Diretórios remotos e solicitações de intervalo HTTP (AKA Byte Serving, Byte Range Pedidos) - ... EDDGrid FromNcFiles, EDDTableFromMultidimNcFiles, EDDTableFromNcFiles, e ETableDDFromNcCFFiles, às vezes pode servir dados de .nc arquivos em servidores remotos e acessados via HTTP se o servidor suporta Servir Byte através de solicitações de intervalo HTTP (o mecanismo HTTP para byte servindo) . Isso é possível porque netcdf-java (que ERDDAP™ usos para ler .nc arquivos) suporta a leitura de dados de remoto .nc arquivos através de solicitações de intervalo HTTP.

Não faças isso!
Em vez disso, use o [<cacheDeUrl> sistema] (#cachefromurl) .

Cache De Url

Não. ** <cacheDe Url> ** ] (#cachefromurl) - Não. Tudo EDDGrid FromFiles e todos os conjuntos de dados EDDTableFromFiles suportam um conjunto de tags que contam ERDDAP™ para baixar e manter uma cópia de todos os arquivos de um conjunto de dados remoto, ou um cache de alguns arquivos (baixado conforme necessário) . Este é um recurso incrivelmente útil.
- O<cacheFromUrl> tag permite especificar um URL com uma lista de arquivos de um conjunto de dados remotos de uma lista de arquivos remotos.
  - Conjuntos de dados não agregados em THREDDS, por exemplo, https://data.nodc.noaa.gov/thredds/catalog/aquarius/nodc\\_binned\\_V3.0/monthly/ \[ 2020-10-21 Este servidor não está mais disponível de forma confiável. \]
  - Conjuntos de dados não agregados Hyrax , por exemplo, https://podaac-opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/
  - A maioria das listas de diretórios como Apache, por exemplo, https://www.ncei.noaa.gov/data/global-precipitation-climatology-project-gpcp-daily/
  - Baldes S3, por exemplo, https://noaa-goes17.s3.us-east-1.amazonaws.com/
    No entanto, isso pode exigir uma conta AWS e mais configuração. Ver trabalhando com S3 Buckets em ERDDAP™ . Além disso, você geralmente não precisa usar cache FromUrl com arquivos em baldes S3 se os arquivos são arquivos ASCII (por exemplo, .csv) Porque ERDDAP™ pode ler eficientemente os dados do balde diretamente através de um fluxo.
  ERDDAP™ copiará ou armazenará esses arquivos no conjunto de dados<fileDir> diretório. Se você precisar de suporte para outro tipo de lista de arquivos remotos (por exemplo, FTP) , por favor envie seu pedido para Chris. John no noaaa.gov .
  - O valor padrão para o<cacheDeUrl> tag é nulo. Se você não especificar um valor para o<cacheFromUrl> tag, o sistema copy/cache não será usado para este conjunto de dados.
  - Se o conjunto de dados<arquivoRegex> configuração é algo diferente de .\*, ERDDAP™ só vai baixar arquivos que correspondem ao arquivoRegex.
  - Se o conjunto de dados<configuração recursiva> é verdadeira e os arquivos remotos estão em subdiretórios, ERDDAP™ vai olhar em subdiretórios remotos que correspondem ao conjunto de dados [<Caminhos-de-ferro (#) , criar a mesma estrutura de diretório localmente, e colocar os arquivos locais nas mesmas subdiretórios.
  - Em Gerar conjuntos de dados Xml, se você especificar um<valor cacheFromUrl>, Gerar Conjuntos de dados Xml vai criar o local<fileDir> diretório e copiar 1 arquivo remoto nele. Gerar conjuntos de dados Xml irá então gerar o datasets.xml chunk baseado no arquivo de amostra (especificar amostra Não há nada) .
  - Se a fonte de dados for remota ERDDAP™ , uso EDDGrid De Erddap ou EDDTable FromErddap em vez de<cacheDeUrl>. Por ali, o teu local. ERDDAP™ parece ter o conjunto de dados, mas não precisará armazenar nenhum dos dados localmente. A única razão para usar<cacheFromUrl> para obter dados de um remoto ERDDAP™ é quando você tem alguma outra razão pela qual você quer ter uma cópia local dos arquivos de dados. Nesse caso:
    - Este conjunto de dados tentará assinar o conjunto de dados no remoto ERDDAP para que as mudanças nesse conjunto de dados chamem a bandeira deste conjunto de dados Url, fazendo com que este conjunto de dados local recarregue e baixe os arquivos remotos alterados. Assim, o conjunto de dados local será atualizado muito logo após as mudanças serem feitas no conjunto de dados remoto.
    - Você deve enviar e-mail ao administrador do remoto ERDDAP™ para pedir datasets.xml para o conjunto de dados remoto para que você possa fazer o conjunto de dados em seu local ERDDAP™ olhar como o conjunto de dados no remoto ERDDAP .
  - Se a fonte de dados for remota ERDDAP™ , o conjunto de dados local tentará se inscrever no conjunto de dados remoto.
    - Se a assinatura for bem sucedida, sempre que o remoto ERDDAP recarrega e tem novos dados, ele entrará em contato com o flagURL para este conjunto de dados, fazendo com que ele recarregue e baixe os novos e/ou arquivos de dados alterados.
    - Se a assinatura falhar (por qualquer razão) ou se você simplesmente quiser garantir que o conjunto de dados local está atualizado, você pode definir um bandeira para o conjunto de dados local, então ele irá recarregar, então ele irá verificar para novos e / ou mudou arquivos de dados remotos.
  - Se a fonte de dados não for remota ERDDAP : o conjunto de dados irá verificar para arquivos remotos novos e/ou alterados sempre que recarregar. Normalmente, isso é controlado por [<recarregar Cada NMinutes> (#reloadeverynminutes) . Mas se você sabe quando há novos arquivos remotos, você pode definir um bandeira para o conjunto de dados local, então ele irá recarregar e verificar para novos e / ou mudou arquivos de dados remotos. Se isso acontecer rotineiramente em um determinado momento do dia (por exemplo, às 7h) , você pode fazer um trabalho cron para usar curl para entrar em contato com a bandeira Url para este conjunto de dados, então ele irá recarregar e verificar para novos e / ou mudou arquivos de dados remotos.
- O<cacheSizeGB> tag especifica o tamanho do cache local. Você provavelmente só precisa usar isso ao trabalhar com sistemas de armazenamento em nuvem como Amazon S3 que é um sistema de armazenamento comumente usado que faz parte de Amazon Web Services (AWS) . O padrão é -1.
  - Se o valor for<= 0 (por exemplo, o valor padrão de -1) , ERDDAP™ vai baixar e manter um cópia completa de todos os arquivos do conjunto de dados remotos no conjunto de dados<fileDir>.
    - Esta é a configuração que é recomendada sempre que possível.
    - Sempre que o conjunto de dados é recarregado, ele compara os nomes, tamanhos e os últimos tempos modificados dos arquivos remotos e os arquivos locais, e downloads de quaisquer arquivos remotos que são novos ou mudaram.
    - Se um arquivo que estava no servidor remoto desaparecer, ERDDAP™ não excluirá o arquivo local correspondente (caso contrário, se algo estava temporariamente errado com o servidor remoto, ERDDAP™ pode excluir alguns ou todos os arquivos locais!) .
    - Com esta configuração, geralmente você vai definir<updateEveryNMillis> to -1, uma vez que o conjunto de dados está ciente de quando ele copiou novos arquivos de dados no lugar.
  - Se o valor for >0, ERDDAP™ irá baixar arquivos do conjunto de dados remoto conforme necessário para um local cache (no conjunto de dados<fileDir>) com um tamanho de limiar desse número especificado de GB.
    - O cache deve ser grande o suficiente para segurar pelo menos vários arquivos de dados.
    - Em geral, quanto maior o cache, melhor, porque o próximo arquivo de dados solicitado será mais provável que já esteja no cache.
    - Caching só deve ser usado quando ERDDAP™ está em execução em um servidor de computação em nuvem (por exemplo, uma instância de computação AWS) e os arquivos remotos em um sistema de armazenamento em nuvem (por exemplo, AWS S3) .
    - Quando o espaço em disco usado pelos arquivos locais excede o cache SizeGB, ERDDAP™ em breve (talvez não imediatamente) excluir alguns dos arquivos armazenados (atualmente, com base no Least Recentemente Usado (LRU) algoritmo) até que o espaço de disco usado pelos arquivos locais seja<0,75 € *cacheSizeGB (o "gol") . Sim, há casos em que LRU executa muito mal - não há algoritmo perfeito.
    - ERDDAP™ nunca tentará excluir um arquivo em cache que ERDDAP™ começou a usar nos últimos 10 segundos. Este é um sistema imperfeito para lidar com o sistema de cache e o sistema de leitor de arquivos de dados sendo apenas vagamente integrado. Por causa desta regra, ERDDAP™ pode não ser capaz de excluir arquivos suficientes para alcançar seu objetivo, em que caso ele vai imprimir um WARNING para o arquivo log.txt, e o sistema vai desperdiçar muito tempo tentando ameixar o cache, e é possível que o tamanho dos arquivos no cache pode exceder muito o cacheSizeGB. Se isso ocorrer, use uma configuração maior do cacheSizeGB para esse conjunto de dados.
    - Atualmente, ERDDAP™ nunca verifica se o servidor remoto tem uma versão mais recente de um arquivo que está no cache local. Se você precisar deste recurso, por favor envie um e-mail para Chris. John em noaaa.gov .
  - Embora o uso dos mesmos nomes de tags possa implicar que o sistema de cópia e o sistema de cache usam o mesmo sistema subjacente, que não está correto.
    - O sistema de cópia inicia proativamente tarefasThread tarefas para baixar arquivos novos e alterados cada vez que o conjunto de dados é recarregado. Apenas os arquivos que foram copiados para o diretório local estão disponíveis através do ERDDAP™ conjunto de dados.
    - O sistema de cache recebe a lista de arquivos remotos sempre que o conjunto de dados é recarregado e finge que todos esses arquivos estão disponíveis através do ERDDAP™ conjunto de dados. Curiosamente, todos os arquivos remotos até aparecem nas páginas /files/web do conjunto de dados e estão disponíveis para download (Embora talvez só depois de um atraso, enquanto o arquivo é primeiro baixado do servidor remoto para o cache local.)
  - Os conjuntos de dados que usam cacheSizeGB podem se beneficiar de usar um NTreads configuração maior que 1, porque isso permitirá que o conjunto de dados baixe mais de 1 arquivo remoto de cada vez.
- O<cachePartialPathRegex> tag é uma tag raramente usada que pode especificar uma alternativa para o conjunto de dados [<Caminhos-de-ferro (#) . O padrão é nulo.
  - Use isso somente se você estiver copiando todo o conjunto de dados através do padrão<valor cacheSizeGB> de -1. Com<valores cacheSizeGB> de >1, isso será ignorado porque não é sensato.
  - Veja [a documentação para<Caminhos-de-ferro (#) para orientação sobre como construir o regex.
  - Se isso for especificado, ele será usado cada vez que o conjunto de dados é recarregado, exceto a primeira vez que um conjunto de dados é recarregado no início de um mês.
  - Isso é útil quando o conjunto de dados remoto é armazenado em um labirinto de subdiretórios e quando a grande maioria desses arquivos raramente, se nunca, mudar. (<tosse NASA<tosse> Você poderia, por exemplo, especificar um<cachePartialPathRegex> que apenas corresponde ao ano atual ou ao mês atual. Estes regexes são muito complicados para especificar, porque todos os nomes de caminhos parciais e completos devem corresponder ao<cachePartialPathRegex> e porque<cachePartialPathRegex> deve trabalhar com as URLs remotas e os diretórios locais. Um exemplo de vida real é:

            <cacheFromUrl>https://data.nodc.noaa.gov/ghrsst/GDS2/L4/GLOB/JPL/MUR/v4.1/</cacheFromUrl>  
            \\>!-- \\[2020-10-21 This server is no longer reliably available.\\] For most types of remote directories, omit the filename (e.g., contents.html for Hyrax). -->  
            <fileDir>/u00/satellite/MUR41/</fileDir>  
            <fileNameRegex>\\*\\.nc</fileNameRegex>  
            <recursive>true</recursive>  
            <pathRegex>.\\*</pathRegex>  
            <cachePartialPathRegex>.\\*/v4\\.1/(|2018/(|01./))</cachePartialPathRegex>  

A URL de amostra acima tem arquivos em subdiretórios com base no ano (por exemplo, 2018) e dia do ano (por exemplo, 001, 002, ..., 365 ou 366) . Note que o<cachePartialPathRegex> começa com .\*, então tem um subdiretório específico que é comum às URLs remotas e aos diretórios locais, por exemplo, /v4\.1/ então tem uma série de grupos de captura aninhados onde a primeira opção não é nada e a segunda opção é um valor específico.

O exemplo acima só corresponderá aos diretórios para os segundos 10 dias de 2018, por exemplo, https://data.nodc.noaa.gov/ghrsst/GDS2/L4/GLOB/JPL/MUR/v4.1/2018/010/ \[ 2020-10-21 Este servidor não está mais disponível de forma confiável. \]
e dia 011, 012, ..., 019. (Veja isto documentação e tutorial do regex .)
Se você precisar de ajuda para criar<cachePartialPathRegex>, envie um e-mail para<cache FromUrl> para Chris. John no noaaa.gov .

Uma abordagem comum: Se você quiser usar<cachePartialPathRegex>, não usá-lo inicialmente, porque você quer ERDDAP™ para baixar todos os arquivos inicialmente. Depois ERDDAP™ baixado todos os arquivos, adicioná-lo ao pedaço do conjunto de dados datasets.xml .

Milhares de arquivos

Se o seu conjunto de dados tem muitos milhares de arquivos, ERDDAP™ pode ser lento para responder a pedidos de dados desse conjunto de dados. Há dois problemas aqui:

O número de arquivos por diretório. Internamente, ERDDAP™ opera na mesma velocidade, independentemente de n arquivos estão em um diretório ou dispersos em vários diretórios. Mas há um problema: Quanto mais arquivos em um determinado diretório, mais lento o sistema operacional está retornando a lista de arquivos no diretório (por arquivo) para ERDDAP . O tempo de resposta pode ser O (n Registar n) . É difícil dizer quantos arquivos em um diretório são muitos, mas 10,000 é provavelmente muitos. Então, se sua configuração está gerando muitos arquivos, uma recomendação aqui pode ser: colocar os arquivos em subdiretórios logicamente organizados (por exemplo, estação ou estação/ano) .

Outra razão para usar subdiretórios: se um usuário quiser usar ERDDAP ' "files" sistema para encontrar o nome do arquivo mais antigo para a estação X, é mais rápido e mais eficiente se os arquivos estão em subdiretórios de estação / ano, porque muito menos informações precisam ser transferidas.

O número total de arquivos. Para conjuntos de dados tabulares, ERDDAP™ mantém o controle do intervalo de valores para cada variável em cada arquivo. Quando um usuário faz uma solicitação, ERDDAP™ tem que ler todos os dados de todos os arquivos que podem ter dados correspondentes ao pedido do usuário. Se o usuário solicitar dados de um tempo limitado (por exemplo, um dia ou um mês) Então ERDDAP™ não terá que abrir muitos arquivos em seu conjunto de dados. Mas há casos extremos onde quase todos os arquivos podem ter dados correspondentes (por exemplo, quando a águaTemperature=13.2C) . Desde que é preciso ERDDAP™ um pouco de tempo (em parte o tempo de busca no HDD, em parte o tempo para ler o cabeçalho do arquivo) apenas para abrir um arquivo dado (e mais se houver muitos arquivos no diretório) , há uma pena de tempo significativa se o número total de arquivos que ERDDAP™ tem de abrir é muito grande. Mesmo abrir 1000 arquivos leva tempo significativo. Portanto, há benefícios para consolidar periodicamente os arquivos diários em pedaços maiores (por exemplo, 1 estação para 1 ano) . Eu entendo que você pode não querer fazer isso por várias razões, mas isso leva a respostas muito mais rápidas. Em casos extremos (por exemplo, eu lido com um conjunto de dados GTSPP que tem ~35 milhões de arquivos de origem) , servir dados de um grande número de arquivos de origem é impraticável porque ERDDAP A resposta a consultas simples pode levar horas e usar toneladas de memória. Ao consolidar arquivos de origem em um número menor (para GTSPP, eu tenho 720 agora, 2 por mês) , ERDDAP™ pode responder razoavelmente rapidamente. Ver Milhões de arquivos

N.B. Solid State Drives são ótimos! A maneira mais rápida, mais fácil e mais barata de ajudar ERDDAP™ lidar com um grande número de (pequeno pequeno) arquivos é usar uma unidade de estado sólida. Ver Solid State Drives são ótimos!

Milhões de arquivos

Alguns conjuntos de dados têm milhões de arquivos de origem. ERDDAP™ pode lidar com isso, mas com resultados mistos.
- Para pedidos que envolvam apenas variáveis listadas em [< subsetVariables > (#subsetvariables) , ERDDAP™ tem todas as informações necessárias já extraídas dos arquivos de dados e armazenadas em um arquivo, para que ele possa responder muito, muito rapidamente.
- Para outros pedidos, ERDDAP™ pode digitalizar o conjunto de dados informações de arquivo em cache e descobrir que apenas alguns dos arquivos podem ter dados que são relevantes para a solicitação e, portanto, responder rapidamente.
- Mas para outros pedidos (por exemplo, waterTemperature=18 degree\_C) onde qualquer arquivo pode ter dados relevantes, ERDDAP™ tem que abrir um grande número de arquivos para ver se cada um dos arquivos tem quaisquer dados que sejam relevantes para a solicitação. Os arquivos são abertos sequencialmente. Em qualquer sistema operacional e qualquer sistema de arquivos (diferente de unidades de estado sólido) Isto leva muito tempo (Então... ERDDAP™ responde lentamente) e realmente amarra o sistema de arquivos (Então... ERDDAP™ responde lentamente a outros pedidos) .

Felizmente, há uma solução.

Configurar o conjunto de dados em um não público ERDDAP™ (O seu computador pessoal?) .
Criar e executar um script que solicita uma série de .nc Arquivos CF, cada um com um grande pedaço do conjunto de dados, geralmente um período de tempo (por exemplo, todos os dados para um determinado mês) . Escolha o período de tempo para que todos os arquivos resultantes sejam menos de 2GB (mas esperançosamente maior que 1GB) . Se o conjunto de dados tiver dados em tempo real, execute o script para regenerar o arquivo para o período de tempo atual (por exemplo, este mês) freqüentemente (A cada 10 minutos? A cada hora?) . Pedidos para ERDDAP™ para .nc Arquivos CF criam um NetCDF v3 .nc arquivo que usa o CF Geometrias de amostragem discretas (DSG) Estruturas de dados de Ragged Array contíguas).
Configurar um EDDTable FromNcCFFiles dataset em seu público ERDDAP™ que recebe dados de .nc (CF) arquivos. ERDDAP™ pode extrair dados desses arquivos muito rapidamente. E como há agora dezenas ou centenas (em vez de milhões) de arquivos, mesmo se ERDDAP™ tem que abrir todos os arquivos, ele pode fazê-lo rapidamente.

Sim, este sistema leva algum tempo e esforço para configurar, mas funciona muito, muito bem. A maioria dos pedidos de dados pode ser tratada 100 vezes mais rápido do que antes. \[ Bob sabia que era uma possibilidade, mas foi Kevin O'Brien que primeiro fez isso e mostrou que funciona bem. Agora. Bob usa isso para o conjunto de dados GTSPP que tem cerca de 18 milhões de arquivos de origem e que ERDDAP™ agora serve através de cerca de 500 .nc (CF) arquivos. \]

Arquivos enormes

Um único arquivo de dados enorme (notavelmente arquivos de dados ASCII enormes) pode causar um OutOfMemoryError. Se este é o problema, deve ser óbvio porque ERDDAP™ não carregará o conjunto de dados. A solução, se possível, é dividir o arquivo em vários arquivos. Idealmente, você pode dividir o arquivo em pedaços lógicos. Por exemplo, se o arquivo tem 20 meses de dados, dividi-lo em 20 arquivos, cada um com 1 mês de dados. Mas há vantagens mesmo se o arquivo principal é dividido arbitrariamente. Esta abordagem tem vários benefícios: a) Isso reduzirá a memória necessária para ler os arquivos de dados para 1/20th, porque apenas um arquivo é lido em um momento. b) Muitas vezes, ERDDAP™ pode lidar com pedidos muito mais rápido, porque só tem que olhar em um ou alguns arquivos para encontrar os dados para uma determinada solicitação. c) Se a coleta de dados estiver em andamento, os 20 arquivos existentes podem permanecer inalterados, e você só precisa modificar um, pequeno e novo arquivo para adicionar o valor dos dados do próximo mês para o conjunto de dados.

Problemas de FTP / Conselhos

Se você FTP novos arquivos de dados para o ERDDAP™ servidor enquanto ERDDAP™ está correndo, há a chance de que ERDDAP™ será recarregar o conjunto de dados durante o processo FTP. Acontece mais frequentemente do que você pode pensar! Se acontecer, o arquivo parecerá válido (tem um nome válido) , mas o arquivo não é válido. Se ERDDAP™ tenta ler dados desse arquivo inválido, o erro resultante fará com que o arquivo seja adicionado à tabela de arquivos inválidos. Isto não é bom. Para evitar este problema, use um nome de arquivo temporário quando FTP'ing o arquivo, por exemplo, ABC2005 .nc \_TEMP . Então, o teste fileNameRegex (ver abaixo) irá indicar que este não é um arquivo relevante. Depois que o processo FTP é completo, renomeie o arquivo para o nome correto. O processo de renomeação fará com que o arquivo se torne relevante em um instante.

Extratos de Nome de Ficheiro

\[ Este recurso é DEPRECATED. Por favor use \\\*fileNome pseudo sourceName Em vez disso. \]
EDDTableFromFiles tem um sistema para extrair uma string de cada nome de arquivo e usar isso para fazer uma variável de dados pseudo. Atualmente, não há nenhum sistema para interpretar estes Strings como datas/horas. Existem várias tags XML para configurar este sistema. Se você não precisar de parte ou todo este sistema, apenas não especifique essas tags ou use "" valores.

preExtractRegex é um expressão regular ( tutorial ) usado para identificar o texto a ser removido do início do nome do arquivo. A remoção só ocorre se o regex for combinado. Isso geralmente começa com "^" para combinar o início do nome do arquivo.
postagens ExtractRegex é uma expressão regular usada para identificar o texto a ser removido do final do nome do arquivo. A remoção só ocorre se o regex for combinado. Isso geralmente termina com "$" para corresponder ao final do nome do arquivo.
Extrato Se presente, esta expressão regular é usada após preExtractRegex e postExtractRegex para identificar uma string a ser extraída do nome do arquivo (por exemplo, o stationID ) . Se o regex não for combinado, todo o nome do arquivo é usado (minus preExtract e post Extrato) . Use ".\*" para combinar com todo o nome de arquivo que é deixado após preExtractRegex e postExtractRegex.
coluna NameForExtract é o nome de origem da coluna de dados para as cadeias extraídas. A dataVariable com isto sourceName deve estar no dataVariable Lista s (com qualquer tipo de dados, mas geralmente String) .

Por exemplo, se um conjunto de dados tiver arquivos com nomes como XYZAble .nc , XYZBaker .nc XYZCharlie .nc , ... e você quer criar uma nova variável ( stationID ) quando cada arquivo é lido que terá valores de ID da estação (Able, Baker, Charlie, ...) extraído dos nomes de arquivos, você pode usar essas tags:

<preExtractRegex>XYZ</preExtractRegex> O ^ inicial é um caráter especial de expressão regular que força ERDDAP™ procurar XYZ no início do nome do arquivo. Isso faz com que XYZ, se encontrado no início do nome do arquivo, seja removido (por exemplo, o nome de arquivo XYZAble .nc se torna Able .nc ) .
<postExtractRegex>\ .nc $</postExtractRegex> O $ no final é um caráter especial de expressão regular que força ERDDAP™ para procurar .nc no final do nome do arquivo. Desde . é uma expressão regular caráter especial (que corresponde a qualquer personagem) , é codificado como \. aqui. (porque 2E é o número de caráter hexadecimal por um período) . Isso causa .nc , se encontrado no final do nome do arquivo, para ser removido (por exemplo, o nome de arquivo parcial Able .nc se torna Able) .
<extractRegex>.\</extractRegex> A expressão regular .\ corresponde a todos os caracteres restantes (por exemplo, o nome de arquivo parcial Able torna-se o extrato para o primeiro arquivo) .
<columnNameForExtract> stationID </columnNameForExtract> Isso diz ERDDAP™ para criar uma nova coluna de origem chamada stationID ao ler cada arquivo. Cada linha de dados para um determinado arquivo terá o texto extraído de seu nome de arquivo (por exemplo, Able) como o valor no stationID coluna.

Na maioria dos casos, existem numerosos valores para essas tags de extrato que irão produzir os mesmos resultados - expressões regulares são muito flexíveis. Mas em alguns casos, há apenas uma maneira de obter os resultados desejados.

Pseudo sourceName S

Cada variável em cada conjunto de dados ERDDAP™ tem um [< sourceName > (Nome de fonte) que especifica o nome da fonte para a variável. EDDTableFromFiles suporta alguns pseudo sourceName s que extraem um valor de algum outro lugar (por exemplo, o nome do arquivo ou o valor de um atributo global) e promover esse valor para ser uma coluna de valores constantes para esse pedaço de dados (por exemplo, a tabela dos dados desse arquivo) . Para essas variáveis, você deve especificar o tipo de dados da variável através do [<dataType>] (# Datatype #) tag. Se a informação extraída é uma string dateTime, você especifica o formato da string dateTime no atributos de unidades . O pseudo sourceName opções são:

global: sourceName S

Um atributo global de metadados em cada arquivo de dados de origem pode ser promovido a ser uma coluna de dados. Se uma variável< sourceName > tem o formato

        <sourceName>global:*attributeName*</sourceName>

então quando ERDDAP™ está lendo os dados de um arquivo, ERDDAP™ procurará um atributo global desse nome (por exemplo, PI) e criar uma coluna preenchida com o valor do atributo. Isso é útil quando o atributo tem valores diferentes em arquivos de origem diferentes, porque de outra forma, os usuários só veriam um desses valores para todo o conjunto de dados. Por exemplo,

        <sourceName>global:PI</sourceName>

Quando você promove um atributo a ser dados, ERDDAP™ remove o atributo correspondente. Isso é apropriado porque o valor é presumivelmente diferente em cada arquivo; enquanto que no conjunto de dados agregados em ERDDAP™ terá apenas um valor. Se você quiser, você pode adicionar um novo valor para o atributo para todo o conjunto de dados adicionando<Nome do anúncio atributos Nome " novo novo Valor </att> para o conjunto de dados global [< addAttributes > (#addattributes) . Para atributos globais que ERDDAP™ requer, por exemplo, a instituição, você deve adicionar um novo valor para o atributo.

variável: sourceName S

O atributo metadados de uma variável em cada arquivo pode ser promovido a ser uma coluna de dados. Se uma variável< sourceName \> tem o formato

        <sourceName>variable:*variableName*:*attributeName*<sourceName>

então quando ERDDAP™ está lendo os dados de um arquivo, ERDDAP™ procurará o atributo especificado (por exemplo, ID) da variável especificada (por exemplo, instrumento) e criar uma coluna preenchida com o valor do atributo. A variável pai (por exemplo, instrumento) não precisa ser um dos dataVariable s incluído na definição do conjunto de dados em ERDDAP . Por exemplo,

        <sourceName>variable:instrument:ID</sourceName>

Isso é útil quando o atributo tem valores diferentes em arquivos de origem diferentes, porque de outra forma, os usuários só veriam um desses valores para todo o conjunto de dados.

Quando você promove um atributo a ser dados, ERDDAP™ remove o atributo correspondente. Isso é apropriado porque o valor é presumivelmente diferente em cada arquivo; enquanto que no conjunto de dados agregados em ERDDAP™ terá apenas um valor. Se você quiser, você pode adicionar um novo valor para o atributo para todo o conjunto de dados adicionando<Nome do anúncio atributos Nome " novo novo Valor </att> para a variável [< addAttributes > (#addattributes) . Para atributos que ERDDAP™ requer, por exemplo, ioos\_category (dependendo da sua configuração) , você deve adicionar um novo valor para o atributo.

Nome do arquivo sourceName S

Você pode extrair parte do arquivoName e promover isso para ser uma coluna de dados. O formato deste pseudo [< sourceName > (Nome de fonte) é

        <sourceName>\\*\\*\\*fileName,*regex*,*captureGroupNumber*</sourceName>

Por exemplo,

        <sourceName>\\*\\*\\*fileName,A(\\d{12})\\.slcpV1.nc,1</sourceName>

Quando EDDTableFromFiles estiver lendo os dados de um arquivo, ele irá certificar-se do arquivoNome (por exemplo, A201807041442.slcpV1 .nc ) corresponde à expressão regular especificada ("Regex") e extrair o especificado (neste caso, o primeiro) grupo de captura (que é uma parte cercada por parênteses) , por exemplo, "201807041442". (Veja isto documentação e tutorial do regex .) O regex pode ser especificado como uma string com ou sem citações circundantes. Se o regex for especificado como uma string com aspas circundantes, a string deve ser Corda de estilo JSON (com caracteres especiais escapou com caracteres \) . O número do grupo de captura é geralmente 1 (o primeiro grupo de captura) , mas pode ser qualquer número.

Caminho sourceName S

Você pode extrair parte do caminho completo de um arquivo Nome (/directories/fileName.ext) e promover isso para ser uma coluna de dados. O formato deste pseudo [< sourceName > (Nome de fonte) é

        <sourceName>\\*\\*\\*pathName,*regex*,*captureGroupNumber*<sourceName>

Por exemplo,

        <sourceName>\\*\\*\\*pathName,/data/myDatasetID/(\\[A-Z0-9\\]\\*)/B(\\d{12}).nc,1</sourceName>

Quando EDDTableFromFiles estiver lendo os dados de um arquivo, ele irá certificar-se do caminho completoNome (por exemplo, /data/myDatasetID/BAY17/B201807041442 .nc . Para este teste, os separadores de diretório sempre serão '/' , nunca '\ ') corresponde à expressão regular especificada ("Regex") e extrair o especificado (neste caso, o primeiro) grupo de captura (que é uma parte cercada por parênteses) Por exemplo, "BAY17". (Veja isto documentação e tutorial do regex .) O regex pode ser especificado como uma string com ou sem citações circundantes. Se o regex for especificado como uma string com aspas circundantes, a string deve ser uma Corda de estilo JSON (com caracteres especiais escapou com caracteres \) . O número do grupo de captura é geralmente 1 (o primeiro grupo de captura) , mas pode ser qualquer número.

"0 ficheiros" Mensagem de erro

Se você correr Gerar conjuntos de dadosXml ou DasDds , ou se você tentar carregar um EDDTable From... Dataset de arquivos em ERDDAP™ , e você recebe uma mensagem de erro "0 files" indicando que ERDDAP™ encontrado 0 arquivos correspondentes no diretório (quando você acha que existem arquivos correspondentes nesse diretório) :
- Verifique se os arquivos estão realmente nesse diretório.
- Verifique a ortografia do nome do diretório.
- Verifique o arquivoNameRegex. É realmente, muito fácil cometer erros com regexes. Para fins de teste, tente o regex .\* que deve corresponder a todos os nomes de arquivos. (Veja isto documentação e tutorial do regex .)
- Verifique se o usuário que está executando o programa (por exemplo, user=tomcat (?) para Tomcat / ERDDAP ) tem permissão 'read' para esses arquivos.
- Em alguns sistemas operacionais (por exemplo, SELinux) e dependendo das configurações do sistema, o usuário que executou o programa deve ter permissão de 'leitura' para toda a cadeia de diretórios que levam ao diretório que tem os arquivos.

padronizar O quê?

Quando qualquer subclasse de EDDTableFromFiles está agregando um conjunto de arquivos de origem, para uma determinada variável, todos os arquivos de origem DEVE ter valores de atributos idênticos para vários atributos: scale\_factor , add\_offset , \_Unsigned, missing\_value , \_FillValue e unidades). Pense nisso: se um arquivo tiver windSpeed units=knots e outro tiver windSpeed units=m/s, então os valores de dados dos dois arquivos não devem ser incluídos no mesmo conjunto de dados agregado. Assim, quando o EDDTableFromFiles primeiro cria o conjunto de dados, ele lê os valores de atributos de um arquivo, então rejeita todos os arquivos que têm valores diferentes para esses atributos importantes. Para a maioria das coleções de arquivos, este não é um problema porque os atributos de todas as variáveis são consistentes. No entanto, para outras coleções de arquivos, isso pode levar a 1%, 10%, 50%, 90% ou até mesmo 99% dos arquivos sendo rejeitados como arquivos "maus". Isso é um problema.

EDDTableDe arquivos tem um sistema para lidar com este problema: padronizar O quê? A padronização Que configuração diz EDDTableFromFiles para padronizar os arquivos assim que lê-los, antes EDDTableFromFiles olha para os atributos para ver se eles são consistentes.

O lado flip é: se o conjunto de dados não tiver esse problema, não use padronizar O quê? padronizar O que tem riscos potenciais (discutido abaixo) e ineficiências. Então, se você não precisa realmente das características de padronização O que, não há necessidade de enfrentar os riscos potenciais e ineficiências. A maior ineficiência é: Quando vários padronizar Que opções são usadas por um conjunto de dados, implica que os arquivos de origem estão armazenando dados de maneiras significativamente diferentes (por exemplo, com diferentes scale\_factor e add\_offset , ou com strings de tempo usando formatos diferentes) . Assim, para um determinado constrangimento em um pedido de usuário, não há nenhuma maneira para ERDDAP™ para fazer uma única restrição de nível de fonte que pode ser aplicada a todos os arquivos de origem. Então... ERDDAP™ só pode aplicar as restrições afetadas em um nível superior. Então... ERDDAP™ tem que ler os dados de mais arquivos antes de aplicar as restrições de nível de destino mais altas. Assim, solicitações aos conjuntos de dados que usam a padronização O que demora mais para ser processado.

Para usar este sistema, você precisa especificar

    <standardizeWhat>*standardizeWhat*</standardizeWhat>

no datasets.xml para o EDDTable De... Dataset de arquivos (dentro de<dataset> tag).

O padronizar O quê? valor especifica quais mudanças EDDTableFromFiles devem tentar aplicar. As mudanças são a soma de alguma combinação de:

Unpack Isso faz muitas operações comuns e seguras para padronizar colunas numéricas nos arquivos:
- Se scale\_factor e/ou add\_offset atributos estão presentes, removê-los e aplicá-los para descompactar os valores de dados.
- Descompactar atributos embalados (por exemplo, real\_min, real\_max, actual\_range , data\_min , data\_max , data\_range, valid\_min , valid\_max , valid\_range ) , se presente, se a variável foi embalada, e se os valores dos atributos foram embalados (isso é complicado, mas razoavelmente confiável) .
- Se \_FillValue e/ou missing\_value estão presentes, convertam esses valores de dados para ERDDAP 's "padrão" valores ausentes: MAX\_VALUE para tipos inteiros (por exemplo, 127 para bytes, 32.767 para short, e 2,147,483,647 para ints, 9223372036854775807 por muito tempo) e NaN para dobras e flutuadores.
- Remover o antigo \_FillValue e/ou missing\_value atributos (se houver) , e substituí-los com apenas \_FillValue= \[ o ERDDAP™ valor de falta padrão \] .
Normalizar Tempos Numéricos Se uma coluna numérica tiver unidades de tempo numérico em estilo CF (" timeUnits desde então baseTime ", por exemplo, "dias desde 1900-01-01") , isso converte a data Valores de tempo em "seconds since 1970-01-01T00:00:00Z" valores e muda o atributo de unidades para indicar isso. Se isso for selecionado e houver uma chance de que essa variável tenha scale\_factor ou add\_offset , #1 deve ser selecionado também.
Aplicar corda missing\_value
Se uma coluna String tiver \_FillValue e/ou missing\_value atributos, isso converte esses valores para "" e remove os atributos.
Encontrar numérico missing\_value
Se uma coluna numérica não tiver \_FillValue ou missing\_value atributos, isso tenta identificar um numérico indefinido missing\_value (por exemplo, -999, 9999, 1e37f) e converter instâncias dele para os valores "padrão" (MAX\_VALUE para tipos inteiros, e NAN para dobras e flutuadores) . Esta opção tem um risco: se o maior ou menor valor de dados válido se parece com um valor ausente (por exemplo, 999) , então esses valores de dados válidos serão convertidos em valores ausentes (por exemplo, NaN) .
Alterar corda "N/A" para "" Para cada coluna String, converter várias cadeias comumente usadas para indicar um valor de String ausente para ". Atualmente, isso procura "., "...", "-", "?", "???", "N/A", "NA", "none", "não aplicável", "null", "não conhecido", "não especificado". A busca de string é insensível a maiúsculas e aplicada após as strings serem cortadas. "nd" e "other" não estão especificamente na lista. Esta opção tem um risco: As cordas que você considera serem valores válidos podem ser convertidas em ".
Normalizar para String ISO 8601 DateTimes Para cada coluna String, tente converter não-purely-numeric String dateTimes (por exemplo, "Jan 2, 2018") para ISO 8601 Data de corda ("2018-01-02") . Nota que todos os valores de dados para a coluna devem usar o mesmo formato, caso contrário, esta opção não fará alterações em uma determinada coluna. Esta opção tem um risco: Se houver uma coluna com valores de cadeia de caracteres que por acaso pareçam uma data comum Formato de tempo, eles serão convertidos para ISO 8601 Data de corda.
Normalizar Tempos de Data Compacto para ISO 8601 DataTimes Para cada String ou coluna do tipo inteiro, tente converter a data de String puramente numéricaTimes (por exemplo, "20180102") para ISO 8601 Data de corda ("2018-01-02") . Nota que todos os valores de dados para a coluna devem usar o mesmo formato, caso contrário, esta opção não fará alterações em uma determinada coluna. Esta opção tem um risco: Se houver uma coluna com valores que não sejam data compacta Tempos mas parecem datas compactasTimes, eles serão convertidos para ISO 8601 String dateTimes.
Normalizar unidades Isso tenta padronizar a cadeia de unidades para cada variável. Por exemplo, "metros por segundo", "metro/segundo", "m.s^-1" , "m s-1" , "m.s-1" será convertido para "m.s-1". Isso não muda os valores dos dados. Isso funciona bem para válido UDUNITS unidades strings, mas pode ter problemas com strings inválidas ou complexas. Você pode lidar com problemas especificando específicos de pares em<padronizeUdunits> em ERDDAP ' \[ Toca a brincar. \] /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util/messages.xml ficheiro. Por favor envie um e-mail para quaisquer alterações que você fizer ao Chris. John noaa.gov para que eles possam ser incorporados no default message.xml. Esta opção tem um risco: Isso pode mangar algumas unidades complexas ou inválidas; no entanto, você pode usar a solução descrita acima para evitar problemas se ocorrerem.

O valor padrão de padronização O que é 0, o que não faz nada.

Se/quando você alterar o valor da padronização Da próxima vez que o conjunto de dados for recarregado, ERDDAP™ irá reler todos os arquivos de dados para o conjunto de dados, a fim de reconstruir a mini-base de dados com informações sobre cada arquivo. Se o conjunto de dados tiver muitos arquivos, isso levará muito tempo.

Notas:

Uma coisa complicada é... A padronização Que configuração é usada para todas as colunas no arquivo de origem. Assim, por exemplo, usando #2048 pode converter com sucesso uma coluna de String dataTimes compactos em ISO 8601 String dateTimes, mas também pode erroneamente converter uma coluna com Strings que só por acaso parece uma data compactaTimes.
datasets.xml e Gerar conjuntos de dados Xml - É especialmente complicado para corrigir as configurações datasets.xml para fazer seu conjunto de dados funcionar da maneira que você quer. A melhor abordagem (como sempre) é:

Uso Gerar conjuntos de dadosXml e especifique o valor de padronizar O que você gostaria de usar.
Uso DasDds para garantir que o conjunto de dados carrega corretamente e reflete a padronização Que configuração que você especificou.
Teste o conjunto de dados à mão quando estiver em ERDDAP™ para garantir que as variáveis afetadas funcionem conforme esperado.

Riscos - Opções #256 e acima são mais arriscadas, ou seja, há uma maior chance de que ERDDAP™ vai fazer uma mudança que não deve ser feita. Por exemplo, a opção #2048 pode acidentalmente converter uma variável com cadeias de caracteres de identificação de estação que tudo simplesmente parece datas de "compacto" ISO 8601 (por exemplo, 20180102) em ISO 8601 "extended" datas ("2018-01-02") .
Devagar depois de uma mudança... Desde o valor de padronizar O que muda os valores de dados que EDDTableFromFiles vê para cada arquivo de dados, se você alterar a padronização Que configuração, EDDTableFromFiles vai jogar fora todas as informações em cache sobre cada arquivo (que inclui o min e max para cada variável de dados em cada arquivo) e reler cada arquivo de dados. Se um conjunto de dados tem um grande número de arquivos, isso pode ser muito demorado, então levará muito tempo para o conjunto de dados para recarregar a primeira vez ERDDAP™ recarrega-o depois de fazer a mudança.
Heurística - Opções #256 e acima usar heurística para fazer suas mudanças. Se você se deparar com uma situação em que as heurísticas tomar uma decisão ruim, por favor envie um e-mail para uma descrição do problema para Chris. John no Noaa. Gov para que possamos melhorar a heurística.
Alternativas... Se uma das opções standardizeWhat não resolver um problema para um determinado conjunto de dados, você pode ser capaz de resolver o problema, fazendo um .nc arquivo de ml para paralelo a cada arquivo de dados e definir mudanças nas coisas nos arquivos para que os arquivos sejam consistentes. Então, diga ao EDDTable De... Dataset de arquivos para agregar o .nc Arquivos de ml.

Ou, use NCO para realmente fazer alterações nos arquivos de modo que os arquivos são consistentes.

Colunas separadas para o ano, mês, data, hora, minuto, segundo

É bastante comum para arquivos de dados tabular ter colunas separadas por ano, mês, data, hora, minuto, segundo. Antes ERDDAP™ v2.10, a única solução foi editar o arquivo de dados para combinar essas colunas em uma coluna de tempo unificada. Com ERDDAP™ 2.10+, você pode usar o Não.< sourceName - Sim. expressão < sourceName > (Nome de fonte) para contar ERDDAP™ como combinar as colunas de origem para fazer uma coluna de tempo unificada, então você não precisa mais editar o arquivo de origem.

<skipHeaderToRegex >

Não.<skipHeaderToRegex>] (O que é isso?) - ... Opcional. (Para EDDTableFromAsciiFiles e EDDTableDeColumnarAsciiFiles conjuntos de dados apenas.)
Quando EDDTableFromAsciiFiles lê um arquivo de dados, ele irá ignorar todas as linhas até e incluindo a linha que corresponde a esta expressão regular. O padrão é "", que não usa esta opção. Um exemplo é

    <skipHeaderToRegex>\\\*\\\*\\\* END OF HEADER.\\*<skipHeaderToRegex>

que irá ignorar todas as linhas até e incluindo uma linha que começa com "\\\* END OF HEADER».

Quando você usa esta tag,<colunaNomesRow> e<firstDataRow> agir como se o cabeçalho foi removido antes que o arquivo seja lido. Por exemplo, você usaria columnNamesRow=0 se os nomes das colunas estiverem na linha logo após o cabeçalho.

Se você quiser usar gerar gerar Conjuntos de dados Xml com um conjunto de dados que precisa desta tag:

Faça um novo, temporário, arquivo de amostra copiando um arquivo existente e removendo o cabeçalho.
Executar gerar Conjuntos de dados Xml e especifique esse arquivo de amostra.
Adicione manualmente o<skipHeaderToRegex> tag para o datasets.xml Chuck.
Excluir o arquivo temporário e amostra.
Use o conjunto de dados em ERDDAP .

<skipLinesRegex >

Opcional. (Para EDDTableFromAsciiFiles e EDDTableDeColumnarAsciiFiles conjuntos de dados apenas.)
Quando EDDTableFromAsciiFiles lê um arquivo de dados, ele irá ignorar todas as linhas que correspondem a esta expressão regular. O padrão é "", que não usa esta opção. Um exemplo é

    <skipLinesRegex>#.\\*<skipLinesRegex>

que irá ignorar todas as linhas que começam com "#".

Quando você usa esta tag,<colunaNomesRow> e<firstDataRow> agir como se todas as linhas correspondentes tivessem sido removidas antes que o arquivo seja lido. Por exemplo, você usaria columnNamesRow=0 mesmo se houver várias linhas começando com, por exemplo, "#" no início do arquivo.

EDDTable FromFiles esqueleto XML

<dataset type="EDDTableFrom...Files" datasetID\="..." active\="..." >
      <nDimensions>...</nDimensions> 
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <standardizeWhat>...</standardizeWhat> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <nThreads>...</nThreads> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <specialMode>mode</specialMode> <-- This rarely-used, OPTIONAL tag
        can be used with EDDTableFromThreddsFiles to specify that special,
        hard-coded rules should be used to determine which files should
        be downloaded from the server. Currently, the only valid mode
        is SAMOS which is used with datasets from
        https://tds.coaps.fsu.edu/thredds/catalog/samos to download only the
        files with the last version number. -->
      <sourceUrl>...</sourceUrl> <-- For subclasses like
        EDDTableFromHyraxFiles and EDDTableFromThreddsFiles, this is where
        you specify the base URL for the files on the remote server.
        For subclasses that get data from local files, ERDDAP™ doesn't use
        this information to get the data, but does display the
        information to users. So I usually use "(local files)". -->
      <fileDir>...</fileDir> <-- The directory (absolute) with the data
        files. -->
      <recursive>true|false</recursive> 
      <pathRegex>...</pathRegex> 
      <fileNameRegex>...</fileNameRegex> <-- 0 or 1. A regular expression
        (tutorial) describing valid data file names, for example,
            ".\\.nc" for all .nc files. -->
      <accessibleViaFiles>true|false(default)</accessibleViaFiles>
        
      <metadataFrom>...</metadataFrom> <-- The file to get metadata
        from ("first" or "last" (the default) based on file's
        lastModifiedTime). -->
      <charset>...</charset>
        
      <skipHeaderToRegex>...</skipHeaderToRegex>
      <skipLinesRegex>...</skipLinesRegex>
      <columnNamesRow>...</columnNamesRow> <-- (For EDDTableFromAsciiFiles
        only) This specifies the number of the row with the column
        names in the files. (The first row of the file is "1".
        Default = 1.) If you specify 0, ERDDAP™ will not look for
        column names and will assign names: Column#1, Column#2, ... -->
      <firstDataRow>...</firstDataRow>
        <-- (For EDDTableFromAsciiFiles and EDDTableFromColumnarAsciiFiles
        only) This specifies the number of the first row with data in the
        files. (The first row of the file is "1". Default = 2.) -->
      <dimensionsCSV>...</dimensionsCSV> <-- (For EDDTableFromNcFiles
        and EDDTableFromMultidimNcFiles only) This is a comma-separated
        list of dimension fullNames. If specified, ERDDAP™ will only read
        variables in the source files which use some or all of these
        dimensions, plus all of the scalar variables. If a dimension
        is in a group, you must specify its fullName,
        e.g., "groupName/dimensionName". -->
      <-- The next four tags are DEPRECATED. For more information, see
        File Name Extracts. -->
      <preExtractRegex>...</preExtractRegex>
      <postExtractRegex>...</postExtractRegex>
      <extractRegex>...</extractRegex>
      <columnNameForExtract>...</columnNameForExtract>
      <sortedColumnSourceName>...</sortedColumnSourceName>
        <-- The sourceName of the numeric column that the data files are
        usually already sorted by within each file, for example, "time".
        Don't specify this or use an empty string if no variable is
        suitable. It is ok if not all files are sorted by this column.
        If present, this can greatly speed up some data requests.
        For EDDTableFromHyraxFiles, EDDTableFromNcFiles and
        EDDTableFromThreddsFiles, this must be the leftmost (first) axis variable.
        EDDTableFromMultidimNcFiles ignores this because it has a better
        system. -->
      <sortFilesBySourceNames>...</sortFilesBySourceNames>
        <-- This is a space-separated list of sourceNames
        which specifies how the internal list of files should be sorted
        (in ascending order), for example "id time".
        It is the minimum value of the specified columns in each file
        that is used for sorting.
        When a data request is filled, data is obtained from the files
        in this order. Thus it determines the overall order of the data
        in the response. If you specify more than one column name, the
        second name is used if there is a tie for the first column; the
        third is used if there is a tie for the first and second
        columns; ... This is OPTIONAL (the default is
        fileDir+fileName order). -->

      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <fileTableInMemory>...</fileTableInMemory> 
      <cacheFromUrl>...</cacheFromUrl> 
      <cacheSizeGB>...</cacheSizeGB> 
      <addAttributes>...</addAttributes> 
      <dataVariable>...</dataVariable> 
        <-- For EDDTableFromHyraxFiles, EDDTableFromMultidimNcFiles,
        EDDTableFromNcFiles, EDDTableFromNccsvFiles, and
        EDDTableFromThreddsFiles, the source's axis variables (for
        example, time) needn't be first or in any specific order. -->
  </dataset>

EDDTable De AsciiService

EDDTable De AsciiService é essencialmente um raspador de tela. Pretende-se lidar com fontes de dados que têm um serviço web simples para solicitar dados (muitas vezes um formulário HTML em uma página web) e que pode retornar os dados em algum formato ASCII estruturado (por exemplo, um formato de texto ASCII de valor de vírgula ou colunar, muitas vezes com outras informações antes e/ou após os dados) .

EDDTableFromAsciiService é a superclasse de todas as classes EDDTableFromAsciiService.... Você não pode usar EDDTableFromAsciiService diretamente. Em vez disso, use uma subclasse de EDDTableFromAsciiService para lidar com tipos específicos de serviços:

EDDTable De ASciiServiceNOS recebe dados de NOAA Serviços ASCII da NOS.

Atualmente, nenhum outro tipo de serviço é suportado. Mas geralmente é relativamente fácil apoiar outros serviços se eles trabalham de forma semelhante. Contacte-nos se tiver um pedido.

Detalhes

As seguintes informações aplicam-se a todas as subclasses de EDDTableFromAsciiService.

Restrições... ERDDAP™ solicitações de dados tabular podem colocar restrições em qualquer variável. O serviço subjacente pode ou não permitir restrições em todas as variáveis. Por exemplo, muitos serviços só suportam restrições nos nomes das estações, latitude, longitude e tempo. Assim, quando uma subclasse de EDDTableFromAsciiService recebe um pedido para um subconjunto de um conjunto de dados, ele passa o máximo de restrições possível para o serviço de dados de origem e, em seguida, aplica as restrições restantes aos dados retornados pelo serviço, antes de entregar os dados ao usuário.
Alcance válido -- Ao contrário de muitos outros tipos de conjuntos de dados, o EDDTableFromAsciiService geralmente não conhece o intervalo de dados para cada variável, por isso não pode rejeitar rapidamente solicitações de dados fora do intervalo válido.
Parsing the ASCII Text Response -- Quando EDDTableFromAsciiService recebe uma resposta de um Serviço de Texto ASCII, deve validar que a resposta tem o formato e a informação esperados e, em seguida, extrair os dados. Você pode especificar o formato usando várias tags especiais no pedaço de XML para este conjunto de dados:
- <antesData1> através<antesData10> tags -- Você pode especificar uma série de peças de texto (quantos quiser, até 10) que EDDTableFromAsciiService deve procurar no cabeçalho do texto ASCII retornado pelo serviço com<antesData1> através<antes deData10>. Por exemplo, isso é útil para verificar se a resposta inclui as variáveis esperadas usando as unidades esperadas. A última tag antesData que você especifica identifica o texto que ocorre antes do início dos dados.
- <depois de dados> - ... Isso especifica o texto que o EDDTableFromAsciiService procurará no texto ASCII retornado pelo serviço que significa o fim dos dados.
- <NoData> - ... Se EDDTableFromAsciiService encontrar este texto no texto ASCII retornado pelo serviço, conclui que não há dados que correspondam ao pedido.

EDDTable FromAsciiService esqueleto XML

<dataset type="EDDTableFromAsciiService..." datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <sourceUrl>...</sourceUrl>
      <beforeData1>...<beforeData1> 
      ...
      <beforeData10>...<beforeData10> 
      <afterData>...<afterData> 
      <noData>...<noData> 
      <addAttributes>...</addAttributes> 
      <dataVariable>...</dataVariable> 
  </dataset>

EDDTable De ASciiServiceNOS

EDDTable De ASciiServiceNOS faz conjuntos de dados EDDTable dos serviços de dados de texto ASCII oferecidos por NOAA ' Serviço Nacional do Oceano (NÃO) . Para obter informações sobre como esta classe funciona e como usá-la, veja a superclasse desta classe EDDTable De AsciiService . É improvável que qualquer outro que não Bob Simons precise usar esta subclasse.

Uma vez que os dados dentro da resposta de um serviço NOS utilizam um formato de texto ASCII colunar, as variáveis de dados que não sejam latitude e longitude devem ter um atributo especial que especifica quais caracteres de cada linha de dados contêm os dados dessa variável, por exemplo,

<att name="responseSubstring">17, 25</att>

EDDTableDe todos os conjuntos de dados

EDDTableDe todos os conjuntos de dados é um conjunto de dados de nível superior que tem informações sobre todos os outros conjuntos de dados que estão atualmente carregados em seu ERDDAP . Ao contrário de outros tipos de conjuntos de dados, não há especificação para o allDatasets dataset in datasets.xml . ERDDAP™ cria automaticamente um conjunto de dados EDDTableFromAllDatasets (com datasetID = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = allDatasets ) . Assim, um allDatasets dataset será criado em cada ERDDAP™ instalação e trabalhará da mesma maneira em cada ERDDAP™ instalação.

O allDatasets dataset é um conjunto de dados tabular. Tem uma linha de informações para cada conjunto de dados. Tem colunas com informações sobre cada conjunto de dados, por exemplo, datasetID , acessível, instituição, título, minLongitude, maxLongitude, minLatitude, maxLatitude, minTime, maxTime, etc. Porque... allDatasets é um conjunto de dados tabular, você pode consultar da mesma forma que você pode consultar qualquer outro conjunto de dados tabular em ERDDAP™ , e você pode especificar o tipo de arquivo para a resposta. Isso permite que os usuários procurem conjuntos de dados de interesse de maneiras muito poderosas.

EDDTable FromAsciiFiles

EDDTable FromAsciiFiles agrega dados de vírgula, tab-, ponto-, ou arquivos de dados tabulares ASCII separados por espaço.

Na maioria das vezes, os arquivos terão nomes de colunas na primeira linha e dados começando na segunda linha. (Aqui, a primeira linha do arquivo é chamada linha número 1.) Mas você pode usar<colunaNomesRow> e<primeiroDataRow> em seu datasets.xml arquivo para especificar um número de linha diferente.
ERDDAP™ permite que as linhas de dados tenham diferentes números de valores de dados. ERDDAP™ assume que os valores de dados ausentes são as colunas finais na linha. ERDDAP™ atribui os valores de valor padrão ausentes para os valores de dados ausentes. (adicionado v1.56)
Os arquivos ASCII são fáceis de trabalhar, mas não são a maneira mais eficiente de armazenar / recuperar dados. Para maior eficiência, salve os arquivos como NetCDF v3 .nc arquivos (com uma dimensão, "row", compartilhada por todas as variáveis) Em vez disso. Você pode uso ERDDAP™ para gerar novos arquivos .
Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Por causa da falta total de metadados em arquivos ASCII, você sempre precisará editar os resultados de GerarDatasetsXml.
Quando: ERDDAP™ lê arquivos de dados ASCII, se encontrar um erro em uma determinada linha (por exemplo, número incorreto de itens) , registra uma mensagem de aviso ("WARNING: Linha má (S) de dados" ... com uma lista das linhas ruins em linhas subseqüentes) ao arquivo log.txt e, em seguida, continua a ler o resto do arquivo de dados. Assim, é sua responsabilidade olhar periodicamente (ou escrever um script para fazê-lo) para essa mensagem no log. txt para que você possa corrigir os problemas nos arquivos de dados. ERDDAP™ é configurado desta forma para que os usuários possam continuar a ler todos os dados válidos disponíveis, mesmo que algumas linhas do arquivo tenham falhas.

Tabela de EDD TolsXmlFiles

Tabela de EDD TolsXmlFiles agrega dados de um conjunto de Estação de Tempo Automático (AWS) Arquivos de dados XML usando a API XML do WeatherBug Rest (que não é mais ativo) .

Este tipo de arquivo é uma maneira simples, mas ineficiente de armazenar os dados, porque cada arquivo geralmente parece conter a observação de apenas um ponto de tempo. Então pode haver um grande número de arquivos. Se você quiser melhorar o desempenho, considere consolidar grupos de observações (Vale uma semana?) em NetCDF v3 .nc arquivos (melhor: .nc arquivos com o CF Geometrias de amostragem discretas (DSG) Contígua Ragged Array formato ) e usando EDDTable FromMultidimNcFiles (ou EDDTable FromNcCFFiles ) para servir os dados. Você pode uso ERDDAP™ para gerar novos arquivos .
Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

EDDTable FromColumnarAsciiFiles

EDDTable FromColumnarAsciiFiles agrega dados de arquivos de dados ASCII tabular com colunas de largura fixa.

Na maioria das vezes, os arquivos terão nomes de colunas na primeira linha e dados começando na segunda linha. A primeira linha / linha no arquivo é chamada linha #1. Mas você pode usar<colunaNomesRow> e<primeiroDataRow> em seu datasets.xml arquivo para especificar um número de linha diferente.
O< addAttributes > para cada um< dataVariable > para estes conjuntos de dados DEVE incluir estes dois atributos especiais:
- <nome do att="startColumn"> Intérprete <att> -- especifica a coluna de caracteres em cada linha que é o início desta variável de dados.
- <nome do att="stopColumn"> Intérprete <att> -- especifica a coluna de caracteres em cada linha que é a 1 após o final desta variável de dados.

A primeira coluna de caracteres é chamada coluna #0. Por exemplo, para este arquivo que tem valores de tempo que aumentam os valores de temperatura :

      0         1         2        <-- character column number 10's digit
      0123456789012345678901234567 <-- character column number 1's digit
      time                temp
      2014-12-01T12:00:00Z12.3
      2014-12-02T12:00:00Z13.6
      2014-12-03T12:00:00Z11.0

a variável de dados de tempo teria

      <att name="startColumn">0<att>  
      <att name="stopColumn">20<att>  

e a variável de dados de tempo teria

      <att name="startColumn">20<att>  
      <att name="stopColumn">24<att>  

Esses atributos devem ser especificados para todas as variáveis exceto valor fixo e nome de arquivo-fonte-nomes variáveis.

Os arquivos ASCII são fáceis de trabalhar, mas não são uma maneira eficiente de armazenar / recuperar dados. Para maior eficiência, salve os arquivos como NetCDF v3 .nc arquivos (com uma dimensão, "row", compartilhada por todas as variáveis) Em vez disso. Você pode uso ERDDAP™ para gerar novos arquivos .
Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Devido à dificuldade de determinar as posições de início e fim para cada coluna de dados e a total falta de metadados em arquivos ASCII, você sempre precisará editar os resultados de GerarDatasetsXml.

EDDTable FromHttpGet

Tabela de EDD FromHttpGet é diferente de todos os outros tipos de conjuntos de dados em ERDDAP™ na medida em que tem um sistema pelo qual "autores" específicos podem adicionar dados, revisar dados ou excluir dados do conjunto de dados por regular HTTP GET ou AM POSTAM solicitações de um programa de computador, um script ou um navegador. O conjunto de dados é queryable pelos usuários da mesma forma que todos os outros conjuntos de dados EDDTable são queryable in ERDDAP . Veja a descrição da superclasse desta classe, Tabela EDD dos arquivos , para ler sobre as características que são herdadas dessa superclasse.

As características únicas do EDDTableFromHttpGet são descritas abaixo. Você precisa ler toda esta seção inicial e compreendê-la; caso contrário, você pode ter expectativas irrealistas ou se meter em problemas que é difícil de corrigir.

Uso intencional

Este sistema destina-se a:

Tabular (in situ) dados, não dados gradeados.
Dados em tempo real - O objetivo é permitir um autor (por exemplo, o sensor, um script QC automatizado ou um humano específico) para fazer uma mudança no conjunto de dados (através de .insert ou comando .delete ) e tornar essa mudança acessível a ERDDAP™ usuários, todos em menos de 1 segundo, e possivelmente muito mais rápido. A maioria desse 1 segundo é tempo de rede. ERDDAP™ pode processar a solicitação em cerca de 1 ms e os dados são imediatamente acessíveis aos usuários. Isto é... rápido , robusto e sistema confiável .
Quase qualquer frequência de dados - Este sistema pode aceitar dados infrequentes (por exemplo, diariamente) através de dados muito frequentes (por exemplo, dados de 100 Hz) . Se você otimizar o sistema, ele pode lidar com dados de maior frequência (talvez 10 KHz dados se você ir para extremos) .
Dados de um sensor ou uma coleção de sensores semelhantes.
Versão / Ciência reprodutiva / DOI s... Situações onde você precisa ser capaz de fazer alterações nos dados (por exemplo, mudar uma bandeira de controle de qualidade) , saber qual autor fez cada mudança, saber o timestamp de quando o autor fez a mudança, e (mediante pedido) ser capaz de ver os dados originais de antes da mudança foi feita. Assim, esses conjuntos de dados são elegíveis para DOI S . porque eles se encontram DOI exigência que o conjunto de dados é imutável, exceto por agregação. Em geral, quase conjuntos de dados em tempo real não são elegíveis para DOI s porque os dados são frequentemente alterados retroativamente (por exemplo, para fins de QA/QC) .

Uma vez que os dados estão em um conjunto de dados EDDTableFromHttpGet, qualquer usuário pode solicitar dados da mesma forma que solicitar dados de qualquer outro conjunto de dados EDDTable.

Experimental: Cuidado.

Uma vez que este sistema é novo e uma vez que os dados ambientais perdidos não podem ser requisitados, você deve tratar EDDTableFromHttpGet como experimental. Se você está transicionando de outro sistema, execute o velho sistema e o novo sistema em paralelo até que você esteja confiante de que o novo sistema funciona bem (semanas ou meses, não apenas horas ou dias) . Em todos os casos, verifique se o seu sistema arquiva separadamente as URLs .insert e .delete que são enviadas para o conjunto de dados EDDTableFromHttpGet (mesmo se apenas nos logs Apache e/ou Tomcat) Pelo menos por um tempo. E em todos os casos, certifique-se de que os arquivos de dados criados pelo seu conjunto de dados EDDTableFromHttpGet são rotineiramente suportados até dispositivos de armazenamento de dados externos. (Note que rsync . pode fazer backup dos arquivos de dados criados pelo EDDTableFromHttpGet de forma muito eficiente.)

.insert e .delete

Para qualquer conjunto de dados ERDDAP™ , quando você envia um pedido para ERDDAP™ para um subconjunto dos dados em um conjunto de dados, você especifica o tipo de arquivo que deseja para a resposta, por exemplo, .csv, .htmlTable , .nc , .json . EDDTable FromHttp Obter estende este sistema para suportar dois tipos de arquivo adicionais que podem inserir (ou mudar) ou excluir dados no conjunto de dados:

Inserir
- A solicitação é formatada como uma resposta padrão do formulário HTML, com pares chave=valor, separados por '&'. Por exemplo, https://some.erddap.url/erddap/tabledap/myDataset**.insert**?stationID=46088&time=2016-03-30T12:37:55Z&latitude=10.1&longitude=-150.1&airTemp=17.23&waterTemp=12.3&author=JohnSmith\_someKey1
  diz ERDDAP™ para adicionar ou alterar os dados para stationID =46088 para o tempo especificado.
- O autor desta mudança é JohnSmith e a chave é algumKey1.
- A URL deve incluir valores válidos (não faltando valores) para todos os http GetRequiredVariables
- Se os valores do http GetRequired Variáveis no pedido (por exemplo, stationID e tempo) combinar os valores em uma linha já no conjunto de dados, os novos valores efetivamente substituir os valores antigos (embora os valores antigos ainda estejam acessíveis se o usuário solicitar dados de um anterior versão do conjunto de dados) .
- A URL .insert nunca deve incluir &timestamp= ( ERDDAP™ gera esse valor) ou e-mail: (que é especificado por .insert (que é comando=0) ou (que é o comando 1) ) .
- Se a URL .insert não especificar valores para outras colunas que estão no conjunto de dados, elas são assumidas como os valores ausentes nativos. (MAX\_VALUE para tipos de dados inteiros, NaN para flutuadores e duplos, e "" para cordas) .
- Não.
  - A solicitação é formatada como uma resposta padrão do formulário HTML, com pares chave=valor, separados por '&'. Por exemplo, https://some.erddap.url/erddap/tabledap/myDataset**.delete**?stationID=46088&time=2016-03-30T12:37:55Z&author=JohnSmith\_someKey1
    diz ERDDAP™ para excluir os dados stationID =46088 no tempo especificado.
  - O autor desta mudança é JohnSmith e a chave é algumKey1.
  - A URL deve especificar http GetRequiredVariables no pedido (por exemplo, stationID e tempo) . Se esses valores corresponderem aos valores em uma linha já no conjunto de dados (que eles geralmente vão) , os valores antigos são efetivamente excluídos (embora os valores antigos ainda estejam acessíveis se um usuário solicitar dados de um anterior versão do conjunto de dados) .
  - Não há necessidade de especificar valores para não-HttpGetRequiredVariables, além do autor, que é necessário para autenticar o pedido.

Detalhes:

.insert e .delete solicitações são formatadas como respostas de formulário HTML padrão, com pares key=value, separados por '&'. Os valores devem ser por cento codificado . Assim, você precisa codificar caracteres especiais na forma %HH, onde HH é o valor hexadecimal de 2 dígitos do personagem. Normalmente, você só precisa converter alguns dos caracteres de pontuação: % em %25, & em %26, " em %22,<em %3C, = em %3D, > em %3E, + em %2B, | em %7C, \[ em %5B, \] em %5D, espaço em %20, e converter todos os caracteres acima #127 em sua forma UTF-8 e, em seguida, por cento codificar cada byte da forma UTF-8 no formato %HH (pedir ajuda a um programador) .
.insert e .delete pedidos devem incluir o http GetRequiredVariables , por exemplo, stationID e tempo. Para pedidos .insert, as variáveis que não são especificadas no pedido são assumidas como valores ausentes (MAX\_VALUE para variáveis integer, NaN para variáveis flutuantes e duplas, e uma string vazia para variáveis String) . Para pedidos .delete, valores para non-HttpGetRequired Variáveis (diferente do autor, que é necessário) são ignorados.
.insert e .delete solicitações devem incluir o nome do autor e a chave do autor através de um parâmetro no formulário autor= autor\_key como o último parâmetro no pedido. Requirir isso para ser a última garante que todo o pedido foi recebido por ERDDAP . Apenas o autor (não a chave) será armazenado no arquivo de dados. Você deve especificar a lista de permitidos autor\_key 's através do atributo global http Beco
Os parâmetros .insert e .delete podem ser escalares (único) valores ou arrays de qualquer comprimento na forma \[ valor1, valor2, valor3,...,valueN \] . Para um determinado pedido, todas as variáveis com arrays devem ter arrays com o mesmo número de valores (mais é um erro) . Se uma solicitação tiver valores escalares e array, os valores escalares são replicados para se tornar arrays com o mesmo comprimento que os arrays especificados, por exemplo, & stationID =46088 pode ser tratado como > stationID = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = \[ 46088, 46088, 46088 \] . Arrays são a chave para alta taxa de transferência . Sem arrays, será desafiador para .insert ou .delete mais de 8 linhas de dados por segundo de um autor remoto (por causa de toda a sobrecarga da rede) . Com arrays, será fácil .insert ou .delete mais de 1000 linhas de dados por segundo de um sensor remoto.
.insert e .delete aceitar (sem uma mensagem de erro) números de ponto flutuante quando inteiros são esperados. Nesses casos, o conjunto de dados rodeia os valores para inteiros.
.insert e .delete aceitar (sem uma mensagem de erro) números inteiros e de ponto flutuante que estão fora de alcance do tipo de dados da variável. Nesses casos, o conjunto de dados armazena os valores como ERDDAP Os valores perdidos nativos para esse tipo de dados (MAX\_VALUE para tipos inteiros e NaN para flutuadores e dobras) .

Resposta

Se o URL .insert ou .delete tiver sucesso, o código de resposta HTTP será 200 (Está bem.) e a resposta será texto com um .json objeto, por exemplo,

    {
    "status":"success",
    "nRowsReceived":1,
    "stringTimestamp":"2018-11-05T22:12:19.517Z",
    "numericTimestamp":1.541455939517+E9
    }

Note que os timestamps têm precisão milissegunda.

Se a URL .insert ou .delete falhar, você receberá um código de resposta HTTP diferente de 200 (Está bem.) , por exemplo, Erro 403 Proibido se você enviar um autor incorreta\_key valor. ERDDAP™ envia o código de resposta HTTP (não, por exemplo, um .json erro formatado) porque é assim que as coisas são feitas na internet e porque os erros podem ocorrer em qualquer lugar do sistema (por exemplo, na rede, que retorna um erro HTTP) . Se o erro é de ERDDAP™ , a resposta pode incluir algum texto (não .json ) com uma explicação mais detalhada do que correu mal, mas o código de resposta HTTP (200 = Ok, qualquer outra coisa é problema) é a maneira adequada de verificar se o .insert ou .delete conseguiu. Se verificar o código de resposta HTTP não é possível ou é inconveniente, procure "status":"sucesso" no texto de resposta que deve ser uma indicação confiável do sucesso.

Arquivos de log

Quando EDDTableFromHttpGet recebe comandos .insert e .delete, ele simplesmente anexa as informações ao arquivo relevante em um conjunto de arquivos de log, cada um dos quais é uma tabela armazenada em um JSON Linhas arquivo CSV . Quando um usuário faz um pedido de dados, ERDDAP™ lê rapidamente os arquivos de log relevantes, aplica as alterações no conjunto de dados na ordem que foram feitas e, em seguida, filtra a solicitação através das restrições do usuário como qualquer outro ERDDAP™ pedido de dados. O particionamento dos dados em vários arquivos de log, o armazenamento de várias peças de informação (por exemplo, o timestamp do comando, e se o comando era .insert ou .delete) , e vários aspectos da configuração do conjunto de dados, todos tornam possível ERDDAP para armazenar dados e recuperar dados deste conjunto de dados muito rapidamente e muito eficiente.

Segurança e Autor

Cada comando .insert e .delete deve incluir &author= autor\_key como o último parâmetro, onde autor\_key é composto pelo identificador do autor (você escolheu: nome, iniciais, pseudônimo, número) Um sublinhado e uma chave secreta. O ERDDAP™ administrador trabalhará com autores para gerar a lista de valores válidos do autor\_key, que podem ser alterados a qualquer momento. Quando EDDTableFromHttpGet recebe um comando .insert ou .delete, garante que o autorID\_key é o último parâmetro e válido. Porque é o último parâmetro, indica que toda a linha de comando chegou ERDDAP™ e não foi truncado. A chave secreta garante que apenas autores específicos podem inserir ou excluir dados no conjunto de dados. ERDDAP™ então extrai o autorID e salva que na variável do autor, para que qualquer pessoa possa ver quem foi responsável por uma determinada mudança no conjunto de dados. .insert e .delete comandos só podem ser feitos via https: (seguro) ERDDAP™ URLs. Isso garante que as informações que estão sendo transferidas sejam mantidas em segredo durante o trânsito.

vezes

Como parte do sistema de log, EDDTableFromHttpGet adiciona um timestamp (o tempo que ERDDAP recebeu o pedido) para cada comando que ele armazena nos arquivos de log. Porque... ERDDAP™ gera o timestamp, não os autores, não importa se diferentes autores estão fazendo mudanças de computadores com relógios definidos para tempos ligeiramente diferentes. O timestamp indica de forma confiável o tempo em que a mudança foi feita para o conjunto de dados.

HTTP POST

"E o HTTP POST?!"
HTTP AM POSTAM é a melhor alternativa (em comparação com HTTP GET ) para enviar informações de um cliente para um servidor HTTP. Se você puder, ou se realmente quiser melhorar a segurança, use o POST em vez do GET para enviar as informações para ERDDAP . POST é mais seguro porque: com GET e https , a URL é transmitida de forma segura, mas toda a URL (incluindo parâmetros, incluindo o autor\_key) será escrito para o Apache, Tomcat, e ERDDAP™ logar arquivos, onde alguém poderia lê-los se os arquivos não são devidamente protegidos. Com o POST, os parâmetros são transmitidos de forma segura e não estão escritos nos arquivos de log. POST é um pouco mais difícil para os clientes trabalhar com e não é suportado tão amplamente pelo software cliente, mas as linguagens de programação o suportam. O conteúdo que você enviar para o conjunto de dados via GET ou POST será o mesmo, apenas formatado de uma forma diferente.

http GetRequired Variáveis Atributo global

Uma parte essencial do que faz todo este sistema funcionar é o atributo global exigido http GetRequired Variáveis, que é uma lista separada por vírgulas dataVariable nomes de origem que identificam exclusivamente uma linha de dados. Isso deve ser o mínimo possível e quase sempre incluirá a variável de tempo. Por exemplo, aqui estão os recomendados http GetRequired Variáveis para cada um dos CF Geometrias de amostragem discretas (DSG) (Claro, os nomes de ID podem ser diferentes no seu conjunto de dados.) :

Para o TimeSeries: stationID , tempo
Para Trajectory: trajectoryID, time
Para Perfil: tempo (assumindo que o tempo é o perfil\_id) , profundidade
Para a série do tempo Perfil: stationID , tempo (assumindo que o tempo é o perfil\_id) , profundidade
Para Trajectória Perfil: trajectoryID, time (assumindo que o tempo é o perfil\_id) , profundidade

Tomando TimeSeries como um exemplo: Dado um comando .insert que inclui stationID =46088 e time=2016-06-23T19:53:00Z (e outros valores para outras variáveis) :

Se não houver dados existentes para essa estação e esse tempo, então o efeito será adicionar os dados ao conjunto de dados.
Se houver dados existentes para essa estação e esse tempo, então o efeito será substituir a linha de dados existente com esses novos dados. (Claro, desde ERDDAP™ mantém o registro de cada comando que recebe, os dados antigos ainda estão no log. Se um usuário solicitar dados de uma versão do conjunto de dados antes dessa mudança, eles verão os dados mais antigos.)

http Introdução

http Introdução Estrutura Atributo global e dados (Login) Nomes de arquivo
Parte do que faz todo este sistema funcionar de forma eficiente é que ERDDAP™ cria um conjunto de dados (log) arquivos, cada um com um pedaço diferente do conjunto de dados. Se estes forem bem configurados, ERDDAP™ será capaz de responder rapidamente à maioria dos pedidos de dados. Esta configuração é especificada pelo http GetDirectoryStructure atributo global, que é um String que parece um nome de arquivo relativo, por exemplo, " stationID /10years", mas é realmente uma especificação para a estrutura do diretório. As partes que indicam como diretório e nomes de arquivo para os dados (log) arquivos serão construídos.
Se uma parte é um inteiro (- Sim. 1) mais um tempoPeriod (milissegundo, segundo, minuto, hora, data, mês, ano, ou seus plurais) , por exemplo, 10 anos, então o conjunto de dados EDDTableFromHttpGet levará o valor do tempo para a linha de dados (por exemplo, 2016-06-23T19:53:00Z) , calcular o tempo truncado a essa precisão (por exemplo, 2010) , e fazer uma pasta ou arquivo Nome disso.

O objetivo é obter um pedaço razoavelmente grande de dados em cada arquivo, mas muito menos de 2GB.

Caso contrário, a parte da especificação deve ser uma dataVariable ' sourceName , por exemplo, stationID . Neste caso, EDDTableFromHttpGet fará uma pasta ou nome de arquivo do valor dessa variável para a nova linha de dados (por exemplo, "46088") .

Como os dados de comando .insert e .delete são armazenados em dados específicos (log) arquivos, EDDTableFromHttpGet geralmente só precisa abrir um ou alguns dados (log) arquivos para encontrar os dados para uma determinada solicitação de usuário. E porque cada dado (log) arquivo tem todas as informações relevantes para o seu pedaço do conjunto de dados, é rápido e fácil para EDDTableFromHttpGet para fazer uma versão específica (ou a versão atual) do conjunto de dados para os dados nesse arquivo (e não tem que gerar a versão solicitada de todo o conjunto de dados) .

As diretrizes gerais são baseadas na quantidade e frequência dos dados. Se assumirmos 100 bytes por linha de dados, então ...

    | Frequency  <br>of measurements | Recommended  <br>httpGetDirectoryStructure |
    | --- | --- |
    | \\>=1 per second | *featureID*/1year/1day |
    | \\>=1 per minute | *featureID*/2months |
    | \\>=1 per hour | *featureID*/10years |
    | \\>=1 per day | *featureID* |

Por exemplo, se a estrutura do diretório for stationID /2 meses e você inserir dados de duas estações (46088 e 46155) com valores de tempo de dezembro de 2015 a maio de 2016, EDDTableFromHttp Get irá criar diretórios nomeados 46088 e 46155 e criar arquivos em cada nome 2015-11 .json I, 2016-01 .json I, 2016-03 .json l, 2016-05 .json Eu... (2 meses de dados para a estação relevante) . Em qualquer momento no futuro, se você usar .insert ou .delete para alterar ou excluir os dados para, por exemplo, estação 46088 em 2016-04-05T14:45:00Z, EDDTableFromHtp Obter vai anexar esse comando para 46088/2016-03 .json l, os dados relevantes (log) ficheiro. E claramente, é bom adicionar dados para outras estações a qualquer momento no futuro, uma vez que o conjunto de dados irá simplesmente criar diretórios adicionais conforme necessário para manter os dados das novas estações.

http Beco

Cada tabela EDD De Http Obter conjunto de dados deve ter um atributo global http GetKeys que especifica a lista de autores permitidos e suas chaves secretas como uma lista separada por vírgulas autor\_key , por exemplo, JohnSmith\_someKey1, HOBOLogger\_someKey2, QCScript59\_someKey3 .

autor\_key's são sensíveis a casos e devem ser inteiramente caracteres ASCII (#33 - #126, e sem qualquer vírgula, " ou ' caracteres
Chaves são como senhas, então eles devem ser >=8 caracteres, difícil de adivinhar, e sem palavras de dicionário interno. Você deve tratá-los como você trataria senhas -- mantê-los privados.
O primeiro caracter '\' separa o autor da chave, então o nome do autor não pode incluir um caracter '\' (mas uma chave pode) .
Qualquer autor pode ter um ou mais autor\_key's, por exemplo, JohnSmith\_some Chave, JohnSmith\_some Key7, etc.
Você pode alterar o valor deste atributo a qualquer momento. As alterações entram em vigor na próxima vez que o conjunto de dados for carregado.
Essas informações serão removidas dos atributos globais do conjunto de dados antes de serem tornados públicos.
Cada solicitação ao conjunto de dados para inserir ou excluir dados deve incluir um &author= autor\_key parâmetro. Depois de verificar a validade da chave, ERDDAP™ apenas salva a parte do autor (não a chave) no arquivo de dados.

Configurar

Aqui estão as etapas recomendadas para configurar um conjunto de dados EDDTableFromHttpGet:

Faça o diretório principal para manter os dados deste conjunto de dados. Por exemplo, vamos usar /data/testGet/ . O usuário executando GenerateDatasetsXml e o usuário executando ERDDAP™ ambos devem ter acesso de leitura-escrita a este diretório.
Use um editor de texto para fazer uma amostra .json l Arquivo CSV com a extensão .json Eu nesse diretório. O nome não é importante. Por exemplo, você pode chamá-lo de amostra .json Eu... Faça uma linha 2 .json l Arquivo CSV, com nomes de colunas na primeira linha e valores dummy/típicos (do tipo de dados correto) na segunda linha. Aqui está um arquivo de amostra que é adequado para uma coleção de featureType =TimeSeries dados que mediram a temperatura do ar e da água. \[ Para featureType =Trajectory, você pode mudar stationID para ser trajectoryID. \]
\[ Para featureType =Perfil, você pode mudar stationID para ser profileID e adicionar uma variável de profundidade. \]

\[ " stationID " "time" , "latitude", "longitude", "airTemp", "waterTemp", "timestamp", "author", "command" \] \[ "myStation", "2018-06-25T17:00Z", 0,0, 0,0, 0,0, 0,0, 0,0, "SomeBody", 0 \]

Nota:

Os valores de dados reais não importam porque você eventualmente excluirá este arquivo, mas eles devem ser do tipo de dados correto. Notavelmente, a variável de tempo deve usar o mesmo formato que os dados reais da fonte usarão.
Para todas as variáveis, o sourceName será igual a destinationName , então use os nomes das variáveis corretas/final agora, incluindo tempo, latitude, longitude e, às vezes, profundidade ou altitude se as variáveis com essa informação serão incluídas.
Quase sempre haverá uma variável chamada tempo que registra o tempo que a observação foi feita. Pode ser dataType String com unidades adequadas para tempos de cadeia (por exemplo, yyyy-MM-dd 'T'HH: mm: ss. SSSZ) ou dados Tipo duplo com unidades adequadas para tempos numéricos (por exemplo, segundos desde 1970-01T00:00:00Z, ou algum outro tempo de base) .
Três das colunas (geralmente os três últimos) deve ser timestamp, autor, comando.
A coluna timestamp será usada pelo EDDTableFromHttpGet para adicionar um timestamp indicando quando adicionou uma determinada linha de dados ao arquivo de dados. Terá dataType duplo e unidades segundos desde 1970-01T00:00Z.
A coluna do autor com dataType String será usada para gravar qual autor autorizado forneceu os dados desta linha. Autorizados são especificados por http Atributo global do GetKeys . Embora as chaves sejam especificadas como autor\_key e estão na URL "request" nesse formulário, somente a parte do autor é salva no arquivo de dados.
A coluna de comando com o byte dataType indicará se os dados nesta linha são uma inserção (0) ou uma exclusão (1) .

Executar GenerateDatasets Xml e dizer-lhe
1. O tipo de conjunto de dados é EDDTableFromHttpGet
2. O diretório é (para este exemplo) /dados/teste Vai!
3. O arquivo de amostra é (para este exemplo) /data/testGet/startup .json Eu...
4. O http GetRequired Variáveis são (para este exemplo) stationID , tempo Veja a descrição de http GetRequiredVariables abaixo.
5. Se os dados forem recolhidos a cada 5 minutos, o http GetDirectoryStructure para este exemplo é stationID /2 meses . Veja a descrição de http Introdução abaixo.
6. O http Beco

Adicionar a saída (o pedaço de datasets.xml para o conjunto de dados) para datasets.xml . 4. Editar datasets.xml chunk para este conjunto de dados para torná-lo correto e completo. Notavelmente, substituir todos os ??? com conteúdo correto. 5. Pelo<configuração fileTableInMemory>:

Defina isso para true se o conjunto de dados geralmente vai obter frequentes .insert e / ou .delete solicitações (por exemplo, mais frequentemente do que uma vez a cada 10 segundos) . Isso ajuda EDDTableFromHttpGet responder mais rápido a pedidos .insert e/ou .delete. Se você definir isso para true, EDDTableFromHttpGet ainda salvará a tabela de arquivos e informações relacionadas ao disco periodicamente (como necessário, aproximadamente a cada 5 segundos) .
Defina isso para falso (o padrão) se o conjunto de dados geralmente receber solicitações infrequentes .insert e/ou .delete (por exemplo, menos de uma vez a cada 10 segundos) .

Nota: É possível usar<cacheFromUrl> e configurações relacionadas em datasets.xml para EDDTable De Http Obtenha conjuntos de dados como uma maneira de fazer e manter uma cópia local de um conjunto de dados EDDTableFromHttpGet remoto em outro ERDDAP . No entanto, neste caso, este conjunto de dados local rejeitará quaisquer pedidos .insert e .delete.

Usando EDDTable DeHttpGet Datasets

Os autores podem fazer "pedidos" que inserir dados ou excluir dados do conjunto de dados .
Depois que os dados reais foram inseridos no conjunto de dados, você pode e deve excluir o arquivo de dados de amostra original.
Os usuários podem solicitar dados do conjunto de dados como eles fazem para qualquer outro conjunto de dados EDDTable em ERDDAP . Se a solicitação não incluir uma restrição na coluna timestamp, então a solicitação recebe dados da versão atual do conjunto de dados (o arquivo de log após o processamento de todos os comandos de inserção e exclusão e re-sorting pelo http GetRequiredVariables) .
Os usuários também podem fazer solicitações específicas para EDDTableFromHttpGet conjuntos de dados:
- Se o pedido incluir um<ou<= restrição da coluna timestamp, então ERDDAP™ processa linhas do arquivo de log até o timestamp especificado. Com efeito, isso exclui temporariamente todas as alterações feitas no conjunto de dados desde o valor do timestamp. Para mais informações, consulte Versão .
- Se o pedido incluir um >, >=, ou = restrição da coluna timestamp, por exemplo, &timestamp<=0, então ERDDAP™ retorna os dados dos arquivos de dados como é, sem processar os comandos de inserção e exclusão.
No futuro, imaginamos que as ferramentas serão construídas (por nós? Por ti?) para trabalhar com esses conjuntos de dados. Por exemplo, pode haver um script que lê os arquivos de registro bruto, aplica uma equação de calibração diferente e gera/atualiza um conjunto de dados diferente com essa informação derivada. Note que o script pode obter os dados originais através de uma solicitação para ERDDAP™ (que recebe os dados no formato de arquivo que é mais fácil para o script trabalhar com) e gerar/update o novo conjunto de dados via .insert "requests" para ERDDAP . O script não precisa de acesso direto aos arquivos de dados; ele pode estar no computador de qualquer autor autorizado.

InformaÃ§Ãμes detalhadas sobre EDDTableFromHttpGet

Os tópicos são:

Não mudes de configuração!
CRUDÊNCIA
InvalidRequests
Velocidade
Robusto.
Confiabilidade do sistema
Versão
"E o HTTP PUT e DELETE?!"
Notas
Graças a CHORDS para a ideia básica.

Aqui está a informação detalhada:

Não mudes de configuração!

Uma vez que o conjunto de dados foi criado e você adicionou dados a ele:

Não adicione ou remova nenhum dataVariable S.
Não mudes o sourceName ou destinationName do dataVariable S.
Não altere os dados Tipo de dataVariable S. Mas você pode mudar o dataVariable Os metadados.
Não mudes o http GetRequired Variáveis atributo global.
Não mudes o http Atributo global GetDirectoryStructure.

Se você precisar alterar qualquer uma dessas coisas, faça um novo conjunto de dados e transfira todos os dados para o novo conjunto de dados.

CRUDÊNCIA

Na ciência da computação, os quatro comandos fundamentais para trabalhar com um conjunto de dados são CREATE, LER, UPDATE, DELETE (CRUDÊNCIA) . SQL, a linguagem para trabalhar com bases de dados relacionais, tem o equivalente em INSERT, SELECT, UPDATE e DELETE. Em EDDTable FromHttpGet,

.insert é uma combinação de CREATE e UPDATE.
.delete é DELETE.
O sistema regular para solicitar subconjuntos de dados é LER.

Assim, EDDTableFromHttpGet suporta todos os comandos fundamentais para trabalhar com um conjunto de dados.

.insert ou .delete solicitações sem erros retornará o código de status HTTP=200 e um objeto JSON, por exemplo,

    {
    "status":"success",
    "nRowsReceived":1,
    "stringTimestamp":"2018-03-26T15:34:05.552Z",
    "numericTimestamp":1.522078445552E9
    }

Os dois valores de timestamp referem-se ao mesmo milissegundo, que é o milissegundo que será armazenado na variável timestamp para as linhas de dados que foram inseridos ou excluídos. ERDDAP™ Não mudará o nome e a formatação desses pares de valores-chave no futuro. ERDDAP™ pode adicionar pares de valores-chave adicionais ao objeto JSON no futuro.

InvalidRequests

As solicitações .insert ou .delete inválidas retornarão um código de status de erro HTTP diferente do status=200 e nenhuma alteração será feita para o conjunto de dados. Isso inclui solicitações com informações incorretas do autor, nomes variáveis incorretas, diferentes comprimentos de matriz para variáveis diferentes, variáveis requeridas ausentes, valores variáveis variáveis ausentes, etc. Se a solicitação envolve mais de um arquivo de dados, é possível que parte do pedido seja bem-sucedida e a parte falhará. No entanto, isso não deve ser um problema se o sensor que envia a solicitação tratar qualquer falha como uma falha completa. Por exemplo, se você contar ERDDAP™ para inserir (ou excluir) os mesmos dados duas vezes seguidas, o pior caso é que essas informações são armazenadas duas vezes, fechar juntos no arquivo de log. É difícil ver como isso pode causar problemas.

Velocidade de HttpGet

Para pedidos .insert ou .delete (não contando http sobre a cabeça) , ballpark figura a velocidade de .insert ou .delete são 1ms por .insert com 1 linha de dados 2ms por .insert com 10 linhas de dados em arrays ( \[ \] )
3ms por .insert com 100 linhas de dados em arrays ( \[ \] )
13ms por .insert com 1000 linhas de dados em arrays ( \[ \] )
Claramente arrays são a chave para alta taxa de transferência . Sem arrays, será desafiador para .insert ou .delete mais de 8 linhas de dados por segundo de um autor remoto (por causa de toda a sobrecarga da rede) . Com arrays, será fácil .insert ou .delete mais de 1000 linhas de dados por segundo de um sensor remoto.

Com grandes quantidades de dados por solicitação, você vai atingir o limite de Tomcat para o comprimento máximo de consulta (padrão é 8KB?) , mas isso pode ser aumentado editando a configuração maxHttpHeaderSize em seu Toca a brincar. /conf/server.xml's HTTP/1.1 Entrada do conector.

Quando ERDDAP™ lê os dados CSV JSON Lines (log) arquivos, há uma pequena penalidade de tempo em comparação com a leitura de arquivos de dados binários. Sentimos que esta pena de tempo quando a leitura era um preço razoável para pagar pela velocidade e robustez do sistema ao escrever dados (que é de primeira importância) .

SSD

Para maior velocidade, usar um Unidade de Estado Sólido (SSD) para armazenar os dados. Eles têm um tempo de acesso de arquivo muito mais rápido (<0.1ms) do que discos rígidos (3 - 12 ms) . Eles também têm uma taxa de transferência de dados mais rápida (200 - 2500 MB/s) do que discos rígidos (~ 200 MB/s) . O seu custo diminuiu consideravelmente nos últimos anos. Embora o SSD inicial tenha tido problemas após um grande número de gravações em um determinado bloco, este problema agora é muito reduzido. Se você apenas usar o SSD para escrever os dados uma vez, leia-o muitas vezes, mesmo um SSD de nível de consumidor (que é consideravelmente menos caro do que um SSD de nível empresarial) deve durar muito tempo.

Robusto.

Tentámos tornar este sistema tão fácil de trabalhar e tão robusto quanto possível.

O sistema é projetado para ter vários fios (por exemplo, o sensor, um script QC automatizado e um humano) simultaneamente trabalhando no mesmo conjunto de dados e até mesmo no mesmo arquivo. Muito disso é possível usando uma abordagem de arquivo de log para armazenar os dados e usando um tipo de arquivo muito simples, JSON Linhas arquivos CSV Para armazenar os dados.
Outra enorme vantagem para JSON Lines CSV é que se um arquivo alguma vez se tornar corrompido (por exemplo, inválido por causa de um erro em uma linha) , é fácil abrir o arquivo em um editor de texto e corrigir o problema.
Outra vantagem é, se houver um erro em uma linha em um arquivo, o sistema ainda pode ler todos os dados em linhas antes e depois da linha de erro. E o sistema ainda pode registrar informações adicionais .insert e .delete.
Uma enorme vantagem de usar arquivos padrão acessíveis a administrador (em comparação com um banco de dados relacional ou Cassandra ou outro software) : Não há outro software que tem de ser mantido e que tem de ser executado para armazenar ou recuperar dados. E é fácil fazer backup de arquivos padrão a qualquer momento e de forma incremental porque os dados estão em pedaços (depois de um tempo, apenas o arquivo atual para cada estação estará mudando) . Em contraste, é preciso esforço considerável e sistema para baixo tempo para fazer arquivos de backup externos de bancos de dados e de Cassandra.

Confiabilidade do sistema

É razoável esperar um servidor com ERDDAP™ para ter 99,9% de tempo de atividade - isso é cerca de 9 horas de inatividade por ano (Embora, você pode usar isso em uma noite ruim!) . Se você é diligente e sortudo, você pode ter 99,99% de tempo de atividade (53 minutos de inatividade por ano) , uma vez que apenas alguns reinícios para atualizações levará tanto tempo. Você teria que tomar medidas extremas (um servidor de backup separado, fonte de alimentação ininterrupta, ar condicionado de backup, pessoal 24x7x365 para monitorar o site, etc.) ter uma chance magra em 99,999% de tempo de atividade (5.25 minutos de inatividade por ano) . Mesmo assim, é extremamente improvável que você alcançará 99,999% de tempo de atividade (ou mesmo 99.99%) porque os problemas estão muitas vezes fora de seu controle. Por exemplo, o Amazon Web Service e o Google oferecem serviços web surpreendentemente confiáveis, mas grandes seções delas são, por vezes, desativadas por horas.

Enfrenta, todos querem ERDDAP™ ter 100% de tempo de atividade, ou pelo menos o "seis noves" vaunted (99.9999% de tempo de atividade é igual a 32 segundos de tempo de inatividade por ano) , mas não há como você vai conseguir, não importa quanto tempo, esforço e dinheiro você gasta.

Mas... ERDDAP™ o tempo de atividade não é o objetivo real aqui. O objetivo é construir uma confiança sistema Um que não perde dados. Este é um problema solvável.

A solução é: construir tolerância a falhas no software de computador que está enviando os dados para ERDDAP . Especificamente, esse software deve manter uma fila de dados esperando para ir para ERDDAP . Quando os dados são adicionados à fila, o software deve verificar a resposta de ERDDAP . Se a resposta não incluir dados recebidos. Sem erros., então o software deve deixar os dados na fila. Quando mais dados são gerados e adicionados à fila, o software deve tentar novamente .inserir os dados na fila (talvez com o \[ \] sistema) . Vai ter sucesso ou falhar. Se falhar, tentará novamente mais tarde. Se você escrever o software para funcionar desta forma e se o software está preparado para fila alguns dias de dados, você realmente tem uma boa chance de carregar 100% dos dados do sensor para ERDDAP . E você terá feito isso sem ir para grande esforço ou despesa.

\[ Fundo: Não pensámos nisto. É assim que as redes de computador conseguem confiabilidade. As redes de computadores são inerentemente não confiáveis. Então, quando você transfere um arquivo de um computador para outro, o software de envio sabe / espera que alguns pacotes podem ser perdidos. Se não receber um reconhecimento adequado para um determinado pacote do receptor, ele reenvia o pacote perdido. Com esta abordagem, o software de remetente e receptor relativamente simples pode construir um sistema de transferência de arquivos confiável em cima de uma rede não confiável. \]

Por que JSON Lines CSV arquivos?!

EDDTableDeHttpGet usa JSON Linhas arquivos CSV . para armazenar os dados. As razões são:

A principal razão é: A simplicidade dos arquivos CSV JSON Lines oferece uma maneira rápida, fácil e confiável para permitir que vários threads escrevam para um determinado arquivo (por exemplo, sincronizando no nome do arquivo) .
Se um arquivo CSV JSON Lines alguma vez foi corrompido (por exemplo, inválido por causa de um erro em uma linha) , EDDTableFromHttpGet ainda pode ler todos os dados em todas as linhas antes e depois da linha de erro. E o sistema .insert e .delete pode continuar a adicionar novos dados ao arquivo de dados.
Porque os arquivos CSV JSON Lines são arquivos ASCII, se um arquivo já se tornou corrompido, seria fácil corrigir (em um editor de texto) .
JSON Lines CSV suporta Cordas Unicode.
JSON Lines CSV suporta strings de comprimento variável (não limitado a algum comprimento máximo) .
JSON Lines CSV suporta inteiros de 64 bits (longos) .
A natureza formal e sintaxe extra de JSON Lines CSV (vs Oldschool CSV) fornece alguma garantia extra de que uma determinada linha não foi corrompida.

Nós inicialmente tentamos usar .nc 3 arquivos com uma dimensão ilimitada. No entanto, houve problemas:

O principal problema foi: Não há nenhuma maneira confiável de permitir que vários threads escrevam para um .nc 3 arquivo, mesmo que os threads cooperam fazendo as escritas de forma sincronizada.
Se um .nc 3 arquivo fica corrompido, o sistema .insert e .delete não pode continuar a usar o arquivo.
Porque... .nc 3 arquivos são binários, se um arquivo fica corrompido (que eles fazem por causa do problema multi-threading) são extremamente difíceis ou impossíveis de corrigir. Não há ferramentas para ajudar com o reparo.
CF não tem como especificar a codificação de strings, então não há nenhuma maneira oficial de suportar Unicode, por exemplo, a codificação UTF-8. Tentamos obter CF para apoiar um atributo \_Encoding, mas não conseguimos fazer nenhum progresso. ( Unidata , para o seu crédito, suporta o atributo \_Encoding.)
.nc 3 arquivos suportam apenas strings de comprimento fixo. Novamente, tentamos obter CF e Unidata para suportar strings de comprimento variável, mas foram incapazes de fazer qualquer progresso.
.nc 3 arquivos não suportam uma maneira fácil de distinguir variáveis de caracteres individuais de variáveis String. Novamente, tentamos obter CF e Unidata apoiar um sistema para distinguir estes dois tipos de dados, mas não foram capazes de fazer qualquer progresso.
.nc 3 arquivos suportam apenas caracteres de 8 bits com uma codificação não especificada. Novamente, tentamos obter CF e Unidata para apoiar um sistema para especificar a codificação, mas não foram capazes de fazer qualquer progresso.
.nc 3 arquivos não suportam inteiros de 64 bits (longos) . Novamente, tentamos obter CF e Unidata para apoiar um sistema por muito tempo, mas não foram capazes de fazer qualquer progresso.

Versão

Porque EDDTable De Http Obter lojas um log de todas as mudanças no conjunto de dados com o timestamp e o autor de cada mudança, ele pode rapidamente recriar esse conjunto de dados a partir de qualquer ponto no tempo. Em certo sentido, há uma versão para qualquer ponto no tempo. Se o pedido de dados de um usuário incluir um timestamp<= restrição, por exemplo, &timestamp<=2016-06-23T16:32:22.128Z (ou qualquer ponto de hora) , mas nenhuma restrição de autor ou comando, ERDDAP™ responderá à solicitação gerando primeiramente uma versão do conjunto de dados a partir desse ponto no tempo. Então, ERDDAP™ aplica outras restrições do usuário, como com qualquer outra solicitação de dados ERDDAP . EDDTableFromHttpGet é configurado para que este processo seja muito rápido e eficiente, mesmo para conjuntos de dados muito grandes.

Da mesma forma, um usuário pode descobrir quando o conjunto de dados foi atualizado pela última vez solicitando ...?timestamp &timestamp=max (vezes) E distintiva ()

E para qualquer solicitação de dados, para qualquer versão do conjunto de dados, os usuários podem ver qual autor fez quais mudanças e quando eles fizeram.

Este sistema de versão permite Ciência reprodutiva porque qualquer pessoa, a qualquer momento, pode solicitar dados da versão do conjunto de dados a qualquer momento do tempo. Esta versão fina não é possível com qualquer outro sistema que conhecemos. O mecanismo subjacente é muito eficiente, pois nenhum espaço de armazenamento extra é necessário, e a sobrecarga de processamento é verdadeiramente mínima.

Nem todo mundo tem necessidade deste tipo de versão fina, mas é extremamente útil, talvez necessário, no contexto de uma grande organização de gerenciamento de dados (por exemplo, OOOI, Earth Cube, Data One e NOAA NCEI) onde um conjunto de dados pode ter vários autores (por exemplo, o sensor, um script QC automatizado e um editor humano) .

\[ História: A necessidade deste tipo de versão surgiu primeiro para mim (Bob.) ao ler sobre e discutir OOI em 2008. Na época, a OOI tinha um sistema cúmplice, lento e ineficiente para a versão baseada no Git. Git é ótimo para o que foi projetado, mas não para isso. Em 2008, enquanto em uma discussão da OOI, eu criei um extenso sistema alternativo-para-OOI eficiente para gerenciamento de dados, incluindo muitas das características que eu adicionei a ERDDAP™ desde então, e incluindo este sistema de versão. Naquela época e desde então, o OOI estava comprometido com seu sistema de versão e não estava interessado em alternativas. Em 2016, outros aspectos deste plano caíram e eu comecei a implementá-lo. Porque houve muitas interrupções para trabalhar em outros projetos, eu não terminei até 2018. Mesmo agora, eu não estou ciente de qualquer outro sistema de dados científicos que oferece acesso tão rápido e fácil a uma versão dos dados a partir de qualquer ponto no tempo, para frequentemente mudar conjuntos de dados. Sistemas de arquivos simples não oferecem isso. As bases de dados relacionais não. A Cassandra não. \]

HTTPS Colocar e excluir

"E o HTTPS PUT e DELETE?!"
Protocolo de Transferência de Hipertexto (HTTP) é a base da World Wide Web e a razão pela qual as URLs da página web começam com "http://"ou "https://". HTTPS é HTTP com uma camada de segurança adicional. Todos os dias, navegadores, scripts e programas de computador fazem bilhões de HTTP (S) GERAIS solicitações para obter informações de fontes remotas. HTTP (S) também inclui outros Verbos , nomeadamente PUT (para empurrar dados para o servidor) e DELETE (para DELETE dados do servidor) . Sim, PUT e DELETE são a maneira adequada de inserir dados e excluir dados de, um conjunto de dados via HTTP (S) . GET é suportado por cada pedaço de software que pode trabalhar com HTTP (S) . O GET é muito fácil de trabalhar. Todo mundo já sabe como trabalhar com GET e muitos sabem como usar POST (que pode ser usado essencialmente da mesma forma que GET) , então fizemos EDDTableFromHttpGet trabalho com GET e POST. Muito poucas pessoas (mesmo alguns programadores de computador) já trabalhou com PUT e DELETE. PUT e DELETE são geralmente suportados apenas por linguagens de computador, então usá-los requer um programa hábil. Então PUT e DELETE são geralmente uma abordagem muito mais cômoda, dado a forma como as ferramentas evoluíram.

Notas de HttpGet

Notas
Não. dataVariable pode ter dataType=char. Use dataType=String em vez disso. Se você realmente precisa dataType=char, e-mail Chris. John em noaaa.gov .

Obrigado.

Graças a CHORDS para a ideia básica.
A ideia básica para EDDTableFromHttpGet (ou seja, usando um HTTP GET solicitar para adicionar dados a um conjunto de dados) é da UCAR (NCAR's?) Serviços de dados em tempo real (ESCORDOS) projeto. O formato para os parâmetros na solicitação (repetido Nome=valor , separados por &'s) é o mesmo formato padrão que é usado por formulários HTML em páginas web. É uma ideia simples e brilhante e ainda mais, porque ele malha tão perfeitamente com ERDDAP O sistema existente para lidar com dados tabulares. A ideia é óbvia em retrospectiva, mas eu (Bob.) Não pensei nisso. EDDTable FromHttp Get usa essa ideia básica, combinada com nossas ideias de como implementá-la, para fazer um sistema ERDDAP™ para carregar dados. Além da ideia básica de usar GET para empurrar dados para o sistema, a implementação EDDTableFromHttpGet é totalmente diferente e totalmente independente de CHORDS e tem características diferentes (por exemplo, arquivos de log, chunking de dados, sistema de segurança diferente, suporte CRUD, dados reproduzíveis) . A nossa exposição ao CHORDS era apenas um webinar. Nós não olhamos para o código deles ou lemos sobre o projeto deles porque imediatamente sabíamos queríamos implementar o sistema de uma forma diferente. Mas estamos gratos a eles pela ideia básica. A referência completa a CHORDS é Daniels, M. D., Kerkez, B., Chandrasekar, V., Graves, S., Stamps, D. S., Martin, C., Dye, M., Gooch, R., Bartos, M., Jones, J., Keiser, K. (2014) . Serviços de dados em tempo real para as Geociências (ESCORDOS) software. UCAR/NCAR -- Laboratório de Observação da Terra. https://doi.org/10.5065/d6v1236q

Tabela de EDD Hyrax Arquivos

Tabela de EDD Hyrax Arquivos (desprecaída) agrega arquivos de dados com várias variáveis, cada uma com uma ou mais dimensões compartilhadas (por exemplo, tempo, altitude (ou profundidade) , latitude, longitude) e servido por um Hyrax OPeNDAP servidor .

Este tipo de conjunto de dados é DEPRIEDADE . A solução mais recente e mais geral é usar cache Opção FromUrl para EDDTable Dos quartos (ou uma variante) , que faz uma cópia local dos arquivos remotos e serve os dados dos arquivos locais. O<opção cacheFromUrl> pode ser usado com qualquer tipo de arquivo de dados tabular. **
Se você não pode fazer isso funcionar por algum motivo, e-mail Chris. John em noaaa.gov . Se não houver reclamações antes de 2020, este tipo de conjunto de dados pode ser removido. **
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.
Na maioria dos casos, cada arquivo tem vários valores para a esquerda (Primeiro) dimensão, por exemplo, tempo.
Os arquivos muitas vezes (mas não precisa) tem um único valor para as outras dimensões (por exemplo, altitude (ou profundidade) , latitude, longitude) .
Os arquivos podem ter variáveis de caracteres com uma dimensão adicional (por exemplo, nCharacters) .
Hyrax Os servidores podem ser identificados pelo "/dods-bin/nph-dods/" ou "/opendap/" na URL.
Esta tela de classe-scrapes o Hyrax páginas web com as listas de arquivos em cada diretório. Por causa disso, é muito específico para o formato atual de Hyrax páginas da web. Vamos tentar ajustar ERDDAP™ rapidamente se/quando futuras versões de Hyrax alterar como os arquivos estão listados.
O<configuração fileDir> é ignorada. Uma vez que esta classe baixa e faz uma cópia local de cada arquivo de dados remoto, ERDDAP™ força o arquivo Dir para ser Diretriz de grande porte /cópia / * datasetID * - Não.
Para< sourceUrl >, use a URL do diretório base do conjunto de dados no Hyrax servidor, por exemplo, < sourceUrl >http://edac-dap.northerngulfinstitute.org/dods-bin/nph-dods/WCOS/nmsp/wcos/</ sourceUrl > (mas colocá-lo em uma linha) (Desculpe, esse servidor não está mais disponível) . O sourceUrl página da web geralmente tem " OPeNDAP Índice de Servidor \[ Google - Agências de publicidade \] " no topo.
Uma vez que esta classe sempre baixa e faz uma cópia local de cada arquivo de dados remoto, você nunca deve envolver esse conjunto de dados em EDDTableCopy .
Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.
Veja os exemplos 1D, 2D, 3D e 4D para EDDTable De NcFiles .

EDDTable De InvalidCRAFiles

EDDTable De InvalidCRAFiles agrega dados de NetCDF (v3 ou v4) .nc arquivos que usam um específico, inválido, variante do CF DSG Contiguous Ragged Array (CRA) arquivos. Embora ERDDAP™ suporta este tipo de arquivo, é um tipo de arquivo inválido que ninguém deve começar a usar. Grupos que atualmente usam este tipo de arquivo são fortemente encorajados a usar ERDDAP™ para gerar arquivos CF DSG CRA válidos e parar de usar esses arquivos.

Detalhes: Esses arquivos têm múltiplas variáveis row\_size, cada uma com um atributo sample\_dimension. Os arquivos são arquivos não-CF-padrão porque a amostra múltipla (obs) dimensões devem ser decodificadas e relacionadas uns com os outros com esta regra adicional e promessa que não faz parte da especificação CF DSG: "você pode associar um dado, por exemplo, valor de temperatura (dimensão temp\_obs) com um determinado valor de profundidade (z\_obs dimensão, a dimensão com mais valores) , porque: a linha de temperatura\_size (para um dado elenco) será 0 ou igual à linha de profundidade correspondente\_size (para aquele elenco) (Essa é a regra.) . Então, se a linha de temperatura\_size não é 0, então os valores de temperatura n para esse elenco se relacionam diretamente com os valores de profundidade n para aquele elenco (Essa é a promessa) "

Outro problema com esses arquivos: a variável Principal\_Investigator row\_size não tem um atributo sample\_dimensional e não segue a regra acima.

Arquivos de amostra para este tipo de conjunto de dados podem ser encontrados emhttps://data.nodc.noaa.gov/thredds/catalog/ncei/wod/ \[ 2020-10-21 Este servidor não está mais disponível de forma confiável \] .

Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

A primeira coisa GerarDatasets Xml faz para este tipo de conjunto de dados depois de responder às perguntas é imprimir a estrutura tipo ncdump do arquivo de amostra. Então, se você digitar algumas respostas patetas para o primeiro loop através de GerarDatasets Xml, pelo menos será capaz de ver se ERDDAP™ pode ler o arquivo e ver quais dimensões e variáveis estão no arquivo. Então você pode dar melhores respostas para o segundo loop através de GerarDatasetsXml.

EDDTable FromJsonlCSVFiles

EDDTable FromJsonlCSVFiles agrega dados de JSON Linhas arquivos CSV . Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

Como jsonlines.org diz, este formato é "Melhor do que CSV" (e legalmente, como funcionário federal, não posso concordar ou discordar com eles - como é louco?) . CSV nunca foi formalmente definido e é dificultado pela bagagem histórica relacionada à sua conexão com os programas de planilha original. JSON Lines CSV, em comparação, é totalmente definido e beneficia de sua conexão com o padrão JSON amplamente utilizado, que por sua vez se beneficia de sua conexão com Java Script e Java . Notavelmente, há suporte completo para inteiros longos e para caracteres Unicode em strings, e uma maneira clara de incluir outros caracteres especiais (notavelmente guias e novas linhas) dentro de cordas.

Este formato é particularmente bom para conjuntos de dados onde você precisa periodicamente anexar linhas adicionais ao final de um determinado arquivo de dados. Por essa razão e outros (ver acima) , EDDTable FromHttpGet usa arquivos CSV Json Lines para armazenamento de dados.

Os arquivos de entrada são considerados UTF-8 codificados. No entanto, dado o \u Dddd formato para codificação de caracteres especiais (e.g., \u20ac é a codificação para o caracter Euro) , você tem a opção de escrever os arquivos para que eles contenham apenas caracteres ASCII de 7 bits usando \u Dddd para codificar todos os caracteres acima #127.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

Quando: ERDDAP™ lê JSON Linhas arquivos de dados CSV, se encontrar um erro em uma determinada linha (por exemplo, número incorreto de itens) , registra uma mensagem de aviso ("WARNING: Linha má (S) de dados" ... com uma lista das linhas ruins em linhas subseqüentes) ao arquivo log.txt e, em seguida, continua a ler o resto do arquivo de dados. Assim, é sua responsabilidade olhar periodicamente (ou escrever um script para fazê-lo) para essa mensagem no log. txt para que você possa corrigir os problemas nos arquivos de dados. ERDDAP™ é configurado desta forma para que os usuários possam continuar a ler todos os dados válidos disponíveis, mesmo que algumas linhas do arquivo tenham falhas.

EDDTable FromMultidimNcFiles

EDDTable FromMultidimNcFiles agrega dados de NetCDF (v3 ou v4) .nc (ou .nc ml ) arquivos com várias variáveis, cada uma com uma ou mais dimensões compartilhadas. Os arquivos podem ter variáveis de caráter com ou sem uma dimensão adicional (por exemplo, STRING14) . Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

Se os arquivos são variantes CF DSG multidimensionais, use este tipo de conjunto de dados em vez de EDDTable FromNcCFFiles .
Para novos conjuntos de dados tabulares .nc arquivos, use esta opção antes de experimentar o mais velho EDDTable De NcFiles . Algumas vantagens desta classe são:
- Esta classe pode ler mais variáveis de uma variedade mais ampla de estruturas de arquivos. Se você especificar DimensionsCSV (uma lista separada por vírgula de nomes de dimensão) em Gerar conjuntos de dados Xml (ou<dimensõesCSV> no datasets.xml info para um desses conjuntos de dados), então ERDDAP™ só lerá variáveis nos arquivos de origem que usam algumas ou todas essas dimensões, além de todas as variáveis escalares. Se uma dimensão está em um grupo, você deve especificar seu fullName, por exemplo, " grupoNome/dimensãoNome ".
- Esta classe muitas vezes pode rejeitar arquivos muito rapidamente se eles não corresponder a restrições de um pedido. Então a leitura de dados de grandes coleções muitas vezes vai muito mais rápido.
- Esta classe lida com variáveis de caridade verdadeiras (variáveis não padrão) corretamente.
- Esta classe pode aparar variáveis String quando o criador não usou Netcdf-java's writeStrings (que acrescenta char #0 para marcar o fim da cadeia) .
- Esta classe é melhor em lidar com arquivos individuais que não possuem certas variáveis ou dimensões.
- Esta classe pode remover blocos de linhas com valores ausentes conforme especificado para CF Geometrias de amostragem discretas (DSG) Arquivos multidimensionais Incompletos
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

Grupo... Gerar conjuntos de dados Xml vai pedir um "Grupo". Você pode entrar "" para tê-lo pesquisar qualquer / todos os grupos, " alguns Grupo "ou " algunsGrupo / alguns SubGrupo " para que ele procure um grupo específico, ou " \[ raiz raiz \] " para que ele procure apenas o grupo raiz. A string "Group" torna-se<grupo> no datasets.xml info para o conjunto de dados (embora " \[ raiz raiz \] Torna-se ") .

DimensõesCSV -- Gerar conjuntos de dados Xml vai pedir uma string "DimensionsCSV". Esta é uma lista de nomes de fontes separados por vírgulas de um conjunto de dimensões. Gerar conjuntos de dados Xml só lerá variáveis de dados na amostra .nc arquivos que usam algumas ou todas essas dimensões (e nenhuma outra dimensão) , além de todas as variáveis escalares no arquivo, e fazer o conjunto de dados dessas variáveis de dados. Se uma dimensão está em um grupo, você deve especificar seu fullName, por exemplo, " grupoNome/dimensãoNome ". Se você não especificar nada (uma string vazia) , Gerar conjuntos de dados Xml procurará as variáveis com a maioria das dimensões, na teoria de que serão as mais interessantes, mas pode haver momentos em que você vai querer fazer um conjunto de dados de algum outro grupo de variáveis de dados que usa algum outro grupo de dimensões. Se você apenas especificar um nome de dimensão que não existe (por exemplo, NO\_MATCH) , ERDDAP™ vai apenas encontrar todas as variáveis escalares. A string "DimensionsCSV" torna-se<dimensõesCSV> no datasets.xml info para o conjunto de dados.

Medidas de tratamento

Há uma categoria de inválido .nc arquivos (porque eles não seguem as regras do CF) que têm múltiplas dimensões (por exemplo, lat, lon, time) quando eles deveriam ter usado apenas uma dimensão (por exemplo, tempo) Por exemplo:

    dimensions:
        time = UNLIMITED ; // (1437 currently)
        depth = 10;
        lat = 1437 ;
        lon = 1437 ;
    variables:
        double time(time) ;
        double lat(lat) ;
        double lon(lon) ;
        float temperature(time, depth) ;

EDDTableFromMultidimNcFiles tem uma característica especial para lidar com esses arquivos: se você adicionar o atributo global "treatDimensionsAs" aos conjuntos de dados globais addAttributes Você pode dizer ERDDAP™ para tratar certas dimensões (e.g., lat e lon) como se fossem outra dimensão (por exemplo, tempo) . O valor do atributo deve ser uma lista separada por vírgula especificando as dimensões "de" e, em seguida, a dimensão "para", por exemplo, lon, tempo
Então... ERDDAP™ lerá o arquivo como se fosse:

    dimensions:
        time = UNLIMITED ; // (1437 currently)
        depth = 10;
    variables:
        double time(time) ;
        double lat(time) ;
        double lon(time) ;
        float temperature(time, depth) ;

Naturalmente, o tamanho atual de cada uma das dimensões na lista deve ser o mesmo; caso contrário, ERDDAP™ irá tratar o arquivo como um "Bad File".

Note que esses arquivos são inválidos porque eles não seguem as regras do CF. Mesmo assim. ERDDAP™ pode lê-los, recomendamos fortemente que você não crie arquivos como este porque outras ferramentas de software baseadas em CF não serão capazes de lê-los corretamente. Se você já tem tais arquivos, recomendamos fortemente substituí-los por arquivos válidos o mais rápido possível.

EDDTable De NcFiles

EDDTable De NcFiles agrega dados de NetCDF (v3 ou v4) .nc (ou .nc ml ) arquivos e Zarr arquivos (a partir da versão 2.25) com várias variáveis, cada uma com uma dimensão compartilhada (por exemplo, tempo) ou mais de uma dimensão compartilhada (por exemplo, tempo, altitude (ou profundidade) , latitude, longitude) . Os arquivos devem ter os mesmos nomes de dimensão. Um determinado arquivo pode ter vários valores para cada uma das dimensões e os valores podem ser diferentes em arquivos de origem diferentes. Os arquivos podem ter variáveis de caracteres com uma dimensão adicional (por exemplo, STRING14) . Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

Os arquivos Zarr têm um comportamento ligeiramente diferente e exigem o fileNameRegex ou o pathRegex para incluir "zarr".

Se o .nc arquivos usar um dos CF Geometrias de amostragem discretas (DSG) formatos de arquivo, tente usar EDDTable FromNcCFFiles antes de tentar isto.
Para novos conjuntos de dados tabulares .nc arquivos, tente o mais novo EDDTable FromMultidimNcFiles primeiro.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

Exemplo 1D: Os arquivos 1D são um pouco diferentes de arquivos 2D, 3D, 4D, ....
- Você pode ter um conjunto de .nc arquivos de dados onde cada arquivo tem um mês de dados de um buoy drifting.
- Cada arquivo terá 1 dimensão, por exemplo, tempo (tamanho = \[ muitos \] ) .
- Cada arquivo terá uma ou mais variáveis 1D que usam essa dimensão, por exemplo, tempo, longitude, latitude, temperatura do ar, ....
- Cada arquivo pode ter variáveis de caráter 2D, por exemplo, com dimensões (tempo, nCharacters) .
Exemplo 2D:
- Você pode ter um conjunto de .nc arquivos de dados onde cada arquivo tem um mês de dados de um buoy drifting.
- Cada arquivo terá 2 dimensões, por exemplo, tempo (tamanho = \[ muitos \] ) e id (tamanho = 1) .
- Cada arquivo terá 2 variáveis 1D com os mesmos nomes que as dimensões e usando a mesma dimensão, por exemplo, tempo (Tempo) Id (I) . Essas variáveis 1D devem ser incluídas na lista< dataVariable > está no XML do conjunto de dados.
- Cada arquivo terá uma ou mais variáveis 2D, por exemplo, longitude, latitude, temperatura do ar, temperatura da água, ...
- Cada arquivo pode ter variáveis de caráter 3D, por exemplo, com dimensões (tempo, trácticas, n) .
Exemplo 3D:
- Você pode ter um conjunto de .nc arquivos de dados onde cada arquivo tem um mês de dados de um buoy estacionário.
- Cada arquivo terá 3 dimensões, por exemplo, tempo (tamanho = \[ muitos \] ) , (tamanho = 1) e lon (tamanho = 1) .
- Cada arquivo terá 3 variáveis 1D com os mesmos nomes que as dimensões e usando a mesma dimensão, por exemplo, tempo (Tempo) , (Não.) lon (lon) . Essas variáveis 1D devem ser incluídas na lista< dataVariable > está no XML do conjunto de dados.
- Cada arquivo terá uma ou mais variáveis 3D, por exemplo, temperatura do ar, temperatura da água, ...
- Cada arquivo pode ter variáveis de caracteres 4D, por exemplo, com dimensões (tempo, mais tarde, mais tarde,) .
- O nome do arquivo pode ter o nome do buoy no nome do arquivo.
Exemplo 4D:
- Você pode ter um conjunto de .nc arquivos de dados onde cada arquivo tem um mês de dados de uma estação. Em cada momento, a estação leva leituras em uma série de profundidades.
- Cada arquivo terá 4 dimensões, por exemplo, tempo (tamanho = \[ muitos \] ) , profundidade (tamanho = \[ muitos \] ) , (tamanho = 1) e lon (tamanho = 1) .
- Cada arquivo terá 4 variáveis 1D com os mesmos nomes que as dimensões e usando a mesma dimensão, por exemplo, tempo (Tempo) , profundidade (profundidade) , (Não.) lon (lon) . Essas variáveis 1D devem ser incluídas na lista< dataVariable > está no XML do conjunto de dados.
- Cada arquivo terá uma ou mais variáveis 4D, por exemplo, temperatura do ar, temperatura da água, ...
- Cada arquivo pode ter variáveis de caracteres 5D, por exemplo, com dimensões (tempo, aprofundado, galo, nCharacters) .
- O nome do arquivo pode ter o nome do buoy no nome do arquivo.

EDDTable FromNcCFFiles

EDDTable FromNcCFFiles agrega dados agregados de NetCDF (v3 ou v4) .nc (ou .nc ml ) arquivos que usam um dos formatos de arquivo especificados pelo CF Geometrias de amostragem discretas (DSG) convenções. Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

Para arquivos usando uma das variantes multidimensionais CF DSG, use EDDTable FromMultidimNcFiles Em vez disso.

As convenções CF DSG definem dezenas de formatos de arquivo e incluem inúmeras pequenas variações. Esta classe lida com todas as variações de que estamos cientes, mas podemos ter perdido uma (ou mais) . Então, se esta classe não puder ler dados de seus arquivos CF DSG, por favor alcance para suporte adicional .

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

EDDTable De NccsvFiles

EDDTable De NccsvFiles agrega dados de NCCSV Arquivos ASCII .csv. Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.

Quando: ERDDAP™ lê arquivos de dados NCCSV, se ele encontrar um erro em uma determinada linha (por exemplo, número incorreto de itens) , registra uma mensagem de aviso ("WARNING: Linha má (S) de dados" ... com uma lista das linhas ruins em linhas subseqüentes) ao arquivo log.txt e, em seguida, continua a ler o resto do arquivo de dados. Assim, é sua responsabilidade olhar periodicamente (ou escrever um script para fazê-lo) para essa mensagem no log. txt para que você possa corrigir os problemas nos arquivos de dados. ERDDAP™ é configurado desta forma para que os usuários possam continuar a ler todos os dados válidos disponíveis, mesmo que algumas linhas do arquivo tenham falhas.

EDDTable FromNOS

EDDTable FromNOS (DEPRIEDADE) lida com dados de um NOAA NÃO fonte, que usa SOAP+XML para pedidos e respostas. É muito específico NOAA O XML do NOS. Veja a amostra EDDTableFromNOS conjunto de dados em conjuntos de dados2.xml.

EDDTable FromOBIS

EDDTable FromOBIS lida com dados de um Sistema de Informação Biogeográfica do Oceano (OBIS) servidor (foihttp://www.iobis.org ) . É possível que não haja servidores mais ativos que utilizem este tipo de sistema de servidor OBIS agora desatualizado.

Os servidores OBIS esperam uma solicitação XML e retornam uma resposta XML.
Porque todos os servidores OBIS servem as mesmas variáveis da mesma maneira (foihttp://iobis.org/tech/provider/questions) , você não precisa especificar muito para configurar um conjunto de dados OBIS ERDDAP .
Você deve incluir um " creator\_email " atributo no global addAttributes , uma vez que essa informação é usada dentro da licença. Um endereço de e-mail adequado pode ser encontrado lendo a resposta XML do sourceURL.
Você pode ou não conseguir obter o atributo global [< subsetVariables > (#subsetvariables) para trabalhar com um determinado servidor OBIS. Se você tentar, tente apenas uma variável (por exemplo, ScientificName ou Genus) .

EDDTable FromOBIS esqueleto XML

<dataset type="EDDTableFromOBIS" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <sourceCode>...</sourceCode>
        
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <-- All ...SourceMinimum and Maximum tags are OPTIONAL -->
      <longitudeSourceMinimum>...</longitudeSourceMinimum>
      <longitudeSourceMaximum>...</longitudeSourceMaximum>
      <latitudeSourceMinimum>...</latitudeSourceMinimum>
      <latitudeSourceMaximum>...</latitudeSourceMaximum>
      <altitudeSourceMinimum>...</altitudeSourceMinimum>
      <altitudeSourceMaximum>...</altitudeSourceMaximum>
      <-- For timeSource... tags, use yyyy-MM-dd'T'HH:mm:ssZ format. -->
      <timeSourceMinimum>...</timeSourceMinimum>
      <timeSourceMaximum>...</timeSourceMaximum>
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
        
      <addAttributes>...</addAttributes> 
  </dataset>

EDDTable FromParquetFiles

EDDTable FromParquetFiles lida com dados de Parquete . Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.

Parquet é projetado para comprimir muito eficientemente, por isso pode lhe dar tamanhos de arquivos menores do que outros formatos.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.
Quando: ERDDAP™ lê arquivos de dados do Parquet, se ele encontrar um erro em uma determinada linha (por exemplo, número incorreto de itens) , registra uma mensagem de aviso ("WARNING: Linha má (S) de dados" ... com uma lista das linhas ruins em linhas subseqüentes) ao arquivo log.txt e, em seguida, continua a ler o resto do arquivo de dados. Assim, é sua responsabilidade olhar periodicamente (ou escrever um script para fazê-lo) para essa mensagem no log. txt para que você possa corrigir os problemas nos arquivos de dados. ERDDAP™ é configurado desta forma para que os usuários possam continuar a ler todos os dados válidos disponíveis, mesmo que algumas linhas do arquivo tenham falhas.

Tabela de EDD SOS

**Tabela de EDD SOS ** lida com dados de um Serviço de Observação do Sensor (SWE/ SOS ) servidor.

Este tipo de conjunto de dados agrega dados de um grupo de estações que são todas atendidas por um SOS servidor.
Todas as estações servem o mesmo conjunto de variáveis (embora a fonte para cada estação não tenha que servir todas as variáveis) .
SOS servidores esperam um pedido XML e retornam uma resposta XML.
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo. Não é fácil gerar o conjunto de dados XML para SOS conjuntos de dados à mão. Para encontrar as informações necessárias, você deve visitar sourceUrl +"? - Sim. SOS - O quê? GetCapabilities " em um navegador; olhar para o XML; fazer um pedido GetObservation à mão; e olhar para a resposta XML à solicitação.
Com a adição ocasional de novos tipos de SOS servidores e mudanças nos servidores antigos, está ficando mais difícil para ERDDAP™ para detectar automaticamente o tipo de servidor a partir das respostas do servidor. O uso de<soserverType> (com um valor de IOOS\_NDBC, IOOS\_NOS, OOSTethys , ou QUEM) está agora firmemente recomendado. Se você tiver problemas com qualquer conjunto de dados deste tipo, tente reiniciar GerrateDatasets Xml para o SOS servidor. Gerar Conjuntos de dados Xml vai deixar você experimentar o diferente<sosServerType> opções até você encontrar o certo para um determinado servidor.
SOS visão geral:
SWE (Activação Web do sensor) e SOS (Serviço de Observação do Sensor) são Normas OpenGIS® . Esse site tem os documentos padrão.
O OGC Web Services Especificação comum ver 1.1.0 ( OGC 06-121r3) cobre a construção de consultas GET e POST (ver seção 7.2.3 e seção 9) .
Se você enviar um pedido getCapabilities xml para um SOS servidor ( sourceUrl - Sim. SOS - O quê? GetCapabilities ") , você obtém um resultado xml com uma lista de estações e o observado Propriedades para as quais eles têm dados.
Um observadopropriedade é uma referência URI formal a uma propriedade. Por exemplo, urn:ogc:phenomenon:longitude:wgs84 ouhttps://mmisw.org/ont/cf/parameter/sea\_water\_temperature
Uma propriedade observada não é uma variável.
Mais de uma variável pode ter o mesmo observado Propriedade (por exemplo, dentroTemp e fora Temp pode ambos ter observado Propriedadehttps://mmisw.org/ont/cf/parameter/air\_temperature) .
Se você enviar um pedido xml getObservation para um SOS servidor, você obtém um resultado xml com descrições de nomes de campo na resposta, unidades de campo e os dados. Os nomes de campo incluirão longitude, latitude, profundidade (talvez) , e tempo.
Cada um dataVariable para uma tabela EDDDe SOS deve incluir um atributo "observedProperty", que identifica a propriedade observada que deve ser solicitada do servidor para obter essa variável. Muitas vezes, várias dataVariable s irá listar o mesmo composto observadopropriedade.
O dataType para cada dataVariable pode não ser especificado pelo servidor. Se assim for, você deve olhar para as respostas de dados XML do servidor e atribuir apropriado [<dataType>s] (# Datatype #) no ERDDAP™ conjunto de dados dataVariable definições.
(No momento de escrever isso) alguns SOS servidores respondem a pedidos de getObservation para mais de um observado Propriedade apenas retornando resultados para o primeiro dosPropriedades observadas. (Nenhuma mensagem de erro!) Consulte o pedido do parâmetro construtor ObservadoPropertiesSeparadamente.
Tabela de EDD SOS adiciona automaticamente

station\_id, longitude, latitude
para os atributos globais do conjunto de dados quando o conjunto de dados é criado.
SOS servidores geralmente expressam unidades com o UCUM sistema. A maioria ERDDAP™ servidores expressam unidades com o UDUNITS sistema. Se você precisar converter entre os dois sistemas, você pode usar ERDDAP Serviço web para converter unidades UCUM para / UDUNITS .

Tabela de EDD SOS esqueleto XML

<dataset type="EDDTableFromSOS" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <sosServerType>...</sosServerType> 
      <responseFormat>...</responseFormat> 
      <stationIdSourceName>...</stationIdSourceName> 
      <longitudeSourceName>...</longitudeSourceName>
      <latitudeSourceName>...</latitudeSourceName>
      <altitudeSourceName>...</altitudeSourceName>
      <altitudeSourceMinimum>...</altitudeSourceMinimum> 
      <altitudeSourceMaximum>...</altitudeSourceMaximum> 
      <altitudeMetersPerSourceUnit>...</altitudeMetersPerSourceUnit>
      <timeSourceName>...</timeSourceName>
      <timeSourceFormat>...</timeSourceFormat>
        
      <observationOfferingIdRegex>...</observationOfferingIdRegex>
        
      <requestObservedPropertiesSeparately>true|false(default)
        </requestObservedPropertiesSeparately>
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <addAttributes>...</addAttributes> 
      <dataVariable>...</dataVariable> 
  </dataset>

EDDTable FromThreddsFiles

EDDTable FromThreddsFiles (desprecaída) agrega arquivos de dados com várias variáveis, cada uma com uma ou mais dimensões compartilhadas (por exemplo, tempo, altitude (ou profundidade) , latitude, longitude) e servido por um TERCEIROS OPeNDAP servidor .

Este tipo de conjunto de dados é DEPRIEDADE . A solução mais recente e mais geral é usar cache Opção FromUrl para EDDTable Dos quartos (ou uma variante) , que faz uma cópia local dos arquivos remotos e serve os dados dos arquivos locais. O<opção cacheFromUrl> pode ser usado com qualquer tipo de arquivo de dados tabular de qualquer fonte baseada na web que publica uma lista de arquivos como diretório. **
Se você não pode fazer isso funcionar por algum motivo, e-mail Chris. John em noaaa.gov . Se não houver reclamações antes de 2020, este tipo de conjunto de dados pode ser removido. **
Recomendamos fortemente usar o Gerar conjuntos de dados Programa Xml para fazer um rascunho áspero do datasets.xml chunk para este conjunto de dados. Você pode então editar isso para afiná-lo.
Na maioria dos casos, cada arquivo tem vários valores para a esquerda (Primeiro) dimensão, por exemplo, tempo.
Os arquivos muitas vezes (mas não precisa) tem um único valor para as outras dimensões (por exemplo, altitude (ou profundidade) , latitude, longitude) .
Os arquivos podem ter variáveis de caracteres com uma dimensão adicional (por exemplo, nCharacters) .
Os servidores THREDDS podem ser identificados pelos "/thredds/" nas URLs. Por exemplo,

    https://www.ncei.noaa.gov/thredds/catalog/uv/6h\\_strs\\_agg/catalog.html

Os servidores THREDDS têm catálogos em vários lugares. Esta classe REQUIRES que a URL inclui "/thredds/catalog/". Você geralmente pode encontrar essa variável iniciando em um navegador no catálogo raiz e clicando no subcatálogo desejado.
Esta classe lê os arquivos catalog.xml servidos por THREDDS com as listas de<catálogoRefs> (referências a arquivos sub catálogo.xml adicionais) e<dataset> (arquivos de dados) .
O<configuração fileDir> é ignorada. Uma vez que esta classe baixa e faz uma cópia local de cada arquivo de dados remoto, ERDDAP™ força o arquivo Dir para ser Diretriz de grande porte /cópia / * datasetID * - Não.
Para< sourceUrl >, use a URL do arquivo catálogo.xml para o conjunto de dados no servidor THREDDS, por exemplo: para esta URL que pode ser usada em um navegador da web, https://data.nodc.noaa.gov/thredds/catalog/nmsp/wcos/catalog.html \[ 2020-10-21 Este servidor não está mais disponível de forma confiável. \] , uso< sourceUrl >https://data.nodc.noaa.gov/thredds/catalog/nmsp/wcos/catalog.xml</ sourceUrl > (mas colocá-lo em uma linha) .
Uma vez que esta classe sempre baixa e faz uma cópia local de cada arquivo de dados remoto, você nunca deve envolver esse conjunto de dados em EDDTableCopy .
Este tipo de conjunto de dados suporta uma tag especial OPTIONAL, raramente utilizada,<especialModelo> modo </specialMode> que pode ser usado para especificar que regras especiais e codificadas devem ser usadas para determinar quais arquivos devem ser baixados do servidor. Atualmente, o único válido modo é SAMOS que é usado com conjuntos de dados dehttps://tds.coaps.fsu.edu/thredds/catalog/samospara baixar apenas os arquivos com o último número de versão.
Veja a superclasse desta classe. Tabela EDD dos arquivos , para obter informações sobre como esta classe funciona e como usá-la.
Veja os exemplos 1D, 2D, 3D e 4D para EDDTable De NcFiles .

Tabela de EDD WFS Arquivos

Tabela de EDD WFS Arquivos (DEPRIEDADE) faz uma cópia local de todos os dados de uma ArcGIS MapaServer WFS servidor para que os dados possam então ser re-servados rapidamente para ERDDAP™ usuários.

Você precisa especificar um especialmente formatado sourceUrl atributo global para contar ERDDAP™ como solicitar informações de recursos do servidor. Por favor, use este exemplo como um modelo:

    <att name="sourceUrl">http://*someUrl/dir1/dir2*/MapServer/WFSServer?request=GetFeature&amp;service=WFS&amp;typename=aasg:BoreholeTemperature&amp;format=&quot;text/xml;%20subType=gml/3.1.1/profiles/gmlsf/1.0.0/0"</att>  

(mas coloque tudo em uma linha)

Você precisa adicionar um atributo global especial para contar ERDDAP™ como identificar os nomes dos pedaços de dados que devem ser baixados. Isso provavelmente funcionará para todos EDDTableDe WFS Conjuntos de dados de arquivos:

    <att name="rowElementXPath">/wfs:FeatureCollection/gml:featureMember</att>

Uma vez que esta classe sempre baixa e faz uma cópia local de cada arquivo de dados remoto, você nunca deve envolver esse conjunto de dados em EDDTableCopy .
Veja a superclasse desta classe. Tabela EDD dos arquivos , para informações adicionais sobre como esta classe funciona e como usá-la.

EDDTable agregados

EDDTable agregados pode fazer um conjunto de dados EDDTable de um grupo de conjuntos de dados EDDTable "criança".

Aqui estão alguns usos para EDDTableAggregateRows:
- Você pode fazer um conjunto de dados EDDTableAggregateRows de dois tipos diferentes de arquivos ou fontes de dados, por exemplo, um conjunto de dados com dados até o final do mês passado armazenado em .nc Arquivos CF e um conjunto de dados com dados para o mês atual armazenados em um banco de dados relacional.
- Você pode fazer um conjunto de dados EDDTableAggregateRows para lidar com uma mudança de arquivos de origem (por exemplo, o formato de tempo alterado, ou um nome variável alterado, ou dados Tipo/ scale\_factor / add\_offset alterado) . Neste caso, uma criança obteria dados de arquivos feitos antes da mudança e a outra criança obteria dados de arquivos feitos após a mudança. Este uso de EDDTableAggregateRows é uma alternativa para usar NcML ou NCO . A menos que haja uma característica distintiva nos nomes de arquivos (para que você possa usar<fileNameRegex> para determinar qual arquivo pertence a qual conjunto de dados da criança), você provavelmente precisa armazenar os arquivos para os dois conjuntos de dados da criança em diretórios diferentes.
- Você pode fazer um conjunto de dados EDDTableAggregateRows que tem um subconjunto compartilhado de variáveis de um ou mais conjuntos de dados semelhantes, mas diferentes, por exemplo, um conjunto de dados que faz um conjunto de dados do perfil da combinação de um conjunto de dados do perfil, um conjunto de dados do TimeSeriesProfile e um conjunto de dados do TrajectoryProfile (que têm algumas variáveis diferentes e algumas variáveis em comum -- nesse caso você terá que fazer variantes especiais para os conjuntos de dados da criança, com apenas as variáveis em comum) .
- Você pode ter vários conjuntos de dados autônomos, cada um com o mesmo tipo de dados, mas de uma estação diferente. Você pode deixar esses conjuntos de dados intactos, mas também criar um conjunto de dados EDDTableAggregateRows que tem dados de todas as estações - cada um dos conjuntos de dados da criança pode ser um simples EDDTable FromErddap , que aponta para um dos conjuntos de dados da estação existente. Se você fizer isso, dê a cada um dos conjuntos de dados EDDTableFromErddap um diferente datasetID do que os conjuntos de dados autônomos originais, por exemplo, anexando "Criança" ao original datasetID .
Cada criança<dataset> especificado deve ser um conjunto de dados completo, como se fosse um conjunto de dados autônomo. Cada um deve ter o mesmo dataVariable S , na mesma ordem, com o mesmo destinationName S , dados Tipos , missing\_value S , \_Valores de arquivo e unidades . Os metadados para cada variável para o conjunto de dados EDDTableAggregateRows vem de variáveis no primeiro conjunto de dados da criança, mas EDDTableAggregateRows atualizará o actual\_range metadados para ser o intervalo real para todas as crianças.
Recomendação: Obtenha cada um dos conjuntos de dados da criança trabalhando como conjuntos de dados autônomos. Então tente fazer o conjunto de dados EDDTableAggregateRows cortando e colando o datasets.xml para cada um no novo agregado EDDTableA Conjunto de dados de linhas.
Dataset Default Ordenar Ordem -- A ordem dos conjuntos de dados da criança determina a ordem de classificação padrão geral dos resultados. Naturalmente, os usuários podem solicitar uma ordem de classificação diferente para um determinado conjunto de resultados por afinação & orderBy (" lista de variáveis separadas por vírgula ") até ao fim da sua consulta.
O "fonte" global global Atributos para o EDDTableAggregateRows é o global combinadoAttributes do primeiro conjunto de dados da criança. O agregado EDDTable Linhas podem ter um global< addAttributes > fornecer atributos globais adicionais ou substituir os atributos globais de origem.

EDDTable agregado Linhas esqueleto XML

<dataset type="EDDTableAggregateRows" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaFiles>true|false(default)</accessibleViaFiles>
        
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <updateEveryNMillis>...</updateEveryNMillis> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <dataset>...</dataset> 
  </dataset>

EDDTableCopy

EDDTableCopy pode fazer uma cópia local de muitos tipos de conjuntos de dados EDDTable e, em seguida, reserve os dados rapidamente a partir da cópia local.

EDDTableCopy (e para dados de grade, EDDGrid Entendido. ) é muito fácil de usar e muito eficaz solução para alguns dos maiores problemas com a utilização de dados de fontes de dados remotas:
- Acessar dados de uma fonte de dados remota pode ser lento.
  - Eles podem ser lentos porque eles são inerentemente lentos (por exemplo, um tipo ineficiente de servidor) ,
  - porque eles são esmagados por muitos pedidos,
  - ou porque seu servidor ou o servidor remoto é de largura de banda limitada.
- O conjunto de dados remoto é por vezes indisponível (novamente, por uma variedade de razões) .
- Basear-se em uma fonte para os dados não escala bem (por exemplo, quando muitos usuários e muitos ERDDAP s utilizá-lo) .
Como Funciona -- O EDDTableCopy resolve esses problemas automaticamente fazendo e mantendo uma cópia local dos dados e servindo dados da cópia local. ERDDAP™ pode servir os dados da cópia local muito, muito rapidamente. E fazer e usar uma cópia local alivia o fardo no servidor remoto. E a cópia local é um backup do original, que é útil no caso de algo acontecer ao original.

EDDTableCopy vs<cacheDeUrl>

<cacheFromUrl> é uma alternativa para EDDTableCopy. Eles funcionam de forma diferente.

Tabela de EDD Copie trabalhos solicitando pedaços de dados de um serviço remoto e armazenando esses pedaços em arquivos locais. Assim, o EDDTableCopy é útil em alguns casos em que os dados são acessíveis através de um serviço remoto.
Não.<cacheDe Url>] (#cachefromurl) transfere os arquivos existentes listados em um site remoto.<cacheFromUrl> é mais fácil de usar e mais confiável, pois pode facilmente dizer quando há um novo arquivo de dados remoto ou quando um arquivo de dados remoto mudou e, portanto, precisa ser baixado.

Se houver situações em que EDDTableCopy ou<cacheDeUrl> poderia ser usado, use<cacheDeUrl> porque é mais fácil e confiável.

<ExtratoDestinação Nomes >

Tabela de EDD Copiar faz a cópia local dos dados solicitando pedaços de dados do conjunto de dados remoto. Tabela de EDD Copiar determina quais pedaços a solicitar solicitando o &distinct () valores para o<extractDestinationNomes> (especificado no datasets.xml , veja abaixo) , que são os nomes de destino separados por espaço de variáveis no conjunto de dados remoto. Por exemplo,

    <extractDestinationNames>drifter profile</extractDestinationNames>

pode produzir combinações de valores distintos de drifter=tig17,profile=1017, drifter=tig17,profile=1095, ... drifter=une12,profile=1223, drifter=une12,profile=1251, ....

Em situações em que uma coluna (por exemplo, perfil) pode ser tudo o que é necessário para identificar exclusivamente um grupo de linhas de dados, se houver um número muito grande de, por exemplo, perfis, pode ser útil também especificar um extrato adicional Destino Nome (por exemplo,) que serve para subdividir os perfis. Isso leva a menos arquivos de dados em um determinado diretório, o que pode levar a um acesso mais rápido.

Arquivos locais

Cada pedaço de dados é armazenado em um separado NetCDF arquivo em um subdiretório de Diretriz de grande porte /cópia / * datasetID * / (como especificado em setup.xml ) . Há um nível subdiretório para todos, mas o último extractoDestinationName. Por exemplo, dados para tig17+1017, seriam armazenados em Diretriz de grande porte /copy/sampleDataset/tig17/1017 .nc . Por exemplo, dados para une12+1251, seriam armazenados em Diretriz de grande porte /copy/sampleDataset/une12/1251 .nc . Diretório e nomes de arquivos criados a partir de valores de dados são modificados para torná-los seguros de nome de arquivo (por exemplo, os espaços são substituídos por "x20") - Isto não afecta os dados.

Novos dados

Cada vez Tabela EDD A cópia é recarregada, verifica o conjunto de dados remoto para ver quais pedaços distintos estão disponíveis. Se o arquivo para um pedaço de dados já não existir, um pedido para obter o pedaço é adicionado a uma fila. ERDDAP 's taskThread processa todas as solicitações filadas para pedaços de dados, one-by-one. Você pode ver estatísticas para a atividade do Thread na tarefa Página de status e no Relatório diário . (Sim. ERDDAP™ poderia atribuir várias tarefas para este processo, mas isso usaria muitos da largura de banda, memória e tempo de CPU da fonte de dados remotos, e muitos dos locais ERDDAP 's largura de banda, memória e tempo de CPU, nenhum dos quais é uma boa ideia.)

NOTA: A primeira vez que um EDDTableCopy é carregado, (se tudo correr bem) lotes de pedidos de pedaços de dados serão adicionados à fila do taskThread, mas nenhum arquivo de dados local será criado. Assim, o construtor vai falhar, mas tarefaThread continuará a trabalhar e criar arquivos locais. Se tudo correr bem, a tarefaThread fará alguns arquivos de dados locais e a próxima tentativa de recarregar o conjunto de dados (em ~ 15 minutos) terá sucesso, mas inicialmente com uma quantidade muito limitada de dados.

AVISO: Se o conjunto de dados remoto é grande e/ou o servidor remoto é lento (É esse o problema, não é?!) , levará muito tempo para fazer uma cópia local completa. Em alguns casos, o tempo necessário será inaceitável. Por exemplo, transmitindo 1 TB de dados sobre uma linha T1 (0.15 GB/s) leva pelo menos 60 dias, em condições ideais. Além disso, ele usa muita largura de banda, memória e tempo de CPU nos computadores remotos e locais. A solução é enviar um disco rígido para o administrador do conjunto de dados remotos para que ele / ele pode fazer uma cópia do conjunto de dados e enviar o disco rígido de volta para você. Use esses dados como ponto de partida e o EDDTableCopy irá adicionar dados a ele. (É assim que o Serviço de Nuvem EC2 da Amazon costumava lidar com o problema, mesmo que seu sistema tenha muita largura de banda.)

AVISO: Se uma dada combinação de valores desaparece de um conjunto de dados remoto, o EDDTableCopy NÃO exclui o arquivo copiado local. Se você quiser, você pode excluí-lo sozinho.

Copiação de tabela<checkSourceData >

O datasets.xml para este conjunto de dados pode ter uma tag opcional

    <checkSourceData>true</checkSourceData>

O valor padrão é verdadeiro. Se / quando você configurá-lo para false, o conjunto de dados nunca irá verificar o conjunto de dados de origem para ver se há dados adicionais disponíveis.

Uso recomendado

Criar<dataset> entrada (o tipo nativo, não EDDTableCopy) para a fonte de dados remota. Faça funcionar corretamente, incluindo todos os metadados desejados.
Se for muito lento, adicione o código XML para envolvê-lo em um conjunto de dados EDDTableCopy.
- Use um diferente datasetID (talvez mudando o datasetID do velho datasetID ligeiramente) .
- Entendido.<acessível Para>,<reloadEveryNMinutes> e<onChange> do XML do EDDTable remoto para o XML do EDDTableCopy. (Seus valores para a matéria EDDTableCopy; seus valores para o conjunto de dados interno tornam-se irrelevantes.)
- Criar<extractDestinationNames> tag (ver acima) .
- <orderExtractBy> é uma lista separada do espaço OPTIONAL de nomes variáveis de destino no conjunto de dados remoto. Quando cada pedaço de dados é baixado do servidor remoto, o pedaço será classificado por essas variáveis (pela primeira variável, então pela segunda variável se a primeira variável estiver ligada, ...) . Em alguns casos, ERDDAP™ será capaz de extrair dados mais rapidamente dos arquivos de dados locais se a primeira variável na lista for uma variável numérica ( "time" conta como uma variável numérica) . Mas escolha essas variáveis de uma forma adequada para o conjunto de dados.
ERDDAP™ fará e manterá uma cópia local dos dados.

WARNING: EDDTableCopy assume que os valores de dados para cada pedaço nunca mudam. Se / quando eles fizerem, você precisa excluir manualmente os arquivos de chunk em Diretriz de grande porte /cópia / * datasetID * / que mudou e bandeira o conjunto de dados a ser recarregado para que os pedaços excluídos serão substituídos. Se você tiver uma assinatura por e-mail para o conjunto de dados, você receberá dois e-mails: um quando o conjunto de dados primeiro recarrega e começa a copiar os dados, e outro quando o conjunto de dados carrega novamente (automaticamente) e detecta os novos arquivos de dados locais.
Alterar os metadados - ... Se você precisar mudar qualquer addAttributes ou alterar a ordem das variáveis associadas ao conjunto de dados de origem:
1. Alterar addAttributes para o conjunto de dados de origem datasets.xml , como necessário.
2. Apague um dos arquivos copiados.
3. Definir um bandeira para recarregar o conjunto de dados imediatamente. Se você usar uma bandeira e tiver uma assinatura por e-mail para o conjunto de dados, você receberá dois e-mails: um quando o conjunto de dados primeiro recarrega e começa a copiar os dados, e outro quando o conjunto de dados carregar novamente (automaticamente) e detecta os novos arquivos de dados locais.
4. O arquivo excluído será regenerado com os novos metadados. Se o conjunto de dados de origem estiver indisponível, o conjunto de dados EDDTableCopy obterá metadados do arquivo regenerado, uma vez que é o arquivo mais jovem.
EDDGrid Entendido. é muito semelhante ao EDDTableCopy, mas trabalha com conjuntos de dados gradeados.

EDDTableCopy esqueleto XML

<dataset type="EDDTableCopy" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> 
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> 
      <accessibleViaFiles>true|false(default)</accessibleViaFiles>
        
      <reloadEveryNMinutes>...</reloadEveryNMinutes> 
      <defaultDataQuery>...</defaultDataQuery> 
      <defaultGraphQuery>...</defaultGraphQuery> 
      <addVariablesWhere>...</addVariablesWhere> 
      <fgdcFile>...</fgdcFile> 
      <iso19115File>...</iso19115File> 
      <onChange>...</onChange> 
      <extractDestinationNames>...</extractDestinationNames> 
      <orderExtractBy>...</orderExtractBy> 
      <fileTableInMemory>...</fileTableInMemory> 
      <checkSourceData>...</checkSourceData> 
      <dataset>...</dataset> 
  </dataset>

- Não.

Detalhes

Aqui estão descrições detalhadas de tags e atributos comuns.

<angularDegreeUnits >

Não. ** <angularDegreeUnits> ** ] (Unidades de grau angular) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml que contém uma lista separada por vírgula de cadeias de unidades que ERDDAP™ deve tratar como unidades de graus angulares. Se uma variável tiver uma dessas unidades, tabledap ' orderByMean filtro irá calcular a média de uma forma especial, em seguida, relatar a média como um valor de -180 a 180. Ver ERDDAP 's EDStatic.java arquivo de código fonte para a lista padrão atual. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

<angularDegreeTrueUnits >

Não. ** <angular GrauTrueUnits> ** ] (#angulardegreetrueunits) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml que contém uma lista separada por vírgula de cadeias de unidades que ERDDAP™ deve tratar como unidades verdadeiras angulares graus. Se uma variável tiver uma dessas unidades, tabledap ' orderByMean filtro irá calcular a média de uma forma especial, em seguida, relatar a média como um valor de 0 a 360. Ver ERDDAP 's EDStatic.java arquivo de origem para a lista padrão atual. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

<CommonStandardNames >

Não. ** <Nomes padrão comuns> ** ] (#commonstandardnames) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml para especificar uma lista separada por vírgula de comum Nomes padrão CF . Por exemplo,

    <commonStandardNames>air\\_pressure, ..., wind\\_to\\_direction</commonStandardNames>  

Esta lista é usada em DataProviderForm3.html como uma conveniência para os usuários. Se você quiser fornecer essas informações em datasets.xml , começar por copiar a lista padrão atual em<DEFAULT\_commonStandardNames> em ERDDAP ' \[ Toca a brincar. \] /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util/messages.xml ficheiro.

<cacheMinutes >

Não. ** <cacheMinuts> ** ] (#cacheminutes) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml para especificar a idade (em minutos) em que os arquivos no cache devem ser excluídos (default=60) . Por exemplo,

    <cacheMinutes>60</cacheMinutes>

Em geral, apenas arquivos de imagem (porque as mesmas imagens são frequentemente solicitadas repetidamente) e .nc arquivos (porque eles devem ser totalmente criados antes de enviar para o usuário) estão em cache. Embora possa parecer que um pedido deve sempre retornar a mesma resposta, isso não é verdade. Por exemplo, um tabledap pedido que inclui tempo> alguns Tempo irá mudar quando novos dados chegam para o conjunto de dados. E um pedido de griddap que inclui \[ último \] para a dimensão do tempo vai mudar quando novos dados chegam para o conjunto de dados. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira . Antes ERDDAP™ v2.00, isso foi especificado no setup.xml, que ainda é permitido mas desencorajado.

<cacheClearMinutes >

Não. ** <cacheClearMinuts> ** ] (#cacheclearminutes) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml para especificar a frequência para verificar arquivos em cache e remover antigos (em minutos) (default=15) . Por exemplo,

    <cacheClearMinutes>15</cacheClearMinutes>

Quando o servidor terminar de manusear uma solicitação, verificará há quanto tempo o último cache limpo foi. Se foi há muito tempo, ele vai filar uma tarefa no TaskThread para limpar o cache. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira . Isso pode ser especificado em setup.xml, mas isso é desencorajado.

<converterInterpolateRequestCSVExample >

Não. ** <converterInterpolateRequestCSVExample> ** ] (#convertinterpolaterequestcsvexample) é uma tag OPTIONAL dentro de uma<erddapDatasets> Identificação datasets.xml \[ começar com ERDDAP™ v2.10 \] que contém um exemplo que será mostrado na página do conversor de interpolar. O valor padrão é: jplMU RSS T41/analysed\_ sst /Bilinear/4 .

<converterInterpolateDatasetIDVariableList >

Não. ** <converterInterpolateDatasetIDVariableList> ** ] (#convertinterpolatedatasetidvariablelist) é uma tag OPTIONAL dentro de uma<erddapDatasets> Identificação datasets.xml \[ começar com ERDDAP™ v2.10 \] que contém uma lista CSV de datasetID /variável Exemplos de nomes que serão usados como sugestões pela página do conversor de interpolar. O valor padrão é: jplMU RSS T41/analysed\_ sst .

<converterToPublicSourceUrl >

Não. ** <convertToPublicSourceUrl> ** ] (# Convert to publicsourceurl) é uma tag OPTIONAL dentro de uma<erddapDatasets> Identificação datasets.xml que contém um atributo "de" e "a" que especifica como converter um local correspondente sourceUrl (geralmente um número IP) em um público sourceUrl (um nome de domínio) "de" deve ter a forma " \[ Alguma coisa? \] // \[ Alguma coisa? \] - Sim. Pode haver 0 ou mais dessas tags. Para mais informações consulte [< sourceUrl > (#sourceurl) . Por exemplo,

    <convertToPublicSourceUrl from="https://192.168.31.18/" to="https://oceanwatch.pfeg.noaa.gov/" />  

vai causar um local correspondente sourceUrl (comohttps://192.168.31.18/thredds/dodsC/satellite/BA/ssta/5day)
em um público sourceUrl (https://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/BA/ssta/5day) . Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

Mas, por razões de segurança e razões relacionadas com o sistema de assinatura, Não use este saco!
Em vez disso, use sempre o nome de domínio público no< sourceUrl > tag e usar /etc/hosts tabela em seu servidor para converter nomes de domínio locais em números IP sem usar um servidor DNS. Você pode testar se um nome de domínio é convertido corretamente em um número IP usando: ping alguns.domínio.nome

data:image/png;base64,

Quando um usuário solicita um .htmlTable resposta de ERDDAP™ , se os dados em uma célula String contém dados:image/png;base64, seguido por uma imagem .png codificada base64, ERDDAP™ irá exibir um ícone (assim que o usuário pode ver a imagem se eles pairar sobre ele) e botões para salvar o texto ou a imagem para a área de transferência. Este recurso foi adicionado em ERDDAP™ v2.19 de Marco Alba.

drawLandMask

** drawLandMask ** especifica a configuração padrão que controla quando e como a máscara de terra deve ser desenhada quando ERDDAP™ desenha um mapa. Pode ser especificado em três lugares diferentes em datasets.xml (listado de menor para maior prioridade) :

Se drawLandMask é especificado dentro<erddapDatasets> (não conectado com qualquer conjunto de dados específico) , então ele especifica o valor padrão de drawLandMask para todas as variáveis em todos os conjuntos de dados. Por exemplo,

    <drawLandMask>under</drawLandMask>

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP leituras datasets.xml . Se esta tag não estiver presente, o valor padrão subjacente está abaixo. 2. Se drawLandMask é especificado como um atributo global de um dado conjunto de dados, então ele especifica o valor padrão de drawLandMask para todas as variáveis nesse conjunto de dados, substituindo qualquer configuração de prioridade menor. Por exemplo,

    <att name="drawLandMask">under</att>

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ recarrega esse conjunto de dados. 3. Se drawLandMask é especificado como atributo de uma variável em um dado conjunto de dados, então especifica o valor padrão de drawLandMask para essa variável nesse conjunto de dados, substituindo qualquer configuração de prioridade menor. Por exemplo,

    <att name="drawLandMask">under</att>

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ recarrega esse conjunto de dados.

Um usuário pode substituir o padrão (onde quer que seja especificado) selecionando um valor para "Mata de terra de rasteja" a partir de uma lista suspensa na página de web Make A Graph do conjunto de dados, ou incluindo &.land= valor na URL que solicita um mapa de ERDDAP .

Em todas as situações, existem 4 valores possíveis para o atributo:

"sob" desenha a máscara de terra antes de desenhar dados no mapa. Para conjuntos de dados gradeados, a terra aparece como uma cor cinza clara constante. Para conjuntos de dados tabulares, "em" mostra dados de topografia sobre terra e oceanos.
"over"... Para conjuntos de dados gradeados, "over" desenha a máscara de terra após ele desenha dados sobre mapas para que ele mascarará qualquer dado sobre a terra. Para conjuntos de dados tabulares, "over" mostra a bathymetry do oceano e um cinza claro constante onde há terra, ambos desenhados sob os dados.
"fora" apenas desenha o contorno da máscara de terra, limites políticos, lagos e rios.
"fora" não saca nada.

<emailDiagnosticsToErdData>

Não. ** <e-mailDiagnosticsToErdData> ** ] (#emaildiagnosticstoerddata) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml . O valor da tag pode ser verdadeiro (o padrão) ou falso. Se for verdade, ERDDAP™ vai enviar o rastreamento de pilha para Chris. John no Noaa. Vamos! (o ERDDAP™ equipe de desenvolvimento) . Isso deve ser seguro, pois nenhuma informação confidencial (por exemplo, o pedido) está incluído no e-mail. Isso deve tornar possível pegar qualquer erro obscuro e totalmente inesperado que leve a NullPointerExceptions. Caso contrário, o usuário vê as exceções, mas o ERDDAP™ equipe de desenvolvimento não (então não sabemos que há um problema que precisa ser corrigido) .

<graphBackgroundColor >

Não. ** <gráficoCorpo de fundo> ** ] (#graphbackgroundcolor) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml para especificar a cor de fundo padrão em gráficos. Isso afeta quase todos os gráficos. Há algumas situações não afetadas. A cor é especificada como um valor hexadecimal de 8 dígitos na forma 0xAARRGGBB, onde AA, RR, GG e BB são os componentes opacidade, vermelho, verde e azul, respectivamente. "0x" é sensível a casos, mas os dígitos hexadecimais não são sensíveis a casos. Por exemplo, um totalmente opaco (?) cor verde-azul com vermelho=22, verde=88, azul=ee seria 0xff2288ee. Opaco branco é 0xffffffffff. O padrão é azul claro opaco (O que é que se passa?) , que tem a vantagem de ser diferente do branco, que é uma cor importante em muitas paletas usadas para desenhar dados. Por exemplo,
```
<graphBackgroundColor>0xffffffff</graphBackgroundColor>  
```

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

<ipAddressMaxRequests >

Não. ** <ipAddressMaxRequests> ** ] (#ipaddressmaxrequests) é uma tag opcional raramente usada (primeiro suportado com ERDDAP™ v2.) dentro de um<erddapDatasets> Identificação datasets.xml que faz parte de um sistema para limitar a capacidade de usuários legítimos excessivamente agressivos e usuários maliciosos para fazer um grande número de pedidos simultâneos que degradam o desempenho do sistema para outros usuários. IpEndereço MaxRequests especifica o número máximo de solicitações simultâneas que serão aceitas a partir de qualquer endereço IP específico. As solicitações adicionais receberão um erro HTTP 429: Too Many Requests. Os pequenos arquivos estáticos no erddap/download/ erddap/images/ não estão isentos desta contagem. O padrão é 15. O máximo permitido é 1000, o que é louco alto -- não fazê-lo! ERDDAP™ não vai aceitar um número menor do que 6 porque muitos usuários legítimos (notavelmente navegadores da web e WMS clientes) fazer até 6 pedidos de cada vez. O ERDDAP™ O Relatório Diário e as informações semelhantes escritas no arquivo log.txt com cada Recarga de Dados Maiores, agora incluirão uma história das solicitações desses endereços IP sob o título "Requester's IP Address (Muitos pedidos) ". Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

A seção "Major LoadDatasets Time Series" de status.html inclui uma coluna "tooMany" que lista o número de solicitações que excedeu a configuração ipAddressMaxRequests de um usuário e, portanto, viu um erro "Too Many Requests". Isso permite que você veja facilmente quando há usuários legítimos super agressivos ativos e usuários maliciosos para que você possa (opcionalmente) veja no arquivo log.txt e decida se você deseja listar os usuários.

Não há nada de errado em definir isto para um número maior. Depende de ti. Mas fazer isso permite / encoraja as pessoas a configurar sistemas que usam um grande número de threads para trabalhar em projetos e, em seguida, não lhes dá nenhum feedback de que o que eles estão fazendo não está recebendo nenhum benefício.

<ipAddressMaxRequestsActive >

Não. ** <ipAddressMaxRequestsActive> ** ] (#ipaddressmaxrequestsactive) é uma tag opcional raramente usada (primeiro suportado com ERDDAP™ v2.) dentro de um<erddapDatasets> Identificação datasets.xml que faz parte de um sistema para limitar a capacidade de usuários legítimos excessivamente agressivos e usuários maliciosos para fazer um grande número de pedidos simultâneos que degradam o desempenho do sistema para outros usuários. ipAddressMaxRequestsActive especifica o número máximo de solicitações simultâneas que serão processadas ativamente a partir de qualquer endereço IP específico. Os pedidos adicionais serão apresentados em uma fila até que os pedidos anteriores tenham sido processados. Os arquivos pequenos e estáticos no erddap/download/ erddap/images/ ARE isentos desta contagem e do estrangulamento relacionado. O padrão é 2. O máximo permitido é 100, o que é alto louco -- não faça isso! Você pode definir isso para 1 para ser rigoroso, especialmente se você tiver problemas com usuários excessivamente agressivos ou maliciosos. Os usuários ainda obterão rapidamente todos os dados que solicitarem (até ipAddressMaxRequests) , mas eles não serão capazes de atrair recursos do sistema. Não recomendamos definir isso para um número maior porque permite que usuários legítimos excessivamente agressivos e usuários maliciosos dominem ERDDAP capacidade de processamento. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

<ipAddressUnlimited >

Não. ** <ipAddressUnlimited> ** ] (#ipaddressunlimited) é uma tag opcional raramente usada (primeiro suportado com ERDDAP™ v2.) dentro de um<erddapDatasets> Identificação datasets.xml que faz parte de um sistema para limitar a capacidade de usuários legítimos excessivamente agressivos e usuários maliciosos para fazer um grande número de pedidos simultâneos que degradam o desempenho do sistema para outros usuários. ipAddressUnlimited é uma lista separada por vírgula de endereços IP que você deseja permitir acesso ilimitado ao seu ERDDAP . Olha no teu diário. arquivo txt para ver qual formato seu servidor está usando para os endereços IP. Em alguns servidores, os endereços IP estarão no formato #.#.#.#.#.# (onde # é um inteiro de 0 a 255) ; enquanto em outros estará no formato #:#:#:#:#:#:#:#:#:#:# . Os solicitantes nesta lista não estão sujeitos a as configurações ipAddressMaxRequests ou ipAddressMaxRequestsActive. Isto pode ser secundário. ERDDAP™ ou para certos usuários ou servidores em seu sistema. ERDDAP™ sempre adiciona " (desconhecido) ", que ERDDAP™ usa quando o endereço IP do solicitante não pode ser determinado, por exemplo, para outros processos em execução no mesmo servidor. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

Se por algum motivo todas as solicitações de um usuário receberem a mensagem de erro "Timeout aguardando suas outras solicitações para processar"., então você pode resolver o problema adicionando o endereço IP do usuário à lista ipAddressUnlimited, aplicando essa alteração e removendo-a dessa lista.

<loadDatasetsMinMinutes >

Não. ** <loadDatasetsMinMinutes> ** ] (#loaddatasetsminminutes) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml para especificar o tempo mínimo (em minutos) entre grandes cargas Conjuntos de dados (quando ERDDAP™ reprocessadores datasets.xml , incluindo verificar cada conjunto de dados para ver se ele precisa ser recarregado de acordo com sua recarga definição EveryNMinutes, default=15) . Por exemplo,

    <loadDatasetsMinMinutes>15</loadDatasetsMinMinutes>

Se uma dada execução de loadDatasets leva menos do que desta vez, o carregador apenas repetidamente olha para o diretório da bandeira e/ou dorme até que o tempo restante tenha passado. O padrão é 15 minutos, o que deve ser bom para quase todos. A única desvantagem para definir isso para um número menor é que ele aumentará a frequência que ERDDAP™ retries conjuntos de dados que têm erros que os impedem de serem carregados (por exemplo, um servidor remoto está em baixo) . Se houver muitos desses conjuntos de dados e eles são retestados frequentemente, a fonte de dados pode considerá-lo comportamento pestering/aggressive. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira . Antes ERDDAP™ v2.00, isso foi especificado no setup.xml, que ainda é permitido mas desencorajado.

<loadDatasetsMaxMinutes >

Não. ** <loadDatasetsMaxMinutes> ** ] (#loaddatasetsmaxminutes) é uma tag OPTIONAL dentro de uma<erddapDatasets> Identificação datasets.xml para especificar o tempo máximo (em minutos) uma grande carga O esforço de conjuntos de dados é permitido tomar (antes da carga Datasets thread tratados como "stalled" e é interrompido) (default=60) . Por exemplo,

    <loadDatasetsMaxMinutes>60</loadDatasetsMaxMinutes>

Em geral, isso deve ser definido para pelo menos duas vezes desde que você razoavelmente pensar que recarregar todos os conjuntos de dados (cumulativamente) deve tomar (porque computadores e redes às vezes são mais lentos do que o esperado) Isso deve ser sempre muito mais longo do que carregarDatasetsMinMinutes. O padrão é de 60 minutos. Algumas pessoas vão definir isso para mais tempo. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira . Antes ERDDAP™ v2.00, isso foi especificado no setup.xml, que ainda é permitido mas desencorajado.

<logLevel >

Não. ** <logLevel> ** ] (#loglevel) é uma tag OPTIONAL dentro de uma<erddapDatasets> Identificação datasets.xml para especificar quantas mensagens de diagnóstico são enviadas para o arquivo log.txt. Pode ser definido como "avisar" (as mais poucas mensagens) , "info" (o padrão) , ou "todos" (o mais mensagens) . Por exemplo,

    <logLevel>info</logLevel>

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira . Antes ERDDAP™ v2.00, isso foi especificado no setup.xml, que ainda é permitido mas desencorajado.

<parcialRequestMaxBytes > e<parcialRequestMaxCells >

Não. ** <parcialRequestMaxBytes> ] (#partialrequestmaxbytes-e-partialrequestmaxcells) E... <parcialRequestMaxCells> ** ] (#partialrequestmaxbytes-e-partialrequestmaxcells) raramente são usadas tags OPTIONAL dentro de uma<erddapDatasets> Identificação datasets.xml . Quando possível (e nem sempre é possível) , ERDDAP™ quebra grandes solicitações de dados em pedaços para conservar a memória.

Com 32 bits Java , em sentido simplista, o número máximo de simultâneo grande pedidos é aproximadamente 3/4 da memória disponível (o valor -Xmx passou para Tomcat) dividido pelo tamanho do pedaço (por exemplo, 1200 MB / 100 MB => 12 pedidos) . Outras coisas exigem memória, então o número real de pedidos será menor. Na prática, chunking nem sempre é possível. Então um enorme ou alguns pedidos não-chunkable simultâneos muito grandes poderia causar problemas em 32 bits Java .

Com 64 bits Java , o valor -Xmx pode ser muito maior. Portanto, a memória é muito menos provável ser uma restrição.

Você pode substituir o tamanho do pedaço padrão, definindo essas tags em datasets.xml (com valores diferentes do que mostrado aqui) : Para grades:<parcialRequestMaxBytes>100000000</partialRequestMaxBytes> Para tabelas:<parcialRequestMaxCells>1000000</partialRequestMaxCells>

parcialRequestMaxBytes é o número máximo preferido de bytes para um pedido de dados de grade parcial (um pedaço do pedido total) . padrão = 100000000 (10^8) . Tamanhos maiores não são necessariamente melhores (e não vá mais de 500 MB porque esse é o limite padrão do THREDDS para DAP respostas) . Mas tamanhos maiores podem exigir menos acessos de toneladas de arquivos (pensar em ERD Os dados de satélite com cada ponto de hora em um arquivo separado - é melhor obter mais dados de cada arquivo em cada solicitação parcial) .

parcialRequestMaxCells é o número máximo preferido de células (NRows \* nColumns na tabela de dados) para um pedido parcial de dados TABLE (um pedaço do pedido total) . Padrão = 100000. Tamanhos maiores não são necessariamente melhores. Eles resultam em uma espera mais longa para o lote inicial de dados da fonte.

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira . Antes ERDDAP™ v2.00, estes foram especificados em setup.xml, que ainda é permitido mas desencorajado.

<requestBlacklist >

Não. ** <requestBlacklist> ** ] (#Requestblacklist) é uma tag OPTIONAL dentro de um<erddapDatasets> Identificação datasets.xml que contém uma lista separada por vírgula de endereços IP numéricos que serão listados em preto. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .
- Isso pode ser usado para afastar um Denial de ataque de serviço , um zelo excessivamente robô web , ou qualquer outro tipo de usuário problemático.
- Usuário problemático -- Se ERDDAP™ retarda um rastreamento ou congela / pára, a causa é muitas vezes um usuário problemático que está executando mais de um script ao mesmo tempo e / ou fazendo um grande número de pedidos muito grandes, extremamente ineficientes, ou inválidos, ou pedidos simultâneos. Olha... - Não. para ver se este é o caso e para encontrar o endereço IP numérico do usuário problemático. Se este é o problema, você provavelmente deve lista negra que o usuário.

Quando ERDDAP™ recebe um pedido de um endereço IP na lista negra, ele retornará o erro HTTP 403: Proibido. A mensagem de erro de texto que acompanha incentiva o usuário a e-mail, o ERDDAP administrador, para resolver os problemas. Se eles levarem o tempo para ler a mensagem de erro (muitos aparentemente não) e contatá-lo, você pode então trabalhar com eles para fazê-los executar apenas um script de cada vez, fazer solicitações mais eficientes, corrigir os problemas em seu script (por exemplo, solicitando dados de um conjunto de dados remoto que não podem responder antes de sair) , ou qualquer outra coisa era a fonte de problemas.

Os usuários muitas vezes simplesmente não sabem que seus pedidos são problemáticos. Eles muitas vezes não têm conhecimento de bugs, ineficiências brutas, ou outros problemas com seus scripts. Eles muitas vezes pensam isso porque o seu ERDDAP™ oferece dados gratuitamente, que eles podem pedir o máximo de dados que quiserem, por exemplo, executando vários scripts ou usando vários threads simultaneamente.

Você pode explicar-lhes que cada um ERDDAP™ , agora importa quão grande e poderoso, tem recursos finitos (Tempo de CPU, disco rígido I/O, largura de banda de rede, etc.) e não é justo se um usuário solicitar dados de uma forma que aglomere outros usuários ou overburdens ERDDAP .
Uma vez que um usuário sabe como fazer 2 pedidos simultâneos, eles muitas vezes não vêem nenhuma razão para não fazer 5, 10 ou 20 pedidos simultâneos, uma vez que os pedidos adicionais não custam nada. É como uma guerra assimétrica: aqui, as armas ofensivas têm uma enorme vantagem (custo zero) sobre as armas defensivas (uma instalação finita com custos reais) .
Apontar para eles que existem diminuindo retornos para fazer solicitações cada vez mais simultâneas; os pedidos adicionais apenas bloquear os pedidos de outros usuários; eles não produzem uma enorme melhoria para eles.
Lembre-os de que existem outros usuários (usuários casuais e outros usuários executando scripts) , então não é justo que eles abram todos ERDDAP Os recursos.
Apontar que os gigantes tecnológicos induzem os usuários a esperar recursos infinitos de serviços web. Enquanto há maneiras de configurar grades/clusters/federações de ERDDAP S para fazer um ERDDAP™ sistema com mais recursos, a maioria ERDDAP™ administradores não têm o dinheiro ou a mão-de-obra para configurar tais sistemas, e tal sistema ainda será finito. Em ERD por exemplo, há uma pessoa (eu...) escrevendo ERDDAP™ , administrando dois ERDDAP S (com ajuda de meu chefe) , e gestão de várias fontes de dados, todos com um orçamento anual de hardware de $0 (confiamos em bolsas ocasionais para pagar por hardware) . Isto não é Google, Facebook, Amazon, etc com 100 de engenheiros, e milhões de dólares de receita para reciclar em sistemas cada vez maiores. E não podemos apenas mover o nosso ERDDAP™ para, por exemplo, Amazon AWS, porque os custos de armazenamento de dados são grandes e as taxas de entrada de dados são grandes e variáveis, enquanto nosso orçamento para serviços externos é fixo $0.
Meu pedido aos usuários é: para pedidos não sensíveis a tempo (que é, de longe, o caso mais comum) , seu sistema deve apenas fazer um pedido de cada vez. Se os pedidos forem sensíveis ao tempo (por exemplo, várias .pngs em uma página web, várias telhas para uma WMS cliente, etc.) , então talvez 4 pedidos simultâneos devem ser o máximo (e apenas por um tempo muito curto) .
Se você explicar a situação ao usuário, a maioria dos usuários entenderá e estará disposto a fazer as mudanças necessárias para que você possa remover seu endereço IP da lista negra.
Para a lista negra de um usuário, adicione seu endereço IP numérico à lista de endereços IP separados por vírgula<requestBlacklist> em seu datasets.xml ficheiro. Para encontrar o endereço IP do usuário problemático, consulte o ERDDAP™ Diretriz de grande porte arquivo /logs/log.txt ( Diretriz de grande porte é especificado em setup.xml ) para ver se este é o caso e para encontrar o endereço IP desse usuário. O endereço IP para cada solicitação está listado nas linhas começando com "{{{{#" e é 4 números separados por períodos, por exemplo, 123.45.67.8 . Procurando por "ERROR" irá ajudá-lo a encontrar problemas como pedidos inválidos.
Você também pode substituir o último número em um endereço IP com\(por exemplo, 202.109.200.\) bloquear uma gama de endereços IP, 0-255.
Você também pode substituir os últimos 2 números em um endereço IP com\.\ (por exemplo, 121.204.\.\) para bloquear uma gama mais ampla de endereços IP, 0-255.0-255.
Por exemplo,

    <requestBlacklist>98.76.54.321, 202.109.200.\\*, 121.204.\\*.\\*</requestBlacklist>

Você não precisa reiniciar ERDDAP™ para as mudanças<requestBlacklist> para ter efeito. As alterações serão detectadas da próxima vez ERDDAP™ verifica se algum conjunto de dados precisa ser recarregado. Ou, você pode acelerar o processo visitando um conjunto de dados URL da bandeira para qualquer conjunto de dados.
Tu és ERDDAP™ O relatório diário inclui uma lista/tal dos solicitantes mais ativos permitidos e bloqueados.
Se você quiser descobrir qual domínio / instituição está relacionada a um endereço IP numérico, você pode usar um serviço de web DNS gratuito e inverso como https://network-tools.com/ .
Pode haver momentos em que faz sentido bloquear certos usuários em um nível superior, por exemplo, usuários maliciosos. Por exemplo, você pode bloquear seu acesso a tudo em seu servidor, não apenas ERDDAP . No Linux, um desses métodos é usar Iptables . Por exemplo, você pode adicionar uma regra que irá bloquear tudo que vem de 198.51.100.0 com o comando iptables - INPUT -s 198.51.100.0 - J DROP

<slowDownTroubleMillis >

Não. ** <slowDownTroubleMillis> ** ] (#Slowdowntroublemillis) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml que contém um inteiro especificando o número de milissegundos (default=1000) para pausar ao responder a todas as solicitações falhadas, por exemplo, conjunto de dados desconhecidos, solicitar muito grande, usuário na lista negra. Por exemplo,
```
<slowDownTroubleMillis>2000</slowDownTroubleMillis>
```

Se um script está fazendo um pedido imediatamente após o outro, então pode rapidamente fazer um mau pedido depois do outro. Com esta configuração, você pode retardar um script de falha assim ERDDAP™ não está cheia de maus pedidos. Se um humano fizer um mau pedido, eles nem vão notar este atraso. Recomendações:

Se o problema é uma negação distribuída do serviço (DDOS) ataque de mais de 100 atacantes, definir isso para um número menor (100?) . Atrasá-los todos para baixo por muito tempo leva a muitos fios ativos.
Se o problema for de 1-10 fontes, defina isso para 1000 ms (o padrão) , mas um número maior (como 10000) também é razoável. Isso os reduz para que eles percam menos recursos de rede. Além disso, 1000 ms ou assim não vai irritar os usuários humanos que fazem um mau pedido.

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

<assinaturaEmailBlacklist >

Não. ** <assinatura E-mailBlacklist ** ] (Lista negra de assinaturas) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml que contém uma lista separada por vírgula de endereços de e-mail que são imediatamente listados a partir da sistema de assinatura Por exemplo
```
<subscriptionEmailBlacklist>bob@badguy.com, john@badguy.com</subscriptionEmailBlacklist>  
```

Este é um sistema insensível a casos. Se um endereço de e-mail for adicionado a esta lista, se esse endereço de e-mail tiver assinaturas, as assinaturas serão canceladas. Se um endereço de e-mail na lista tentar assinar, o pedido será recusado. Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

Texto padrão

Texto padrão - ... Existem várias tags OPTIONAL (mais raramente são usados) dentro de um<erddapDatasets> Identificação datasets.xml para especificar texto que aparece em vários lugares em ERDDAP . Se você quiser alterar o texto padrão, copie o valor existente da tag do mesmo nome em Toca a brincar. /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util.messages.xml para dentro datasets.xml , então modifique o conteúdo. A vantagem de tê-los em datasets.xml é que você pode especificar novos valores a qualquer momento, mesmo quando ERDDAP™ está a correr. Quaisquer alterações nos valores dessas tags entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira . Os nomes de tags descrevem seu propósito, mas veja o conteúdo padrão em message.xml para um entendimento mais profundo.
<padrãoLicença>
<padrãoContato>
<standardDataLicenses>
<padrãoDisclaimerOfEndorsement>
<standardDisclaimerOfExternalLinks>
<standardGeneralDisclaimer>
<padrão Política de Privacidade>
<startHeadHtml5>
<startBodyHtml5> é uma boa tag para mudar, a fim de personalizar a aparência do topo de cada página da web em sua ERDDAP . Notavelmente, você pode usar isso para adicionar facilmente uma mensagem temporária no ERDDAP™ Página inicial (por exemplo, "Verifique o novo conjunto de dados JPL MUR SST v4.1 ..." ou "This ERDDAP™ estará offline para manutenção 2019-05-08T17:00 PDT até 2019-05-08T20:00 PDT.") . Um quirk de colocar esta tag em datasets.xml é: quando você reiniciar ERDDAP , o primeiro pedido a ERDDAP™ retornará o início padrão BodyHtml5 HTML, mas cada solicitação subsequente usará o HTML startBodyHtml5 especificado em datasets.xml .
<a descrição curta Html> é uma boa tag para mudar, a fim de personalizar a descrição de seu ERDDAP . Note que você pode facilmente mudar isso para adicionar uma mensagem temporária na página inicial (por exemplo, "Isto ERDDAP™ estará offline para manutenção 2019-05-08T17:00 PDT até 2019-05-08T20:00 PDT.") .
<endBodyHtml5>

Antes ERDDAP™ v2.00, estes foram especificados em setup.xml, que ainda é permitido mas desencorajado.

<incomum Atividade >

Não. ** <Atividade incomum> ** ] (#unusualatividade) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml para especificar o número máximo de pedidos entre duas corridas de LoadDatasets que é considerado normal (default=10000) . Se esse número for excedido, um e-mail é enviado para e-mail (como especificado em setup.xml) . Por exemplo,
```
<unusualActivity>10000</unusualActivity>  
```

<updateMaxEvents >

Não. ** <updateMaxEvents> ** ] (#updatemaxevents) é uma tag OPTIONAL raramente usada dentro de uma<erddapDatasets> Identificação datasets.xml para especificar o número máximo de eventos de mudança de arquivo (padrão=10) que será tratado pelo [<updateEveryNMillis>] (#updateeverynmillis #) sistema antes de mudar para recarregar o conjunto de dados. Por exemplo,
```
<updateMaxEvents>10</updateMaxEvents>  
```

O sistema updateEveryNMillis destina-se a executar muito rapidamente antes que a solicitação de um usuário seja processada. Se houver muitos eventos de mudança de arquivo, então presumivelmente não pode ser executado rapidamente, então, em vez disso, exige que o conjunto de dados seja recarregado. Se você ERDDAP™ lida com conjuntos de dados que devem ser mantidos atualizados mesmo quando houver mudanças em um grande número de arquivos de dados, você pode definir isso para um número maior (100?) .

<usuário >

Não. ** <utilizador> ** ] (#user #) é uma tag OPTIONAL dentro de uma<erddapDatasets> Identificação datasets.xml que identifica o nome de usuário, senha (se a autenticação = personalizada) , e papéis (uma lista separada por vírgula) . O uso de nome de usuário e senha varia ligeiramente com base no valor de [<autenticação> (/docs/servidor-admin/informação adicional#autenticação) em seu ERDDAP É o arquivo setup.xml.
- Isto faz parte de ERDDAP ' sistema de segurança para restringir o acesso a alguns conjuntos de dados a alguns usuários.
- Faça um separado<user> tag para cada usuário. Opcionalmente, se autenticação=oauth2, você pode configurar dois<utilizador> tags para cada usuário: uma para quando o usuário faz login via Google, um para quando o usuário faz login via Orcid, presumivelmente com as mesmas funções.
- Se não houver<user> tag para um cliente, ele só será capaz de acessar conjuntos de dados públicos, ou seja, conjuntos de dados que não têm um [<acessível para> (Acessível a) tag.
- Nome de utilizador Para autenticação=personalizado, o nome de usuário é geralmente uma combinação de letras, dígitos, sublinhados e períodos. Para autenticação=email, o nome de usuário é o endereço de e-mail do usuário. Pode ser qualquer endereço de e-mail. Para autenticação=google, o nome de usuário é o endereço de e-mail completo do Google. Isso inclui contas gerenciadas pelo Google como @noaa.gov contas. Para autenticação=orcid, o nome de usuário é o número de conta Orcid do usuário (com traços) . Para autenticação=oauth2, o nome de usuário é o endereço de e-mail completo do Google ou o número de conta Orcid do usuário (com traços) .
- senha Para autenticação=email, google, orcid ou oauth2, não especifique um atributo de senha. Para autenticação=personalizado, você deve especificar um atributo de senha para cada usuário.
  - As senhas que os usuários entram são sensíveis a casos e devem ter 8 ou mais caracteres para que eles sejam mais difíceis de quebrar. Hoje em dia, até 8 caracteres podem ser rachados de forma rápida e barata pela força bruta usando um conjunto de computadores na AWS. ERDDAP™ apenas impõe o mínimo de 8 caracteres quando o usuário tenta fazer login (não quando o<user> tag está sendo processado, porque esse código só vê o hash digest da senha, não a senha de texto simples).
  - setup.xml's<codificação de senhas determina como as senhas são armazenadas no<utilizador> etiquetas em datasets.xml . Para aumentar a segurança, as opções são:
    - MD5 (Não uses isto!) -- para o atributo password, especifique o resumo hash MD5 da senha do usuário.
    - UEPMD5 (Não uses isto!) -- para o atributo password, especifique o resumo hash do MD5 Nome de utilizador : ERDDAP : senha . O nome de usuário e " ERDDAP " são usados para sal o valor hash, tornando mais difícil decodificar.
    - SHA256 (não recomendado) -- para o atributo password, especifique o resumo hash SHA-256 da senha do usuário.
    - UEPSHA256 (default, recomendado passwordEncoding. Mas muito melhor: use o google, orchid, ou oauth2 opções de autenticação.) -- para o atributo password, especifique o digestivo hash SHA-256 Nome de utilizador : ERDDAP : senha . O nome de usuário e " ERDDAP " são usados para sal o valor hash, tornando mais difícil decodificar.
  - No Windows, você pode gerar valores de digestão por senha MD5 baixando um programa MD5 (como MD5 ) e usando (por exemplo) : md5 -djsmith: ERDDAP : Palavra-passe real
  - No Linux/Unix, você pode gerar valores de digestão MD5 usando o programa md5sum integrado (por exemplo) : echo -n "jsmith: ERDDAP : Palavra-passe real " | Md5sum
  - Senhas de texto simples armazenadas são sensíveis a casos. As formas armazenadas de senhas MD5 e UEPMD5 não são sensíveis a casos.
  - Por exemplo (usando UEPMD5) , se username="jsmith" e password="myPassword", o<user> tag é:

            <user username="jsmith"  
            password="57AB7ACCEB545E0BEB46C4C75CEC3C30"  
            roles="JASmith, JASmithGroup" />  

onde a senha armazenada foi gerada com md5 -djsmith: ERDDAP : minha palavra

funções é uma lista separada por vírgula de funções para as quais o usuário está autorizado. Qualquer<dataset> pode ter um [<acessível para> (Acessível a) tag que lista as funções que são permitidas para acessar esse conjunto de dados. Para um determinado usuário e um dado conjunto de dados, se uma das funções na lista de funções do usuário corresponde a uma das funções na lista de conjuntos de dados<funções acessíveisTo>, então o usuário está autorizado a acessar esse conjunto de dados.

Cada usuário que faz login é automaticamente dado o papel \[ Qualquer pessoa Em \] , se há um<user> tag para eles em datasets.xml ou não. Então, se um dado conjunto de dados tiver

            <accessibleTo>\\[anyoneLoggedIn\\]</accessibleTo>

então qualquer usuário que está conectado será autorizado a acessar esse conjunto de dados, mesmo que não haja<user> tag para eles em datasets.xml .

Quaisquer alterações no valor desta tag entrarão em vigor na próxima vez ERDDAP™ leituras datasets.xml , incluindo em resposta a um conjunto de dados bandeira .

<pathRegex >

Não. ** <pathRegex> ** ] (#) permite especificar uma expressão regular que limita os caminhos (que subdiretórios) será incluído no conjunto de dados. O padrão é .\*, que corresponde a todos os caminhos. Esta é uma tag raramente usada, raramente necessária, OPTIONAL para EDDGrid DeFiles conjuntos de dados, EDDTableDeFiles conjuntos de dados, e alguns outros tipos de conjuntos de dados. No entanto, quando você precisa, você realmente precisa.

Para fazer isso funcionar, você precisa ser realmente bom com expressões regulares. Veja isto documentação e tutorial do regex . Em particular, você precisa saber sobre grupos de captura (algo dentro de parênteses) e o símbolo "ou" | ". Juntos, estes permitem especificar qualquer número de opções, por exemplo, (Opção1 | opção2 | opção3) . Além disso, qualquer uma das opções não pode ser nada, por exemplo, ( | opção2 | opção3) . Além disso, você precisa saber que grupos de captura podem ser aninhados, ou seja, qualquer opção em um grupo de captura pode conter outro grupo de captura, por exemplo, ( | opção2 ( | opção2 b) | opção2c) | opção3) que diz que opção2 pode ser seguido por nada, ou opção2b, ou opção2c. Para pathRegexes, cada opção será um nome de pasta seguido por um /, por exemplo, bar / .

A parte complicada do caminhoRegex é: Quando ERDDAP™ recursivamente desce a árvore de diretórios, o caminhoRegex deve aceitar todos os caminhos que encontra em seu caminho para os diretórios com dados. Regex's com grupos de captura aninhados são uma boa maneira de lidar com isso.

Um exemplo: Suponha que temos a seguinte estrutura de diretório:

/foo/bar/D0001/a/\\*.nc  
/foo/bar/D0001/b/\\*.nc  
/foo/bar/D0002/a/\\*.nc  
/foo/bar/D0002/b/\\*.nc  
...  
/foo/bar/E0001/a/\\*.nc  
...  

e o fileDirectory especificado é /foo/bar/, e nós apenas queremos .nc arquivos no D \[ 0-9 \] {4}/a/ subdirectories. A solução é definir caminhoRegex para /foo/bar/ ( | D \[ 0-9 \] (4) ( | a)) )
Isso diz: O caminho deve começar com /foo/bar/ Isso pode ser seguido por nada ou D \[ 0-9 \] (4) Isso pode ser seguido de nada ou a /

Sim, o PathRegex pode ser incrivelmente difícil de formular. Se você ficar preso, pergunte a um programador de computador (a coisa mais próxima no mundo real a um feiticeiro que brota incantações?) ou enviar um e-mail para Chris. John no noaaa.gov.

<dataset >

Não. ** <dataset> ** ] (#dataset) é um OPTIONAL (mas sempre usado) tag dentro de uma<erddapDatasets> Identificação datasets.xml que (se você incluir todas as informações entre<dataset> e</dataset>) descreve completamente um conjunto de dados. Por exemplo,
```
<dataset type="EDDGridFromDap" datasetID="erdPHssta8day" active="true"> ... </dataset>  
```

Pode haver qualquer número de tags de conjuntos de dados em sua datasets.xml ficheiro. Três atributos MAY aparecem dentro de um<dataset> tag:

Tipo... um Tipo " é um atributo REQUIRED dentro de um<dataset> tag in datasets.xml que identifica o tipo de conjunto de dados (por exemplo, se é um EDDGrid /gridded ou EDDTable / conjunto de dados tabular) e a fonte dos dados (por exemplo, um banco de dados, arquivos ou um remoto OPeNDAP servidor) . Ver Lista de Tipos de Conjunto de Dados .

conjunto de dados I.

** datasetID = aDatasetID "** é um atributo REQUIRED dentro de um<dataset> tag que atribui um curto (geralmente<15 caracteres), único, identificando nome para um conjunto de dados.
O datasetID deve ser uma carta (A-Z, a-z) seguido por qualquer número de A-Z, a-z, 0-9, e \_ (mas melhor se<32 caracteres no total).
Conjunto de dados IDs são sensíveis a casos, mas NÃO criar dois datasetID s que só diferem em letras maiúsculas/baixas. Ele vai causar problemas em computadores Windows (seu e/ou computador de um usuário) .
Melhores práticas: Recomendamos usar camelo Processo .
Melhores práticas: Recomendamos que a primeira parte seja uma sigla ou abreviação do nome da instituição-fonte e a segunda parte seja uma sigla ou abreviação do nome do conjunto de dados. Quando possível, criamos um nome que reflete o nome da fonte para o conjunto de dados. Por exemplo, usamos datasetID - Não. sst a8day" para um conjunto de dados do NOAA NMFS SWFSC Divisão de Investigação Ambiental ( ERD ) que é designado pela fonte para ser satélite/PH/ sst 8 dias.
Se você alterar o nome de um conjunto de dados, o conjunto de dados antigo (com o nome antigo) vai continuar a viver ERDDAP . Este é um conjunto de dados "órfãos", porque a especificação para ele datasets.xml Agora desapareceu. Isto deve ser tratado:
1. Para ERDDAP™ v2.19 e mais tarde, você não precisa fazer nada. ERDDAP™ removerá automaticamente esses conjuntos de dados órfãos.
2. Para ERDDAP™ v2.18 e antes, você precisa fazer algo para remover os conjuntos de dados órfãos: Faça um conjunto de dados ativo="false", por exemplo,

                <dataset type="EDDTableFromNcFiles" datasetID="*theOldName*" active="false" />

Após a próxima grande carga Conjuntos de dados, Você pode remover essa tag depois que o conjunto de dados antigo é inativo.

ativo

Ativar booleano " é um atributo OPTIONAL dentro de um<dataset> tag in datasets.xml o que indica se um conjunto de dados está ativo (elegíveis para uso em ERDDAP ) ou não.
Os valores válidos são verdadeiros (o padrão) e falso.
Uma vez que o padrão é verdadeiro, você não precisa usar esse atributo até que você queira remover temporariamente ou permanentemente este conjunto de dados ERDDAP .
Se você apenas remover um dataset ativo="true" de datasets.xml , o conjunto de dados ainda estará ativo em ERDDAP™ mas nunca será atualizado. Tal conjunto de dados será um "órfão" e será listado como tal no status. html página web abaixo da lista de conjuntos de dados que não foram carregados.
Se você definir ativo="false", ERDDAP™ irá desativar o conjunto de dados da próxima vez que tentar atualizar o conjunto de dados. Quando fazes isto, ERDDAP™ não descarta qualquer informação que possa ter armazenado sobre o conjunto de dados e certamente não faz nada aos dados reais.
Para remover um conjunto de dados ERDDAP™ Veja Remoção de Dados de Força .

** Várias tags podem aparecer entre as<dataset> e</dataset> tags. **
Há alguma variação em que as tags são permitidas por que tipos de conjuntos de dados. Veja a documentação para um específico tipo de conjunto de dados para detalhes.

<acessível Para >

Não. ** <acessível - A sério? ** ] (Acessível a) é uma tag OPTIONAL dentro de uma<dataset> tag que especifica uma lista separada por vírgulas papéis que são autorizados a ter acesso a este conjunto de dados. Por exemplo,
```
<accessibleTo>RASmith, NEJones</accessibleTo>  
```
- Isto faz parte de ERDDAP ' sistema de segurança para restringir o acesso a alguns conjuntos de dados a alguns usuários.
- Se esta tag não estiver presente, todos os usuários (mesmo que não tenham entrado) terá acesso a este conjunto de dados.
- Se esta tag estiver presente, este conjunto de dados só será visível e acessível a usuários conectados que tenham uma das funções especificadas. Este conjunto de dados não será visível para usuários que não estão conectados.
- Cada usuário que faz login é automaticamente dado o papel \[ Qualquer pessoa Em \] , se há um<user> tag para eles em datasets.xml ou não. Então, se um dado conjunto de dados tiver
```
    <accessibleTo>\\[anyoneLoggedIn\\]</accessibleTo>  
```

então qualquer usuário que está conectado será autorizado a acessar esse conjunto de dados, mesmo que não haja<user> tag para eles em datasets.xml .

<gráficosAccessibleTo >

Não. ** <gráficosAccessibleTo> ** ] (#graphsacessível para) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml que determina se gráficos e metadados para o conjunto de dados estão disponíveis para o público. Oferece uma maneira de substituir parcialmente o conjunto de dados [<acessível para> (Acessível a) configuração. Os valores permitidos são:
- auto... Este valor (ou a ausência de um<graphsAccessibleTo> tag para o conjunto de dados) faz acesso a gráficos e metadados do conjunto de dados imitar o conjunto de dados<configuração acessível para>. Então, se o conjunto de dados é privado, seus gráficos e metadados serão privados. E se o conjunto de dados é público, seus gráficos e metadados serão públicos.
- público - ... Esta configuração torna os gráficos e metadados do conjunto de dados acessíveis a qualquer pessoa, mesmo usuários que não estejam conectados, mesmo que o conjunto de dados seja de outra forma privado porque ele tem um<acessível Para> tag.

<acessível ViaFiles >

Não. ** <acessívelViaFiles> ** ] (#acessível através de arquivos) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml para EDDGrid Dimensão existente agregada , EDDGrid Entendido. , EDDGrid Tabela DED , EDDGrid De Erddap , EDDGrid De Etopo , EDDGrid Dos quartos (incluindo todas as subclasses) , EDDGrid SideBySide , EDDTableCopy EDDTable FromErddap , Tabela de EDD EDDGrid e Tabela EDD dos arquivos (incluindo todas as subclasses) conjuntos de dados. Pode ter um valor de verdadeiro ou falso. Por exemplo,
```
<accessibleViaFiles>true</accessibleViaFiles>  
```

Se o valor for verdadeiro, ERDDAP™ irá fazê-lo para que os usuários possam navegar e baixar os arquivos de dados de origem do conjunto de dados via ERDDAP ' "files" sistema . Ver "files" sistema documentação para mais informações.

O valor padrão de<acessívelViaFiles> vem de<defaultAccessibleViaFiles> em setup.xml . Tem um valor padrão de falso, mas recomendamos que você adicione essa tag ao seu setup.xml com um valor de verdade.

Recomendação -- Recomendamos fazer todos os conjuntos de dados relevantes acessíveis através do sistema de arquivos, definindo<defaultAccessibleViaFiles> para true no setup.xml porque há um grupo de usuários para quem esta é a maneira preferida para obter os dados. Entre outras razões, o "files" sistema torna mais fácil para os usuários ver quais arquivos estão disponíveis e quando eles são alterados pela última vez, facilitando que um usuário mantenha sua própria cópia de todo o conjunto de dados. Se você geralmente não quiser fazer conjuntos de dados acessíveis através do sistema de arquivos, defina<defaultAccessibleViaFiles> para false. Em qualquer caso, basta usar<acessívelViaFiles> para os poucos conjuntos de dados que são exceções à política geral definida por<defaultAccessibleViaFiles> (por exemplo, quando o conjunto de dados usa .nc ml arquivos, que não são realmente úteis para usuários) .

<acessível Viajando WMS >

Não. ** <acessível Viajando WMS > ** ] (#acessível através de) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml para todos EDDGrid subclasses. Pode ter um valor de verdade (o padrão) ou falso. Por exemplo,
```
<accessibleViaWMS>true</accessibleViaWMS>  
```

Se o valor for falso, ERDDAP ' WMS servidor não estará disponível para este conjunto de dados. Isso é comumente usado para conjuntos de dados que têm alguns valores de longitude maiores que 180 (que tecnicamente é inválido para WMS serviços) , e para o qual você também está oferecendo uma variante do conjunto de dados com valores de longitude inteiramente no intervalo -180 a 180 via EDDGrid LonPM180 . Se o valor for verdadeiro, ERDDAP™ vai tentar tornar o conjunto de dados disponível através ERDDAP ' WMS servidor. Mas se o conjunto de dados é completamente inadequado para WMS (por exemplo, não há dados de longitude ou latitude) , então o conjunto de dados não estará disponível via ERDDAP ' WMS servidor, independentemente desta configuração.

<Adicionar Variáveis Onde >

Não.<addVariablesWhere>] (#addvariableswhere) é uma tag OPTIONAL dentro do<dataset> tag para todos os conjuntos de dados EDDTable.

Os pedidos de qualquer conjunto de dados da EDDTable podem incluir &add Variáveis Onde? (" atributos Nome ", atributos Valor ") , que diz ERDDAP™ para adicionar todas as variáveis no conjunto de dados onde Atributos relacionados para a lista de variáveis solicitadas. Por exemplo, se um usuário adiciona &add Variáveis Onde? (" ioos\_category ","Wind") para uma consulta, ERDDAP irá adicionar todas as variáveis no conjunto de dados que têm ioos\_category = Atributo Wind à lista de variáveis solicitadas (por exemplo, windSpeed, windDirection, windGustSpeed) . atributos Nome e atributos Valor são sensíveis a casos.

Em datasets.xml , se o pedaço de dataset.xml para um conjunto de dados tem

<addVariablesWhere>*attributeNamesCSV*<addVariablesWhere>

por exemplo,

<addVariablesWhere>ioos\\_category,units<addVariablesWhere>

o formulário de acesso de dados (Página web .html) para o conjunto de dados incluirá um widget (para cada atributoNome na lista separada por vírgula) abaixo da lista de variáveis que permite aos usuários especificar um valor de atributo. Se o usuário selecionar um valor de atributos para um ou mais dos nomes de atributos, eles serão adicionados à solicitação via &add Variáveis Onde? (" atributos Nome ", atributos Valor ") . Assim, esta tag em datasets.xml permite especificar a lista de nomes de atributos que aparecerão no Formulário de Acesso de Dados para esse conjunto de dados e facilita que os usuários adicionem &addVariables Onde funções para o pedido. O atributosCSV A lista é sensível a casos.

<altitudeMetersPerSourceUnit >

Não. ** <altitudeMetersPerSourceUnit> ** ] (#altitudemeterspersourceunit) é uma tag OPTIONAL dentro do<dataset> tag em conjuntos de dados. xxml para EDDTableDe SOS conjuntos de dados (Só!) que especifica um número que é multiplicado pelos valores de altitude ou profundidade da fonte para convertê-los em valores de altitude (em metros acima do nível do mar) . Por exemplo,
```
<altitudeMetersPerSourceUnit>-1</altitudeMetersPerSourceUnit>  
```

Esta tag DEVE ser usada se os valores do eixo vertical do conjunto de dados não são medidores, positivo=up. Caso contrário, é OPTIONAL, uma vez que o valor padrão é 1. Por exemplo,

Se a fonte já é medida em metros acima do nível do mar, use 1 (ou não use esta tag, uma vez que 1 é o valor padrão) .
Se a fonte for medida em metros abaixo do nível do mar, use -1.

    <altitudeMetersPerSourceUnit>-1</altitudeMetersPerSourceUnit>

Se a fonte for medida em km acima do nível do mar, use 0,001.

<defaultDataQuery >

Não. ** <defaultDataQuery> ** ] (Tradução e Revisão:) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml que diz ERDDAP™ para usar a consulta especificada (a parte da URL após o "?") se o arquivo .html Tipo (o formulário de acesso de dados) é solicitado sem consulta.
- Você provavelmente raramente precisará usar isso.
- Você precisa para XML-encode (não o código de porcentagem) as consultas padrão desde que estão em um documento XML. Por exemplo, & se torna & ,<torna-se<, > se torna > .
- Por favor, verifique o seu trabalho. É fácil cometer um erro e não ter o que você quer. ERDDAP™ tentará limpar seus erros -- mas não confie nisso, desde\*como fazer\*é limpo pode mudar.
- Para conjuntos de dados do griddap, um uso comum disso é especificar um valor diferente da profundidade padrão ou da dimensão da altitude (por exemplo, \[ 0 \] em vez de \[ último \] ) . Em qualquer caso, você deve sempre listar todas as variáveis, sempre usar os mesmos valores de dimensão para todas as variáveis, e quase sempre usar \[ 0 \] , \[ último \] ou \[ 0: última \] para os valores de dimensão. Por exemplo:
```
    <defaultDataQuery>u\\[last\\]\\[0\\]\\[0:last\\]\\[0:last\\],v\\[last\\]\\[0\\]\\[0:last\\]\\[0:last\\]</defaultDataQuery>
```
- Para tabledap datasets, se você não especificar qualquer restrição, a solicitação retornará todo o conjunto de dados, o que pode ser impraticamente grande, dependendo do conjunto de dados. Se você não quiser especificar quaisquer restrições, em vez de ter um vazio<defaultDataQuery> (que é o mesmo que não especificar um padrão Pergunta de dados) , você precisa listar explicitamente todas as variáveis que deseja incluir no defaultDataQuery.
- Para tabledap datasets, o uso mais comum disso é especificar um intervalo de tempo padrão diferente (em relação ao máximo (Tempo) , por exemplo, &time>=max (Tempo) -1day, ou em relação a agora, por exemplo, &time>= now- 1 dia) . Lembre-se que não requerer variáveis de dados é o mesmo que especificar todas as variáveis de dados, então geralmente você pode apenas especificar a nova restrição de tempo. Por exemplo:
```
    <defaultDataQuery>&amp;time&gt;=max(time)-1day</defaultDataQuery>  
```

    <defaultDataQuery>&amp;time&gt;=now-1day</defaultDataQuery>

<defaultGraphQuery >

Não. ** <defaultGraphQuery> ** ] (#defaultgraphquery) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml que diz ERDDAP™ para usar a consulta especificada (a parte da URL após o "?") se o arquivo .graph Tipo (o fazer um formulário gráfico) é solicitado sem consulta.
- Você provavelmente raramente precisará usar isso.
- Você precisa para XML-encode (não o código de porcentagem) as consultas padrão desde que estão em um documento XML. Por exemplo, & se torna & ,<torna-se<, > se torna > .
- Por favor, verifique o seu trabalho. É fácil cometer um erro e não ter o que você quer. ERDDAP™ tentará limpar seus erros -- mas não confie nisso, desde\*como fazer\*é limpo pode mudar.
- Para conjuntos de dados do griddap, o uso mais comum disso é especificar um valor diferente da profundidade padrão ou da dimensão da altitude (por exemplo, \[ 0 \] em vez de \[ último \] ) e/ou especificar que uma variável específica seja graficada. Em qualquer caso, você quase sempre vai usar \[ 0 \] , \[ último \] ou \[ 0: última \] para os valores de dimensão. Por exemplo:
```
    <defaultGraphQuery>temp\\[last\\]\\[0\\]\\[0:last\\]\\[0:last\\]&amp;.draw=surface&amp;.vars=longitude|latitude|temp</defaultGraphQuery>  
```
(mas coloque tudo em uma linha)
- Para tabledap datasets, se você não especificar qualquer restrição, a solicitação irá gravar todo o conjunto de dados, o que pode demorar muito tempo, dependendo do conjunto de dados.
- Para tabledap datasets, o uso mais comum disso é especificar um intervalo de tempo padrão diferente (em relação ao máximo (Tempo) , por exemplo, &time>=max (Tempo) -1day, ou em relação a agora, por exemplo, &time>= now- 1 dia) . Lembre-se que não requerer variáveis de dados é o mesmo que especificar todas as variáveis de dados, então geralmente você pode apenas especificar a nova restrição de tempo. Por exemplo:
```
    <defaultGraphQuery>&amp;time&gt;=max(time)-1day</defaultGraphQuery>  
```

    <defaultGraphQuery>&amp;time&gt;=now-1day</defaultGraphQuery>

<dimensionValuesInMemory >

Não. ** <dimensão Valores em memória> ** ] (#valores de dimensão em memória) (verdadeiro (o padrão) ou falso) é uma tag OPTIONAL e raramente usada dentro do<dataset> tag para qualquer EDDGrid dataset que diz ERDDAP™ onde manter os valores-fonte das dimensões (também conhecido como o axisVariable S) :
- true = em memória (que é mais rápido, mas usa mais memória)
- false = no disco (que é mais lento, mas não usa memória)

Por exemplo,

<dimensionValuesInMemory>false</dimensionValuesInMemory>

Você só deve usar isso com o valor não-padrão de falso se o seu ERDDAP™ tem um monte de conjuntos de dados com dimensões muito grandes (por exemplo, milhões de valores, por exemplo, EDDGrid Conjuntos de dados da AudioFiles) e ERDDAP O uso de memória é sempre muito alto. Veja a Memória: atualmente usando linha em \[ seu domínio \] /erddap/status.html para monitorar ERDDAP™ uso de memória.

<arquivoTableInMemory >

Não. ** <arquivoTableInMemory> ** ] (#filetableinmemory) (verdadeiro ou falso (o padrão) ) é uma tag OPTIONAL dentro do<dataset> tag para qualquer EDDGrid Dos Ficheiros e Tabela EDD Conjunto de dados do FromFiles que conta ERDDAP™ onde manter a tabela de arquivos (que tem informações sobre cada arquivo de dados de origem) :
- true = em memória (que é mais rápido, mas usa mais memória)
- false = no disco (que é mais lento, mas não usa memória)

Por exemplo,

<fileTableInMemory>true</fileTableInMemory>

Se você definir isso para true para qualquer conjunto de dados, mantenha um olho na memória: atualmente usando linha em \[ seu domínio \] /erddap/status.html para garantir que ERDDAP™ ainda tem muita memória livre.

<fgdcFile >

Não. ** <FgdcFile ** ] (#fgdcfile) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml que diz ERDDAP™ para usar um arquivo FGDC pré-feito em vez de ter ERDDAP™ tentar gerar o arquivo. Uso:

    <fgdcFile>*fullFileName*</fgdcFile>

completo Nome do arquivo pode se referir a um arquivo local (algures no sistema de ficheiros do servidor) ou a URL de um arquivo remoto. Se completo Nome do arquivo \=" ou o arquivo não é encontrado, o conjunto de dados não terá metadados FGDC. Então isso também é útil se você quiser suprimir os metadados FGDC para um conjunto de dados específico. Ou podes pôr<fgdcActive>false</fgdcActive> em setup.xml para dizer ERDDAP™ não oferecer metadados FGDC para qualquer conjunto de dados.

<INSTITUIÇÕES Arquivo >

Não. ** <iso19115File> ** ] (#iso19115file) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml que diz ERDDAP™ para usar um arquivo ISO 19115 pré-feito em vez de ter ERDDAP™ tentar gerar o arquivo. Uso:
```
<iso19115File>*fullFileName*</iso19115File>  
```
completo Nome do arquivo pode se referir a um arquivo local (algures no sistema de ficheiros do servidor) ou a URL de um arquivo remoto. Se completo Nome do arquivo \=" ou o arquivo não é encontrado, o conjunto de dados não terá metadados ISO 19115. Então isso também é útil se você quiser suprimir os metadados ISO 19115 para um conjunto de dados específico. Ou podes pôr<iso19115Active>false</iso19115Active> em setup.xml para contar ERDDAP™ não oferecer metadados ISO 19115 para qualquer conjunto de dados.

<Axis de correspondência NDigits >

Não. ** <O que é isso? ** ] (#matchaxisndigits) é uma tag OPTIONAL dentro de uma EDDGrid <dataset> tag para EDDGrid conjuntos de dados que são agregados, por exemplo, agregados de arquivos. Cada vez que o conjunto de dados é recarregado, ERDDAP™ verifica se os valores do eixo de cada componente da agregação são os mesmos. A precisão dos testes é determinada pela Jogos de Vestir , que especifica o número total de dígitos que devem corresponder ao testar valores de eixo de dupla precisão, 0 - 18 (o padrão) . Ao testar os valores do eixo flutuante, o teste é feito com os dígitos matchAxisNDigits/2. Um valor de 18 ou superior diz EDDGrid para fazer um teste exato. Um valor de 0 diz EDDGrid não fazer nenhum teste, o que não é recomendado, exceto conforme descrito abaixo.

Embora EDDGrid permite que os componentes da agregação tenham valores de eixo ligeiramente diferentes, apenas um conjunto de valores de eixo é mostrado ao usuário. O conjunto é do mesmo componente que fornece os metadados de origem do conjunto de dados. Por exemplo, EDDGrid Conjuntos de dados do FromFiles, que é especificado pelo<metadadosDe configuração do> (default=last) .

O uso de matchAxisNDigits\=0 é fortemente desencorajado na maioria dos casos, porque desliga toda a verificação. Mesmo a verificação mínima é útil porque garante que os componentes são adequados para agregar. Todos nós presumimos que todos os componentes são adequados, mas nem sempre é assim. É assim um importante teste de sanidade. Mesmo os valores de matchAxisNDigits1, 2, 3 ou 4 são desencorajados porque os diferentes valores de eixo muitas vezes indicam que os componentes foram criados (Binned?) uma maneira diferente e, portanto, não são adequados para agregação.

Há um caso em que usar o matchAxisNDigits\=0 é útil e recomendado: com agregados de arquivos remotos, por exemplo, dados em baldes S3. Neste caso, se o conjunto de dados usa cacheFromUrl, cacheSizeGB, matchAxisNDigits\=0, e o EDDGrid Sistema FromFiles para Agregação via Nomes de arquivo Então EDDGrid não precisa ler todos os arquivos remotos para fazer a agregação. Isso permite que conjuntos de dados feitos a partir de dados em baldes S3 para carregar muito rapidamente (ao contrário de absurdamente lentamente se EDDGrid tem que baixar e ler todos os arquivos) .

<nThreads >

Começar com ERDDAP™ versão 2.00, quando qualquer subclasse de EDDTableFromFiles ou EDDGrid lê dados de sua fonte, pode ler um pedaço de dados (por exemplo, um arquivo de origem) em um momento (em um fio) (que é o padrão) ou mais de um pedaço de dados (por exemplo, 2+ arquivos de origem) em um momento (em 2 ou mais fios) ao processar cada pedido.
- Regra de Tumb: Para a maioria dos conjuntos de dados na maioria dos sistemas, use nThreads=1, o padrão. Se você tem um computador poderoso (muitos núcleos de CPU, muita memória) , em seguida, considerar a definição nTreads para 2, 3, 4 ou superior (mas nunca mais do que o número de núcleos de CPU no computador) para conjuntos de dados que podem beneficiar:
  - A maioria dos conjuntos de dados EDDTableFromFiles beneficiará.
  - Os conjuntos de dados onde algo causa um atraso antes que um pedaço de dados possa realmente ser processado irão beneficiar, por exemplo:
    - Datasets com externamente comprimido (por exemplo, .gz ) binário (por exemplo, .nc ) arquivos, porque ERDDAP™ tem que descomprimir todo o arquivo antes que ele possa começar a ler o arquivo.
    - Datasets que usam cacheSizeGB Porque ERDDAP™ muitas vezes tem que baixar o arquivo antes que ele possa lê-lo.
    - Conjuntos de dados com arquivos de dados armazenados em um sistema de arquivos paralelo de alta largura de banda, porque ele pode fornecer mais dados, mais rápido, quando solicitado. Exemplos de sistemas de arquivos paralelos incluem JBOD , PNFS , Gluster , Amazon S3 e Google Cloud Storage.

Atenção: Ao usar nThreads>1, fique de olho em ERDDAP uso de memória, uso de rosca e capacidade de resposta geral (ver ERDDAP Página de status ) . Veja comentários sobre essas questões abaixo.

Para um dado conjunto de dados, esta configuração nThreads pode vir de diferentes lugares:
- Se o datasets.xml chunk para um conjunto de dados tem<nThreads> tag (dentro do<dataset> tag, não como um atributo global) com um valor >= 1, esse valor de nThreads é usado. Assim, você pode especificar um número diferente para cada conjunto de dados.
- Caso contrário, se datasets.xml tem um<nTableThreads> tag (para EDDTable Conjuntos de dados de Ficheiros) ou um<nGridThreads> tag (para EDDGrid conjuntos de dados) com um valor >= 1, fora de um<dataset> tag, esse valor de nThreads é usado.
- Caso contrário, 1 thread é usado, que é uma escolha segura, uma vez que usa a menor quantidade de memória.

Pelo original original ERDDAP™ instalação , usamos <nTableThreads> 6</nTableThreads> (É um servidor poderoso.) Os pedidos difíceis agora levam 30% do tempo anterior.

Uso de Recursos do Monitor

Quando você está experimentando com diferentes configurações nThreads (e talvez fazendo pedidos de amostra difíceis para o seu ERDDAP ) , você pode monitorar o uso de recursos do seu computador:

Em Macs, use o Finder : Aplicações : Utilitários : Monitor de Atividade
No Linux, use o topo
No Windows 10, use Ctrl + Shift + Esc para abrir o Gerenciador de tarefas

Aviso: Diminuição da responsabilidade

Em isolamento, ERDDAP™ cumprirá uma solicitação para um conjunto de dados com uma configuração mais alta de nThreads mais rápido do que se nThreads=1. Mas enquanto esse pedido está sendo processado, outras solicitações de outros usuários serão um pouco lotadas e obter uma resposta mais lenta. Também, quando ERDDAP™ responde a uma determinada solicitação, outros recursos de computação (por exemplo, acesso de unidade de disco, largura de banda de rede) pode ser limitante, especialmente com configurações mais altas do nThreads. Assim, com configurações nThreads mais altas, a capacidade de resposta geral do sistema será pior quando houver várias solicitações sendo processadas - isso pode ser muito irritante para os usuários! Devido a isso: nunca definir nThreads para mais do que o número de núcleos de CPU no computador. nThreads=1 é a configuração mais justa desde cada solicitação (entre várias solicitações simultâneas) terá uma parcela igual de recursos de computação. Mas quanto mais poderoso o computador, menos este será um problema.

Atenção: Memória superior Uso para EDDGrid Conjuntos de dados

O uso de memória durante o processamento de pedidos é diretamente proporcional à configuração nThreads. Uma regra razoavelmente segura do polegar é: você precisa definir ERDDAP configurações de memória para pelo menos 2GB + (2GB \* nTreads) . Alguns pedidos para alguns conjuntos de dados precisarão de mais memória do que isso. Por exemplo, definir nThreads=3 para qualquer EDDGrid dataset significa que a configuração -Xmx deve ser pelo menos -Xmx8000M. Se essa configuração de memória é maior que 3/4 a memória física do computador, diminua a configuração nThreads para que você possa diminuir a configuração de memória.

O uso de memória de pedidos de processamento de threads para conjuntos de dados EDDTable é quase sempre menor porque os arquivos são geralmente muito menores. No entanto, se um dado conjunto de dados EDDTable tiver enorme (por exemplo, >=1 GB) arquivos de dados, então os comentários acima serão aplicados a esses conjuntos de dados também.

Seja qual for a configuração nThreads, fique de olho nas estatísticas de uso de memória em seu ERDDAP Página de status . Você nunca deve chegar perto de maximizar o uso da memória em ERDDAP ; caso contrário haverá erros e falhas graves.

Temporariamente definido para 1

Se o uso atual da memória é ainda ligeiramente alto, ERDDAP™ irá definir nThreads para este pedido para 1. Assim, ERDDAP™ conserva a memória quando a memória é escassa.

Diminuindo Retornos

Há retornos diminuindo para aumentar a configuração nThreads: 2 threads serão muito melhores do que 1 (se ignorarmos overclocking dinâmico) . Mas 3 será apenas um pedaço melhor que 2. E 4 serão apenas marginalmente melhores do que 3.

Em um teste de uma consulta difícil para um grande conjunto de dados EDDTable, o tempo de resposta usando 1, 2, 3, 4, 5, 6 threads foi 38, 36, 20, 18, 13, 11 segundos. (Agora usamos nTableThreads=6 nesse servidor.)

NThreads=2: Embora, muitas vezes há um benefício significativo para especificar nThreads=2 em vez de nThreads=1, muitas vezes não fará muita diferença no tempo do relógio necessário para responder a um pedido de um determinado usuário. A razão é: com nThreads=1, a maioria da CPU moderna muitas vezes dinamicamente overclock (impulso turbo) para aumentar temporariamente a velocidade do relógio da CPU. Assim, com nThreads=1, o um núcleo muitas vezes estará trabalhando em uma velocidade de clock maior do que cada um dos dois núcleos se você usou nThreads=2. Independentemente disso, ainda achamos que é melhor usar nThreads=2 em vez de nThreads=1, uma vez que essa configuração irá produzir melhores resultados em uma variedade mais ampla de situações. E, claro, se o seu computador possui núcleos de CPU suficientes, uma configuração de nThreads ainda maior deve produzir melhores resultados.

Como discutido acima, as configurações de nThreads muito altas podem levar a respostas mais rápidas a alguns pedidos, mas o risco de redução geral ERDDAP™ capacidade de resposta e uso de alta memória (como observado acima) enquanto esses pedidos estão sendo processados significa que geralmente não é uma boa ideia.

CPU Núcleos

Você nunca deve definir nThreads para um número maior do que o número de núcleos de CPU na CPU do computador. Essencialmente, todas as CPUs modernas têm múltiplos núcleos (por exemplo, 2, 4 ou 8) . Alguns computadores têm até várias CPUs (por exemplo, 2 CPUs \* 4 núcleos/CPU = 8 núcleos de CPU) . Para descobrir quantos CPUs e núcleos um computador tem:

Em Macs, use Chave de opção : Apple Menu : Informações do Sistema
No Linux, use cat /proc/cpuinfo
No Windows 10, use Ctrl + Shift + Esc para abrir Gerenciador de tarefas : Desempenho (Processadores lógicos mostram o número total de núcleos de CPU)

Sim, a maioria dos processadores nos dias de hoje dizem que suportam 2 fios por núcleo (via via via via hiperthreading ) , mas os 2 threads compartilham recursos de computação, então você não verá o dobro da taxa de transferência em uma CPU sob carga pesada. Por exemplo, um computador com uma CPU com 4 núcleos pode reivindicar para suportar até 8 threads, mas você nunca deve exceder nThreads=4 nisso ERDDAP . Lembre-se que:

A configuração nThreads em ERDDAP™ é por solicitação. ERDDAP™ muitas vezes lida com várias solicitações simultaneamente.
ERDDAP™ faz coisas que não sejam solicitações de processo, por exemplo, recarregar conjuntos de dados.
Quando ERDDAP™ responde a uma determinada solicitação, outros recursos de computação (por exemplo, acesso de unidade de disco, largura de banda de rede) pode ser limitante. Quanto maior você definir nThreads, mais provável que esses outros recursos serão maximizados e retardarão ERDDAP A resposta geral.
O sistema operacional faz outras coisas além de executar ERDDAP .

Então é melhor não definir a configuração nThreads para mais do que o número de núcleos na CPU do computador.

Sua Quilometragem Maio Vary (YMMV)

Os resultados de diferentes configurações de nThreads variam muito para diferentes solicitações para diferentes conjuntos de dados em diferentes sistemas. Se você realmente quer saber o efeito de diferentes configurações nThreads, execute testes realistas.

Por que nThreads por solicitação?

Eu posso ouvir alguns de vocês pensando "Por que nThreads por solicitação? Se eu estivesse codificando isso, eu usaria um pool de threads de trabalhadores permanentes e uma fila de mensagens para melhor desempenho." O problema com a utilização de um conjunto de threads de trabalhadores e uma fila de mensagens é que um pedido difícil inundaria a fila com inúmeras tarefas lentas. Isso seria um bloqueio eficaz. ERDDAP™ de até mesmo iniciar o trabalho em tarefas relacionadas a outros pedidos até que o pedido inicial foi (essencialmente) Acabou. Assim, mesmo pedidos subseqüentes simples responderiam super lentamente. ERDDAP O uso de nThreads por solicitação leva a um uso muito mais justo de recursos de computação.

nThreads vs. vários computadores do trabalhador

Infelizmente, ERDDAP 's nThreads sistema nunca será tão eficaz como verdadeiro paralelo através de vários computadores trabalhadores, com cada um trabalhando em um pedaço de dados, na maneira que Hadoop ou Apache Spark são geralmente usados. Quando a tarefa é verdadeiramente paralela/distribuída a vários computadores, cada computador pode usar todos os seus recursos na sua parte da tarefa. Com ERDDAP 's nThreads sistema, cada um dos fios está competindo para a largura de banda do mesmo computador, drives de disco, memória, etc. Infelizmente, a maioria de nÃ£o tem recursos ou fundos para configurar ou mesmo alugar (na Amazon Web Services (AWS) ou Google Cloud Platform (GCP) ) enormes redes de computadores. Além disso, ao contrário de um banco de dados relacional que é permitido retornar as linhas de resultados em qualquer ordem, ERDDAP™ faz uma promessa de retornar as linhas de resultados em uma ordem consistente. Esta restrição faz ERDDAP 's nThreads implementação menos eficiente. Mas... ERDDAP 's nThreads é útil em muitos casos.

No entanto, há maneiras de fazer ERDDAP™ escala para lidar com um grande número de pedidos rapidamente, estabelecendo um grade/cluster/federação de ERDDAP S .

<paletas >

Começar com ERDDAP™ versão 2.12, datasets.xml pode incluir um<paletas> tag (dentro<erddapDatasets>) que substitui o<paletas> valor de tag de mensagens.xml (ou reverte para o valor message.xml se a tag in datasets.xml está vazio) . Isso permite que você altere a lista de paletas disponíveis enquanto ERDDAP™ está a correr. Ele também permite que você faça uma mudança e tê-lo persistir quando você instalar uma nova versão de ERDDAP . WARNING: As paletas listadas em datasets.xml deve ser um superset das paletas listadas em mensagens.xml; caso contrário ERDDAP™ vai lançar uma exceção e parar de processamento datasets.xml . Isso garante que tudo ERDDAP™ instalações pelo menos suportam as mesmas paletas principais. ATENÇÃO: ERDDAP™ verifica se os arquivos de paletas especificados em mensagens.xml realmente existem, mas não verifica os arquivos de paleta listados em datasets.xml . É sua responsabilidade garantir que os arquivos estão presentes.

Também começando com ERDDAP™ versão 2.12, se você fizer um subdiretório cptfiles no ERDDAP™ diretório de conteúdo, ERDDAP™ copiará todos os arquivos \*.cpt nesse diretório no \[ Toca a brincar. \] /webapps/erddap/WEB-INF/cptfiles diretório cada vez ERDDAP™ Começa. Assim, se você colocar arquivos cpt personalizados nesse diretório, esses arquivos serão usados por ERDDAP™ , sem esforço extra em sua parte, mesmo quando você instala uma nova versão de ERDDAP .

AVISO: Se você adicionar paletas personalizadas ao seu ERDDAP™ tu tens EDDGrid FromErddap e/ou EDDTableDe conjuntos de dados Erddap em seu ERDDAP™ , então os usuários verão suas opções de paleta personalizadas ERDDAP™ Faça um gráfico páginas da web, mas se o usuário tentar usá-los, eles obterão um gráfico com o padrão (geralmente arco-íris) paleta. Isso porque a imagem é feita pelo controle remoto ERDDAP™ que não tem a paleta personalizada. As únicas soluções agora são para enviar um e-mail remoto ERDDAP™ administrador para adicionar suas paletas personalizadas ao seu ERDDAP ou e-mail Chris. John noaa.gov para pedir que as paletas sejam adicionadas ao padrão ERDDAP™ distribuição.

<onChange >

Não. ** <sobre a mudança ** ] (#onchange #) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml que especifica uma ação que será feita quando este conjunto de dados for criado (quando ERDDAP™ é reiniciado) e sempre que este conjunto de dados muda de qualquer forma.
- Atualmente, para EDDGrid subclasses, qualquer mudança para metadados ou para uma variável eixo (por exemplo, um novo ponto de tempo para dados próximos do tempo real) é considerado uma mudança, mas uma recarga do conjunto de dados não é considerada uma mudança (por si só) .
- Atualmente, para subclasses EDDTable, qualquer recarga do conjunto de dados é considerada uma mudança.
- Atualmente, apenas dois tipos de ações são permitidas:
  - "http://"ou "https://"- ... Se a ação começar com "http://"ou "https://", ERDDAP™ vai enviar um HTTP GET solicitar a URL especificada. A resposta será ignorada. Por exemplo, a URL pode dizer a algum outro serviço web para fazer algo.
    - Se a URL tiver uma parte de consulta (depois do "?) , deve ser já por cento codificado . Você precisa codificar caracteres especiais nas restrições (diferente do inicial '&' e o principal '=' em restrições) na forma %HH, onde HH é o valor hexadecimal de 2 dígitos do personagem. Normalmente, você só precisa converter alguns dos caracteres de pontuação: % em %25, & em %26, " em %22,<em %3C, = em %3D, > em %3E, + em %2B, | em %7C, \[ em %5B, \] em %5D, espaço em %20, e converter todos os caracteres acima #127 em sua forma UTF-8 e, em seguida, por cento codificar cada byte da forma UTF-8 no formato %HH (pedir ajuda a um programador) . Por exemplo, & stationID > = 41004 torna-se & nbsp; stationID %3E =%2241004%22 A codificação por cento é geralmente necessária quando você acessa ERDDAP via software diferente de um navegador. Os navegadores geralmente lidam com a codificação por cento para você. Em algumas situações, você precisa codificar por cento todos os caracteres que não A-Za-z0-9\_-!.~ ' () \*, mas ainda não codifica a inicial '&' ou a principal '=' em restrições. Linguagens de programação têm ferramentas para fazer isso (por exemplo, ver Java ' java.net.URLEncoder e Java O script é [encodeURIComponent()] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) ) e há sites que por cento codificar / decodificar para você .
    - Desde então datasets.xml é um arquivo XML, você MUST também &-encode ALL '&', '<', e '>' na URL como ' &', '<', and '>' after percent encoding.
    - Exemplo: Para uma URL que você pode digitar em um navegador como: https://www.company.com/webService?department=R%26D&param2=value2
      Você deve especificar um<onChange> tag via (em uma linha)
    <onChange>https://www.company.com/webService?department=R%26D&param2=value2</onChange>
  - para: - ... Se a ação começar com "mailto:", ERDDAP™ enviará um e-mail para o endereço de e-mail subsequente indicando que o conjunto de dados foi atualizado / alterado. Por exemplo:<onChange>mail para:john.smith@company.com</onChange> Se você tem uma boa razão para ERDDAP™ para apoiar algum outro tipo de ação, envie-nos um e-mail descrevendo o que você quer.
- Esta tag é OPTIONAL. Pode haver tantas etiquetas como quiser. Use uma dessas tags para cada ação a ser executada.
- Isto é análogo ERDDAP sistema de assinatura por e-mail/URL, mas essas ações não são armazenadas persistentemente (ou seja, eles são apenas armazenados em um objeto EDD) .
- Para remover uma assinatura, basta remover o<tag onChange>. A mudança será notada na próxima vez que o conjunto de dados for recarregado.

<reloadEveryNMinutes >

Não. ** <recarregar Cada NMinuts> ** ] (#reloadeverynminutes) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml de quase todos os tipos de conjuntos de dados que especificam com que frequência o conjunto de dados deve ser recarregado. Por exemplo,
```
<reloadEveryNMinutes>60</reloadEveryNMinutes>
```
- Geralmente, conjuntos de dados que mudam frequentemente (por exemplo, obter novos arquivos de dados) deve ser recarregado frequentemente, por exemplo, a cada 60 minutos.
- Os conjuntos de dados que mudam raramente devem ser recarregados com frequência, por exemplo, a cada 1440 minutos (diariamente) ou 10080 minutos (semanal semanal semanal) .
- Esta tag é OPTIONAL, mas recomendado. O padrão é 10080.
- Um exemplo é:<reloadEveryNMinuts>1440</recarregar Cada NMinuts>
- Quando um conjunto de dados é recarregado, todos os arquivos no Diretriz de grande porte /cache / * datasetID * diretório são excluídos.
- Não importa o que isso esteja definido, um conjunto de dados não será carregado mais frequentemente do que<loadDatasetsMinMinutes> (default = 15) , conforme especificado em setup.xml . Então, se você quiser que os conjuntos de dados sejam recarregados com muita frequência, você precisa definir ambos recarregar EveryNMinutes e carregarDatasets MinMinutes a pequenos valores.
- Não configure reloadEveryNMinutes para o mesmo valor que loadDatasets MinMinutes, porque o tempo decorrido é provável que seja (por exemplo) 14:58 ou 15:02, assim o conjunto de dados só será recarregado em cerca de metade das principais recargas. Em vez disso, use um menor (por exemplo, 10) ou maior (por exemplo, 20) recarregar Cada NMinutes valor.
- Independentemente da recarga EveryNMinutes, você pode dizer manualmente ERDDAP™ para recarregar um conjunto de dados específico o mais rapidamente possível através de um arquivo de bandeira .
- Para programadores curiosos -- em ERDDAP™ , a recarga de todos os conjuntos de dados é tratada por dois fios únicos. Um fio inicia uma pequena recarga se encontrar um arquivo de bandeira ou uma grande recarga (que verifica todos os conjuntos de dados para ver se eles precisam ser recarregados) . O outro thread faz a recarga real dos conjuntos de dados um de cada vez. Esses threads funcionam em segundo plano, garantindo que todos os conjuntos de dados sejam mantidos atualizados. O fio que realmente faz as recargas prepara uma nova versão de um conjunto de dados, em seguida, swap-lo no lugar (essencialmente substituindo a versão antiga atomicamente) . Então é muito possível que a seguinte sequência de eventos ocorra (É uma coisa boa.) :
  1. ERDDAP™ começa a recarregar um conjunto de dados (fazendo uma nova versão) no fundo.
  2. O usuário 'A' faz um pedido para o conjunto de dados. ERDDAP™ usa a versão atual do conjunto de dados para criar a resposta. (Isso é bom. Não houve atraso para o usuário, e a versão atual do conjunto de dados nunca deve ser muito estável.)
  3. ERDDAP™ termina criando a nova versão recarregada do conjunto de dados e swaps que nova versão em produção. Todos os novos pedidos subsequentes são tratados pela nova versão do conjunto de dados. Para consistência, o pedido do usuário A ainda está sendo preenchido pela versão original.
  4. O usuário 'B' faz um pedido para o conjunto de dados e ERDDAP™ usa a nova versão do conjunto de dados para criar a resposta.
  5. As solicitações do usuário A e do usuário B são concluídas (talvez A's termina primeiro, talvez B's termina primeiro) .

Consigo ouvir alguém a dizer: "Só dois trilhos! Ha! Isso é coxo! Ele deve configurar isso para que o recarregamento de conjuntos de dados use tantos fios como são necessários, então tudo é feito mais rápido e com pouco ou nenhum atraso." Sim e não. O problema é que carregar mais de um conjunto de dados de cada vez cria vários novos problemas difíceis. Todos eles precisam ser resolvidos ou tratados. O sistema atual funciona bem e tem problemas gerenciáveis (por exemplo, potencial para lag antes que uma bandeira seja notada) . (Se você precisar de ajuda para gerenciá-los, consulte nosso seção sobre como obter suporte adicional .) O relacionado atualização CadaNMillis . sistema funciona dentro de threads de resposta, assim que pode e leva a vários conjuntos de dados sendo atualizados (não a recarga completa) simultaneamente.

Proativo vs. Reativo

ERDDAP O sistema de recarga é proativo -- os conjuntos de dados são recarregados logo após a sua recarga Cada vez que o tempo está pronto (ou seja, eles se tornam "stale", mas nunca muito stale) , se o conjunto de dados está recebendo pedidos de usuários ou não. Então... ERDDAP™ datasets são sempre atualizados e prontos para uso. Isso é em contraste com a abordagem reativa do THREDDS: o pedido de um usuário é o que diz ao THREDDS para verificar se um conjunto de dados é estável (pode ser muito estável) . Se for obsoleto, o THREDDS faz o usuário esperar (muitas vezes por alguns minutos) enquanto o conjunto de dados é recarregado.

<atualização EveryNMillis >

Não. ** <updateEveryNMillis> ** ] (#updateeverynmillis #) é uma tag OPTIONAL dentro de uma<dataset> tag in datasets.xml de alguns tipos de conjuntos de dados que ajudam ERDDAP™ trabalhar com conjuntos de dados que mudam muito frequentemente (tão frequentemente quanto cada segundo) . Ao contrário ERDDAP É normal, proactivo,<recarregar Cada NMinutes> (#reloadeverynminutes) sistema para recarregar completamente cada conjunto de dados, este sistema adicional OPTIONAL é reativo (acionado por uma solicitação de usuário) e mais rápido porque é incremental (apenas atualizando as informações que precisam ser atualizadas) . Por exemplo, se um pedido para um EDDGrid O conjunto de dados do FromDap ocorre mais do que o número especificado de milissegundos desde a última atualização, ERDDAP™ vai ver se existem novos valores para a esquerda (primeiro, geralmente "time" ) dimension e, se assim for, basta baixar esses novos valores antes de lidar com o pedido do usuário. Este sistema é muito bom em manter um conjunto de dados em rápida mudança up-to-date com demandas mínimas sobre a fonte de dados, mas ao custo de retardar ligeiramente o processamento de algumas solicitações de usuário.
- Para usar este sistema, adicione (por exemplo) :
```
<updateEveryNMillis>1000</updateEveryNMillis>  
```

logo após o<reloadEveryNMinuts> tag para o conjunto de dados em datasets.xml . O número de milissegundos que você especificar pode ser tão pequeno quanto 1 (para garantir que o conjunto de dados esteja sempre atualizado) . Um valor de 0 (o padrão) ou um número negativo desliga o sistema.

Devido à sua natureza incremental, as atualizações devem terminar muito rapidamente, para que os usuários nunca devem esperar muito tempo.
Se uma segunda solicitação de dados chegar antes da atualização anterior terminar, a segunda solicitação não irá ativar outra atualização.
Ao longo da documentação, tentaremos usar a palavra "recarregar" para recargas regulares e completas de conjuntos de dados e "update" para essas novas atualizações incrementais e parciais.
Para fins de teste, alguns diagnósticos são impressos para log.txt se [<logLevel> (#loglevel) em datasets.xml está definido para "todos".
Se você usar atualizações incrementais e especialmente se a esquerda (Primeiro) , por exemplo, tempo, eixo é grande, você pode querer definir<reloadEveryNMinutes> para um número maior (1440?) , de modo que as atualizações fazem a maior parte do trabalho para manter o conjunto de dados atualizado, e recargas completas são feitas com freqüência.
Nota: este novo sistema de atualização atualiza metadados (por exemplo, tempo actual\_range , time\_coverage\_end, ...) mas não dispara noChange (URL de e-mail ou toque) ou alterar a RSS alimentação (Talvez devesse...) .
Para todos os conjuntos de dados que usam subclasses de EDDGrid Dos quartos e Tabela EDD dos arquivos :
- ATENÇÃO: quando você adiciona um novo arquivo de dados a um conjunto de dados copiando-o no diretório que ERDDAP™ olha para, há um perigo que ERDDAP™ vai notar o arquivo parcialmente escrito; tentar lê-lo, mas falhar porque o arquivo é incompleto; declarar o arquivo para ser um arquivo "maio" e removê-lo (temporariamente) do conjunto de dados. Para evitar isso, nós RECOMENDAMENTE ESTRAMENTE que você copie um novo arquivo no diretório com um nome temporário (por exemplo, 20150226 .nc TEMPO) que não corresponde ao arquivo de conjuntos de dados NomeRegex (\*\\ .nc ) , então renomeie o arquivo para o nome correto (por exemplo, 20150226 .nc ) . Se você usar essa abordagem, ERDDAP™ irá ignorar o arquivo temporário e apenas notar o arquivo corretamente nomeado quando estiver completo e pronto para ser usado.
- Se você modificar arquivos de dados existentes no lugar (por exemplo, para adicionar um novo ponto de dados) ,<updateEveryNMillis> funcionará bem se as mudanças aparecerem atomicamente (em um instante) e o arquivo é sempre um arquivo válido. Por exemplo, a biblioteca netcdf-java permite adições à dimensão ilimitada de um "clássico" .nc arquivo v3 a ser feito atomicamente. <updateEveryNMillis> funcionará mal se o arquivo é inválido enquanto as alterações estão sendo feitas.
- <updateEveryNMillis> funcionará bem para conjuntos de dados onde um ou alguns arquivos mudam em um curto período de tempo.
- <updateEveryNMillis> trabalhará mal para conjuntos de dados onde um grande número de arquivos muda em um curto período de tempo (a menos que as alterações apareçam atomicamente) . Para esses conjuntos de dados, é melhor não usar<updateEveryNMillis> e para definir um bandeira para contar ERDDAP™ para recarregar o conjunto de dados.
- <updateEveryNMillis> não atualiza as informações associadas ao [< subsetVariables > (#subsetvariables) . Normalmente, isso não é um problema, porque o subsetVariables ter informações sobre coisas que não mudam muito (por exemplo, a lista de nomes de estações, latitudes e longitudes) . Se o subsetVariables alterações de dados (por exemplo, quando uma nova estação é adicionada ao conjunto de dados) , em seguida, contate o URL da bandeira para o conjunto de dados para contar ERDDAP™ para recarregar o conjunto de dados. Caso contrário, ERDDAP™ não vai notar o novo subconjunto Informações variáveis até a próxima vez que o conjunto de dados for recarregado (<reloadEveryNMinutes>).
- Nossa recomendação genérica é usar:
```
    <reloadEveryNMinutes>1440</reloadEveryNMinutes>  
    <updateEveryNMillis>10000</updateEveryNMillis>
```
- TROUBLE? Em computadores Linux, se você estiver usando<updateEveryNMillis> com EDDGrid FromFiles ou EDDTableFromFiles classes, você pode ver um problema onde um conjunto de dados não consegue carregar (ocasionalmente ou consistentemente) com a mensagem de erro: "IOException: limite de usuário de inotify instâncias alcançadas ou muitos arquivos abertos". A causa pode ser um erro Java o que faz inotificar instâncias para não ser lixo coletado. Este problema é evitado em ERDDAP™ v1.66 e superior. Então a melhor solução é mudar a versão mais recente de ERDDAP . Se isso não resolver o problema (isto é, se você tem um grande número de conjuntos de dados usando<updateEveryNMillis>), você pode corrigir este problema chamando:
```
sudo sysctl fs.inotify.max\\_user\\_watches=65536  
sudo sysctl fs.inotify.max\\_user\\_instances=1024  
sudo sysctl -p  
```

Ou, use números mais altos se o problema persistir. O padrão para relógios é 8192. O padrão para instâncias é 128.

Você pode colocar<updateMaxEvents>10</updateMaxEvents> em datasets.xml (com as outras configurações perto da parte superior) para alterar o número máximo de alterações de arquivo (padrão=10) que será processado pelo sistema updateEveryNMillis. Um número maior pode ser útil para o conjunto de dados onde é muito importante que eles sejam mantidos sempre atualizados. Ver atualizarMáxEventos documentação .
Para programadores curiosos -- essas atualizações incrementais, ao contrário ERDDAP Está cheio. recarregar Cada um dos Minuts sistema, ocorrer dentro de threads de solicitação de usuário. Assim, qualquer número de conjuntos de dados pode ser atualizado simultaneamente. Há código (e uma fechadura) para garantir que apenas um thread está trabalhando em uma atualização para qualquer conjunto de dados em qualquer momento. Permitir múltiplas atualizações simultâneas foi fácil; permitir múltiplas recargas completas simultâneas seria mais difícil.

<sourceCanConstrainStringEQNE>

Não. ** <fonteCanConstrainStringEQNE> ** ] (#sourcecanconstrainstringqne) é uma tag OPTIONAL dentro de uma tabela EDD<dataset> tag in datasets.xml que especifica se a fonte pode restringir as variáveis String com os operadores = e !=.
- Para EDDTableFromDapSequence, isso se aplica apenas às variáveis de sequência externa String. Assume-se que a fonte não pode lidar com quaisquer restrições em variáveis de sequência interna.
- Esta tag é OPTIONAL. Os valores válidos são verdadeiros (o padrão) e falso.
- Para EDDTable FromDapSequence OPeNDAP Servidores DRDS, isso deve ser definido como verdadeiro (o padrão) .
- Para EDDTable FromDapSequence Servidores Dapper, isso deve ser definido como falso.
- Um exemplo é:

        <sourceCanConstrainStringEQNE>true</sourceCanConstrainStringEQNE>

<sourceCanConstrainStringGTLT >

Não. ** <fonteCanConstrainStringGTLT> ** ] (#sourcecanconstrainstringgtlt) é uma tag OPTIONAL dentro de uma tabela EDD<dataset> tag que especifica se a fonte pode restringir variáveis String com a<,<=, > e >= operadores.
- Para EDDTableFromDapSequence, isso se aplica apenas às variáveis de sequência externa String. Assume-se que a fonte não pode lidar com quaisquer restrições em variáveis de sequência interna.
- Os valores válidos são verdadeiros (o padrão) e falso.
- Esta tag é OPTIONAL. O padrão é verdadeiro.
- Para EDDTable FromDapSequence OPeNDAP Servidores DRDS, isso deve ser definido como verdadeiro (o padrão) .
- Para EDDTable FromDapSequence Servidores Dapper, isso deve ser definido como falso.
- Um exemplo é:

        <sourceCanConstrainStringGTLT>true</sourceCanConstrainStringGTLT>

<sourceCanConstrainStringRegex >

Não. ** <fonteCanConstrainStringRegex> ** ] (#sourcecanconstrainstrtrainregex) é uma tag OPTIONAL dentro de uma tabela EDD<dataset> tag que especifica se a fonte pode restringir variáveis String por expressões regulares, e se assim for, o que o operador é.
- Os valores válidos são "=~~" (o DAP padrão) , "~~=" (equivocadamente apoiado por muitos DAP servidores) ou " (indicando que a fonte não suporta expressões regulares) .
- Esta tag é OPTIONAL. O padrão é ".
- Para EDDTable FromDapSequence OPeNDAP Servidores DRDS, isso deve ser definido para "" (o padrão) .
- Para EDDTable FromDapSequence Servidores Dapper, isso deve ser definido para "" (o padrão) .
- Um exemplo é:

        <sourceCanConstrainStringRegex>=~</sourceCanConstrainStringRegex>

<sourceCanDoDistinct >

Não. ** <sourceCanDoDistinct> ** ] (Tradução e Revisão:) é uma tag OPTIONAL dentro de uma EDDTableFromDatabase<dataset> tag que especifica se o banco de dados de origem deve lidar com &distinct () restrições em consultas de usuário.
- Esta tag é OPTIONAL. Valores válidos não são ( ERDDAP™ manipula distinta; o padrão) , parcial (a fonte lida distinta e ERDDAP™ lida com ele novamente) e sim (a fonte lida distinta) .
- Se você estiver usando não e ERDDAP™ está ficando sem memória quando manuseando distinto, use sim.
- Se você estiver usando sim e o banco de dados de origem lida distinta muito lentamente, use não.
- parcial dá-lhe o pior de ambos: é lento porque o tratamento de banco de dados de distinto é lento e pode ficar sem memória em ERDDAP .
- Bancos de dados interpretam DISTINCT como um pedido para apenas linhas únicas de resultados, enquanto ERDDAP™ interpreta-o como um pedido para uma lista ordenada de linhas únicas de resultados. Se você definir isso para parcial ou sim, ERDDAP™ automaticamente também diz ao banco de dados para classificar os resultados.
- Uma pequena diferença nos resultados: Sem | parcial, ERDDAP™ vai classificar "" no início dos resultados (antes de não-" cordas) . Com sim, o banco de dados pode (Postgres vai) sort "" no final dos resultados (após strings não-") . Vou adivinhar que isso também afetará a classificação de palavras curtas versus palavras mais longas que começam com a palavra curta. Por exemplo, ERDDAP™ vai classificar "Simon" antes "Simons".
- Um exemplo é:

        <sourceCanDoDistinct>yes</sourceCanDoDistinct>

<sourceCanOrderBy >

Não. ** <fonte CanOrderBy> ** ] (#sourcecanorderby) é uma tag OPTIONAL dentro de uma EDDTableFromDatabase<dataset> tag que especifica se o banco de dados de origem deve lidar & orderBy (...) restrições em consultas de usuário.
- Esta tag é OPTIONAL. Valores válidos não são ( ERDDAP™ cabos orderBy (...) ; o padrão) , parcial (a fonte lida orderBy e ERDDAP™ lida com ele novamente) e sim (a fonte lida orderBy (...) ) .
- Se você estiver usando não e ERDDAP™ está ficando sem memória ao lidar orderBy (...) Usa sim.
- Se você estiver usando sim e o banco de dados de origem lida orderBy (...) demasiado lentamente, use não.
- parcial dá-lhe o pior de ambos: é lento porque o tratamento de banco de dados de orderBy (...) é lento e pode ficar sem memória em ERDDAP .
- Uma pequena diferença nos resultados: Sem | parcial, ERDDAP™ vai classificar "" no início dos resultados (antes de não-" cordas) . Com sim, o banco de dados pode (Postgres vai) sort "" no final dos resultados (após strings não-") . Isso também pode afetar a classificação de palavras curtas versus palavras mais longas que começam com a palavra curta. Por exemplo, ERDDAP™ vai classificar "Simon" antes de "Simons", mas eu não tenho certeza sobre como um banco de dados irá classificá-los.
- Um exemplo é:

        <sourceCanOrderBy>yes</sourceCanOrderBy>

<sourceNeedsExpandedFP\_EQ>

Não. ** <fonteNeedsExpandedFP\_EQ> ** ] (#sourceneedsexpandedfp_eq) é uma tag OPTIONAL dentro de uma tabela EDD<dataset> tag que especifica (verdadeiro (o padrão) ou falso) se a fonte precisa de ajuda com consultas com<numérico Variável<flutuantePointValue> (e!=, >=,<=). Por exemplo,
```
<sourceNeedsExpandedFP\\_EQ>false</sourceNeedsExpandedFP\\_EQ>
```
- Para algumas fontes de dados, consultas numéricas envolvendo =,=,<=, ou >= pode não funcionar como desejado com números de ponto flutuante. Por exemplo, uma busca por longitude=220.2 pode falhar se o valor for armazenado como 220.20000000000001.
- Este problema surge porque os números de ponto flutuante são não representado exatamente dentro de computadores .
- Se fonteNeedsExpandedFP\_EQ é definido como verdadeiro (o padrão) , ERDDAP™ modifica as consultas enviadas para a fonte de dados para evitar esse problema. É sempre seguro e bom deixar este conjunto verdadeiro.

< sourceUrl >

Não. ** < sourceUrl > ** ] (#sourceurl) é uma tag comum dentro de um conjunto de dados global< addAttributes > tag que especifica a URL que é a fonte dos dados.
- Um exemplo é:
```
    <sourceUrl>https://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/VH/chla/1day</sourceUrl>  
```
(mas coloque tudo em uma linha)
- Em ERDDAP™ , todos os conjuntos de dados terão um " sourceUrl " nos atributos globais combinados que são mostrados aos usuários.
- Para a maioria dos tipos de conjuntos de dados, esta tag é REQUIRED. Veja a descrição do tipo de conjunto de dados para descobrir se isso é REQUIREDO ou não.
- Para alguns conjuntos de dados, o separado< sourceUrl > tag não é permitido. Em vez disso, você deve fornecer um " sourceUrl " atributo global , geralmente no global \> addAttributes <. Se não houver URL de origem real (por exemplo, se os dados são armazenados em arquivos locais) , este atributo muitas vezes apenas tem um valor de placeholder, por exemplo,<nome do att="name"> (arquivos locais) </att> .
- Para a maioria dos conjuntos de dados, esta é a base da URL que é usada para solicitar dados. Por exemplo, DAP servidores, este é o URL para o qual .dods, .das, .dds, ou .html pode ser adicionado.
- Desde então datasets.xml é um arquivo XML, você MUST também codificar '&', '<', e '>' na URL como ' &', '<', e ' >'.
- Para a maioria dos tipos de conjuntos de dados, ERDDAP™ adiciona o original sourceUrl (o "localSourceUrl" no código fonte) ao atributos globais (onde se torna o "publicSourceUrl" no código fonte) . Quando a fonte de dados é arquivos locais, ERDDAP™ adiciona sourceUrl = (arquivos locais) " aos atributos globais como precaução de segurança. Quando a fonte de dados é um banco de dados, ERDDAP™ adiciona sourceUrl = (base de dados) " aos atributos globais como precaução de segurança. Se alguns dos seus conjuntos de dados usarem não público sourceUrl ' (geralmente porque seu computador está em seu DMZ ou em uma LAN local) você pode usar [<convertToPublicSourceUrl>] (# Convert to publicsourceurl) tags para especificar como converter o local sourceUrl s para o público sourceUrl S.
- A sourceUrl pode começar com http:// , https:// , ftp://, e talvez outros prefixos. https conexões ler e verificar o certificado digital da fonte para garantir que a fonte é quem eles dizem que são. Em casos raros, esta verificação pode falhar com o erro "javax.net.sl.SSLProtocolException: handshake alert: unrecognized\_name". Isso é provavelmente devido ao nome de domínio no certificado que não corresponde ao nome de domínio que você está usando. Você pode e deve ler os detalhes do sourceUrl 's certificado em seu navegador web, notavelmente, a lista de "DNS Name"s na seção "Subject Alternative Name".

Em alguns casos, sourceUrl você está usando pode ser um pseudônimo do nome de domínio no certificado. Por exemplo, https://podaac-opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/vai lançar este erro, mas https://opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/, que usa o nome de domínio no certificado, não vai. A solução nestes casos é, portanto, encontrar e usar o nome de domínio no certificado. Se não o encontrar no certificado, contacte o fornecedor de dados.

Em outros casos, o nome de domínio no certificado pode ser para um grupo de nomes. Se isso ocorrer ou o problema não for possível, por favor envie um e-mail para Chris. John noaa.gov para relatar o problema.

<addAttributes>

Não. ** < addAttributes > ** ] (#addattributes) é uma tag OPTIONAL para cada conjunto de dados e para cada variável que permite ERDDAP Os administradores controlam os atributos de metadados associados a um conjunto de dados e suas variáveis.
- ERDDAP™ combina os atributos da fonte do conjunto de dados ("fonteAttributes") e o " addAttributes "que você define em datasets.xml (que têm prioridade) para fazer o "combinedAttributes", que são o que ERDDAP™ os usuários veem. Assim, você pode usar addAttributes para redefinir os valores do sourceAttributes, adicionar novos atributos ou remover atributos.
- O< addAttributes > tag inclui 0 ou mais ** <- Sim. ** subtags, que são usados para especificar atributos individuais.
- Cada atributo consiste em um nome e um valor (que tem um tipo de dados específico, por exemplo, duplo) .
- Pode haver apenas um atributo com um nome dado. Se houver mais, a última tem prioridade.
- O valor pode ser um único valor ou uma lista separada do espaço de valores.
- Sintaxe
  - A ordem do<subtags att> dentro addAttributes não é importante.
  - O<formato de subtag att> é
```
    <att name="*name*" \\[type="*type*"\\] >*value*</att>
```
  - O nome de destino de todos os atributos DEVE começar com uma letra (A-Z, a-z) e DEVE conter apenas os caracteres A-Z, a-z, 0-9, ou '\_'.
  - Se um<subtag att> não tem valor ou valor de null, esse atributo será removido dos atributos combinados. Por exemplo,<att name="rows" /> irá remover linhas dos atributos combinados. Por exemplo,<int name= "coordenadas">null</att> irá remover coordenadas dos atributos combinados.

atributos Tipo

[O valor do tipo OPTIONAL para<subtags att>] (#attribuídotipo) indica o tipo de dados para os valores. O tipo padrão é String. Um exemplo de um atributo String é:
```
<att name="creator\\_name">NASA/GSFC OBPG</att>
```
- Tipos válidos para valores únicos são bytes (inteiro de 8 bits) , curto (inteiro assinado de 16 bits) , int (32-bit inscrito inteiro) , longo (Inteligente assinado de 64 bits) , flutuar (Ponto flutuante de 32 bits) , duplo (Ponto flutuante de 64 bits) Charlie e String. Por exemplo,
```
<att name="scale\\_factor" type="float">0.1</att>
```

Veja estas notas sobre o Tipo de dados de carvão . Veja estas notas sobre o Tipo de dados longo .

Tipos válidos para listas separadas por espaço de valores (ou valores únicos) são byteList, shortList, unsignedShortList, charList, intList, longList, floatList, double Lista. Por exemplo,
```
<att name="actual\\_range" type="doubleList">10.34 23.91</att>  
```

Um ShortList não assinado permite especificar uma lista de shorts não assinados, mas eles serão convertidos em uma lista dos caracteres Unicode correspondentes (por exemplo, "65 67 69" será convertido em "A C E". Se você especificar um charList, codifique quaisquer caracteres especiais (por exemplo, espaço, citações duplas, backslash,<#32, ou >#127) como você os codificaria na seção de dados de um arquivo NCCSV (por exemplo, ", "\" ou """, "\\", " \n ", "\u20ac") . Não há nenhum cordelista. Armazene os valores String como um String multi-linha. Por exemplo,

<att name="history">2011-08-05T08:55:02Z ATAM - made CF-1.6 compliant.  
2012-04-08T08:34:58Z ATAM - Changed 'height' from double to float.</att>  

Atributos globais

Não. ** Atributos globais / Global< addAttributes > ** ] (Atributos globais) - ... < addAttributes > é uma tag OPTIONAL dentro da<dataset> tag que é usado para alterar atributos que se aplicam a todo o conjunto de dados.
- ** Use o global< addAttributes > para alterar os atributos globais do conjunto de dados. ** ERDDAP™ combina os atributos globais da fonte do conjunto de dados (** Atributos de fonte ) e global addAttributes que você define em datasets.xml (que têm prioridade) para fazer o global Atributos combinados ** , que são o que ERDDAP™ os usuários veem. Assim, você pode usar addAttributes para redefinir os valores do sourceAttributes, adicionar novos atributos ou remover atributos.
- Veja o [ ** < addAttributes > informação] (#addattributes) que se aplica a global e variável < addAttributes > ** .
- FGDC e ISO 19115-2/19139 Metadados - ... Normalmente, ERDDAP™ gerará automaticamente ISO 19115-2/19139 e FGDC (FGDC-STD-001-1998) Arquivos de metadados XML para cada conjunto de dados usando informações dos metadados do conjunto de dados. Então... bons metadados de dataset leva a bom ERDDAP -metadados ISO 19115 e FGDC. Por favor, considere colocar muito tempo e esforço para melhorar os metadados de seus conjuntos de dados (que é uma coisa boa a fazer de qualquer maneira) . A maioria dos atributos de metadados de conjuntos de dados que são usados para gerar os metadados ISO 19115 e FGDC são do Padrão de metadados ACDD e são tão observados abaixo.
- Muitos atributos globais são especiais nisso ERDDAP™ procura-los e usá-los de várias maneiras. Por exemplo, um link para o infoUrl está incluído em páginas web com listas de conjuntos de dados e outros lugares, para que os usuários possam descobrir mais sobre o conjunto de dados.
- Quando um usuário seleciona um subconjunto de dados, globalAttributes relacionados à longitude da variável, latitude, altitude (ou profundidade) , e intervalos de tempo (por exemplo, Southernmost\_Northing, Northernmost\_Northing, time\_coverage\_start, time\_coverage\_end) são gerados ou atualizados automaticamente.
- Uma amostra simples global< addAttributes > é:
```
<addAttributes> 
  <att name="Conventions">COARDS, CF-1.6, ACDD-1.3</att>
  <att name="infoUrl">https://coastwatch.pfeg.noaa.gov/infog/PH\\_ssta\\_las.html</att>
  <att name="institution">NOAA CoastWatch, West Coast Node</att>
  <att name="title">SST, Pathfinder Ver 5.0, Day and Night, Global</att>
  <att name="cwhdf\\_version" />
</addAttributes>  
```

O atributo cwhdf\_version vazio causa o atributo source cwhdf\_version (se houver) para ser removido da lista final, combinada de atributos.

Fornecer esta informação ajuda ERDDAP™ fazer um trabalho melhor e ajuda os usuários a entender os conjuntos de dados. Os bons metadados tornam um conjunto de dados utilizável. Metadados insuficientes tornam um conjunto de dados inútil. Por favor, tome o tempo para fazer um bom trabalho com atributos de metadados.

Atributos globais especiais em ERDDAP™

reconhecimento

reconhecimento e reconhecimento (do ACÓRDÃO padrão de metadados) é uma maneira RECOMENDADA de reconhecer o grupo ou grupos que forneceram apoio (notavelmente, financeira) para o projeto que criou esses dados. Por exemplo,

<att name="acknowledgment">AVISO</att>

Note que ACDD 1.0 e 1.1 usaram a ortografia "conhecimento" (que é a ortografia habitual nos EUA.) , mas ACDD 1.3 mudou isso para "conhecimento" (que é a ortografia habitual no Reino Unido.) . Minha compreensão é que a mudança foi essencialmente um acidente e que eles certamente não reconheceram as ramificações da mudança. Que confusão! Agora existem milhões de arquivos de dados em todo o mundo que têm "conhecimento" e milhões que têm "conhecimento". Isso destaca a loucura das mudanças "simples" em um padrão, e enfatiza a necessidade de estabilidade em padrões. Porque ACDD 1.3 (que é a versão de ACDD que ERDDAP™ suportes) diz "conhecimento", é isso ERDDAP™ (notavelmente Gerar conjuntos de dados Xml) encoraja.

cdm\_altitude\_proxy

cdm\_altitude\_proxy é apenas para conjuntos de dados EDDTable que não têm uma variável de altitude ou profundidade, mas têm uma variável que é um proxy para altitude ou profundidade (por exemplo, pressão, sigma, garrafaNumber) , você pode usar este atributo para identificar essa variável. Por exemplo,

<att name="cdm\\_altitude\\_proxy">pressure</att>

Se o cdm\_data\_type é Perfil ou TrajectoryProfile e não há nenhuma variável de altitude ou profundidade, cdm\_altitude\_proxy MUST ser definido. Se cdm\_altitude\_proxy for definido, ERDDAP™ adicionará os seguintes metadados à variável: \_Coordinate AxisType=Altura e eixo=Z.

cdm\_data\_type

cdm\_data\_type (do ACÓRDÃO padrão de metadados) é um atributo global que indica o Unidata Modelo de dados comum tipo de dados para o conjunto de dados. Por exemplo,

<att name="cdm\\_data\\_type">Point</att>

O CDM ainda está evoluindo e pode mudar novamente. ERDDAP™ cumpre com os relacionados e mais detalhados Geometrias de amostragem discretas (DSG) capítulo do CF 1.6 convenções de metadados (anteriormente denominadas Convenções de Observação de Pontos CF) .

Ou o conjunto de dados global Atributos de fonte ou seu global< addAttributes > MUST incluir o atributo cdm\_data\_type . Alguns tipos de conjunto de dados (como EDDTable De Obis) irá definir isso automaticamente.
Para EDDGrid datasets, as opções cdm\_data\_type são Grid (o padrão e, de longe, o tipo mais comum para EDDGrid conjuntos de dados) , MovingGrid, Outro, Ponto, Perfil, RadialSweep, TimeSeries, TimeSeriesProfile, Swath, Trajectory e TrajectoryProfile. Atualmente, EDDGrid não requer que quaisquer metadados relacionados sejam especificados, nem verifica se os dados correspondem ao cdm\_data\_type. Isso provavelmente mudará no futuro próximo.
EDDTable usa cdm\_data\_type de uma forma rigorosa, seguindo a especificação DSG do CF em vez de CDM, que por alguma razão não foi atualizado para ser consistente com DSG. Se os metadados de um conjunto de dados não estiverem em conformidade com o ERDDAP 's cdm\_data\_type's requirements (ver abaixo) , o conjunto de dados falhará em carregar e gerará um mensagem de erro . (Isso é uma coisa boa, no sentido de que a mensagem de erro lhe dirá o que é errado para que você possa corrigi-lo.) E se os dados do conjunto de dados não corresponderem à configuração dos metadados do conjunto de dados (por exemplo, se houver mais de um valor de latitude para uma determinada estação em um conjunto de dados de séries de tempos) , alguns pedidos de dados retornarão dados incorretos na resposta. Por isso, certifica-te que percebes tudo isto.

Para todos esses conjuntos de dados, nas Convenções e Metadata\_Conventions atributos globais, consulte CF-1.6 (não CF-1.0, 1.1, 1.2, 1.3, 1.4 ou 1.5) , uma vez que CF-1.6 é a primeira versão a incluir as mudanças relacionadas à Geometria de Amostragem Discreta (DSG) convenções.

** ERDDAP™ tem uma relação não-simples com CF DSG**
ERDDAP™ pode fazer um conjunto de dados DSG válido de um conjunto de dados de origem que já é um arquivo DSG válido (S) , ou fora de um conjunto de dados de origem que não é configurado para DSG, mas pode ser feito assim através de alterações de metadados (alguns dos quais são ERDDAP - específica para fornecer uma abordagem mais geral para especificar a configuração do DSG) .
ERDDAP™ faz muitos testes de validade quando carrega um conjunto de dados. Se o conjunto de dados tiver um cdm\_data\_type (ou featureType ) atributos carregados com sucesso ERDDAP™ Então ERDDAP™ está dizendo que o conjunto de dados atende aos requisitos do DSG (caso contrário, ERDDAP™ vai lançar uma exceção explicando o primeiro problema que encontrou) . ATENÇÃO: Um conjunto de dados carregado com sucesso parece atender aos requisitos do DSG (tem a combinação certa de atributos) , mas ainda pode ser incorretamente configurado, levando a resultados incorretos .nc CF e .nc Arquivos de resposta CFMA. (O software é inteligente de algumas maneiras e sem pistas em outros.)
Quando você olha para os metadados do conjunto de dados em ERDDAP™ , o conjunto de dados DSG parece estar dentro ERDDAP O formato interno (uma mesa gigante, semelhante a banco de dados) . Não está em um dos formatos DSG (por exemplo, as dimensões e os metadados não estão certos) , mas as informações necessárias para tratar o conjunto de dados como um conjunto de dados DSG estão nos metadados (por exemplo, cdm\_data\_type=TimeSeries e cdm\_timeseries\_variables= aCsvListOfStationRelatedVarables nos metadados globais e cf\_role=timeseries\_id para alguma variável) .
Se um usuário solicitar um subconjunto do conjunto de dados em um .nc CF (um .nc arquivo no formato de arquivo Contiguous Ragged Array da DSG) ou .nc Arquivo CFMA (um .nc arquivo no formato de arquivo Multidimensional Array da DSG) , esse arquivo será um arquivo CF DSG válido. ATENÇÃO: No entanto, se o conjunto de dados foi configurado incorretamente (para que as promessas feitas pelos metadados não sejam verdadeiras) , então o arquivo de resposta será tecnicamente válido, mas será incorreta de alguma forma.

EDDTable cdm_data_types

Para conjuntos de dados EDDTable, as opções cdm\_data\_type (e requisitos relacionados em ERDDAP ) são

Ponto

Ponto -- é para um conjunto de medidas tomadas em horários e locais não relacionados.
Tal como acontece com todos os cdm\_data\_types que não sejam Outros, os conjuntos de dados de ponto MUST têm variáveis de longitude, latitude e tempo.

Perfil

Perfil -- é um conjunto de medidas todas tomadas ao mesmo tempo, em um local de longitude de latitude, mas em mais de uma profundidade (ou altitude) . O conjunto de dados pode ser uma coleção desses perfis, por exemplo, 7 perfis de diferentes locais. Este cdm\_data\_type não implica qualquer conexão lógica entre qualquer um dos perfis.
Uma das variáveis (por exemplo, profile\_number) MUST ter o atributo variável cf\_role=profile\_id para identificar a variável que identifica exclusivamente os perfis.
```
<att name="cf\\_role">profile\\_id</att>  
```

Se nenhuma outra variável for adequada, considere usar a variável tempo.

cdm\_profile\_variáveis

O conjunto de dados DEVE incluir o globalAttribute cdm\_profile\_variáveis , onde o valor é uma lista separada por vírgula das variáveis que têm a informação sobre cada perfil. Para um determinado perfil, os valores dessas variáveis devem ser constantes. Por exemplo,
```
<att name="cdm\\_profile\\_variables">profile\\_number,time,latitude,longitude</att>
```

A lista DEVE incluir a variável cf\_role=profile\_id e todas as outras variáveis com informações sobre o perfil e tempo, latitude e longitude. A lista nunca incluirá altitude, profundidade ou quaisquer variáveis de observação.

\[ Opinião: cdm\_data\_type=Profile raramente deve ser usado. Na prática, um dado conjunto de dados é geralmente ou um TimeSeriesProfile (perfis em posição fixa) ou um TrajectoryProfile (perfis ao longo de uma trajetória) , e assim deve ser devidamente identificado como tal. \]

Série de Tempo

Série de Tempo -- é uma sequência de medições (por exemplo, temperatura da água do mar) tomado em um, fixo, latitude, longitude, profundidade (ou altitude) localização. (Pense nisso como "estação".) O conjunto de dados pode ser uma coleção destes TimeSeries, por exemplo, uma sequência de cada um de 3 locais diferentes.
Uma das variáveis (por exemplo, station\_id) MUST ter o atributo variável cf\_role=timeseries\_id para identificar a variável que identifica exclusivamente as estações.
```
<att name="cf\\_role">timeseries\\_id</att>
```

cdm\_timeseries\_variables

O conjunto de dados DEVE incluir o globalAttribute cdm\_timeseries\_variables , onde o valor é uma lista separada por vírgula das variáveis que têm a informação sobre cada estação. Para uma determinada estação, os valores dessas variáveis devem ser constantes. Por exemplo,
```
<att name="cdm\\_timeseries\\_variables">station\\_id,station\\_type,latitude,longitude</att>
```

A lista DEVE incluir a variável cf\_role=timeseries\_id e todas as outras variáveis com informações sobre a estação, que quase sempre inclui latitude e longitude (e altitude ou profundidade, se presente) . A lista nunca incluirá tempo ou quaisquer variáveis de observação.

Para alguns buoys amarrados, um conjunto de dados pode ter dois conjuntos de variáveis de latitude e longitude:
1. Um par de valores de latitude e longitude constantes (i.e., a localização fixa da amarração) . Em ERDDAP™ , dar estas variáveis destinationName s de latitude e longitude, e incluem essas variáveis na lista de cdm\_timeseries\_variables.
2. Valores de latitude e longitude precisos associados a cada observação. Em ERDDAP™ , dar estas variáveis diferentes destinationName S (por exemplo, precisoLat e preciso Lon) e não inclua essas variáveis na lista de cdm\_timeseries\_variables. O raciocínio para isso é: de uma perspectiva teórica, para um conjunto de dados DSG TimeSeries, a latitude e longitude (e altitude ou profundidade, se presente) localização da estação Deve ser constante.

TempoSeriesProfile

TempoSeriesProfile -- é para uma sequência de perfis tomados em um, fixo, localização longitude de latitude. Cada perfil é um conjunto de medidas tomadas em múltiplas altitudes ou profundidades. O conjunto de dados pode ser uma coleção destes TimeSeriesProfiles, por exemplo, uma sequência de perfis tomados em cada um dos 12 locais diferentes.
Uma das variáveis (por exemplo, station\_id) MUST ter o atributo variável cf\_role=timeseries\_id para identificar a variável que identifica exclusivamente as estações.

    <att name="cf\\_role">timeseries\\_id</att>

Uma das variáveis (por exemplo, profile\_number) MUST ter o atributo variável cf\_role=profile\_id para identificar a variável que identifica exclusivamente os perfis.
```
<att name="cf\\_role">profile\\_id</att>  
```
(Um determinado perfil\_id só tem de ser único para uma série dada\_id.) Se nenhuma outra variável for adequada, considere usar a variável tempo.
O conjunto de dados DEVE incluir o globalAttribute cdm\_timeseries\_variables, onde o valor é uma lista separada por vírgula das variáveis que têm a informação sobre cada estação. Para uma determinada estação, os valores dessas variáveis devem ser constantes. Por exemplo,
```
<att name="cdm\\_timeseries\\_variables">station\\_id,station\\_type,latitude,longitude</att>
```

A lista DEVE incluir a variável cf\_role=timeseries\_id e todas as outras variáveis com informações sobre a estação, que quase sempre inclui latitude e longitude. A lista nunca incluirá tempo, altitude, profundidade ou quaisquer variáveis de observação.

O conjunto de dados DEVE incluir o globalAttribute cdm\_profile\_variables, onde o valor é uma lista separada por vírgula das variáveis que têm a informação sobre cada perfil. Para um determinado perfil, os valores dessas variáveis devem ser constantes. Por exemplo,
```
<att name="cdm\\_profile\\_variables">profile\\_number,time</att>
```

A lista DEVE incluir a variável cf\_role=profile\_id e todas as outras variáveis com informações sobre o perfil, que quase sempre inclui tempo. A lista nunca incluirá latitude, longitude, altitude, profundidade ou quaisquer variáveis de observação.

Trajeto

Trajeto -- é uma sequência de medidas tomadas ao longo de uma trajetória (um caminho através do espaço e do tempo) (e.g., mar\_water\_temperature tomado por um navio como ele se move através da água) . O conjunto de dados pode ser uma coleção destes Trajetórios, por exemplo, uma sequência de cada um de quatro navios diferentes.
Uma das variáveis (por exemplo, ship\_id) MUST ter o atributo cf\_role=trajectory\_id para identificar a variável que identifica exclusivamente as trajetórias.
```
<att name="cf\\_role">trajectory\\_id</att>
```

cdm\_trajectory\_variables

O conjunto de dados DEVE incluir o globalAttribute cdm\_trajectory\_variables , onde o valor é uma lista separada por vírgula das variáveis que têm a informação sobre cada trajetória. Para uma determinada trajetória, os valores dessas variáveis devem ser constantes. Por exemplo,
```
<att name="cdm\\_trajectory\\_variables">ship\\_id,ship\\_type,ship\\_owner</att>
```

A lista DEVE incluir a variável cf\_role=trajectory\_id e todas as outras variáveis com informações sobre a trajetória. A lista nunca incluirá tempo, latitude, longitude ou quaisquer variáveis de observação.

TrajetoProjecto

TrajetoProjecto -- é uma sequência de perfis levados ao longo de uma trajetória. O conjunto de dados pode ser uma coleção destes TrajectoryProfiles, por exemplo, uma sequência de perfis tomados por 14 navios diferentes.
Uma das variáveis (por exemplo, ship\_id) MUST ter o atributo variável cf\_role=trajectory\_id para identificar a variável que identifica de forma única as trajetórias.
```
<att name="cf\\_role">trajectory\\_id</att>
```
Uma das variáveis (por exemplo, profile\_number) MUST ter o atributo variável cf\_role=profile\_id para identificar a variável que identifica exclusivamente os perfis.
```
<att name="cf\\_role">profile\\_id</att>  
```
(Um determinado perfil\_id só tem de ser único para uma determinada trajetória\_id.) Se nenhuma outra variável for adequada, considere usar a variável tempo.
O conjunto de dados DEVE incluir o globalAttribute cdm\_trajectory\_variables, onde o valor é uma lista separada por vírgula das variáveis que têm a informação sobre cada trajetória. Para uma determinada trajetória, os valores dessas variáveis devem ser constantes. Por exemplo,
```
<att name="cdm\\_trajectory\\_variables">ship\\_id,ship\\_type,ship\\_owner</att>
```

A lista DEVE incluir a variável cf\_role=trajectory\_id e todas as outras variáveis com informações sobre a trajetória. A lista nunca incluirá variáveis relacionadas ao perfil, tempo, latitude, longitude ou quaisquer variáveis de observação.

O conjunto de dados DEVE incluir o globalAttribute cdm\_profile\_variables, onde o valor é uma lista separada por vírgula das variáveis que têm a informação sobre cada perfil. Para um determinado perfil, os valores dessas variáveis devem ser constantes. Por exemplo,
```
<att name="cdm\\_profile\\_variables">profile\\_number,time,latitude,longitude</att>
```

A lista DEVE incluir a variável cf\_role=profile\_id e todas as outras variáveis com informações sobre o perfil, que quase sempre inclui tempo, latitude e longitude. A lista nunca incluirá altitude, profundidade ou quaisquer variáveis de observação.

Outros

Outros -- não tem requisitos. Use-o se o conjunto de dados não se encaixar em uma das outras opções, notavelmente, se o conjunto de dados não incluir variáveis de latitude, longitude e tempo.

Todos os conjuntos de dados EDDTable com um cdm\_data\_type diferente do "Outro" DEVE ter variáveis de longitude, latitude e tempo.
Conjuntos de dados com perfis DEVE ter uma variável de altitude, uma variável de profundidade ou uma cdm\_altitude\_proxy variável.
Se você não pode fazer um conjunto de dados cumprir com todos os requisitos para o ideal cdm\_data\_type, use "Point" (que tem poucos requisitos) ou "Outro" (que não tem requisitos) Em vez disso.
Esta informação é utilizada por ERDDAP™ de várias maneiras, por exemplo, mas principalmente para fazer .nc Arquivos CF ( .nc arquivos que estão em conformidade com as Representações Ragged Array Contiguous associadas ao conjunto de dados cdm\_data\_type) e .nc Arquivos CFMA ( .nc arquivos que estão em conformidade com as Representações Multidimensionais de Array associadas ao conjunto de dados cdm\_data\_type) como definido em Geometrias de amostragem discretas (DSG) capítulo do CF convenções de metadados, que foram anteriormente nomeadas "Convenções de Observação de Pontos CCF".
Dica: Para esses conjuntos de dados, a configuração correta para subsetVariables é geralmente a combinação de todas as variáveis listadas nos atributos cdm\_...\_variables. Por exemplo, para TimeSeriesProfile, use o cdm\_timeseries\_variables mais o cdm\_profile\_variables.

contributor\_name

** contributor\_name ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar uma pessoa, organização ou projeto que contribuiu para este conjunto de dados (por exemplo, o criador original dos dados, antes de ser reprocessado pelo criador deste conjunto de dados) . Por exemplo,

    <att name="contributor\\_name">NOAA OceanWatch - Central Pacific</att>

Se "contributor" realmente não se aplica a um conjunto de dados, omitir este atributo. Comparado a creator\_name , isto às vezes é mais focado na fonte de financiamento.

contributor\_role

** contributor\_role ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar o papel de contributor\_name . Por exemplo,

    <att name="contributor\\_role">Source of Level 2b data</att>

Se "contributor" realmente não se aplica a um conjunto de dados, omitir este atributo.

Convenções

Convenções (do CF padrão de metadados) está firmemente recomendado. (Pode ser REQUIREDO no futuro.) O valor é uma lista separada por vírgula de padrões de metadados que este conjunto de dados segue. Por exemplo:

<att name="Conventions">COARDS, CF-1.6, ACDD-1.3</att>

As convenções comuns de metadados utilizadas em ERDDAP™ são:

COARDS Convenções é o precursor da CF.
Clima e previsão (CF) Convenções é a fonte de muitos dos atributos recomendados e exigidos em ERDDAP . A versão atual do CF é identificada como "CF-1.6".
O NetCDF Atribua a Convenção para o Descobrimento de Dados (ACÓRDÃO) é a fonte de muitos dos atributos recomendados e exigidos em ERDDAP . A versão original 1.0 de ACDD (um trabalho brilhante por Ethan Davis) , foi identificado como Unidata Dataset Discovery v1.0 A corrente (a partir de 2015) 1.3 versão do ACDD é identificada como ACDD-1.3 . Se seus conjuntos de dados estiverem usando Unidata Dataset Discovery v1.0, nós encorajamos você a mudar seus conjuntos de dados para usar ACDD-1.3 .

Se o seu conjunto de dados seguir algum padrão de metadados adicional, adicione o nome à lista CSV no atributo Conventions.

coverage\_content\_type

** coverage\_content\_type ** (do ISO 19115 padrão de metadados) é a maneira RECOMENDADA de identificar o tipo de dados gradeados (em EDDGrid conjuntos de dados) . Por exemplo,

<att name="coverage\\_content\\_type">modelResult</att>

Os únicos valores permitidos são auxiliarInformação, imagem, modeloResulto, físico Medição (o padrão quando os metadados ISO 19115 são gerados) , qualidadeInformação, referênciaInformação e temáticaClassificação. (Não use esta tag para conjuntos de dados EDDTable.)

creator\_name

** creator\_name ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar a pessoa, organização ou projeto (se não uma pessoa ou organização específica) , mais responsável pela criação (ou reprocessamento mais recente) destes dados. Por exemplo,

<att name="creator\\_name">NOAA NMFS SWFSC ERD</att>

Se os dados foram amplamente reprocessados (por exemplo, dados de satélite do nível 2 ao nível 3 ou 4) , então geralmente o reprocessador é listado como o criador e o criador original é listado via contributor\_name . Comparado a projeto , isso é mais flexível, uma vez que pode identificar uma pessoa, uma organização ou um projeto.

creator\_email

** creator\_email ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar um endereço de email (formatado corretamente) que fornece uma maneira de entrar em contato com o criador. Por exemplo,

<att name="creator\\_email">erd.data@noaa.gov</att>

creator\_url

** creator\_url ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar uma URL para a organização que criou o conjunto de dados, ou uma URL com as informações do criador sobre este conjunto de dados (mas esse é mais o propósito de infoUrl ) . Por exemplo,

<att name="creator\\_url">https://www.pfeg.noaa.gov</att>

date\_created

** date\_created ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar a data em que os dados foram criados pela primeira vez (por exemplo, processado neste formulário) , em formato ISO 8601. Por exemplo,

<att name="date\\_created">2010-01-30</att>

Se os dados forem periodicamente adicionados ao conjunto de dados, esta é a primeira data que os dados originais foram disponibilizados.

date\_modified

** date\_modified ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar a data em que os dados foram modificados pela última vez (por exemplo, quando um erro foi corrigido ou quando os dados mais recentes foram adicionados) , em formato ISO 8601. Por exemplo,

<att name="date\\_modified">2012-03-15</att>

date\_issued

** date\_issued ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar a data em que os dados foram disponibilizados pela primeira vez para outros, no formato ISO 8601, por exemplo, 2012-03-15. Por exemplo,

<att name="date\\_issued">2010-07-30</att>

Por exemplo, o conjunto de dados pode ter um date\_created de 2010-01-30, mas só foi disponibilizado publicamente 2010-07-30. date\_issued é menos comumente usado do que date\_created e date\_modified . Se date\_issued é omitido, presume-se que é o mesmo que o date\_created .

global global drawLandMask

** drawLandMask ** - ... Este é um atributo global OPTIONAL usado por ERDDAP™ (e sem padrões de metadados) que especifica o valor padrão para a opção "Draw Land Mask" no formulário Make A Graph do conjunto de dados ( * datasetID * .) e para o parâmetro &.land em uma URL solicitando um mapa dos dados. Por exemplo,

<att name="drawLandMask">over</att>

Ver drawLandMask Visão geral .

featureType

** featureType ** (do CF padrão de metadados) é IGNORADO e/ou REPLACADO. Se o conjunto de dados cdm\_data\_type é apropriado, ERDDAP™ irá usá-lo automaticamente para criar um featureType atributo. Então não há necessidade de você adicioná-lo.

No entanto, se você estiver usando EDDTable FromNcCFFiles para criar um conjunto de dados de arquivos que seguem CF Geometrias de amostragem discretas (DSG) padrão , os próprios arquivos devem ter featureType corretamente definido, de modo que ERDDAP™ pode ler os arquivos corretamente. Isso faz parte dos requisitos CF DSG para esse tipo de arquivo.

história

história (do CF e ACÓRDÃO padrões de metadados) é um atributo global String multi-linha RECOMENDADO com uma linha para cada etapa de processamento que os dados sofreram. Por exemplo,

<att name="history">2011-08-05T08:55:02Z CMOR: Rewrote data to comply with CF standards.  
2012-04-08T08:34:58Z CMOR: Converted 'height' type from 'd' to 'f'.</att>

Idealmente, cada linha tem um ISO 8601:2004 (E) data de formatação+timeZ (por exemplo, 2011-08-05T08:55:02Z) seguido por uma descrição da etapa de processamento.
ERDDAP™ cria isso se não existir já.
Se já existe, ERDDAP™ irá anexar novas informações às informações existentes.
A história é importante porque permite que os clientes voltem à fonte original dos dados.

infoUrl

** infoUrl ** é um atributo global REQUIRED com a URL de uma página web com mais informações sobre este conjunto de dados (geralmente no site da instituição de origem) . Por exemplo,

<att name="infoUrl">http://www.globec.org/</att>

Ou o conjunto de dados global Atributos de fonte ou seu global< addAttributes > Deve incluir este atributo.
infoUrl é importante porque permite aos clientes descobrir mais sobre os dados da fonte original.
ERDDAP™ exibe um link para o infoUrl no formulário de acesso de dados ( * datasetID * .html) , Faça uma página web gráfico ( * datasetID * .) , e outras páginas da web.
Se a URL tiver uma parte de consulta (depois do "?) , deve ser já por cento codificado . Você precisa codificar caracteres especiais nas restrições (diferente do inicial '&' e o principal '=' , se houver) na forma %HH, onde HH é o valor hexadecimal de 2 dígitos do personagem. Normalmente, você só precisa converter alguns dos caracteres de pontuação: % em %25, & em %26, " em %22,<em %3C, = em %3D, > em %3E, + em %2B, | em %7C, \[ em %5B, \] em %5D, espaço em %20, e converter todos os caracteres acima #127 em sua forma UTF-8 e, em seguida, por cento codificar cada byte da forma UTF-8 no formato %HH (pedir ajuda a um programador) . Por exemplo, & stationID > = 41004 torna-se & nbsp; stationID %3E =%2241004%22 A codificação por cento é geralmente necessária quando você acessa ERDDAP via software diferente de um navegador. Os navegadores geralmente lidam com a codificação por cento para você. Em algumas situações, você precisa codificar por cento todos os caracteres que não A-Za-z0-9\_-!.~ ' () \*, mas ainda não codifica a inicial '&' ou a principal '=' . Linguagens de programação têm ferramentas para fazer isso (por exemplo, ver Java ' java.net.URLEncoder
e Java O script é [encodeURIComponent()] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) ) e há sites que por cento codificar / decodificar para você .
Desde então datasets.xml é um arquivo XML, você MUST também &-encode ALL '&', '<', e '>' na URL como ' &', '<', and '>' after percent encoding.
infoUrl é único ERDDAP . Não é de nenhum padrão de metadados.

instituição

instituição (do CF e ACÓRDÃO padrões de metadados) é um atributo global REQUIRED com a versão curta do nome da instituição que é a fonte desses dados (geralmente uma sigla, geralmente<20 caracteres). Por exemplo,

<att name="institution">NASA GSFC</att>

Ou o conjunto de dados global Atributos de fonte ou seu global< addAttributes > Deve incluir este atributo.
ERDDAP™ exibe a instituição sempre que exibe uma lista de conjuntos de dados. Se o nome de uma instituição aqui é mais de 20 caracteres, apenas os primeiros 20 caracteres serão visíveis na lista de conjuntos de dados (mas toda a instituição pode ser visto colocando o cursor do mouse sobre o ícone "?" adjacente) .
Se você adicionar instituição à lista de< categoryAttributes > em ERDDAP ' setup.xml arquivo, os usuários podem facilmente encontrar conjuntos de dados da mesma instituição via ERDDAP "Search for Datasets by Category" na página inicial.

palavras-chave

palavras-chave (do ACÓRDÃO padrão de metadados) é uma lista separada por vírgulas RECOMENDADA de palavras e frases curtas (por exemplo, GCMD Palavras-chave da ciência ) que descrevem o conjunto de dados de uma forma geral, e não assumindo qualquer outro conhecimento do conjunto de dados (por exemplo, para dados oceânicos, incluem o oceano) . Por exemplo,

<att name="keywords">ano, circulation, coastwatch, currents, derived, Earth Science &gt; Oceans &gt; Ocean Circulation &gt; Ocean Currents, eastward, eastward\\_sea\\_water\\_velocity, experimental, hf radio, meridional, noaa, northward, northward\\_sea\\_water\\_velocity, nuevo, ocean, oceans, radio, radio-derived, scan, sea, seawater, velocity, water, zonal</att>  

Desde então datasets.xml é um documento XML, os caracteres &,<e > em um atributo como palavras-chave (por exemplo, os caracteres > nas palavras-chave da ciência do GCMD) deve ser codificado como &,<, e >, respectivamente. Quando um conjunto de dados é carregado ERDDAP ,

"Earth Science > " é adicionado ao início de qualquer palavra-chave GCMD que não tem.
As palavras-chave GCMD são convertidas em Title Case (ou seja, as primeiras letras são capitalizadas) .
As palavras-chave são reorganizadas em ordem ordenada e quaisquer caracteres de linha nova são removidos.

keywords\_vocabulary

** keywords\_vocabulary ** (do ACÓRDÃO padrão de metadados) é um atributo RECOMENDADO: se você estiver seguindo uma diretriz para as palavras/frases em suas palavras-chave atributo (por exemplo, GCMD Science Keywords) , coloque o nome dessa diretriz aqui. Por exemplo,

<att name="keywords\\_vocabulary">GCMD Science Keywords</att>

licença

licença (do ACÓRDÃO padrão de metadados) é um atributo global STRONGLY RECOMENDED com as restrições de licença e/ou uso. Por exemplo,

<att name="license">\\[standard\\]</att>

Se... \[ padrão \] " ocorre no valor do atributo, ele será substituído pelo padrão ERDDAP™ licença da<padrãoLicense> tag in ERDDAP ' \[ Toca a brincar. \] /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util/messages.xml ficheiro.

Metadata\_Conventions

** Metadata\_Conventions ** é desatualizado ACDD 1.0 (que foi identificado em Metadata\_Conventions como " Unidata Dataset Discovery v1.0") padrão de metadados. O valor do atributo foi uma lista separada por vírgula de convenções de metadados usadas por este conjunto de dados. Se um conjunto de dados usa ACDD 1.0, este atributo é STRONGLY RECOMENDED, por exemplo,

<att name="Metadata\\_Conventions">COARDS, CF-1.6, Unidata Dataset Discovery v1.0</att>  

Mas... ERDDAP™ agora recomenda ACDD-1.3. Se tiveres alterne seus conjuntos de dados para usar ACDD-1.3 , uso de Metadata\_Conventions é STRONGLY DISCOURAGED: basta usar [<Convenções>] (#convenções) Em vez disso.

processing\_level

** processing\_level ** (do ACÓRDÃO padrão de metadados) é uma descrição textual RECOMENDADA do processamento (por exemplo, Níveis de processamento de dados do Sistema de Observação da Terra da NASA , por exemplo, Nível 3) ou nível de controle de qualidade (por exemplo, Qualidade da Ciência) dos dados. Por exemplo,

<att name="processing\\_level">3</att>

projeto

projeto (do ACÓRDÃO padrão de metadados) é um atributo OPTIONAL para identificar o projeto que o conjunto de dados faz parte. Por exemplo,

<att name="project">GTSPP</att>

Se o conjunto de dados não faz parte de um projeto, não use esse atributo. Comparado a creator\_name , isto está focado no projeto (não uma pessoa ou uma organização, que pode estar envolvida em vários projetos) .

publisher\_name

** publisher\_name ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar a pessoa, organização ou projeto que está publicando este conjunto de dados. Por exemplo,

<att name="publisher\\_name">JPL</att>

Por exemplo, você é o editor se outra pessoa ou grupo criado o conjunto de dados e você está apenas reservá-lo via ERDDAP . Se "publicador" realmente não se aplica a um conjunto de dados, omitir este atributo. Comparado a creator\_name , o editor provavelmente não modificou significativamente ou reprocessou os dados; o editor está apenas disponibilizando os dados em um novo local.

publisher\_email

** publisher\_email ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar um endereço de email (formatado corretamente, por exemplo, john\_smith@great.org) que fornece uma maneira de entrar em contato com o editor. Por exemplo,

<att name="publisher\\_email">john\\_smith@great.org</att>

Se "publicador" realmente não se aplica a um conjunto de dados, omitir este atributo.

publisher\_url

** publisher\_url ** (do ACÓRDÃO padrão de metadados) é a maneira RECOMENDADA de identificar uma URL para a organização que publicou o conjunto de dados, ou uma URL com as informações do editor sobre este conjunto de dados (mas esse é mais o propósito de infoUrl ) . Por exemplo,

<att name="publisher\\_url">https://podaac.jpl.nasa.gov</att>

Se "publicador" realmente não se aplica a um conjunto de dados, omitir este atributo.

real\_time

** real\_time ** é um atributo global String (não de qualquer padrão) indicando se este é um conjunto de dados em tempo real. Por exemplo,

<att name="real\\_time">true</att>

Se isto é falso (o padrão) , ERDDAP™ irá armazenar respostas a pedidos de tipos de arquivos onde todo o arquivo deve ser criado antes ERDDAP™ pode começar a enviar a resposta ao usuário e reutilizá-los por até cerca de 15 minutos (por exemplo, .nc , .png) . Se isto for verdade, ERDDAP™ nunca irá armazenar os arquivos de resposta e sempre retornará arquivos recém-criados.

sourceUrl atributos

** sourceUrl ** é um atributo global com a URL da fonte dos dados. Por exemplo,

<att name="sourceUrl">https://opendap.co-ops.nos.noaa.gov/ioos-dif-sos/SOS</att>  

(mas coloque tudo em uma linha)

ERDDAP™ geralmente cria esse atributo global automaticamente. Duas exceções são EDDTableDe Hyrax Arquivos e EDDTableDeThreddsFiles.
Se a fonte é arquivos locais e os arquivos foram criados por sua organização, use

    <att name="sourceUrl">(local files)</att>

Se a fonte é banco de dados local e os dados foram criados por sua organização, use

    <att name="sourceUrl">(local database)</att>

sourceUrl é importante porque permite que os clientes sigam para a fonte original dos dados.
sourceUrl é único ERDDAP . Não é de nenhum padrão de metadados.

standard\_name\_vocabulary

** standard\_name\_vocabulary ** (do ACÓRDÃO padrão de metadados) é um atributo RECOMENDADO para identificar o nome do vocabulário controlado de que variável standard\_name são levados. Por exemplo,

<att name="standard\\_name\\_vocabulary">CF Standard Name Table v77</att>

para a versão 77 do Tabela de nomes padrão CF .

subsetVariables

** subsetVariables ** (apenas para conjuntos de dados EDDTable) é um atributo global RECOMENDADO que permite especificar uma lista separada por vírgula de [< dataVariable > (#datavariable) destinationName s para identificar variáveis que tenham um número limitado de valores (declarada de outra forma: variáveis para as quais cada um dos valores tem muitas duplicatas) . Por exemplo,

    <att name="subsetVariables">station\\_id, longitude, latitude</att>

Se este atributo estiver presente, o conjunto de dados terá um * datasetID * Página web .subset (e um link para ele em cada lista de conjuntos de dados) que permite aos usuários selecionar rapidamente e facilmente vários subconjuntos dos dados.

Cada vez que um conjunto de dados é carregado, ERDDAP cargas e lojas no disco uma tabela com todos os distintos () combinações do subconjunto Valores da variável. ERDDAP™ pode ler que subsetVariables tabela e processá-lo muito rapidamente (especialmente em comparação com a leitura de muitos arquivos de dados ou obtenção de dados de um banco de dados ou outro serviço externo) .
Isso permite ERDDAP™ para fazer 3 coisas:
1. Permite ERDDAP™ para colocar uma lista de valores possíveis em uma lista suspensa no formulário de acesso de dados, Faça uma página web do gráfico e .subset páginas da web.
2. Permite ERDDAP™ para oferecer uma página web .subset para esse conjunto de dados. Essa página é interessante porque torna fácil encontrar combinações válidas dos valores dessas variáveis, que para alguns conjuntos de dados e algumas variáveis é muito, muito difícil (quase impossível) . Então, todos os pedidos de usuário para distinto () subconjunto Os dados variáveis serão muito rápidos.
3. Se houver uma solicitação de usuário que se refere apenas a um subconjunto dessas variáveis, ERDDAP™ pode ler rapidamente o subsetVariables tabela e responder ao pedido. Isso pode economizar muito tempo e esforço para ERDDAP .
A ordem do destinationName s você especificar determina a ordem de classificação no * datasetID * .subset página web, então você geralmente especificará as variáveis mais importantes primeiro, então o menos importante. Por exemplo, para conjuntos de dados com dados de série de tempo para várias estações, você pode usar, por exemplo,
```
    <att name="subsetVariables">station\\_id, longitude, latitude</att>  
```

para que os valores sejam classificados pela estação\_id.

Obviamente, é sua escolha que as variáveis a incluir no subsetVariables lista, mas o uso sugerido é:

Em geral, inclua variáveis para as quais você deseja ERDDAP™ para exibir uma lista suspensa de opções no formulário de acesso de dados do conjunto de dados (.html) e Make-A-Graph (.) páginas da web.

Em geral, inclua variáveis com informações sobre os recursos do conjunto de dados (as estações, perfis e/ou trajetórias, nomeadamente cdm\_timeseries\_variables , cdm\_profile\_variáveis , cdm\_trajectory\_variables ) . Existem apenas alguns valores diferentes para essas variáveis para que elas funcionem bem com listas suspensas.

Nunca inclua quaisquer variáveis de dados associadas a observações individuais (por exemplo, tempo, temperatura, salinidade, velocidade atual) no subsetVariables lista. Há muitos valores diferentes para essas variáveis, então uma lista suspensa seria lenta para carregar e ser difícil de trabalhar com (ou não trabalhar) .

Se o número de combinações distintas dessas variáveis for maior que cerca de 1.000.000, você deve considerar restringir o subsetVariables que você especificar para reduzir o número de combinações distintas para abaixo de 1.000.000; caso contrário, o * datasetID * . páginas web subdefinidas podem ser geradas lentamente. Em casos extremos, o conjunto de dados não pode ser carregado ERDDAP™ porque gerar a lista de combinações distintas usa muita memória. Se assim for, você deve remover algumas variáveis do subsetVariables lista.
Se o número de valores distintos de qualquer variável subconjunto for maior que cerca de 20.000, você deve considerar não incluir essa variável na lista de valores distintos de qualquer variável subconjunto. subsetVariables ; caso contrário, demora muito tempo para transmitir o * datasetID * .subset, * datasetID * .graph, e * datasetID * .html páginas web. Além disso, em um Mac, é muito difícil fazer seleções de uma lista suspensa com mais de 500 itens por causa da falta de uma barra de rolagem. Um compromisso é: remover variáveis da lista quando os usuários não são propensos a selecionar valores de uma lista suspensa.
Você deve testar cada conjunto de dados para ver se o subsetVariables A configuração está bem. Se o servidor de dados de origem é lento e demora muito (ou falha) para baixar os dados, ou reduzir o número de variáveis especificadas ou remover o subsetVariables atributo global.
Subconjunto Variáveis é muito útil. Então, se seu conjunto de dados é adequado, por favor crie um subsetVariables atributo.

Tabela de EDD SOS adiciona automaticamente

    <att name="subsetVariables">station\\_id, longitude, latitude</att>

quando o conjunto de dados é criado.

Possível aviso: se um usuário usar o * datasetID * .subset página web seleciona um valor que tem um carruagemReturn ou caráter newline, * datasetID * .subset falhará. ERDDAP™ não pode funcionar em torno deste problema por causa de alguns detalhes HTML. Em qualquer caso, é quase sempre uma boa ideia remover o carruagemReturn e caracteres de linha nova dos dados. Para ajudá-lo a corrigir o problema, se a Tabela EDD. subsetVariables Método de tabela de dados em ERDDAP detecta valores de dados que causarão problemas, ele enviará um aviso com uma lista de valores ofendidos para o e-mail Tudo Para endereços de e-mail especificados no setup.xml. Assim, você sabe o que precisa ser corrigido.
Mesas subconjuntas pré-geradas. Normalmente, quando ERDDAP™ carrega um conjunto de dados, ele solicita o distinto () tabela de dados de variáveis subdefinidas da fonte de dados, apenas através de uma solicitação de dados normal. Em alguns casos, esses dados não estão disponíveis a partir da fonte de dados ou a recuperação da fonte de dados pode ser difícil no servidor de origem de dados. Se assim for, você pode fornecer uma tabela com as informações em uma .json ou arquivo .csv com o nome Toca a brincar. /content/erddap/subset/ * datasetID * .json (ou .csv) . Se presente, ERDDAP™ irá lê-lo uma vez quando o conjunto de dados é carregado e usá-lo como fonte dos dados subconjuntos.
Se houver um erro ao lê-lo, o conjunto de dados não será carregado.
Deve ter os mesmos nomes de colunas (por exemplo, o mesmo caso) como< subsetVariables >, mas as colunas MAY estar em qualquer ordem.
Tem colunas extras (eles serão removidos e as linhas redundantes serão removidas) .
Valores perdidos devem estar faltando valores (não números falsos como -99) .
.json arquivos podem ser um pouco mais difíceis de criar, mas lidar com personagens Unicode bem. .json arquivos são fáceis de criar se você criá-los com ERDDAP .
arquivos .csv são fáceis de trabalhar com, mas adequados apenas para caracteres ISO 8859-1. Arquivos .csv DEVE ter nomes de colunas na primeira linha e dados em linhas subseqüentes.
Para grandes conjuntos de dados ou quando< subsetVariables > é misconfigured, a tabela de combinações de valores pode ser grande o suficiente para causar erros Too Much Data ou OutOfMemory. A solução é remover variáveis da lista de< subsetVariables > para os quais há um grande número de valores, ou remover variáveis conforme necessário até que o tamanho dessa tabela seja razoável. Independentemente do erro, as partes de ERDDAP™ que use o subsetVariables sistema não funciona bem (por exemplo, páginas web carregam muito lentamente) quando há muitas linhas (por exemplo, mais de um milhão) naquela mesa.
subsetVariables não tem nada a ver com especificar quais variáveis os usuários podem usar em restrições, ou seja, como os usuários podem solicitar subconjuntos do conjunto de dados. ERDDAP™ sempre permite que restrições se referem a qualquer uma das variáveis.

Unidades do tempo

Tempo e timestamp colunas devem ter ISO 8601:2004 (E) data formatada + hora Cordas Z (por exemplo, 1985-01-31T15:31:00Z) .

resumo

resumo (do CF e ACÓRDÃO padrões de metadados) é um atributo global REQUIRED com uma longa descrição do conjunto de dados (geralmente<500 caracteres). Por exemplo,

<att name="summary">VIIRSN Level-3 Standard Mapped Image, Global, 4km, Chlorophyll a, Daily. The Visible and Infrared Imager/Radiometer Suite (VIIRS) is a multi-disciplinary instrument that flies on the National Polar-orbiting Operational Environmental Satellite System (NPOESS) series of spacecraft, including the NPOESS Preparatory Project (NPP).</att>

Ou o conjunto de dados global Atributos de fonte ou seu global< addAttributes > Deve incluir este atributo.
resumo é muito importante porque permite aos clientes ler uma descrição do conjunto de dados que tem mais informações do que o título e, portanto, entender rapidamente o que é o conjunto de dados.
Conselho: por favor escreva o resumo para que ele funcione para descrever o conjunto de dados para alguma pessoa aleatória que você encontra na rua ou para um colega. Lembre-se de incluir o Cinco W e um H : Quem criou o conjunto de dados? Que informações foram coletadas? Quando foram coletados os dados? Onde foi recolhido? Porque foi recolhido? Como foi recolhido?
ERDDAP™ exibe o resumo no formulário de acesso de dados do conjunto de dados ( * datasetID * .html) , Faça uma página web gráfico ( * datasetID * .) , e outras páginas da web. ERDDAP™ usa o resumo ao criar documentos FGDC e ISO 19115.

testOutOfDate

** testOutOfDate ** (um opcional ERDDAP - atributo específico de metadados globais, não de qualquer padrão) especifica, de forma simplista, quando os dados para um conjunto de dados em tempo quase real são considerados desatualizados, especificados como now- NUnits Por exemplo, now- 2 dias para dados que geralmente aparecem 2448 horas após o valor do tempo. Para dados de previsão, use agora + NUnits , por exemplo, agora + 6 dias para dados de previsão que é, no máximo, 8 dias no futuro. (Ver now- NUnits Descrição da sintaxe .) Se o valor máximo de tempo para o conjunto de dados for mais recente do que o tempo especificado, o conjunto de dados é considerado atualizado. Se o valor máximo de tempo for mais antigo do que o tempo especificado, o conjunto de dados é considerado atualizado. Para conjuntos de dados desatualizados, há presumivelmente um problema com a fonte de dados, portanto ERDDAP™ é incapaz de acessar dados de pontos de tempo mais recentes.

O testOutOfDate o valor é exibido como uma coluna no allDatasets conjunto de dados em seu ERDDAP . Também é usado para calcular o índice outOfDate, que é outra coluna no allDatasets conjunto de dados. Se o índice for<1, o conjunto de dados é considerado atualizado. Se o índice for<=1, o conjunto de dados é considerado fora de data. Se o índice for<=2, o conjunto de dados é considerado muito fora de data.

O testOutOfDate valor também é usado por ERDDAP™ para gerarhttps://yourDomain/erddap/outOfDateDatasets.htmlPágina web ( exemplo ) que mostra os conjuntos de dados que têm< testOutOfDate > tags, com os conjuntos de dados classificados por como fora de data eles são. Se você alterar o tipo de arquivo (de .html para .csv, .jsonlCSV , .nc , .tsv ,) , você pode obter essas informações em diferentes formatos de arquivo.

Quando possível, Gerar conjuntos de dadosXml adiciona um testOutOfDate atributo ao global addAttributes de um conjunto de dados. Este valor é uma sugestão baseada nas informações disponíveis para GerarDatasetsXml. Se o valor não for apropriado, altere-o.

"Out-of-date" aqui é muito diferente de [<recarregar Cada NMinutes> (#reloadeverynminutes) , que lida com como up-to-date ERDDAP O conhecimento do conjunto de dados é. O< testOutOfDate > sistema assume que ERDDAP O conhecimento do conjunto de dados está atualizado. A pergunta< testOutOfDate > lida com é: parece haver algo errado com a fonte dos dados, fazendo com que os dados mais recentes não sejam acessíveis ERDDAP ?

título

título (do CF e ACÓRDÃO padrões de metadados) é um atributo global REQUIRED com a descrição curta do conjunto de dados (geralmente<= 95 caracteres). Por exemplo,

<att name="title">VIIRSN Level-3 Mapped, Global, 4km, Chlorophyll a, Daily</att>

Ou o conjunto de dados global Atributos de fonte ou seu global< addAttributes > Deve incluir este atributo.
título é importante porque cada lista de conjuntos de dados apresentados por ERDDAP (outros resultados de pesquisa) lista os conjuntos de dados em ordem alfabética, por título. Então, se você quiser especificar a ordem dos conjuntos de dados, ou tiver alguns conjuntos de dados agrupados, você tem que criar títulos com isso em mente. Muitas listas de conjuntos de dados (por exemplo, em resposta a uma pesquisa de categoria) , mostrar um subconjunto da lista completa e em uma ordem diferente. Assim, o título de cada conjunto de dados deve ficar por conta própria.
Se o título contém a palavra "DEPRECATED" (letras maiúsculas) , então o conjunto de dados vai obter um ranking mais baixo em pesquisas.

< axisVariable >

Não. ** < axisVariable > ** ] (#axisvariable) é usado para descrever uma dimensão (também chamado "axis") . Para EDDGrid conjuntos de dados, um ou mais axisVariable tags é REQUIREDO, e todos dataVariable S sempre compartilhar / usar todas as variáveis do eixo. ( Porquê? E se não o fizerem? )
Deve haver uma variável de eixo para cada dimensão das variáveis de dados. As variáveis de eixo devem ser especificadas na ordem em que as variáveis de dados as usam. (Os conjuntos de dados da TabelaEDD NÃO podem usar< axisVariable > tags.) Um exemplo carnudo é:

  <axisVariable>
      <sourceName\>MT</sourceName>
      <destinationName\>time</destinationName>
      <addAttributes>
        <att name="units">days since 1902-01-01T12:00:00Z</att>
      </addAttributes>
  </axisVariable>

< axisVariable > suporta as seguintes subtags:

< sourceName \ >

Não.< sourceName - Sim. (Nome de fonte) -- o nome da fonte de dados para a variável. Este é o nome que ERDDAP™ usará ao solicitar dados da fonte de dados. Este é o nome que ERDDAP™ procurará quando os dados forem devolvidos da fonte de dados. Isto é sensível ao caso. Isto é necessário.

< destinationName \ >

Não.< destinationName - Sim. (Nome de destino) é o nome da variável que será mostrada e usada por ERDDAP™ usuários.
- Isto é OPTIONAL. Se ausente, o sourceName é usado.
- Isso é útil porque permite que você altere um críptico ou estranho sourceName .
- destinationName é sensível ao caso.
- destinationName s DEVE começar com uma carta (A-Z, a-z) e DEVE ser seguido por 0 ou mais caracteres (A-Z, a-z, 0-9, e \_) . ("-" foi permitido antes ERDDAP™ versão 1.10.) Esta restrição permite que nomes variáveis de eixo sejam os mesmos em ERDDAP™ , nos arquivos de resposta, e em todo o software onde esses arquivos serão usados, incluindo linguagens de programação (Tipo... Python , Matlab e Java Script) onde há restrições semelhantes em nomes variáveis.
- Em EDDGrid conjuntos de dados, longitude, latitude, altitude, profundidade e tempo variáveis do eixo são especiais.

axisVariable <addAttributes>

Não.< addAttributes > (#variável-addattributes) define um conjunto OPTIONAL de atributos ( Nome = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = valor ) que são adicionados aos atributos da fonte para uma variável, para fazer os atributos combinados para uma variável. Se a variável Atributos de fonte ou< addAttributes > incluir scale\_factor e/ou add\_offset atributos, seus valores serão usados para descompactar os dados da fonte antes da distribuição para o cliente (resultado Valor = fonte Valor \* scale\_factor + add\_offset ) . A variável descompactada será do mesmo tipo de dados (por exemplo, flutuar) como o scale\_factor e add\_offset valores.

< dataVariable >

Não. ** < dataVariable > ** ] (#datavariable) é um problema (para quase todos os conjuntos de dados) tag dentro do<dataset> tag que é usado para descrever uma variável de dados. Deve haver 1 ou mais casos desta tag. Um exemplo carnudo é:

  <dataVariable>
      <sourceName\>waterTemperature</sourceName>
      <destinationName\>sea\_water\_temperature</destinationName>
      <dataType>float</dataType>
      <addAttributes>
        <att name="ioos\_category">Temperature</att>
        <att name="long\_name">Sea Water Temperature</att>
        <att name="standard\_name">sea\_water\_temperature</att>
        <att name="units">degree\_C</att>
      </addAttributes>
  </dataVariable>

< dataVariable > suporta as seguintes subtags:

< sourceName >

Não.< sourceName > (Nome de fonte) -- o nome da fonte de dados para a variável. Este é o nome que ERDDAP™ usará ao solicitar dados da fonte de dados. Este é o nome que ERDDAP™ procurará quando os dados forem devolvidos da fonte de dados. Isto é sensível ao caso. Isto é necessário.

Grupos

CF adicionou suporte para grupos com CF v1.8. A partir de 2020, NetCDF ferramentas suportam colocar variáveis em grupos em um .nc ficheiro. Na prática, isso significa apenas que as variáveis têm um nome longo que identifica o grupo (S) e o nome variável, por exemplo, group1a/group2c/varName ). ERDDAP™ suporta grupos convertendo o "/" na variável< sourceName > em "\_" na variável< destinationName >, por exemplo, group1a\_group2c\_varName . (Quando você vê isso, você deve perceber que os grupos não são muito mais do que uma convenção de sintaxe.) Quando as variáveis são listadas em ERDDAP™ , todas as variáveis em um grupo aparecerão juntas, imitando o grupo subjacente. \[ Se ERDDAP™ , nomeadamente Gerar conjuntos de dados Xml, não executa bem como pode com arquivos de origem que têm grupos, por favor envie um arquivo de amostra para Chris. John em noaaa.gov . \]

EDDTableDeFiles conjuntos de dados podem usar alguns especialmente codificados, pseudo sourceName s para definir novas variáveis de dados, por exemplo, para promover um atributo global para ser uma variável de dados. Ver esta documentação .

HDF Estruturas

Começar com ERDDAP™ v2.12, EDDGrid De NcFiles e EDDGrid A partir de NcFiles Unpacked pode ler dados de "estruturas" em .nc 4 e .hdf 4 ficheiros. Para identificar uma variável que é de uma estrutura, a< sourceName > deve usar o formato: Design de moda | Nome do membro , por exemplo, group1/myStruct | MyMember.

Nomes de fonte de valor fixo

Em um conjunto de dados EDDTable, se você quiser criar uma variável (com um único valor fixo) que não está no conjunto de dados de origem, use:

    <sourceName>=*fixedValue*</sourceName>

O sinal de igualdade inicial diz ERDDAP™ que um fixo O valor seguirá.

Para variáveis numéricas, o valor fixo deve ser um único valor finito ou NaN (caso insensível, por exemplo, \=NaN) .
Para variáveis String, o valor fixo deve ser único, Corda de estilo JSON (com caracteres especiais escapou com caracteres \) , por exemplo, \="My \"Special\" String" .
Para uma variável timestamp, especifique o valor fixo como um número em "seconds since 1970-01-01T00:00:00Z" e uso unidades=segundos desde 1970-01-01T00:00Z .

As outras tags para o< dataVariable > trabalho como se fosse uma variável regular. Por exemplo, para criar uma variável chamada altitude com um valor fixo de 0,0 (flutuar) , use:

<sourceName>=0</sourceName>
<destinationName\>altitude</destinationName>
<dataType>float</dataType>

Para situações incomuns, você pode até especificar um actual\_range addAttribute, que irá substituir os valores esperados de destinoMin e destinoMax (que, de outro modo, seria igual ao fixo Valor) .

Nomes de fonte de script / Variáveis derivadas

Começar com ERDDAP™ v2.10, em um Tabela EDD dos arquivos , EDDTable FromDatabase ou EDDTable De Nomes de Arquivo dataset, o< sourceName > pode ser uma expressão (uma equação que avalia a um único valor) , usando o formato

    <sourceName>=*expression*</sourceName>

ou um script (uma série de declarações que retorna um único valor) , usando o formato

    <sourceName>=*script*</sourceName>

ERDDAP™ depende da Projeto Apache Java Língua da expressão (JEXL) (licença: Apache ) para avaliar as expressões e executar os scripts. O cálculo para uma determinada nova variável é feito dentro de uma linha dos resultados, repetidamente para todas as linhas. As expressões e scripts usam um Java - e Java sintaxe semelhante a script e pode usar qualquer um dos operadores e métodos que são construídos em JEXL . Os scripts também podem usar métodos (funções) destas classes:

Calendário2 , que é um wrapper para alguns dos métodos relacionados com estática, tempo e calendário em com.cohort.util.Calendar2 ( licença ) . Por exemplo, Calendário2.parseToEpochSeconds ( sourceTime, data TimeFormat ) analisará a fonte string de tempo através da string dateTimeFormat e retornar uma "seconds since 1970-01-01T00:00:00Z" (épocaConds) valor duplo.
Matemática , que é um wrapper para quase todos os métodos estáticos, relacionados com matemática em Java.lang. Matemática . Por exemplo, Math.atan2 ( y, x ) leva em coordenadas retangulares (y, x) e retorna coordenadas polares (um array de duplos com \[ r, theta \] ) .
Matemática , que é um wrapper para quase todos os métodos estáticos, relacionados à matemática em com.cohort.util. Matemática ( licença ) . Por exemplo, Math2.round ( d, nPlaces ) arredondará d para o número especificado de dígitos à direita do ponto decimal.
String, que lhe dá acesso a todos os métodos estáticos, relacionados a corda em Java.lang. String . Objetos de corda em ERDDAP™ expressões e scripts podem usar qualquer um de seus associados Java métodos, como descrito no java.lang. Documentação de corda. Por exemplo, String.valueOf (D) converterá o valor duplo d em uma corda (embora você também pode usar ""+d) .
String2 , que é um wrapper para a maioria dos métodos estáticos, String- e relacionados a array em com.cohort.util.String2 ( licença ) . Por exemplo, String2 .z eropad ( número, nDigits ) adicionará 0s à esquerda do número Corda de modo que o número total de dígitos é nDigits (por exemplo, String2 .z eropad (6, 2) voltará "06") .
linha , que tem métodos não estáticos para acessar os dados das várias colunas na linha atual da tabela de dados de origem. Por exemplo, row.columnString ("ano") lê o valor da coluna "ano" como uma corda, enquanto, row.column Int ("ano") lê o valor da coluna "ano" como um inteiro.

Por razões de segurança, expressões e scripts não podem usar outras classes que não as 6. ERDDAP™ impõe essa limitação criando uma lista negra padrão (que listas negras todas as classes) e depois uma lista branca (que permite especificamente as 6 classes descritas acima) . Se você precisar de outros métodos e/ou outras classes para fazer seu trabalho, por favor envie seus pedidos para Chris. John em noaaa.gov .

Eficiência

Para EDDTableDeFiles conjuntos de dados, há apenas um muito, muito mínimo (provavelmente não perceptível) desaceleração para pedidos de dados dessas variáveis. Para EDDTableFromDatabase, há uma enorme penalidade de velocidade para solicitações que incluem restrições sobre essas variáveis (por exemplo, (&longitude0360>30&longitude0360<40) porque as restrições não podem ser passadas para o banco de dados, então o banco de dados tem que retornar muito mais dados para ERDDAP™ (que é muito demorado) assim ERDDAP™ pode criar a nova variável e aplicar a restrição. Para evitar o pior caso (onde não há restrições sendo passado para o banco de dados) , ERDDAP™ lança uma mensagem de erro para que o banco de dados não tenha que devolver todo o conteúdo da tabela. (Se você quiser contornar isso, adicione uma restrição a uma coluna não-escrita que será sempre verdadeira, por exemplo, &time<3000-01.) Por esta razão, com EDDTableFromDatabase, é provavelmente sempre melhor criar uma coluna derivada no banco de dados em vez de usar sourceName =script in ERDDAP .

Visão geral de como uma expressão (Ou script) É usado:

Em resposta à solicitação de um usuário para dados tabulares, ERDDAP™ recebe dados de uma série de arquivos de origem. Cada arquivo de origem gerará uma tabela de matérias-primas (diretamente da fonte) dados. ERDDAP™ então passará pela tabela de dados brutos, linha por linha, e avaliará a expressão ou script uma vez por cada linha, a fim de criar uma nova coluna que tenha essa expressão ou script como uma sourceName .

Gerar conjuntos de dadosXml

Note que Gerar conjuntos de dados Xml é completamente inconsciente quando há uma necessidade de criar uma variável com< sourceName - Sim. expressão </ sourceName > Você tem que criar a variável em datasets.xml à mão.

Exemplos de expressão:

Aqui estão alguns exemplos completos de variáveis de dados que usam uma expressão para criar uma nova coluna de dados. Esperamos que estes exemplos (e variantes deles) cobrirá cerca de 95% do uso de toda expressão sourceName S.

Combinando "data" e "time" colunas em uma coluna de tempo unificada:

    <dataVariable>
        <sourceName>=Calendar2.parseToEpochSeconds(row.columnString("date") + "T" + 
            row.columnString("time") + "Z", "yyyy-MM-dd'T'HH:mm:ss'Z'")</sourceName> 
        <destinationName>time</destinationName>
        <dataType>double</dataType>
        <addAttributes>
            <att name="units">seconds since 1970-01-01</att>
        </addAttributes>
    </dataVariable>

Isso. sourceName expressão faz um novo "time" coluna concatenando os valores de string a partir do "date" ( yyyy-MM-dd ) e "time" (HH:) colunas em cada linha do arquivo de origem, e convertendo essa string em uma "seconds since 1970-01-01" (épocaConds) valor duplo.

Ou curso, você terá que personalizar a string de formato de tempo para lidar com o formato específico nas colunas de data e hora de origem de cada conjunto de dados, veja o documentação de unidades de tempo .

Tecnicamente, você não precisa usar Calendário2.parseToEpochSeconds () converter a data + hora combinada em epochSeconds. Você pode simplesmente passar a data + hora String para ERDDAP™ e especifique o formato (por exemplo, yyyy-MM-dd 'T'H:mm:ss'Z') através do atributo unidades. Mas há vantagens significativas para converter em epochSeconds -- notavelmente, EDDTableFromFiles pode então facilmente acompanhar o intervalo de valores de tempo em cada arquivo e assim decidir rapidamente se olhar em um determinado arquivo ao responder a uma solicitação que tem restrições de tempo.

Um problema relacionado é a necessidade de criar uma coluna data+hora unificada de uma fonte com ano separado, mês, data, hora, minuto, segundo. A solução é muito semelhante, mas muitas vezes você precisará de zero-pad muitos dos campos, de modo que, por exemplo, mês (1 - 12) e data (1 - 31) sempre tem 2 dígitos. Aqui está um exemplo com ano, mês, data:

    <sourceName>=Calendar2.parseToEpochSeconds(row.columnString("year") + 
        String2.zeroPad(row.columnString("month"), 2) + 
        String2.zeroPad(row.columnString("date"), 2), "yyyyMMdd")</sourceName>

Um problema relacionado é a necessidade de criar uma coluna de latitude ou longitude unificada combinando os dados nas colunas de graus, minutos e segundos da tabela de origem, cada uma armazenada como inteiros. Por exemplo,

    <sourceName>=row.columnInt("deg") + row.columnInt("min")/60.0 + 
        row.columnInt("sec")/3660.0</sourceName>

Convertendo uma coluna chamada "lon" com valores de longitude de 0 - 360° em uma coluna chamada "longitude" com valores de -180 - 180°

    <dataVariable>
        <sourceName>=Math2.anglePM180(row.columnDouble("lon"))</sourceName> 
        <destinationName>longitude</destinationName>
        <dataType>double</dataType>
        <addAttributes>
            <att name="units">degrees\\_east</att>
        </addAttributes>
    </dataVariable>

Isso. sourceName expressão faz uma nova coluna "longitude" convertendo o valor duplo da coluna "lon" em cada linha do arquivo de origem (presumivelmente com 0 - 360 valores) , e convertendo isso em um -180 a 180 valor duplo.

Se você quiser converter valores de longitude fonte de -180 - 180° em 0 - 360°, use

    <sourceName>=Math2.angle0360(row.columnDouble("lon"))</sourceName>

Nomeando as Duas Variáveis de Longitude: Se o conjunto de dados tiver 2 variáveis de longitude, recomendamos usar destinationName = longitude para a variável -180 - 180° e destinationName = longitude0360 (e longName="Longitude 0-360°") para a variável 0 - 360°. Isso é importante porque os usuários às vezes usam a Pesquisa Avançada para procurar dados dentro de um intervalo de longitude específico. Essa busca funcionará melhor se a longitude consistentemente tiver -180 - 180° valores para todos os conjuntos de dados. Além disso, os atributos geoespaciais do conjunto de dados\_lon\_min, geoespacial\_lon\_max, Westernmost\_Easting e Easternmost\_Eastings globais serão definidos de forma consistente (com valores de longitude -180 a 180°) ;

Convertendo uma coluna chamada "tempF" com valores de temperatura em grau\_ F em uma coluna chamada "tempC" com temperaturas em grau\_ C:

    <dataVariable>
        <sourceName>=(row.columnFloat("tempF")-32)\\*5/9</sourceName> 
        <destinationName>tempC</destinationName>
        <dataType>float</dataType>
        <addAttributes>
            <att name="units">degrees\\_C</att>
        </addAttributes>
    </dataVariable>

Isso. sourceName expressão faz uma nova coluna "tempC" convertendo o grau float\_ Valor F da coluna "tempF" em cada linha do arquivo de origem em um grau float\_ Valor C.

Note que seu conjunto de dados pode ter tanto o temp original F variável e o novo temp Variável C por ter outra variável com

    <sourceName>tempF</sourceName>

Convertendo colunas de "velocidade" e "direção" em duas colunas com os componentes u,v

Para fazer uma variável u, use

    <sourceName>=row.columnFloat("speed") \\* Math.cos(row.columnFloat("direction"))</sourceName>

Para fazer uma variável v, use

    <sourceName>=row.columnFloat("speed") \\* Math.sin(row.columnFloat("direction"))</sourceName>

Ou, dado u,v:

Para fazer uma variável de velocidade, use

    <sourceName>=Math.atan2(row.columnDouble("v"), row.columnDouble("u"))\\[0\\]</sourceName>

Para fazer uma variável de direção, use

    <sourceName>=Math.toDegrees(Math.atan2(row.columnDouble("v"), row.columnDouble("u"))\\[1\\])</sourceName>

Exemplo de script:

Aqui está um exemplo de usar um script, não apenas uma expressão, como um sourceName . Esperamos que os scripts, ao contrário de expressões, não sejam necessários muitas vezes. Neste caso, o objetivo é retornar um valor não-NaN faltando (- 99) para valores de temperatura fora de um intervalo específico. Note que o script é a parte após o "=".

    <dataVariable>
        <sourceName>=var tc=row.columnFloat("tempC"); return tc&gt;35 || tc&lt;-5? -99.0f : tc\\*9/5+32;</sourceName> 
        <destinationName>tempF</destinationName>
        <dataType>float</dataType>
        <addAttributes>
            <att name="units">degrees\\_F</att>
        </addAttributes>
    </dataVariable>

Bandeira dura

Se você alterar a expressão ou script definido em um sourceName , você deve definir um bandeira dura para o conjunto de dados para ERDDAP™ exclui todas as informações em cache para o conjunto de dados e re-leia todos os arquivos de dados (usando a nova expressão ou script) da próxima vez que carregar o conjunto de dados. Alternativamente, você pode usar DasDds que faz o equivalente de definir uma bandeira dura.

Codificador de porcentagem

Isso raramente é relevante: Porque as expressões e scripts são escritos em datasets.xml , que é um documento XML, você deve por cento codificar qualquer<, \>, e & caracteres nas expressões e scripts como<, > e & .

Problemas comuns

Um problema comum é que você cria uma variável com sourceName = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = expressão mas a coluna resultante de dados apenas tem valores ausentes. Alternativamente, algumas linhas da nova coluna têm valores perdidos e você acha que não deveriam. O problema subjacente é que algo está errado com a expressão e ERDDAP está convertendo esse erro em um valor perdido. Para resolver o problema,

Veja a expressão para ver qual é o problema.
Olha... - Não. , que mostrará a primeira mensagem de erro gerada durante a criação de cada nova coluna.

As causas comuns são:

Usaste o caso errado. Expressões e scripts são sensíveis a casos.
Omitiste o nome da turma. Por exemplo, você deve usar Math.abs () , não apenas abs () .
Você não digitou conversões. Por exemplo, se o tipo de dados de um valor de parâmetro é String e você tem um valor duplo, você precisa converter um duplo em uma string via "+d.
O nome da coluna na expressão não corresponde exatamente ao nome da coluna no arquivo (ou o nome pode ser diferente em alguns arquivos) .
Há um erro de sintaxe na expressão (por exemplo, um desaparecido ou extra) ').

Se você ficar preso ou precisar de ajuda, por favor inclua os detalhes e veja nossos seção sobre como obter suporte adicional .

< destinationName >

Não.< destinationName > (Nome de destino) -- o nome da variável que será mostrada e utilizada ERDDAP™ usuários.
- Isto é OPTIONAL. Se ausente, o sourceName é usado.
- Isso é útil porque permite que você altere um críptico ou estranho sourceName .
- destinationName é sensível ao caso.
- destinationName s DEVE começar com uma carta (A-Z, a-z) e DEVE ser seguido por 0 ou mais caracteres (A-Z, a-z, 0-9, e \_) . ("-" foi permitido antes ERDDAP™ versão 1.10.) Esta restrição permite que nomes de variáveis de dados sejam os mesmos em ERDDAP™ , nos arquivos de resposta, e em todo o software onde esses arquivos serão usados, incluindo linguagens de programação (Tipo... Python , Matlab e Java Script) onde há restrições semelhantes em nomes variáveis.
- Em conjuntos de dados EDDTable, longitude, latitude, altitude (ou profundidade) e tempo variáveis de dados são especiais.

<dados Tipo >

Não.<dataType>] (# Datatype #) -- especifica o tipo de dados vindo da fonte. (Em alguns casos, por exemplo, ao ler dados de arquivos ASCII, ele especifica como os dados provenientes da fonte devem ser armazenados.)
- Isso é REQUIREDO por alguns tipos de conjuntos de dados e IGNORADO por outros. Tipos de conjuntos de dados que exigem isso para seus dataVariable s são: EDDGrid FromXxFiles, EDDTableFromXxxFiles, EDDTableFromM WFS , EDDTable FromNOS, EDDTable From SOS . Outros tipos de conjuntos de dados ignoram esta tag porque eles obtêm as informações da fonte.
- Os valores válidos são qualquer um dos padrões ERDDAP™ tipos de dados mais booleano (ver abaixo) . Os nomes de dataType são sensíveis a casos.

dados booleanos

"boolean" é um caso especial.
Internamente, ERDDAP™ não suporta um tipo booleano porque os booleanos não podem armazenar valores perdidos e a maioria dos tipos de arquivos não suportam booleanos. Também, DAP não suporta booleanos, então não haveria nenhuma maneira padrão de consultar variáveis booleanas.
Especificando "boolean" para os dados Tipo em datasets.xml fará com que os valores booleanos sejam armazenados e representados como bytes: 0=false, 1=true, 127= missing\_value .
Os usuários podem especificar restrições usando os valores numéricos (por exemplo, "isAlive=1") .
ERDDAP™ administradores às vezes precisam usar os dados "boolean" Tipo em datasets.xml para contar ERDDAP™ como interagir com a fonte de dados (por exemplo, para ler valores booleanos de um banco de dados relacional e convertê-los para 0, 1, ou 127) .
Se você quiser alterar uma variável de dados do dataType nos arquivos de origem (por exemplo, curto) em alguns outros dados Digite o conjunto de dados (por exemplo,) Não use<dataType> para especificar o que você quer. (Ele funciona para alguns tipos de conjuntos de dados, mas não outros.) Em vez disso:
- Uso<dataType> para especificar o que está nos arquivos (por exemplo, curto) .
- No< addAttributes > para a variável, adicione um scale\_factor atributo com os novos dados Tipo (por exemplo,) e um valor de 1, por exemplo,

            <att name="scale\\_factor" type="int">1</att>

dataVariable <addAttributes>

Não.< addAttributes > (#variável-addattributes) -- define um conjunto de atributos ( Nome = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = valor ) que são adicionados aos atributos da fonte para uma variável, para fazer os atributos combinados para uma variável. Isto é OPTIONAL. Se a variável Atributos de fonte ou< addAttributes > incluir scale\_factor e/ou add\_offset atributos, seus valores serão usados para descompactar os dados da fonte antes da distribuição para o cliente. A variável descompactada será do mesmo tipo de dados (por exemplo, flutuar) como o scale\_factor e add\_offset valores.

Variável<addAttributes>

Não. ** Atributos variáveis / Variável< addAttributes > ** ] (#variável-addattributes) - ...< addAttributes > é uma tag OPTIONAL dentro de uma< axisVariable > ou< dataVariable > tag que é usado para alterar os atributos da variável.
- ** Use uma variável< addAttributes > para alterar os atributos da variável. ** ERDDAP™ combina atributos de uma variável a partir da fonte do conjunto de dados (** Atributos de fonte ) e da variável addAttributes que você define em datasets.xml (que têm prioridade) para fazer a variável " Atributos combinados ** ", que são o que ERDDAP™ os usuários veem. Assim, você pode usar addAttributes para redefinir os valores do sourceAttributes, adicionar novos atributos ou remover atributos.
- Veja o [ ** < addAttributes > informação] (#addattributes) que se aplica a global e variável < addAttributes > ** .
- ERDDAP™ procura e usa muitos desses atributos de várias maneiras. Por exemplo, os valores do colorBar são necessários para disponibilizar uma variável via WMS , para que os mapas podem ser feitos com colorBars consistentes.
- A longitude, latitude, altitude (ou profundidade) , e variáveis de tempo obter muitos metadados apropriados automaticamente (por exemplo, unidades ) .
- Uma amostra< addAttributes > para uma variável de dados é:
    <addAttributes>
          <att name="actual\_range" type="doubleList">10.34 23.91</att>
          <att name="colorBarMinimum" type="double">0</att>
          <att name="colorBarMaximum" type="double">32</att>
          <att name="ioos\_category">Temperature</att>
          <att name="long\_name">Sea Surface Temperature</att>
          <att name="numberOfObservations" />
          <att name="units">degree\_C</att>
    </addAttributes>

O atributo numberOfObservations vazio causa o número de origemAtributos OfObservations (se houver) para ser removido da lista final, combinada de atributos.

Fornecer esta informação ajuda ERDDAP™ fazer um trabalho melhor e ajuda os usuários a entender os conjuntos de dados. Os bons metadados tornam um conjunto de dados utilizável. Metadados insuficientes tornam um conjunto de dados inútil. Por favor, tome o tempo para fazer um bom trabalho com atributos de metadados.

Comentários sobre atributos variáveis que são especiais em ERDDAP :

actual\_range

** actual\_range ** é um atributo variável RECOMENDADO. Por exemplo,

<att name="actual\_range" type="floatList"\>0.17 23.58</att>

Este atributo é do CDC COARDS e CF 1.7+ padrões de metadados.
Se presente, deve ser um array de dois valores do mesmo tipo de dados que o tipo de dados de destino da variável, especificando o real (não o teórico ou o permitido) valores mínimos e máximos dos dados para essa variável.
Se os dados forem embalados scale\_factor e/ou add\_offset , actual\_range deve ter valores descompactados e ser do mesmo tipo de dados que os valores desempactados.
Para algumas fontes de dados (por exemplo, todos EDDTableDe... Conjuntos de dados de arquivos) , ERDDAP™ determina o actual\_range de cada variável e define o actual\_range atributo. Com outras fontes de dados (por exemplo, bases de dados relacionais, Cassandra, DAP Per... Hyrax ) , pode ser problemático ou pesado para a fonte para calcular o intervalo, então ERDDAP™ não o pede. Neste caso, é melhor se você pode definir actual\_range (especialmente para as variáveis longitude, latitude, altitude, profundidade e tempo) adicionando um actual\_range atributo a cada variável [< addAttributes > (#addattributes) para este conjunto de dados datasets.xml Por exemplo,

<att name="actual\_range" type="doubleList"\>-180 180</att>

Para numérico variáveis tempo e timestamp , os valores especificados devem ser a fonte relevante (não destino) valores numéricos. Por exemplo, se os valores de tempo de origem são armazenados como "dias desde 1985-01-01-01", então o actual\_range deve ser especificado em "dias desde 1985-01-01". E se você quiser se referir a AGORA como o segundo valor para dados quase em tempo real que é periodicamente atualizado, você deve usar NaN . Por exemplo, para especificar um intervalo de dados de 1985-01-17 até AGORA, use

<att name="actual\_range" type="doubleList"\>16 NaN</att>

Se actual\_range é conhecido (por ERDDAP™ calculando-o ou adicionando-o via< addAttributes > ERDDAP™ irá exibi-lo ao usuário no formulário de acesso de dados ( * datasetID * .html) e fazer um gráfico páginas da web ( * datasetID * .) para esse conjunto de dados e usá-lo ao gerar os metadados FGDC e ISO 19115. Além disso, os últimos 7 dias do tempo actual\_range são usados como subconjunto de tempo padrão.
Se actual\_range é conhecido, os usuários podem usar min () e máximo () funções em pedidos, que muitas vezes é muito útil.
Para toda a EDDTable... conjuntos de dados, se actual\_range é conhecido (ou especificando-o ou por ERDDAP™ calculando-o) , ERDDAP™ será capaz de rejeitar rapidamente quaisquer pedidos de dados fora desse intervalo. Por exemplo, se o menor valor de tempo do conjunto de dados corresponder a 1985-01-17, então um pedido para todos os dados de 1985-01-01 até 1985-01-16 será imediatamente rejeitado com a mensagem de erro "Sua consulta não produziu resultados correspondentes". Isto faz actual\_range um pedaço muito importante de metadados, como pode salvar ERDDAP™ muito esforço e salvar o usuário muito tempo. E isso ressalta que actual\_range valores não devem ser mais estreitos do que o intervalo real dos dados; caso contrário, ERDDAP™ pode dizer erroneamente "Não há dados correspondentes" quando de fato há dados relevantes.
Quando um usuário seleciona um subconjunto de dados e solicita um tipo de arquivo que inclui metadados (por exemplo, .nc ) , ERDDAP™ modifica actual\_range no arquivo de resposta para refletir o intervalo do subconjunto.
Ver também data\_min e data\_max , que são uma maneira alternativa de especificar o actual\_range . No entanto, estes são deprecated agora que actual\_range é definido por CF 1.7+.

Atributos da barra de cor

Existem vários atributos variáveis OPTIONAL que especificam os atributos padrão sugeridos para uma barra de cores (usado para converter valores de dados em cores em imagens) para esta variável.

Se presente, essas informações são usadas como informações padrão por griddap e tabledap sempre que você solicitar uma imagem que use uma barra de cores.
Por exemplo, quando os dados gradeados de latitude-longitude são plotados como uma cobertura em um mapa, a barra de cores especifica como os valores de dados são convertidos em cores.
Ter esses valores permite ERDDAP™ criar imagens que usam uma barra de cores consistente em diferentes solicitações, mesmo quando o tempo ou outros valores de dimensão variam.
Estes nomes de atributos foram criados para uso em ERDDAP . Eles não são de um padrão de metadados.
Os atributos relacionados à barra de cores são:
- ** colorBarMinimum ** especifica o valor mínimo no colorBar. Por exemplo,
<att name="colorBarMinimum" type="double"\>-5</att>
- Se os dados forem embalados scale\_factor e/ou add\_offset , especifique o colorBarMinimum como um valor não embalado.
- Valores de dados inferiores ao colorBarMinimum são representados pela mesma cor que colorBarMinimum valores.
- O atributo deve ser de Tipo="duplo" , independentemente do tipo da variável de dados.
- O valor é geralmente um bom número redondo.
- Melhores práticas: Recomendamos um valor ligeiramente superior ao valor mínimo de dados.
- Não há valor padrão.
** colorBarMaximum ** especifica o valor máximo no colorBar. Por exemplo,

<att name="colorBarMaximum" type="double"\>5</att>

Se os dados forem embalados scale\_factor e/ou add\_offset , especifique o colorBarMinimum como um valor não embalado.
Valores de dados mais elevados do que colorBarMaximum são representados pela mesma cor que colorBarMaximum valores.
O atributo deve ser de Tipo="duplo" , independentemente do tipo da variável de dados.
O valor é geralmente um bom número redondo.
Melhores práticas: Recomendamos um valor ligeiramente inferior ao valor máximo dos dados.
Não há valor padrão.
cor da cor BarPalette especifica a paleta para o colorBar. Por exemplo,

        <att name="colorBarPalette">WhiteRedBlack</att>

Tudo ERDDAP™ instalações suportam estas paletas padrão: BlackBlueWhite, BlackRedWhite, BlackWhite, BlueWhiteRed, LightRainbow, Ocean, OceanDepth, Rainbow, RedWhiteBlue, ReverseRainbow, Topography, TopographyDepth \[ adicionado em v1.74 \] , WhiteBlack, WhiteBlueBlack e WhiteRedBlack.
Se tiver instalado paletas adicionais , você pode se referir a um deles.
Se este atributo não estiver presente, o padrão é BlueWhiteRed se \-1\* colorBarMinimum = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = colorBarMaximum ; caso contrário, o padrão é Rainbow.
cor de rosa especifica a escala para o colorBar. Por exemplo,

        <att name="colorBarScale">Log</att>

Os valores válidos são Linear e Log.
Se o valor for Log, colorBarMinimum deve ser maior que 0.
Se este atributo não estiver presente, o padrão é Linear.
cor da cor BarContinuidade especifica se o colorBar tem uma paleta contínua de cores, ou se o colorBar tem algumas cores discretas. Por exemplo,

        <att name="colorBarContinuous">false</att>

Os valores válidos são as strings verdadeiras e falsas.
Se este atributo não estiver presente, o padrão é verdadeiro.
colorBarNSections especifica o número padrão de seções no colorBar. Por exemplo,

        <att name="colorBarNSections" type="int">6</att>

Os valores válidos são inteiros positivos.
Se este atributo não estiver presente, o padrão é \-1, que diz ERDDAP™ para escolher o número de seções com base no intervalo do colorBar.

WMS

Os principais requisitos para uma variável a ser acessível através ERDDAP ' WMS servidor são:

O conjunto de dados deve ser um EDDGrid ... conjunto de dados.
A variável de dados DEVE ser uma variável grelhada.
A variável de dados MUST tem variáveis de longitude e de eixo de latitude. (Outras variáveis do eixo são OPTIONAL.)
Deve haver alguns valores de longitude entre -180 e 180.
O colorBarMinimum e colorBarMaximum atributos DEVE ser especificado. (Outros atributos de barras coloridas são OPTIONAL.)

data\_min e data\_max

** data\_min ** e ** data\_max ** - ... Estes são atributos variáveis deprecated definidos no World Ocean Circulation Experiment (WOCE) descrição de metadados. Por exemplo,

<att name="data\_min" type="float"\>0.17</att>
<att name="data\_max" type="float"\>23.58</att>

Recomendamos que você use actual\_range , em vez de data\_min e data\_max Porque actual\_range é agora definido pela especificação CF.
Se presente, eles devem ser do mesmo tipo de dados que o tipo de dados de destino da variável, e especificar o real (não o teórico ou o permitido) valores mínimos e máximos dos dados para essa variável.
Se os dados forem embalados scale\_factor e/ou add\_offset , data\_min e data\_max deve ser desembalado valores usando o tipo de dados desembalado.

variável drawLandMask

** drawLandMask ** - ... Este é um atributo variável OPTIONAL usado por ERDDAP™ (e sem padrões de metadados) que especifica o valor padrão para a opção "Draw Land Mask" no formulário Make A Graph do conjunto de dados ( * datasetID * .) e para o parâmetro &.land em uma URL solicitando um mapa dos dados. Por exemplo,

    <att name="drawLandMask">under</att>

Ver drawLandMask Visão geral .

Codificação

\_Encontre
Este atributo só pode ser usado com variáveis String .
Este atributo é fortemente recomendado.
Este atributo é do NetCDF Guia do usuário (NUG) .
Internamente em ERDDAP™ , Strings são uma sequência de caracteres de 2 bytes que usam o Conjunto de caracteres Unicode UCS-2 .
Muitos tipos de arquivo apenas suportam caracteres 1-byte em Strings e, portanto, precisam deste atributo para identificar um associado charset (Página de código AKA) que define como mapear os 256 valores possíveis para um conjunto de 256 caracteres desenhados do conjunto de caracteres UCS-2 e/ou do sistema de codificação, por exemplo, UTF-8 (que requer entre 1 e 4 bytes por caracter) .
Os valores para \_Encoding são insensíveis a casos.
Em teoria, ERDDAP™ poderia suportar identificadores de codificação \_ esta lista de IANA Mas na prática, ERDDAP™ atualmente apenas suporta
- ISO-8859-1 (note que tem traços, não sublinha) , que tem a vantagem de que é idêntico aos primeiros 256 caracteres do Unicode, e
- UTF-8.
Ao ler arquivos de origem, o valor padrão é ISO-8859-1, exceto para arquivos netcdf-4, onde o padrão é UTF-8.
Este é um problema problemático em curso porque muitos arquivos de origem usam charsets ou codificações que são diferentes do ISO-8859-1, mas não identificam o charset ou codificação. Por exemplo, muitos arquivos de dados de origem têm alguns metadados copiados e colados a partir do Microsoft Word no Windows e, portanto, têm hífens extravagantes e apostrofes de um charset específico do Windows em vez de hífens e apostrofes ASCII. Esses personagens então aparecem como personagens estranhos ou '?' em ERDDAP .

arquivoAccessBaseUrl

** arquivoAccessBaseUrl e arquivoAccessSuffix** são atributos muito raramente usados que não são de qualquer padrão. Se uma coluna EDDTable tiver nomes de arquivo de arquivos acessíveis à web (por exemplo, imagem, vídeo ou arquivos de áudio) , você pode adicionar

    <att name="fileAccessBaseUrl">*someBaseURL*</a>

para especificar a URL base (final com /) necessário para fazer os nomes de arquivos em URLs completas. Em casos incomuns, como quando uma coluna tem referências a arquivos .png, mas os valores não ".png", você pode adicionar

    <att name="fileAccessSuffix">*someSuffix*</a>

(por exemplo,<att name="fileAccessSuffix">.png</a>) para especificar um sufixo a ser adicionado para fazer os nomes dos arquivos em URLs completas. Então, .htmlTable respostas, ERDDAP™ irá mostrar o nome do arquivo como um link para a URL completa (a base Url mais o nome do arquivo mais o sufixo) .

Se quiseres ERDDAP™ para servir os arquivos relacionados, fazer um separado EDDTable De Nomes de Arquivo dataset para esses arquivos (pode ser um conjunto de dados privado) .

arquivoAccessArchive Url.

arquivoAccessArchive Url. é um atributo muito raramente usado que não é de qualquer padrão. Se uma coluna EDDTable tiver nomes de arquivo de arquivos acessíveis à web (por exemplo, imagem, vídeo ou arquivos de áudio) que são acessíveis através de um arquivo (por exemplo, .zip arquivo) acessível através de uma URL, use<int name="fileAccessArchiveUrl"> O NOSSA </att> para especificar a URL para o arquivo.

Se quiseres ERDDAP™ para servir o arquivo, fazer um separado EDDTable De Nomes de Arquivo dataset para esse arquivo (pode ser um conjunto de dados privado) .

ioos\_category

** ioos\_category ** - ... Este é um atributo variável REQUIRED se<variáveisMustHaveIoosCategory> é definido como verdadeiro (o padrão) em setup.xml ; caso contrário, é OPTIONAL. Por exemplo,<Nome do anúncio ioos\_category "</att> As categorias são NOAA Sistema Integrado de Observação do Oceano (IOOS) .
(Como escrever isto) Não estamos cientes de definições formais desses nomes.
Os nomes principais são de Zdenka Willis' .ppt "Integrated Ocean Observing System (IOOS) NOAA Abordagem para construir uma capacidade operacional inicial" e do US IOOS Blueprint (página 1-5) .
É provável que esta lista seja revisada no futuro. Se você tem pedidos, por favor envie um e-mail para Chris. John no noaaa.gov.
ERDDAP™ suporta uma lista maior de categorias do que IOOS faz porque Bob Simons adicionou nomes adicionais (principalmente com base nos nomes de campos científicos, por exemplo, Biologia, Ecologia, Meteorologia, Estatística, Taxonomia) para outros tipos de dados.
Os valores válidos atuais em ERDDAP™ são Bathymetry, Biology, Bottom Character, CO2, Colored Dissolved Organic Matter, Contaminants, Currents, Dissolved Nutrients, Dissolved O2, Ecology, Fish Abundance, Fish Species, Heat Flux, Hydrology, Ice Distribution, Identifier, Location, Meteorology, Ocean Color, Optical Properties, Other, Pathogens, Phytoplank
Há alguma sobreposição e ambiguidade entre termos diferentes - faça o seu melhor.
Se você adicionar ioos\_category para a lista de< categoryAttributes > em ERDDAP ' setup.xml arquivo, os usuários podem facilmente encontrar conjuntos de dados com dados semelhantes via ERDDAP "Search for Datasets by Category" na página inicial. Tente usar ioos\_category para procurar conjuntos de dados de interesse.
Houve uma discussão sobre ERDDAP™ e ioos\_category no ERDDAP™ Google Group.

Você pode ser tentado a definir<variáveisMustHaveIoosCategory> para false para que este atributo não seja necessário. ("Pfft! O que é para mim?") Algumas razões para deixá-lo definido como verdadeiro (o padrão) e uso ioos\_category são:

Se setup.xml<variáveisMustHaveIoosCategoria> está definido como verdadeiro, Gerar conjuntos de dadosXml sempre cria/suggests an ioos\_category atributo para cada variável em cada novo conjunto de dados. Então porque não o deixa entrar?
ERDDAP™ permite que os usuários procurem conjuntos de dados de interesse por categoria. ioos\_category é uma categoria de pesquisa muito útil porque o ioos\_categories (por exemplo, Temperatura) são bastante amplas. Isto faz ioos\_category muito melhor para esta finalidade do que, por exemplo, o CF muito mais fino standard\_name S (que não são tão bons para este propósito por causa de todos os sinónimos e pequenas variações, por exemplo, mar\_surface\_temperatura versus sea\_water\_temperatura) . (Utilização ioos\_category para esta finalidade é controlada por< categoryAttributes > no seu ficheiro setup.xml.) Tente usar ioos\_category para procurar conjuntos de dados de interesse.
Estas categorias são NOAA Sistema Integrado de Observação do Oceano (IOOS) . Essas categorias são fundamentais para a descrição do IOOS da missão do IOOS. Se você estiver dentro NOAA , apoio ioos\_category é bom Um... NOAA coisa a fazer. (Olha para isto. Um. NOAA vídeo e ser inspirado!) Se você está em alguma outra agência dos EUA ou internacional, ou trabalhar com agências governamentais, ou trabalhar com algum outro Sistema de Observação do Oceano, não é uma boa ideia cooperar com o escritório do IOOS dos EUA?
Mais cedo ou mais tarde, você pode querer outros ERDDAP™ link para seus conjuntos de dados via EDDGrid De Erddap e EDDTable FromErddap . Se o outro ERDDAP™ requerimento ioos\_category , seus conjuntos de dados devem ter ioos\_category em ordem para EDDGrid De Erddap e EDDTableDe Erddap para trabalhar.
É psicologicamente muito mais fácil incluir ioos\_category quando você cria o conjunto de dados (É só outra coisa que ERDDAP™ exige adicionar o conjunto de dados para ERDDAP ) , do que adicioná-lo após o fato (se você decidiu usá-lo no futuro) .

long\_name

** long\_name ** ( COARDS , CF e ACÓRDÃO padrões de metadados) é um atributo variável RECOMENDADO em ERDDAP . Por exemplo,

    <att name="long\\_name">Eastward Sea Water Velocity</att>

ERDDAP™ usa o long\_name para rotular eixos em gráficos.
Melhores práticas: Capitalizar as palavras no long\_name como se fosse um título (capitalizar a primeira palavra e todas as palavras não-artigo) . Não inclua as unidades no long\_name . O nome longo não deve ser muito longo (geralmente<20 caracteres), mas deve ser mais descritivo do que o destinationName , que é muitas vezes muito conciso.
Se... long\_name " não é definido na variável Atributos de fonte ou< addAttributes > ERDDAP™ irá gerenciá-lo através da limpeza standard\_name (se apresentar) ou o destinationName .

missing\_value

** missing\_value ** e \_Fill Valor ( COARDS e CF ) são atributos variáveis que descrevem um número (por exemplo, -9999) que é usado para representar um valor ausente. Por exemplo,

<att name="missing\_value" type="double"\>-9999</att>

Para variáveis String, o padrão para ambos é "" (a string vazia) . Para variáveis numéricas, o padrão para ambos é NaN.

ERDDAP™ suportes missing\_value e \_FillValue, uma vez que algumas fontes de dados atribuem significados ligeiramente diferentes para eles.
Se presente, eles devem ser do mesmo tipo de dados que a variável.
Se os dados forem embalados scale\_factor e/ou add\_offset , o missing\_value e \_FillValue valores devem ser igualmente embalados. Da mesma forma, para uma coluna com valores de data/hora de caracteres que usam um local time\_zone , o missing\_value e os valores \_FillValue devem usar o fuso horário local.
Se uma variável usa esses valores especiais, o missing\_value e/ou atributos \_FillValue são REQUIRED.
Para variáveis tempo e timestamp (se a fonte é strings ou numeric) , missing\_value s e \_FillValues aparecem como "" (a string vazia) quando o tempo é escrito como uma corda e como NaN quando o tempo é escrito como um duplo. Os valores-fonte para missing\_value e \_FillValue não aparecerá nos metadados da variável.
Para variáveis String, ERDDAP™ sempre converte qualquer missing\_value s ou \_FillValue valores de dados em "" (a string vazia) . Os valores-fonte para missing\_value e \_FillValue não aparecerá nos metadados da variável.
Para variáveis numéricas: O missing\_value e \_FillValue aparecerá nos metadados da variável. Para alguns formatos de dados de saída, ERDDAP™ deixará estes números especiais intactos, por exemplo, você verá -9999. Para outros formatos de dados de saída (notavelmente formatos como texto como .csv e .htmlTable ) , ERDDAP™ substituirá esses números especiais com NaN ou ".
Alguns tipos de dados têm marcadores de valor ausente inerentes que não precisam ser explicitamente identificados com missing\_value ou atributos \_FillValue: variáveis flutuantes e duplas têm NaN (Não um número) , Os valores de corda usam a string vazia e os valores de caridade têm caráter \uffff (personagem #65535, que é o valor de Unicode para Não um personagem) . Os tipos de dados inteiros não têm marcadores de valor inerentes a falta.
Se uma variável integer tiver um valor ausente (por exemplo, uma posição vazia em um arquivo .csv) , ERDDAP™ interpretará o valor como definido missing\_value ou \_FillValue para essa variável. Se nenhum for definido, ERDDAP™ interpretará o valor como o valor ausente padrão para esse tipo de dados, que é sempre o valor máximo que pode ser mantido por esse tipo de dados: 127 para variáveis byte, 32767 para curto, 2147483647 para int, 9223372036854775807 por muito tempo, 255 para ubyte, 65535 para ushort, 4294967295 para uint, e 18446744073709551615 para ulong.

ADD \_FillValue ATTRIBUTES ?

ADD \_FillValue ATTRIBUTES ?
Cada vez ERDDAP™ carrega um conjunto de dados, verifica se as variáveis com tipos de dados de fonte de inteiro têm um definido missing\_value ou atributo \_FillValue. Se uma variável não, então ERDDAP™ imprime uma mensagem para o arquivo de log (começando com "Add \_FillValue Attribute?") recomendando que o ERDDAP™ administrador adicionar um \_Fill Atributo de valor para esta variável em datasets.xml . É muito útil para cada variável ter um \_FillValue ou missing\_value porque os valores ausentes são sempre possíveis, por exemplo, se um determinado arquivo em um conjunto de dados não tiver uma determinada variável, ERDDAP™ precisa ser capaz de apresentar essa variável como tendo todos os valores ausentes para essa variável. Se você decidir que uma variável não deve ter um atributo \_FillValue, você pode adicionar <not names="\_FillValue">null</att> em vez disso, que irá suprimir a mensagem para isso datasetID + combinação variável no futuro.

Cada vez ERDDAP™ inicia-se, recolhe todas essas recomendações em uma mensagem que é escrita no arquivo de log (começando com " ADD \_FillValue ATTRIBUTES ?") , enviado para o ERDDAP™ administrador e escrito em um arquivo de dados CSV no \[ Diretriz de grande porte \] /logs / diretório. Se você quiser, você pode usar o programa GerarDatasetsXml (e a opção AddFillValueAttributes) para aplicar todas as sugestões no arquivo CSV para o datasets.xml ficheiro. Para qualquer um dos datasetID / combinações variáveis nesse arquivo, se você decidir que não há necessidade de adicionar o atribuído, você pode alterar o atributo<not names="\_FillValue">null</att> para suprimir a recomendação para isso datasetID + combinação variável no futuro.

Isto é importante! Como Bob disse muitas vezes: seria ruim (e embaraçoso) se algumas das evidências do aquecimento global foram causadas por valores ausentes não identificados nos dados (por exemplo, valores de temperaturas de 99 ou 127 graus\_ C que deveria ter sido marcado como valores ausentes e, portanto, distorceu as estatísticas médias e/ou medianas mais altas) .

O \_FillValue e missing\_value valores para uma determinada variável em diferentes arquivos de origem devem ser consistentes; caso contrário, ERDDAP™ aceitará arquivos com um conjunto de valores e rejeitará todos os outros arquivos como "Bad Files". Para resolver o problema,
- Se os arquivos são gradeados .nc arquivos, você pode usar EDDGrid A partir de NcFilesUnpacked .
- Se os arquivos são arquivos de dados tabulares, você pode usar EDDTableFrom...Files ' padronizar O quê? para contar ERDDAP para padronizar os arquivos de origem como eles são lidos ERDDAP .
- Para problemas mais difíceis, você pode usar NcML ou NCO para resolver o problema.

scale\_factor

** scale\_factor ** (default = 1) e ** add\_offset ** (padrão = 0) ( COARDS e CF ) são atributos variáveis OPTIONAL que descrevem dados que são embalados em um tipo de dados mais simples através de uma transformação simples.
Se presente, seu tipo de dados é diferente do tipo de dados de origem e descreve o tipo de dados dos valores de destino. Por exemplo, uma fonte de dados pode ter armazenado valores de dados flutuantes com um dígito decimal embalado como pequenos pontos (Intérprete) , usando scale\_factor = 0,1 e add\_offset = 0. Por exemplo,

<att name="scale\_factor" type="float"\>0.1</att>
<att name="add\_offset" type="float"\>0</att>

Neste exemplo, ERDDAP™ descompactar os dados e apresentá-los ao usuário como valores de dados flutuantes.

Se presente, ERDDAP™ irá extrair os valores desses atributos, remover os atributos e descompactar automaticamente os dados para o usuário: destino Valor = fonte Valor \* scale\_factor + add\_offset
Ou, declarou outra maneira: unpackedValue = embalado Valor \* scale\_factor + add\_offset
O scale\_factor e add\_offset valores para uma determinada variável em diferentes arquivos de origem devem ser consistentes; caso contrário, ERDDAP™ aceitará arquivos com um conjunto de valores e rejeitará todos os outros arquivos como "Bad Files". Para resolver o problema,
- Se os arquivos são gradeados .nc arquivos, você pode usar EDDGrid A partir de NcFilesUnpacked .
- Se os arquivos são arquivos de dados tabulares, você pode usar EDDTableFrom...Files ' padronizar O quê? para contar ERDDAP para padronizar os arquivos de origem como eles são lidos ERDDAP .
- Para problemas mais difíceis, você pode usar NcML ou NCO para resolver o problema.

standard\_name

** standard\_name ** (do CF padrão de metadados) é um atributo variável RECOMENDADO em ERDDAP . CF mantém a lista de permitidos Nomes padrão CF . Por exemplo,

    <att name="standard\\_name">eastward\\_sea\\_water\\_velocity</att>

Se você adicionar standard\_name a atributos de variáveis e adicionar standard\_name para a lista de< categoryAttributes > em ERDDAP ' setup.xml arquivo, os usuários podem facilmente encontrar conjuntos de dados com dados semelhantes via ERDDAP "Search for Datasets by Category" na página inicial.
Se você especificar um CF standard\_name para uma variável, as unidades atributo para a variável não têm de ser idênticas às Unidades Canonical especificadas para o nome padrão na tabela CF Standard Name, mas as unidades MUST ser convertíveis para as Unidades Canonical. Por exemplo, todos os CF relacionados à temperatura standard\_name tem "K" (Kelvin.) como Unidades Cânones. Assim, uma variável com relação à temperatura standard\_name MUST ter unidades de K, grau\_C, grau\_F, ou alguma variante UDUnits desses nomes, uma vez que eles são todos interconversíveis.
Melhores práticas: Parte do poder do vocabulários controlados vem de usar apenas os termos na lista. Então recomendamos manter os termos definidos no vocabulário controlado, e recomendamos contra a composição de um termo se não houver um apropriado na lista. Se você precisar de termos adicionais, consulte se o comitê de padrões os adicionará ao vocabulário controlado.
standard\_name Os valores são os únicos valores de atributos CF que são sensíveis a casos. São sempre todos minúsculos. Começar ERDDAP™ v1.82, GerarDatasets irá converter letras maiúsculas para letras minúsculas. E quando um conjunto de dados é carregado ERDDAP , letras maiúsculas são silenciosamente alteradas para letras minúsculas.

time\_precision

time\_precision é um atributo OPTIONAL usado por ERDDAP™ (e sem padrões de metadados) para variáveis tempo e timestamp , que pode estar em conjuntos de dados ou conjuntos de dados tabulares, e em axisVariable ou dataVariable S. Por exemplo,

    <att name="time\\_precision">1970-01-01</att>

time\_precision especifica a precisão a ser utilizada sempre que ERDDAP™ formata os valores de tempo dessa variável como strings em páginas web, incluindo .htmlTable respostas. Em formatos de arquivo onde ERDDAP™ formatos vezes como strings (por exemplo, .csv e .json ) , ERDDAP™ apenas usa o time\_precision - formato especificado se incluir segundos fracionários; caso contrário, ERDDAP™ usa o 1970-01T00:00 Formato Z.

Valores válidos são 1970-01, 1970-01-01-01, 1970-01T00Z, 1970-01-01T00:00Z, 1970-01T00:00 (o padrão) , 1970-01T00:00:00:00.0Z, 1970-01T00:00:00:00.00Z, 1970-01T00:00:00.000Z. \[ 1970 não é uma opção porque é um único número, então ERDDAP™ não pode saber se é uma cadeia de tempo formatada (um ano) ou se for um número de segundos desde 1970-01T00:00Z. \]
Se time\_precision não é especificado ou o valor não é correspondido, o valor padrão será usado.
Aqui, como em outras partes de ERDDAP™ , quaisquer campos do tempo formatado que não são exibidos são assumidos ter o valor mínimo. Por exemplo, 1985-07, 1985-07-01, 1985-07-01T00Z, 1985-07-01T00:00Z, e 1985-07-01T00:00:00 Z são todos considerados equivalentes, embora com diferentes níveis de precisão implícitos. Isto corresponde ao ISO 8601:2004 "extended" Especificação do formato do tempo .
ATENÇÃO: Você só deve usar um limitado time\_precision se Todos dos valores de dados para a variável têm apenas o valor mínimo para todos os campos ocultos.
Por exemplo, você pode usar um time\_precision de 1970-01-01 se todos os valores de dados têm hora=0, minuto=0, e segundo=0 (por exemplo 2005-03-04T00:00:00Z e 2005-03-05T00:00:00Z) .
Por exemplo, não use um time\_precision de 1970-01-01 se houver valores não-0 hora, minuto ou segundos, (por exemplo 2005-03-05T12:00Z) porque o valor de hora não padrão não seria exibido. Caso contrário, se um usuário pedir todos os dados com time=2005-03-05, o pedido falhará inesperadamente.

time\_zone

** time\_zone **
time\_zone é um atributo OPTIONAL usado por ERDDAP™ (e sem padrões de metadados) para variáveis tempo e timestamp , que pode estar em conjuntos de dados gradeados ou conjuntos de dados tabulares.
O padrão é " Zulu " (que é a versão moderna do fuso horário de GMT) .
InformaÃ§Ãμes de fundo: "tempo compensa" (por exemplo, Pacific Standard Time, -08:00, GMT-8) são fixos, específicos, compensações em relação a Zulu (GMT) . Em contraste, "zonas do tempo" são as coisas muito mais complexas que são afetadas pelo Daylight Saving (por exemplo, "US/Pacific") , que tiveram regras diferentes em lugares diferentes em tempos diferentes. Os fusos horários sempre têm nomes, pois não podem ser resumidos por um simples valor de deslocamento (veja a coluna "Nomes de banco de dados TZ" na tabela https://en.wikipedia.org/wiki/List\_of\_tz\_database\_time\_zones ) . ERDDAP ' time\_zone atributo ajuda você a lidar com dados de tempo local de algum fuso horário (por exemplo, 1987-03-25T17:32:05 Pacífico Tempo) . Se você tiver dados de tempo de cadeia ou numérica com um (fixo) tempo de deslocamento, você deve simplesmente ajustar os dados para Zulu (que é o que ERDDAP™ desejos) especificando um tempo de base diferente no atributo unidades (por exemplo, "horas desde 1970-01T08:00:00Z", note o T08 para especificar o deslocamento do tempo) , e sempre verifique os resultados para garantir que você obtenha os resultados que deseja.
Para variáveis de timestamp com dados de origem de Strings, este atributo permite especificar um fuso horário que leva ERDDAP™ para converter os tempos de origem da zona local (alguns em tempo padrão, alguns em tempo de verão) para dentro Zulu vezes (que estão sempre em tempo padrão) . A lista de nomes de fuso horário válidos é provavelmente idêntica à lista na coluna TZ na https://en.wikipedia.org/wiki/List\_of\_tz\_database\_time\_zones . Os fusos horários comuns dos EUA são: US/Hawaii, US/Alaska, US/Pacific, US/Mountain, US/Arizona, US/Central, US/Eastern.
Para variáveis de timestamp com dados de origem numérica, você pode especificar o " time\_zone "atributo, mas o valor deve ser " Zulu "ou "UTC". Se você precisar de suporte para outros fusos horários, por favor envie um e-mail para Chris. John em noaaa.gov .

herdado_tempo_ajustar

herdado_tempo_ajustar Começar ERDDAP™ 2.29.0, as variáveis temporais funcionam de forma ligeiramente diferente. Em casos raros, mais provavelmente ao usar dias desde e um ano antes de 1582 (Então... dias desde 0000-01-01 ou dias desde 1-1-1 00:00:0.0 ) você precisará indicar para um ajuste para a variável de data. A razão para isto é ERDDAP™ usa a biblioteca java.time para gerenciar datas internamente. Existem alguns conjuntos de dados que exigem usar a antiga biblioteca GregorianCalendar para descobrir as datas corretas.

<axisVariable>
    <sourceName>time</sourceName>
    <destinationName>time</destinationName>
    <!-- sourceAttributes>
        ... removed several lines ...
        <att name="units">days since 1-1-1 00:00:0.0</att>
    </sourceAttributes -->
    <addAttributes>
        ... removed several lines ...
        <att name="legacy_time_adjust">true</att>
    </addAttributes>
</axisVariable>

unidades

unidades ( COARDS , CF e ACÓRDÃO padrão de metadados) define as unidades dos valores de dados. Por exemplo,

    <att name="units">degree\\_C</att>

"unidades" é REQUIREDO como uma fonteAttribute ou um addAttribute para "time" variáveis e é STRONGLY RECOMENDADO para outras variáveis sempre que apropriado (que é quase sempre) .
Em geral, recomendamos UDUnits \- unidades compatíveis que são exigidas pelo COARDS e CF padrões.
Outro padrão comum é UCUM -- o Código Unificado para Unidades de Medição. OGC serviços como SOS , WCS e WMS exigem UCUM e muitas vezes referem-se a UCUM como UOM (Unidades de medida) .
Recomendamos que você use um padrão de unidades para todos os conjuntos de dados em seu ERDDAP . Devias contar. ERDDAP™ que padrão você está usando com<unidades\_standard>, em seu setup.xml ficheiro.
As unidades para uma determinada variável em arquivos de origem diferentes devem ser consistentes. Se você tem uma coleção de arquivos de dados onde um subconjunto dos arquivos usa valores de unidades diferentes de um ou mais outros subconjuntos dos arquivos (por exemplo, "dias desde 1985-01-01-01" versus "dias desde 2000-01-01", "degree\_Celsius" versus "deg\_C", ou "knots" versus "m/s") você precisa encontrar uma maneira de padronizar os valores das unidades, caso contrário, ERDDAP™ só carregará um subconjunto dos arquivos. Pense nisso: se um arquivo tiver windSpeed units=knots e outro tiver windSpeed units=m/s, então os valores dos dois arquivos não devem ser incluídos no mesmo conjunto de dados agregados.
- Se os arquivos são gradeados .nc arquivos, em muitas situações você pode usar EDDGrid A partir de NcFilesUnpacked .
- Se os arquivos são arquivos de dados tabulares, em muitas situações você pode usar EDDTableFrom...Files ' padronizar O quê? para contar ERDDAP para padronizar os arquivos de origem como eles são lidos ERDDAP .
- Para problemas mais difíceis, você pode usar NcML ou NCO para resolver o problema.
A seção padrão CF 8.1 diz que se os dados de uma variável forem embalados via scale\_factor e/ou add\_offset , "As unidades de uma variável devem ser representativas dos dados não embalados."
Para variáveis de tempo e timestamp, ou a variável Atributos de fonte ou< addAttributes > (que tem precedência) MAIS unidades que é ou
Para variáveis do eixo do tempo ou variáveis de dados do tempo com dados numéricos: UDUnits \- string compatível (com o formato unidades desde então baseTime ) descrevendo como interpretar valores de tempo de origem (por exemplo, segundos desde 1970-01-01T00:00Z) .

unidades pode ser qualquer um de:

    ms, msec, msecs, millis, millisec, millisecs, millisecond, milliseconds,  
    s, sec, secs, second, seconds, m, min, mins, minute, minutes, h, hr, hrs, hour, hours,  
    d, day, days, week, weeks, mon, mons, month, months, yr, yrs, year, or years.  

Tecnicamente, ERDDAP™ não segue o UDUNITS padrão ao converter "years since" e "months since" valores de tempo para "seconds since" . O UDUNITS padrão define um ano como um valor fixo, único: 3.15569259747e7 segundos. E UDUNITS define um mês como ano/12. Infelizmente, a maioria/todos os conjuntos de dados que vimos que usam "years since" ou "months since" claramente pretendem que os valores sejam anos de calendário ou meses de calendário. Por exemplo, 3 "months since 1970-01-01" é geralmente destinado a significar 1970-04-01. Então... ERDDAP™ interpreta "years since" e "months since" como anos de calendário e meses, e não segue estritamente o UDUNITS padrão.

O baseTime deve ser uma ISO 8601:2004 (E) data formatada cadeia de tempo ( yyyy-MM-dd 'T'HH:mm:ssZ, por exemplo, 1970-01T00:00:00Z) , ou alguma variação disso (por exemplo, com partes faltando no final) . ERDDAP™ tenta trabalhar com uma ampla gama de variações desse formato ideal, por exemplo, "1970-1-1 0:0:0" é suportado. Se a informação do fuso horário estiver faltando, presume-se que seja o Zulu fuso horário (AKA GMT) . Mesmo que outro deslocamento de tempo seja especificado, ERDDAP™ nunca usa o horário de verão. Se o baseTime usa algum outro formato, você deve usar< addAttributes > especificar uma nova cadeia de unidades que utilize uma variação do ISO 8601:2004 (E) formato (por exemplo, dias de mudança desde 1 de janeiro de 1985 em dias desde 1985-01-01-01.

Você pode testar ERDDAP capacidade de lidar com um específico unidades desde então baseTime com ERDDAP ' Conversor de Tempo . Esperemos que você possa conectar um número (o primeiro valor da fonte de dados?) e uma cadeia de unidades, clique em Converter e ERDDAP™ será capaz de convertê-lo em um ISO 8601:2004 (E) data formatada cadeia de tempo. O conversor retornará uma mensagem de erro se a cadeia de unidades não for reconhecível.

Unidades de tempo de corda

Para as unidades atribuem por variáveis de dados de tempo ou timestamp com dados String, você deve especificar um java.time.DateTimeFormatter padrão (que é principalmente compatível com java.text. Simples de usar) que descreve como interpretar os tempos de cadeia.

Para os formatos de tempo comumente usados que são variações do ISO 8601:2004 (E) formato padrão (por exemplo, 2018-01-02T00:00Z) , você pode especificar variações de yyyy-MM-dd 'T'HH:mm:ssZ, por exemplo, use yyyy-MM-dd se o tempo de cadeia só tiver uma data. Para qualquer formato que comece com yyyy-M, ERDDAP usa um parser especial que é muito perdoando de pequenas variações no formato. O parser pode lidar com fusos horários no formato 'Z', "UTC", "GMT", ±XX:XX, ±XXXX e formatos ±XX. Se partes do tempo de data não forem especificadas (por exemplo, minutos e segundos) , ERDDAP™ assume o menor valor para esse campo (por exemplo, se os segundos não forem especificados, segundos=0 é assumido) .

Para todos os outros formatos de tempo de cadeia de caracteres, você precisa especificar precisamente uma cadeia de formato de tempo compatível com DateTimeFormatter. Tipo... yyyy-MM-dd 'T'HH:mm:ssZ, estas cadeias de formato são construídas a partir de caracteres que identificam um tipo específico de informação da cadeia de tempo, por exemplo, m significa minuto de hora. Se você repetir o caractere de formato algum número de vezes, ele refinará ainda mais o significado, por exemplo, m significa que o valor pode ser especificado por qualquer número de dígitos, mm significa que o valor deve ser especificado por 2 dígitos. O Java documentação para DateTimeFormatter é uma visão geral bruta e não torna esses detalhes claros. Então aqui está uma lista de variações de caracteres de formato e seu significado dentro ERDDAP™ (que às vezes é ligeiramente diferente de Java DataTimeFormatter) :

| Personagens | Exemplos | Significado | | -... | -... | -... | | u, y, Y | \-4712, 0, 1, 10, 100, 2018 | um número de ano, qualquer número de dígitos. ERDDAP™ guloseimas y (ano de idade) e Y (ano baseado na semana, porque isso é frequentemente usado erroneamente em vez de y) como u, o número de ano astronômico . Os anos astronômicos são inteiros positivos ou negativos que não usam o BC (A.C.) ou CE (ANÚNCIA) designadores da era: 2018=2018CE, ..., 2=2CE, 1=1CE, 0=1BCE, -1=2BCE, -2=3BCE, ... | | uuuuu, yyyy, Sim. | \-4712, 0000, 0001, 0010, 0100, 2018 | um número de ano astronômico de 4 dígitos (ignorando qualquer precedente '-) | | M | 1, 01, 12 | um número de mês, qualquer número de dígitos (1 de Janeiro) | | MM | 01, 12 | a 2 dígitos (zero acolchoado) número do mês | | MMM | Jan, jan, JAN | a 3 letra Nome do mês inglês, caso insensível | | MMMM | Janeiro, Janeiro, Janeiro, Janeiro, Janeiro, JANEIRO | uma letra 3 ou nome completo do mês Inglês, caso insensível | | D | 1, 01, 31 | um número de dia de mês, qualquer número de dígitos | | D | 01, 31 | a 2 dígitos (zero acolchoado) dia de mês. O primeiro 'digit' pode ser um espaço. | | D | 1, 001, 366 | dia-de-ano, qualquer número de dígitos, 001=Jan 1 | | DDD | 001, 366 | dia de ano, 3 dígitos, 001=Jan 1 | | E | thu, THU, Thu | uma carta dia-de-semana, o valor é ignorado ao analisar | | E | quinta-feira, quinta-feira | uma letra 3 ou dia-de-semana inglês completo, caso insensível, o valor é ignorado ao analisar | | H. H. | 0, 00, 23 | H hora do dia (0-23) , qualquer número de dígitos | | HH | 00, 23 | HH hora do dia (00-23) 2 dígitos. O primeiro 'digit' pode ser um espaço. | | um | am, AM, pm, PM | AM ou PM, caso-insensível | | h | 12, 1, 01, 11 | relógio de hora-de-m-pm (12, 1, 2, ... 11) , qualquer número de dígitos | | Hã | 12, 01, 11 | relógio de hora-de-m-pm (12, 1, 2, ... 11) 2 dígitos. O primeiro 'digit' pode ser um espaço. | | KK | 1, 11 | hora de am-pm (0, 1, ...11) , qualquer número de dígitos | | KKK | 00, 01, 11 | hora-de-am-pm, 2 dígitos | | m | 0, 00, 59 | minuto de hora, qualquer número de dígitos | | mm | 00, 59 | minuto de hora, 2 dígitos | | S | 0, 00, 59 | segundo minuto, qualquer número de dígitos | | S | 00, 59 | 2 dígitos | | S | 0, 000, 9, 999 | fração de segundo, como se segue um ponto decimal, qualquer número de dígitos | | SS | 00, 99 | centos de um segundo, 2 dígitos | | SISTEMA | 000, 999 | milhares de segundo, 3 dígitos | | A | 0, 0000, 8639999999 | millisecond-of-day, qualquer número de dígitos | | AAAAAAAA | 00000000, 8639999999 | millisecond-of-day, 8 dígitos | | N | 0, 00000000000000, 8639999999999999999999 | nanossegundos-de-dia, qualquer número de dígitos. Em ERDDAP™ , isto é truncado para nMillis. | | NNNNNNNNNNNNNNN | 00000000000000, 86399999999999999999 | nanossegundo dia, 14 dígitos. Em ERDDAP™ Isto é truncado para nMillis. | | n | 0, 00000000000, 5999999999999 | nanossegundo de segundo, qualquer número de dígitos. Em ERDDAP™ Isto é truncado para nMillis. | | NENHUMN | 00000000000, 599999999999999 | nanossegundo de segundo, 11 dígitos. Em ERDDAP™ Isto é truncado para nMillis. | | XXX, ZZZ | Z, -08:00, +01:00 | um fuso horário com o formato 'Z' ou ± (deslocamento de 2 dígitos hora) : (deslocamento de 2 dígitos minuto) . Isto trata espaço como + (não padrão) . ZZZ suportando 'Z' não é padrão, mas lida com um erro de usuário comum. | | XX, ZZ | Z -0800, +0100 | um fuso horário com o formato 'Z' ou ± (deslocamento de 2 dígitos hora) : (deslocamento de 2 dígitos minuto) . Isto trata espaço como + (não padrão) . ZZ suportando 'Z' não é padrão, mas lida com um erro de usuário comum. | | X, Z | Z, -08, +01 | um fuso horário com o formato 'Z' ou ± (deslocamento de 2 dígitos hora) : (deslocamento de 2 dígitos minuto) . Isto trata espaço como + (não padrão) . Z suportando 'Z' não é padrão, mas lida com um erro de usuário comum. | | ? | \-08:00, +01:00 | um fuso horário com o formato ± (deslocamento de 2 dígitos hora) : (deslocamento de 2 dígitos minuto) . Isto trata espaço como + (não padrão) . | | xxxx | +0100 | um fuso horário com o formato ± (deslocamento de 2 dígitos hora) (deslocamento de 2 dígitos minuto) . Isto trata espaço como + (não padrão) . | | x | \-08, +01 | um fuso horário com o formato ± (deslocamento de 2 dígitos hora) . Isto trata espaço como + (não padrão) . | | ' | 'T', 'Z', 'GMT' | início e fim de uma série de caracteres literais | | ' ' (duas citações únicas) | ' ' | duas únicas citações denota uma única citação literal | | \[ \] | \[ \] | o início (" \[ ") e fim (" \] ") de uma seção opcional. Esta notação é suportada apenas para caracteres literais e no final da cadeia de formato. | | #, {, } | #, {, } | reservado para uso futuro | | G, L, Q,e,c,V,z,O,p | | Estes caracteres de formatação são suportados por Java 's DateTimeFormatter, mas atualmente não suportado por ERDDAP . Se você precisar de suporte para eles, e-mail Chris. John em noaaa.gov . |

Notas:

Em um tempo de data com pontuação, valores numéricos podem ter um número variável de dígitos (por exemplo, no formato de data de folga dos EUA "1/2/1985", o mês e a data podem ser 1 ou 2 dígitos) assim o formato deve usar tokens de 1 letra, por exemplo, M/d/yyyyy, que aceitam qualquer número de dígitos por mês e data.
Se o número de dígitos para um item for constante, por exemplo, 01/02/1985, em seguida, especifique o número de dígitos no formato, por exemplo, MM/dd/yyyyyyyyy para 2 dígitos mês, data de 2 dígitos e 4 dígitos ano.
Estes formatos são complicados para trabalhar com. Um determinado formato pode funcionar para a maioria, mas não todos, strings de tempo para uma determinada variável. Sempre verifique se o formato que você especificar está funcionando como esperado em ERDDAP para todas as cadeias de tempo de uma variável.
Quando possível, GerarDatasetXml sugerirá strings de formato de tempo.
Se você precisar de ajuda para gerar uma string de formato, envie um e-mail para Chris. John em noaaa.gov .

A principal variável de dados de tempo (para conjuntos de dados tabulares) e a variável principal eixo de tempo (para conjuntos de dados gradeados) são reconhecidos pelo destinationName Hora. Seus metadados de unidades devem ser uma cadeia de unidades compatíveis com UDUnits para valores numéricos de tempo, por exemplo, "dias desde 1970-01-01" (para conjuntos de dados tabulares ou gradeados) ou unidades adequadas para tempos de cadeia Por exemplo, "M/d/yyyyyy" (para conjuntos de dados tabulares) .

Unidades de tempo diferentes em diferentes grades .nc Arquivos - Se você tem uma coleção de grade .nc arquivos onde, para a variável de tempo, um subconjunto dos arquivos usa unidades de tempo diferentes de um ou mais outros subconjuntos dos arquivos, você pode usar EDDGrid A partir de NcFilesUnpacked . Converte valores de tempo para "seconds since 1970-01-01T00:00:00Z" em um nível inferior, escondendo assim as diferenças, para que você possa fazer um conjunto de dados da coleção de arquivos heterogêneos.

Variáveis de fuso horário

Variáveis de fuso horário - ... Qualquer outra variável ( axisVariable ou dataVariable Em um EDDGrid ou conjunto de dados EDDTable) pode ser uma variável timeStamp. As variáveis de timestamp são variáveis que têm unidades relacionadas ao tempo e dados de tempo, mas têm< destinationName > excepto o tempo. As variáveis TimeStamp comportam-se como a variável de tempo principal na medida em que convertem o formato de tempo da fonte em "seconds since 1970-01-01T00:00:00Z" e/ou ISO 8601:2004 (E) formato). ERDDAP™ reconhece o tempo Variáveis do carimbo por seu tempo relacionado " unidades " metadados, que devem corresponder a esta expressão regular " \[ a-zA-Z \] + + uma vez + \[ 0-9 \] .+ (para data numérica Times, por exemplo, "seconds since 1970-01-01T00:00:00Z" ) ou ser uma data string de formato de tempo contendo "uuuuu", "yyyy" ou "YYYY" (por exemplo, " yyyy-MM-dd "T'HH:mm:sZ") . Mas por favor ainda use destinationName "time" para a data principal Variável de tempo.

Verifique sempre o seu trabalho para ter certeza de que os dados de tempo que aparecem ERDDAP™ é os dados de tempo corretos. Trabalhar com dados de tempo é sempre complicado e propenso a erros.

Ver mais informações sobre variáveis de tempo . ERDDAP™ tem um utilitário para Converter um numérico Tempo para / de um tempo de corda . Ver Como? ERDDAP™ Lidas com o tempo .

valid\_range

** valid\_range ** ou ** valid\_min ** e ** valid\_max ** - ... Estes são atributos variáveis OPTIONAL definidos no CF convenções de metadados. Por exemplo,

<att name="valid\_range" type="floatList"\>0.0 40.0</att>

<att name="valid\_min" type="float"\>0.0</att>
<att name="valid\_max" type="float"\>40.0</att>

Se presente, eles devem ser do mesmo tipo de dados que a variável, e especificar os valores mínimos e máximos válidos dos dados para essa variável. Os usuários devem considerar valores fora deste intervalo para ser inválido.
ERDDAP™ não aplica o valid\_range . Disse outra maneira: ERDDAP™ não converte valores de dados fora do valid\_range para o \_Fill Valor ou valor missing\_value . ERDDAP™ apenas passa neste metadados e deixa o aplicativo até você. Porquê? É para isso que servem os metadados. Se o provedor de dados quisesse, o provedor de dados poderia ter convertido os valores de dados fora do valid\_range para ser \_FillValues. ERDDAP™ não segundo adivinhe o provedor de dados. Esta abordagem é mais segura: se for mais tarde mostrado que o valid\_range era muito estreito ou incorreto, ERDDAP™ Não terá apagado os dados.
Se os dados forem embalados scale\_factor e/ou add\_offset , valid\_range , valid\_min e valid\_max deve ser o tipo de dados embalado e valores. Desde então ERDDAP™ aplica-se scale\_factor e add\_offset quando ele carrega o conjunto de dados, ERDDAP™ vai desfazer o pacote valid\_range , valid\_min e valid\max valores para que os metadados de destino (mostrado aos usuários) indicará o tipo e o intervalo de dados não embalados. Ou, se um unpacked\ valid\_range atributo está presente, ele será renomeado valid\_range quando ERDDAP™ carrega o conjunto de dados.

<removeMVRows >

Não. ** <removeMVRows> ** ] (#removemvrows) é uma tag OPTIONAL dentro de uma tag em datasets.xml para EDDTable FromFiles (incluindo todas as subclasses) conjuntos de dados, embora seja usado apenas para EDDTableFromMultidimNcFiles. Pode ter um valor de verdadeiro ou falso. Por exemplo, verdadeiro Isso remove qualquer bloco de linhas no final de um grupo onde todos os valores são missing\_value , \_FillValue, ou o CoHort ...Array valor perdido nativo (ou char=#32 para CharArrays) . Isto é para o tipo de arquivo CF DSG Multidimensional Array e arquivos semelhantes. Se for verdade, isso faz o teste adequado e assim sempre carrega todas as variáveis de dim máximo, então pode levar tempo extra. O valor padrão é falso. Recomendação -- Se possível para o seu conjunto de dados, recomendamos definir removeMVRows para false. Definir removeMVRows para true pode reduzir significativamente as solicitações, embora possam ser necessárias para alguns conjuntos de dados.

Introdução​

Um conjunto necessário​

Variáveis em datasets.xml​

Provedor de dados Formulário​

Ferramentas​

O programa não funciona?​

As ferramentas imprimem várias mensagens diagnósticas:​

Gerar conjuntos de dadosXml​

"0 ficheiros" Mensagem de erro​

Você precisa editar a saída de GerarDatasets Xml para torná-lo melhor.​

não adicionar nomes padrão​

Scripting​

Tipos Especiais/Pseudo Dataset​

EDDGrid De Erddap​

EDDTable FromErddap​

EDDGrid A partir de três​

EDDGrid LonPM180 De ErddapCatalog​

EDDGrid Lon0360 De ErddapCatalog​

EDDs De Ficheiros​

EDDTable FromEML e EDDTable FromEMLBatch​

EDDTable FromInPort​

addFillValueAtributos​

encontrar Duplicado Tempo​

Não.​

DasDds​

Bônus Ferramenta de terceiros: ERDDAP - Não.​

A estrutura básica do datasets.xml Arquivo​

XI.​

Notas​

Escolhendo o Tipo de Conjunto de Dados​

Servindo os dados como é​

Olá.​

Codificação de caracteres especiais​

XML não tolera erros de sintaxe​

Dicas de resolução de problemas​

Variáveis especiais​

Por que apenas duas estruturas básicas de dados?​

Dimensões​

Dados de grade projetados​

GIS e dados de reprojeção​

Tipos de dados​

bytes​

O que é?​

curto​

- Não.​

- Não.​

*​

longo​

ulongo​

flutuar​

duplo​

Charlie.​

String​

Limitações do tipo de dados​

ASCII​

JSON​

.nc 3 arquivos​

.nc 4 arquivos​

Arquivos NCCSV​

DAP​

Tipo de dados Comentários​

Arquivos de mídia​

Trabalhando com arquivos AWS S3​

S3 Buckets​

Credenciais AWS​

AWS / arquivos /​

Pontos finais personalizados S3​

ERDDAP™ e AWS S3 Buckets​

AWS S3 Dados abertos​

Acessando arquivos em um balde AWS S3​

Teste público AWS S3 Buckets​

Visualizando o conteúdo de um balde​

Fazendo uma tabela EDD FromFileNames Dataset with a AWS S3 Bucket​

Arquivos NcML​

NetCDF Operadores ( NCO )​

Limites ao tamanho de um conjunto de dados​

Mudar para ACDD-1.3​

Zarr​

Lista de conjuntos de dados de tipos​

EDDGrid​

Introdução

Um conjunto necessário

Variáveis em datasets.xml

Provedor de dados Formulário

Ferramentas

O programa não funciona?

As ferramentas imprimem várias mensagens diagnósticas:

Gerar conjuntos de dadosXml

"0 ficheiros" Mensagem de erro

Você precisa editar a saída de GerarDatasets Xml para torná-lo melhor.

não adicionar nomes padrão

Scripting

Tipos Especiais/Pseudo Dataset

EDDGrid De Erddap

EDDTable FromErddap

EDDGrid A partir de três

EDDGrid LonPM180 De ErddapCatalog

EDDGrid Lon0360 De ErddapCatalog

EDDs De Ficheiros

EDDTable FromEML e EDDTable FromEMLBatch

EDDTable FromInPort

addFillValueAtributos

encontrar Duplicado Tempo

Não.

DasDds

Bônus Ferramenta de terceiros: ERDDAP - Não.

A estrutura básica do datasets.xml Arquivo

XI.

Notas

Escolhendo o Tipo de Conjunto de Dados

Servindo os dados como é

Olá.

Codificação de caracteres especiais

XML não tolera erros de sintaxe

Dicas de resolução de problemas

Variáveis especiais

Por que apenas duas estruturas básicas de dados?

Dimensões

Dados de grade projetados

GIS e dados de reprojeção

Tipos de dados

bytes

O que é?

curto

- Não.

- Não.

*

longo

ulongo

flutuar

duplo

Charlie.

String

Limitações do tipo de dados

ASCII

JSON

.nc 3 arquivos

.nc 4 arquivos

Arquivos NCCSV

DAP

Tipo de dados Comentários

Arquivos de mídia

Trabalhando com arquivos AWS S3

S3 Buckets

Credenciais AWS

AWS / arquivos /

Pontos finais personalizados S3

ERDDAP™ e AWS S3 Buckets

AWS S3 Dados abertos

Acessando arquivos em um balde AWS S3

Teste público AWS S3 Buckets

Visualizando o conteúdo de um balde

Fazendo uma tabela EDD FromFileNames Dataset with a AWS S3 Bucket

Arquivos NcML

NetCDF Operadores ( NCO )

Limites ao tamanho de um conjunto de dados

Mudar para ACDD-1.3

Zarr

Lista de conjuntos de dados de tipos

EDDGrid