Práce s datasets.xml Soubor

\[ Tato webová stránka bude pouze zajímavé ERDDAP™ Správci. \]

Poté, co jste následovali ERDDAP™ Návod k instalaci , musíte upravit datasets.xml soubor v tomcat /content/erddap/ pro popis souborů dat, které máte ERDDAP™ instalace bude sloužit.

Můžete vidět příklad datasets.xml na GitHubu .

---

Úvod

Některá montáž nutná

Nastavení datového souboru v ERDDAP™ není jen otázkou ukazování na adresář nebo URL souboru. Musíte napsat část XML pro datasets.xml který popisuje datový soubor.

• V případě roštových souborů údajů, aby byl datový soubor v souladu s ERDDAP 's datovou strukturou pro roštovaná data, musíte identifikovat podmnožinu proměnných datového souboru, které sdílejí stejné rozměry. ( Proč? Jak? )
• Současná metadata datového souboru jsou importována automaticky. Ale pokud chcete upravit metadata nebo přidat jiná metadata, musíte je zadat v datasets.xml . A ERDDAP™ potřebuje další metadata, včetně globální atributy (např. infoUrl , instituce, sourceUrl , shrnutí a název) a proměnné atributy (např. long\_name a jednotky) . Stejně jako metadata, která jsou v současné době v datovém souboru, doplňují popisné informace do datového souboru, metadata požadovaná ERDDAP™ doplňuje popisné informace do souboru údajů. Další metadata jsou dobrým doplňkem k vašemu souboru dat a pomáhají ERDDAP™ lépe se snažte prezentovat svá data uživatelům, kteří je neznají.
• ERDDAP™ potřebuje, abys dělal speciální věci s zeměpisná délka, zeměpisná šířka, výška (nebo hloubka) , a časové proměnné .

Pokud si koupíte do těchto myšlenek a vynaložit úsilí vytvořit XML pro datasets.xml , dostanete všechny výhody ERDDAP™ včetně:

• Úplné vyhledávání textu pro soubory dat
• Hledat datové soubory podle kategorií
• Formuláře pro přístup k datům ( * datasetID * .html) takže můžete požádat o podmnožinu dat ve spoustě různých formátů souborů
• Formuláře na vyžádání grafů a map ( * datasetID * .graph)
• Web Map Service ( WMS ) pro mřížkované soubory dat
• RESTful přístup k vašim údajům

Making the datasets.xml vyžaduje značné úsilí pro prvních několik souborů údajů, ale Je to jednodušší. . Po prvním datovém souboru můžete často pro další datový soubor použít mnoho své práce. Naštěstí, ERDDAP™ přichází se dvěma Nástroje vám pomůže vytvořit XML pro každý soubor dat v datasets.xml . Když se zasekneš, uvidíš naše oddíl o získání dodatečné podpory .

Proměnné v datasets.xml

Od ERDDAP™ verze 2.29.0, datasets.xml je nyní (volitelně) zpracované Stringsubstitutor . To má mnoho využití včetně nastavení soukromých hodnot (jako hesla) pomocí proměnných prostředí. To může být vypnuto nastavením EnvParsing na false v setup.xml.

Poskytovatel údajů Formulář

Když k vám přijde poskytovatel údajů a doufá, že vám přidá nějaké údaje ERDDAP , může být obtížné a časově náročné shromažďovat všechna metadata (informace o datovém souboru) potřeba přidat soubor údajů do ERDDAP . Mnoho zdrojů údajů (například .csv soubory, Soubory Excelu, databáze) nemají žádná interní metadata, takže ERDDAP™ má formulář poskytovatele údajů, který shromažďuje metadata od poskytovatele údajů a poskytuje poskytovateli údajů další pokyny, včetně rozsáhlých pokynů pro Data v databázích . Předložené informace jsou převedeny na datasets.xml formát a pak e-mailem na ERDDAP™ Správce (Ty) a psáno (Přiložené) až velkýRodič rodičů /logs/dataProviderForm.log . Forma tak částečně automatizuje proces získání datového souboru do ERDDAP , ale ERDDAP™ Správce musí ještě dokončit datasets.xml střih a vypořádat se s získáním datového souboru (án) od poskytovatele nebo připojení k databázi.

Předkládání skutečných datových souborů z externích zdrojů je obrovské bezpečnostní riziko, takže ERDDAP™ s tím se nevyrovná. Musíte přijít na řešení, které funguje pro vás a poskytovatele dat, například, e-mail (pro malé soubory) , vytáhnout z mraku (například DropBox nebo Google Drive) , místo sftp (s hesly) nebo tenisky Čistá (USB disk nebo externí pevný disk) . Asi bys měl přijmout složky jen od lidí, které znáš. Budete muset skenovat soubory pro viry a přijmout další bezpečnostní opatření.

Není tam žádné spojení. ERDDAP™ na formulář poskytovatele údajů (např. ERDDAP™ domovská stránka) . Místo toho, když vám někdo řekne, že chce, aby jim jejich data doručila vaše ERDDAP , můžete jim poslat e-mail s nápisem: Ano, můžeme vaše data dostat do ERDDAP . Pro začátek prosím vyplňte formulář nahttps://yourUrl/erddap/dataProviderForm.html (nebo http:// pokud https:// není povoleno) . Až to dokončíte, zavolám vám, abych vám vysvětlila detaily. Pokud se jen chcete podívat na formulář (bez vyplnění) , můžete vidět formulář na ERD 's ERDDAP : Úvod , Část 1 , Část 2 , Část 3 a Část 4 . Tyto odkazy na ERD ERDDAP™ Pošlete mi informace, ne vy, takže s nimi neposílejte informace, pokud opravdu nechcete přidat data do ERD ERDDAP .

Chcete-li odstranit formulář poskytovatele dat ze svého ERDDAP™ , dát

<dataProviderFormActive>false</dataProviderFormActive>  

ve vašem souboru.xml.

Popud k tomu byl NOAA 's 2014 Přístup veřejnosti k výsledkům výzkumu (PARR) Směrnice , které vyžaduje, aby všechny NOAA environmentální údaje financované prostřednictvím dolarů daňových poplatníků jsou zpřístupněny prostřednictvím datové služby (nejen soubory) do 12 měsíců od stvoření. Takže je zde zvýšený zájem o používání ERDDAP™ zpřístupnit soubory dat prostřednictvím služby ASAP. Potřebovali jsme účinnější způsob, jak se vypořádat s velkým počtem poskytovatelů dat.

Zpětná vazba/návrhy? Tento formulář je nový, tak prosím e-mail erd dot data at noaa dot gov pokud máte nějakou zpětnou vazbu nebo návrhy na zlepšení.

Nástroje

ERDDAP™ přichází se dvěma programy příkazového řádku, které jsou nástroji, které vám pomohou vytvořit XML pro každý soubor dat, který chcete ERDDAP™ sloužit. Jakmile to nachystáš ERDDAP™ a spustit (alespoň jednou) , můžete najít a použít tyto programy v tomcat /webapps/erddap/WEB-INF adresář. Existují skripty Linux/Unix (s prodloužením .sh) a skripty Windows (s rozšířením .bat) pro každý program. \[ Na Linuxu, spusťte tyto nástroje jako stejný uživatel (Tomcat?) Tomcat. \] Když spustíte každý program, bude vám klást otázky. Pro každou otázku napište odpověď a stiskněte Enter. Nebo kdykoliv stiskněte ^C, abyste opustili program.

Program nebude fungovat?

• Pokud dostanete neznámý program (nebo podobné) chybová zpráva, problém je pravděpodobně, že operační systém nemohl najít Java . Musíš zjistit, kde Java je ve vašem počítači, pak upravit odkaz na javu v .bat nebo .sh soubor, který se snažíte použít.
• Pokud máte soubor se sklenicí nenalezen nebo třída nenalezena chybová zpráva, pak Java nemohl najít jednu ze tříd uvedených v .bat nebo .sh souboru se snažíte použít. Řešením je zjistit, kde .jar soubor je, a upravit java odkaz na něj v .bat nebo .sh souboru.
• Pokud používáte verzi Java který je příliš starý na program, program nebude fungovat a uvidíte chybovou zprávu jako Výjimku ve vlákně "main" java.lang.UnsupportedClassVersionError: některé/třída/jméno : Nepodporovaná major.málo verze některéČíslo
  Řešením je aktualizovat na nejnovější verzi Java a ujistěte se, že .sh nebo .bat soubor pro program používá.

Nástroje tisknou různé diagnostické zprávy:

• Slovo "ERROR" se používá, když se něco pokazilo, takže postup nebyl dokončen. I když je otravné, aby se chyba, chyba vás nutí vypořádat se s problémem.
• Slovo "WARNING" se používá, když se něco pokazilo, ale postup byl schopen dokončit. Tyhle jsou dost vzácné.
• Všechno ostatní je jen informativní zpráva. Můžete přidat \-verbose do GenerovatDatasetsXml nebo DasDds příkazový řádek pro získání dalších informativních zpráv, které někdy pomáhají řešit problémy.

Oba nástroje jsou velkou pomocí, ale stále musíte přečíst všechny tyto pokyny na této stránce pečlivě a dělat důležitá rozhodnutí sami.

GenerovatDatasetsXml

• GenerovatDatasetsXml je program příkazového řádku, který může generovat hrubý návrh datového souboru XML pro téměř jakýkoli typ datového souboru.

We STRONGLY RECOMMEND that you use GenerateDatasets Xml místo vytváření částí datasets.xml ručně, protože:

• Generovat soubory dat Xml funguje za sekundu. Dělat to ručně je nejméně hodinová práce, i když víte, co děláte.
• Generovat soubory dat Xml dělá lepší práci. Dělat to ručně vyžaduje rozsáhlé znalosti o tom, jak ERDDAP™ Funguje to. Je nepravděpodobné, že budete dělat lepší práci ručně. (Bob Simons vždy používá GenerátorDatasets Xml pro první návrh, a napsal ERDDAP .)
• Generovat soubory dat Xml vždy generuje platný kus datasets.xml . Jakýkoliv kus datasets.xml že budete psát bude pravděpodobně mít alespoň několik chyb, které brání ERDDAP™ od načtení souboru údajů. Často lidem trvá hodiny, než tyto problémy diagnostikují. Neztrácej čas. Nechte generovat Datové soubory Xml dělat tvrdou práci. Pak můžete vylepšit .xml rukou, pokud chcete.

Když používáte GeneranteDatasets Xml program:

• Na Windows, když poprvé spustíte GenerateDatasetsXml, musíte upravit soubor GenerateDatasetsXml.bat s textovým editorem pro změnu cesty k javě. exe soubor tak, aby Windows mohli najít Java .
• Generovat soubory dat Xml Vás nejprve požádá, abyste zadali EDDType (Erd Dap Dataset Typ) souboru údajů. Viz Seznam typů datových souborů (v tomto dokumentu) zjistit, který typ je vhodný pro datový soubor, na kterém pracujete. Kromě pravidelných EDDTypes, existuje také několik Speciální/Pseudo Typy datové sady (např. ten, který se plazí po katalogu THREDDS k vytvoření kusu datasets.xml pro každý soubor údajů v katalogu) .
• Generovat soubory dat Xml se vás pak zeptá na řadu otázek specifických pro tento EDDType. Otázky shromažďují informace potřebné pro ERDDAP™ přístup ke zdroji datového souboru. Abych pochopil co ERDDAP™ žádá, viz dokumentaci pro EDDType, kterou jste zadali kliknutím na stejný typ datového souboru v Seznam typů datových souborů .

Pokud potřebujete zadat řetězec se speciálními znaky (Znaky Whitespace na začátku nebo konci, jiné než ASCII) , zadejte String ve stylu JSON (se speciálními znaky utekl s \ znaky) . Například zadat pouze znak karty, zadejte "\t" (s okolními dvojitými citacemi, které říkají ERDDAP™ že tohle je řetězec ve stylu JSON.

• Často, jedna z vašich odpovědí nebude to, co GenerateDatasetsXml potřebuje. Pak můžete zkusit znovu, s revidovanými odpověďmi na otázky, až do GenerateDatasets Xml může úspěšně najít a pochopit zdrojová data.
• Pokud správně odpovíte na otázky (nebo dostatečně správně) , GenerátorDatasets Xml se připojí ke zdroji datového souboru a shromáždí základní informace (například názvy proměnných a metadata) . Pro soubory, které jsou z místních NetCDF .nc a související soubory, GeneratorDatasets Xml bude často tisknout ncdump-jako strukturu souboru po prvním čtení souboru. To vám může poskytnout informace k odpovědi na otázky lépe na následné smyčce přes GenerateDatasetsXml.
• Generovat soubory dat Xml pak vytvoří hrubý návrh datového XML pro tento datový soubor.
• Diagnostické informace a hrubý návrh datového souboru XML budou zapsány do velkýRodič rodičů /logs/GenerateDatasetsXml.log .
• Hrubý návrh souboru XML bude zapsán do velkýRodič rodičů /logs/GenerateDatasetsXml.out .

"0 souborů" Chyba zprávy

Pokud spustíte GenerateDatasets Xml nebo DasDds , nebo pokud se pokusíte načíst EDDGrid Z...Files nebo EDDTableFrom... Soubory souborů v ERDDAP™ , a dostanete chybovou zprávu "0 souborů" ukazující, že ERDDAP™ nalezeno 0 odpovídajících souborů v adresáři (když si myslíte, že jsou odpovídající soubory v tomto adresáři) :

• Zkontrolujte, zda jste zadali celé jméno adresáře. A pokud jste zadali název souboru vzorku, ujistěte se, že jste zadali celé jméno souboru, včetně celého názvu adresáře.

• Zkontrolujte, zda jsou soubory skutečně v adresáři.

• Zkontrolujte pravopis názvu adresáře.

• Zkontrolujte souborNameRegex. Je opravdu snadné dělat chyby s regexy. Pro testovací účely zkuste regex .\*, který by měl odpovídat všem názvům souborů. (Vidíš tohle? dokumentace regexu a reflexní tutoriál .)

• Zkontrolujte, zda uživatel, který program provozuje (např. user=tomcat (?) pro přípravek Tomcat/ ERDDAP ) má "číst" povolení pro tyto soubory.

• V některých operačních systémech (např. SELinux) a v závislosti na nastavení systému musí mít uživatel, který program spustil, oprávnění číst celý řetězec adresářů vedoucích do adresáře, který má soubory.

• Pokud máte problémy, které nemůžete vyřešit, požádat o podporu s co největším množstvím informací. Podobně, pokud se zdá, že vhodný EDDType pro daný datový soubor nefunguje s tímto datovým souborem, nebo pokud neexistuje vhodný EDDType, prosím, soubor vydání na GitHubu s údaji (a případně soubor vzorku) .  

Musíte editovat výstup z GenerateDatasets Xml, aby to bylo lepší.

 

• DISCLAIMER: SCHUNG OF datasets.xml VYROBIT GenerovatDatasady Xml není perfektní. Musíte číst a editovat XML, než jej použijete u veřejnosti ERDDAP . Generovat soubory dat Xml odpouští spoustě pravidel, která nejsou vždy správná. Jste zodpovědní za zajištění správnosti XML, ke kterému se připojíte ERDDAP 'S datasets.xml File.

  (Nekřičím. Z historických právních důvodů musí být zřeknutí se odpovědnosti zapsáno ve všech hlavičkách.)

Výstup GenerateDatasetsXml je hrubý návrh. Budete ho téměř vždy muset upravit. Vyvinuli jsme a i nadále vyvíjíme obrovské úsilí, abychom co nejpřipravenější výstup učinili, ale existují hranice. Ze zdrojových metadat nejsou často dostupné potřebné informace.

Základním problémem je, že žádáme počítačový program. (GenerovatDatasetsXml) dělat úkol, kde, pokud jste dali stejný úkol pro 100 lidí, dostanete 100 různých výsledků. Neexistuje jediná správná odpověď. Je zřejmé, že program je nejblíže čtení Bobovy mysli (Ne tvoje.) , ale i tak, to není vše-pochopení AI program, jen banda heuristiky dláždil dohromady dělat Al-jako úkol. (Ten den, kdy se všechno pochopí, může přijít, ale ještě nepřišel. Pokud ano, my lidé můžeme mít větší problémy. Opatrně, co si přeješ.)

• Pro informační účely ukazuje výstup globální zdrojAttributy a variabilní zdrojAttributy jako komentáře. ERDDAP™ kombinuje zdrojAttributy a addAttributes (které mají přednost) k výrobě kombinované Atributy, které jsou zobrazeny uživateli. (A další atributy jsou automaticky přidávány do délky, zeměpisné šířky, výšky, hloubky a časových proměnných, když ERDDAP™ vlastně vytváří soubor dat) .  

• Pokud nemáte rádi zdrojAttribute, přepište jej přidáním addAttribute se stejným názvem, ale jinou hodnotou (nebo bez hodnoty, pokud ji chcete odstranit) .  

• Všechny addAttributes jsou počítačové návrhy. Upravte je! Pokud nemáte rádi addAttribute, změňte to.  

• Pokud chcete přidat další addAttributes , přidejte je.  

• Pokud chcete změnit destinationName Změň to. Ale neměň se. sourceName s.  

• Můžete změnit pořadí dataVariable s nebo odstranit některý z nich.

  • Pak můžete použít DasDds (viz níže) opakovaně testovat XML pro tento datový soubor, aby bylo zajištěno, že výsledný datový soubor se objeví, jak chcete, aby v ERDDAP .
  • Neváhejte udělat malé změny na datasets.xml například vygenerovaný kus dodává lepší infoUrl , shrnutí nebo název.

DoNOTAddStandardNames

Pokud přidáte \-donotAddStandardNames jako parametr příkazového řádku při spuštění generování Datové soubory Xml, generovat Datové soubory Xml nepřidá standard\_name do addAttributes pro proměnné jiné než proměnné s názvem zeměpisná šířka, zeměpisná délka, výška, hloubka nebo čas (které mají očividné standard\_name án) . To může být užitečné, pokud používáte výstup z generování Datové soubory Xml přímo v ERDDAP™ bez úpravy výstupu, protože generovat Datové soubory Xml často hádá standard\_name špatně. (Všimněte si, že vždy doporučujeme upravit výstup před použitím v ERDDAP .) Použití tohoto parametru bude mít jiné menší související účinky, protože hádané standard\_name se často používá k jiným účelům, např. k vytvoření nového long\_name , a vytvořit nastavení barevBar.

Skriptování

Jako alternativu k interaktivnímu zodpovězení otázek na klávesnici a smyčce pro generování dalších souborů dat můžete poskytnout argumenty příkazových řádků, abyste mohli zodpovědět všechny otázky pro vytvoření jednoho datového souboru. Generovat soubory dat Xml tyto parametry zpracuje, napíše výstup do výstupního souboru a program ukončí.

Chcete-li to nastavit, nejprve použijte program v interaktivním režimu a zapište své odpovědi. Zde je částečný příklad: Řekněme, že spustíte skript: ./GenerateDatasetsXml.sh Pak zadejte: EDDTableFromAsciiFiles Pak zadejte: /u00/data/ Pak zadejte: .\ *\.ask Pak zadejte: /u00/data/sampleFile.asc Poté zadejte: ISO-8859-1

Pro neinteraktivní spuštění použijte tento příkaz: ./GenerateDatasetsXml.sh EDDTableFromAsciiFiles /u00/data/ .\*\.asc /u00/data/sampleFile.asc ISO-8859-1 Takže v podstatě vypíšete všechny odpovědi na příkazový řádek. To by mělo být užitečné pro soubory dat, které se často mění způsobem, který vyžaduje opětovné spuštění GenerateDatasets Xml (zejména EDDGrid FromThreddsCatalog) .

Podrobnosti:

• Pokud parametr obsahuje prostor nebo nějaký zvláštní znak, pak enkódovat parametr jako String ve stylu JSON , např. "můj parametr s mezerami a dvěma \n řádky."
• Pokud chcete zadat prázdný řetězec jako parametr, použijte:
• Pokud chcete zadat výchozí hodnotu parametru, použijte: výchozí  
• Generovat soubory dat Xml podporuje a -i Soubory údajů XmlName # Název značky parametr příkazového řádku, který vkládá výstup do zadaného datasets.xml soubor (výchozí je tomcat / content/ erddap/ datasets.xml ) . Generovat soubory dat Xml hledá dva řádky v souborech dat XmlName:

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

a

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

a nahradí vše mezi těmito řádky novým obsahem, a změní některéDatetime.

• Přepínač -i je pouze zpracován (a změny datasets.xml jsou pouze vyrobeny) Pokud spustíte GenerateDatasets Xml s argumenty příkazového řádku, které specifikují všechny odpovědi na všechny otázky pro jednu smyčku programu. (Viz výše "Scripting.") (Myšlenka je: Tento parametr je určen pro použití se skripty. Pokud program používáte v interaktivním režimu (psaní informací na klávesnici) , jste pravděpodobně generovat některé nesprávné kousky XML před tím, než si vytvořit ten, který chcete.)
• Pokud nejsou nalezeny Begin a End řádky, pak jsou tyto řádky a nový obsah vloženy těsně před</erddapDatasets>.
• Existuje také - I (kapitál i) přepínač pro testovací účely, který funguje stejně jako -i, ale vytváří soubor nazvaný datasets.xml Datum a nedělá změny datasets.xml .
• Nezkoušejte GenerovatDatasety Xml s -i ve dvou procesech najednou. Existuje šance, že bude zachována pouze jedna sada změn. Může to být vážný problém. (například poškozené soubory) .

Pokud používáte "GenerateDatasetsXml -verbose," vytiskne více diagnostických zpráv než obvykle.

Speciální/Pseudo Typy datové sady

Obecně platí, že možnosti EDDType v GenerateDatasets Xml shoda typů EDD popsaných v tomto dokumentu (viz Seznam typů datových souborů ) a vygenerovat jeden datasets.xml cuk pro vytvoření jednoho datového souboru z jednoho konkrétního zdroje dat. Existuje několik výjimek a zvláštních případů:

EDDGrid FromErddap

Tento EDDType generuje všechny datasets.xml kousky potřebné k výrobě EDDGrid FromErddap Data ze všech EDDGrid Data ve vzdáleném ERDDAP . Budete mít možnost ponechat si originál datasetID án (který může kopírovat některé datasetID již ERDDAP ) nebo generování nových jmen, které budou jedinečné (ale obvykle nejsou tak čitelné jako lidé.) .  

EDDTableFromErddap

Tento EDDType generuje všechny datasets.xml kousky potřebné k výrobě EDDTableFromErddap Soubory dat ze všech datových souborů EDDTable ve vzdáleném ERDDAP . Budete mít možnost ponechat si originál datasetID án (který může kopírovat některé datasetID již ERDDAP ) nebo generování nových jmen, které budou jedinečné (ale obvykle nejsou tak čitelné jako lidé.) .  

EDDGrid FromThreddsCatalog

Tento EDDType generuje všechny datasets.xml kousky potřebné pro všechny EDDGrid FromDap Soubory dat, které může najít tím, že se opakovaně plazí přes THREDDS (sub) Katalog. Existuje mnoho forem katalogových URL THREDDS. Tato volba REQUERES a THREDDS .xml URL s /catalog/ v ní, například, https://oceanwatch.pfeg.noaa.gov/thredds/catalog/catalog.xmlnebo https://oceanwatch.pfeg.noaa.gov/thredds/catalog/Satellite/aggregsatMH/chla/catalog.xml
(příbuzný katalog .html je na https://oceanwatch.pfeg.noaa.gov/thredds/Satellite/aggregsatMH/chla/catalog.html, které není přijatelné pro EDDGrid FromThreddsCatalog). Pokud máte problémy s EDDGrid FromThredds Katalog:

• Ujistěte se, že URL, kterou používáte, je platné, obsahuje /catalog/ a končí s /catalog.xml .
• Pokud je to možné, použijte veřejnou IP adresu (například:https://oceanwatch.pfeg.noaa.gov) v URL, nikoli místní numerická IP adresa (například:https://12.34.56.78) . Pokud je THREDDS přístupný pouze prostřednictvím místní číselné IP adresy, můžete použít [<convertToPublicSourceUrl>] (# Konvertovat na veřejné zdrojeurl) tak ERDDAP™ uživatelé vidí veřejnou adresu, i když ERDDAP™ získává data z místní číselné adresy.
• Pokud máte problémy, které nemůžete vyřešit, zkontrolovat tipy na odstraňování problémů .
• Nízkoúrovňové kód pro tento nyní používá Unidata katalogový kód netcdf-java (Thredds. Katalogové třídy) takže může zvládnout všechny katalogy THREDDS (což může být překvapivě složité.) Díky Unidata na ten kód.  

EDDGrid LonPM180FromErddapKatalog

Tento EDDType generuje datasets.xml k výrobě EDDGrid LonPM180 Data ze všech EDDGrid data v souboru ERDDAP jejichž délka je větší než 180.

• Pokud je to možné, použijte veřejnou IP adresu (například:https://oceanwatch.pfeg.noaa.gov) v URL, nikoli místní numerická IP adresa (například:https://12.34.56.78) . Pokud ERDDAP™ je přístupná pouze prostřednictvím místní číselné IP adresy, můžete použít [<convertToPublicSourceUrl>] (# Konvertovat na veřejné zdrojeurl) tak ERDDAP™ uživatelé vidí veřejnou adresu, i když ERDDAP™ získává data z místní číselné adresy.  

EDDGrid Lon0360FromErddapKatalog

Tento EDDType generuje datasets.xml k výrobě EDDGrid Lon0360 Data ze všech EDDGrid data v souboru ERDDAP jejichž délka je menší než 0.

• Pokud je to možné, použijte veřejnou IP adresu (například:https://oceanwatch.pfeg.noaa.gov) v URL, nikoli místní numerická IP adresa (například:https://12.34.56.78) . Pokud ERDDAP™ je přístupná pouze prostřednictvím místní číselné IP adresy, můžete použít [<convertToPublicSourceUrl>] (# Konvertovat na veřejné zdrojeurl) tak ERDDAP™ uživatelé vidí veřejnou adresu, i když ERDDAP™ získává data z místní číselné adresy.  

EDDsFromFoles

Vzhledem k startovnímu adresáři prochází adresář a všechny podadresáře a snaží se vytvořit soubor pro každou skupinu datových souborů, které najde.

• To předpokládá, že pokud je soubor údajů nalezen, soubor údajů zahrnuje všechny podadresáře.
• Pokud je soubor údajů nalezen, budou podobné adresáře sourozenců považovány za samostatné soubory dat (Například adresáře pro 90. léta, 2000 a 2010 budou vytvářet samostatné datové soubory) . Měli by být snadno kombinovat ručně - stačí změnit první datový soubor<fileDir> do mateřského adresáře a smažte všechny následující soubory sourozenců.
• Tohle se bude snažit vytvořit jen kus datasets.xml pro nejčastější typ přípony souboru v adresáři (nepočítám .md5, který je ignorován) . Takže, vzhledem k adresáři s 10 .nc soubory a 5 .txt soubory, soubor bude generován pro .nc Pouze soubory.
• To předpokládá, že všechny soubory v adresáři se stejným rozšířením patří do stejného datového souboru. Pokud má adresář nějaké .nc soubory s daty SST a některé .nc soubory s údaji o chlorofylu, pouze jeden vzorek .nc soubor bude přečten (SST? chlorofyl?) a pouze jeden soubor bude vytvořen pro tento typ souboru. Tento datový soubor se pravděpodobně nepodaří načíst kvůli komplikacím ze snaze načíst dva typy souborů do stejného souboru.
• Pokud existuje méně než 4 soubory s nejčastějším rozšířením v adresáři, to předpokládá, že nejsou datové soubory a jen přeskočí adresář.
• Pokud jsou 4 nebo více souborů v adresáři, ale to nemůže úspěšně generovat část datasets.xml pro soubory (například nepodporovaný typ souboru) , to bude generovat EDDTableFromFileNames Databáze souborů.
• Na konci diagnostiky, že to píše do logu souboru, těsně před datasets.xml Tohle vytiskne tabulku se shrnutím informací shromážděných přes všechny podadresáře. Tabulka vyjme všechny podadresáře a uvede nejčastější typ přípony souboru, celkový počet souborů a jaký typ souboru byl vytvořen pro tyto soubory (pokud existuje) . Pokud čelíte složité, hluboce vnořené struktuře souborů, zvažte spuštění GenerateDatasets Xml s EDDType=EDDsFromFromFoles jen pro generování těchto informací,
• Tato volba nemusí dělat velkou práci odhadovat nejlepší EDDType pro danou skupinu datových souborů, ale je to rychlé, snadné a stojí za pokus. Pokud jsou zdrojové soubory vhodné, funguje dobře a je dobrým prvním krokem při generování datasets.xml pro souborový systém se spoustou podadresářů, každý s datovými soubory z různých souborů dat.  

EDDTableFromEML a EDDTableFromEMLBatch

Tyto speciální EDDType generuje datasets.xml k vytvoření EDDTableFromAsciiFiles soubor údajů z každé tabulky popsané v Jazyk ekologických metadat XML soubor. Varianta "Batch" funguje na všech EML souborech v lokálním nebo vzdáleném adresáři. Prosím, podívejte se na oddělení dokumentace pro EDDTableFromEML .  

EDDTableFromInPort

Tento speciální EDDType generuje datasets.xml k vytvoření EDDTableFromAsciiFiles Soubor údajů z informací v inport- xml Složka. Pokud můžete získat přístup ke zdrojovému datovému souboru (inport-xml soubor by měl mít vodítka, kde ho najít) , můžete vytvořit pracovní soubor v ERDDAP .

Následující kroky nastíní, jak používat GenerateDatasets Xml s inport-xml souborem, aby se pracovní data v ERDDAP .

1. Jakmile máte přístup k inport-xml souboru (buď jako URL nebo lokální soubor) : spustit generováníDatasets Xml, zadejte EDDType=EDDTableFromInPort, zadejte inport-xml URL nebo celé jméno souboru, zadejte, kteréChild=0, a zadejte další požadované informace (pokud je známo) . (V tuto chvíli nemusíte mít zdrojový datový soubor nebo zadat jeho jméno.) Nastavení Child=0 říká GenerateDatasets Xml napsat informace pro všechny z<Informace o subjektu a atributu ><Účetní jednotka > je v inport-xml souboru (pokud existují) . Vytiskne také shrnutí informací o pozadí, včetně všech download-url uvedených v inport-xml souboru.
2. Podívej se na všechny ty informace. (včetně informací o pozadí, které generujíNastavení dat Xml otisky) a navštívit download-url (án) pro pokus o nalezení zdrojového datového souboru (án) . Jestli ho najdeš (Oni) , stáhnout (Oni) do adresáře, který je přístupný ERDDAP . (Pokud nemůžete najít žádné zdrojové datové soubory, není důvod pokračovat.)
3. Spustit generování Datové soubory Zase Xml. Pokud zdrojový datový soubor odpovídá jednomu ze souborů inport-xml<Informace o subjektu a atributu ><Účetní jednotka >, uveďte, které Child= které číslo Entity (např. 1, 2, 3, ...) . ERDDAP™ pokusí se spojit názvy sloupců v souboru zdrojových dat s názvy v informacích o subjektu a vyzve k přijetí/odmítnutí/opravení jakýchkoli nesrovnalostí. Nebo, pokud inport-xml soubor nemá žádné<Informace o subjektu a atributu ><Upřesněte, které dítě =0.
4. V části datasets.xml která byla vyrobena pomocí GenerateDatasets Xml, revidovat [globální< addAttributes >] (#Global-atributes) dle potřeby/žádoucí.
5. V části datasets.xml který byl vyroben GenerateDatasetsXml, přidat / obnovit [< dataVariable >] (# Dataproměnná) informace potřebné k popisu každé proměnné. Ujistěte se, že správně identifikujete každou proměnnou [< sourceName >] (#zdrojové jméno) (jak to vypadá ve zdroji) , [< destinationName >] (Název místa určení) (který má více omezení povolených znaků než sourceName ) , [<jednotky >] (#jednotky) (zvláště pokud je proměnné času nebo času kde jednotky musí stanovit formát) a [< missing\_value >] (#missing_value) ,
6. Když jste blízko dokončení, opakovaně používat DasDds nástroj, který rychle zjistí, zda je popis datového souboru platný a zda se soubor údajů objeví v ERDDAP™ jak si přeješ.  

Bylo by skvělé, kdyby skupiny používající InPort dokumentovaly své soubory dat. ERDDAP™ zpřístupnit skutečné údaje:

• ERDDAP™ je řešení, které lze použít právě teď, takže můžete splnit NOAA 's Přístup veřejnosti k výsledkům výzkumu (PARR) požadavky Právě teď, ne v nějakém neurčitém čase v budoucnosti.
• ERDDAP™ zpřístupní aktuální údaje uživatelům, nejen metadatům. (K čemu jsou metadata bez dat?)
• ERDDAP™ podporuje metadata (zejména jednotky proměnných) , na rozdíl od některých jiných softwaru datového serveru je zvažován. (K čemu jsou data bez metadat?) Používat software, který nepodporuje metadata, je zvát data k nepochopení a zneužití.
• ERDDAP™ je svobodný a open-source software, na rozdíl od některých jiných software je zvažován. Probíhající vývoj ERDDAP™ je již zaplaceno. Podpora ERDDAP™ uživatelé jsou zdarma.
• ERDDAP 's vzhled lze snadno přizpůsobit, aby odrážel a zvýraznit vaši skupinu (ne ERD nebo ERDDAP ) .
• ERDDAP™ nabízí konzistentní způsob přístupu ke všem datům.
• ERDDAP™ lze číst data z mnoha typů datových souborů a z relačních databází.
• ERDDAP™ může řešit velké soubory údajů, včetně souborů údajů, kde jsou zdrojová data v mnoha datových souborech.
• ERDDAP™ mohou psát data do mnoha typů datových souborů, na žádost uživatele, včetně vědeckých datových souborů typů, jako je netCDF, ESRI .csv, a ODV .txt .
• ERDDAP™ může vytvořit vlastní grafy a mapy podmnožin dat, na základě specifikace uživatele.
• ERDDAP™ mohou řešit nedatové soubory, jako jsou sbírky obrazů, video nebo audio souborů.
• ERDDAP™ byla instalována a použita při více než 60 institucí po celém světě .
• ERDDAP™ je uveden jako jeden z datových serverů doporučených pro použití v rámci NOAA v NOAA Procesní směrnice pro přístup k údajům , na rozdíl od některých jiných software je zvažován.
• ERDDAP™ je produktem NMFS / NOAA , takže použití uvnitř NMFS a NOAA by měla být pýchou pro NMFS a NOAA .

Prosím, dej mi to. ERDDAP™ Zkus to. Pokud potřebujete pomoc, vyšlete prosím zprávu do ERDDAP™ Skupina Google.  

addFillValueAttributes

Tato speciální volba EDDType není typ souboru dat. Jedná se o nástroj, který může přidat atributy \_FillValue do některých proměnných v některých souborech dat. Viz addFillValueAttributes .  

najítDuplicate Čas

Tato speciální volba EDDType není typ souboru dat. Místo toho to říká GenerateDatasets Xml prohledat sbírku mřížkovaných .nc (a související) soubory k nalezení a vytištění seznamu souborů s duplikovanými hodnotami času. Když se podívá na časové hodnoty, převede je z původních jednotek na "seconds since 1970-01-01" v případě, že různé soubory používají různé jednotky řetězce. Musíte poskytnout výchozí adresář (též se stopovacím lomítkem) , název souboru regulární výraz (např. .\*\ .nc ) , a název časové proměnné v souborech.  

ncdump

Tato speciální volba EDDType není typ souboru dat. Místo toho to říká GenerateDatasets Xml tisknout ncdump \-jako výtisk .nc , .nc ml nebo .hdf Složka. Ve skutečnosti používá netcdf-java NCdump , což je omezenější nástroj než C verze NCdump. Pokud použijete tuto volbu, GenerateDatasetsXml vás požádá, abyste využili jednu z možností: "-h" (hlavička) , "-c" (souřadnice varů) , "-vall" (výchozí) , "-v var1;var2," "-v var1 (0,0:10,0:20) ". To je užitečné, protože bez ncdump je těžké vědět, co je v .nc , .nc ml nebo .hdf soubor a tím, který EDDType byste měli zadat pro GenerateDatasets Xml. Pro .nc ml soubor, bude tisknout výstup ncdump pro výsledek .nc Změny souborů v ml použité na podklad .nc nebo .hdf Složka.  

DasDds

• DasDds je program příkazového řádku, který můžete použít poté, co jste vytvořili první pokus na XML pro nový datový soubor v datasets.xml . S DasDds můžete opakovaně testovat a vylepšovat XML. Když používáte program DasDds:

1. Na Windows, když poprvé spustíte DasDds, musíte upravit DasDds. bat soubor s textovým editorem změnit cestu k javě. exe soubor tak, aby Windows mohli najít Java .
2. DasDds vás žádá o datasetID pro datový soubor, na kterém pracujete.
3. DasDds se snaží vytvořit datový soubor s tímto datasetID .
   • DasDds vždy tiskne spoustu diagnostických zpráv. Pokud použijete "DasDds -verbose," DasDds vytiskne více diagnostických zpráv než obvykle.
   • Pro bezpečnost, DasDds vždy odstraní všechny cached data data data (soubory) pro datový soubor před pokusem o vytvoření datového souboru. Toto je ekvivalent nastavení Tvrdá vlajka Takže pro souhrnné soubory, možná budete chtít upravit souborNameRegex dočasně omezit počet souborů, které konstruktér najde.
   • Pokud datový soubor nenačte (z jakéhokoli důvodu) , DasDds se zastaví a ukáže vám chybovou zprávu pro první chybu, kterou najde. Nesnažte se uhodnout, v čem by mohl být problém. Přečtěte si zprávu ERROR pozorně.
     Pokud je to nutné, přečtěte si předchozí diagnostické zprávy a najděte další vodítka a informace.
   • Proveďte změnu XML souboru, abyste se pokusili vyřešit tento problém
     a nechat DasDds se pokusit vytvořit soubor znovu.
   • Pokud budete opakovaně řešit každý problém, nakonec vyřešíte všechny problémy
     a data se nabijí.
4. Všechny DasDds výstup (diagnostika a výsledky) jsou zapsány na obrazovce a na velkýRodič rodičů /logs/DasDds.log .
5. Pokud DasDds mohou vytvořit soubor dat, DasDds vám pak ukáže .das (Struktura datového souboru) , .dds (Dataset Descriptor Struktura) a .timeGaps (časové mezery) informace pro datový soubor na vaší obrazovce a zapsat na velkýRodič rodičů /logs/DasDds.out .
6. Často budete chtít provést nějakou malou změnu XML datového souboru, aby se vyčistila metadata datového souboru a znovu spustila DasDds.

Bonus Nástroj třetí strany: ERDDAP - Lint

ERDDAP -Lint je program od Roba Fullera a Adama Leadbettera z Irish Marine Institute, který můžete použít ke zlepšení metadat vašeho ERDDAP™ Data. ERDDAP -lint "obsahuje pravidla a jednoduchou statické webové aplikace pro provádění některých ověřovacích testů proti vašemu ERDDAP™ server. Všechny testy jsou spuštěny ve webovém prohlížeči." Jako Nástroj Unix/Linux lint, můžete upravit stávající pravidla nebo přidat nová pravidla. Viz ERDDAP - Lint pro více informací.

Tento nástroj je zvláště užitečný pro soubory dat, které jste vytvořili před nějakou dobou a nyní chcete aktualizovat s vašimi aktuálními preferencemi metadat. Například rané verze GenerateDatasets Xml se nesnažil vytvořit globální creator\_name , creator\_email , creator\_type nebo creator\_url metadata. Hodilo by se ti. ERDDAP -lt identifikovat soubory, které nemají atributy metadat.

Díky Rob a Adam za vytvoření tohoto nástroje a zpřístupnění ERDDAP™ komunita.  

Základní struktura datasets.xml Soubor

Požadované a volitelné značky povolené v datasets.xml soubor (a počet případů, kdy se mohou objevit) jsou uvedeny níže. V praxi, vaše datasets.xml bude mít hodně<Štítky datového souboru> a používat pouze ostatní značky uvnitř<erddapDatasets> podle potřeby.

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

   <standardLicense>...</standardLicense> <!-- 0 or 1 -->
   <standardContact>...</standardContact> <!-- 0 or 1 -->
   <standardDataLicenses>...</standardDataLicenses> <!-- 0 or 1 -->
   <standardDisclaimerOfEndorsement>...</standardDisclaimerOfEndorsement> <!-- 0 or 1 -->
   <standardDisclaimerOfExternalLinks>...</standardDisclaimerOfExternalLinks> <!-- 0 or 1 -->
   <standardGeneralDisclaimer>...</standardGeneralDisclaimer> <!-- 0 or 1 -->
   <standardPrivacyPolicy>...</standardPrivacyPolicy> <!-- 0 or 1 -->
   <startHeadHtml5>...</startHeadHtml5> <!-- 0 or 1 -->
   <startBodyHtml5>...</startBodyHtml5> <!-- 0 or 1 -->
   <theShortDescriptionHtml>...</theShortDescriptionHtml> <!-- 0 or 1 -->
   <endBodyHtml5>...</endBodyHtml5> <!-- 0 or 1 -->

   <user username="..." password="..." roles="..." /> <!-- 0 or more -->

   <dataset>...</dataset> <!-- 1 or more -->
 </erddapDatasets>

Je možné, že v budoucnu budou povolena jiná kódování, ale prozatím se doporučuje pouze ISO-8859-1.  

XInclude

Novinka ve verzi 2.25 je podpora pro XInclude. To vyžaduje použití parseru SAX<UseSaxParser > true</useSaxParser > ve vašem nastavení.xml. To vám umožní zapsat každý soubor do vlastního souboru a pak je všechny zahrnout do hlavního souboru datasets.xml , opakované části definic datového souboru nebo obojí. Pokud chcete vidět příklad, EDDTestDataset.java stanoví XInclude pro opětovné použití proměnných definic.  

---

Poznámky

Práce s datasets.xml Soubor je netriviální projekt. Přečtěte si prosím pozorně všechny tyto poznámky. Až si vybereš Typ souboru , pečlivě si přečtěte podrobný popis.  

Výběr typu datové sady

Ve většině případů je jen jeden ERDDAP™ Typ datového souboru, který je vhodný pro daný zdroj dat. V několika případech (např. .nc soubory) , Existuje několik možností, ale obvykle jedna z nich je určitě nejlepší. První a největší rozhodnutí, které musíte udělat, je: je vhodné považovat soubor dat za skupinu multidimenzionálních polí (Pokud ano, uvidíte EDDGrid Typy souborů údajů ) nebo jako databázová tabulka údajů (Pokud ano, uvidíte Typy datového souboru EDDTable ) .  

Sloužit údaje, jak je

Obvykle není třeba měnit zdroj dat (např. převést soubory na jiný typ souboru) takže ERDDAP™ může sloužit. Jeden z předpokladů ERDDAP™ je, že zdroj dat bude použit tak, jak je. Obvykle to funguje dobře. Některé výjimky jsou:

• Související databáze a Cassandra -- ERDDAP™ mohou sloužit data přímo z relačních databází a Cassandra. Ale pro bezpečnost, vyvážení zatížení a problémy s výkonem se můžete rozhodnout vytvořit jinou databázi se stejnými údaji nebo uložit data do NetCDF v3 .nc Soubory a mít ERDDAP™ slouží data z nového zdroje dat. Viz EDDtableFromDatabase a EDDTableFromCassandra .
• Nepodporované zdroje dat -- ERDDAP™ může podporovat velký počet typů datových zdrojů, ale svět je naplněn 1000's (Milióny?) různých zdrojů údajů (zejména struktury datových souborů) . Pokud ERDDAP™ nepodporuje váš zdroj dat:
  • Pokud je zdroj dat NetCDF .nc soubory, můžete použít NcML upravit soubory údajů při letu nebo použít NCO trvale upravovat datové soubory.
  • Data můžete zapisovat do datového zdroje, který ERDDAP™ Podpora. NetCDF - 3 .nc soubory jsou dobré, obecné doporučení, protože jsou binární soubory, které ERDDAP™ umí číst velmi rychle. Pokud jde o tabulková data, zvažte uložení údajů do souboru .nc Soubory, které používají CF Geometrie diskrétního odběru vzorků (DSG) Kontiguous Ragged Array datové struktury a tak lze zacházet s ERDDAP 's EDDTableFromNcCFFiles ). Pokud jsou logicky organizovaní (každý s údaji pro kus prostoru a času) , ERDDAP™ může z nich velmi rychle extrahovat data.
  • Můžete požádat, aby podpora pro tento zdroj dat byla přidána do ERDDAP™ e-mailem Chrisovi. John v Noaa.gov.
  • Můžete přidat podporu pro tento zdroj dat tím, že zapíšete kód, aby se o něj postaral sám. Viz vá ERDDAP™ Průvodce programátorem
• Rychlost... ERDDAP™ může číst data z některých zdrojů dat mnohem rychleji než ostatní. Například čtení NetCDF v3 .nc Soubory jsou rychlé a čtení ASCII souborů je pomalejší. A pokud je velký (> 1000) nebo obrovský (> 10 000) počet zdrojových datových souborů, ERDDAP™ bude reagovat na některé požadavky na údaje pomalu. Obvykle není rozdíl pro lidi patrný. Nicméně, pokud si myslíte, ERDDAP™ je pomalý pro daný datový soubor, můžete se rozhodnout vyřešit problém zápisem dat do efektivnější nastavení (obvykle: několik, dobře strukturovaných, NetCDF v3 .nc soubory) . Pro tabulková data viz Tato rada .  

Nápověda

Často je snazší vytvořit XML pro datový soubor tak, že vytvoří kopii pracovního popisu datového souboru v datovém souboru.xml a poté jej upraví.

Kódování zvláštních znaků

Od datasets.xml je XML soubor, musíte & Kód "&,"<"a ">" v jakémkoli obsahu jako "&," "<"a ">." Špatně:<Název > Čas a osy</title > Správně:<Název > Čas a tides</title >  

XML netoleruje chyby syntaxe

Poté, co editujete soubor datate.xml, je dobrý nápad ověřit, že výsledek je dobře tvarované XML vložením XML textu do XML checkeru jako xmlvalidace .  

Tipy proti potížím

• Jiné způsoby, jak diagnostikovat problémy s daty
  Kromě dvou hlavních Nástroje ,
• log.txt je log soubor se všemi ERDDAP Diagnostické zprávy.
• The Denní zpráva má více informací než stránka stavu, včetně seznamu souborů údajů, které nebyly načteny, a výjimky (chyby) vygenerovali.
• The Stavová stránka je rychlý způsob, jak zkontrolovat ERDDAP 's statusem každého webového prohlížeče. Obsahuje seznam souborů, které nebyly načteny (i když ne související výjimky) a za úkolŠíření statistik (ukazující pokrok EDDGrid Kopírovat a EDDtableCopy Soubory údajů a všechny EDDGrid FromFiles nebo EDDTableFromFoles Soubory údajů, které používají cacheFromUrl (ale ne cache VelikostGB) ) .
• Když se zasekneš, uvidíš naše oddíl o získání dodatečné podpory .  

Zvláštní proměnné

• ** Zeměpisná délka, zeměpisná šířka, výška, hloubka, tlak a čas (LLAT) proměnná destinationName Jsou zvláštní.**
• Obecně:
  • LLAT proměnné jsou uvedeny na ERDDAP™ pokud proměnná osy je (místo EDDGrid Soubory údajů) nebo datové proměnné (pro soubory EDDTable) destinationName je "délka," "zeměpisná šířka," "nadmořská výška," "hloubka," nebo "time" .
  • Důrazně vás vybízíme, abyste pro tyto proměnné používali tyto standardní názvy, kdykoli je to možné. Žádný z nich není nutný. Pokud nepoužijete tyto speciální názvy proměnných, ERDDAP™ nepozná jejich význam. Například proměnné LLAT jsou zpracovávány speciálně pomocí Make A Graph ( * datasetID * .graph) : Pokud je proměnná X Axis "délka" a proměnná Y Axis je "zeměpisná šířka," dostanete mapu (pomocí standardní projekce a s pozemní maskou, politickými hranicemi atd.) místo grafu.
  • ERDDAP™ automaticky přidá spoustu metadat k LLAT proměnných (Například, " ioos\_category "," jednotky "a několik atributů souvisejících s normami, jako je "\_CoordinaceAxisType") .
  • ERDDAP™ automaticky, on-the-fly, přidá spoustu globálních metadat souvisejících s hodnotami LLAT vybrané podmnožiny dat (například "geospatial\_lon\_min") .
  • Klienti, kteří podporují tyto standardy metadat, budou moci využít přidané metadata k umístění dat v čase a prostoru.
  • Pro klienty bude snazší vytvářet dotazy, které zahrnují proměnné LLAT, protože názvy proměnné jsou ve všech příslušných souborech stejné.
• Pro proměnnou "délka" a proměnnou "zeměpisná šířka":
  • Použijte destinationName s "délka" a "zeměpisná šířka" pouze pokud jednotky jsou stupně\_východ a stupně\_north, resp. Pokud vaše údaje neodpovídají těmto požadavkům, použijte různé názvy proměnných (například x, y, lonRadians, latRadians) .
  • Pokud máte údaje o délce a zeměpisné šířce vyjádřené v různých jednotkách, a tedy s různými destinationName s, například, lonRadians a latRadians, Make A Graph ( * datasetID * .graph) vytvoří grafy (například časové řady) místo map.
• Pro "nadmořskou výšku," "presure" nebo "hloubkovou" proměnnou:
  • Použijte destinationName "nadmořská výška" pro identifikaci vzdálenosti dat nad hladinou moře (pozitivní hodnoty="up") . Volitelně můžete použít "nadmořskou výšku" pro vzdálenosti pod hladinou moře, pokud jsou hodnoty pod mořem záporné (nebo pokud například použijete, [<att name=" scale\_factor "type="int" - 1</att>] (#scale_factor) převést hodnoty hloubky na hodnoty nadmořské výšky.
  • Použijte destinationName "hloubka" pro identifikaci vzdálenosti dat pod hladinou moře (pozitivní hodnoty="down") .
  • Alternativně, pro zvýšení definované úrovně tlaku vzduchu (např. isobary ) , měli byste nastavit destinationName na "tlak." To podporuje jednotky v "hPa," "Pa" a "mbar" (pozitivní hodnoty="down") .
  • Soubor údajů může mít pouze jednu "nadmořskou výšku," "tlak" nebo "hloubkovou" proměnnou.
  • Pro tyto "nadmořská výška" a "hloubkové" proměnné jednotky musí být "m," "meter" nebo "metry." Pokud se jednotky liší (například sáhy) , můžete použít [<att name=" scale\_factor "> některé Hodnota </att>] (#scale_factor) a [<att name="jednotky"</att>] (#jednotky) převést jednotky na metry.
  • Pokud vaše údaje neodpovídají těmto požadavkům, použijte jiný destinationName (například nadGround, vzdálenost ToBottom) .
  • Pokud znáte vertikální CRS, zadejte jej v metadatech, např. "EPSG:5829" (okamžitá výška nad hladinou moře) , "EPSG:5831" (okamžitá hloubka pod hladinou moře) , nebo "EPSG:5703" (NAVD88 výška) .
• Pro "time" proměnná:
  • Použijte destinationName "time" pouze pro proměnné, které zahrnují celé datum+čas (nebo datum, pokud je to vše, co existuje) . Pokud například existují samostatné sloupce pro datum a časOfDay, nepoužívejte název proměnné "time" .
  • Viz jednotky pro více informací o atributu jednotek pro proměnné času a časuStamp.
  • Časová proměnná a související čas Proměnné známky jsou jedinečné v tom, že vždy převést hodnoty dat z časového formátu zdroje (Ať je to cokoliv.) do číselné hodnoty (sekundy od 1970-01-01T00:00:00Z) nebo hodnota řetězce (ISO 8601:2004 (E) formát) V závislosti na situaci.
  • Pokud uživatel požaduje údaje o čase, může o ně požádat zadáním času jako číselné hodnoty (sekundy od 1970-01-01T00:00:00Z) nebo hodnota řetězce (ISO 8601:2004 (E) formát) .
  • ERDDAP™ má nástroj pro Převést numerické Čas do/z doby řetězce .
  • Viz Jak ERDDAP Obchoduje s časem .

Proč jen dvě základní datové struktury?

• Vzhledem k tomu, že je obtížné pro lidské klienty a počítačové klienty řešit komplexní soubor možných datových struktur, ERDDAP™ používá pouze dvě základní datové struktury:
  • a struktura roštových dat (například pro satelitní data a modelová data) a
  • a struktura tabulkových dat (například pro in-situ bóje, stanice a data trajektorie) .
• Určitě ne všechny údaje mohou být vyjádřeny v těchto strukturách, ale většina z nich může. Zejména tabulky jsou velmi flexibilní datové struktury (Podívejte se na úspěch relačních databázových programů) .
• Tím se datové dotazy snadněji konstruují.
• Díky tomu mají datové odpovědi jednoduchou strukturu, díky které je jednodušší data sloužit v širší škále standardních typů souborů. (které často jen podporují jednoduché datové struktury) . To je hlavní důvod, proč jsme to naplánovali. ERDDAP™ Tudy.
• Tohle nám to velmi usnadňuje. (nebo kdokoliv) psát klientský software, který pracuje se všemi ERDDAP™ Data.
• To usnadňuje srovnání dat z různých zdrojů.
• Jsme si velmi vědomi toho, že pokud jste zvyklí pracovat s daty v jiných datových strukturách, můžete si zpočátku myslet, že tento přístup je zjednodušující nebo nedostatečný. Ale všechny datové struktury mají kompromisy. Žádný není dokonalý. Dokonce i do-it-všechny struktury mají své nevýhody: práce s nimi je složitá a soubory lze psát nebo číst pouze se speciálními softwarovými knihovnami. Pokud přijmete ERDDAP 's přístupem dost na to, aby se s ním pokusil pracovat, můžete zjistit, že má své výhody (zejména podpora pro více typů souborů, které mohou držet odpovědi na údaje) . The ERDDAP™ slide show (zvláště skluzavka datových struktur ) Hodně o těchto otázkách mluví.
• A i kdyby vám to připadalo divné, ERDDAP™ klienti si toho nikdy nevšimnou - prostě uvidí, že všechny datové soubory mají pěknou jednoduchou strukturu a budou vděční, že mohou získat data z široké škály zdrojů vrácených v široké škále formátů souborů.  

Rozměry

• Co když proměnné mřížky ve zdrojovém souboru NESdílejí stejné proměnné osy?
  In EDDGrid Soubory údajů, všechny datové proměnné MUSÍ používat (podíl) všechny proměnné osy. Takže pokud zdrojový soubor má některé proměnné s jednou sadou rozměrů, a další proměnné s jinou sadou rozměrů, budete muset udělat dva soubory souborů v ERDDAP . Například, můžete udělat jeden ERDDAP™ Soubor s názvem "Nějaká hlava (na povrchu) " držet proměnné, které používají \[ čas \] \[ zeměpisná šířka \] \[ zeměpisná délka \] rozměry a další ERDDAP™ Soubor s názvem "Nějaká hlava (v hloubkách) " držet proměnné, které používají \[ čas \] \[ výška \] \[ zeměpisná šířka \] \[ zeměpisná délka \] . Nebo můžete změnit zdroj dat a přidat rozměr s jedinou hodnotou. (například nadmořská výška=0) aby proměnné byly konzistentní.

  ERDDAP™ nezvládá složitější soubory dat (například modely, které používají síť trojúhelníků) Dobře. Můžete sloužit tyto soubory v ERDDAP™ vytvořením dvou nebo více souborů údajů v ERDDAP™ (tak, aby všechny datové proměnné v každém novém datovém souboru sdílely stejnou sadu osových proměnných) Ale tohle uživatelé nechtějí. U některých souborů údajů můžete zvážit vytvoření pravidelné roštové verze datového souboru a nabídnout ji kromě původních údajů. Nějaký klientský software se může zabývat pouze pravidelnou sítí, takže tím získáte další klienty.  

Promítnutá data

Některá data mají komplexní strukturu. Například satelitní úroveň 2 ("Dlouhá trať") data nepoužívají jednoduchou projekci. Modelky (a další) často pracují s daty o různých necyklických projekcích (například kuželovité, polární stereografické, tripolární) nebo v nestrukturovaných sítích (komplexnější strukturu dat) . Někteří koncoví uživatelé chtějí tato data tak, jak jsou, takže nedochází ke ztrátě informací. Pro tyto klienty, ERDDAP™ mohou sloužit data, jak je, pouze pokud ERDDAP™ správce rozdělí původní datový soubor na několik souborů údajů, přičemž každá část obsahuje proměnné, které sdílejí stejné proměnné osy. Ano, je to zvláštní pro lidi, kteří jsou do toho zapleteni a je to jiné než většina OPeNDAP servery. Ale... ERDDAP™ zdůrazňuje zpřístupnění údajů v mnoha formátech. To je možné, protože ERDDAP™ použití/vyžaduje jednotnější strukturu údajů. I když je to trochu trapné. (tj. jiné, než se očekávalo) , ERDDAP™ může distribuovat promítaná data.

\[ Ano. ERDDAP™ mohou mít uvolněnější požadavky na strukturu dat, ale zachovat požadavky na výstupní formáty. Ale to by vedlo k záměně mezi mnoha uživateli, zejména nováčky, protože mnoho zdánlivě platných žádostí o data s různými strukturami by bylo neplatné, protože data by do typu souboru nezapadala. Stále se vracíme k návrhu současného systému. \]

Někteří koncoví uživatelé chtějí data v lat lon válcové projekce, jako je Equirectangulární / deska carrée nebo Mercator) pro snadné použití v různých situacích. V těchto situacích podporujeme ERDDAP™ správce používat jiný software ( NCO ? Matlab ? R? IDV? ...?) re-projektovat údaje na geograficky (Equirektangulární projekce / deska carrée) nebo jiné válcové projekce a slouží této formě dat v ERDDAP™ jako jiný datový soubor. To je podobné tomu, co lidé dělají, když převádějí satelitní data úrovně 2 na data úrovně 3. Jeden takový nástroj je NCO která nabízí možnosti rozšíření pro regriding dat.

GIS a reprojektování dat

Vzhledem k tomu, že je svět GIS často orientován na mapu, programy GIS obvykle nabízejí podporu pro přeprojektování dat, tj. propracovávání dat na mapě s jinou projekcí.

V současné době, ERDDAP™ nemá nástroje pro přepracovávání údajů. Místo toho doporučujeme použít externí nástroj k vytvoření varianty datového souboru, kde byly údaje přeprojektovány z původního formuláře do obdélníku (zeměpisná délka) pole vhodné pro ERDDAP .

Podle našeho názoru CF/ DAP svět je trochu jiný než svět GIS a pracuje na mírně nižší úrovni. ERDDAP™ to odráží. Obecně, ERDDAP™ je určen především pro práci s daty (ne mapy) a nechce se změnit (např. reprojekt) ta data. Pro ERDDAP™ , roštovaná data jsou často/obvykle/nejlépe spojena s hodnotami lat lon a válcovou projekcí, a ne s hodnotami x,y. V každém případě, ERDDAP™ nedělá nic s projekcí dat, jen předává data, jak je to s jeho aktuální projekcí, o teorii, že reprojekce je významnou změnou dat a ERDDAP™ nechce být zapojen do významných změn. Následní uživatelé by také mohli naivně data znovu promítat, což by nebylo tak dobré, jako jen provést jednu rekonstrukci. (Takže, pokud ERDDAP™ Správce chce data nabídnout v jiné projekci, v pořádku; jen reprojektovat data offline a nabídnout, že jako jiný datový soubor v ERDDAP . Spousta satelitních dat je nabízena jako to, co NASA nazývá Level 2 (swath) a jako úroveň 3 (Ekvirektální projekce) verze.) Kdy? ERDDAP™ dělá mapy (přímo nebo prostřednictvím WMS nebo KML) , ERDDAP™ v současné době nabízí pouze mapy s projekcí Equirektangular / deska carrée, která je naštěstí přijata většina mapovacích programů.

Podporujeme ERDDAP™ Správci používají jiný software ( NCO ? Matlab ? R? IDV? ...?) re-projektovat údaje na geograficky (Equirektangulární projekce / deska carrée) nebo jiné válcové projekce a slouží této formě dat v ERDDAP™ jako jiný datový soubor. To je podobné tomu, co lidé dělají, když převádějí satelitní data úrovně 2 na data úrovně 3. Jeden takový nástroj je NCO která nabízí možnosti rozšíření pro regriding dat.

Doufáme, že ERDDAP™ budou mít v budoucnu vestavěné nástroje pro nabízení map s dalšími projekcemi. Také doufáme, že budeme mít v budoucnu lepší spojení se světem GIS (jiný než proud WMS služba) . Je hrozné, že v tomto "moderním" světě jsou vazby mezi CF/ DAP Svět a svět GIS jsou stále tak slabé. Obě ty věci jsou na seznamu To Do. (Chcete-li pomoci, zejména s připojením ERDDAP™ Na MapServer, prosím e-mail Chris. John at noaa.gov .)

Typy údajů

ERDDAP™ podporuje následující datové typy (názvy jsou případově citlivé; 'u' prefix znamená "nepodepsaný"; číslo mnoha jmen v jiných systémech je počet bitů) :

byte

• byte podepsal celé hodnoty s rozsahem -128 až 127. V jiných systémech se tomu někdy říká int8. Tomuhle se říká "tinyint" od SQL a Cassandry. ERDDAP™ převody boolean z některých zdrojů (např. SQL a Cassandra) do bajtů v ERDDAP™ s hodnotou 0=false, 1=true a 127= missing\_value .

ubyte

• ubyte má nesignované celé hodnoty s rozsahem 0 až 255. V jiných systémech se tomu někdy říká uint8.

krátké

• krátké podepsal celé hodnoty s rozsahem -32768 až 32767. V jiných systémech se tomu někdy říká int16. Tomu se říká "malý" od SQL a Cassandry.

krátké

• krátké má nesignované celé hodnoty s rozsahem 0 až 65535. V jiných systémech se tomu někdy říká uint16.

int

• int podepsal celé hodnoty s rozsahem -2147483648 až 2147483647. V jiných systémech se tomu někdy říká int32. Tomuhle se říká "integer" | číselný (?) " by SQL and "int" by Cassandra.

uint

• uint má nesignované celočíselné hodnoty s rozsahem 0 až 4294967295. V jiných systémech se tomu někdy říká uint32.

dlouhé

• dlouhé podepsal celé hodnoty s rozsahem -9223372036854775808 až 922337236854775807. V jiných systémech se tomu někdy říká int64. Tomuhle se říká "velký | číselný (?) " od SQL a "velký" od Cassandry. Protože mnoho typů souborů nepodporuje dlouhá data, jejich použití je deprimováno. Pokud je to možné, použijte místo toho dvojité (viz níže) .

ulong

• ulong má nesignované celočíselné hodnoty v rozsahu 0 až 18446740737095516115 V jiných systémech se tomu někdy říká uint64. Protože mnoho typů souborů nepodporuje ulong data, jejich použití je deprimováno. Pokud je to možné, použijte místo toho dvojité (viz níže) .

plavat

• plavat je plovák IEEE 754 s rozsahem přibližně +/- 3.402823466e+38. V jiných systémech se tomu někdy říká plovák 32. Tomuhle se říká "skutečná | plavat (?) | desetinné číslo (?) | číselný (?) " by SQL and "float" by Cassandra. Zvláštní hodnota NaN znamená Not-a-Number. ERDDAP™ převádí kladné a záporné hodnoty nekonečna na NaN.

dvakrát

• dvakrát je dvoulůžkový IEEE 754 s rozsahem přibližně +/- 1,7976931348623157E+308. V jiných systémech se tomu někdy říká plovák64. Tomu se říká "dvojitá přesnost." | plavat (?) | desetinné číslo (?) | číselný (?) " by SQL and "double" by Cassandra. Zvláštní hodnota NaN znamená Not-a-Number. ERDDAP™ převádí kladné a záporné hodnoty nekonečna na NaN.

char

• char je jeden, 2- bajt (16-bit) Unicode UCS-2 znak od \u0000 (# 0) přes \uffff (#65535) . \uffff 'je definice není-a-charakter, analogická dvojité hodnotě NaN. Použití znaku je deprimováno, protože mnoho typů souborů buď nepodporuje chary nebo pouze podporuje 1-bajtové chary (viz níže) . Zvažte místo toho použití Stringu. Uživatelé mohou použít znakové proměnné k vytváření grafů. ERDDAP™ převést znaky na jejich kódové číslo Unicode, které lze použít jako numerická data.

String

• String je sekvence 0 nebo více, 2-bajt (16-bit) Unicode UCS-2 znaky . ERDDAP™ používá/vykládá řetězec o délce 0 jako chybějící hodnotu. ERDDAP™ nepodporuje skutečný nulový řetězec. Teoretická maximální délka řetězce je 2147483647 znaků, ale tam jsou pravděpodobně různé problémy na různých místech i s poněkud kratší Struny. Použití ERDDAP 's String for SQL's character, varchar, character change, binary, varbinary, interval, pole, multiset, xml, and any other database data type that doesn't fit cleanly with any other ERDDAP™ datový typ. Použití ERDDAP 's String for Cassandra's "text" and any other Cassandra data type that doesn't cleanly fit with any other ERDDAP™ datový typ.  

Před ERDDAP™ v2.10, ERDDAP™ nepodporula nepodepsané integer typy interně a nabídla omezenou podporu u svých čtenářů a spisovatelů dat.

Omezení typu údajů

Napadá tě ERDDAP™ jako systém, který má virtuální datové soubory a který pracuje čtením dat ze zdroje datového souboru do interního datového modelu a zápisem dat do různých služeb (např.(OPeN)DAP, WMS ) a typy souborů v reakci na požadavky uživatelů.

• Každý vstupní čtečka podporuje podmnožinu datových typů, které ERDDAP™ Podpora. Takže čtení dat do ERDDAP Vnitřní datové struktury nejsou problém.
• Každý autor výstupu také podporuje podmnožinu datových typů. To je problém, protože ERDDAP musí například zmáčknout dlouhá data do souborů, které nepodporují dlouhá data.  

Níže jsou uvedena vysvětlení omezení (nebo žádný) různých autorů výstupů a jak ERDDAP™ řeší problémy. Tyto komplikace jsou nedílnou součástí ERDDAP 'je cílem učinit rozdílné systémy interoperabilní.

ASCII

• ASCII (.csv, .tsv , atd.) textové soubory -
  • Všechna numerická data jsou zapsána prostřednictvím svého reprezentace String (s chybějícími datovými hodnotami zobrazenými jako řetězce s délkou 0) .
  • I když ERDDAP™ píše dlouhé a ulong hodnoty správně do ASCII textových souborů, mnoho čtenářů (např. tabulkové programy) nemůže správně řešit dlouhé a ulong hodnoty a místo toho je převést na dvojnásobek hodnot (se ztrátou přesnosti v některých případech) .
  • Char a String data jsou psána přes JSON Strings, které řídí všechny znaky Unicode (zejména "neobvyklé" znaky za ASCII #127, např. znak Euro se jeví jako "\u20ac") .

JSON

• JSON ( .json , .jsonlCSV , atd.) textové soubory -
  • Všechna numerická data se zapisují prostřednictvím reprezentace String.
  • Char a String data jsou zapsána jako JSON Strings, které řídí všechny znaky Unicode (zejména "neobvyklé" znaky za ASCII #127, např. znak Euro se jeví jako "\u20ac") .
  • Chybějící hodnoty pro všechny numerické datové typy se jeví jako nulové.  

.nc 3 soubory

• .nc 3 soubory nativní podporu žádné nepodepsané integer datové typy. Před CF v1.9, CF nepodporuje nepodepsané integer typy. Abych se s tím vyrovnal, ERDDAP™ 2.10+ následuje standard NUG a vždy přidá atribut "\_Unsigned" s hodnotou "true" nebo "false" k označení, zda jsou data z nepodepsané nebo podepsané proměnné. Všechny celočíselné atributy jsou zapsány jako podepsané atributy (např. byte) s podepsanými hodnotami (např. ubyte actual\_range atribut s hodnotami 0 až 255, se zobrazí jako atribut byte s hodnotami 0 až -1 (překročení hodnoty komplementu obou hodnot mimo rozsah). Neexistuje žádný jednoduchý způsob, jak zjistit, které (podepsané) celočíselné atributy by se měly číst jako nepodepsané atributy. ERDDAP™ podporuje atribut "\_Unsigned" při čtení .nc 3 složky.
• .nc 3 soubory nepodporuje dlouhé nebo dlouhé datové typy. ERDDAP™ se s tím vypořádá tím, že je dočasně převede do dvou proměnných. Dvojnásobek může přesně reprezentovat všechny hodnoty do +/- 9,007,199,254,740,992 Což je 2^53. To je nedokonalé řešení. Unidata odmítá provést menší upgrade na .nc 3 řešit tyto a související problémy, citace .nc 4 (velká změna) jako řešení.
• Specifikace CF (před v1. 9) řekl, že podporuje znak datový typ, ale to není jasné, pokud znak je určen pouze jako stavební bloky char pole, které jsou efektivně Struny. Otázky na jejich mailing list přinesl pouze matoucí odpovědi. Vzhledem k těmto komplikacím, je nejlepší vyhnout se Char proměnné v ERDDAP™ a pokud možno použít String proměnné.
• Tradičně .nc 3 soubory pouze podporované řetězce s ASCII-kódován (7-bit, #0 - #127) Postavy. NUG (a ERDDAP ) rozšířit, že (začínající ~2017) vložením atributu "\_Encoding" s hodnotou "ISO-8859-1" (rozšíření ASCII, které definuje všech 256 hodnot každého 8-bitového znaku) nebo "UTF-8" k označení toho, jak jsou zakódována String data. Jiné kódování může být legální, ale jsou odrazeni.  

.nc 4 soubory

• .nc 4 soubory podporují všechny ERDDAP 's datovými typy.

NCCSV soubory

NCCSV 1.0 soubory nepodporuje žádné nepodepsané celočíselné datové typy. NCCSV 1.1+ soubory podporovat všechny nepodepsané integer datové typy.  

DAP

• (OPeN)DAP (.das, .dds, .asc ASCII soubory, a .dods binární soubory) -
  • (OPeN)DAPmá krátké, krátké, int, uint, float a dvojité hodnoty správně.
  • (OPeN)DAPmá "byte" datový typ, který definuje jako nepodepsaný, zatímco historicky THREDDS a ERDDAP™ zacházeli s "byte" jako s podepsanými v jejich(OPeN)DAPslužby. Abych se s tím vyrovnal lépe, ERDDAP™ 2,10+ se řídí normou NUG a vždy přidává atribut "\_Unsigned" s hodnotou "true" nebo "false" k označení, zda data jsou co ERDDAP™ volá byte nebo ubyte. Všechny atributy byte a ubyte jsou zapsány jako atributy "byte" s podepsanými hodnotami (např. ubyte actual\_range atribut s hodnotami 0 až 255, se zobrazí jako atribut byte s hodnotami 0 až -1 (překročení hodnoty komplementu obou hodnot mimo rozsah). Neexistuje jednoduchý způsob, jak zjistit, které atributy "byte" by se měly číst jako atributy ubyte.
  • (OPeN)DAPnepodporuje podepsané nebo nepodepsané longy. ERDDAP™ se s tím vypořádá tím, že je dočasně převede do dvou proměnných a atributů. Dvojnásobek může přesně reprezentovat všechny hodnoty do 9,007,199,254,740,992 Což je 2^53. To je nedokonalé řešení. OPeNDAP (organizace) odmítá provést menší upgrade na DAP 2.0 řešit tyto a související problémy, citace DAP 4 (velká změna) jako řešení.
  • Protože(OPeN)DAPnemá samostatný znakový datový typ a technicky podporuje pouze 1-bayte ASCII znaky (#0 - #127) v řetězech se proměnné znakových dat zobrazí jako 1-znakové dlouhé řetězce v(OPeN)DAP.das, .dds, a .dods reakce.
  • Technicky vzato,(OPeN)DAPspecifikace podporuje pouze řetězce s ASCII kódovanými znaky (#0 - #127) . NUG (a ERDDAP ) rozšířit, že (začínající ~2017) vložením atributu "\_Encoding" s hodnotou "ISO-8859-1" (rozšíření ASCII, které definuje všech 256 hodnot každého 8-bitového znaku) nebo "UTF-8" k označení toho, jak jsou zakódována String data. Jiné kódování může být legální, ale jsou odrazeni.  

Poznámky typu údajů

• Vzhledem k tomu, že špatná podpora pro dlouhé, ulong, a char data v mnoha typech souborů, odrazujeme používání těchto datových typů v ERDDAP . Pokud je to možné, použijte dvojité místo dlouhé a ulong, a použijte String místo char.  
• Metadata - protože(OPeN)DAP's .das a .dds odpovědi nepodporuje dlouhé nebo dlouhé atributy nebo datové typy (a místo toho jim ukázat jako dvojité) , můžete místo toho použít ERDDAP 's tabulární reprezentace metadat, jak je vidět v http .../erddap/ Informace / * datasetID * .html webová stránka (například: https://coastwatch.pfeg.noaa.gov/erddap/info/cwwcNDBCMet/index.html ) (které můžete také získat v jiných typech souborů, např. .csv, .htmlTable , .itx , .json , .jsonlCSV1 , .jsonlCSV , .jsonlKVP , .mat , .nc , .nccsv , .tsv , .xhtml ) nebo .nccsv Odpověď na metadata (například: https://coastwatch.pfeg.noaa.gov/erddap/tabledap/cwwcNDBCMet.nccsvMetadata i když .nccsv Metadata jsou dostupná pouze pro tabulkové soubory dat) , obojí podporuje všechny datové typy (zejména dlouhé, ulong a char) .  

Soubory médií

Ne všechna data jsou pole čísel nebo textu. Některé soubory souborů se skládají z mediálních souborů, jako jsou obrazy, audio a video soubory. ERDDAP™ má některé speciální funkce, které uživatelům usnadní přístup k mediálním souborům. Je to dvoustupňový proces:  

1. Zpřístupněte každý soubor prostřednictvím vlastní URL prostřednictvím systému, který podporuje požadavky na rozsah byte. Nejjednodušší způsob, jak to udělat, je dát soubory do adresáře, který ERDDAP™ má přístup k. (Pokud jsou v kontejneru jako .zip soubor, rozbalte je, i když možná budete chtít nabídnout .zip soubor také uživatelům.) Tak udělej EDDTableFromFileNames Soubor dat pro zpřístupnění souborů prostřednictvím ERDDAP™ , zejména prostřednictvím ERDDAP 's "files" systém .

Všechny soubory přístupné prostřednictvím EDDTableFromFileNames a ERDDAP 's "files" podpora systému požadavky na rozsah byte . Normálně, když klient (Například prohlížeč) se žádost na URL, dostane celý soubor jako odpověď. Ale s žádostí o rozsah byte, žádost určuje rozsah bajtů ze souboru, a server vrací pouze tyto byty. To je zde důležité, protože audio a video přehrávače v prohlížečích fungují pouze v případě, že se k souboru lze dostat prostřednictvím požadavků na rozsah byte.

Nepovinné: Pokud máte více než jeden soubor souborů s přidruženými mediálními soubory, můžete vytvořit pouze jeden EDDTableFromFileNames, který má podsložka pro každou skupinu souborů. Výhodou je, že když chcete přidat nové soubory médií pro nový datový soubor, stačí vytvořit novou složku a vložit soubory do této složky. Složka a soubory budou automaticky přidány do souboru EDDTableFromFileNames.

2. Nepovinné: Pokud máte soubor dat, který obsahuje odkazy na soubory médií, přidejte jej do ERDDAP . Například, můžete mít soubor .csv s řadou pokaždé, když někdo viděl velrybu a sloupec, který obsahuje název souboru obrázku související s tímto pozorováním. Pokud název souboru obrázku je pouze název souboru, např., Img20141024T192403Z, ne úplný URL, pak musíte přidat souborAccessBase Url a/nebo souborAccessSuffix atributy metadat pro tento účel dataVariable který určuje základní URL a příponu pro tyto názvy souborů. Pokud jste soubory zpřístupnili prostřednictvím EDDTableFromFileNames, URL bude ve formě baseUrl /erddap/files/ * datasetID * / Například,

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

Pokud existuje .zip nebo jiný kontejnerový soubor se všemi mediálními soubory vztahujícími se k datové proměnné, doporučujeme, abyste tento soubor také zpřístupnit uživatelům (Viz krok 1 výše) a pak ji identifikovat pomocí souborAccessArchive Url atribut.

\[ Začínáme ERDDAP™ v1. 82 \] Pokud uděláte první krok výše (nebo oba kroky) , pak když uživatel zobrazit ERDDAP™ "files" systém pro tento datový soubor (nebo žádá o zobrazení podmnožiny datového souboru prostřednictvím .htmlTable žádost, pokud jste udělali druhý krok) , ERDDAP™ zobrazí '?' ikonu vlevo od názvu souboru. Pokud se uživatel vznáší nad ikonou, uvidí popup zobrazující obraz, nebo audio přehrávač, nebo video přehrávač. Prohlížeče podporují pouze omezený počet typů

• obrázek (obvykle .gif, .jpg, a .png) ,
• audio (obvykle .mp3, .ogg, a .wav) a
• video soubory (obvykle .mp4, .ogv, a . webm) .

Podpora se liší od různých verzí různých prohlížečů na různých operačních systémech. Takže pokud máte na výběr, který typ souboru nabídnout, dává smysl nabídnout tyto typy.

Nebo pokud uživatel klikne na název souboru zobrazený na ERDDAP™ webová stránka, jejich prohlížeč zobrazí obraz, audio nebo video soubor jako samostatné webové stránky. To je většinou užitečné vidět velmi velký obraz nebo video na celé obrazovce, místo v popup.

Práce se soubory AWS S3

Amazon Web Service (AWS) je prodejcem cloud computing služby. S3 je systém úložiště objektů nabízený AWS. Místo hierarchického systému adresářů a souborů tradičního souborového systému (jako pevný disk ve vašem počítači) , S3 nabízí jen "kakety," které drží "objekty" (Zavoláme jim. "files" ) .

Pro soubory ASCII (např. .csv) , ERDDAP™ může pracovat přímo se soubory v kbelících. Jediné, co musíte udělat, je upřesnit<souborDir> pro datový soubor, který používá specifický formát pro kbelík AWS, např.https://bucketName.s3.aws-region.amazonaws.com/subdirectory/. Nepoužívejte<cacheFromUrl> . Podrobnosti viz níže.

Ale pro binární soubory (např. .nc , .grib, .bufr a .hdf soubory) , musíte použít<cacheFromUrl> systém popsaný níže. ERDDAP , netcdf-java (která ERDDAP™ používá pro čtení dat z těchto souborů) , a další vědecký datový software jsou navrženy pro práci se soubory v tradičním souborovém systému, který nabízí úroveň bloku přístup ke souborům (který umožňuje čtení částí souboru) , ale pouze S3 nabízí Úroveň souboru (objekt) přístup ke souborům (což umožňuje pouze čtení celého souboru) . AWS nabízí alternativu k S3, Elastický blokový obchod (EBS) ), který podporuje přístup k souborům na úrovni bloku, ale je dražší než S3, takže se zřídka používá pro hromadné ukládání velkého množství datových souborů. (Takže když lidé říkají ukládání dat v cloudu (S3) je levné, je to obvykle jablka k pomerančům srovnání.)

Kýble S3

Obsah kýblu. Klíče. Objekty, oddělovače.
Technicky S3 kbelíky nejsou organizovány v hierarchické struktuře souborů jako souborový systém na počítači. Místo toho kbelíky obsahují pouze "objekty" (soubory) , každý z nich má "klíč" (jméno) . Příkladem klíče v tomto noaa-goes17 kbelíku je

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

Odpovídající URL pro tento objekt je

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 podporuje malou variaci v tom, jak je tato URL vytvořena, ale ERDDAP™ vyžaduje tento zvláštní formát:   https://bucketName.s3.region.amazonaws.com/key

Od ERDDAP V2.29 můžete nyní použít s3:// URI formát místo kbelík URL. Toto je formát používaný AWS s3 cli . s3:// kbelík Název / klíč

The region pro S3 URI lze určit jedním ze tří způsobů:

• The region v uživateli Tomcat ~/.aws/config profil
• The AWS_DEFAULT_REGION proměnná prostředí
• The aws.region Proměnná JVM (v setenv.sh pro Tomcat)

Je to běžná praxe, stejně jako u tohoto příkladu, aby jména klíčů vypadala jako hierarchická cesta plus název souboru, ale technicky nejsou. Protože je to běžné a užitečné, ERDDAP™ zachází s klíči / je, jako by se jedná o hierarchickou cestu plus název souboru, a tato dokumentace bude odkazovat na ně jako takové. Pokud klíče kbelíku nepoužívají / jsou (např., klíč jako ABI-Lib.2018.052.22.OR\_ABI-L1b-RadM2-M3C10\_G16\_s201805222475755), poté ERDDAP™ bude celý klíč považovat za dlouhý název souboru.

Soukromé vs veřejné kýble -- Správce kbelíku S3 může učinit kbelík a jeho obsah veřejným nebo soukromým. Pokud je veřejný, jakýkoli soubor v kbelíku může být stažen někým, kdo používá URL pro soubor. Amazon má Otevřít data program, který hostí veřejné datové soubory (včetně údajů od NOAA , NASA a USGS) Zdarma a neúčtuje nikomu stáhnout soubory z těchto kbelíků. Pokud je kbelík soukromý, soubory v kbelíku jsou přístupné pouze oprávněným uživatelům a AWS účtuje poplatek (obvykle platí majitel kbelíku) pro stahování souborů do počítače S3. ERDDAP™ může pracovat s daty ve veřejných i soukromých kbelících.

AWS oprávnění

Aby to tak bylo. ERDDAP™ můžete číst obsah soukromých kbelíků, potřebujete AWS pověřovací listiny a musíte uložit pověřovací soubor na standardní místo, takže ERDDAP™ může najít informace. Viz AWS SDK Java 2.x dokumentace: Nastavit výchozí akreditivy . (Možnost uložení hodnot jako Java parametry příkazového řádku v \[ tomcat \] /bin/setenv.sh může být dobrá volba.)

AWS /soubory/

• /soubory/ systém -- The ERDDAP™ /soubory/ systém umožňuje uživatelům stáhnout zdrojové soubory pro datový soubor. Doporučujeme zapnout všechny soubory souborů se zdrojovými soubory, protože mnoho uživatelů si chce stáhnout původní zdrojové soubory.
  • Pokud jsou soubory v soukromém kbelíku S3, bude žádost uživatele o stažení souboru řešena ERDDAP™ , který přečte data ze souboru a pak je předá uživateli, čímž zvýší zatížení vašeho souboru ERDDAP™ , pomocí příchozí a odchozí šířky pásma, a dělá vás (vá ERDDAP™ Správce) zaplatit poplatek za výstup dat AWS.
  • Pokud jsou soubory ve veřejném kbelíku S3, bude žádost uživatele o stažení souboru přesměrována na URL AWS S3 pro tento soubor, takže data neprojdou ERDDAP™ , tedy snížení zatížení na ERDDAP . A pokud jsou soubory v Amazon Open Data (volný) veřejný kbelík, pak vy (vá ERDDAP™ Správce) nebude muset AWS platit žádný poplatek za přenos dat. Proto je zde velká výhoda, která slouží datům veřejnosti. (ne soukromá) Kbelíky S3 a obrovská výhoda pro podávání dat z Amazon Open Data (volný) Kbelíky.

ERDDAP Také podporuje anonymní pověřovací listiny pro veřejné vědro. Chcete-li použít anonymní pověřovací listiny, přidat <useAwsAnonymous> pravda </useAwsAnonymous> na vaše nastavení.xml.

Vlastní S3 koncové body

Pro S3 kompatibilní úložiště objektů, které Amazon hostí, musíte nastavit endpoint_url spolu s určením vašeho kbelíku/klíče pomocí s3:// URI.

The endpoint_url lze určit jedním ze tří způsobů:

• The endpoint_url v uživateli Tomcat ~/.aws/config profil
• The AWS_ENDPOINT_URL proměnná prostředí
• The aws.endpoint Url Proměnná JVM (v setenv.sh pro Tomcat)

Pro úplný seznam konfiguračních proměnných S3, Viz dokument Amazon .

Vlastní podpisové certifikáty U samohostovaných kbelíků S3 budete mít často samopodepsané certifikáty SSL. Pro ERDDAP Chcete-li číst z těchto kbelíků, musíte přidat svůj řetězec certifikátů do JVM svěřenectví v $JAVA_HOME/jre/lib/security/cacerts . Navíc, ERDDAP používá AWS běžný běh přístup k vědru synchronně. To zvyšuje výkon, ale také vyžaduje, aby vaše auto-podepsané certifikáty se přidají do vašeho OS specifického truststore. Pokud se tomu chcete vyhnout, můžete vyřadit AWS CRT pomocí <useAwsCrt> false </useAwsCrt> ve vašem nastavení.xml.

ERDDAP™ a AWS S3 Kýble

** ERDDAP™ a AWS S3 Kýble**
Naštěstí, po velkém úsilí, ERDDAP™ má řadu funkcí, které jí umožňují řešit vlastní problémy při práci s blokovým přístupem S3 souborů rozumně účinným způsobem:

• \[ Prohlášení: Práce s kbelíky AWS S3 je spousta práce navíc. AWS je obrovský ekosystém služeb a funkcí. Je toho hodně k učení. Chce to čas a úsilí, ale je to možné. Buď trpělivý a všechno zařídíš. Hledej/pros o pomoc ( AWS dokumentace , webové stránky jako Přetok zásobníku , a pravidelné ERDDAP™ možnosti podpory Pokud se zasekneš. \]
   
• Může být těžké zjistit strukturu adresáře a jména souborů v kbelíku S3. ERDDAP™ má řešení pro tento problém: EDDTableFromFileNames má speciální \\\*fromOnTheFly možnost, která umožňuje vytvořit soubor EDDTableFromFileNames, který umožňuje uživatelům prohlížet obsah kbelíku S3 (a stahovat soubory) prostřednictvím datového souboru "files" Možnost. Existuje příklad níže .  
• ERDDAP™ může číst data z externí komprimované datové soubory , takže je v pořádku, pokud soubory na S3 jsou uloženy jako .gz , .gzip , .bz2 , .Z, nebo jiné typy externě komprimovaných datových souborů, které mohou dramaticky (2 - 20X) snížit náklady na skladování souborů. Často není žádný časový trest za použití externě komprimovaných souborů, protože čas uložen přenosem menšího souboru ze S3 do ERDDAP zhruba bilance času potřebného pro ERDDAP™ aby dekomprimoval soubor. Chcete-li tuto funkci použít, stačí se ujistit, že soubor dat<souborNázevRegex> umožňuje typ komprimovaného souboru (např. přidáním ( | .gz ) až do konce regexu) .  
• Pro nejčastější případ, kde máte ERDDAP™ nainstalován ve vašem PC pro test/vývoj a kde má datový soubor binární datové soubory, které jsou uloženy jako objekty v kbelíku S3, jeden přístup k získání datového souboru v ERDDAP™ je:

  1. Vytvořte si adresář ve vašem PC a podržte několik testovacích datových souborů.

  2. Stáhněte si dva datové soubory ze zdroje do adresáře, který jste právě vytvořili.

  3. Použití GenerovatDatasetsXml k vytvoření části datasets.xml pro datový soubor založený na dvou místních datových souborech.

  4. Zkontrolujte, zda soubor údajů funguje podle potřeby DasDds a/nebo vaše místní ERDDAP .

     Následující kroky vytvoří kopii tohoto souboru údajů (který získá data z kbelíku S3) na veřejnosti ERDDAP .

  5. Kopírovat část datasets.xml pro soubor údajů do souboru datasets.xml pro veřejnost ERDDAP™ To bude sloužit datům.

  6. Vytvořit adresář na veřejnosti ERDDAP Místní pevný disk, který udrží dočasné soubory. Adresář nebude používat mnoho místa na disku (viz cacheSizeGB níže) .

  7. Změna hodnoty datového souboru<fileDir> tag tak, že ukazuje na adresář, který jste právě vytvořili (i když je adresář prázdný) .

  8. Přidat a cacheFromUrl tag, který určuje název kbelíku datového souboru a volitelnou předponu (tj. adresář) v konkrétním Aws S3 URL formát, který ERDDAP™ vyžaduje .

  9. Přidat [<cacheSizeGB>] (#Cachefromurl) Označení xml datového souboru (Například 10 je dobrá hodnota pro většinu souborů údajů) říct ERDDAP™ omezit velikost místní cache (tj. nesnažte se skrývat všechny vzdálené soubory) .

  10. Zjisti, jestli to funguje na veřejnosti. ERDDAP . Všimněte si, že poprvé ERDDAP™ načítá data, bude trvat dlouho načíst, protože ERDDAP™ potřebuje stáhnout a přečíst všechny datové soubory.

Pokud je datový soubor obrovskou sbírkou rozsáhlých datových souborů, bude to trvat velmi dlouho a bude to nepraktické. V některých případech, pro mřížkované datové soubory, ERDDAP™ může extrahovat potřebné informace (např. časový bod pro data v datovém souboru s mřížkou) ze jména souboru a vyhnout se tomuto problému. Viz Agregace prostřednictvím Název souboru .

11. Volitelně (ale zejména pro datové soubory EDDTableFromFoles) , můžete přidat nThreads tag k datovému souboru ERDDAP použít více než 1 vlákno při reakci na požadavek uživatele na data. To minimalizuje účinky zpoždění, které nastane, když ERDDAP™ čte datové soubory z (vzdálený) AWS S3 kbelíky do místní cache a (Možná.) Dekomprese.

AWS S3 Otevřít data

V rámci NOAA 's Velký datový program , NOAA má partnerství s pěti organizacemi, včetně AWS, "k prozkoumání možných výhod uložení kopií klíčových pozorování a výstupů modelu v Cloudu, aby bylo možné počítat přímo na datech bez nutnosti dalšího šíření." AWS zahrnuje soubory, ze kterých pochází NOAA jako součást svého programu nabídnout veřejnosti přístup k velké kolekci Otevřít data o AWS S3 z jakéhokoli počítače, zda se jedná o Amazon Compute instance (pronajatý počítač) na síti AWS nebo vlastním počítači v jakékoliv síti. Níže uvedený příklad předpokládá, že pracujete s veřejně přístupným datovým souborem.

Přístup k souborům v AWS S3 Bucket

Pro soukromý datový kbelík S3 vám majitel kbelíku musí dát přístup k vědru. (Viz dokument AWS.)

Ve všech případech budete potřebovat účet AWS, protože AWS SDK pro Java (která ERDDAP™ používá k získávání informací o obsahu vědra) vyžaduje oprávnění AWS účtu. (více v tomto níže)

ERDDAP™ přístup k kbelíkům AWS S3 pouze pokud zadáte [<cacheFromUrl>] (#Cachefromurl) (nebo<souborDir>) ve zvláštním formátu: https://bucketName.s3.aws-region.amazonaws.com/prefix/
kde

• KbelíkJméno je krátká forma jména kbelíku, např. noaa-goes17 .
• Oblast Aws, např. us-east-1, je ze sloupce "Region" v jedné z tabulek Konec služby AWS kde je kbelík skutečně umístěn.
• Předpona je volitelná. Pokud je přítomen, musí skončit '/' .

Například,https://noaa-goes17.s3.us-east-1.amazonaws.com/ABI-L1b-RadC/
Tento formát URL je jedním z doporučení AWS S3: viz Přístup k kýblu a popis předpon . ERDDAP™ vyžaduje, abyste spojili kbelík URL a volitelný prefix do jedné URL, aby bylo možné určit<cacheFromUrl> (nebo<fileDir>) kde jsou soubory umístěny.

Testování veřejných AWS S3 Kýble

Pro veřejné kbelíky můžete a měli byste otestovat kbelík URL adresáře AWS S3 ve vašem prohlížeči, např. https://noaa-goes17.s3.us-east-1.amazonaws.com Pokud je kbelík URL správný a vhodný pro ERDDAP , vrátí XML dokument, který má (částečný) seznam obsahu toho vědra. Bohužel, celá URL (tj. kbelík URL plus předpona) že ERDDAP™ nefunguje v prohlížeči. AWS nenabízí systém prohlížení hierarchie kbelíku snadno ve vašem prohlížeči. (Pokud je to špatně, pošlete prosím Chrisovi email. John v Noaa.gov. Jinak, Amazone, prosím přidejte podporu!)

Zobrazení obsahu kýblu

Kbelíky S3 často obsahují několik kategorií souborů, v několika pseudo podadresářů, které by se mohly stát pár ERDDAP™ Data. Aby se ERDDAP™ Soubory dat, musíte znát výchozí adresář pro<cacheFromUrl> (nebo<fileDir>) a formát názvů souborů, které tuto podmnožinu souborů identifikují. Pokud se pokusíte zobrazit celý obsah kbelíku v prohlížeči, S3 vám ukáže prvních 1000 souborů, což je nedostatečné. V současné době, nejlepší způsob, jak si prohlédnout veškerý obsah kbelíku je vytvořit EDDTableFromFileNames Soubor údajů (na počítači. ERDDAP™ a/nebo na veřejnosti ERDDAP ) , který vám také dává snadný způsob, jak procházet strukturu adresáře a stahovat soubory. The<souborDir> pro to bude URL, které jste vytvořili výše, např.,https://noaa-goes17.s3.us-east-1.amazonaws.com. \[ Proč AWS S3 nenabízí rychlý a snadný způsob, jak to udělat bez účtu AWS? \] Všimněte si, že když tohle dělám na svém počítači v neamazonské síti, zdá se, že Amazon zpomaluje reakci na trik. (asi 100 (?) Soubory za kus) po prvních několika útržcích (1000 souborů za kus) jsou staženy. Vzhledem k tomu, kbelíky mohou mít obrovské množství souborů (Noaa-goes17 má 26 milionů) , získání všech obsahů kbelíku může trvat EDDTableFromFileJména několik hodin (např. 12!) do konce. \[ Amazonka, je to tak? \]

Vytvářet graf ZFileNames Dataset s AWS S3 Bucket

Pokud máte jméno kbelíku, ale již nemáte seznam souborů v kbelíku S3 nebo předponu, která identifikuje umístění příslušných souborů v kbelíku, použijte níže uvedené pokyny k vytvoření souboru EDDTableFromFileNames, abyste mohli procházet hierarchii adresáře kbelíku S3 prostřednictvím ERDDAP 's "files" systém.

1. Otevřít účet AWS ERDDAP™ používá AWS SDK pro Java získat informace o vědě od AWS, takže musíte vytvořit a aktivovat účet AWS . To je docela velká práce, se spoustou věcí, které se musíš naučit.  
2. Dejte své AWS oprávnění kam ERDDAP™ může je najít. Postupujte podle pokynů Nastavit AWS Credentials a Region for Development tak ERDDAP™ (Konkrétně AWS SDK Java ) bude moci najít a použít vaše AWS pověření. Pokud ERDDAP™ Nemůžete najít doklady, uvidíte Java.lang. IlegálníHargument Výjimkou: profilový soubor nemůže být chybou v ERDDAP 's log.txt soubor.

Tip pro Linux a Mac OS: pověřovací soubor musí být v domovském adresáři uživatele, který spouští Tomcat (a ERDDAP ) (pro tento odstavec, budeme předpokládat user=tomcat) ve složce zvané ~/.aws/credentials . Nepředpokládejte, že ~ je /home/tomcat -- vlastně použít cd ~ zjistit, kde operační systém myslí ~ pro uživatele=tomcat je. Vytvořte adresář, pokud neexistuje. Dále, poté, co umístíte pověřovací soubor na místo, ujistěte se, že uživatel a skupina pro soubor jsou tomcat a pak použít Chmod 400 pověřovacích listin, aby se ujistil, že soubor je čten pouze pro uživatele=tomcat.

3. Vytvořit kbelík URL v formát, který ERDDAP™ vyžaduje např. https://noaa-goes17.s3.us-east-1.amazonaws.com a (pro veřejné vědro) otestujte jej v prohlížeči, aby se ujistil, že vrátí XML dokument, který má částečný seznam obsahu tohoto kbelíku.  
4. Použití GenerovatDatasetsXml vytvořit EDDTableFromFileNames Soubor údajů:
   • Pro úvodní adresář použijte tuto syntaxi: \\\ z OnTheFly, Vaše BucketUrl* například: \\\* from OnThe Fly,https://noaa-goes17.s3.us-east-1.amazonaws.com/
   • Jméno souboru regex? .\*
   • Rekurzivní? pravda
   • reload Každý NMinutes? 10080
   • infoUrl ?https://registry.opendata.aws/noaa-goes/
   • Instituce? NOAA
   • Shrnutí? Nic. ( ERDDAP™ automaticky vytvoří slušné shrnutí.)
   • Název? Nic. ( ERDDAP™ automaticky vytvoří slušný název.) Jako obvykle byste měli editovat výsledný XML pro ověření správnosti a provést vylepšení před částí souborů, které jej používají v datasets.xml .
5. Pokud budete postupovat podle výše uvedených pokynů a načíst soubor údajů v ERDDAP , jste vytvořili EDDTableFromFoles soubor. Jako příklad, a aby bylo pro každého jednodušší procházet a stahovat soubory z kbelíků AWS Open Data, jsme vytvořili soubory EDDTableFromFileNames (viz seznam na https://upwell.pfeg.noaa.gov/erddap/search/index.html?searchFor=awsS3Files\_ ) pro téměř všechny AWS S3 Otevřít datové vědro . \[ Pár kýblů, které jsme do kořenového adresáře nezahrnuli. (více než lze stáhnout v přiměřeném čase) , nebo nedovolují přístup veřejnosti (Neměly by být všechny veřejné?) , nebo jsou kbelíky Requester Pays (např. Sentinel) . \]
   Pokud kliknete na "files" odkaz na jeden z těchto souborů, můžete procházet adresář strom a soubory v tomto S3 kbelíku. Kvůli cestě\\\*fromOnTheFly EDDTableFromFiles funguje, tyto seznamy adresářů jsou vždy dokonale aktuální, protože ERDDAP™ Dostane je do letadla. Pokud kliknete na strom adresáře na aktuální název souboru a kliknete na název souboru, ERDDAP™ přesměruje váš požadavek na AWS S3 tak, abyste mohli soubor stáhnout přímo z AWS. Pak si můžete ten soubor prohlédnout.

Problémy? Pokud váš EDDTableFromFoles nenačte do ERDDAP™ (nebo DasDds) , podívejte se do souboru log.txt pro chybovou zprávu. Pokud uvidíte Java.lang. NelegálníHargumentVýjimka: profilový soubor nemůže být chybou nula, problém je, že AWS SDK pro Java (používaný ERDDAP ) Nenašel jsem tu složku. Viz pokyny výše.  

Je nešťastné, že AWS nedovoluje lidem, aby prohlížečem prohlíželi obsah veřejného kbelíku.

Pak můžete udělat ERDDAP™ data, která uživatelům umožňují přístup k datům v souborech.
Viz pokyny v ERDDAP™ a S3 kýbly (nad) . Pro vzorek EDDTableFromFileNames soubor, který jste vytvořili výše, pokud uděláte trochu pošťouchání kolem adresáře a názvy souborů ve stromu adresáře, je jasné, že jména adresářů nejvyšší úrovně (např. ABI-L1b-RadC) odpovídá tomu, co ERDDAP™ Volal bych samostatné soubory dat. Kbelík, se kterým pracujete, může být podobný. Pak byste mohli pokračovat v vytváření samostatných souborů v ERDDAP™ pro každý z těchto souborů údajů, např. https://noaa-goes17.s3.us-east-1.amazonaws.com/ABI-L1b-RadC/
jako<cacheFromUrl>. Bohužel, pro tento konkrétní příklad, soubory údajů v kbelíku se zdá být úroveň 1 nebo úroveň 2 soubory údajů, které ERDDAP™ není moc dobrý v , protože datový soubor je složitější sběr proměnných, které používají různé rozměry.  

NcML soubory

NcML soubory vám umožní zadat změny při letu na jeden nebo více původních zdrojů NetCDF (V3 nebo v4) .nc , .grib, .bufr, nebo .hdf (v4 nebo v5) soubory, a pak mít ERDDAP™ Léčba .nc ml soubory jako zdrojové soubory. ERDDAP™ Soubory budou akceptovat .nc ml soubory kdykoliv .nc Soubory se očekávají. NcML soubory musí mít rozšíření .nc ml. Viz Unidata Dokumentace NcML . NcML je užitečné, protože můžete udělat některé věci s ním (například provádět různé změny různých souborů ve sbírce, včetně přidání rozměru se specifickou hodnotou do souboru) , že nemůžete dělat s ERDDAP 's datasets.xml .

• Změny .nc ml souboru posledníModifikovaný čas způsobí, že soubor bude znovu načten, kdykoli je soubor znovu načten, ale změny v podkladovém souboru .nc Datové soubory nebudou přímo zaznamenány.
• Tip: NcML\*velmi\*citlivé na pořadí některých položek v NcML souboru. Myslete na NcML jako upřesnění řady pokynů v uvedeném pořadí, se záměrem změnit zdrojové soubory (stav na začátku/nahoře souboru NcML) do cílových souborů (stav na konci/podmínce souboru NcML) .

Alternativou k NcML je NetCDF Provozovatelé ( NCO ) . Velký rozdíl je v tom, že NcML je systém pro provádění změn při letu (takže zdrojové soubory nejsou změněny) , vzhledem k těmto důvodům: NCO lze použít k provedení změn (nebo nové verze) Složky. Oba NCO a NcML jsou velmi, velmi flexibilní a umožňují vám udělat téměř jakoukoli změnu můžete myslet na soubory. Pro oba, může být náročné přijít na to, jak přesně dělat to, co chcete dělat - zkontrolujte web pro podobné příklady. Oba jsou užitečné nástroje pro přípravu netCDF a HDF soubory pro použití s ERDDAP , zejména k provedení změn nad rámec toho, co ERDDAP Manipulační systém to zvládne.

Příklad #1: Přidání rozměru času s jednou hodnotou Tady je. .nc ml soubor, který vytváří nový vnější rozměr (čas, s 1 hodnotou: 1041379200) a přidá tento rozměr do proměnné pic v souboru s názvem 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>

Příklad #2: Změna stávající hodnoty času Někdy zdroj .nc soubor již má časový rozměr a časovou hodnotu, ale hodnota je nesprávná (pro vaše účely) . Tohle .nc ml soubor říká: pro datový soubor s názvem ""19810825230030-NCEI..." pro rozměr proměnné "time" , nastavit jednotky atribut být 'sekundy od 1970-01-01T00:00:00Z' a nastavit časovou hodnotu 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 Provozovatelé ( NCO )

"NetCDF operátori ( NCO ) se skládá z tuctu samostatných, příkazových programů, které berou netCDF \[ V3 nebo v4 \] , HDF \[ v4 nebo v5 \] , \[ .grib, .bufr, \] nebo DAP soubory jako vstup, pak fungovat (Například odvození nových dat, výpočetní statistiky, tisk, hyperslab, manipulace metadat) a výstup výsledků na obrazovku nebo soubory v textových, binárních nebo netCDF formátech. NCO Asistence analýzy mřížkovaných vědeckých údajů. Shell-command style NCO umožňuje uživatelům interaktivně manipulovat a analyzovat soubory nebo s expresivními skripty, které se vyvarují nadbytku vyšších úrovní programovacích prostředí." (z NCO domovská stránka) .

Alternativa k NCO je NcML . Velký rozdíl je v tom, že NcML je systém pro provádění změn při letu (takže zdrojové soubory nejsou změněny) , vzhledem k těmto důvodům: NCO lze použít k provedení změn (nebo nové verze) Složky. Oba NCO a NcML jsou velmi, velmi flexibilní a umožňují vám udělat téměř jakoukoli změnu můžete myslet na soubory. Pro oba, může být náročné přijít na to, jak přesně dělat to, co chcete dělat - zkontrolujte web pro podobné příklady. Oba jsou užitečné nástroje pro přípravu netCDF a HDF soubory pro použití s ERDDAP , zejména k provedení změn nad rámec toho, co ERDDAP Manipulační systém to zvládne.

Můžete například použít NCO aby jednotky časové proměnné byly konzistentní ve skupině souborů, kde původně nebyly konzistentní. Nebo můžete použít NCO uplatnit scale\_factor a add\_offset ve skupině souborů, kde scale\_factor a add\_offset mají různé hodnoty v různých zdrojových souborech. (Nebo se nyní můžete vypořádat s těmito problémy v ERDDAP™ přes EDDGrid FromNcFilesUnpacked , což je varianta EDDGrid FromNcFiles, které rozebírá zabalená data a standardizuje časové hodnoty na nízké úrovni, aby se mohly zabývat soubory sběru, které mají různé scale\_factor s a add\_offset , nebo jiné časové jednotky.)

NCO je svobodný a otevřený zdroj software, který používá GPL 3. 0 Řidičák.

Příklad #1: Udělat jednotky konzistentní EDDGrid FromFiles a EDDTable Ze souborů trvají na tom, že jednotky dané proměnné jsou totožné ve všech souborech. Pokud některé soubory jsou triviálně (ne funkčně) jiné než jiné (např. časové jednotky "sekundy od 1970-01-01 00:00:00 UTC" versus "seconds since 1970-01-01T00:00:00Z" , můžete použít NCO 's ncatted . změnit jednotky ve všech souborech být totožné s nco/ncatted -a jednotky,time,o,c,'sekundy od 1970-01-01T00:00:00Z' \* .nc
\[ Pro mnoho problémů, jako je tento v EDDTableFrom... Soubory souborů, nyní můžete použít standardizovat Co? říct ERDDAP standardizovat zdrojové soubory, jak jsou čteny do ERDDAP . \]

Limity velikosti datové sady

Uvidíte mnoho odkazů na "2 miliardy" níže. Přesněji řečeno, to je odkaz na 2.147, Praha4647 (2^31-1) , což je maximální hodnota 32-bit podepsané celé číslo. Například v některých počítačových jazycích Java (která ERDDAP™ je napsáno) , že je největší datový typ, který lze použít pro mnoho datových struktur (například velikost pole) .

Pro hodnoty řetězce (například pro názvy proměnných, názvy atributů, hodnoty atributů String a hodnoty dat String) , maximální počet znaků na String ERDDAP™ 2 miliardy. Ale téměř ve všech případech, tam budou malé nebo velké problémy, pokud String přesahuje rozumnou velikost (např. 80 znaků pro názvy proměnných a názvy atributů a 255 znaků pro většinu hodnot atributu String a hodnot dat) . Například webové stránky, které zobrazují dlouhé názvy proměnných, budou trapně široké a dlouhé názvy proměnných seškrtány, pokud překročí limit typu souboru odezvy.

U mřížkovaných souborů údajů:

• Maximální počet axisVariable Je to 2 miliardy. Maximální počet dataVariable Je to 2 miliardy. Ale pokud má datový soubor >100 proměnných, bude to obtížné pro uživatele používat. A pokud má datový soubor více než 1 milion proměnných, bude váš server potřebovat mnoho fyzické paměti a budou zde další problémy.
• Maximální velikost každého rozměru ( axisVariable ) je ~2 miliardy hodnot.
• Myslím, že maximální celkový počet buněk (produkt všech rozměrů) je neomezené, ale může to být ~9e18.

U tabulkových souborů:

• Maximální počet dataVariable Je to 2 miliardy. Ale pokud má datový soubor >100 proměnných, bude to obtížné pro uživatele používat. A pokud má datový soubor více než 1 milion proměnných, bude váš server potřebovat mnoho fyzické paměti a budou zde další problémy.
• Maximální počet zdrojů (například soubory) To se dá shrnout na ~2 miliardy.
• V některých případech maximální počet řádků z jednotlivého zdroje (například soubor, ale ne databáze) je ~2 miliardy řad.
• Nemyslím si, že existují jiné hranice.

U roštových i tabulárních souborů existují určité interní limity velikosti podmnožiny, které může uživatel požadovat v jediné žádosti (často související s >2 miliardy něčeho nebo ~9e18 něčeho) , ale je mnohem pravděpodobnější, že uživatel narazí na limit pro daný typ souboru.

• NetCDF verze 3 .nc soubory jsou omezeny na 2GB bajty. (Pokud je to pro někoho opravdu problém, dejte mi vědět: Mohl bych přidat podporu pro NetCDF verze 3 .nc 64-bitové rozšíření nebo NetCDF Verze 4, která by výrazně zvýšila limit, ale ne nekonečně.)
• Prohlížeče havarovat pouze po ~500MB dat, takže ERDDAP™ omezuje odpověď na .htmlTable požaduje ~400MB dat.
• Mnoho programů analýzy dat má podobné limity (Například, maximální velikost rozměru je často ~2 miliardy hodnot) , takže není důvod tvrdě pracovat, aby se dostali kolem omezení typu souboru.
• Limity specifické pro daný soubor jsou užitečné v tom, že brání naivním žádostem o skutečně obrovské množství údajů (Například "dejte mi celý tento soubor údajů," když má datový soubor 20TB dat) , které by trvalo týdny nebo měsíce ke stažení. Čím delší bude stahování, tím pravděpodobněji selže z různých důvodů.
• Limity specifické pro daný soubor jsou užitečné v tom, že přinutí uživatele zabývat se přiměřeně velkými podskupinami (např. řešení velkého mřížkovaného datového souboru prostřednictvím souborů s daty z jednoho časového bodu) .  

Přepnout na ACDD-1.3

My (zejména GenerovatDatasetsXml ) v současné době doporučujeme ACDD verze 1.3 , která byla ratifikována na počátku roku 2015 a která je v atributu globálních úmluv označována jako "ACDD-1.3." Před ERDDAP™ verze 1.62 (vydané v červnu 2015) , ERDDAP™ použitý/doporučený originál, verze 1.0, NetCDF Atributová úmluva pro Discovery datových souborů který byl označován jako " Unidata Dataset Discovery v1.0" v globálních úmluvách a Metadata\_Conventions atributy.

Pokud vaše datové soubory používají dřívější verze ACDD, DOPORUČUJEme, že přepnete na ACDD-1.3. Není to těžké. ACDD-1.3 je vysoce zpětně kompatibilní s verzí 1.0. Přepnout pro všechny soubory dat (kromě EDDGrid OdErddap a EDDTable Z dat Erddapu) :

1. Odstranit nově deprecovaný globální Metadata\_Conventions atribut přidáním (nebo změnou existujícího Metadata\_Conventions atribut)

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

do globálního souboru údajů< addAttributes >.   2. Pokud má datový soubor atribut Konvence v globálním měřítku< addAttributes >, změnit vše " Unidata Dataset Discovery v1.0" reference na "ACDD-1.3." Pokud datový soubor nemá atribut Conventions v globálním měřítku< addAttributes >, pak přidat jeden, který odkazuje na ACDD-1.3. Například,

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

  3. Pokud má datový soubor globální standard\_name\_vocabulary atribut, prosím změňte formát hodnoty například na:

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

Pokud je odkaz na starší verzi Standardní tabulka názvu CF . je pravděpodobně dobrý nápad přejít na aktuální verzi (65, jak to píšeme) , Vzhledem k tomu, že nové standardní názvy jsou přidány do této tabulky s následnými verzemi, ale staré standardní názvy jsou zřídka deprekovány a nikdy odstraněny.   4. I když ACDD-1.0 zahrnoval globální atributy pro creator\_name , creator\_email , creator\_url , GenerovatDatasetsXml automaticky je přidal až někdy kolem ERDDAP™ v1.50. Jedná se o důležité informace:

• creator\_name dává uživatelům vědět / citovat tvůrce datového souboru.
• creator\_email sdělí uživatelům preferovanou e-mailovou adresu pro kontaktování tvůrce datového souboru, například pokud mají otázky týkající se datového souboru.
• creator\_url dává uživatelům způsob, jak zjistit více o tvůrce.
• ERDDAP™ všechny tyto informace využívá při vytváření dokumentů o metadatech FGDC a ISO 19115-2/19139 pro každý datový soubor. Tyto dokumenty často používají externí vyhledávací služby.

Přidejte prosím tyto atributy do globálního souboru dat< 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>  

To je ono. Doufám, že to nebylo tak těžké.  

Zarr

Od verze 2.25 ERDDAP™ může číst místní Zarr soubory pomocí EDDTableFromNcFiles a EDDGrid FromNcFiles .

(Od srpna 2019) Snadno se můžeme mýlit, ale ještě nejsme přesvědčeni, že Zarr , nebo podobné systémy, které rozbíjejí datové soubory do menších částí, jsou skvělá řešení problému ERDDAP™ čtení dat uložených v cloudových službách jako Amazon AWS S3. Zarr je skvělá technologie, která ukázala svou užitečnost v různých situacích, jen si nejsme jisti, že ERDDAP +S3 bude jednou z těchto situací. Hlavně říkáme, že než se pokusíme uložit všechna data do Zarru, uděláme nějaké testy, abychom zjistili, jestli je to skutečně lepší řešení.

Problémy s přístupem k datům v cloudu jsou latence (zpoždění na první získání údajů) a přístup na úrovni souborů (spíše než blokový přístup) . Zarr řeší problém přístupu na úrovni souborů, ale s latencí nic nedělá. Ve srovnání s pouhým stažením souboru (takže lze číst jako místní soubor s přístupem na úroveň bloku) , Zarr může dokonce zhoršit problém latence, protože se Zarr, čtení souboru nyní zahrnuje řadu několika volání číst různé části souboru (každý s vlastním zpožděním) . Problém latence lze vyřešit paralelizací požadavků, ale to je řešení vyšší úrovně, které není závislé na Zarr.

A se Zarr (jako u relačních databází) , ztratíme pohodlí mít datový soubor je jednoduchý, jediný soubor, který můžete snadno ověřit integritu, nebo provést / stáhnout kopii.

ERDDAP™ (od v2) má systém pro udržování lokální cache souborů ze zdroje URL (např. S3) (viz [<cacheFromUrl> a<cacheMaxGB>] (#Cachefromurl) ). A nový [<nThreads>] (# nitra) by měl minimalizovat problém latence paralelizací vyhledávání dat na vysoké úrovni.<cacheFromUrl> se zdá, že pracuje velmi dobře pro mnoho scénářů. (Nejsme si jistí, jak prospěšné<nThreads> je bez dalších zkoušek.) Připouštíme, že jsme neudělali časové testy na AWS instance s dobrým síťovým připojením, ale úspěšně jsme testovali s různými vzdálenými URL zdroji souborů. A ERDDAP 's<cacheFromUrl> pracuje s jakýmkoli typem datového souboru (např. .nc , .hdf , .csv, .jsonlCSV ) , i když externě komprimované (např. .gz ) , bez jakýchkoli změn souborů (Například je přepisuje jako sbírky Zarr) .

Je pravděpodobné, že různé scénáře upřednostní různá řešení, např., stačí si přečíst část souboru jednou (Zarr vyhraje.) , vs. potřeba číst celý soubor jednou, vs. potřeba číst část nebo celý soubor opakovaně (<cacheFromUrl> vyhraje).

Hlavně říkáme, že než se pokusíme uložit všechna data do Zarru, uděláme nějaké testy, abychom zjistili, jestli je to skutečně lepší řešení.

---

Seznam datových souborů typu

Pokud potřebujete pomoci vybrat správný typ datového souboru, viz Výběr typu datové sady .

Typy souborů dat spadají do dvou kategorií. ( Proč? )

EDDGrid

• ** EDDGrid ** Datové soubory zvládají datovaná data.
• In EDDGrid datové soubory, datové proměnné jsou multidimenzionální pole dat.
• Pro každý rozměr musí existovat proměnná osy. Proměnné osy MUSÍ být specifikovány v pořadí, v jakém je datové proměnné používají.
• In EDDGrid Soubory údajů, všechny datové proměnné MUSÍ používat (podíl) všechny proměnné osy. ( Proč? Co když ne? ) Nový ERDDAP™ verze 2.29.0 EDDGrid FromNcFiles je experimentální podpora datových proměnných, které nepodporují všechny proměnné osy (nebo jak to někteří nazvali 1D a 2D dat ve stejném datovém souboru) .
• Vytříděné hodnoty rozměrů - Celkem EDDGrid Soubory údajů, každý rozměr musí být v seřazeném pořadí (vzestupně nebo sestupně) . Každý může být nepravidelně mezerný. Nejsou žádné vazby. To je požadavek Standard metadat CF . Pokud hodnoty jakéhokoli rozměru nejsou v seřazeném pořadí, soubor dat se nenačte a ERDDAP™ určí první netříděnou hodnotu v souboru záznamu, velkýRodič rodičů /logs/log.txt .

Několik podtříd má další omezení (zejména, EDDGrid AgregátExistingDimension vyžaduje, aby vnější (nejlevější, první) rozměr byl vzestupný.

Netříděné hodnoty rozměrů téměř vždy indikují problém se zdrojovým souborem. To se nejčastěji vyskytuje, když je do agregace zahrnut chybný nebo nevhodný soubor, což vede k netříděné časové dimenzi. Pro vyřešení tohoto problému viz chybová zpráva v ERDDAP™ log.txt soubor k nalezení urážlivé časové hodnoty. Pak se podívejte do zdrojových souborů najít odpovídající soubor (nebo jeden před nebo jeden po) To nepatří do agregace.

• Viz podrobnější popis EDDGrid datový model .
• The EDDGrid Typy údajů jsou:
  • EDDGrid FromAudioFiles shromažďuje data ze skupiny místních audio souborů.
  • EDDGrid FromDap zpracovává roštová data z DAP servery.
  • EDDGrid OdEDDTable umožňuje převést tabulkový soubor do mřížkového souboru.
  • EDDGrid FromErddap zvládá mřížkovaná data ze vzdáleného ERDDAP .
  • EDDGrid OdEtopa jen zpracovává vestavěná data ETOPO topography.
  • EDDGrid FromFiles je supertřída všech EDDGrid Z... tříd.
  • EDDGrid Z MergeIRFiles Sčítání údajů ze skupiny místních MergeIR .gz Složky.
  • EDDGrid FromNcFiles Údaje o agregátech ze skupiny místních NetCDF (V3 nebo v4) .nc a související soubory.
  • EDDGrid FromNcFilesUnpacked je varianta, pokud EDDGrid FromNcFiles, které také hromadí data ze skupiny místních NetCDF (V3 nebo v4) .nc a související soubory, které ERDDAP™ Vybaluje na nízké úrovni.
  • EDDGrid LonPM180 mění hodnoty délky dítěte EDDGrid takže jsou v rozmezí -180 až 180.
  • EDDGrid Lon0360 mění hodnoty délky dítěte EDDGrid takže jsou v rozmezí 0 až 360.
  • EDDGrid SideBySide agregáty dvě nebo více EDDGrid Údaje bok po boku.
  • EDDGrid AgregátExistujícíRozměr agregáty dvě nebo více EDDGrid datové soubory, z nichž každý má jiný rozsah hodnot pro první rozměr, ale stejné hodnoty pro ostatní rozměry.
  • EDDGrid Kopírovat může vytvořit místní kopii jiného EDDGrid 's daty a slouží data z místní kopie.  
• Všechny EDDGrid Soubory dat podporují nastavení nThreads, které říká ERDDAP™ kolik vláken použít při reakci na žádost. Viz nThreads dokumentace pro podrobnosti.  

EDDTabulka

• EDDTabulka Soubory dat zpracovávají tabulární data.
• Tabulková data mohou být reprezentována jako databázová tabulka s řádky a sloupcemi. Každý sloupec (datové proměnné) má název, soubor atributů a ukládá pouze jeden typ dat. Každá řada má postřeh (nebo skupina souvisejících hodnot) . Zdroj dat může mít data v jiné datové struktuře, složitější datové struktuře a/nebo více datových souborů, ale ERDDAP™ musí být schopna srovnat zdrojová data do tabulky podobné databázi, aby bylo možné prezentovat data jako soubor tabulek uživatelům ERDDAP .
• Viz podrobnější popis Datový model EDDTable .
• Typy souborů údajů EDDTable jsou:
  • EDDTableFromAllDatasets je datový soubor vyšší úrovně, který má informace o všech ostatních datových souborech ve vašem ERDDAP .
  • EDDTableFromAsciiFiles agreguje data z čárkových, tabulkových, středníkových nebo mezerně oddělených datových souborů ASCII.
  • EDDTableFromAsciiService je supertřída všech EDDTableFromAsciiService... tříd.
  • EDDTableFromAsciiServiceNOS zpracovává údaje z některých NOAA NOS webové služby.
  • EDDTableFromAudioFiles shromažďuje data ze skupiny místních audio souborů.
  • EDDTableFrom AwsXmlFiles agreguje data ze sady automatických počasí (AWS) XML soubory.
  • EDDTableFromCassandra zpracovává tabulková data z jedné Cassandry tabulky.
  • EDDTableFromColumnarAsciiFiles shromažďuje data z tabulkových datových souborů ASCII s datovými sloupy s pevnou šířkou.
  • EDDTableFromDapSekvence zpracovává tabulární data z DAP sekvenční servery.
  • EDDtableFromDatabase zpracovává tabulková data z jedné tabulky databáze.
  • EDDTableFrom EDDGrid umožňuje vytvořit soubor EDDTable z EDDGrid Soubor dat.
  • EDDTableFromErddap zpracovává tabulková data ze vzdáleného ERDDAP .
  • EDDTableFromFileNames vytváří soubor dat z informací o skupině souborů v systému souborů serveru, ale nepodává data zevnitř souborů.
  • EDDTableFromFoles je supertřída všech EDDTableFrom...Files třídy.
  • EDDTableFromHttpGet je ERDDAP 'je pouze systém pro import dat a export dat.
  • EDDTableFrom Hyrax Soubory (ODCHYLKY) kumuluje data ze souborů s několika proměnnými se sdílenými rozměry poskytovanými Hyrax OPeNDAP server .
  • EDDTableFromNeplatnéCRAFile Údaje z agregátů NetCDF (V3 nebo v4) .nc soubory, které používají specifický, neplatný, varianta CF DSG Contiguous Ragged Array (CRA) Složky. I když ERDDAP™ podporuje tento typ souboru, je to neplatný typ souboru, který by nikdo neměl používat. Skupiny, které v současné době používají tento typ souboru, jsou důrazně vybízeny k používání ERDDAP™ generovat platné soubory CF DSG CRA a přestat používat tyto soubory.
  • EDDTableFromJsoniCSVFiles Údaje z agregátů JSON Řádky CSV souborů .
  • EDDTablefromMultidimNcFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc soubory s několika proměnnými se sdílenými rozměry.
  • EDDTableFromMqtt konstruuje soubor založený na MQTT zprávách. Poznámka: dokumentace je na vyhrazené stránce. Všimněte si, že existuje mnoho podobností s EDDTableFromHttpGet .
  • EDDTableFromNcFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc soubory s několika proměnnými se sdílenými rozměry. Je v pořádku pokračovat v používání tohoto datového souboru pro stávající datové soubory, ale pro nové datové soubory doporučujeme použít místo toho EDDTableFromMultidimNcFiles.
  • EDDTableFromNcCFFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc soubory, které používají jeden ze formátů souborů uvedených v CF Geometrie diskrétního odběru vzorků (DSG) Konvence. Ale pro soubory používající jednu z multidimenzionálních CF DSG variant, použijte EDDTablefromMultidimNcFiles Místo toho.
  • EDDTableFromNccsvFiles Údaje z agregátů NCCSV ASCII .csv soubory.
  • EDDTableFromNOS (ODCHYLKY) zpracovává tabulková data z NOS XML serverů.
  • EDDTableFromOBIS zpracovává tabulková data ze serverů OBIS.
  • EDDTableFromParquetFiles zpracovává údaje od Parket .
  • EDDTableFrom SOS zpracovává tabulární data z SOS servery.
  • EDDTableFromThreddsFiles (ODCHYLKY) kumuluje data ze souborů s několika proměnnými se sdílenými rozměry poskytovanými THREDDS OPeNDAP server .
  • EDDTableFrom WFS Soubory (ODCHYLKY) vytvoří místní kopii všech údajů z ArcGIS MapServer WFS server, takže data pak mohou být rychle re-served ERDDAP™ uživatelé.
  • EDDTableAggregateRows může vytvořit soubor EDDTable ze skupiny datových souborů EDDTable.
  • EDDtableCopy může vytvořit místní kopii mnoha typů souborů údajů EDDTable a pak rychle re-serve dat z místní kopie.

---

Podrobné popisy typů datových souborů

EDDGrid FromDap

** EDDGrid FromDap** zpracovává proměnné sítě z DAP servery.

• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Můžete shromáždit informace, které potřebujete k vylepšení, nebo vytvořit vlastní XML pro EDDGrid FromDap data database tím, že se podíváte na soubory DDS a DAS zdrojového souboru ve vašem prohlížeči (přidáním .das a .dds do sourceUrl Například: https://thredds1.pfeg.noaa.gov/thredds/dodsC/satellite/BA/ssta/5day.dds ) .  
• EDDGrid FromDap může získat data z jakékoliv multidimenzionální proměnné z a DAP datový server. (V předchozích dílech... EDDGrid FromDap byl omezen na proměnné označené jako "grid," ale to již není požadavek.)
   
• Vytříděné hodnoty rozměrů - Hodnoty pro každý rozměr MUSÍ být v seřazeném pořadí (vzestupně nebo sestupně) . Hodnoty mohou být nepravidelně rozloženy. Nejsou žádné vazby. To je požadavek Standard metadat CF . Pokud hodnoty jakéhokoli rozměru nejsou v seřazeném pořadí, soubor dat se nenačte a ERDDAP™ určí první netříděnou hodnotu v souboru záznamu, velkýRodič rodičů /logs/log.txt .

Netříděné hodnoty rozměrů téměř vždy indikují problém se zdrojovým souborem. To se nejčastěji vyskytuje, když je do agregace zahrnut chybný nebo nevhodný soubor, což vede k netříděné časové dimenzi. Pro vyřešení tohoto problému viz chybová zpráva v ERDDAP™ log.txt soubor k nalezení urážlivé časové hodnoty. Pak se podívejte do zdrojových souborů najít odpovídající soubor (nebo jeden před nebo jeden po) To nepatří do agregace.

EDDGrid FromDap kostra XML

    <dataset type="EDDGridFromDap" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <accessibleViaWMS>...</accessibleViaWMS> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1.
        For EDDGridFromDap, this gets the remote .dds and then gets the new
        leftmost (first) dimension values. -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <dimensionValuesInMemory>...</dimensionValuesInMemory> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <axisVariable>...</axisVariable> <!-- 1 or more -->
      <dataVariable>...</dataVariable> <!-- 1 or more -->
    </dataset>

 

EDDGrid OdEDDTable

** EDDGrid OdEDDTable** umožňuje převést soubor tabulky EDDTable do souboru EDDGrid Souřadnice dat. Pamatuj si to. ERDDAP™ považuje soubory údajů za buď Souřadnice dat (podtřídy EDDGrid ) nebo soubor tabulkových dat (podtřídy EDDTable) .

• Normálně, pokud máte nastavená data, stačí nastavit EDDGrid Databáze přímo. Někdy to není možné, například když máte data uložená v relační databázi, která ERDDAP™ lze přistupovat pouze přes EDDTableFromDatabase. EDDGrid Z třídy EDDTable vám umožní tuto situaci napravit.  
• Je zřejmé, že údaje v podkladovém souboru EDDTable musí být (v podstatě) datová pole, ale v tabulkové formě. Databáze EDDTable může mít například data CDD: měření východního a severního proudu, v několika hloubkách, několikrát. Vzhledem k tomu, že hloubky jsou v každém bodě stejné, EDDGrid FromEDDTable může vytvořit roštový soubor s časem a rozměrem hloubky, který přístup k datům prostřednictvím základního datového souboru EDDTable.  
• Generovat soubory dat Xml... Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Můžete shromáždit informace, které potřebujete ke zlepšení hrubého návrhu.  
• Zdrojové atributy -- Stejně jako u všech ostatních typů souborů údajů, EDDGrid FromTable má představu, že existují globální zdrojAttributes a globální addAttributes (uvedené v datasets.xml ) , které jsou kombinovány pro globální kombinaci Atributy, které uživatelé vidí. Pro globální zdrojAttributy, EDDGrid FromEDDTable používá globální kombinaci Atributy podkladového souboru EDDTable. (Když se nad tím chvíli zamyslíš, dává to smysl.)

Podobně, pro každý axisVariable 's a dataVariable 's addAttributes , EDDGrid FromEDDTable používá kombinaci proměnné Atributy základního datového souboru EDDTable jako EDDGrid Od zdroje EDDTable proměnnéAttributy. (Když se nad tím chvíli zamyslíš, dává to smysl.)

V důsledku toho, pokud má EDDTable dobrá metadata, EDDGrid FromEDDTable často potřebuje velmi málo addAttributes Metadata -- jen pár vylepšení sem a tam.

• dataVariable s versus axisVariable s -- Základní EDDTable má pouze dataVariable s. An EDDGrid Soubor dat z EDDTable bude mít některé axisVariable án (vytvořeno z některé z EDDTable dataVariable án) a některé dataVariable án (vytvořen ze zbývajícího EDDTable dataVariable án) . GenerovatDatasetsXml bude hádat, o který EDDTable dataVariable s EDDGrid OdEDDTable axisVariable Ale je to jen odhad. Musíte upravit výstup GenerateDatasetsXml, abyste určili, který dataVariable s se stane axisVariable s, a v jakém pořadí.  

• OsaValues -- Není nic o podkladovém EDDTable říct EDDGrid OdEDDTable možné hodnoty axisVariable s v roštové verzi datového souboru, takže musíte poskytnout tyto informace pro každý axisVariable přes jeden z těchto atributů:

  • osaValues -- umožňuje zadat seznam hodnot. Například, <att name="axisValues" type="doubleList" \>2, 2.5, 3, 3.5, 4</att > Všimněte si použití datový typ plus slovo List. Také typ seznamu (například dvojitá) , MUSÍ odpovídat údajům Typ proměnné v EDDTable a EDDGrid Z dat EDDTable.
  • osaValuesStartStrideStop -- umožňuje zadat posloupnost pravidelně rozložených hodnot zadáním start, krok a stop hodnot. Zde je příklad, který odpovídá příkladu osValues výše: <att name="axisValuesStartStrideStop" type="doubleList" \>2, 0, 5, 4</att > Znovu si všimněte použití datového typu seznamu. Také typ seznamu (například dvojitá) , MUSÍ odpovídat údajům Typ proměnné v EDDTable a EDDGrid Z dat EDDTable.  

Aktualizace... Stejně jako neexistuje žádná možnost pro EDDGrid FromEDDTable pro stanovení osValues z EDDTable zpočátku neexistuje spolehlivý způsob pro EDDGrid FromEDDTable to determine from the EDDTable when the axisValues have changed (zejména pokud existují nové hodnoty časové proměnné) . V současné době je jediným řešením změna atributu OsaValues v datasets.xml a znovu načíst data. Například, můžete napsat scénář

1. Hledat datasets.xml místo datasetID =" theDatasetID " Takže pracujete se správným souborem dat.
2. Hledat datasets.xml pro další výskyt VariablesSourceName
   Takže pracujete se správnou proměnnou.
3. Hledat datasets.xml pro další výskyt

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

takže znáte výchozí pozici značky. 4. Hledat datasets.xml pro další výskyt

        </att>  

takže znáte konečnou polohu hodnot osy. 5. Nahradit starý start, krok, zastavit hodnoty s novými hodnotami. 6. Kontaktujte URL vlajky pro soubor údajů, který má sdělit ERDDAP™ znovu načíst soubor údajů.

Není to ideální, ale funguje to.  

• přesnost... Kdy? EDDGrid FromEDDTable reaguje na požadavek uživatele na data, přenáší řádek dat z tabulky odezvy EDDTable do tabulky EDDGrid reakční síť. Aby to bylo možné, musí zjistit, zda hodnoty "osy" v daném řádku tabulky odpovídají kombinaci hodnot osy v mřížkě. Pro celé datové typy je snadné určit, zda jsou dvě hodnoty stejné. Ale pro plováky a dvojité, to přináší hrozný problém plovoucí bod čísla přesně neodpovídá . (například 0,2 versus 0.199999999999996) . Do (pokusit se) Vypořádej se s tím. EDDGrid FromTable umožňuje určit atribut přesnosti pro některý z axisVariable s, který určuje celkový počet desetinných čísel, které musí být totožné.
  • Například,<att name="precision" type="int [51]5</att >
  • Pro různé typy datových proměnných existují různé výchozí přesné hodnoty. Výchozí hodnoty jsou obvykle vhodné. Pokud nejsou, musíte určit různé hodnoty.
  • Pro axisVariable , které jsou čas nebo čas Proměnné známky , výchozí je plná přesnost (přesná shoda) .
  • Pro axisVariable s, které jsou plováky, výchozí přesnost je 5.
  • Pro axisVariable s, které jsou dvojité, výchozí přesnost je 9.
  • Pro axisVariable s, které mají celé datové typy, EDDGrid FromEDDTable ignoruje přesný atribut a vždy používá plnou přesnost (přesná shoda) .  
  • Varování! Při konverzi kusu tabulárních dat na kus mřížkovaných dat, pokud EDDGrid FromEDDTable nemůže shodovat hodnotu "osy" eddTable s jednou z očekávaných EDDGrid hodnoty osy EDDTable, EDDGrid OdEDDTable tiše (žádná chyba) vyhodí data z této řádky tabulky. Například mohou existovat jiné údaje (není na síti) v souboru EDDTable. (A pokud krok > 1, není zřejmé, že EDDGrid OdTable, které hodnoty osy jsou požadované hodnoty a které jsou ty, které mají být přeskočeny kvůli kroku.) Takže pokud jsou přesné hodnoty příliš vysoké, uživatel uvidí chybějící hodnoty v odezvě na data, pokud skutečně existují platné hodnoty dat.

Naopak, pokud jsou hodnoty přesnosti nastaveny příliš nízko, hodnoty "osy" eddTable, které by neměly odpovídat EDDGrid Od EDDTable hodnoty osy budou (chybně) shoda.

Tyto potenciální problémy jsou hrozné, protože uživatel dostane špatná data (nebo chybějící hodnoty) kdy by měli získat správné údaje (nebo alespoň chybová zpráva) . Tohle není chyba. EDDGrid Z tabulky. EDDGrid FromTable tento problém nevyřeší. Problém spočívá v převodu tabulkových dat na roštovaná data (Ledaže by bylo možné učinit jiné předpoklady, ale tady je udělat nelze.) . Je to na tobě. ERDDAP™ správce Vyzkoušejte si EDDGrid OdEDDTable důkladně zajistit, aby byly stanoveny přesné hodnoty, aby se zabránilo těmto potenciálním problémům.

gapThreshold

• gapThreshold -- Toto je velmi neobvyklý typ datového souboru. Vzhledem k tomu, typy dotazů, které mohou být provedeny na (Vyřešeno) a EDDGrid Soubor údajů (v souvislosti s rozsahy a kroky axisVariable án) jsou velmi odlišné od typů dotazů, které mohou být provedeny na (Vyřešeno) soubor údajů EDDTable (jen souvisí s rozsahy některých proměnných) , výkon EDDGrid Z údajů EDDTable se budou značně lišit v závislosti na přesné žádosti, která je podána, a rychlosti základního souboru EDDTable. Pro žádosti, které mají postupnou hodnotu > 1, EDDGrid FromEDDTable může požádat o poměrně velký kus dat o podkladovém EDDTable (jako kdyby stride=1) a pak prosévat výsledky, uchovávat data z některých řádků a vyhazovat data od ostatních. Pokud bude muset prosít hodně dat, aby získal data, která potřebuje, bude žádost trvat déle.

Pokud EDDGrid OdEDDTable může říci, že tam budou velké mezery (s řádky nežádoucích údajů) mezi řádky s požadovanými údaji, EDDGrid FromEDDTable se může rozhodnout, že provede několik dílčích žádostí k podkladovému EDDTable namísto jedné velké žádosti, čímž přeskočí nežádoucí řádky dat ve velkých mezerách. Citlivost pro toto rozhodnutí je kontrolována mezerouThreshold hodnota, jak je uvedeno v<gapThreshold> tag (výchozí=1000 řádků zdrojových dat) . Nastavení mezeryThreshold na menší číslo povede k vytvoření datového souboru (obecně) Další žádosti. Nastavení mezeryThreshold k většímu počtu povede k vytvoření datového souboru (obecně) Méně žádostí.

Pokud je mezeraThreshold nastavena příliš malá, EDDGrid FromEDDTable bude fungovat pomaleji, protože nadmořská výška více požadavků bude větší než čas uložený získáním některých přebytečných dat. Je-li mezeraThreshold je nastaven příliš velký, EDDGrid FromEDDTable bude fungovat pomaleji, protože z EDDTable budou vyčerpána tolik přebytečných dat, jen aby byla vyřazena. (Jak Goldilocks objevil, uprostřed je "právě.") Nadmořská výška pro různé typy datových souborů EDDTable se značně liší, takže jediný způsob, jak znát aktuální nejlepší nastavení vašeho datového souboru, je prostřednictvím experimentování. Ale nezajdeš příliš daleko, když se budeš držet výchozí hodnoty.

Jednoduchý příklad je: Představte si EDDGrid OdTable pouze s jedním axisVariable (čas, o velikosti 100000) , jedna dataVariable (teplota) , a výchozí mezeraThreshold 1000.

• Pokud uživatel požaduje teplotu \[ 0💯5000 \] , krok je 100, takže velikost mezery je 99, což je méně než mezeraThreshold. Takže... EDDGrid OdTable bude pouze jeden požadavek na EDDTable pro všechny údaje potřebné pro žádost (odpovídá teplotě \[ 0:5000 \] ) a zahodit všechny řádky dat, které nepotřebuje.
• Pokud uživatel požaduje teplotu \[ 0:2500:5000 \] , že krok je 2500 takže velikost mezery je 2499, což je větší než mezeraThreshold. Takže... EDDGrid FromTable bude podávat samostatné požadavky na EDDTable, které odpovídají teplotě \[ 0 \] , teplota \[ 2500 \] , teplota \[ 5000 \] .

Výpočet velikosti mezery je složitější, pokud existuje více os.

Pro každou žádost uživatele: EDDGrid FromEDDTable tiskne diagnostické zprávy související s tímto v log.txt Složka.

• Pokud [<LogLevel >] (#loglevel) v datasets.xml je nastaven na info, to vytiskne zprávu jako \* nOuterAxes=1 of 4 nOuterRequests=22 Pokud nOuterAxes=0, gapThreshold nebyl překročen a pouze jedna žádost bude podána do EDDTable. Pokud nOuterAxes>0, gapThreshold byl překročen a nOuterRequests budou provedeny do EDDTable, což odpovídá každé požadované kombinaci nejlevějších nOuterAxes. Například pokud má datový soubor 4 axisVariable s a dataVariable Jako na východ. \[ čas \] \[ zeměpisná šířka \] \[ zeměpisná délka \] \[ hloubka \] , nejlevější (první) Osová proměnná je čas.
• Pokud<logLevel > v datasets.xml je nastaven na všechny, další informace jsou zapsány do log.txt souboru.  

EDDGrid Z EDDTable kostry XML

 <dataset type="EDDGridFromEDDTable" datasetID\="..." active\="..." >
    <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
    <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
    <accessibleViaWMS>...</accessibleViaWMS> <!-- 0 or 1 -->
    <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
    <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1.
     For EDDGridFromEDDTable, this only works if the underlying EDDTable
     supports updateEveryNMillis. -->
    <gapThreshold>...</gapThreshold> <!-- 0 or 1. The default is 1000. >
    <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
    <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
    <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
    <iso19115File>...</iso19115File> <!-- 0 or 1 -->
    <onChange>...</onChange> <!-- 0 or more -->
    <addAttributes>...</addAttributes> <!-- 0 or 1 -->
    <axisVariable>...</axisVariable> <!-- 1 or more -->
    <dataVariable>...</dataVariable> <!-- 1 or more -->
    <dataset>...</dataset> <!-- The underlying source EDDTable dataset. -->
 </dataset>

EDD* from ERDDAP

** EDDGrid FromErddap** zvládá mřížkovaná data ze vzdáleného ERDDAP™ server. EDDTableFromErddap zpracovává tabulková data ze vzdáleného ERDDAP™ server.

• EDDGrid FromErddap a EDDTableFromErddap se chovají odlišně od všech ostatních typů souborů dat v ERDDAP .
• Stejně jako ostatní typy souborů dat, i tyto soubory dat získávají informace o datovém souboru ze zdroje a uchovávají jej v paměti.
• Stejně jako jiné typy souborů údajů, když ERDDAP™ vyhledávání souborů dat, zobrazení formuláře pro přístup k datům ( * datasetID * .html) , nebo zobrazí formulář Make A Graph ( * datasetID * .graph) , ERDDAP™ používá informace o datovém souboru, který je v paměti.
• EDDGrid OdErddap a EDDTable FromErddap jsou základem pro mřížky/klastry/federace z ERDDAP s, která efektivně distribuuje využití procesoru (převážně pro vytváření map) , využití paměti, ukládání dat a využití pásma velkého datového centra.

Přesměrování

• Na rozdíl od jiných typů souborů údajů, kdy ERDDAP™ přijímá žádost o údaje nebo obrázky z těchto souborů údajů, ERDDAP přesměrování požadavek na ovladač ERDDAP™ server. Výsledkem je:
  • Tohle je velmi efektivní. (CPU, paměť a šířka pásma) , protože jinak
    1. Kompozit ERDDAP™ musí zaslat žádost druhé osobě ERDDAP™ (Což zabere čas.) .
    2. Druhý ERDDAP™ musí získat data, přeformátovat je a předat data kompozitu. ERDDAP .
    3. Kompozit ERDDAP™ musí přijímat údaje (pomocí šířky pásma) , přeformátovat ji (pomocí procesoru a paměti) , a předat data uživateli (pomocí šířky pásma) . Přesměrováním žádosti a umožněním druhé ERDDAP™ zaslat odpověď přímo uživateli, složenému ERDDAP™ V podstatě netráví čas, paměť nebo šířku pásma na žádost.
  • Přesměrování je transparentní pro uživatele bez ohledu na klientský software (prohlížeč nebo jiný software nebo nástroj příkazového řádku) .
• You can tell ERDDAP™ nepřesměrovat žádné uživatelské požadavky nastavením<přesměrování>false</redirect>, ale to neguje většinu výhod datového souboru ...FromErddap (zejména rozptyl zatížení na předním konci ERDDAP™ na vzdálený/zádaj ERDDAP ) .    

Předplatné

Normálně, když EDDGrid OdErddap a EDDTable OdErddap jsou (re) nabitý na vašem ERDDAP , se snaží přidat předplatné do vzdáleného datového souboru prostřednictvím vzdáleného ERDDAP 's e-mailem / URL předplatné systém. Tak, kdykoli se vzdálený soubor změní, je vzdálený ERDDAP™ kontaktujte setDataset URL vlajky na Vašem ERDDAP™ tak, aby byl místní datový soubor znovu načten ASAP a aby byl místní datový soubor vždy dokonale aktualizován a napodoboval vzdálený datový soubor. Takže, když se to stane poprvé, měli byste dostat e-mail, který požaduje, abyste potvrdili předplatné. Nicméně, pokud místní ERDDAP™ nelze poslat e-mail nebo pokud ovladač ERDDAP 's e-mailem / URL předplatné systém není aktivní, měli byste e-mailem vzdálené ERDDAP™ správce a požádat, aby s/he ručně přidat [<oZměnit>] (#Změnit) ...</onChange> značky na všechny příslušné soubory dat volat soubor dat setDataset URL vlajky . Podívejte se. ERDDAP™ denní report pro seznam setuDataset Vlajka URL, ale jen poslat ty pro EDDGrid FromErddap a EDDTableFromErddap soubory do vzdáleného ERDDAP™ Správce.

Nefunguje to? Nezůstávají vaše lokální data v synchronizaci se vzdálenými soubory dat? Několik věcí musí fungovat správně, aby tento systém fungoval tak, aby vaše datové soubory zůstaly aktuální. Zkontrolujte každou z těchto věcí v pořadí:

1. Vaše ERDDAP™ musí být schopen odesílat e-maily. Viz nastavení e-mailu ve vašem nastavení.xml.
2. Obecně (ale ne vždy) , vaše ERDDAP 's<baseUrl> a<baseHttpsUrl > nesmí mít číslo portu (např.: 8080, :8443) . Pokud ano, použijte proxypass k odstranění přístavu z Urlu.
3. Ve vašem nastavení.<screenToRemoteErddapDataset> musí být nastaven na true.
4. Když váš místní EDD... FromErddap soubor je znovu načten, měl by poslat žádost na vzdálený ERDDAP™ k odběru vzdáleného datového souboru. Podívejte se do log.txt, jestli se to děje.
5. Měli byste dostat e-mail a požádat vás o potvrzení žádosti o předplatné.
6. Musíte kliknout na odkaz v tomto e-mailu potvrdit žádost o předplatné.
7. Ovladač ERDDAP™ by měl říci, že potvrzení bylo úspěšné. Kdykoli si můžete vyžádat e-mail ze vzdáleného ERDDAP™ se seznamem vašich předplatných. Viz formulář na vzdálenýErddapBase Url /erddap/subscriptions/list.html .
8. Při změně vzdáleného souboru dat (např. získá další údaje) , ovladač ERDDAP™ zkuste kontaktovat vlajku URL na vašem ERDDAP . Nemůžete to zkontrolovat, ale můžete se zeptat správce ovladače. ERDDAP™ Zkontrolovat tohle.
9. Vaše ERDDAP™ musí obdržet žádost o stanovení této vlajkyURL. Podívejte se do svého log.txt pro "nastavitDatasetFlag.txt?" požadavek (án) a zjistěte, zda existuje chybová zpráva spojená s požadavky.
10. Vaše ERDDAP™ pak by se měl pokusit znovu načíst soubor (Možná ne hned, ale ASAP) .  

Aktuální max (čas) ?

EDDGrid /TableFromErddap soubory dat mění své uložené informace o každém zdrojovém souboru pouze tehdy, když zdrojový soubor je "reloaded"ed a některé změny metadat (např. časová proměnná actual\_range ) , čímž vzniká oznámení o předplatném. Pokud má zdrojový soubor data, která se často mění (například nová data každou sekundu) a používá "aktualizace" systém pro zjištění častých změn základních údajů, EDDGrid /TableFromErddap nebude informován o těchto častých změnách až do dalšího souboru souborů "načíst," takže EDDGrid /TableFromErddap nebude dokonale aktuální. Tento problém lze minimalizovat změnou zdrojového souboru<reloadEveryNMinutes > na menší hodnotu (60, 15?) takže existuje více oznámení o předplatném říct EDDGrid /TableFromErddap aktualizovat své informace o zdrojovém souboru.

Nebo pokud váš systém správy dat ví, kdy má zdrojový soubor nová data (např. prostřednictvím skriptu, který kopíruje datový soubor na místo) , a pokud to není super časté (např. každých 5 minut nebo méně často) Existuje lepší řešení:

1. Nepoužívejte<updateEveryNMillis> za účelem aktualizace zdrojového souboru.
2. Nastavit zdrojový soubor<reloadEveryNMinutes > na větší číslo (1440?) .
3. Ať skript kontaktuje zdrojový soubor URL vlajky Hned poté, co kopíruje nový datový soubor.  

To povede k tomu, že zdrojový soubor bude dokonale aktualizován a způsobí, že vytvoří oznámení o předplatném, které bude zasláno EDDGrid /TableFromErddap data data. To povede EDDGrid /TableFromErddap database to be perfectly up-to-date (No, do 5 sekund po přidání nových údajů) . A vše, co bude provedeno efektivně (bez zbytečného opětovného načítání dat) .  

Ne. addAttributes , axisVariable nebo dataVariable

Na rozdíl od jiných typů souborů dat, EDDTableFromErddap a EDDGrid OdErddap soubory neumožňují globální<addAttributes>,< axisVariable > nebo< dataVariable > sekce datasets.xml pro tento datový soubor. Problém je v tom, že to by vedlo k nesrovnalosti:

1. Řekněme, že to bylo povoleno a vy jste přidal nový globální atribut.
2. Když se uživatel zeptá ERDDAP™ pro globální atributy se objeví nový atribut.
3. Ale když se uživatel zeptá ERDDAP™ pro datový soubor, Váš ERDDAP™ přesměruje žádost na zdroj ERDDAP . To ERDDAP™ neví o novém atributu. Pokud tedy vytvoří datový soubor s metadaty, např. .nc Soubor, metadata nebudou mít nový atribut.

Existují dvě pracovní skupiny:

1. Přesvědčit správce zdroje ERDDAP™ provést změny, které chcete k metadatům.
2. Místo eddtableFromErddap použijte EDDTableFromDapSekvence . Nebo místo EDDGrid FromErddap, use EDDGrid FromDap . Tyto typy EDD vám umožní efektivně se připojit k datovému souboru na vzdáleném ERDDAP™ (ale bez přesměrování požadavků na údaje) a umožňují vám zahrnout globální<addAttributes>,< axisVariable > nebo< dataVariable > sekce datasets.xml . Další rozdíl: budete se muset ručně přihlásit ke vzdálenému datovému souboru, aby soubor dat na vašem ERDDAP™ bude oznámeno (prostřednictvím URL vlajky ) pokud dojde ke změnám vzdáleného datového souboru. Vytváříte tedy nový datový soubor namísto propojení se vzdáleným datovým souborem.  

Ostatní poznámky

• Z bezpečnostních důvodů EDDGrid OdErddap a EDDTable FromErddap nepodporuje [<accessTo>] (#přístupný) tag a nemůže být použit se vzdálenými soubory dat, které vyžadují přihlášení (protože používají [<accessTo>] (#přístupný) )... Viz ERDDAP 's bezpečnostní systém za omezení přístupu k některým datům pro některé uživatele.  
• Začneme s ERDDAP™ v2.10, EDDGrid FromErddap a EddtableFromErddap podporu [<dostupnéViaFiles>] (#Accessibleviafiles) Tagu. Na rozdíl od jiných typů souborů dat je výchozí hodnota pravdivá, ale soubory datového souboru budou přístupnéViaFiles pouze v případě, že zdrojový soubor má také<přístupnéViaFiles> nastaveno na true.  
• Můžete použít Generovat soubory dat Xml program k vytvoření datasets.xml kus pro tento typ datového souboru. Ale tyto typy dat můžete provádět snadno ručně.  

EDDGrid Od kostry Erddap XML

• EDDGrid Od kostry Erddap XML datový soubor je velmi jednoduchý, protože záměrem je pouze napodobit vzdálený datový soubor, který je již vhodný pro použití v ERDDAP :

  <dataset type="EDDGridFromErddap" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <accessibleViaFiles>...</accessibleViaFiles> <!-- 0 or 1, default=true. -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1
        For EDDGridFromErddap, this gets the remote .dds and then gets
        the new leftmost (first) dimension values. -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <dimensionValuesInMemory>...</dimensionValuesInMemory> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <redirect>true(default)|false</redirect> <!-- 0 or 1; -->
  </dataset>

EDDTableFromErddap kostra XML

• Kostra XML pro soubor EDDTableFromErddap je velmi jednoduchá, protože záměrem je pouze napodobit vzdálený soubor dat, který je již vhodný pro použití v ERDDAP :

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

EDDGrid OdEtopa

** EDDGrid OdEtopa** Jen slouží ETOPO1 Global 1-Minute Gridd (Ice Surface, mřížka registrovaná, binární, 2byte int: etopo1\_ice\_g\_i2 .zip ) který je distribuován s ERDDAP .

• Jen dva. datasetID jsou podporovány pro EDDGrid FromEtopo, takže můžete přistupovat k datům s hodnotami délky -180 až 180, nebo k hodnotám délky 0 až 360.
• Nikdy nejsou žádné subtagy, protože data jsou již popsána v rámci ERDDAP .
• Takže dvě možnosti pro EDDGrid Z Etopo souborů jsou (Doslova) :

      <!-- 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 FromFiles

** EDDGrid FromFiles** je supertřída všech EDDGrid Z... tříd. Nemůžeš použít EDDGrid Z Files přímo. Místo toho použijte podtřídu EDDGrid OdFiles pro zpracování konkrétního typu souboru:

• EDDGrid Z MergeIRFiles zpracovává data z mřížky MergeIR .gz Složky.
• EDDGrid FromAudioFiles shromažďuje data ze skupiny místních audio souborů.
• EDDGrid FromNcFiles zpracovává data z mřížky GRIB .grb soubory, HDF (v4 nebo v5) .hdf soubory, .nc ml soubory a NetCDF (V3 nebo v4) .nc Složky. To může fungovat s jinými typy souborů (například BUFR) Jen jsme to neotestovali. Prosím, pošlete nám nějaké vzorky, pokud máte zájem.
• EDDGrid FromNcFilesUnpacked je varianta EDDGrid FromNcFiles, které zpracovává data z mřížky NetCDF (V3 nebo v4) .nc a související soubory, které ERDDAP™ Vybaluje na nízké úrovni.

V současné době nejsou podporovány žádné jiné typy souborů. Obvykle je však poměrně snadné přidat podporu pro jiné typy souborů. Kontaktujte nás, pokud máte požadavek. Nebo, pokud jsou vaše data ve starém formátu, ze kterého byste se chtěli odstěhovat, doporučujeme převést soubory, které mají být NetCDF v3 .nc Složky. NetCDF je široce podporovaný binární formát, umožňuje rychlý náhodný přístup k datům a je již podporován ERDDAP .

Z detailů souborů

Následující informace se vztahují na všechny podtřídy EDDGrid Z Files.

Agregace stávajícího rozměru

Všechny varianty EDDGrid FromFiles mohou hromadit data z místních souborů, kde každý soubor má 1 (nebo více) různé hodnoty pro nejlevější (první) rozměr, obvykle \[ čas \] , které budou shrnuty. Například, rozměry mohou být \[ čas \] \[ výška \] \[ zeměpisná šířka \] \[ zeměpisná délka \] , a soubory mohou mít data pro jednoho (nebo pár) časová hodnota (án) na soubor. Výsledný datový soubor se jeví jako by všechny údaje souboru byly kombinovány. Velké výhody agregace jsou:

• Velikost souhrnné datové sady může být mnohem větší než jeden soubor může být pohodlně (~2GB) .
• Pro téměř aktuální data je snadné přidat nový soubor s nejnovějším souborem dat. Nemusíš přepisovat celý soubor.

Požadavky na agregaci jsou:

• Místní složky nemusí mít stejné. dataVariable án (podle definice v datovém souboru datasets.xml ) . Databáze bude mít dataVariable s definovaná v datasets.xml . Pokud daný soubor nemá daný dataVariable , ERDDAP™ přidá chybějící hodnoty podle potřeby.
• Všechny dataVariable s axisVariable s/rozměry (podle definice v datovém souboru datasets.xml ) . Soubory budou shrnuty na základě prvního (nejvíce vlevo) rozměr, tříděný vzestupně.
• Každý soubor MŮŽE mít data pro jednu nebo více hodnot prvního rozměru, ale mezi soubory nemůže být žádné překrytí. Pokud má soubor více než jednu hodnotu pro první rozměr, hodnoty MUSÍ být tříděny vzestupně, bez vazeb.
• Všechny soubory musí mít přesně stejné hodnoty pro všechny ostatní rozměry. Přesnost zkoušky určuje zápasAxisNDigits .
• Všechny soubory musí mít úplně stejné. jednotky metadata pro všechny axisVariable s a dataVariable s. Pokud je problém, můžete být schopni použít NcML nebo NCO Napravit problém.  

Agregace prostřednictvím názvů souborů nebo globálních metadat

Všechny varianty EDDGrid FromFiles může také agregovat skupinu souborů přidáním nového levičáku (první) rozměr, obvykle čas, na základě hodnoty odvozené z každého názvu souboru nebo z hodnoty globálního atributu, který je v každém souboru. Například název souboru může obsahovat časovou hodnotu dat v souboru. ERDDAP™ pak vytvoří novou časovou dimenzi.

Na rozdíl od podobné funkce v THREDDS, ERDDAP™ vždy vytvoří axisVariable s číselnými hodnotami (podle požadavků CF) , nikdy String hodnoty (které nejsou povoleny CF) . Také, ERDDAP™ bude třídit soubory v agregace na základě číselné axisVariable hodnota, která je přiřazena každému souboru, takže proměnná osy bude mít vždy tříděné hodnoty, jak požaduje CF. Přístup THREDDS k provedení lexikografického typu na základě názvů souborů vede k agregace, kde hodnoty osy nejsou tříděny (který není povolen CF) pokud názvy souborů třídí jinak než odvozená axisVariable hodnoty.

Nastavit jednu z těchto agregace v ERDDAP™ , budete definovat nový levý nejvíce (první) axisVariable se speciálním pseudo< sourceName >, který říká ERDDAP™ kde a jak najít hodnotu nového rozměru z každého souboru.

• Formát pseudo sourceName která získává hodnotu z názvu souboru (jen filename.ext) je \\\ název souboru, údaje Typ , extraktRegex , ZachytitSkupinovéČíslo*
• Formát pseudo sourceName která získá hodnotu z absolutního jména cesty souboru je \\\ název cesty, údaje Typ , extraktRegex , ZachytitSkupinovéČíslo* \[ Pro to, název cesty vždy používá '/' jako znak oddělovače adresáře, nikdy '\'. \]
• Formát pseudo sourceName který získává hodnotu z globálního atributu je \\\ globální: atribut Název , údaje Typ , extraktRegex , ZachytitSkupinovéČíslo*
• Tento pseudo sourceName volba funguje jinak než ostatní: místo vytvoření nového levičáku (první) axisVariable , to nahrazuje hodnotu proudu axisVariable s hodnotou získanou z názvu souboru (jen filename.ext) . Formát je \\\ nahradit FromFileName, údaje Typ , extraktRegex , ZachytitSkupinovéČíslo*  

Popisy částí, které potřebujete poskytnout, jsou:

• atribut Název -- název globálního atributu, který je v každém souboru a který obsahuje rozměrovou hodnotu.
• údaje Typ -- To určuje datový typ, který bude použit k ukládání hodnot. Viz standardní seznam údaje Typy že ERDDAP™ podporuje, kromě toho, že String zde není povolen, protože proměnné osy v ERDDAP™ nemůže být String proměnné.

Existuje další pseudodataType, timeFormat= řetězec TimeFormat , který říká ERDDAP™ že hodnota je String timeStamp jednotky vhodné pro časy strun . Ve většině případů, stringTimeFormat budete potřebovat bude změna jednoho z těchto formátů:

• yyyy-MM-dd "T'HH:mm:ss.SSSZ -- která ISO 8601:2004 (E) formát času data. Možná budete potřebovat zkrácenou verzi, např. yyyy-MM-dd T'HH:mm:ss nebo yyyy-MM-dd .
• rrrrMMddHHmmss.SSS -- což je kompaktní verze formátu data ISO 8601. Můžete potřebovat zkrácenou verzi, např. rrrrMMddHHmmss nebo rrrrMMdd.
• M/d/rrrr H:mm:ss.SSS -- což je U.S. slash datum formátu. Můžete potřebovat zkrácenou verzi, např. M/d/rrrr .
• rrrrDDDHmmssSSS -- což je rok plus nula-polstrovaný den roku (např. 001 = 1. leden 365 = 31. prosinec v nelegálním roce; to je někdy chybně nazýváno Julian datum) . Můžete potřebovat zkrácenou verzi tohoto, např. rrrrDDD .

Pokud použijete tento pseudo dataType, přidejte to do nové proměnné< addAttributes >:

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

Pokud chcete posunout všechny časové hodnoty, posuňte časovou hodnotu v jednotkách, např. 1970-01-01T12:00:00Z.

• extraktRegex -- Tohle je regulární výraz ( tutoriál ) která zahrnuje skupinu zachytávání (v závorce) který popisuje, jak extrahovat hodnotu z názvu souboru nebo globální hodnoty atributu. Například název souboru jako S19980011998031.L3b\_MO\_CHL .nc , zachytit skupinu #1, "\ \dtutoriál "v pravidelném výrazu S (\ \dtutoriál ) \ \dtutoriál \.L3b.\* zachytí prvních 7 číslic za 'S': 1998001.
• Comment -- Tohle je číslo zachycené skupiny. (v závorce) v pravidelném vyjádření, které obsahuje informace o zájmu. Obvykle je to 1, první skupina. Někdy je třeba použít zachycení skupin pro jiné účely v regexu, takže důležité zachycení skupiny číslo bude 2 (druhá skupina zajetí) nebo 3 (třetí) , atd.

Plný příklad axisVariable což činí souhrnný datový soubor s novou časovou osou, která získá časové hodnoty z názvu souboru každého souboru je

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

Když používáte "timeFormat=" pseudo data Typ, ERDDAP™ přidá 2 atributy do axisVariable takže se zdá, že pocházejí ze zdroje:

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

Takže v tomto případě, ERDDAP™ vytvoří novou osu pojmenovanou "time" s dvojitými hodnotami (sekundy od 1970-01-01T00:00:00Z) extrahováním 7 číslic za 'S' a před ".L3m" v názvu souboru a výkladem hodnot jako časových hodnot formátovaných jako rrrrDDD.

Můžete přepsat výchozí základní čas (1970-01-01T00:00:00Z) přidáním addAttribut který určuje jiný atribut jednotek s jiným základním časem. Běžná situace je: existují skupiny datových souborů, každý s jedním dnem složené ze satelitního datového souboru, kde chcete, aby čas hodnota být poledne dne uvedený v názvu souboru (středový čas každého dne) a chtějí proměnnou long\_name být "Centered Time." Příkladem je:

      <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>

Note hours=12 in the base time, which adds 12 hours related to the original base time of 1970-01-01T00:00:00Z.

Plný příklad axisVariable což činí souhrnný soubor údajů s novou "běh" osou (s int hodnotami) který získává spuštěné hodnoty z globálního atributu "runID" v každém souboru (s hodnotami jako "r17\_globální," kde 17 je číslo spuštění) je

      <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>

Všimněte si, že skupina zachytit číslo 2 zachytit číslice, které se vyskytují po 'r' nebo 's', a před "\_globální'. Tento příklad také ukazuje, jak přidat další atributy (např. ioos\_category a jednotky) k proměnné osy.  

Vnější komprimované soubory

• Datové soubory, které jsou podskupinami EDDGrid FromFiles a EDDTable FromFiles mohou sloužit data přímo z externě komprimovaných datových souborů, včetně .tgz , .tar .gz , .tar .gzip , .gz , .gzip , .zip , .bz2 , a .Z soubory.  

• To funguje překvapivě dobře!
  Ve většině případů je zpomalení spojené s dekompresí malých a středních datových souborů menší. Pokud potřebujete ušetřit místo na disku, důrazně podporujeme použití této funkce, zejména pro starší soubory, které jsou zřídka přístupné.  

• Šetřete peníze!
  To je jeden z mála funkcí v ERDDAP™ To vám nabízí šanci ušetřit spoustu peněz (i když za cenu mírně sníženého výkonu) . Pokud je kompresní poměr např. 6:1 (Někdy to bude mnohem vyšší.) , pak datové soubory souboru budou potřebovat pouze 1/6 prostor disku. Pak možná dokážeš zvládnout 1 RAID (o dané velikosti) místo 6 RAIDS (o stejné velikosti) . To jsou obrovské úspory nákladů. Doufejme, že schopnost komprimovat některé soubory ve sbírce (Ty starší?) a nestlačit ostatní (Ty novější?) , A změnit to kdykoliv, pojďme minimalizovat nevýhody komprimovat některé ze souborů (pomalejší přístup) . A pokud je volba mezi uložením souborů na pásku (a přístupné pouze na požádání, po prodlení) vs uložení komprimované na RAID (a přístupné prostřednictvím ERDDAP ) , pak je obrovská výhoda pro použití komprese tak, aby uživatelé dostat interaktivní a (relativně) rychlý přístup k datům. A pokud vám to může ušetřit od zakoupení dalšího RAIDu, může vám tato funkce ušetřit asi 30 000 dolarů.  

• Pro všechny EDDGrid Podtřídy FromFiles, pokud mají datové soubory rozšíření, které naznačuje, že jsou externě komprimované soubory (v současné době: .tgz , .tar .gz , .tar .gzip , .gz , .gzip , .zip , .bz2 nebo .Z) , ERDDAP™ dekompresní soubory do adresáře cache datového souboru, když je čte (pokud už nejsou v cache) . Totéž platí pro binární soubor (např. .nc ) podtřídy EDDTableFromFoles.  

• Pro podtřídy EDDTableFromFoles pro nebinární soubory (např. .csv) , datové soubory s příponou naznačující, že jsou externě komprimované soubory budou dekompresovány při čtení souboru.  

• POŽADAVEK: Pokud je použit typ externího komprimovaného souboru (např. .tgz nebo .zip ) podporuje více než 1 soubor uvnitř komprimovaného souboru, komprimovaný soubor musí obsahovat pouze 1 soubor.  

• REQUIREMENT: Tato funkce předpokládá, že obsah externě komprimovaných souborů se nemění, takže může být znovu použit dekomprimovaný soubor. Pokud jsou některé nebo všechny datové soubory datového souboru někdy změněny, neshrňte tyto soubory. To odpovídá běžnému používání, protože lidé obvykle nestlačí soubory, které někdy potřebují změnit.  

• <souborNázevRegex> Aby to fungovalo, data jsou<souborNameRegex> musí odpovídat jménům komprimovaných souborů. Očividně, regexy jako .\bude odpovídat všem jménům souborů. Pokud zadáte specifický typ souboru, např. .\\ .nc , pak je třeba upravit regex tak, aby zahrnovala i kompresní rozšíření, např., .\ \ .nc \ .gz (pokud všechny soubory budou Něco * .nc .gz Soubory) .  

• Je v pořádku, pokud váš datový soubor obsahuje kombinaci komprimovaných a ne komprimovaných souborů. To může být užitečné, pokud věříte, že některé soubory (např. starší soubory) bude používán méně často, a proto by bylo užitečné ušetřit prostor na disku stlačením. Aby to fungovalo,<fileNameRegex> se musí shodovat s názvy komprimovaných a nestlačených souborů, např. .\nebo .\\ .nc ( | \ .gz ) (pokud skupina zachycuje na konci této skupiny stanoví, že .gz je volitelné.  

• Je v pořádku, pokud komprimujete nebo dekompresujete konkrétní soubory ve sbírce kdykoliv. Pokud soubor údajů nepoužívá [<updateEveryNMillis>] (#update everynmillis) , nastavit soubor údajů vlajka říct ERDDAP™ znovu načíst datový soubor a tím si všimnout změn. Zajímavé je, že můžete použít různé kompresní algoritmy a nastavení pro různé soubory ve stejném souboru (např. .bz2 pro zřídka používané soubory, .gz pro často nepoužité soubory a bez komprese pro často používané soubory) , Ujistěte se, že regex podporuje všechny použité přípony souboru, např. .\*\ .nc ( | \ .gz | \ .bz2 ) .  

• Kompresní poměry a rychlosti pro různé kompresní algoritmy se samozřejmě liší podle zdrojového souboru a nastavení (např. úroveň stlačení) . Pokud chcete optimalizovat tento systém pro vaše soubory, proveďte test různých kompresních metod s vašimi soubory a s celou řadou nastavení komprese. Pokud chcete spolehlivě dobré (nemusí být nutně nejlepší) nastavení, budeme mírně doporučit gzip ( .gz ) . gzip nedělá nejmenší komprimovaný soubor (Je to dost blízko.) , ale komprimuje soubor velmi rychle a (důležitější pro ERDDAP™ uživatelé) Rozkládá soubor velmi rychle. Navíc, gzip software přichází standardně s každou instalací Linux a Mac OS a je snadno dostupný pro Windows prostřednictvím bezplatných nástrojů, jako jsou 7Zip a Linux doplňky jako Git Bash. Například pro stlačení zdrojového souboru do .gz verze souboru (stejný název souboru, ale s .gz Přiložené) , použití (v Linuxu, Mac OS a Git Bash)
  gzip * sourceName *
  Dekompresní a .gz soubor zpět k originálu, použijte gunzip * sourceName .gz *
  Chcete-li komprimovat každý ze zdrojových souborů v adresáři a jeho podadresáře, rekurzivně, použijte gzip - R režisér Název
  Dekompresní každý z .gz soubory v adresáři a jeho podadresáře , rekurzivně , použití gunzip - r režisér Název
   

• UPOZORNĚNÍ: Nekomprimujte vnější tlak ( gzip ) Soubory, které jsou již interně komprimované! Mnoho souborů již má komprimovaná data interně. Jestliže gzip Tyto soubory, výsledné soubory nebudou o moc menší (<5%) a ERDDAP™ bude ztrácet čas dekompresí je, když je potřebuje přečíst. Například:

  • datové soubory: např. .nc 4 a .hdf 5 souborů: Některé soubory používají vnitřní komprese, některé ne. Jak říct: komprimované proměnné mají atributy "\_Chunksize." Také, pokud skupina roštů .nc nebo .hdf Soubory jsou různé velikosti, jsou pravděpodobně vnitřně komprimované. Pokud jsou všechny stejné velikosti, nejsou vnitřně stlačené.
  • Soubory obrázků: např. .gif, .jpg a .png
  • audio soubory: např. .mp3 a .ogg.
  • video soubory: např. .mp4, .ogv, a .webm.

Jeden nešťastný případ: .wav audio soubory jsou obrovské a nejsou vnitřně komprimované. Bylo by hezké stlačit ( gzip ) Oni, ale obecně byste neměli, protože pokud ano, uživatelé nebudou schopni přehrávat komprimované soubory ve svém prohlížeči.  

• Zkušební pouzdro: stlačení (s gzip ) datový soubor s mřížkou 1523 .nc Složky.

  • Údaje ve zdrojových souborech byly řídké. (mnoho chybějících hodnot) .
  • Celkový diskový prostor šel z 57 GB před kompresí na 7 GB po.
  • Žádost o mnoho údajů z 1 time point je<1 s před a po kompresi.
  • Žádost o 1 datový bod pro 365 časových bodů (nejhorší případ) přešla ze 4 s na 71 s.  

Pro mě je to rozumný kompromis pro jakýkoli soubor údajů a určitě pro soubory údajů, které jsou často používány.  

• Vnitřní versus vnější tlak -- Ve srovnání s interní kompresí souborů nabízených .nc 4 a .hdf 5 souborů, ERDDAP 's přístupem pro externě komprimované binární soubory má výhody a nevýhody. Nevýhodou je: pro jednou přečíst malou část jednoho souboru, vnitřní komprese je lepší, protože EDDGrid FromFiles stačí dekompresovat pár kusů (án) Složka, ne celá složka. Ale... ERDDAP 's přístupem má některé výhody:

  • ERDDAP™ podporuje komprese všech typů datových souborů (binární a non-binář, např. .nc 3 a .csv) nejen .nc 4 a .hdf 4.
  • Pokud většina souboru musí být přečtena více než jednou v krátkém časovém období, pak šetří čas na dekompresi souboru jednou a přečíst jej mnohokrát. To se stává v ERDDAP™ pokud uživatel používá Make-A-Graph pro datový soubor a provede sérii malých změn v grafu.
  • Schopnost mít komprimované soubory a nekomprimované soubory ve stejné kolekci vám umožní více ovládat, které soubory jsou komprimovány a které nejsou. A toto přidané ovládání přichází bez úpravy zdrojového souboru (protože můžete zkomprimovat soubor např. .gz a pak ji dekomprimovat pro získání původního souboru) .
  • Schopnost kdykoli změnit, zda je daný soubor komprimován a jak je komprimován (různé algoritmy a nastavení) dává vám větší kontrolu nad výkonem systému. A původní nestlačený soubor můžete snadno kdykoliv obnovit.

I když ani jeden přístup není vítězem ve všech situacích, je jasné, že ERDDAP 's schopností sloužit datům z externích komprimovaných souborů činí vnější kompresi přiměřenou alternativou k vnitřní komprese nabízené .nc 4 a .hdf 5. To je důležité vzhledem k tomu, že vnitřní komprese je jedním z hlavních důvodů, proč se lidé rozhodnou použít .nc 4 a .hdf 5.  

Dekomprese Cache

ERDDAP™ je dekompresní verze komprimované binární (např. .nc ) datový soubor, když je potřeba soubor přečíst. Dekompresované soubory jsou uloženy v adresáři datového souboru velkýRodič rodičů /dekomprimováno/ . Dekompresované soubory, které nebyly v poslední době použity, budou vymazány, aby uvolnily prostor, když je kumulativní velikost souboru >10GB. Můžete to změnit nastavením<dekomprimovanýCacheMaxGB> (výchozí=10) v souborech údajů Xml.xml, např.

        <decompressedCacheMaxGB>40</decompressedCacheMaxGB>  

Také, dekompresované soubory, které nebyly použity v posledních 15 minutách budou vymazány na začátku každého hlavního souboru reload. Můžete to změnit nastavením<dekompresovanýCacheMaxMinutesOld> (výchozí=15) v souborech údajů Xml.xml, např.

        <decompressedCacheMaxMinutesOld>60</decompressedCacheMaxMinutesOld>  

Větší čísla jsou pěkné, ale kumulativní velikost dekompresních souborů může způsobit velkýRodič rodičů dojít z diskového prostoru, což způsobuje vážné problémy.  

• Protože dekomprese souboru může trvat hodně času. (0,1 až 10 sekund) , soubory souborů s komprimovanými soubory mohou využít nastavení souboru [<nThreads>] (# nitra) nastavení na vyšší číslo (2? 3? 4?) . Nevýhody k ještě vyššímu počtu (Například 5? 6? 7?) snižují výnosy a požadavek jednoho uživatele pak může využít vysoké procento zdrojů systému, čímž výrazně zpomalí zpracování žádostí druhého uživatele. Proto neexistuje žádné ideální nastavení nThreads, jen různé důsledky v různých situacích s různými nastaveními.  

Vytříděné hodnoty rozměrů

Hodnoty pro každý rozměr MUSÍ být v seřazeném pořadí (vzestupně nebo sestupně, kromě prvního (nejvíce vlevo) rozměr, který musí být vzestupný) . Hodnoty mohou být nepravidelně rozloženy. Nemůžou být žádné vazby. To je požadavek Standard metadat CF . Pokud hodnoty jakéhokoli rozměru nejsou v seřazeném pořadí, soubor dat se nenačte a ERDDAP™ určí první netříděnou hodnotu v souboru záznamu, velkýRodič rodičů /logs/log.txt .

Netříděné hodnoty rozměrů téměř vždy indikují problém se zdrojovým souborem. To se nejčastěji vyskytuje, když je do agregace zahrnut chybný nebo nevhodný soubor, což vede k netříděné časové dimenzi. Pro vyřešení tohoto problému viz chybová zpráva v ERDDAP™ log.txt soubor k nalezení urážlivé časové hodnoty. Pak se podívejte do zdrojových souborů najít odpovídající soubor (nebo jeden před nebo jeden po) To nepatří do agregace.

Adresáře

Soubory mohou být v jednom adresáři nebo v adresáři a jeho podadresáři (rekurzivně) . Pokud existuje velký počet souborů (např. > 1 000) , operační systém (a tak EDDGrid FromFiles) bude fungovat mnohem efektivněji, pokud uložíte soubory do řady podadresářů (jeden za rok nebo jeden za měsíc pro soubory údajů s velmi častými soubory) , tak, že nikdy neexistuje obrovské množství souborů v daném adresáři.  

<cacheFromUrl>

Všechny EDDGrid FromFiles a všechny soubory EDDTableFromFoles podporují sadu tagů, které říkají ERDDAP™ stáhnout a udržovat kopii všech souborů vzdáleného datového souboru nebo cache několika souborů (stažen podle potřeby) . Tohle může být neuvěřitelně užitečné. Viz cache FromUrl dokumentace .

Vzdálené adresáře a HTTP požadavky na rozsah

(AKA Byte Servírování, Byte Range Žádosti, Přijmout-Ranges http hlavička)
EDDGrid FromNcFiles, EDDTableFromMultidimNcFiles, EDDTableFromNcFiles, and EDDTableFromNcCFFiles, can Někdy sloužit údaje od .nc soubory na vzdálených serverech a přístupné přes HTTP, pokud server podporuje Byte Slouží přes HTTP požadavky na rozsah (HTTP mechanismus pro bajtové podávání) . To je možné, protože netcdf-java (která ERDDAP™ použití ke čtení .nc soubory) podporuje čtení dat ze vzdáleného .nc soubory přes HTTP požadavky na rozsah.

Nedělej to! Je strašně neefektivní a pomalý. Místo toho použijte [<cacheFromUrl> system] (#Cachefromurl) .

Přístup ERDDAP™ Soubory jako soubory prostřednictvím žádostí o rozsah byte -- Otočím to kolem, vzhledem k tomu, že můžete (teoreticky) Pomyšlení na soubor údajů v ERDDAP™ jako obr .nc soubor započítáním " .nc " na základnu OPen DAP URL pro daný datový soubor (např.https://myserver.org/erddap/griddap/datasetID.nca také přidáním ?query poté, co zadat podmnožinu) , je možná rozumné se zeptat, zda můžete použít netcdf-java, Ferret , nebo jiné NetCDF klientský software pro čtení dat prostřednictvím Žádosti o HTTP rozsah od ERDDAP . Odpověď je ne, protože není opravdu velký " .nc "Složka. Pokud to chcete udělat, udělejte místo toho jednu z těchto možností:

• Použití(OPeN)DAPklientský software pro připojení ke službám Griddap nabízeným ERDDAP . To je ono. DAP (a tak ERDDAP ) byl navržen pro. Je velmi efektivní.
• Nebo stáhnout zdrojový soubor (án) z "files" systém (nebo podmnožina souboru prostřednictvím .nc ? dotaz) do počítače a používat netcdf-java, Ferret , nebo jiné NetCDF klientský software pro čtení (Teď) místní soubor (án) .  

Informace o souboru

Když EDDGrid Databáze FromFiles je nejprve načtena, EDDGrid FromFiles čte informace ze všech příslušných souborů a vytváří tabulky (jeden řádek pro každý soubor) s informacemi o každém platném souboru a každém "špatném" (jiný nebo neplatný) Složka.

• Tabulky jsou také uloženy na disku, jako NetCDF v3 .nc soubory v velkýRodič rodičů /dataset/ last2CharsOfDatasetID / * datasetID * / v souborech pojmenovaných: dirTable .nc (který obsahuje seznam jedinečných názvů adresářů) , soubor Tabulka .nc (která obsahuje tabulku s údaji každého platného souboru) , badFiles .nc (který drží tabulku s informacemi každého špatného souboru) .
• Pro urychlení přístupu k EDDGrid Databáze souborů (ale na úkor využití více paměti) , můžete použít [<souborTableInMemory> true</fileTableInMemory>] (# filetableinmemory) říct ERDDAP™ uchovávat kopii tabulek informací o souboru v paměti.
• Kopie tabulek informací o souboru na disku je také užitečná, když ERDDAP™ je vypnuto a restartováno: ukládá EDDGrid OdFiles z nutnosti znovu přečíst všechny datové soubory.
• Když je soubor dat znovu načten, ERDDAP™ stačí přečíst data v nových souborech a souborech, které se změnily.
• Pokud má soubor jinou strukturu než ostatní soubory (například jiný datový typ pro jednu z proměnných nebo jinou hodnotu pro " jednotky " atribut) , ERDDAP přidá soubor do seznamu "špatných" souborů. Informace o problému se souborem budou zapsány do velkýRodič rodičů /logs/log.txt soubor.
• Nikdy byste neměli muset smazat nebo pracovat s těmito soubory. Jednou výjimkou je: pokud stále provádíte změny datového souboru datasets.xml nastavit, možná budete chtít odstranit tyto soubory k vynucení ERDDAP™ znovu přečíst všechny soubory, protože soubory budou číst/interpretovat jinak. Pokud budete někdy potřebovat odstranit tyto soubory, můžete to udělat, když ERDDAP™ Utíká. (Pak nastavte vlajka co nejdříve načíst soubor údajů.) Nicméně, ERDDAP™ obvykle si všimne, že datasets.xml informace neodpovídají souboru Informace o tabulce a automaticky smaže tabulky souborů.
• Pokud chcete podpořit ERDDAP™ aktualizovat uložené informace o datovém souboru (například, pokud jste právě přidali, odstranili nebo změnili některé soubory do datového adresáře datového souboru) , použijte Systém vlajky donutit ERDDAP™ aktualizovat informace o cached souboru.  

Žádosti o zacházení

Při zpracování žádosti klienta o údaje, EDDGrid FromFiles se může rychle podívat do tabulky s platnou informací o souboru zjistit, které soubory mají požadovaná data.  

Aktualizace informací o souboru

Kdykoli je soubor znovu načten, jsou aktualizovány informace o cache souboru.

• Databáze se pravidelně načítá tak, jak stanoví<reloadEveryNMinutes> v informacích datového souboru v datasets.xml .
• Databáze je znovu načítána co nejdříve. ERDDAP™ zjistí, že jste přidali, odstranili, Touch'd (změnit poslední soubor Změněný čas) , nebo změnil datový soubor.
• Databáze je znovu načtena co nejdříve, pokud použijete Systém vlajky .

Když je soubor dat znovu načten, ERDDAP™ Porovnává aktuálně dostupné soubory s informačními tabulkami v cache. Nové soubory se čtou a přidávají do platné tabulky souborů. Soubory, které již neexistují, jsou staženy z platné tabulky souborů. Soubory, kde došlo ke změně časového razítka souboru, se čtou a jejich informace se aktualizují. Nové tabulky nahrazují staré tabulky v paměti a na disku.  

Špatné soubory

Tabulka špatných souborů a důvody, proč byly soubory prohlášeny za špatné (poškozený soubor, chybějící proměnné atd.) je e-mailem na e-mail Všechno Na e-mailovou adresu (Pravděpodobně vy.) pokaždé, když je soubor dat znovu načten. Měli byste tyto soubory co nejdříve nahradit nebo opravit.  

Chybějící proměnné

Pokud některé složky nemají některé z dataVariable s definovaná v souboru údajů datasets.xml To je v pořádku. Kdy? EDDGrid FromFiles čte jeden z těchto souborů, to bude působit, jako by soubor měl proměnnou, ale se všemi chybějícími hodnotami.  

FTP Potíže/Advice

Pokud FTP nové datové soubory do ERDDAP™ server zatímco ERDDAP™ Utíká, je tu šance, že ERDDAP™ bude soubor údajů během procesu FTP znovu nabíjet. Stává se to častěji, než si myslíte! Pokud k tomu dojde, bude se soubor zdát platný (má platné jméno) Ale ta složka ještě není platná. Pokud ERDDAP™ pokusí se číst data z tohoto neplatného souboru, výsledná chyba způsobí přidání souboru do tabulky neplatných souborů. To není dobré. Aby se zabránilo tomuto problému, použijte dočasné jméno souboru při FTP 'ing soubor, například ABC2005 .nc \_TEMP . Pak souborNameRegex test (viz níže) uvede, že se nejedná o relevantní soubor. Po dokončení procesu FTP přejmenujte soubor na správný název. Proces přejmenování způsobí, že soubor bude okamžitě relevantní.  

"0 souborů" Chyba zprávy

Když utečeš GenerovatDatasetsXml nebo DasDds , nebo pokud se pokusíte načíst EDDGrid Z... soubory souborů dat v ERDDAP™ , a dostanete chybovou zprávu "0 souborů" ukazující, že ERDDAP™ nalezeno 0 odpovídajících souborů v adresáři (když si myslíte, že jsou odpovídající soubory v tomto adresáři) :

• Zkontrolujte, zda jsou soubory skutečně v adresáři.
• Zkontrolujte pravopis názvu adresáře.
• Zkontrolujte souborNameRegex. Je opravdu snadné dělat chyby s regexy. Pro testovací účely zkuste regex .\*, který by měl odpovídat všem názvům souborů. (Vidíš tohle? dokumentace regexu a reflexní tutoriál .)
• Zkontrolujte, zda uživatel, který program provozuje (např. user=tomcat (?) pro přípravek Tomcat/ ERDDAP ) má "číst" povolení pro tyto soubory.
• V některých operačních systémech (např. SELinux) a v závislosti na nastavení systému musí mít uživatel, který program spustil, oprávnění číst celý řetězec adresářů vedoucích do adresáře, který má soubory.  

EDDGrid Z files kostra XML

• Kostra XML pro všechny EDDGrid Podtřídy FromFiles jsou:

  <dataset type="EDDGridFrom...Files" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <accessibleViaWMS>...</accessibleViaWMS> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1. For
        EDDGridFromFiles subclasses, this uses Java's WatchDirectory system
        to notice new/deleted/changed files quickly and efficiently. -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <matchAxisNDigits>...</matchAxisNDigits> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <dimensionValuesInMemory>...</dimensionValuesInMemory> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <fileDir>...</fileDir> <-- The directory (absolute) with the
        data files. -->
      <recursive>true|false</recursive> <!-- 0 or 1. Indicates if
        subdirectories of fileDir have data files, too. -->
      <pathRegex>...</pathRegex> <!-- 0 or 1. Only directory names which
        match the pathRegex (default=".\") will be accepted. -->
      <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>
        <!-- 0 or 1 -->
      <metadataFrom>...</metadataFrom> <-- The file to get
        metadata from ("first" or "last" (the default) based on file's
        lastModifiedTime). -->
      <fileTableInMemory>...</fileTableInMemory> <!-- 0 or 1 (true or
        false (the default)) -->
      <cacheFromUrl>...</cacheFromUrl> <!-- 0 or 1 -->
      <cacheSizeGB>...</cacheSizeGB> <!-- 0 or 1 -->
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <axisVariable>...</axisVariable> <!-- 1 or more -->
      <dataVariable>...</dataVariable> <!-- 1 or more -->
  </dataset>

EDD*FromAudioFiles

** EDDGrid FromAudioFiles** a EDDTableFromAudioFiles souhrn dat ze sbírky místních audio souborů. (Tyto se poprvé objevily v ERDDAP™ v1.82.) Rozdíl je, že EDDGrid FromAudioFiles považuje data za multidimenzionální datový soubor (obvykle se 2 rozměry: \[ start souboru Čas \] a \[ uplynulo Čas v rámci souboru \] ) , zatímco EDDTableFromAudioFiles považuje data za tabulární data (obvykle se sloupcemi pro spuštění souboruTime, uplynulý čas se souborem a data z audio kanálů) . EDDGrid FromAudioFiles vyžaduje, aby všechny soubory měly stejný počet vzorků, takže pokud to není pravda, musíte použít EDDTableFromAudioFiles. Jinak je volba typu EDD zcela na vás. Jednou z výhod EDDTableFromAudioFiles: můžete přidat další proměnné s jinými informacemi, např., stationID , staniceType. V obou případech nedostatek jednotné časové proměnné ztěžuje práci s daty z těchto typů EDD, ale nebyl žádný dobrý způsob, jak nastavit jednotnou časovou proměnnou.

Vidíš tyhle třídy? EDDGrid FromFiles a EDDTableFromFoles , pro obecné informace o tom, jak tato třída funguje a jak ji používat.

Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Vzhledem k tomu, že audio soubory nemají jiná metadata než informace související se kódováním zvukových dat, budete muset editovat výstup z GenerateDatasets Xml poskytovat základní informace (např. titul, shrnutí, creator\_name , instituce, historie) .

Podrobnosti:

• Existuje velký počet formátů audio souborů. V současné době, ERDDAP™ lze číst data z většiny .wav a .au souborů. Momentálně nemůže číst jiné typy audio souborů, např. .aiff nebo .mp3. Pokud potřebujete podporu pro jiné formáty audio souborů nebo jiné varianty .wav a .au, prosím, pošlete svou žádost Chrisovi. John at noaa.gov . Nebo jako workaround můžete použít právě teď, můžete převést své zvukové soubory na PCM\_ Podepsáno (pro celá data) nebo PCM\_ FLOAT (pro údaje o plovoucích bodech) .wav soubory tak, že ERDDAP™ může s nimi pracovat.
• V současné době, ERDDAP™ může číst audio soubory s tím, co Java 's AudioFormat třída volá PCM\_FLOAT, PCM\_SIGNED, PCM\_UNSIGNED, ALAW, a ULAW kódování. ERDDAP™ konvertuje hodnoty PCM\_UNSIGNED (např. 0 až 255) do podepsaných hodnot (např. -128 až 128) přeskupením bitů v hodnotách dat. ERDDAP™ konvertuje ALAW a ULAW kódován z jejich nativní kódovaný byte formát do krátké (int16) hodnoty. Od Java chce bigEndian=true data, ERDDAP™ přerovnává bajty dat uložených s bigEndian=false (malý endián) pro správné čtení hodnot. Pro všechna ostatní kódování (PCM) , ERDDAP™ čte data tak, jak je.
• Kdy? ERDDAP™ čte data z audio souborů, převádí dostupná audio metadata souboru na globální atributy. To bude vždy zahrnovat (s zobrazenými hodnotami vzorku)

Smyčcový audioBigEndian "false"; //true or false int audio kanály 1; Smyčcové audiokódování "PCM\_SIGNED"; float audioFrameRate 9600.0; //per second int audioFrameSize 2; //# of data bytes per frame float audioSampleRate 9600.0; //per second int audioSampleSizeInBits 16; //# bitů na kanál na vzorek

Pro ERDDAP 's účely, rám je synonymem pro vzorek, což jsou údaje pro jeden bod v čase. Vlastnosti v ERDDAP™ bude mít informace popisující data, jak to bylo ve zdrojových souborech. ERDDAP™ budou často měnit tato data při čtení dat, např. PCM\_UNSIGNED, ALAW, a ULAW kódovaná data jsou převedena na PCM\_SIGNED a bigEndian=false data jsou převedena na bigEndian=true data (což je jak Java chce si to přečíst.) . Nakonec hodnoty údajů ERDDAP™ vždy bude Kódováno PCM hodnoty údajů (tj. jednoduché digitalizované vzorky zvukové vlny) .

• Kdy? ERDDAP™ čte data z audio souborů, čte celý soubor. ERDDAP™ může číst až 2 miliardy vzorků na jeden kanál. Například pokud je vzorkovací frekvence 44,100 vzorků za sekundu, 2 miliardy vzorků se přeloží na asi 756 minut zvukových údajů na jeden soubor. Pokud máte audio soubory s více než tímto množstvím dat, musíte rozebrat soubory do menších částí tak, aby ERDDAP™ může je přečíst.
• Protože ERDDAP™ čte celé zvukové soubory, ERDDAP™ musí mít přístup k velkému množství paměti pro práci s velkými zvukovými soubory. Viz ERDDAP 's nastavením paměti . Opět, pokud je to problém, práce, kterou můžete použít právě teď je rozebrat soubory na menší kousky tak, že ERDDAP™ umí je přečíst s menší pamětí.
• Některé zvukové soubory byly špatně napsány. ERDDAP™ vyvíjí malé úsilí, aby se těmito případy zabýval. Ale obecně, když je chyba, ERDDAP™ a věru se vymaní (a odmítnout tento soubor) nebo (pokud je chyba nezjistitelná) číst údaje (ale údaje budou nesprávné) .
• ERDDAP™ nekontroluje ani nemění hlasitost zvuku. V ideálním případě jsou celočíselná data zvuku zvětšena tak, aby byla použita celá škála datového typu.
• Audio soubory a audio přehrávače nemají systém pro chybějící hodnoty (např. -999 nebo Float.NaN) . Takže audio data by neměla mít žádné chybějící hodnoty. Pokud chybí hodnoty (např. pokud potřebujete prodloužit audio soubor) Použijte řadu 0, které budou vykládány jako dokonalé ticho.
• Kdy? ERDDAP™ čte data z audio souborů, vždy vytváří sloupec zvaný "prošlý" Čas s časem pro každý vzorek, v sekundách (uloženy jako dvojité) , vzhledem k prvnímu vzorku (který je přidělen Time=0.0 s) . S EDDGrid FromAudioFiles se stává proměnnou uplynulé časové osy.
• EDDGrid FromAudioFiles vyžaduje, aby všechny soubory měly stejný počet vzorků. Takže pokud to není pravda, musíte použít EDDTableFromAudioFiles.
• Pro EDDGrid FromAudioFiles, doporučujeme nastavit [<dimensionValuesInMemory>] (# Dimensionvalueinmemory) na false (jak doporučuje GenerateDatasets Xml) Protože časový rozměr má často obrovský počet hodnot.
• Pro EDDGrid FromAudioFiles, měli byste téměř vždy používat EDDGrid Systém FromFiles pro Agregace prostřednictvím Název souboru , téměř vždy výpisem data zahájení nahrávky Čas z názvů souborů. Například,

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

Generovat soubory dat Xml to podpoří a pomůže vám s tím.

• Pro EDDTableFromAudioFiles byste měli téměř vždy používat systém EDDTableFromFoles pro \\\* fileName pseudo sourceName án k získání informací ze jména souboru (téměř vždy datum zahájení Čas na nahrávání) a podporovat jej tak, aby byl sloupcem údajů. Například,

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

Časový formát by pak měl být uveden jako atribut jednotek:<att name="onities="yyyMMdd"\_'HHmmss</att >  

EDDGrid Z MergeIRFiles

** EDDGrid Z MergeIRFiles** souhrnné údaje z místních, MergeIR Soubory, které jsou z Měřící mise pro tropické deště (TRMM) , což je společná mise mezi NASA a Japan Aerospace Exploration Agency (JAXA) . Sloučit IR soubory lze stáhnout z NASA .

EDDGrid OdMergeIRFiles.java byl napsán a přispěl k ERDDAP™ projekt Jonathana Lafiteho a Philippa Makowskiho z R.Tech Engineeringu (licence: autorizovaný open source) .

EDDGrid Z MergeIRFiles je trochu neobvyklé:

• EDDGrid FromMergeIRFile podporuje komprimované nebo nestlačené zdrojové datové soubory, v jakékoli kombinaci, ve stejném datovém souboru. To vám například umožňuje komprimovat starší soubory, které jsou zřídka přístupné, ale odkompresovat nové soubory, které jsou často přístupné. Nebo můžete změnit typ kompresi z původní . Z na příklad, .gz .
• Pokud máte komprimované a nestlačené verze stejných datových souborů ve stejném adresáři, ujistěte se prosím, že<fileNameRegex> pro váš soubor se shoduje s názvy souborů, které chcete, aby se shodovaly a neodpovídá názvům souborů, které nechcete, aby se shodovaly.
• Nekompresní zdrojové datové soubory nesmí mít příponu souboru (tj. žádné "" v názvu souboru) .
• Stlačené zdrojové datové soubory musí mít příponu souboru, ale ERDDAP™ určuje typ komprese tím, že zkontroluje obsah souboru, nikoli pohledem na příponu souboru souboru (například ".Z") . Podporované typy komprese zahrnují "gz," "bzip2," "xz," "lzma," "nappy-raw," "nappy-framed," "pack200" a "z." Kdy? ERDDAP™ čte komprimované soubory, dekompresuje se při letu, bez zápisu do dočasného souboru.
• Všechny zdrojové datové soubory musí používat původní systém pojmenování souborů: tj., merg\_ RRRRMMDDHH \_4km-pixel (kde RRRRMMDDHH označuje čas spojený s údaji v souboru) , plus přípona souboru, pokud je soubor komprimován.

Vidíš tuhle třídu? EDDGrid FromFiles , pro obecné informace o tom, jak tato třída funguje a jak ji používat.

Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.  

EDDGrid FromNcFiles

** EDDGrid FromNcFiles** souhrnné údaje z místní, mřížkované, GRIB .grb a .grb2 soubory, HDF (v4 nebo v5) .hdf soubory, .nc ml soubory, NetCDF (V3 nebo v4) .nc soubory a Zarr soubory (od verze 2.25) . Soubory Zarr mají mírně odlišné chování a vyžadují buď souborNameRegex nebo cestuRegex zahrnout "zarr."

Nový ERDDAP™ verze 2.29.0 je experimentální podpora datových proměnných, které nepodporují všechny proměnné osy (nebo jak to někteří nazvali 1D a 2D dat ve stejném datovém souboru) . Prosím, kontaktujte GitHuba. (diskuse nebo otázky) se zpětnou vazbou a brouky.

To může fungovat s jinými typy souborů (například BUFR) Jen jsme to neotestovali. Prosím, pošlete nám nějaké vzorky.

• Pro soubory GRIB, ERDDAP™ udělá .gbx index soubor poprvé čte každý soubor GRIB. Takže soubory GRIB musí být v adresáři, kde "uživatel," který spustil Tomcat má oprávnění číst + psát.
• Vidíš tuhle třídu? EDDGrid FromFiles , informace o tom, jak tato třída funguje a jak ji používat.
• Začneme s ERDDAP™ v2.12 EDDGrid FromNcFiles a EDDGrid FromNcFiles Vybalené mohou číst data z "struktur" v .nc 4 a .hdf 4 soubory. Pro identifikaci proměnné, která je ze struktury,< sourceName > musí používat formát: FullStructureName | Název člena , například skupina1/myStruct | Můj pane.
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

Skupiny v souborech Gridded Nc

Netcdf4 soubory mohou obsahovat skupiny. ERDDAP™ jen vytvoří soubor údajů z proměnných v jedné skupině a všech jejích mateřských skupinách. Můžete zadat konkrétní název skupiny v GeneranteDatasets Xml (vynechat stopovací lomítko) , nebo použít "" mít GenerateDatasets Xml hledat všechny skupiny pro proměnné, které používají nejvíce rozměrů, nebo použití " \[ kořen \] " mít GenerateDatasets stačí hledat proměnné v kořenové skupině.

První věc, kterou GenerateDatasetsXml dělá pro tento typ datového souboru poté, co odpovíte na otázky, je tisk ncdump-jako struktura výběrového souboru. Takže pokud zadáte pár hloupých odpovědí pro první smyčku přes GenerateDatasets Xml, aspoň uvidíš, jestli ERDDAP™ může přečíst soubor a zjistit, jaké rozměry a proměnné jsou v souboru. Pak můžete dát lepší odpovědi pro druhou smyčku přes GenerateDatasetsXml.

EDDGrid FromNcFilesUnpacked

** EDDGrid FromNcFilesUnpacked** je varianta EDDGrid FromNcFiles které agregují údaje z místní, mřížkované NetCDF (V3 nebo v4) .nc a související soubory. Rozdíl je v tom, že tato třída vybalí každý datový soubor před EDDGrid FromFiles se dívá na soubory:

• Vybaluje proměnné, které jsou plné scale\_factor nebo add\_offset .
• Převádí \_FillValue a missing\_value hodnoty, které mají být NaN (nebo MAX\_VALUE pro celé datové typy) .
• Převádí hodnoty času a času na "seconds since 1970-01-01T00:00:00Z" .

Velkou výhodou této třídy je, že poskytuje způsob, jak se vypořádat s různými hodnotami scale\_factor , add\_offset \_FillValue, missing\_value , nebo časové jednotky v různých zdrojových souborech ve sbírce. Jinak byste museli použít nástroj jako NcML nebo NCO upravit každý soubor k odstranění rozdílů tak, aby soubory mohly být řešeny EDDGrid Z NcFiles. Aby tato třída správně fungovala, musí soubory dodržovat standardy CF pro související atributy.

• Pokud se pokusíte vytvořit EDDGrid FromNcFiles Vybalené ze skupiny souborů, se kterými jste se dříve snažili a nepoužívali EDDGrid OdNcFiles, cd do velkýRodič rodičů /dataset/ Last2Letters / * datasetID * / kde Last2Letters je poslední 2 písmena datasetID , a odstranit všechny soubory v tomto adresáři.
• Začneme s ERDDAP™ v2.12 EDDGrid FromNcFiles a EDDGrid FromNcFiles Vybalené mohou číst data z "struktur" v .nc 4 a .hdf 4 soubory. Pro identifikaci proměnné, která je ze struktury,< sourceName > musí používat formát: FullStructureName | Název člena , například skupina1/myStruct | Můj pane.
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

Netcdf4 soubory mohou obsahovat skupiny. Viz Tato dokumentace .

První věc, kterou GenerateDatasetsXml dělá pro tento typ datového souboru poté, co odpovíte na otázky, je tisk ncdump-jako struktura výběrového souboru předtím Je vybalená. Takže pokud zadáte pár hloupých odpovědí pro první smyčku přes GenerateDatasets Xml, aspoň uvidíš, jestli ERDDAP™ může přečíst soubor a zjistit, jaké rozměry a proměnné jsou v souboru. Pak můžete dát lepší odpovědi pro druhou smyčku přes GenerateDatasetsXml.

EDDGrid LonPM180

** EDDGrid LonPM180** mění hodnoty délky dítěte (uzavřen) EDDGrid data, která mají některé hodnoty délky větší než 180 (například 0 až 360) takže jsou v rozmezí -180 až 180 (Zeměpisná délka Plus nebo Minus 180, proto název) .

• To poskytuje způsob, jak vytvořit soubory údajů, které mají hodnoty délky větší než 180 v souladu s OGC Služby (např. WMS server v ERDDAP ) , protože všechny OGC služby vyžadují hodnoty délky v rozmezí -180 až 180.
• Práce v blízkosti přerušení způsobuje problémy bez ohledu na to, zda je přerušení na délce 0 nebo na délce 180. Tento typ datového souboru umožňuje vyhnout se těmto problémům pro každého tím, že nabízí dvě verze stejného datového souboru: jedna s hodnotami délky v rozmezí 0 až 360 ("Pacificentric"?) , jedna s hodnotami délky v rozmezí -180 až 180 ("Atlanticentric"?) .
• U dětských souborů se všemi hodnotami délky většími než 180 jsou všechny nové hodnoty délky prostě o 360 stupňů nižší. Například datový soubor s hodnotami délky 180 až 240 by se stal datovým souborem s hodnotami délky -180 až -120.
• U dětských souborů údajů, které mají hodnoty délky pro celou planetu (přibližně 0 až 360) , nová hodnota délky bude upravena tak, aby byla (zhruba) - 180 až 180: Původní hodnoty 0 až téměř 180 se nemění. Původní hodnoty 180 až 360 jsou převedeny na -180 až 0 a přesunuty na začátek pole délky.
• U dětských souborů, které se pohybují 180, ale nepokrývají svět, ERDDAP™ vloží chybějící hodnoty podle potřeby k vytvoření souboru, který pokrývá zeměkouli. Například dětský datový soubor s hodnotami délky 140 až 200 by se stal datovým souborem s hodnotami délky -180 až 180. Hodnoty dětí 180 až 200 by se staly -180 až -160. Vkládají se nové hodnoty délky od -160 do 140. Odpovídající hodnoty dat budou \_FillValues. Hodnoty dětí 140 až téměř 180 by se nezměnily. Vložení chybějících hodnot se může zdát divné, ale vyhýbá se několika problémům, které vyplývají z toho, že hodnoty délky, které náhle skočí (např. od -160 do 140) .
• In GenerovatDatasetsXml , existuje zvláštní "dataset type," EDDGrid LonPM180FromErddapCatalog, který umožňuje generovat datasets.xml místo EDDGrid LonPM180 datové soubory z každého z EDDGrid data v souboru ERDDAP jejichž délka je větší než 180. To usnadňuje nabízet dvě verze těchto souborů údajů: originál s hodnotami délky v rozmezí 0 až 360, a nový datový soubor s hodnotami délky v rozmezí -180 až 180.

Soubor údajů o dětech v rámci každého EDDGrid Databáze LonPM180 bude EDDGrid Od souboru Erddap, který ukazuje na původní datový soubor. Nový soubor údajů datasetID bude název původního datového souboru plus "\_LonPM180." Například,

    <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> 

Polož to. EDDGrid Databáze LonPM180 níže původní soubor údajů v datasets.xml . To se vyhýbá některým možným problémům.

Alternativně můžete nahradit EDDGrid FromErddap child database with the original database's datasets.xml . Pak bude existovat pouze jedna verze datového souboru: ta s hodnotami délky v rozmezí -180 až 180. Odradíme ji, protože jsou chvíle, kdy je každá verze datového souboru pohodlnější.

• Pokud například nabízíte dvě verze datového souboru s délkou 0 až 360 a jednou s délkou 180 až 180:

  • Můžete použít volitelné [<přístupný Via WMS > false</přístupný Via WMS >] (#Accessibleviawms) s datovým souborem 0-360 k násilnému vypnutí WMS služba pro tento datový soubor. Pak bude přístupná pouze verze souboru LonPM180 WMS .
  • Existuje několik způsobů, jak udržet soubor údajů LonPM180 aktuální se změnami základního datového souboru:
    • Pokud je soubor údajů o dítěti EDDGrid FromErddap soubor, který odkazuje na datový soubor ve stejném ERDDAP™ , soubor údajů LonPM180 se pokusí přímo přihlásit k podkladovému datovému souboru tak, aby byl vždy aktuální. Přímé předplatné nevytváří e-maily, které vás žádají o potvrzení předplatného - validace by měla být provedena automaticky.
    • Pokud dětský soubor údajů není EDDGrid OdErddap soubor, který je na stejné ERDDAP™ Databáze LonPM180 se pokusí používat systém pravidelného předplatného k upsání základního datového souboru. Pokud máte systém předplatného ve svém ERDDAP™ Zapnuto, měli byste dostat e-maily a požádat vás o potvrzení předplatného. Prosím, udělejte to.
    • Pokud máte systém předplatného ve svém ERDDAP™ Vypnuto, databázový soubor LonPM180 může mít někdy zastaralá metadata, dokud nebude soubor LonPM180 znovu načten. Takže pokud je systém předplatného vypnut, měli byste nastavit [<reload EveryNMinutes >] (# reload everynminutes) nastavení souboru údajů LonPM180 na menší číslo, takže je pravděpodobnější, že dříve zachytí změny v souboru údajů o dítěti.

• Pro datové soubory s maximální délkou > 360 použijte následující volitelnou konfiguraci pro nastavení maximální hodnoty a datový soubor se opraví na -180 až 180.

    <maxSourceLon>540</maxSourceLon>

EDDGrid kostra LonPM180 XML

  <dataset type="EDDGridLonPM180" datasetID\="..." active\="..." >
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1. For
        EDDGridFromDap, this gets the remote .dds and then gets the new
        leftmost (first) dimension values. -->
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <accessibleViaWMS>...</accessibleViaWMS> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <dimensionValuesInMemory>...</dimensionValuesInMemory> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <dataset>...</dataset> <!-- The child EDDGrid dataset. -->
  </dataset>

EDDGrid Lon0360

** EDDGrid Lon0360** mění hodnoty délky dítěte (uzavřen) EDDGrid Soubor údajů, který má některé hodnoty délky menší než 0 (například -180 až 180) takže jsou v rozmezí 0 až 360 (Proto název) .

• Práce v blízkosti přerušení způsobuje problémy bez ohledu na to, zda je přerušení na délce 0 nebo na délce 180. Tento typ datového souboru umožňuje vyhnout se těmto problémům pro každého tím, že nabízí dvě verze stejného datového souboru: jedna s hodnotami délky v rozmezí -180 až 180 ("Atlanticentric"?) . jedna s hodnotami délky v rozmezí 0 až 360 ("Pacificentric"?) ,
• U dětských souborů se všemi hodnotami délky menšími než 0, jsou všechny nové hodnoty délky jednoduše o 360 stupňů vyšší. Například datový soubor s hodnotami délky -180 až -120 by se stal datovým souborem s hodnotami délky 180 až 240.
• U dětských souborů údajů, které mají hodnoty délky pro celou planetu (zhruba -180 až 180) , nová hodnota délky bude upravena tak, aby byla (zhruba) 0 až 360: Původní hodnoty -180 až 0 se převedou na 180 až 360 a posunou se na konec pole délky. Původní hodnoty 0 až téměř 180 se nemění.
• U dětských souborů, které pokrývají lon=0, ale nepokrývají glóbus, ERDDAP™ vloží chybějící hodnoty podle potřeby k vytvoření souboru, který pokrývá zeměkouli. Například dětský datový soubor s hodnotami délky -40 až 20 by se stal datovým souborem s hodnotami délky 0 až 360. Hodnoty dětí od 0 do 20 by se nezměnily. Nové hodnoty délky budou vloženy od 20 do 320. Odpovídající hodnoty dat budou \_FillValues. Hodnoty dětí -40 až 0 by se staly 320 až 360. Vložení chybějících hodnot se může zdát divné, ale vyhýbá se několika problémům, které vyplývají z toho, že hodnoty délky, které náhle skočí (např. od 20 do 320) .
• In GenerovatDatasetsXml , existuje zvláštní "dataset type," EDDGrid Lon0360From ErddapCatalog, který vám umožní generovat datasets.xml místo EDDGrid Lon0360 datové soubory z každého z EDDGrid data v souboru ERDDAP jejichž délka je větší než 180. To usnadňuje nabízet dvě verze těchto souborů údajů: originál s hodnotami délky v rozmezí 0 až 360, a nový datový soubor s hodnotami délky v rozmezí -180 až 180.

Soubor údajů o dětech v rámci každého EDDGrid Lon0360 bude soubor dat EDDGrid Od souboru Erddap, který ukazuje na původní datový soubor. Nový soubor údajů datasetID bude název původního datového souboru plus "\_Lon0360." Například,

    <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> 

Polož to. EDDGrid Databáze Lon0360 níže původní soubor údajů v datasets.xml . To se vyhýbá některým možným problémům.

Alternativně můžete nahradit EDDGrid FromErddap child database with the original database's datasets.xml . Pak bude existovat pouze jedna verze datového souboru: ta s hodnotami délky v rozmezí 0 až 360. Odradíme ji, protože jsou chvíle, kdy je každá verze datového souboru pohodlnější.

• Pokud například nabízíte dvě verze datového souboru s délkou 0 až 360 a jednou s délkou 180 až 180:
  • Můžete použít volitelné [<přístupný Via WMS > false</přístupný Via WMS >] (#Accessibleviawms) s 0 až 360 datovým souborem k násilnému vypnutí WMS služba pro tento datový soubor. Pak bude přístupná pouze verze -180 až 180 souborů WMS .
  • Existuje několik způsobů, jak udržet datový soubor Lon0360 aktuální se změnami základního datového souboru:
    • Pokud je soubor údajů o dítěti EDDGrid FromErddap soubor, který odkazuje na datový soubor ve stejném ERDDAP™ , soubor údajů Lon0360 se pokusí přímo přihlásit k podkladovému souboru tak, aby byl vždy aktuální. Přímé předplatné nevytváří e-maily, které vás žádají o potvrzení předplatného - validace by měla být provedena automaticky.
    • Pokud dětský soubor údajů není EDDGrid OdErddap soubor, který je na stejné ERDDAP™ , soubor údajů Lon0360 se pokusí použít systém pravidelného předplatného k upsání základního datového souboru. Pokud máte systém předplatného ve svém ERDDAP™ Zapnuto, měli byste dostat e-maily a požádat vás o potvrzení předplatného. Prosím, udělejte to.
    • Pokud máte systém předplatného ve svém ERDDAP™ Vypnuto, soubor souborů Lon0360 může někdy mít zastaralá metadata, dokud není soubor Lon0360 znovu načten. Takže pokud je systém předplatného vypnut, měli byste nastavit [<reload EveryNMinutes >] (# reload everynminutes) nastavení souboru údajů Lon0360 na menší číslo, takže je pravděpodobnější, že dříve zachytí změny souboru údajů o dítěti.

EDDGrid Lon0360 kostra XML

  <dataset type="EDDGridLon0360" datasetID\="..." active\="..." >
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1. For
        EDDGridFromDap, this gets the remote .dds and then gets the new
        leftmost (first) dimension values. -->
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <accessibleViaWMS>...</accessibleViaWMS> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <dimensionValuesInMemory>...</dimensionValuesInMemory> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <dataset>...</dataset> <!-- The child EDDGrid dataset. -->
  </dataset>

EDDGrid SideBySide

** EDDGrid SideBySide** agregáty dvě nebo více EDDGrid Soubory údajů (děti) Bok po boku.

• Výsledný datový soubor má všechny proměnné ze všech dětských souborů.
• Databáze rodičů a všechny soubory údajů o dětech musí být odlišné datasetID s. Pokud jsou jména v rodině úplně stejná, soubor údajů selže při načtení (s chybovou zprávou, že hodnoty souhrnné osy nejsou v seřazeném pořadí) .
• Všechny děti musí mít stejné výchozí hodnoty pro axisVariable án \[ 1+ \] (například zeměpisná šířka, zeměpisná délka) . Přesnost zkoušky určuje zápasAxisNDigits .
• Děti mohou mít různé výchozí hodnoty pro axisVariable án \[ 0 \] (například čas) , ale obvykle jsou většinou stejné.
• Zdá se, že mateřský soubor bude mít všechny axisVariable án \[ 0 \] výchozí hodnoty od všech dětí.
• To například umožňuje kombinovat zdrojový soubor s U-komponentou vektoru a dalším zdrojovým datovým souborem s v-komponentou vektoru, takže mohou být podávaná kombinovaná data.
• Děti vytvořené touto metodou jsou drženy v soukromí. Nejsou samostatně přístupné datové soubory (například požadavky klientů na údaje nebo Soubory s vlajkou ) .
• Globální metadata a nastavení pro rodiče pocházejí z globálních metadat a nastavení pro první dítě.
• Pokud existuje výjimka při vytváření prvního dítěte, rodiče nebudou stvořeni.
• Pokud existuje výjimka při vytváření jiných dětí, to posílá e-mail na e-mail vše (jak je uvedeno v setup.xml ) a pokračuje s ostatními dětmi.

EDDGrid Boční kostra XML

  <dataset type="EDDGridSideBySide" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <accessibleViaWMS>...</accessibleViaWMS> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <matchAxisNDigits>...</matchAxisNDigits> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <dimensionValuesInMemory>...</dimensionValuesInMemory> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <dataset>...</dataset> <!-- 2 or more -->
  </dataset>

EDDGrid AgregátExistujícíRozměr

** EDDGrid AgregátExistujícíRozměr** agregáty dvě nebo více EDDGrid datové soubory, z nichž každý má jiný rozsah hodnot pro první rozměr, ale stejné hodnoty pro ostatní rozměry.

• Například jeden soubor údajů o dětech může mít 366 hodnot. (pro rok 2004) pro časový rozměr a jiné dítě může mít 365 hodnot (pro rok 2005) pro časovou dimenzi.
• Všechny hodnoty pro všechny ostatní rozměry (například zeměpisná šířka, zeměpisná délka) Musí být stejné pro všechny děti. Přesnost zkoušky určuje zápasAxisNDigits .
• Vytříděné hodnoty rozměrů - Hodnoty pro každý rozměr MUSÍ být v seřazeném pořadí (vzestupně nebo sestupně) . Hodnoty mohou být nepravidelně rozloženy. Nejsou žádné vazby. To je požadavek Standard metadat CF . Pokud hodnoty jakéhokoli rozměru nejsou v seřazeném pořadí, soubor dat se nenačte a ERDDAP™ určí první netříděnou hodnotu v souboru záznamu, velkýRodič rodičů /logs/log.txt .

Netříděné hodnoty rozměrů téměř vždy indikují problém se zdrojovým souborem. To se nejčastěji vyskytuje, když je do agregace zahrnut chybný nebo nevhodný soubor, což vede k netříděné časové dimenzi. Pro vyřešení tohoto problému viz chybová zpráva v ERDDAP™ log.txt soubor k nalezení urážlivé časové hodnoty. Pak se podívejte do zdrojových souborů najít odpovídající soubor (nebo jeden před nebo jeden po) To nepatří do agregace.

• Databáze rodičů a soubor údajů o dětech se musí lišit datasetID s. Pokud jsou jména v rodině úplně stejná, soubor údajů selže při načtení (s chybovou zprávou, že hodnoty souhrnné osy nejsou v seřazeném pořadí) .
• V současné době, dítě soubor musí být EDDGrid FromDap data data a MUSÍ mít nejnižší hodnoty souhrnné dimenze (obvykle nejstarší časové hodnoty) . Všechny ostatní děti musí být téměř stejné soubory údajů. (se liší jen v hodnotách pro první rozměr) a jsou určeny jen jejich sourceUrl .
• Souhrnný soubor dat získává metadata od prvního dítěte.
• The Generovat soubory dat Xml program může vytvořit hrubý návrh datasets.xml pro EDDGrid AgregátExisingDimension založený na souboru souborů, které podává Hyrax nebo THREDDS server. Například, použijte tento vstup pro program ("/1988" v URL dělá příklad běžet rychleji) :

    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  

Můžete použít výsledný< sourceUrl > značky nebo odstranit a odkomentovat< sourceUrl > tag (tak, že nové soubory jsou zaznamenány pokaždé, když je soubor znovu načten.

EDDGrid AgregátExistující kostra rozdělení XML

  <dataset type="EDDGridAggregateExistingDimension" datasetID\="..."
        active\="..." >
      <dataset>...</dataset> <!-- This is a regular EDDGridFromDap dataset
        description child with the lowest values for the aggregated
        dimensions. -->
      <sourceUrl>...</sourceUrl> <!-- 0 or many; the sourceUrls for
        other children. These children must be listed in order of
        ascending values for the aggregated dimension. -->
      <sourceUrls serverType="..." regex="..." recursive="true"
        pathRegex\=".\"
        >https://someServer/someDirectory/someSubdirectory/catalog.xml</sourceUrls>
        <!-- 0 or 1. This specifies how to find the other children,
        instead of using separate sourceUrl tags for each child. The
        advantage of this is: new children will be detected each time
        the dataset is reloaded. The serverType must be "thredds",
        "hyrax", or "dodsindex".         An example of a regular expression (regex) (tutorial) is .\\.nc
        recursive can be "true" or "false".
        Only directory names which match the
        <pathRegex>
        (default=".\*") will be accepted.
        A thredds catalogUrl MUST include "/thredds/catalog/".
        An example of a thredds catalogUrl is
        https://thredds1.pfeg.noaa.gov/thredds/catalog/Satellite/aggregsatMH/
          chla/catalog.xml
        An example of a hyrax catalogUrl is
        https://opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/
        flk/1988/contents.html
        An example of a dodsindex URL is
        https://opendap.jpl.nasa.gov/opendap/GeodeticsGravity/tellus/L3/mascon/RL06/JPL/v02/CRI/netcdf/contents.html
        (Note the "OPeNDAP logo at the top of the page.)
        When these children are sorted by filename, they must be in
        order of ascending values for the aggregated dimension. -->
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <accessibleViaWMS>...</accessibleViaWMS> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <matchAxisNDigits>...</matchAxisNDigits> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <dimensionValuesInMemory>...</dimensionValuesInMemory> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
  </dataset>

EDDGrid Kopírovat

** EDDGrid Kopírovat** vyrábí a udržuje místní kopii jiného EDDGrid 's daty a slouží data z místní kopie.

• EDDGrid Kopírovat (a pro tabulková data, EDDtableCopy ) je velmi snadné použití a velmi efektivní řešení některých největších problémů se službou dat ze vzdáleného zdroje dat:
• Přístup k datům ze vzdáleného zdroje dat může být pomalý.
  • Může být pomalý, protože je neodmyslitelně pomalý. (například neefektivní typ serveru) ,
  • Protože je přemožena příliš mnoha požadavky,
  • nebo proto, že váš server nebo vzdálený server je omezen.
• Vzdálený datový soubor je někdy nedostupný (znovu, z různých důvodů) .
• Spoléhání na jeden zdroj pro data se neměří dobře (například, když mnoho uživatelů a mnoho ERDDAP Využijte ho.) .  
• Jak to funguje... EDDGrid Kopírování řeší tyto problémy tím, že automaticky vytvoří a udržuje místní kopii dat a slouží data z místní kopie. ERDDAP™ může sloužit data z místní kopie velmi, velmi rychle. A vytvoření místní kopie uvolní zátěž vzdáleného serveru. A místní kopie je záloha originálu, což je užitečné pro případ, že by se něco stalo s originálem.

Na vytvoření místní kopie souboru není nic nového. Co je tady nového je, že tato třída to dělá\*snadné\*vytvořit a\*udržovat\*místní kopie údajů z\*odrůda\*typů vzdálených zdrojů dat a\*přidat metadata\*při kopírování dat.

• Kousky dat... EDDGrid Kopírování dělá místní kopii dat tím, že požaduje kousky dat ze vzdáleného<Soubor údajů > . Tam bude kus pro každou hodnotu z nejlevnějších (první) proměnná osy. EDDGrid Kopírování nespoléhá na čísla indexu vzdáleného datového souboru pro osu - ty se mohou změnit.

UPOZORNĚNÍ: Pokud je velikost kusu dat tak velká (> 2GB) že způsobuje problémy, EDDGrid Kopii nelze použít. (Promiňte, doufáme, že pro tento problém budeme mít řešení v budoucnosti.)

• \[ Alternativa k EDDGrid Kopírovat - Pokud jsou vzdálená data dostupná prostřednictvím stažených souborů, nikoli webové služby, použijte cache Možnost FromUrl pro EDDGrid FromFiles , který tvoří místní kopii vzdálených souborů a slouží data z místních souborů. \]
• Místní soubory... Každý kus dat je uložen v samostatném NetCDF soubor v podadresáři velkýRodič rodičů /kopie/ * datasetID * / (jak je uvedeno v setup.xml ) . Jméno souboru vytvořené z osových hodnot je upraveno tak, aby byly bezpečné (Například pomlčky se nahrazují "x2D") Tohle nemá vliv na skutečná data.  
• Nová data -- Pokaždé EDDGrid Kopírování je znovu načteno, kontroluje ovladač<Databáze > zjistit, jaké kousky jsou k dispozici. Pokud soubor pro kus dat již neexistuje, je do fronty přidán požadavek na získání kusu. ERDDAP 's úkolemThread zpracovává všechny ve frontě žádosti o kousky dat, jeden po druhém. Můžete vidět statistiky pro úkolThread činnost na Stavová stránka a v Denní zpráva . (Ano. ERDDAP™ by mohl přidělit více úkolů tomuto procesu, ale to by využít spoustu vzdáleného zdroje dat šířky pásma, paměti a času CPU, a mnoho místních ERDDAP 's šířkou pásma, pamětí a CPU časem, ani jeden z nich není dobrý nápad.)

POZNÁMKA: Úplně poprvé EDDGrid Rozumím. (Pokud vše půjde dobře) Do fronty úkolThread bude přidáno mnoho žádostí o kousky dat, ale nebudou vytvořeny žádné místní datové soubory. Takže konstruktér selže, ale úkolThread bude i nadále pracovat a vytvářet místní soubory. Pokud vše půjde dobře, úkolThread vytvoří místní datové soubory a další pokus o opětovné načtení datového souboru (za ~15 minut) bude úspěšný, ale zpočátku s velmi omezeným množstvím dat.

POZNÁMKA: Poté, co má místní datový soubor nějaká data a objeví se ve vašem ERDDAP , pokud je vzdálený datový soubor dočasně nebo trvale nepřístupný, bude místní datový soubor stále fungovat.

UPOZORNĚNÍ: Pokud je vzdálený datový soubor velký a/nebo je vzdálený server pomalý (To je ten problém, že?) , bude trvat dlouho, aby kompletní místní kopii. V některých případech bude potřebný čas nepřijatelný. Například přenos 1 TB dat přes řádek T1 (0, 15 GB/s) trvá nejméně 60 dní, za optimálních podmínek. Navíc využívá spoustu šířky pásma, paměti a času CPU na vzdálených a místních počítačích. Řešením je odeslání pevného disku správci vzdálené datové sady tak, aby mohl vytvořit kopii souboru dat a odeslat pevný disk zpět vám. Použít tyto údaje jako výchozí bod a EDDGrid Kopírování do něj přidá data. (To je jeden způsob, jak Cloud Service společnosti Amazon řeší problém, i když jejich systém má hodně šířky pásma.)

UPOZORNĚNÍ: Pokud je daná hodnota pro levý (první) proměnná osy mizí ze vzdáleného datového souboru, EDDGrid Kopírování nevymaže místní zkopírovaný soubor. Jestli chceš, můžeš to smazat sám.

@ info: whatsthis Údaje

The datasets.xml pro tento datový soubor může mít volitelnou značku

    <checkSourceData>true</checkSourceData>  

Výchozí hodnota je pravdivá. Pokud / když jej nastavíte na false, data nikdy nezkontrolují zdrojový soubor, aby zjistili, zda jsou k dispozici další data.

pouze od

You can tell EDDGrid Kopírovat pro vytvoření kopie podmnožiny zdrojového souboru, místo celého zdrojového souboru, přidáním značky ve formuláři<pouzeOd> některé Hodnota </pouzeOd > do souboru údajů datasets.xml kus. EDDGrid Kopírování bude stahovat pouze hodnoty dat související s hodnotami prvního rozměru (obvykle časový rozměr) které jsou větší než některé Hodnota . některé Hodnota může být:

• Relativní čas stanovený prostřednictvím now- nJednotky . Například,<pouzeOd> now- 2 roky</pouzeVzhledem k tomu, že > říká datovému souboru, aby pouze místní kopie údajů pro data, kde hodnoty vnějšího rozměru (obvykle časové hodnoty) jsou v posledních dvou letech (který je přehodnocen pokaždé, když je soubor dat znovu načten, což je, když hledá nové údaje kopírovat) . Viz now- nJednotky Popis syntaxe . To je užitečné, pokud má první rozměr časová data, což obvykle má.

  EDDGrid Kopírování nevymaže místní datové soubory, které mají data, která časem zestárnou now- nJednotky . Tyto soubory můžete kdykoli smazat, pokud se rozhodnete. Pokud ano, důrazně doporučujeme nastavit vlajka poté, co smažete soubory k prozrazení EDDGrid Kopírovat pro aktualizaci seznamu cached souborů.

• Pevný bod v čase určený jako řetězec ISO 8601 yyyy-MM-ddTHH:mm:ssZ . Například,<pouzeOd >2000-01-01T00:00:00Z</onlyOd té doby> říká souboru dat pouze, aby místní kopie dat, kde je hodnota prvního rozměru \>=2000-01-01T00:00:00Z . To je užitečné, pokud první rozměr má data času, což obvykle dělá.  

• Číslo plovoucího bodu. Například,<pouzeOd >94668480. 0</pouzeOd > . Jednotky budou cílové jednotky první dimenze. Například pro časové rozměry, jednotky v ERDDAP™ jsou vždy "seconds since 1970-01-01T00:00:00Z" . Takže 94668480.0. "seconds since 1970-01-01T00:00:00Z" odpovídá 2000-01-01T00:00:00Z. To je vždy užitečná volba, ale je zvláště užitečná, když první dimenze nemá data o čase.

EDDGrid Kopírovat doporučené použití

1. Vytvořit<Databáze > položka (původní typ, nikoli EDDGrid Kopírovat) pro vzdálený zdroj dat. Udělejte to správně, včetně všech požadovaných metadat.
2. Pokud je to příliš pomalé, přidejte XML kód k zabalení do EDDGrid Kopírovat data.
   • Použít jiný datasetID (Možná změnou datasetID starých datasetID mírně) .
   • Kopírovat<přístupný To>,<reloadEveryNMinutes> a<onChange> ze vzdáleného EDDGrid 's XML na EDDGrid XML kopie. (Jejich hodnoty pro EDDGrid Kopírovat hmotu; jejich hodnoty pro vnitřní datový soubor jsou irelevantní.)
3. ERDDAP™ vytvoří a udržuje místní kopii údajů.  

• UPOZORNĚNÍ: EDDGrid Kopírovat předpokládá, že hodnoty dat pro každý kus se nikdy nezmění. Pokud ano, musíte ručně smazat jednotlivé soubory v velkýRodič rodičů /kopie/ * datasetID * / která se změnila a vlajka soubor údajů, který má být znovu načten, aby byly smazané kusy nahrazeny. Pokud máte e-mailové předplatné datového souboru, dostanete dva e-maily: jeden, když soubor dat poprvé načte a začne kopírovat data, a další, když se soubor dat znovu načte (automaticky) a detekuje nové místní datové soubory.  
• Všechny hodnoty osy musí být stejné. Pro každou z os kromě těch nejlevějších (první) , všechny hodnoty musí být stejné pro všechny děti. Přesnost zkoušky určuje zápasAxisNDigits .  
• Nastavení, Metadata, Proměnné -- EDDGrid Kopírovat používá nastavení, metadata a proměnné z uzavřeného zdrojového souboru.  
• Změnit metadata -- Pokud potřebujete změnit některý addAttributes nebo změnit pořadí proměnných spojených se zdrojovým datovým souborem:
  1. Změňte addAttributes pro zdrojový soubor dat v datasets.xml , podle potřeby.
  2. Smazat jeden z kopírovaných souborů.
  3. Nastavit vlajka okamžitě načíst soubor údajů. Pokud použijete vlajku a máte e-mailové předplatné datového souboru, dostanete dva e-maily: jeden, když soubor dat poprvé znovu načte a začne kopírovat data, a druhý, když se soubor dat znovu načte (automaticky) a detekuje nové místní datové soubory.
  4. Smazaný soubor bude regenerován s novými metadaty. Pokud zdrojový soubor není k dispozici, EDDGrid Kopírovat soubor získá metadata z regenerovaného souboru, protože je to nejmladší soubor.

EDDGrid Kopírovat kostru XML

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

EDDTableFromCassandra

EDDTableFromCassandra zpracovává údaje z jednoho Cassandra stůl. Cassandra je databáze NoSQL.

• ERDDAP™ může pracovat s Cassandra v2 a v3 bez změn nebo rozdílů v nastavení. Testovali jsme s Cassandra v2 a v3 z Apač . Pravděpodobně ERDDAP™ může také pracovat s Cassandrou staženou z DataStax.  
• Pro srpen 2019 - květen 2021 jsme měli problém přimět Cassandru pracovat s AdoptOpenJdkem Java v8. Hodila EXCEPTION\_ACCESS\_VIOLATION). Ale teď (květen 2021) , že problém je pryč: můžeme úspěšně použít Cassandra v2.1.22 a AdopOpenJdk jdk8u292-b10.  

Jedna tabulka

Cassandra nepodporuje "připojení" tak, jak to dělají relační databáze. Jedna ERDDAP™ EDDTableFromCassandra databázové mapy na jednu (možná podmnožina jednoho) Stůl Cassandry.

Cassandra datasets.xml

• ERDDAP™ přichází s Cassandrou. Java řidič, takže nemusíte instalovat samostatně.
• Pečlivě si přečtěte všechny informace tohoto dokumentu o EDDTableFromCassandra. Některé detaily jsou velmi důležité.
• Cassandra Java řidič je určen k práci s Apache Cassandra (1,2+) a DataStax Enterprise (3.1+) . Pokud používáte Apache Cassandra 1.2.x, musíte upravit soubor cassandra.yaml pro každý uzel pro nastavení startu\_native\_transport: true, pak restartovat každý uzel.
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak můžete upravit, že na jemné naladění (zejména [<oddíl Název KeySource >] (#partitionkeysourcenames) ). Většinu informací, které potřebujete k vytvoření XML pro datový soubor EDDTableFromCassandra, můžete shromáždit prostřednictvím kontaktu se správcem Cassandry a vyhledáváním na webu.

Generovat soubory dat Xml má dvě speciální možnosti pro EDDTableFromCassandra:

1. Pokud vstoupíte "!!!LIST!!!!" (bez kotací) pro klíčový prostor program zobrazí seznam klíčových prostor
2. Pokud vstoupíte do určitého klíčového prostoru a zadáte "!!!LIST!!!!" (bez kotací) pro název tabulky, program zobrazí seznam tabulek v tomto keyspace a jejich sloupců.

Citlivost případu

• Klíčově citlivé názvy a tabulky - Cassandra zachází se jmény klíčů a tabulky způsobem, který je citlivý na případy. Kvůli tomuhle nesmíte nikdy použít rezervované slovo. (ale s jiným případem) jako keyspace Cassandra nebo jméno stolu.
• Název sloupce necitlivý na případy -- Ve výchozím nastavení, Cassandra zachází názvy sloupců způsobem, který je citlivý na případy. Pokud použijete jedno z Cassandriných vyhrazených slov jako název sloupce (Prosím, ne!) , musíte použít

        <columnNameQuotes>"<columnNameQuotes>  

v datasets.xml pro tento datový soubor tak, aby Cassandra a ERDDAP™ bude s názvy sloupců zacházet způsobem, který je citlivý na případy. To bude pravděpodobně masivní bolest hlavy pro vás, protože je těžké určit případ citlivé verze jmen sloupců - Cassandra téměř vždy zobrazuje názvy sloupců jako všechny malé-případ, bez ohledu na skutečný případ.

• úzce spolupracovat se správcem Cassandry, který může mít příslušné zkušenosti. Pokud datový soubor nenačte, přečtěte si chybová zpráva pečlivě zjistit proč.  

Cassandra<spojení Nemovitost>

Cassandra má vlastnosti připojení, které mohou být uvedeny v datasets.xml . Mnoho z nich ovlivní výkon Cassandry... ERDDAP™ spojení. Bohužel, vlastnosti Cassandra musí být nastaveny programově v Java Takže ERDDAP™ musí mít kód pro každou nemovitost ERDDAP™ Podpora. V současné době, ERDDAP™ podporuje tyto vlastnosti: (Zobrazené výchozí hodnoty jsou to, co vidíme. Default vašeho systému může být jiný.)

• Obecné možnosti
  <spojení Název nemovitosti=" komprese "> žádný | LZ4 | Snappy </připojení Majetek > (případ-necitlivý, výchozí=ne)
  (Obecné kompresní poradenství: použijte "ne," pokud je spojení mezi Cassandrou a ERDDAP™ je lokální/rychlostní a pokud je spojení vzdálené/pomalé, použijte 'LZ4'.)
  <spojení Název nemovitosti=" pověřovací listiny "> uživatelské jméno/heslo </připojení Majetek > (To je doslova. '/' )
  <spojení Název nemovitosti=" metriky "> pravda | false </připojení Majetek > (2021-01-25 byl výchozí=true, nyní ignorován a vždy false)
  <spojení Název nemovitosti=" přístav "> anInteger </připojení Majetek > (výchozí pro nativní binární protokol=9042)
  <spojení Název nemovitosti=" ssl "> pravda | false </připojení Majetek > (default=false)
  (Můj rychlý pokus použít ssl selhal. Pokud uspějete, prosím, řekněte mi, jak jste to udělal.)
• Možnosti dotazu
  <spojení Název nemovitosti=" soulad Úroveň "> všechny | jakékoli | každý\_quorum | místní\_one | místní\_quorum | místní\_serial | jeden | usnášeníschopnost | sériová | tři | dva </připojení Majetek > (případ necitlivý, výchozí=ON)
  <spojení Název nemovitosti=" getSize "> anInteger </připojení Majetek > (výchozí=5000)
  (Nenastavujte getSize na menší hodnotu.)
  <spojení Název nemovitosti=" Sériová konzistenceLevel "> všechny | jakékoli | každý\_quorum | místní\_one | místní\_quorum | místní\_serial | jeden | usnášeníschopnost | sériová | tři | dva </připojení Majetek > (nesenzitivní případ, výchozí hodnota = SERIAL)
• Možnosti socketu
  <spojení Název nemovitosti=" connectTimeoutMillis "> anInteger </připojení Majetek > (výchozí=5000)
  (Nenastavit připojení TimeoutMillis na menší hodnotu.)
  <spojení Název nemovitosti=" uchovávatAlive "> pravda | false </připojení Majetek > <spojení Název nemovitosti=" readTimeoutMillis "> anInteger </připojení Majetek > (Cassandra výchozí readTimeoutMillis je 12000, ale ERDDAP™ změní výchozí hodnotu na 120000. Pokud Cassandra hází readTimeouts, zvýšení to nemusí pomoci, protože Cassandra někdy hází je dříve než tentokrát. Problém je pravděpodobnější, že ukládáte příliš mnoho dat na oddíl Klíčová kombinace.)
  <spojení Název nemovitosti=" receiveBufferSize "> anInteger </připojení Majetek > (Není jasné, co je výchozí receiveBufferSize. Nenastav to na malou hodnotu.)
  <spojení Název nemovitosti=" soLinger "> anInteger </připojení Majetek > <spojení Název nemovitosti=" tcpNoDelay "> pravda | false </připojení Majetek > (default=null)

Pokud potřebujete být schopni nastavit další vlastnosti připojení, viz naše oddíl o získání dodatečné podpory .

Pro daný startup Tomcat se připojeníProperties používá pouze poprvé, kdy je vytvořen soubor dat pro danou Cassandra URL. Všechny reloady tohoto datového souboru a všech následných souborů, které sdílejí stejnou URL, budou používat tyto originální připojeníProperties.

CQL

Jazyk dotazů Cassandra (CQL) je povrchně jako SQL, dotaz jazyk používaný tradiční databáze. Protože OPeNDAP 's tabulkovými požadavky na data byly navrženy tak, aby napodobovaly požadavky SQL tabulky dat, je možné pro ERDDAP™ převést tabulkové žádosti o data do CQL Bound/PreparedStatements. ERDDAP™ vloží prohlášení do log.txt jako prohlášení jako text: státAsText
Verze prohlášení, kterou uvidíte, bude textovou reprezentací prohlášení a bude mít pouze "?" kde budou umístěny mezní hodnoty.  
Není to tak jednoduché... Bohužel, CQL má mnoho omezení, na které sloupce mohou být dotazovány, s kterými typy omezení, například oddíly klíčových sloupců lze omezit s = a IN, takže ERDDAP™ pošle Cassandra několik omezení a použije všechna omezení po obdržení údajů od Cassandry. Abych pomohl. ERDDAP™ efektivně jednat s Cassandra, musíte upřesnit [<oddíl Název KeySource >] (#partitionkeysourcenames) , [<ClosterColumnSourceNames>] (#clustercolumsourcenames) a [<indexColumnSourceNázevs>] (#indexcolunctionsourcenames) v datasets.xml pro tento datový soubor. To jsou nejdůležitější způsoby, jak pomoci. ERDDAP™ efektivně pracovat s Cassandrou. Když to neřekneš ERDDAP™ Tyto informace, data budou bolestivě pomalé v ERDDAP™ a využít tuny zdrojů Cassandry.  

<oddíl Jméno KeySource>

Protože diskové klíče hrají ústřední roli v tabulkách Cassandra, ERDDAP™ potřebuje znát jejich sourceName s a případně další informace o tom, jak s nimi pracovat.

• Musíte zadat čárku oddělený seznam jmen zdrojového sloupce oddílu v datasets.xml přes<oddíl KeySourceNames>. Jednoduchý příklad,

        <partitionKeySourceNames>station, deviceid<partitionKeySourceNames>  

Složitější příklad:

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

• TimeStamp Partition Keys -- Je-li jedním ze sloupců klíčů oddílu sloupec časové razítko, který má hrubou verzi jiného sloupce časového razítka, zadejte tuto informaci přes *oddílKeySourcName/otherColumnSourceName/ time\_precision *
  kde time\_precision je jeden z time\_precision struny používané jinde v ERDDAP . Stopa Z v time\_precision řetězec je výchozí, takže nezáleží na tom, zda time\_precision řetězec končí v Z nebo ne. Například, ERDDAP™ bude interpretovat datum/vzorkčas/1970-01-01 jako "Závazky pro datum lze vytvořit z omezení doby odběru vzorků pomocí tohoto time\_precision .." Skutečná konverze omezení je složitější, ale to je přehled. Použijte to, kdykoli je to důležité. Umožňuje ERDDAP™ pracovat efektivně s Cassandrou. Pokud tento vztah mezi sloupcemi existuje v tabulce Cassandra a neřeknete ERDDAP™ , datový soubor bude bolestivě pomalý v ERDDAP™ a využít tuny zdrojů Cassandry.
• Jednoduché Klíče k rozdělení hodnot -- Pokud chcete ERDDAP™ Soubor dat pro práci pouze s jednou hodnotou jednoho diskového klíče, upřesněte oddílKeySourceName=hodnota . Nepoužívejte citace pro numerický sloupec, například deviceid=1007 Používat citace pro String sloupec, například, standid="Point Pinos"
• Nastavení dat Default Sort Order -- Pořadí klíče pro rozdělení< dataVariable > je v datasets.xml určuje výchozí pořadí výsledků od Cassandry. Uživatelé samozřejmě mohou požádat o jiný druh objednávky pro daný soubor výsledků zadáním & orderBy (" čárka oddělený seznam proměnných ") až do konce jejich dotazu.
• Ve výchozím nastavení, Cassandra a ERDDAP™ zacházet s názvy sloupců necitlivým způsobem. Ale když to nastavíš sloupecNázevQuotes " ERDDAP™ bude zacházet s názvy sloupců Cassandra v případě citlivém způsobem.  

<oddíl KeyCSV>

Je-li uvedeno toto, ERDDAP™ použije ho místo toho, aby požádal Cassandru o oddíl Klíčové informace při každém opětovném načtení souboru údajů. To poskytuje seznam různých hodnot klíče oddílu, v pořadí budou použity. Časy musí být specifikovány jako sekundy od 1970-01-01T00:00:00Z. Ale existují také dva zvláštní alternativní způsoby, jak určit časy (každá zakódovaná jako řetězec) :

1. čas (aISO8601 Čas) (MŮŽE být zakódován jako řetězec)
2. "časy (anISO8601StartTime, strideSecond, stopTime) " (Musí být zakódován jako řetězec)
   stop Čas může být ISO8601 Čas nebo " now- čas nUnits (např. " now- 3 minuty") . stop Čas nemusí přesně odpovídat startu. Čas + x krokSecond. Hádka s časy () hodnota dostane rozšířen do více řádků před každým dotazem, takže seznam oddílu Klíče mohou být vždy dokonale aktuální. Například,

    <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>

expanduje do této tabulky kombinací diskových klíčů:

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

<ClosterColumnSourceNames>

Cassandra akceptuje omezení SQL na klastry, které tvoří druhou část primárního klíče (za rozdělovacím klíčem (án) ) . Takže je důležité identifikovat tyto sloupce pomocí<closterColumnSourceNames>. To umožňuje ERDDAP™ pracovat efektivně s Cassandrou. Pokud jsou shluky sloupců a neřeknete ERDDAP , datový soubor bude bolestivě pomalý v ERDDAP™ a využít tuny zdrojů Cassandry.

• Například,<ClosterColumnSourceNames> myClusterColumn1, myClusterColumn2 </clusterColumnSourceNames>
• Pokud tabulka Cassandra nemá žádné sloupce, buď nespecifikujte<closterColumnSourceNames> nebo jej zadat bez hodnoty.
• Ve výchozím nastavení, Cassandra a ERDDAP™ zacházet s názvy sloupců necitlivým způsobem. Ale když to nastavíš sloupecNázevQuotes " ERDDAP™ bude zacházet s názvy sloupců Cassandra způsobem citlivým na případy.  

<indexColumnSourceNames>

Cassandra přijímá '=' omezení na sekundární index sloupce, které jsou sloupce, které jste výslovně vytvořili indexy pro přes

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

(Ano, závorky jsou nutné.)
Takže je velmi užitečné, když identifikujete tyto sloupce pomocí<indexColumnSourceNázevs>. To umožňuje ERDDAP™ pracovat efektivně s Cassandrou. Pokud existují sloupce indexu a neřeknete ERDDAP , Některé dotazy budou zbytečné, bolestivě pomalé v ERDDAP™ a využít tuny zdrojů Cassandry.

• Například,<indexColumnSourceNázevs> myIndexColumn1, myIndexColumn2 </indexColumnSourceNázevs>
• Pokud tabulka Cassandra nemá žádné sloupce indexu, buď nespecifikujte<indexColumnSourceNames>, nebo jej zadat bez hodnoty.
• Cassandra indexy nejsou jako databázové indexy. Cassandra indexy pomáhají pouze s '=' omezení. A jsou jen doporučené pro sloupce, které mají mnohem méně odlišných hodnot než celkové hodnoty.
• Ve výchozím nastavení, Cassandra a ERDDAP™ zacházet s názvy sloupců necitlivým způsobem. Ale když to nastavíš sloupecNázevQuotes " ERDDAP™ bude zacházet s názvy sloupců Cassandra způsobem citlivým na případy.  

<maxRequestFraction>

Kdy? ERDDAP™ (re) zatížení souboru dat, ERDDAP™ dostane od Cassandry seznam různých kombinací diskových klíčů. Pro obrovský datový soubor bude počet kombinací obrovský. Pokud chcete zabránit žádosti uživatelů požadovat většinu nebo všechny soubory údajů (nebo dokonce žádost, která se ptá ERDDAP™ stáhnout většinu nebo všechny údaje za účelem dalšího filtrování) , můžete říct ERDDAP™ pouze povolit žádosti, které snižují počet kombinací prostřednictvím<maxRequestFraction>, což je číslo plovoucího bodu mezi 1e-10 (Což znamená, že žádost nemůže potřebovat více než jednu kombinaci v miliardě.) a 1 (selhání, což znamená, že žádost může být pro celý soubor údajů) . Například pokud má datový soubor 10000 různých kombinací diskových klíčů a maxRequestFraction je nastaven na 0,1, pak žádosti, které potřebují data ze 1001 nebo více kombinací, vytvoří chybovou zprávu, ale budou povoleny žádosti, které potřebují údaje od 1000 nebo méně kombinací.

Obecně platí, že čím větší soubor dat, tím nižší byste měli nastavit<maxRequestFraction>. Takže to můžete nastavit na 1 pro malý datový soubor, 0,1 pro středně velký datový soubor, 0,01 pro velký datový soubor a 0,0001 pro obrovský datový soubor.

Tento přístup zdaleka není dokonalý. To povede k tomu, že některé rozumné žádosti budou zamítnuty a některé příliš velké žádosti budou povoleny. Je to však obtížný problém a toto řešení je mnohem lepší než nic.

Cassandra subsetVariables

Stejně jako u ostatních datových souborů v programu EDDTable můžete zadat seznam oddělených čárkami< dataVariable > destinationName s v globálním atributu nazvaném " subsetVariables " určit proměnné, které mají omezený počet hodnot. Soubor pak bude mít webovou stránku .subset a zobrazí seznamy různých hodnot pro tyto proměnné v seznamech drop-down na mnoha webových stránkách.

Včetně proměnných klíčů pro rozdělení a statických sloupců v seznamu je STRONGLIE E NCO Uraged. Cassandra bude moci vytvořit seznam různých kombinací velmi rychle a snadno pokaždé, když je soubor dat znovu načten. Výjimkou jsou klíče od časoznaku, které jsou hrubými verzemi některého jiného sloupce časového razítka -- je pravděpodobně nejlepší je vynechat ze seznamu subsetVariables protože existuje velké množství hodnot a nejsou příliš užitečné pro uživatele.

Pokud zahrnete nerozdělovací klíč, nestatické proměnné do seznamu, bude pravděpodobně velmi Výpočetně drahé pro Cassandra pokaždé, když je soubor dat znovu načten, protože ERDDAP™ musí procházet každý řádek datového souboru, aby informace vygeneroval. Ve skutečnosti, dotaz pravděpodobně selže. Takže, až na velmi malé soubory dat, toto je STRONGLY DISCOURAGED.

DataTypes Cassandra

Protože je tu nějaká nejednoznačnost, o které Datové typy Cassandra mapa, na kterou ERDDAP™ datové typy, musíte zadat [<dataType>] (#datatyp) tag pro každého [< dataVariable >] (# Dataproměnná) říct ERDDAP™ které dataType použít. Standard ERDDAP™ údaje Typy (a nejčastější odpovídající datové typy Cassandra) jsou:

• boolean (boolean) , které ERDDAP™ pak obchody jako byty
• byte (int, pokud je rozsah -128 až 127)
• krátké (int, pokud je rozsah -32768 až 32767)
• int (int, counter?, varint?, pokud je dosah -2147483648 až 2147483647)
• dlouhé (bigint, pult?, varint?, je-li rozsah -9223372036854775808 až 922337236854775807)
• plavat (plavat)
• dvakrát (dvojité desetinné číslo (s možnou ztrátou přesnosti) , časové razítko)
• char (ascii nebo text, pokud nikdy nemají více než 1 znak)
• String (Ascii, text, varchar, inet, uuid, timeuid, blob, mapa, set, list?)

Cassandra's časové razítko je zvláštní případ: použití ERDDAP 's dvojími údaji Typ.

Pokud zadáte String dataType v ERDDAP™ pro Cassandra mapu, nastavit nebo seznam, mapa, nastavit nebo seznam v každém řádku Cassandra bude převeden na jeden řetězec v jednom řádku v ERDDAP™ stůl. ERDDAP™ má alternativní systém pro seznamy; viz níže.

typ Seznamy... ERDDAP 's [<dataType>] (#datatyp) značka pro Cassandru dataVariable s může zahrnovat pravidelné ERDDAP™ údaje Typy (viz výše) plus několik speciálních datových typů, které lze použít pro sloupce seznamu Cassandra: booleanList, byteList, ubyteList, shortList, intList, uintList, longList, ulongList, floatList, doubleList, charList, StringList. Když jeden z těchto sloupců seznamu je ve výsledcích jsou předány do ERDDAP™ , každý řádek zdrojových dat bude rozšířen na seznam. velikost () řádky údajů v ERDDAP ; jednoduchá data Typy (např. int) v tomto řádku zdrojových dat bude duplikován seznam. velikost () krát. Pokud výsledky obsahují více než jeden seznam proměnných, všechny seznamy v daném řádku údajů musí mít stejnou velikost a musí být "paralelní" seznamy nebo ERDDAP™ vytvoří chybovou zprávu. Například pro měření proudů z ADCP, hloubka \[ 0 \] , uCurrent \[ 0 \] , vCurrent \[ 0 \] , a zCurrent \[ 0 \] jsou všechny související a hloubka \[ 1 \] , uCurrent \[ 1 \] , vCurrent \[ 1 \] , a zCurrent \[ 1 \] jsou všichni příbuzní, ... Alternativně, pokud nechcete ERDDAP™ rozšířit seznam do více řádků ERDDAP™ tabulka, zadejte String jako dataVariable 's údaji Zadejte tak, aby celý seznam byl reprezentován jako jeden String v jednom řádku ERDDAP .

Cassandra TimeStamp Data

Data Cassandry jsou vždy obeznámena s časovými pásmy. Pokud zadáte data časového razítka bez upřesnění časového pásma, Cassandra předpokládá, že časové razítko používá místní časové pásmo.

ERDDAP™ podporuje data časového razítka a vždy uvádí data v Zulu /GMT časové pásmo. Takže pokud zadáte data časového razítka v Cassandra pomocí jiného časového pásma než Zulu /GMT, nezapomeňte, že musíte udělat všechny dotazy pro data časového razítka v ERDDAP™ s použitím Zulu /GMT časové pásmo. Takže nebuď překvapená, když hodnoty časového razítka, které vycházejí z ERDDAP jsou posunuty o několik hodin kvůli přepínání časového pásma z lokálního na Zulu Čas GMT.

• In ERDDAP 's datasets.xml , v< dataVariable > tag pro proměnnou časového razítka, nastaveno

          <dataType>double</dataType>  

a< addAttributes > nastaveno

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

• Návrh: Pokud jsou data časovým rozsahem, je užitečné, aby se hodnoty časového razítka vztahovaly na střed implikovaného časového rozsahu. (například poledne) . Například pokud má uživatel data za 2010-03-26T13:00Z z jiného datového souboru a chce nejbližší data z tohoto souboru souborů Cassandra, která mají data za každý den, pak data za 2010-03-26T12:00Z (představující údaje Cassandra pro uvedené datum) je samozřejmě nejlepší (oproti půlnoci před nebo po, kde je méně zřejmé, co je nejlepší) .
• ERDDAP™ má nástroj pro Převést numerické Čas do/z doby řetězce .
• Viz Jak ERDDAP™ Obchoduje s časem .  

Integer nulls

Cassandra podporuje nuly v Cassandra int ( ERDDAP™ int) a velký ( ERDDAP™ dlouhé) sloupce, ale ERDDAP™ nepodporuje true nulles pro žádný integer datový typ. Ve výchozím nastavení, Cassandra integer nulls bude převeden v ERDDAP™ do 2147483647 pro int sloupce nebo 9223372036854775807 pro dlouhé sloupy. Tyto se objeví jako "NaN" v některých typech textových výstupních souborů (například .csv) , "" v jiných typech textových výstupních souborů (například: .htmlTable ) , a zvláštní číslo (2147483647 pro chybějící int hodnoty) v jiných typech souborů (například binární soubory jako .nc a rohož) . Uživatel může vyhledávat řádky dat s tímto typem chybějící hodnoty odkazem na "NaN," např. "&windSpeed=NaN."

Pokud použijete nějakou jinou celočíselnou hodnotu k označení chybějících hodnot v tabulce Cassandra, prosím, uveďte tuto hodnotu v datasets.xml :

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

Pro Cassandra plovoucí bod sloupce, nuly se převést na NaNs v ERDDAP . Pro datové typy Cassandra, které jsou převedeny na Strings in ERDDAP™ , nuly jsou převedeny na prázdné Strings. To by neměl být problém.

"WARNING: Re-příprava již připravený dotaz"

• "WARNING: Re-příprava již připravený dotaz" v tomcat /logs/catalina.out (nebo nějaký jiný soubor protokolu Tomcat)
  Cassandra dokumentace říká, že je problém, pokud stejný dotaz je provedena do připravenéStatement dvakrát (nebo více) . (Vidíš tohle? hlášení chyby .) Aby se vyhnula naštvání Cassandry, ERDDAP™ caches všechny PřipravenéStatements tak, aby je mohl znovu použít. Tato cache je ztracena, pokud / když Tomcat / ERDDAP™ je restartován, ale myslím, že je to v pořádku, protože připravené stavy jsou spojeny s danou relací (mezi Java a Cassandra) , který je také ztracen. Takže můžete vidět tyto zprávy. Neznám žádné jiné řešení. Naštěstí je to varování, ne chyba. (Ačkoli Cassandra hrozí, že to může vést k problémům s výkonem) .

Cassandra tvrdí, že připravené stavy jsou navždy dobré, takže ERDDAP 's cache PreparedStatements by nikdy neměla být zastaralá/neplatná. Jestli to není pravda a dostanete chyby ohledně zastaralého stavu, který je zastaralý/neplatný, pak musíte restartovat ERDDAP™ vymazat ERDDAP 's cache připravených stavů.

Bezpečnost Cassandry

Viz Zabezpečení Cassandry

Při práci s Cassandrou musíte dělat věci tak bezpečně a bezpečně, jak je to možné, abyste nedovolili škodlivému uživateli poškodit Vaši Cassandru nebo získat přístup k datům, ke kterým by neměli mít přístup. ERDDAP™ Snaží se také dělat věci bezpečně.

• Povzbuzujeme vás, abyste to připravili. ERDDAP™ připojit se k Cassandra jako uživatel Cassandra, který má přístup pouze k relevantní tabulka (án) a má pouze práva na čtení.
• Doporučujeme vám nastavit spojení od ERDDAP™ Cassandra tak, aby to
  • vždy používá SSL,
  • pouze umožňuje připojení z jedné IP adresy (nebo jeden blok adres) a z jednoho ERDDAP™ uživatele a
  • pouze přenáší hesla ve své MD5 hashed formě.
• \[ ZNÁMÝ PROBLÉM \] SpojeníProperties (včetně hesla!) jsou uloženy jako prostý text v datasets.xml . Nenašli jsme způsob, jak nechat správce zadat heslo Cassandra během ERDDAP 's startup in Tomcat (který nastane bez vstupu uživatele) , takže heslo musí být přístupné v souboru. Aby to bylo bezpečnější:
• Ty. (vá ERDDAP™ Správce) měl by být vlastníkem datasets.xml a mají READ a WRITE přístup.
• Vytvořte skupinu, která zahrnuje pouze uživatelskou=tomcat. Použijte chgrp, aby se skupina pro datasets.xml , jen s oprávněním číst.
• Použít chmod pro přiřazení práv O-rwx (žádný přístup READ nebo WRITE pro "jiné" uživatele) místo datasets.xml .
• Až dovnitř ERDDAP™ , heslo a další vlastnosti připojení jsou uloženy v "soukromém" Java proměnné.
• Žádosti klientů jsou rozebrány a zkontrolovány platnost před generováním CQL žádostí o Cassandru.
• Žádosti o aplikaci Cassandra se podávají s CQL Bound/PreparedStatements, aby se zabránilo aplikaci CQL. Cassandra je v každém případě méně náchylná k CQL injekci než tradiční databáze SQL injekce .  

Cassandra rychlost

Cassandra může být rychlá nebo pomalá. Existují věci, které můžete udělat, aby to rychle:

• Obecně - Povaha CQL je, že dotazy jsou deklarativní . Jen určují, co uživatel chce. Neobsahují specifikace nebo tipy, jak má být dotaz řešen nebo optimalizován. Takže neexistuje žádná možnost pro ERDDAP™ generovat dotaz takovým způsobem, že to pomáhá Cassandra optimalizovat dotaz (nebo jakýmkoli způsobem určuje, jak má být dotaz řešen) . Obecně je na správci Cassandry, aby věci naplánovali. (například indexy) optimalizovat pro určité typy dotazů.  
• Upřesnění sloupců časového razítka, které jsou spojeny s hrubým přesným časovým znakem přes [<oddíl Název KeySource >] (#partitionkeysourcenames) je nejdůležitější způsob, jak pomoci ERDDAP™ efektivně pracovat s Cassandrou. Pokud tento vztah existuje v tabulce Cassandra a neřeknete ERDDAP™ , datový soubor bude bolestivě pomalý v ERDDAP™ a využít tuny zdrojů Cassandry.  
• Upřesnění sloupců seskupení prostřednictvím [<ClosterColumnSourceNames>] (#clustercolumsourcenames) je druhý nejdůležitější způsob, jak pomoci ERDDAP™ efektivně pracovat s Cassandrou. Pokud jsou shluky sloupců a neřeknete ERDDAP , velká podmnožina možných dotazů na data bude zbytečně, bolestivě pomalé v ERDDAP™ a využít tuny zdrojů Cassandry.  
• Značka Indexy pro běžné proměnné -- Můžete urychlit několik dotazů vytvořením indexů pro sloupce Cassandra, které jsou často omezeny s "=" omezení.

Cassandra nemůže dělat indexy pro seznam, množinu nebo mapu sloupců.

• Upřesnění sloupců indexu prostřednictvím [<indexColumnSourceNázevs>] (#indexcolunctionsourcenames) je důležitý způsob, jak pomoci ERDDAP™ efektivně pracovat s Cassandrou. Pokud existují sloupce indexu a neřeknete ERDDAP , některé dotazy na data budou zbytečné, bolestivě pomalé v ERDDAP™ a využít tuny zdrojů Cassandry.  

Statistiky Cassandry

• "Cassandra stats" Diagnostické zprávy -- Za každou ERDDAP™ uživatelský dotaz do souboru Cassandra, ERDDAP™ vytiskne řádek v souboru protokolu, velkýRodič rodičů /logs/log.txt, s některými statistikami souvisejícími s dotazem, například,

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

Použití čísel v příkladu výše, to znamená:

• Kdy? ERDDAP™ poslední (re) Cassandra řekla: ERDDAP™ že existuje 10000 různých kombinací diskových klíčů. ERDDAP™ cache všechny odlišné kombinace v souboru.
• Vzhledem k omezením uživatele, ERDDAP™ identifikovány 2 kombinace z 10000, které mohou mít požadované údaje. Takže, ERDDAP™ 2 hovory do Cassandry, jeden pro každou kombinaci diskových klíčů. (To Cassandra vyžaduje.) Je zřejmé, že je obtížné, pokud velký datový soubor má velký počet kombinací diskových klíčů a daný požadavek není drasticky snížit, že. Můžete požadovat, aby každý požadavek snížit klíčový prostor nastavením [<maxRequestFraction>] (#maxrequestfraction) . Tady, 2/10000=2e-4, což je méně než maxRequestFraction (0, 1) Takže žádost byla povolena.
• Po uplatnění omezení na diskové klíče, sloupce klastrů a indexové sloupce které poslal ERDDAP™ , Cassandra vrátil 1200 řádků dat do ERDDAP™ v ResultSet.
• Výsledek Set musel mít údaje Type= nějaký typ Seznam sloupce (s průměrem 10 položek na seznam) , protože ERDDAP™ Rozšíření 1200 řad z Cassandry na 12000 řad ERDDAP .
• ERDDAP™ vždy aplikuje všechna omezení uživatele na data z Cassandry. V tomto případě omezení, která Cassandra nezvládla, snížila počet řádků na 7405. To je počet řádků odeslaných uživateli.

Nejdůležitější použití těchto diagnostických zpráv je zajistit, aby ERDDAP™ Dělá to, co si myslíš, že dělá. Jestli ne. (Například, není to snížení počtu odlišných kombinací, jak se očekávalo?) Pak můžete použít informace, abyste zjistili, co se děje.  

• Výzkum a experiment najít a nastavit lépe [<spojeníProperty>] (#cassandra-connectionproperty) Je.  
• Zkontrolujte rychlost síťového spojení mezi Cassandrou a ERDDAP . Pokud je spojení pomalé, zkuste to zlepšit. Nejlepší je, když ERDDAP™ běží na serveru připojeném ke stejnému (rychle) přepnout jako server běžící uzel Cassandra, ke kterému jste připojeni.  
• Prosím, buď trpělivý. Informace si pozorně přečtěte zde a v dokumentaci Cassandry. Experiment. Zkontroluj si práci. Pokud Cassandra... ERDDAP™ spojení je stále pomalejší, než jste očekávali, prosím, uveďte schéma vašeho stolu Cassandra a ERDDAP™ část datasets.xml a vidět naše oddíl o získání dodatečné podpory .  
• Pokud všechno ostatní selže, zvážit uložení údajů ve shromažďování NetCDF v3 .nc soubory (zvláště .nc Soubory, které používají CF Geometrie diskrétního odběru vzorků (DSG) Kontiguous Ragged Array datové struktury a tak lze zacházet s ERDDAP 's EDDTableFromNcCFFiles ) . Pokud jsou logicky organizovaní (každý s údaji pro kus prostoru a času) , ERDDAP™ může z nich velmi rychle extrahovat data.  

EDDTableFromCassandra kostra XML

  <dataset type="EDDTableFromCassandra" datasetID\="..." active\="..." >
      <ipAddress>...</ipAddress>
        <!-- The Cassandra URL without the port number, for example,
        127.0.0.1 REQUIRED. -->
      <connectionProperty name="name">value</connectionProperty>
        <!-- The names (for example, "readTimeoutMillis") and values
          of the Cassandra properties that ERDDAP™ needs to change.
          0 or more. -->
      <keyspace>...</keyspace> <!-- The name of the keyspace that has
        the table. REQUIRED. -->
      <tableName>...</tableName> <!-- The name of the table, default = "".
        REQUIRED. -->
      <partitionKeySourceNames>...<partitionKeySourceNames>
        <!-- REQUIRED. -->
      <clusterColumnSourceNames>...<clusterColumnSourceNames>
        <!-- OPTIONAL. -->
      <indexColumnSourceNames>...<indexColumnSourceNames> <!-- OPTIONAL. -->
      <maxRequestFraction>...<maxRequestFraction>
        <!-- OPTIONAL double between 1e-10 and 1 (the default). -->
      <columnNameQuotes>...<columnNameQuotes> <!-- OPTIONAL.
        Options: \[nothing\] (the default) or ". -->
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <dataVariable>...</dataVariable> <!-- 1 or more.
         Each dataVariable MUST include a <dataType> tag. See
           Cassandra DataTypes.
         For Cassandra timestamp columns, set dataType=double and
         units=seconds since 1970-01-01T00:00:00Z -->
  </dataset>

EDDTableFromDapSekvence

EDDTableFromDapSekvence zpracovává proměnné v rámci 1- a 2-úrovňové posloupnosti od DAP servery jako např. DAP PE (vhttps://www.pmel.noaa.gov/epic/software/dapper/, nyní přerušen) .

• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili. Informace, které potřebujete, můžete získat při pohledu na soubory DDS zdrojových dat a DAS ve vašem prohlížeči (přidáním .das a .dds do sourceUrl (příklad bylhttps://dapper.pmel.noaa.gov/dapper/epic/tao\_time\_series.cdp.dds).

• Proměnná je v DAP sekvence, pokud odpověď .dds ukazuje, že datová struktura drží proměnnou je "sekvence" (případ necitlivý) .

• V některých případech uvidíte sekvenci v sekvenci, dvouúrovňovou sekvenci -- EDDTableFromDapSekvence je také zpracovává.

EDDTableFromDapSekvenční kostra XML

  <dataset type="EDDTableFromDapSequence" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <outerSequenceName>...</outerSequenceName>
        <!-- The name of the outer sequence for DAP sequence data.
        This tag is REQUIRED. -->
      <innerSequenceName>...</innerSequenceName>
        <!-- The name of the inner sequence for DAP sequence data.
        This tag is OPTIONAL; use it if the DAP data is a two level
        sequence. -->
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <sourceCanConstrainStringEQNE>true|false</sourceCanConstrainStringEQNE>
      <sourceCanConstrainStringGTLT>true|false</sourceCanConstrainStringGTLT>
      <sourceCanConstrainStringRegex>...</sourceCanConstrainStringRegex>
      <skipDapperSpacerRows>...</skipDapperSpacerRows>
        <!-- skipDapperSpacerRows specifies whether the dataset
        will skip the last row of each innerSequence other than the
        last innerSequence (because Dapper servers put NaNs in the
        row to act as a spacer). This tag is OPTIONAL. The default
        is false. It is recommended that you set this to true for
        all Dapper sources and false for all other data sources. -->
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <dataVariable>...</dataVariable> <!-- 1 or more -->
    </dataset>

EDDtableFromDatabase

EDDtableFromDatabase zpracovává data z jedné relační databáze nebo pohled.

Jedna tabulka nebo pohled

Pokud data, která chcete sloužit, jsou ve dvou nebo více tabulkách (a proto je třeba join k získání údajů z obou tabulek najednou) , musíte udělat jeden denormalizované (již připojen) Tabulka nebo pohled se všemi údaji, které chcete zpřístupnit jako jeden datový soubor v ERDDAP .

U velkých, komplexních databází může mít smysl oddělit několik částí jako denormalizované tabulky, každá s jiným typem dat, které se stanou samostatnými soubory dat v ERDDAP .

Příprava denormalizované tabulky pro použití v ERDDAP™ Možná to zní jako šílený nápad. Prosím, věřte nám. Existuje několik důvodů, proč ERDDAP™ pracuje s denormalizovanými tabulkami:

• Pro uživatele je to mnohem jednodušší. Kdy? ERDDAP™ prezentuje soubor dat jako jeden, jednoduchý, denormalizovaný, jeden stůl, je velmi snadné pro každého pochopit data. Většina uživatelů nikdy neslyšel o normalizovaných tabulek, a velmi málo pochopit klíče, cizí klíče, nebo tabulky se připojí, a téměř jistě neznají podrobnosti různých typů spojení, nebo jak určit SQL, aby se připojili (nebo více spojení) Správně. Používání denormalizovaného stolu se vyhýbá všem těmto problémům. Tento důvod sám o sobě ospravedlňuje použití denormalizované jediné tabulky pro prezentaci datového souboru ERDDAP™ uživatelé.  
• Normalizované tabulky (více tabulek souvisejících podle klíčových sloupců) jsou skvělé pro ukládání dat v databázi. Ale i v SQL, výsledek, který je vrácen k uživateli je denormalizovaný (Připojeno) Jeden stůl. Takže se zdá rozumné prezentovat soubor dat uživatelům jako obrovskou, denormalizovanou, jedinou tabulku, ze které pak mohou požadovat podskupiny (např. ukažte mi řádky tabulky, kde teplota > 30) .  
• Můžete udělat změny pro ERDDAP™ bez výměny stolů. ERDDAP™ má několik požadavků, které mohou být odlišné od toho, jak jste založili svou databázi. Například, ERDDAP™ vyžaduje, aby data časového razítka byla uložena v polích "časové razítko s časovým pásem." Vytvořením oddělené tabulky/pohledu pro ERDDAP™ , Můžete provést tyto změny, když uděláte denormalizovaný stůl pro ERDDAP . Nemusíte tedy měnit své stoly.  
• ERDDAP™ bude rekonstruovat některé z struktury standardizovaných tabulek. Můžete určit, které sloupce dat pocházejí z tabulek "vnější," a proto mají omezený počet různých hodnot. ERDDAP™ bude shromažďovat všechny různé kombinace hodnot v těchto sloupcích a prezentovat je uživatelům na speciální . Podmnožina webové stránky, která pomáhá uživatelům rychle vybrat podmnožiny datového souboru. Rozdílné hodnoty pro každý sloupec jsou rovněž uvedeny v seznamech drop-down na ostatních webových stránkách datového souboru.  
• Denormalizovaná tabulka dělá data předání od vás do ERDDAP Pomalu správce. Jste expert na tento soubor dat, takže dává smysl, abyste rozhodovali o tom, které tabulky a které sloupce se připojit a jak se k nim připojit. Takže nám nemusíš nic dávat. (nebo hůř, koncoví uživatelé) Několik tabulek a podrobné pokyny, jak se k nim připojit, stačí nám dát přístup k denormalizovanému stolu.  
• Denormalizovaná tabulka umožňuje efektivní přístup k datům. Denormalizovaná forma je obvykle rychlejší přístup než normalizovaná forma. Spojení může být pomalé. Několik spojení může být velmi pomalé.  

Za účelem získání dat ze dvou nebo více tabulek v databázi do ERDDAP™ , Existují tři možnosti:  

• Doporučená volba: S daty z denormalizované tabulky si můžete vytvořit soubor čárky nebo záložky oddělené hodnoty. Pokud je soubor obrovský, pak dává smysl vytvořit několik souborů, každý s soudržnou podmnožinu denormalizované tabulky (například údaje z menšího časového rozmezí) .

Velkou výhodou je, že ERDDAP™ bude schopen zvládnout uživatelské požadavky na data bez dalšího úsilí vaší databází. Takže... ERDDAP™ nebude zátěží pro vaši databázi nebo bezpečnostní riziko. To je nejlepší možnost za téměř všech okolností, protože ERDDAP™ obvykle získat data ze souborů rychleji než z databáze (Pokud jsme převést .csv soubory na .nc Soubory CF) . (Součástí je, že ERDDAP + soubory je systém pouze pro čtení a nemusí se zabývat změnami při poskytování KYSELINA (Atomie, konzistence, izolace, trvanlivost) .) Také, pravděpodobně nebudete potřebovat samostatný server, protože můžeme ukládat data na jednom z našich RAID a přístup k němu s existující ERDDAP™ na existujícím serveru.

• Možnost: Vytvoříte novou databázi na jiném počítači s denormalizovaným stolem. Vzhledem k tomu, že tato databáze může být zdarma a open source databáze jako MariaDB, MySQL, a PostgreSQL, tato volba nemusí stát hodně.

Velkou výhodou je, že ERDDAP™ bude schopen zvládnout uživatelské požadavky na data bez dalšího úsilí vaší aktuální databází. Takže... ERDDAP™ nebude zátěží pro vaši současnou databázi. To také eliminuje mnoho bezpečnostních obav, protože ERDDAP™ nebude mít přístup do vaší aktuální databáze.

• Odporná možnost: Můžeme se spojit. ERDDAP™ do vaší současné databáze. K tomu musíte:

  • Vytvořte oddělenou tabulku nebo zobrazení s denormalizovanou tabulkou dat.
  • Vytvořit uživatele "erddap," který má přístup pouze ke čtení pouze k denormalizované tabulce (án) .  

To je možnost, pokud se data mění velmi často a chcete dát ERDDAP™ uživatelům okamžitý přístup k těmto změnám; nicméně, i tak, může mít smysl použít volbu souboru výše a pravidelně (každých 30 minut?) nahradit soubor, který má dnešní data. Obrovské nevýhody tohoto přístupu jsou, že ERDDAP™ uživatelské požadavky budou pravděpodobně klást nesnesitelně velké břemeno na vaší databázi a že ERDDAP™ spojení představuje bezpečnostní riziko (I když můžeme minimalizovat/spravovat riziko) .

Výroba denormalizované tabulky nebo pohled na ERDDAP™ je dobrá příležitost udělat několik změn, které ERDDAP™ potřeby, způsobem, který neovlivňuje vaše původní stoly:

• Změna dat a časových polí/sloupců pro použití datového typu, který Postgres volá časové razítko s časovým pásem (nebo ekvivalent ve vaší databázi) . Časové značky bez informací časového pásma nefungují správně v ERDDAP .
• Vytvořit indexy pro sloupce, které uživatelé často hledají.
• Být velmi vědomi případ pole/název sloupce (například použijte všechny malé případy) když je píšeš.
• Nepoužívejte vyhrazená slova pro tabulku a pro názvy polí/sloupců.

Pokud potřebujete pomoc s denormalizovanou tabulkou nebo zobrazením, kontaktujte prosím správce databáze. Pokud chcete mluvit o celém tomto přístupu nebo strategii, jak to nejlépe udělat, prosím, e-mail Chris. John at noaa.gov .

databáze v datasets.xml

Je těžké vytvořit správnou datasets.xml informace potřebné pro ERDDAP™ navázat spojení s databází. Buď trpělivý. Buďte metodičtí.

• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

Generovat soubory dat Xml má tři speciální možnosti pro EDDTableFromDatabase:

1. Pokud vstoupíte "!!!LIST!!!!" (bez kotací) pro název katalogu zobrazí program seznam názvů katalogů.
2. Pokud vstoupíte "!!!LIST!!!!" (bez kotací) pro název schématu zobrazí program seznam názvů schémat.
3. Pokud vstoupíte "!!!LIST!!!!" (bez kotací) pro název tabulky program zobrazí seznam tabulek a jejich sloupců. První "!!!LIST!!!!" položka, kterou uděláte, je ten, který bude použit.

• Pečlivě si přečtěte všechny informace tohoto dokumentu o EDDTableFromDatabase.
• Většinu informací, které potřebujete k vytvoření XML pro datový soubor EDDTableFromDatabase, můžete shromáždit prostřednictvím kontaktu se správcem databáze a vyhledáváním na webu.
• I když databáze často zachází s názvy sloupců a názvy tabulek způsobem, který je citlivý na případ, jsou případ-citlivý v ERDDAP . Takže pokud chybová zpráva z databáze říká, že název sloupce je neznámý (například "Neznámý identifikátor= ' sloupec\_název '") i když víte, že existuje, zkuste použít všechny hlavní města, například, COLUMN\_NAME , což je často pravda, případ-citlivý verze názvu sloupce.
• úzce spolupracovat se správcem databáze, který může mít příslušné zkušenosti. Pokud datový soubor nenačte, přečtěte si chybová zpráva pečlivě zjistit proč.  

JDBC ovladač

• [JDBC ovladač a<Název řidiče >] (#jdbc-driver) -- Musíte získat příslušný JDBC 3 nebo JDBC 4 ovladač .jar soubor pro vaši databázi a Dej to tam. tomcat /webapps/erddap/WEB-INF/lib po instalaci ERDDAP . Pak ve tvém datasets.xml pro tento soubor údajů musíte uvést<DriverName> pro tohoto řidiče, který je (Bohužel) jiný než název souboru. Hledat na webu JDBC ovladač pro vaši databázi a ovladačJméno, že Java Musíš ho použít.

  • Pro MariaDB, zkuste https://mariadb.com/kb/en/about-the-mariadb-java-client/
    The<název řidiče > pro použití v datasets.xml (viz níže) je pravděpodobně org.mariadb.jdbc. Řidiči.
  • Pro MySQL a Amazon RDS, zkuste https://dev.mysql.com/downloads/connector/j/
    The<název řidiče > pro použití v datasets.xml (viz níže) je pravděpodobně com.mysql.jdbc. Řidiči.
  • Pro Oracle , zkuste https://www.oracle.com/database/technologies/appdev/jdbc-downloads.html . The<název řidiče > pro použití v datasets.xml (viz níže) je pravděpodobně oracle.jdbc.driver. Oracle Řidiči.
  • Pro Postgresql jsme dostali JDBC 4 řidiče z https://mvnrepository.com/artifact/org.postgresql/postgresql
    The<název řidiče > pro použití v datasets.xml (viz níže) je pravděpodobně Org.postgresql. Řidiči.
  • Pro SQL Server můžete získat JTDS JDBC ovladač od https://jtds.sourceforge.net . The<název řidiče > pro použití v datasets.xml (viz níže) je pravděpodobně net.sourceforge.jtds.jdbc. Řidiči.

Poté, co dáte JDBC ovladač .jar ERDDAP™ lib adresář, musíte přidat odkaz na že .jar soubor v .bat a / nebo .sh skript soubory pro GenerateDatasets Xml, DasDds, a ArchiveADataset, které jsou v tomcat /webapps/erddap/WEB-INF/ adresář; jinak získáte ClassNotFoundException při spuštění těchto skriptů.

Bohužel, JDBC je někdy zdrojem problémů. Ve své roli prostředníka ERDDAP™ a v databázi někdy provádí jemné změny standardní/generické databáze SQL požadovat, aby ERDDAP™ vytváří, čímž způsobuje problémy (například související identifikátory horních/nízkých případů a související datum/časová časová pásma ) . Prosím, buďte trpěliví, pozorně si přečtěte informace, zkontrolujte si svou práci a podívejte se na naši oddíl o získání dodatečné podpory .

Databáze<spojení Nemovitost>

• [<spojeníProperty>] (#Database-connectionproperty) -- V datasets.xml pro váš datový soubor musíte definovat několik spojení Majetkové značky ERDDAP™ jak se připojit k vaší databázi (například pro upřesnění uživatelského jména, hesla, ssl připojení a velikost webu ) . Pro každou situaci je to jiné a je trochu těžké to zjistit. Vyhledejte na webu příklady použití JDBC ovladače pro připojení do vaší databáze. The<connectionProperty> names (například "uživatel," "heslo" a "ssl") , a některé z připojeníProperty hodnoty lze nalézt vyhledáváním na webu pro "Vlastnosti připojení JDBC databáze Typ " (například: Oracle , MySQL, Amazon RDS, MariaDB, PostgreSQL) .  

Citlivost jmen a případů

• Citlivost případu - Ve výchozím nastavení EDDTableFromDatabase uvádí ANSI-SQL-standardní dvojité citace kolem názvu pole/sloupce ve SELECT příkazech v případě, že jste použili vyhrazené slovo jako název pole/sloupce nebo zvláštní znak v názvu pole/sloupce. Dvojité citace také zmařit některé typy SQL vstřikových útoků. You can tell ERDDAP™ používat ", " nebo žádné citace prostřednictvím<sloupecNázevQuotes> v datasets.xml pro tento datový soubor.

Pro mnoho databází, použití jakéhokoliv typu citací způsobí, že databáze pracovat s názvem pole / sloupce v případě citlivé způsobem (místo výchozího databázového případu necitlivý způsob) . Databáze často zobrazují názvy souborů/sloupců jako všechny vyšší případy, kdy je ve skutečnosti citlivá forma jiná. In ERDDAP™ , Prosím vždy pokládejte názvy sloupců databáze za citlivé případy.

• Pro Marii DB, musíte spustit databázi s \---sql-mode=ANSI\_QUOTES .
• Pro MySQL a Amazon RDS musíte spustit databázi s \---sql-mode=ANSI\_QUOTES .
• Oracle podporuje ANSI-SQL-standardní dvojité uvozovky ve výchozím nastavení .
• PostgreSQL standardně podporuje dvojcitace ANSI-SQL.

Nepoužívejte rezervované slovo pro databázi, katalog, schéma nebo jméno tabulky. ERDDAP™ Nedává jim to uvozovky.

Pokud je to možné, použijte při vytváření tabulky databáze všechny malé případy pro databázi, katalog, schémata, názvy tabulek a názvy polí (nebo pohled) a při odkazování na pole/název sloupce v datasets.xml v ERDDAP . Jinak můžete dostat chybovou zprávu s nápisem databáze, katalog, schéma, tabulka a/nebo pole nebyla nalezena. Pokud dostanete chybovou zprávu, zkuste použít verzi citlivou na případ, veškerou verzi v horním případě a všechny malé verze názvu v ERDDAP . Jeden z nich může fungovat. Pokud ne, musíte změnit název databáze, katalogu, schématu a/nebo tabulky na všechny malé případy.

Databáze<údaje Typ>

• Databáze [<dataType>] (#datatyp) Tagy... Protože je tu nějaká nejednoznačnost, o které databázové datové typy mapa, na kterou ERDDAP™ datové typy, musíte zadat [<dataType>] (#datatyp) tag pro každého [< dataVariable >] (# Dataproměnná) říct ERDDAP™ které dataType použít. Součástí problému je to, že různé datové soubory používají různé termíny pro různé datové typy - takže se vždy snažte odpovídat definicím, nejen jménům. Viz popis standardní ERDDAP™ údaje Typy , který zahrnuje odkazy na odpovídající datové typy SQL. Datum a časové razítko jsou zvláštní případy: použití ERDDAP 's dvojími údaji Typ.  

Databáze Datum Čas Data

Některé časové sloupce databázových dat nemají výslovné časové pásmo. Takové sloupy jsou pro nás problém. ERDDAP . Databáze podporují pojem data (s časem nebo bez) bez časového pásma jako přibližného rozsahu času. Ale... Java (a tak ERDDAP ) se zabývá pouze okamžitým datem + časy s časovým pásem. Takže možná víte, že data data data jsou založena na místním časovém pásmu (též s šetřícím časem denního světla) nebo GMT/ Zulu časové pásmo, ale Java (a ERDDAP ) Ne. Původně jsme si mysleli, že bychom mohli tento problém vyřešit. (Například upřesněním časového pásma pro sloupec) , ale databáze+JDBC+ Java interakce z toho udělaly nespolehlivé řešení.

• Takže, ERDDAP™ vyžaduje, abyste v databázové tabulce uložili všechna data data data a data data data databázového datového typu, který odpovídá typu JDBC "timestrom s časovým pásem" (ideálně, že používá GMT/ Zulu časové pásmo) .
• In ERDDAP 's datasets.xml , v< dataVariable > tag pro proměnnou časového razítka, nastaveno

    <dataType>double</dataType>

a< addAttributes > nastaveno

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

• Návrh: Pokud jsou data časovým rozsahem, je užitečné, aby se hodnoty časového razítka vztahovaly na střed implikovaného časového rozsahu. (například poledne) . Například pokud má uživatel data pro 2010-03-26T13:00Z z jiného datového souboru a chce nejbližší data z databázového datového souboru, který má data za každý den, pak databázová data pro 2010-03-26T12:00Z (představující údaje pro uvedené datum) je samozřejmě nejlepší (oproti půlnoci před nebo po, kde je méně zřejmé, co je nejlepší) .
• ERDDAP™ má nástroj pro Převést numerické Čas do/z doby řetězce .
• Viz Jak ERDDAP Obchoduje s časem .

Integer nulls

Databáze podporují nuly v celé řadě (int, drobounký, malinký) sloupce, ale ERDDAP™ nepodporuje pravé nuly. Databáze nulls bude převedena v ERDDAP™ 127 pro bytové sloupce, 255 pro ubytové sloupce, 32767 pro krátké sloupce, 65535 pro krátké sloupce, 2147483647 pro int sloupce, 4294967295 pro uint sloupce, 9,223,372,036,854,775,807 pro dlouhé sloupce, nebo 184467407370955115 pro dlouhé sloupce. Pokud použijete tyto výchozí hodnoty, identifikujte prosím tyto missing\_value s pro uživatele datového souboru v ERDDAP™ s

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

nebo

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

Alternativně můžete použít " missing\_value " atribut místo "\_FillValue." Generovat soubory dat Xml automaticky přidá tyto atributy \_FillValue, když generuje navrhované datasets.xml pro databázové soubory.

Pro databázi plovoucích bodů sloupce, nuly se převést na NaNs v ERDDAP . Pro databázové datové typy, které jsou převedeny do Strings in ERDDAP™ , nuly jsou převedeny na prázdné Strings.

Bezpečnost databáze

• Při práci s databázemi musíte dělat věci tak bezpečně a bezpečně, jak je to možné, abyste zabránili tomu, aby škodlivý uživatel poškodil vaši databázi nebo získal přístup k datům, ke kterým by neměl mít přístup. ERDDAP™ Snaží se také dělat věci bezpečně.
  • Zvažte replikování, na jiném počítači, databáze a databázové tabulky s daty, které chcete ERDDAP™ sloužit. (Ano, pro komerční databáze jako Oracle To zahrnuje dodatečné licenční poplatky. Ale pro databáze open source jako PostgreSQL, MySQL, Amazon RDS a MariaDB to nic nestojí.) To vám dává vysokou úroveň bezpečnosti a také zabraňuje ERDDAP™ žádosti o zpomalení původní databáze.
  • Povzbuzujeme vás, abyste to připravili. ERDDAP™ připojit se k databázi jako uživatel databáze, který má přístup pouze k relevantní databáze (án) a má pouze práva na čtení.
  • Doporučujeme vám nastavit spojení od ERDDAP™ do databáze tak, aby
    • vždy používá SSL,
    • pouze umožňuje připojení z jedné IP adresy (nebo jeden blok adres) a z jednoho ERDDAP™ uživatele a
    • pouze přenáší hesla ve své MD5 hashed formě.
  • \[ ZNÁMÝ PROBLÉM \] SpojeníProperties (včetně hesla!) jsou uloženy jako prostý text v datasets.xml . Nenašli jsme způsob, jak nechat správce zadat heslo k databázi během ERDDAP 's startup in Tomcat (který nastane bez vstupu uživatele) , takže heslo musí být přístupné v souboru. Aby to bylo bezpečnější:
  • Ty. (vá ERDDAP™ Správce) měl by být vlastníkem datasets.xml a mají READ a WRITE přístup.
  • Vytvořte skupinu, která zahrnuje pouze uživatelskou=tomcat. Použijte chgrp, aby se skupina pro datasets.xml , jen s oprávněním číst.
  • Použít chmod pro přiřazení práv O-rwx (žádný přístup READ nebo WRITE pro "jiné" uživatele) místo datasets.xml .
  • Až dovnitř ERDDAP™ , heslo a další vlastnosti připojení jsou uloženy v "soukromém" Java proměnné.
  • Žádosti klientů jsou rozebrány a zkontrolovány platnost před vytvořením SQL žádosti o databázi.
  • Žádosti do databáze jsou podány s SQL ReadyStatements, aby se zabránilo SQL injekce .
  • Žádosti do databáze se podávají s provedením Dotaz (neprovede seStation) omezit žádosti pouze o čtení (takže pokus o SQL injekci změnit databázi selže také z tohoto důvodu,) .  

SQL

• Protože OPeNDAP 's tabulkovými požadavky na data byly navrženy pro napodobení SQL tabulkových požadavků na data, je to snadné pro ERDDAP™ převést tabulkové žádosti o data na jednoduché SQL PřipravenéStatements. Například: ERDDAP™ žádost

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

bude převeden na SQL připravený stav

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

ERDDAP™ požadavky s & distinct () a/nebo & orderBy ( proměnné ) přidá DISTINCT a/nebo ORDER BY proměnné SQL připravené prohlášení. Obecně platí, že to výrazně zpomalí odpověď z databáze. ERDDAP™ přihlásí připravený stav do log.txt jako

    statement=*thePreparedStatement*  

Toto bude textová reprezentace PřipravenéhoStatementu, která se může mírně lišit od skutečného PřipravenéhoStatementu. Například v PřipravenémStatementu jsou časy zakódovány zvláštním způsobem. Ale v textové reprezentaci se zobrazují jako data ISO 8601.  

Rychlost databáze

• Databáze mohou být pomalé. Jsou věci, které můžete udělat:
  • Obecně - Povaha SQL je, že dotazy jsou deklarativní . Jen určují, co uživatel chce. Neobsahují specifikace nebo tipy, jak má být dotaz řešen nebo optimalizován. Takže neexistuje žádná možnost pro ERDDAP™ generovat dotaz takovým způsobem, že pomáhá databázi optimalizovat dotaz (nebo jakýmkoli způsobem určuje, jak má být dotaz řešen) . Obecně je na správci databáze, aby věci nastavil. (například indexy) optimalizovat pro určité typy dotazů.

Nastavit velikost souboru

Databáze vrací data do ERDDAP™ v kouscích. Ve výchozím nastavení vrací různé databáze jiný počet řádků. Často je toto číslo velmi malé a velmi neefektivní. Například výchozí pro Oracle 10! Přečti si dokumentaci JDBC pro ovladač databáze JDBC pro nalezení vlastnosti připojení, která má být nastavena, a přidej ji k popisu datového souboru datasets.xml . Například, Pro MySQL a Amazon RDS použijte

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

Pro MariaDB není v současné době možné změnit velikost aportu. Ale je to požadovaná funkce, takže hledat na webu zjistit, zda to bylo provedeno. Pro Oracle , použití

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

Pro PostgreSQL použijte

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

Ale klidně to číslo změňte. Nastavení čísla příliš velké způsobí ERDDAP™ používat spoustu paměti a být více pravděpodobné, že dojde paměti.

Vlastnosti připojení

Každá databáze má jiné vlastnosti připojení, které mohou být uvedeny v datasets.xml . Mnoho z nich bude mít vliv na výkon databáze ERDDAP™ spojení. Pro zobrazení možností si přečtěte dokumentaci pro ovladač JDBC databáze. Pokud zjistíte vlastnosti připojení, které jsou užitečné, prosím, pošlete e-mail s údaji na erd dot data at noaa dot gov .

• Udělej stůl... Pravděpodobně dostanete rychlejší odpovědi, pokud budete pravidelně (Každý den? Kdykoliv jsou nová data?) generovat skutečnou tabulku (Podobně jako jste vytvořili názor) a říct ERDDAP™ získat data z tabulky místo VIEW. Vzhledem k tomu, že každý požadavek na stůl pak může být splněn bez připojení k jinému stolu, odpověď bude mnohem rychlejší.
• Vysavač stolu - MySQL a Amazon RDS budou reagovat mnohem rychleji, pokud používáte OPTIMILNÍ TABULKA . Maria DB bude reagovat mnohem rychleji, pokud používáte OPTIMILNÍ TABULKA . PostgreSQL bude reagovat mnohem rychleji, pokud VACUUM Stůl. Oracle nemá ani nepotřebuje analogický příkaz.
• Značka Indexy pro běžné proměnné -- Můžete urychlit mnoho / většina dotazů vytvořením indexů v databázi pro proměnné (které databáze nazývají "sloupce") které jsou často omezeny v dotazu uživatele. Obecně platí, že tyto proměnné jsou stejné jako [< subsetVariables >] (#subsetvariables) a/nebo zeměpisné šířky, délky a časových proměnných.

Použít spojení

Normálně, ERDDAP™ provede samostatné připojení k databázi pro každou žádost. To je nejspolehlivější přístup. Rychlejší alternativou je použití datového zdroje, který podporuje sdílení připojení. Pro nastavení, upřesněte (například)

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

přímo vedle< sourceUrl >,<název řidiče > a<spojení Property>. A v tomcat /conf/context.xml, definovat zdroj se stejnou informací, například,

        <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"/>  

Obecné informace o použití datového zdroje jsou na https://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html . Viz Informace o datovém zdroji Tomcat a Příklady datového zdroje Tomcat nebo hledat na webu příklady použití DataSources s jinými servery aplikace.

• Pokud všechno ostatní selže, zvážit uložení údajů ve shromažďování NetCDF v3 .nc soubory (zvláště .nc Soubory, které používají CF Geometrie diskrétního odběru vzorků (DSG) Kontiguous Ragged Array datové struktury a tak lze zacházet s ERDDAP 's EDDTableFromNcCFFiles ) . Pokud jsou logicky organizovaní (každý s údaji pro kus prostoru a času) , ERDDAP™ může z nich velmi rychle extrahovat data.  

EDDTableFromDatabase kostra XML

  <dataset type="EDDTableFromDatabase" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
        <!-- The format varies for each type of database, but will be
          something like:
          For MariaDB: jdbc:mariadb://xxx.xxx.xxx.xxx:3306/databaseName
          For MySql jdbc:mysql://xxx.xxx.xxx.xxx:3306/databaseName
          For Amazon RDS: jdbc:mysql://xxx.xxx.xxx.xxx:3306/databaseName
          For Oracle: jdbc:oracle:thin:@xxx.xxx.xxx.xxx:1521:databaseName
          For Postgresql: jdbc:postgresql://xxx.xxx.xxx.xxx:5432/databaseName
          where xxx.xxx.xxx.xxx is the host computer's numeric IP address
          followed by :PortNumber (4 digits), which may be different for your
          database. REQUIRED. -->
      <driverName\>...</driverName>
        <!-- The high-level name of the database driver, for example,
          "org.postgresql.Driver". You need to put the actual database
          driver .jar file (for example, postgresql.jdbc.jar) in
          tomcat/webapps/erddap/WEB-INF/lib. REQUIRED. -->
      <connectionProperty name="name">value</connectionProperty>
        <!-- The names (for example, "user", "password", and "ssl")
          and values of the properties needed for ERDDAP™ to establish
          the connection to the database. 0 or more. -->
      <dataSourceName>...</dataSourceName> <!-- 0 or 1 -->
      <catalogName>...</catalogName>
        <!-- The name of the catalog which has the schema which has the
          table, default = "". OPTIONAL. Some databases don't use
          this. -->
      <schemaName>...</schemaName> <!-- The name of the
        schema which has the table, default = "". OPTIONAL. -->
      <tableName>...</tableName> <!-- The name of the
        table, default = "". REQUIRED. -->
      <columnNameQuotes><columnNameQuotes> <!-- OPTIONAL. Options:
        " (the default), ', \[nothing\]. -->
      <orderBy>...</orderBy> <!-- A comma-separated list of
        sourceNames to be used in an ORDER BY clause at the end of the
        every query sent to the database (unless the user's request
        includes an &orderBy() filter, in which case the user's
        orderBy is used). The order of the sourceNames is important.
        The leftmost (first) sourceName is most important; subsequent
        sourceNames are only used to break ties. Only relevant
        sourceNames are included in the ORDER BY clause for a given user
        request. If this is not specified, the order of the returned
        values is not specified. Default = "". OPTIONAL. -->
      <sourceCanOrderBy>no(default)|partial|yes</sourceCanOrderBy>
        <!-- 0 or 1 -->
      <sourceCanDoDistinct>no(default)|partial|yes</sourceCanDoDistinct>
        <!-- 0 or 1 -->
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <dataVariable>...</dataVariable> <!-- 1 or more.
        Each dataVariable MUST include a <dataType> tag.
        See Database DataTypes.
        For database date and timestamp columns, set dataType=double and
        units=seconds since 1970-01-01T00:00:00Z -->
  </dataset>

EDDTableFrom EDDGrid

**EDDTableFrom EDDGrid ** umožňuje vytvořit soubor EDDTable z libovolného EDDGrid Soubor dat.

• Některé společné důvody k tomu jsou:
  • To umožňuje, aby soubor údajů byl dotazován s OPeNDAP omezení výběru, což je typ "požadavky podle hodnoty" (který mohl uživatel požádat) .
  • Soubor údajů je ze své podstaty souborem tabulek.
• Hodnota globálního atributu "maxAxis0" (obvykle type="int") , (výchozí hodnota je 10) budou použity k omezení počtu os \[ 0 \] (obvykle "time" osa) hodnoty uzavřeného EDDGrid data, ke kterým lze přistupovat na žádost o údaje. Pokud nechcete mít žádný limit, zadejte hodnotu 0. Toto nastavení je důležité, protože jinak by pro uživatele bylo příliš snadné požádat EDDTableFrom EDDGrid prohledat všechna data datového souboru. To by trvalo dlouho a téměř jistě by selhalo s timeout chybou. Toto je nastavení, díky kterému je bezpečné mít EDDTableFrom EDDGrid Soubory dat ve Vašem ERDDAP bez obav, že povedou k nepřiměřenému využívání výpočetních zdrojů.
• Pokud je uzavřen EDDGrid vá EDDGrid FromErddap a ERDDAP™ je stejné ERDDAP , pak EDDTableFrom EDDGrid bude vždy používat aktuálně dostupná verze referenčního datového souboru přímo. To je velmi efektivní způsob pro EDDTableFrom EDDGrid přístup k datům v síti.
• Tato třída je [<reload EveryNMinutes >] (# reload everynminutes) Záleží na tom. Přiložené EDDGrid 's<reloadEveryNMinutes> se ignoruje.
• Pokud hodnota pro [<updateEveryNMillis>] (#update everynmillis) je dodáván pro tento datový soubor, je ignorován. Přiložené EDDGrid 's<updateEveryNMillis> je to, na čem záleží.
• GenerovatDatasetsXml má možnost pro datový typ=EDDTableFrom EDDGrid který žádá o URL ERDDAP (obvykle stejné ERDDAP ) (končí v "/erddap/") a pravidelný výraz. Generovat soubory dat Xml pak vytvoří XML pro EDDTableFrom EDDGrid Databáze pro každý datový soubor v síti ERDDAP™ který má datasetID který odpovídá regulárnímu výrazu (použijte .\* k porovnání všech datasetID s pro mřížkované soubory dat) .

Část XML, která je generována pomocí GenerateDatasetsXml pro každý soubor dat, zahrnuje:

• A datasetID což je EDDGrid 's datasetID plus "\_AsATable."
• Nový souhrnný globální atribut, který je EDDGrid 's shrnutím plus nový první odstavec popisující, co je tento datový soubor.
• Nový titul globální atribut, který je EDDGrid 's názvem plus', (Jako tabulka) ".
• Nový globální atribut maxAxis0 s hodnotou 10.

EDDTableFrom EDDGrid kostra XML

  <dataset type="EDDTableFromEDDGrid" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1.
        For EDDTableFromEDDGrid, this calls lowUpdate() of the underlying
        EDDGrid. -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <dataset>...</dataset> <!-- 1
         Any type of EDDGrid dataset. You can even use an
         EDDGridFromERDDAP™ to access an independent EDDGrid dataset on
         this server. -->
    </dataset>

EDDTableFromFileNames

EDDTableFromFileNames vytvoří soubor dat z informací o skupině souborů v systému serveru, včetně URL pro každý soubor, aby uživatelé mohli soubory stáhnout prostřednictvím ERDDAP 's "files" systém . Na rozdíl od všech EDDTableFromFoles podtřídy, tento typ datového souboru neslouží datům zevnitř souborů.

• EDDTableFromFileNames je užitečné, když:
  • Máte skupinu souborů, které chcete distribuovat jako celé soubory, protože neobsahují "data" stejným způsobem, jako mají pravidelné datové soubory data. Například obrazové soubory, video soubory, Word dokumenty, Excel tabulkové soubory, PowerPoint prezentační soubory, nebo textové soubory s nestrukturovaným textem.
  • Máte skupinu souborů, které mají data ve formátu, který ERDDAP™ Ještě neumím číst. Například projektově specifický, vlastní, binární formát.  

EDDTableFromFileNames Data

• Údaje v souboru EDDTableFromFileNames je stůl, který ERDDAP™ vytváří on-the-fly s informacemi o skupině místních souborů. V tabulce je řádek pro každý soubor. Čtyři zvláštní atributy v datasets.xml pro tento soubor údajů určit, které soubory budou zahrnuty do tohoto souboru údajů:

soubor Dir

• <fileDir> -- To určuje zdrojový adresář v souborovém systému serveru soubory pro tento soubor. Soubory, které jsou skutečně umístěny v systému serveru v<fileDir> se objeví ve sloupci URL tohoto datového souboru ve virtuálním adresáři s názvemhttps://serverUrl/erddap/files/datasetID/. Například, pokud datasetID n jplMU RSS T, a<fileDir> is /home/data/mur/ , a že adresář má soubor jplMU RSS T20150103000000.png, pak URL, která bude zobrazena uživatelům pro tento soubor bude https://serverUrl/erddap/jplMURSST/jplMURSST20150103000000.png.

Kromě použití místního adresáře pro<fileDir> můžete také zadat URL vzdálené webové stránky podobné adresáři. To funguje s:

• Neagregovaná data v THREDDS, např. https://data.nodc.noaa.gov/thredds/catalog/aquarius/nodc\\_binned\\_V3.0/monthly/ \[ 2020-10-21 Tento server již není spolehlivě dostupný. \]
• Neagregované datové soubory v Hyrax např. https://podaac-opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/
• Většina adresářů podobných Apači, např. https://www1.ncdc.noaa.gov/pub/data/cmb/ersst/v5/netcdf/

zOnTheFly

\\\*fromOnTheFly -- Pro nějaké velké S3 vědro (jako noaa-goes17, který má 26 milionů souborů) , může trvat ERDDAP™ do 12 hodin ke stažení veškeré informace o obsahu kbelíku (a pak jsou tu další problémy.) . Abych se přes to dostal, existuje zvláštní způsob, jak použít<fileDir> v EDDTableFromFileNames vytvořit soubor s adresářem a názvy souborů z kbelíku AWS S3. Databáze nebude mít seznam všech adresářů kbelíku S3 a názvů souborů, které uživatel může vyhledávat prostřednictvím žádostí do datového souboru. Ale soubor dostane jména adresářů a souborů on-the-fly, pokud uživatel přejde hierarchii adresáře s datovým souborem "files" Možnost. To umožňuje uživatelům prohlížet hierarchii souborů a souborů v kbelíku S3 prostřednictvím datového souboru "files" systém. K tomu místo určení URL pro kbelík S3 jako "Starting adresář" (ve generováníDatasets Xml) nebo<souborDir> (v datasets.xml ) , použití:

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

například:

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

Viz dokument práce s S3 Kyblíky v ERDDAP™ , zejména popis konkrétního formátu, který musí být použit pro S3 kbelík URL. A vidíš tyto podrobnosti a příklad používání\*\*Z OnThe Fly.

rekurzivní

• <rekurzivní > -- Soubory v podadresáři<fileDir> s názvy, které odpovídají<souborRegex> se objeví ve stejných podadresách "files" URL pokud<rekursive> je nastaven na true. Výchozí hodnota je nepravdivá.
• [<pathRegex>] (#pathragex) -- Pokud rekursive=true, Pouze názvy adresářů, které odpovídají cestěRegex (default=".\*") budou přijaty. Pokud se rekursive=false, to je ignorováno. To se zřídka používá, ale může být velmi užitečné za neobvyklých okolností. (Vidíš tohle? dokumentace regexu a reflexní tutoriál .)

souborRegex

• <souborRegex> -- Pouze názvy souborů, kde celý název souboru (bez názvu adresáře) odpovídá<souborRegex> bude zařazen do tohoto souboru. Například jplMU RSS T.{14}\.png . (Vidíš tohle? dokumentace regexu a reflexní tutoriál .)
   

Z názvů souborů Obsah tabulky dat

V tabulce budou sloupce s:

• URL... URL, které mohou uživatelé použít ke stažení souboru přes ERDDAP 's "files" systém .

• jméno -- Jméno souboru (bez názvu adresáře) .

• Poslední věc... Doba, kdy byl soubor naposledy upraven (uloženy jako dvojníky s "seconds since 1970-01-01T00:00:00Z" ) . Tato proměnná je užitečná, protože uživatelé mohou vidět, zda obsah daného souboru naposledy změnil. Tato proměnná je a čas Proměnná známka , takže údaje se mohou objevit jako číselné hodnoty (sekundy od 1970-01-01T00:00:00Z) nebo hodnota řetězce (ISO 8601:2004 (E) formát) V závislosti na situaci.

• velikost -- Velikost souboru v bajtech, uloženo jako dvojnásob. Jsou uloženy jako dvojité soubory, protože některé soubory mohou být větší, než umožňují ints a dlouhé nejsou podporovány v některých typech souborů odezvy. Dvojité dá přesnou velikost, dokonce i pro velké soubory.

• sloupce pro přidávání definované ERDDAP™ správce s informacemi extrahovanými z názvu souboru (například čas spojený s údaji v souboru) na základě dvou atributů, které zadáte v metadatech pro každý další sloupec/ dataVariable :

  • ExtractRegex -- Tohle je regulární výraz ( tutoriál ) . Celý regex musí odpovídat celému názvu souboru (bez názvu adresáře) . Regex musí zahrnovat alespoň jednu zachycovací skupinu. (část regulárního výrazu, která je přiložena závorkami) která ERDDAP™ používá k určení, který oddíl názvu souboru pro získání dat.
  • výtažek Skupina... Tohle je číslo zachycené skupiny. (#1 je první skupina zachycení) v pravidelném vyjádření. Výchozí hodnota je 1. Zachycovací skupina je část regulárního výrazu, který je uzavřen závorkami.

Zde jsou dva příklady:

            <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> 

V případě časové proměnné, pokud má soubor název jplMU RSS T20150103000000.png, extraktRegex bude odpovídat názvu souboru, extrahovat znaky, které odpovídají první skupina zachycení ("20150103000000") jako dataType=String, pak použijte jednotky vhodné pro časy strun k analýze řetězců do hodnot časových dat (2015-01-03T00:00:00Z) .

V případě denní proměnné, pokud má soubor název jplMU RSS T20150103000000.png, extraktRegex bude odpovídat názvu souboru, extrahovat znaky, které odpovídají první skupina zachycení ("03") jako [<dataType>] (#datatyp) \=int, získávání datové hodnoty 3.

Další informace

• Ne [<updateEveryNMillis>] (#update everynmillis) -- Tento typ datového souboru nepotřebuje a nemůže použít<updateEveryNMillis> tag, protože informace, které EDDTableFromFileJména jsou vždy dokonale aktuální, protože ERDDAP™ dotazuje souborový systém, aby reagoval na každou žádost o údaje. I když existuje obrovské množství souborů, tento přístup by měl fungovat přiměřeně dobře. Odpověď může být pomalá, pokud existuje obrovský počet souborů a databáz nebyl dotazován na chvíli. Ale několik minut poté, operační systém uchovává informace v cache, takže odpovědi by měly být velmi rychlé.  
• Můžete použít Generovat soubory dat Xml program k vytvoření datasets.xml kus pro tento typ datového souboru. Můžete přidat/definovat další sloupce s informacemi extrahovanými z názvu souboru, jak je uvedeno výše.  

EDDTableFromFileNázev kostry XML

  <dataset type="EDDTableFromFileNames" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <fileDir>...</fileDir>
      <recursive>...</recursive> <!-- true or false (the default) -->
      <pathRegex>...</pathRegex> <!-- 0 or 1. Only directory names which
        match the pathRegex (default=".\*") will be accepted. -->
      <fileNameRegex>...</fileNameRegex>
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <dataVariable>...</dataVariable> <!-- 1 or more.
         Each dataVariable MUST include <dataType> tag. -->
  </dataset>

EDDTableFromFoles

EDDTableFromFoles je supertřída všech EDDTableFrom...Files třídy. Nemůžete použít EDDTableFromFoFoles přímo. Místo toho použijte podtřída EDDTableFromFromFoles pro zpracování konkrétního typu souboru:

• EDDTableFromAsciiFiles agreguje data z čárkových, tabulkových, středníkových nebo mezerně oddělených datových souborů ASCII.
• EDDTableFromAudioFiles shromažďuje data ze skupiny místních audio souborů.
• EDDTableFrom AwsXmlFiles agreguje data ze sady automatických počasí (AWS) XML soubory.
• EDDTableFromColumnarAsciiFiles shromažďuje data z tabulkových datových souborů ASCII s datovými sloupy s pevnou šířkou.
• EDDTableFrom Hyrax Soubory (ODCHYLKY) souhrnné údaje o několika proměnných, každá se sdílenými rozměry (například čas, výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) , a sloužil Hyrax OPeNDAP server .
• EDDTableFromNeplatnéCRAFile Údaje z agregátů NetCDF (V3 nebo v4) .nc soubory, které používají specifický, neplatný, varianta CF DSG Contiguous Ragged Array (CRA) Složky. I když ERDDAP™ podporuje tento typ souboru, je to neplatný typ souboru, který by nikdo neměl používat. Skupiny, které v současné době používají tento typ souboru, jsou důrazně vybízeny k používání ERDDAP™ generovat platné soubory CF DSG CRA a přestat používat tyto soubory.
• EDDTableFromJsoniCSVFiles Údaje z agregátů JSON Řádky CSV souborů .
• EDDTablefromMultidimNcFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc (nebo .nc ml ) soubory s několika proměnnými, každá se sdílenými rozměry (například čas, výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) .
• EDDTableFromNcFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc (nebo .nc ml ) soubory s několika proměnnými, každá se sdílenými rozměry (například čas, výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) . Je v pořádku pokračovat v používání tohoto datového souboru pro stávající datové soubory, ale pro nové datové soubory doporučujeme použít místo toho EDDTableFromMultidimNcFiles.
• EDDTableFromNcCFFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc (nebo .nc ml ) soubory, které používají jeden ze formátů souborů uvedených v CF Geometrie diskrétního odběru vzorků (DSG) Konvence. Ale pro soubory používající jednu z multidimenzionálních CF DSG variant, použijte EDDTablefromMultidimNcFiles Místo toho.
• EDDTableFromNccsvFiles Údaje z agregátů NCCSV ASCII .csv soubory.
• EDDTableFromParquetFiles zpracovává údaje od Parket .
• EDDTableFromThreddsFiles (ODCHYLKY) kumuluje data ze souborů s několika proměnnými se sdílenými rozměry poskytovanými THREDDS OPeNDAP server .
• EDDTableFrom WFS Soubory (ODCHYLKY) vytvoří místní kopii všech údajů z ArcGIS MapServer WFS server, takže data pak mohou být rychle re-served ERDDAP™ uživatelé.

V současné době nejsou podporovány žádné jiné typy souborů. Obvykle je však poměrně snadné přidat podporu pro jiné typy souborů. Kontaktujte nás, pokud máte požadavek. Nebo, pokud jsou vaše data ve starém formátu, ze kterého byste se chtěli odstěhovat, doporučujeme převést soubory, které mají být NetCDF v3 .nc soubory (a zejména .nc Soubory s CF Geometrie diskrétního odběru vzorků (DSG) Kontiguous Ragged Array data struktura -- ERDDAP™ může z nich velmi rychle extrahovat data) . NetCDF je široce podporovaný binární formát, umožňuje rychlý náhodný přístup k datům a je již podporován ERDDAP .

Podrobnosti z souborů

Následující informace platí pro všechny podtřídy EDDTableFromFoles.

Agregace

Tato třída shromažďuje data z místních souborů. Každý soubor má (relativně) malá tabulka dat.

• Výsledný datový soubor se jeví jako by všechny tabulky souboru byly kombinovány (všechny řádky dat ze souboru #1, plus všechny řádky ze souboru #2, ...) .
• Soubory nemusí mít všechny zadané proměnné. Pokud daný soubor nemá zadanou proměnnou, ERDDAP™ přidá chybějící hodnoty podle potřeby.
• Proměnné ve všech souborech MUSÍ mít stejné hodnoty pro add\_offset , missing\_value , \_Fill Hodnota , scale\_factor a jednotky atributy (pokud existuje) . ERDDAP™ kontroly, ale je to nedokonalý test -- pokud existují různé hodnoty, ERDDAP neví, co je správné, a proto, které soubory jsou neplatné. Pokud je problém, můžete být schopni použít NcML nebo NCO Napravit problém.  

Stlačené soubory

Soubory zdrojových dat pro všechny podtřídy EDDTableFromFromFoles lze externě komprimovat (např. .tgz , .tar .gz , .tar .gzip , .gz , .gzip , .zip , .bz2 nebo .Z) . Viz Vnější dokumentace komprimovaných souborů .  

Informace o souboru

• Při prvním načtení databázového souboru EDDTableFromFoles čte informace ze všech příslušných souborů a vytváří tabulky (jeden řádek pro každý soubor) s informacemi o každém platném souboru a každém "špatném" (jiný nebo neplatný) Složka.
  • Tabulky jsou také uloženy na disku, jako NetCDF v3 .nc soubory v velkýRodič rodičů /dataset/ last2CharsOfDatasetID / * datasetID * / v souborech pojmenovaných: dirTable .nc (který obsahuje seznam jedinečných názvů adresářů) , soubor Tabulka .nc (která obsahuje tabulku s údaji každého platného souboru) , badFiles .nc (který drží tabulku s informacemi každého špatného souboru) .
  • Pro urychlení přístupu k datovému souboru EDDTableFromFoles (ale na úkor využití více paměti) , můžete použít [<souborTableInMemory> true</fileTableInMemory>] (# filetableinmemory)
    říct ERDDAP™ uchovávat kopii tabulek informací o souboru v paměti.
  • Kopie tabulek informací o souboru na disku je také užitečná, když ERDDAP™ je vypnuto a restartováno: ukládá EDDTable OdFiles z nutnosti znovu přečíst všechny datové soubory.
  • Když je soubor dat znovu načten, ERDDAP™ stačí přečíst data v nových souborech a souborech, které se změnily.
  • Pokud má soubor jinou strukturu než ostatní soubory (například jiný datový typ pro jednu z proměnných nebo jinou hodnotu pro " jednotky " atribut) , ERDDAP přidá soubor do seznamu "špatných" souborů. Informace o problému se souborem budou zapsány do velkýRodič rodičů /logs/log.txt soubor.
  • Nikdy byste neměli muset smazat nebo pracovat s těmito soubory. Jednou výjimkou je: pokud stále provádíte změny datového souboru datasets.xml nastavit, možná budete chtít odstranit tyto soubory k vynucení ERDDAP™ znovu přečíst všechny soubory, protože soubory budou číst/interpretovat jinak. Pokud budete někdy potřebovat odstranit tyto soubory, můžete to udělat, když ERDDAP™ Utíká. (Pak nastavte vlajka co nejdříve načíst soubor údajů.) Nicméně, ERDDAP™ obvykle si všimne, že datasets.xml informace neodpovídají souboru Informace o tabulce a automaticky smaže tabulky souborů.
  • Pokud chcete podpořit ERDDAP™ aktualizovat uložené informace o datovém souboru (například, pokud jste právě přidali, odstranili nebo změnili některé soubory do datového adresáře datového souboru) , použijte Systém vlajky donutit ERDDAP™ aktualizovat informace o cached souboru.  

Žádosti o zacházení

• ERDDAP™ Tabulkové žádosti o údaje mohou klást omezení na jakoukoli proměnnou.
• Při zpracování požadavku klienta na data se může EDDTableFromFoles rychle podívat do tabulky s platnou informací o souboru, aby zjistil, které soubory mohou mít příslušná data. Například pokud má každý zdrojový soubor data pro jednu bóji s pevným umístěním, může EDDTableFromFoles velmi účinně určit, které soubory mohou mít data v daném rozsahu délky a zeměpisné šířky.
• Vzhledem k tomu, že platná tabulka informací o souboru obsahuje minimální a maximální hodnotu každé proměnné pro každý platný soubor, může EDDTableFromFoles často efektivně řešit další dotazy. Například pokud některé z bójí nemají čidlo tlaku vzduchu a klient požaduje data pro AirPressure!=NaN, EdDTableFromFiles může efektivně určit, která bóje mají údaje o tlaku vzduchu.  

Aktualizace informací o souboru

Kdykoli je soubor znovu načten, jsou aktualizovány informace o cache souboru.

• Databáze se pravidelně načítá tak, jak stanoví<reloadEveryNMinutes> v informacích datového souboru v datasets.xml .
• Databáze je znovu načítána co nejdříve. ERDDAP™ zjistí, že jste přidali, odstranili, Touch'd (změnit poslední soubor Změněný čas) , nebo změnil datový soubor.
• Databáze je znovu načtena co nejdříve, pokud použijete Systém vlajky .

Když je soubor dat znovu načten, ERDDAP™ Porovnává aktuálně dostupné soubory s kašovanou informační tabulkou souboru. Nové soubory se čtou a přidávají do platné tabulky souborů. Soubory, které již neexistují, jsou staženy z platné tabulky souborů. Soubory, kde došlo ke změně časového razítka souboru, se čtou a jejich informace se aktualizují. Nové tabulky nahrazují staré tabulky v paměti a na disku.  

Špatné soubory

Tabulka špatných souborů a důvody, proč byly soubory prohlášeny za špatné (poškozený soubor, chybějící proměnné, nesprávné hodnoty osy atd.) je e-mailem na e-mail Všechno Na e-mailovou adresu (Pravděpodobně vy.) pokaždé, když je soubor dat znovu načten. Měli byste tyto soubory co nejdříve nahradit nebo opravit.  

Chybějící proměnné

Pokud některé složky nemají některé z dataVariable s definovaná v souboru údajů datasets.xml To je v pořádku. Když EDDTableFromFoles čte jeden z těchto souborů, bude to působit, jako by soubor měl proměnnou, ale se všemi chybějícími hodnotami.  

Údaje v blízkém reálném čase

• EDDTableFromFoles považuje žádosti o nejnovější data za zvláštní případ. Problém: Pokud jsou soubory tvořící soubor často aktualizovány, je pravděpodobné, že data nebudou aktualizována pokaždé, když se soubor změní. Takže EDDTableFromFoles nebude vědět o změně souborů. (Můžeš použít Systém vlajky , ale to může vést k ERDDAP™ načítání dat téměř neustále. Ve většině případů to nedoporučujeme.) EDDTableFromFoles se tímto zabývá následujícím systémem: Kdy? ERDDAP™ obdrží žádost o údaje během posledních 20 hodin (například před 8 hodinami až do teď) , ERDDAP™ bude vyhledávat všechny soubory, které mají všechna data za posledních 20 hodin. Takže, ERDDAP™ nemusí mít dokonale aktuální data pro všechny soubory, aby našel nejnovější data. Měli byste se ještě nastavit [<reload EveryNMinutes >] (# reload everynminutes) na přiměřeně malou hodnotu (například 60) , Ale nemusí to být malé (například 3) .  

  • Nedoporučuje se organizace téměř reálných dat v souborech: Pokud například máte datový soubor, který ukládá data pro mnoho stanic (nebo bóje, nebo trajektorie, ...) po mnoho let, můžete zařídit soubory tak, aby například, tam je jeden soubor na stanici. Ale pokaždé, když dorazí nová data pro stanici, musíte si přečíst velký starý soubor a napsat velký nový soubor. A kdy ERDDAP™ znovu načte soubor, všimne si, že některé soubory byly upraveny, takže tyto soubory čte úplně. To je neefektivní.  

  • Doporučené organizace téměř reálných dat v souborech: Uložit data například do bloků, všechna data za jednu stanici/buoy/trajektorii za jeden rok (nebo jeden měsíc) . Pak, když přijde nový datum, jen soubor s letošní (nebo měsíc) jsou ovlivněny údaje.

  • Nejlepší: Použití NetCDF v3 .nc soubory s neomezeným rozměrem (čas) . Pak, pro přidání nových dat, stačí přidat nová data, aniž byste museli číst a přepisovat celý soubor. Změna se provádí velmi efektivně a v podstatě atomově, takže soubor není nikdy v rozporu.

  • Jinak: .nc soubory s neomezeným rozměrem (čas) , pak, když potřebujete přidat nová data, musíte přečíst a přepsat celý dotčený soubor (Doufejme, že malé, protože to má jen rok (nebo měsíc) hodnota údajů) . Naštěstí všechny soubory za předchozí roky (nebo měsíce) pro tuto stanici zůstat beze změny.

V obou případech, kdy ERDDAP™ reloads soubor, většina souborů se nemění; jen několik, malé soubory se změnily a je třeba číst.  

Adresáře

Soubory mohou být v jednom adresáři nebo v adresáři a jeho podadresáři (rekurzivně) . Pokud existuje velký počet souborů (např. > 1 000) , operační systém (a tedy EDDTableFromFoles) bude fungovat mnohem efektivněji, pokud uložíte soubory do řady podadresářů (jeden za rok nebo jeden za měsíc pro soubory údajů s velmi častými soubory) , tak, že nikdy neexistuje obrovské množství souborů v daném adresáři.  

Vzdálené adresáře a HTTP požadavky na rozsah

• Vzdálené adresáře a HTTP požadavky na rozsah (AKA Byte Servis, Byte Range žádosti) -- EDDGrid EDDTableFromMultidimNcFiles, EDDTableFromNcFiles a EDDTableFromNcCFFiles mohou někdy sloužit data z .nc soubory na vzdálených serverech a přístupné přes HTTP, pokud server podporuje Byte Slouží přes HTTP požadavky na rozsah (HTTP mechanismus pro bajtové podávání) . To je možné, protože netcdf-java (která ERDDAP™ použití ke čtení .nc soubory) podporuje čtení dat ze vzdáleného .nc soubory přes HTTP požadavky na rozsah.

  Nedělej to!
  Místo toho použijte [<cacheFromUrl> system] (#Cachefromurl) .

CacheFromUrl

• [ ** <cacheFromUrl> ** ] (#Cachefromurl) - Všechny EDDGrid FromFiles a všechny soubory EDDTableFromFoles podporují sadu tagů, které říkají ERDDAP™ stáhnout a udržovat kopii všech souborů vzdáleného datového souboru nebo cache několika souborů (stažen podle potřeby) . Tohle je neuvěřitelně užitečná vlastnost.

  • The<cacheFromUrl> tag umožňuje zadat URL se seznamem souborů vzdáleného souboru ze vzdáleného seznamu souborů.

    • Neagregovaná data v THREDDS, např. https://data.nodc.noaa.gov/thredds/catalog/aquarius/nodc\\_binned\\_V3.0/monthly/ \[ 2020-10-21 Tento server již není spolehlivě dostupný. \]
    • Neagregované datové soubory v Hyrax např. https://podaac-opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/
    • Většina adresářů podobných Apači, např. https://www.ncei.noaa.gov/data/global-precipitation-climatology-project-gpcp-daily/
    • S3 kbelíky, např. https://noaa-goes17.s3.us-east-1.amazonaws.com/
      To však může vyžadovat účet AWS a další nastavení. Viz práce s S3 Kyblíky v ERDDAP™ . Také, obvykle nemusíte používat cache FromUrl se soubory v S3 kbelíky, pokud jsou soubory ASCII soubory (např. .csv) , protože ERDDAP™ efektivně číst data z kbelíku přímo přes proud.

    ERDDAP™ bude kopírovat nebo cachovat tyto soubory v souboru<fileDir> adresář. Pokud potřebujete podporu pro jiný typ vzdáleného seznamu souborů (např. FTP) Pošlete prosím svou žádost Chrisovi. John at noaa.gov .

    • Výchozí hodnota pro<cacheFromUrl> tag je null. Pokud nespecifikujete hodnotu pro<cacheFromUrl> tag, systém kopírování/cache nebude použit pro tento datový soubor.
    • Pokud je datový soubor<souborRegex> nastavení je něco jiného než .\*, ERDDAP™ bude stahovat pouze soubory, které odpovídají souboruRegex.
    • Pokud je datový soubor<rekursive> nastavení je pravda a vzdálené soubory jsou v podadresáři, ERDDAP™ bude hledat ve vzdálených podadresářech, které odpovídají datovému souboru [<pathRegex>] (#pathragex) , vytvořit stejnou strukturu adresáře lokálně a dát místní soubory do stejných podadresářů.
    • Ve generováníDatasets Xml, pokud zadáte<cacheFromUrl> hodnota, Generovat Datové soubory Xml vytvoří místní<fileDir> adresář a kopírovat 1 vzdálený soubor do něj. Generovat soubory dat Xml pak generuje datasets.xml kus založený na souboru vzorku (specifikovat vzorek Soubor=nic) .
    • Pokud je zdroj dat vzdálený ERDDAP™ , použití EDDGrid FromErddap nebo EDDTableFromErddap místo<cacheFromUrl>. Tímto způsobem, váš místní ERDDAP™ Zdá se, že data mají, ale nebudou muset ukládat žádná z dat na místě. Jediný důvod k použití<cacheFromUrl > získat data ze vzdáleného ERDDAP™ je, když máte nějaký jiný důvod, proč chcete mít místní kopii datových souborů. V takovém případě:
      • Tento datový soubor se pokusí odeslat datový soubor na vzdáleném ERDDAP takže změny tohoto datového souboru budou nazývat vlajku tohoto souboru Url, což způsobuje, že tento místní datový soubor znovu načíst a stáhnout změněné vzdálené soubory. Místní datový soubor bude proto aktualizován velmi brzy po provedení změn vzdáleného datového souboru.
      • Měli byste e-mail správce vzdáleného ERDDAP™ požádat o datasets.xml pro vzdálený datový soubor, takže můžete vytvořit datový soubor ve svém lokálním ERDDAP™ Vypadá to jako datový soubor ve vzdáleném ERDDAP .
    • Pokud je zdroj dat vzdálený ERDDAP™ , místní datový soubor se pokusí přihlásit ke vzdálenému datovému souboru.
      • Pokud předplatné uspěje, kdykoli je vzdálené ERDDAP reloads and has new data, it will contact the flagURL for this data data, což způsobí, že bude znovu načíst a stáhnout nové a / nebo změněné datové soubory.
      • Pokud předplatné selže (z jakéhokoli důvodu) nebo pokud jednoduše chcete zajistit, aby byl místní datový soubor aktualizován, můžete nastavit vlajka pro místní datový soubor, takže bude znovu načíst, takže bude kontrolovat nové a/nebo změněné vzdálené datové soubory.
    • Pokud zdroj dat není vzdálený ERDDAP : databázový soubor zkontroluje nové a/nebo změněné vzdálené soubory pokaždé, když je znovu načte. Normálně je řízen [<reload EveryNMinutes >] (# reload everynminutes) . Ale pokud víte, kdy jsou nové vzdálené soubory, můžete nastavit vlajka pro místní datový soubor, takže bude znovu načíst a kontrolovat nové a/nebo změněné vzdálené datové soubory. Pokud k tomu dojde pravidelně v určitou denní dobu (např. v 7 ráno) , můžete udělat cron práci používat curl kontaktovat vlajku Url pro tento datový soubor, takže bude znovu načíst a kontrolovat nové a/nebo změněné vzdálené datové soubory.

  • The<cacheSizeGB> tag určuje velikost místní cache. Pravděpodobně to potřebujete použít pouze při práci s cloudovými úložnými systémy, jako je Amazon S3 což je běžně používaný skladovací systém, který je součástí Amazon Webové služby (AWS) . Výchozí hodnota je -1.

    • Pokud je hodnota<0, 0 (např. výchozí hodnota -1) , ERDDAP™ stáhne a udržuje kompletní kopie ze všech souborů vzdáleného datového souboru v datovém souboru<fileDir>.
      • Toto je nastavení, které se doporučuje kdykoli je to možné.
      • Pokaždé, když je soubor dat znovu načten, porovnává jména, velikosti a poslední kodifikované časy vzdálených souborů a místních souborů a stahuje všechny vzdálené soubory, které jsou nové nebo se změnily.
      • Pokud soubor, který byl na vzdáleném serveru zmizí, ERDDAP™ nevymaže odpovídající místní soubor (jinak, pokud je něco dočasně špatně se vzdáleným serverem, ERDDAP™ může smazat některé nebo všechny místní soubory!) .
      • S tímto nastavením, obvykle budete nastavit<updateEveryNMillis> to -1, protože datový soubor si je vědom toho, kdy kopíroval nové datové soubory.
    • Je-li hodnota >0, ERDDAP™ bude stahovat soubory ze vzdáleného souboru podle potřeby do místního cache (v souboru údajů)<fileDir>) s mezní velikostí uvedeného počtu GB.
      • Ceche musí být dostatečně velká, aby měla alespoň několik datových souborů.
      • Obecně platí, že čím větší cache, tím lepší, protože další požadovaný datový soubor bude pravděpodobnější, že již bude v cache.
      • Caching by měl být použit pouze tehdy, ERDDAP™ běží na cloud computing serveru (např. výpočetní instance AWS) a vzdálené soubory v cloudovém úložišti (např. AWS S3) .
      • Když místo na disku používané místními soubory přesahuje cache VelikostGB, ERDDAP™ bude brzy (Možná ne hned.) smazat některé z cached souborů (v současné době, na základě nejméně nedávno použité (LRU) algoritmus) dokud není místo na disku používané místními soubory<0.75\*cacheSizeGB ("cíl") . Ano, existují případy, kdy LRU provádí velmi špatně - neexistuje žádný dokonalý algoritmus.
      • ERDDAP™ se nikdy nepokusí smazat cached soubor, který ERDDAP™ začal používat během posledních 10 sekund. Jedná se o nedokonalý systém pro řešení systému cache a systém čtečky dat je pouze volně integrován. Kvůli tomuto pravidlu, ERDDAP™ nemusí být schopen odstranit dostatek souborů pro dosažení svého cíle, v tom případě to bude tisknout VAROVÁNÍ do log.txt souboru, a systém bude plýtvat hodně času se snaží prořezat cache, a je možné, že velikost souborů v cache může výrazně překročit cacheSizeGB. Pokud k tomu někdy dojde, použijte větší cacheSizeGB nastavení pro tento datový soubor.
      • V současné době, ERDDAP™ nikdy nekontrolujte, zda má vzdálený server novější verzi souboru, který je v lokální cache. Pokud potřebujete tuto funkci, prosím, e-mail Chris. John at noaa.gov .
    • Ačkoli použití stejných názvů značek může znamenat, že kopírovací systém a systém cache používají stejný základní systém, to není správné.
      • Kopírovací systém aktivně spouští úkolyThread pro stahování nových a změněných souborů pokaždé, když je soubor znovu načten. Pouze soubory, které byly skutečně zkopírovány do místního adresáře jsou k dispozici prostřednictvím ERDDAP™ Soubor dat.
      • Systém cache získá seznam vzdálených souborů pokaždé, když je soubor znovu načten a předstírá, že všechny tyto soubory jsou k dispozici prostřednictvím ERDDAP™ Soubor dat. Zajímavé je, že všechny vzdálené soubory se dokonce objeví v /souborech/ webových stránkách datového souboru a jsou k dispozici ke stažení (I když možná až po zpoždění, zatímco soubor je nejprve stažen ze vzdáleného serveru do místní cache.)
    • Datové soubory, které používají cacheSizeGB, mohou mít prospěch z použití nThreads nastavení větší než 1, protože to umožní soubor dat stáhnout více než 1 vzdálený soubor najednou.

  • The<cachePartialPathRegex> tag je zřídka používaný tag, který může určit alternativu pro soubor dat [<pathRegex>] (#pathragex) . Výchozí hodnota je nulová.

    • Použijte to pouze v případě, že kopírujete celý soubor souborů přes výchozí<cacheSizeGB> hodnota -1.<cacheSizeGB> hodnoty >1, to bude ignorováno, protože to je nesmyslné.
    • Viz [dokumentace pro<pathRegex>] (#pathragex) pro návod, jak vytvořit regex.
    • Je-li uvedeno toto, použije se vždy při opětovném načtení souboru dat, s výjimkou prvního opětovného načtení datového souboru na začátku měsíce.
    • To je užitečné, když je vzdálený soubor uložen v labyrintu podadresářů a kdy se velká většina těchto souborů, pokud vůbec, mění. (<kašel > NASA<kašel >) Můžete například zadat<cachePartialPathRegex>, který jen odpovídá aktuálnímu roku nebo aktuálnímu měsíci. Tyto regexy jsou velmi složité určit, protože všechny částečné a plné názvy cest musí odpovídat<cachePartialPathRegex> a protože<cachePartialPathRegex> musí pracovat se vzdálenými URL adresami a místními adresáři. Skutečný životní příklad je:

            <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>  

Sample URL má soubory v podadresářech podle roku (např., 2018) a den roku (např. 001, 002, ..., 365 nebo 366) . Všimněte si, že<cachePartialPathRegex> začíná na .\*, pak má konkrétní podadresář, který je společný pro vzdálené URL a lokální adresáře, např., /v4\.1/ pak má řadu vnořených skupin, kde první možnost je nic. a druhá možnost je specifická hodnota.

Výše uvedený příklad bude odpovídat adresářům pouze pro druhé 10 dnů roku 2018, např. https://data.nodc.noaa.gov/ghrsst/GDS2/L4/GLOB/JPL/MUR/v4.1/2018/010/ \[ 2020-10-21 Tento server již není spolehlivě dostupný. \]
a den 011, 012, ..., 019. (Vidíš tohle? dokumentace regexu a reflexní tutoriál .)
Pokud potřebujete pomoct vytvořit<cachePartialPathRegex>, prosím e-mailem<cacheFromUrl> to Chris. John at noaa.gov .

• Společný přístup: Pokud chcete použít<cachePartialPathRegex>, nepoužívejte jej zpočátku, protože chcete ERDDAP™ stáhnout všechny soubory zpočátku. Po ERDDAP™ stáhnul všechny soubory, přidal je do souboru datasets.xml .  

Tisíce souborů

Pokud váš soubor má mnoho tisíc souborů, ERDDAP™ může být pomalé reagovat na žádosti o údaje z tohoto datového souboru. Jsou tu dva problémy:  

1. Počet souborů v adresáři. Vnitřní, ERDDAP™ pracuje stejnou rychlostí bez ohledu na to, zda jsou n soubory v jednom adresáři nebo rozptýleny v několika adresářích.   Ale je tu problém: Čím více souborů v daném adresáři, tím pomalejší je operační systém při vrácení seznamu souborů v adresáři (na soubor) až ERDDAP . Doba odezvy může být 0. (n log n) . Je těžké říct, kolik souborů v jednom adresáři je příliš mnoho, ale 10 000 je pravděpodobně příliš mnoho. Takže pokud vaše nastavení generuje spoustu souborů, doporučení zde může být: dát soubory do logicky organizovaných podadresářů (např. stanice nebo stanice/rok) .

Další důvod k použití podadresářů: pokud uživatel chce použít ERDDAP 's "files" systém pro nalezení jména nejstaršího souboru pro stanici X, je rychlejší a efektivnější, pokud jsou soubory ve stanici / rok podadresáře, protože mnohem méně informací je třeba převést.

2. Celkový počet souborů. Pro soubor tabulkových dat, ERDDAP™ sleduje rozsah hodnot pro každou proměnnou v každém souboru. Když uživatel podá žádost, ERDDAP™ musí číst všechna data ze všech souborů, které mohou mít data odpovídající žádosti uživatele. Pokud uživatel požádá o data z omezeného času (např. jeden den nebo jeden měsíc) , pak ERDDAP™ nebude muset otevřít příliš mnoho souborů ve vašem souboru. Ale jsou extrémní případy, kdy téměř každý soubor může mít odpovídající data (např. při voděTeplota =13.2C) . Od té doby ERDDAP™ trochu času (částečně čas hledání na HDD, částečně čas na čtení hlavičky souboru) jen otevřít daný soubor (a více, pokud je mnoho souborů v adresáři) , existuje významný časový trest, pokud celkový počet souborů, které ERDDAP™ Musí se otevřít, je velmi velká. I otevření 1000 souborů vyžaduje značný čas. Takže jsou tu výhody, jak pravidelně konsolidovat denní soubory do větších částí (např. 1 stanice na 1 rok) . Chápu, že to možná nechcete dělat z různých důvodů, ale vede to k mnohem rychlejším reakcím. V extrémních případech (Například, jednám s datovým souborem GTSPP, který má ~35 milionů zdrojových souborů) , podávání dat z obrovského počtu zdrojových souborů je nepraktické, protože ERDDAP 's odpovědí na jednoduché dotazy může trvat hodiny a používat tuny paměti. Konsolidací zdrojových souborů do menšího čísla (pro GTSPP mám nyní 720, 2 měsíčně) , ERDDAP™ může reagovat rozumně rychle. Viz Miliony souborů
    

N.B. Solid State Drives jsou skvělé! Nejrychlejší, nejjednodušší, nejlevnější způsob, jak pomoci ERDDAP™ vypořádat se s obrovským počtem (malý) Soubory je použít pevný stav disk. Viz Solid State Drives jsou skvělé!
 

Miliony souborů

• Některé soubory mají miliony zdrojových souborů. ERDDAP™ Zvládne to, ale se smíšenými výsledky.

  • Pro žádosti, které zahrnují pouze proměnné uvedené v [< subsetVariables >] (#subsetvariables) , ERDDAP™ má všechny potřebné informace již extrahované z datových souborů a uložené v jednom souboru, takže může reagovat velmi, velmi rychle.
  • Pro další žádosti, ERDDAP™ může skenovat soubory dat cachované informace o souboru a zjistit, že pouze několik souborů může mít údaje, které jsou relevantní pro žádost, a tak rychle reagovat.
  • Ale na jiné požadavky (například vodaTeplota=18 stupňů\_C) kde jakýkoli soubor může mít příslušné údaje, ERDDAP™ musí otevřít velký počet souborů, aby zjistil, zda každý soubor má nějaké údaje, které jsou relevantní pro žádost. Soubory se otevírají postupně. Na jakémkoli operačním systému a jakémkoli souborovém systému (jiné než pevné pohony) Trvá to dlouho. (tak ERDDAP™ reaguje pomalu.) a opravdu spojuje souborový systém (tak ERDDAP™ reaguje pomalu na jiné požadavky) .

Naštěstí existuje řešení.

1. Nastavení datového souboru na neveřejném ERDDAP™ (Váš osobní počítač?) .
2. Vytvořit a spustit skript, který požaduje řadu .nc CF soubory, každý s velkým kusem datového souboru, obvykle časové období (například všechny údaje za daný měsíc) . Vyberte si časové období tak, aby všechny výsledné soubory byly menší než 2GB (ale doufejme, že větší než 1GB) . Pokud má datový soubor data téměř v reálném čase, spusťte skript pro regeneraci souboru za aktuální časové období (např. tento měsíc) často (každých 10 minut? každou hodinu?) . Žádosti o ERDDAP™ místo .nc CF soubory vytvořit a NetCDF v3 .nc soubor, který používá CF Geometrie diskrétního odběru vzorků (DSG) Kontiguous Ragged Array data structures).
3. Nastavit EDDTableFromNcCFFiles Soubor údajů na veřejnosti ERDDAP™ který získává data od .nc (CF) Složky. ERDDAP™ může extrahovat data z těchto souborů velmi rychle. A protože jsou teď tucty nebo stovky (místo milionů) souborů, i když ERDDAP™ musí otevřít všechny soubory, může to udělat rychle.

Ano, tento systém vyžaduje nějaký čas a úsilí, ale funguje velmi, velmi dobře. Většinu požadavků na data lze zvládnout stokrát rychleji než předtím. \[ Bob věděl, že je to možné, ale byl to Kevin O'Brien, kdo to udělal poprvé a ukázal, že to funguje dobře. Teď, Bob to používá pro soubor GTSPP, který má asi 18 milionů zdrojových souborů a který ERDDAP™ Nyní slouží přes asi 500 .nc (CF) Složky. \]

N.B. Solid State Drives jsou skvělé! Nejrychlejší, nejjednodušší, nejlevnější způsob, jak pomoci ERDDAP™ vypořádat se s obrovským počtem (malý) Soubory je použít pevný stav disk. Viz Solid State Drives jsou skvělé!
 

Obrovské soubory

• Jeden obrovský datový soubor (zejména obrovské datové soubory ASCII) Může způsobit OutOfMemoryError. Pokud je to problém, mělo by to být zřejmé, protože ERDDAP™ nebude načítat soubor údajů. Řešením, pokud je to proveditelné, je rozdělit soubor na více souborů. V ideálním případě můžete rozdělit soubor na logické kousky. Například pokud má soubor 20 měsíční hodnotu dat, rozdělí je na 20 souborů, každý z nich má 1 měsíční hodnotu dat. Ale existují výhody, i když je hlavní soubor rozdělen libovolně. Tento přístup má více výhod: a) Tím se sníží paměť potřebná pro čtení datových souborů na 1/20th, protože pouze jeden soubor se čte najednou. b) Často, ERDDAP™ může řešit požadavky mnohem rychleji, protože se musí podívat pouze do jednoho nebo několika souborů najít data pro danou žádost. c) Pokud sběr dat probíhá, pak se může stávající 20 souborů změnit, a stačí upravit jeden, malý, nový soubor pro přidání dat v hodnotě příští měsíc do souboru.  

FTP Potíže/Advice

• Pokud FTP nové datové soubory do ERDDAP™ server zatímco ERDDAP™ Utíká, je tu šance, že ERDDAP™ bude soubor údajů během procesu FTP znovu nabíjet. Stává se to častěji, než si myslíte! Pokud k tomu dojde, bude se soubor zdát platný (má platné jméno) Ale ta složka není platná. Pokud ERDDAP™ pokusí se číst data z tohoto neplatného souboru, výsledná chyba způsobí přidání souboru do tabulky neplatných souborů. To není dobré. Aby se zabránilo tomuto problému, použijte dočasné jméno souboru při FTP 'ing soubor, například ABC2005 .nc \_TEMP . Pak souborNameRegex test (viz níže) uvede, že se nejedná o relevantní soubor. Po dokončení procesu FTP přejmenujte soubor na správný název. Proces přejmenování způsobí, že soubor bude okamžitě relevantní.

Extrakty názvu souboru

\[ Tato funkce je DEPRECED. Prosím použijte \\\* fileName pseudo sourceName Místo toho. \]
EDDTableFromFoles má systém pro extrahování Stringu z každého názvu souboru a jeho použití k vytvoření pseudo datové proměnné. V současné době neexistuje systém, který by tyto Struny interpretoval jako data/časy. Existuje několik XML značek pro nastavení tohoto systému. Pokud nepotřebujete část nebo celý tento systém, prostě nespecifikujte tyto značky nebo použijte "" hodnoty.

• PreExtractRegex je regulární výraz ( tutoriál ) slouží k identifikaci textu, který má být odstraněn od začátku názvu souboru. K odstranění dojde pouze tehdy, pokud se regex shoduje. To obvykle začíná na "^," aby odpovídal začátku názvu souboru.
• místo ExtractRegex je regulární výraz používaný k identifikaci textu, který má být odstraněn z konce názvu souboru. K odstranění dojde pouze tehdy, pokud se regex shoduje. To obvykle končí "$" na konci názvu souboru.
• extraktRegex Je-li přítomen, používá se tento regulární výraz po preExtractRegex a postExtractRegex k identifikaci řetězce, který má být extrahován z názvu souboru (např. stationID ) . Pokud regex neodpovídá, použije se celý název souboru (- PreExtract a post Výtažek) . Použijte ".\*" k porovnání celého názvu souboru, který je ponechán po preExtractRegex a postExtractRegex.
• sloupec NázevForExtract je zdrojový název datového sloupce pro extrahované řetězce. A dataVariable s tímhle. sourceName musí být v dataVariable Seznam (s jakýmkoli datovým typem, ale obvykle String) .

Například pokud má datový soubor soubory se jmény jako XYZAble .nc , XYZBaker .nc , XYZCharlie .nc , ... a chcete vytvořit novou proměnnou ( stationID ) při čtení každého souboru, který bude mít hodnoty stanice ID (Able, Baker, Charlie, ...) extrahované z názvů souborů, můžete použít tyto značky:

• <PreExtractRegex>^XYZ</preExtractRegex > Počáteční ^ je regulární výraz zvláštní znak, který nutí ERDDAP™ hledat XYZ na začátku názvu souboru. To způsobuje, že XYZ, pokud je nalezen na začátku názvu souboru, bude odstraněn (například název souboru XYZAble .nc se stane Able .nc ) .
• <PostExtractRegex>\ .nc $</postExtractRegex> $ na konci je pravidelný výraz zvláštní znak, který nutí ERDDAP™ Hledat .nc na konci názvu souboru. Od . je regulární výraz zvláštní znak (který odpovídá jakékoli postavě) , je kódován jako \. Tady. (protože 2E je hexadecimální číslo znaku po dobu) . To způsobuje .nc , najdete-li na konci názvu souboru, který má být odstraněn (například částečný název souboru Able .nc se stane Able) .
• <extraktRegex>.\</extrahRegex> .\ regulární výraz odpovídá všem zbývajícím znakům (například částečný název souboru Able se stává výpisem pro první soubor) .
• <sloupecNázevForExtract> stationID </SloupceNázevForExtract> To říká ERDDAP™ vytvořit nový zdrojový sloupec nazvaný stationID při čtení každého souboru. Každý řádek dat pro daný soubor bude mít text extrahovaný z názvu souboru (například: Able) jako hodnota v stationID sloupek.

Ve většině případů existuje mnoho hodnot pro tyto extrahovací značky, které budou mít stejné výsledky - regulární výrazy jsou velmi flexibilní. Ale v několika případech existuje jen jeden způsob, jak získat požadované výsledky.  

Pseudo sourceName án

Každá proměnná v každém datovém souboru v ERDDAP™ má [< sourceName >] (#zdrojové jméno) který určuje název zdroje proměnné. EDDTableFromFoles podporuje několik pseudo sourceName s, které extrahují hodnotu z jiného místa (např. název souboru nebo hodnota globálního atributu) a podporovat tuto hodnotu jako sloupec konstantních hodnot pro tento kus dat (Například tabulka údajů tohoto souboru) . Pro tyto proměnné musíte zadat datový typ proměnné přes [<dataType>] (#datatyp) Tagu. Pokud jsou extrahované informace řetězec dateTime, zadejte formát řetězce dateTime v atribut jednotek . Jméno sourceName možnosti jsou:  

globální: sourceName án

Příznak globálních metadat v každém zdrojovém datovém souboru může být podporován jako sloupec dat. Pokud proměnná je< sourceName > má formát

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

pak když ERDDAP™ čte data ze souboru, ERDDAP™ bude hledat globální atribut tohoto jména (např. PI) a vytvořit sloupec naplněný hodnotou atributu. To je užitečné, pokud atribut má různé hodnoty v různých zdrojových souborech, protože jinak by uživatelé viděli pouze jednu z těchto hodnot pro celý soubor dat. Například,

        <sourceName>global:PI</sourceName>

Když propagujete atribut jako data, ERDDAP™ odstraní odpovídající atribut. To je vhodné, protože hodnota je pravděpodobně odlišná v každém souboru; vzhledem k tomu, že v souhrnném souboru údajů ERDDAP™ bude mít jen jednu hodnotu. Pokud chcete, můžete přidat novou hodnotu pro atribut pro celý soubor dat přidáním<att name=" atribut Název "> nový Hodnota </att > na globální soubor dat [< addAttributes >] (#addattributy) . Pro globální atributy, které ERDDAP™ vyžaduje například instituci, musíte přidat novou hodnotu atributu.  

proměnná: sourceName án

Příznak metadat proměnné v každém souboru může být podporován jako sloupec dat. Pokud proměnná je< sourceName \> má formát

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

pak když ERDDAP™ čte data ze souboru, ERDDAP™ bude hledat zadaný atribut (například ID) zadané proměnné (například nástroj) a vytvořit sloupec naplněný hodnotou atributu. Mateřská proměnná (například nástroj) Nemusí být jedním z dataVariable S zahrnutý v definici datového souboru ERDDAP . Například,

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

To je užitečné, pokud atribut má různé hodnoty v různých zdrojových souborech, protože jinak by uživatelé viděli pouze jednu z těchto hodnot pro celý soubor dat.

Když propagujete atribut jako data, ERDDAP™ odstraní odpovídající atribut. To je vhodné, protože hodnota je pravděpodobně odlišná v každém souboru; vzhledem k tomu, že v souhrnném souboru údajů ERDDAP™ bude mít jen jednu hodnotu. Pokud chcete, můžete přidat novou hodnotu pro atribut pro celý soubor dat přidáním<att name=" atribut Název "> nový Hodnota </att > k proměnné [< addAttributes >] (#addattributy) . Pro atributy, které ERDDAP™ vyžaduje například: ioos\_category (v závislosti na nastavení) , musíte přidat novou hodnotu pro atribut.

název souboru sourceName án

Můžete extrahovat část souboruJméno a propagovat jej jako sloupec dat. Formát tohoto pseudo [< sourceName >] (#zdrojové jméno) je

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

Například,

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

Když EDDTableFromFromFoles čte data ze souboru, ujistí se, že název souboru (například A201807041442.slcpV1 .nc ) odpovídá specifikovanému regulárnímu výrazu ("regex") a extrahovat specifikované (v tomto případě první) Skupina pro zachycení (která je součástí obklopená závorkami) Například "201807041442." (Vidíš tohle? dokumentace regexu a reflexní tutoriál .) Reflex může být specifikován jako řetězec s okolními citacemi nebo bez nich. Pokud je regex určen jako řetězec s okolními citacemi, musí být řetězec String ve stylu JSON (se speciálními znaky utekl s \ znaky) . Číslo skupiny zachycení je obvykle 1 (první skupina zajetí) , ale může být jakékoliv číslo.  

název cesty sourceName án

Můžete extrahovat část plné cesty souboru Název (/adresáře/fileName.ext) a podporovat to, aby to byl sloupec údajů. Formát tohoto pseudo [< sourceName >] (#zdrojové jméno) je

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

Například,

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

Když EDDTableFromFromFoles čte data ze souboru, zajistí celou cestuName (např. /data/myDatasetID/BAY17/B201807041442 .nc . Pro tento test, adresář oddělovače budou vždy '/' , nikdy '\ ') odpovídá specifikovanému regulárnímu výrazu ("regex") a extrahovat specifikované (v tomto případě první) Skupina pro zachycení (která je součástí obklopená závorkami) Například "BAY17." (Vidíš tohle? dokumentace regexu a reflexní tutoriál .) Reflex může být specifikován jako řetězec s okolními citacemi nebo bez nich. Pokud je regex určen jako řetězec s okolními citacemi, musí být řetězec String ve stylu JSON (se speciálními znaky utekl s \ znaky) . Číslo skupiny zachycení je obvykle 1 (první skupina zajetí) , ale může být jakékoliv číslo.  

"0 souborů" Chyba zprávy

• Když utečeš GenerovatDatasetsXml nebo DasDds , nebo pokud se pokusíte načíst EDDTableFrom... Soubory souborů v ERDDAP™ , a dostanete chybovou zprávu "0 souborů" ukazující, že ERDDAP™ nalezeno 0 odpovídajících souborů v adresáři (když si myslíte, že jsou odpovídající soubory v tomto adresáři) :
  • Zkontrolujte, zda jsou soubory skutečně v adresáři.
  • Zkontrolujte pravopis názvu adresáře.
  • Zkontrolujte souborNameRegex. Je opravdu snadné dělat chyby s regexy. Pro testovací účely zkuste regex .\*, který by měl odpovídat všem názvům souborů. (Vidíš tohle? dokumentace regexu a reflexní tutoriál .)
  • Zkontrolujte, zda uživatel, který program provozuje (např. user=tomcat (?) pro přípravek Tomcat/ ERDDAP ) má "číst" povolení pro tyto soubory.
  • V některých operačních systémech (např. SELinux) a v závislosti na nastavení systému musí mít uživatel, který program spustil, oprávnění číst celý řetězec adresářů vedoucích do adresáře, který má soubory.  

standardizovat Co?

• Pokud každá podtřída EDDTableFromFromFoles agreguje soubor zdrojových souborů pro danou proměnnou, všechny zdrojové soubory musí mít stejné hodnoty atributů pro několik atributů: scale\_factor , add\offset , \ nepodepsané, missing\_value , \_FillValue a jednotky). Zamyslete se nad tím: pokud jeden soubor má windSpeed jednotky=knots a druhý má windSpeed jednotky=m/s, pak by se hodnoty dat ze dvou souborů neměly zahrnout do stejného souhrnného souboru. Když tedy EDDTableFromFoles nejprve vytvoří soubor, přečte hodnoty atributu z jednoho souboru, pak odmítne všechny soubory, které mají pro tyto důležité atributy různé hodnoty. Pro většinu souborů to není problém, protože atributy všech proměnných jsou konzistentní. U jiných sbírek souborů to však může vést k 1%, 10%, 50%, 90% nebo dokonce k 99% odmítnutých souborů jako "špatných." To je problém.

EDDTableFrom soubory má systém, který řeší tento problém: standardizovat Co? Standardizace To, co nastavení říká, že EDDTableFromFromFoles má standardizovat soubory, jakmile je přečte, než se EdDTableFromFoles podívá na atributy, aby zjistil, zda jsou konzistentní.

Obrácená strana je: pokud datový soubor nemá tento problém, nepoužívejte standardizaci Co? standardizovat Co má některá možná rizika (Diskutováno níže) a neefektivnosti. Takže pokud vlastně nepotřebujete funkce standardizace Není třeba čelit potenciálním rizikům a neefektivitě. Největší neefektivita je: Když různé standardizovat Jaké možnosti používá datový soubor, to znamená, že zdrojové soubory ukládají data výrazně různými způsoby (např. s různými scale\_factor a add\_offset , nebo s časovými řetězci používajícími různé formáty) . Proto pro dané omezení v žádosti uživatele neexistuje žádný způsob, jak ERDDAP™ vytvořit jediné omezení úrovně zdroje, které lze aplikovat na všechny zdrojové soubory. Takže... ERDDAP™ mohou dotčená omezení uplatňovat pouze na vyšší úrovni. Takže... ERDDAP™ musí před použitím vyšších omezení cílové úrovně číst údaje z více souborů. Takže žádosti o soubory, které používají standardizaci Co trvá déle, než bude zpracováno.

Chcete-li tento systém používat, musíte určit

    <standardizeWhat>*standardizeWhat*</standardizeWhat>  

v datasets.xml pro EDDtableFrom... Soubory souborů (v rámci<Soubor údajů > značka).

The standardizovat Co? hodnota určuje, které změny by se měly zkusit použít. Změny jsou součtem některých kombinací:

1. Vybalit To dělá mnoho běžných a bezpečných operací pro standardizaci numerických sloupců v souborech:
   • Pokud scale\_factor nebo add\_offset atributy jsou přítomny, odstranit je a použít je k vybalení hodnot dat.
   • Rozbalit zabalené atributy (např. aktuální\_min, aktuální\_max, actual\_range , data\_min , data\_max , data\_range, valid\_min , valid\_max , valid\_range ) , pokud existuje, pokud proměnná byla zabalena, a pokud atribut hodnoty byly zabaleny (Je to složité, ale přiměřeně spolehlivé.) .
   • Pokud \_FillValue a/nebo missing\_value jsou přítomny, převést tyto hodnoty dat na ERDDAP 's "standardní" chybějící hodnoty: MAX\_valueE pro integer typy (např. 127 pro bajty, 32,767 pro zkratku a 2.147, 21.3.200647 pro ints, 9223372036854775807 dlouho) a NaN pro dvojníky a plováky.
   • Odstranit staré \_FillValue a/nebo missing\_value atributy (pokud existuje) , a nahradit je pouze \_FillValue= \[ vá ERDDAP™ standardní chybějící hodnota \] .  
2. Standardizovat číselné časy Pokud má číselný sloupec číselné časové jednotky ve stylu CF (" timeUnits od baseTime "např. "dny od roku 1900-01-01") , To převádí datum Hodnoty času do "seconds since 1970-01-01T00:00:00Z" hodnoty a změny atributu jednotek to indikují. Pokud je zvolena a existuje šance, že tato proměnná má scale\_factor nebo add\_offset , #1 MUSÍ být také vybrán.  
3. Použít řetězec missing\_value
   Pokud má sloupec String \_FillValue a/nebo missing\_value atributy, to převádí tyto hodnoty na "" a odstraňuje atributy.  
4. Najít číselnou missing\_value
   Pokud číselný sloupec nemá \_FillValue nebo missing\_value atributy, které se snaží identifikovat nedefinované číselné missing\_value (např. -999, 999, 1e37f) a převést její případy na "standardní" hodnoty (MAX\_VALUE pro integer typy, a NAN pro dvojníky a plováky) . Tato možnost má riziko: pokud největší nebo nejmenší platná hodnota údajů vypadá jako chybějící hodnota (např. 999) , pak tyto platné hodnoty údajů budou převedeny na chybějící hodnoty (např. NaN) .  
5. Změnit řetězec "N/A" na "" Pro každý sloupec String, převést několik řetězců běžně používaných k označení chybějící hodnota String na "" . V současné době to vypadá jako "," "..." "-," "?" "??" "N/A," "NA," "None," "není použitelné," "null," "neznámý," "nespecifikovaný." Hledání strun je případ-necitlivé a aplikovat po strun jsou trim'd. "nd" a "ostatní" nejsou konkrétně na seznamu. Tato možnost má riziko: Struny, které považujete za platné hodnoty, mohou být převedeny na ""  
6. Standardizovat na řetězec ISO 8601 DateTimes Pro každý sloupec String se snažte převést ne-čisté-numerické datum řetězceTimes (např. "Jan 2, 2018") ISO 8601 Datum provázku ("2018-01-02") . Poznámka že všechny hodnoty údajů pro sloupec musí používat stejný formát, jinak tato volba neprovede žádné změny v daném sloupci. Tato možnost má riziko: Pokud existuje sloupec s hodnotami řetězce, který vypadá jako běžné datum Časový formát, budou převedeny na ISO 8601 String dateTimes.  
7. Standardizovat Compact DateTimes do ISO 8601 DateTimes Pro každý sloupec String nebo integer-type se snažte převést čistě numerické datum řetězceTimes (např. "20180102") ISO 8601 Datum provázku ("2018-01-02") . Poznámka že všechny hodnoty údajů pro sloupec musí používat stejný formát, jinak tato volba neprovede žádné změny v daném sloupci. Tato možnost má riziko: Pokud existuje sloupec s hodnotami, které nejsou kompaktní datum Times but look like compact dateTimes, they will be converted to ISO 8601 String dateTimes.  
8. Standardizovat jednotky To se snaží standardizovat řetězec jednotek pro každou proměnnou. Například "metry za sekundu," "metr za sekundu," "m.s^-1" , "m s-1" , "m.s-1" budou všechny převedeny na "m.s-1." To nemění hodnoty dat. To funguje dobře pro platné UDUNITS jednotky řetězce, ale může mít problémy s invalidy nebo složité řetězce. Můžete se vypořádat s problémy tím, že konkrétní od-na páry v<standardizaceUd units > v ERDDAP 's \[ tomcat \] /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util/messages.xml file. Prosím, pošlete Chrisovi všechny změny. John na noaa.gov tak, aby mohly být začleněny do výchozích zpráv.xml. Tato možnost má riziko: To může zamotat některé složité nebo neplatné jednotky; nicméně, můžete použít pracovní-obcházení výše popsané k obcházení problémů, pokud k nim dojde.  

Výchozí hodnota standardizace Co je 0, což nic nedělá.

Pokud změníte hodnotu standardizace Co, příště až bude soubor znovu načten, ERDDAP™ bude znovu číst všechny datové soubory pro datový soubor s cílem obnovit mini-databázi s informacemi o každém souboru. Pokud má soubor mnoho souborů, bude to trvat dlouho.

Poznámky:

• Ošemetná věc je... Standardizace Jaké nastavení se používá pro všechny sloupce ve zdrojovém souboru. Například použití #2048 může úspěšně převést sloupec kompaktního smyčcového dataTimes do ISO 8601 String dateTimes, ale může také omylem převést sloupec se Strings, který se náhodou jeví jako kompaktní datumTimes.  
• datasets.xml a generovatDatasety Xml - Je obzvláště obtížné dostat nastavení správné v datasets.xml aby váš soubor fungoval tak, jak chcete. Nejlepší přístup (jako vždy) je:

1. Použití GenerovatDatasetsXml a zadat hodnotu standardizace Co byste chtěl použít.
2. Použití DasDds zajistit správné zatížení datového souboru a odrážet standardizaci Jaké nastavení jste zadali.
3. Otestovat soubor údajů ručně, když je v ERDDAP™ zajistit, aby postižené proměnné fungovaly podle očekávání.  

• Riziko - Možnosti #256 a vyšší jsou více riskantní, tj. je větší šance, že ERDDAP™ udělá změnu, která by neměla být provedena. Například možnost #2048 může omylem převést proměnnou pomocí řetězce stanice ID, které se jen náhodou podívat ISO 8601 "kompaktní" data (např. 20180102) do ISO 8601 "extended" data ("2018-01-02") .  
• Pomalu po změně... Od hodnoty standardizace Co mění hodnoty dat, které EDDTableFromFromFoles vidí pro každý datový soubor, pokud změníte standardizaci Jaké nastavení, EDDTableFromFoles vyhodí všechny cached informace o každém souboru (která zahrnuje min a max pro každou datovou proměnnou v každém souboru) a znovu si přečtěte každý datový soubor. Pokud má datový soubor velký počet souborů, může to být velmi časově náročné, takže bude trvat dlouho, než soubor bude poprvé znovu načíst ERDDAP™ Nabije ho po změně.  
• Heuristika - Možnosti #256 a výše použít heuristiku k provedení jejich změn. Pokud narazíte na situaci, kdy se heuristici špatně rozhodnou, pošlete prosím Chrisovi popis problému. John v Noaa. Gov, abychom mohli zlepšit heuristiku.  
• Alternativy... Pokud jedna ze standardních možností nevyřeší problém pro daný datový soubor, můžete být schopni vyřešit problém vytvořením .nc soubor ml paralelně každý datový soubor a definovat změny ve věcech v souborech tak, aby byly soubory konzistentní. Pak řekni EDDTableFrom... Soubory souborů k shrnutí .nc ml souborů.

Nebo použít NCO skutečně provést změny souborů tak, aby soubory byly konzistentní.

Samostatné sloupce pro rok, měsíc, datum, hodina, minuta, druhý

Je poměrně běžné, že tabulkové datové soubory mají samostatné sloupce pro rok, měsíc, datum, hodinu, minutu, sekundu. Před ERDDAP™ V2.10, jediným řešením bylo upravit datový soubor tak, aby tyto sloupce byly kombinovány do jednotného časového sloupce. S ERDDAP™ 2, 0+, můžete použít [< sourceName Ostatní výraz < sourceName >] (#zdrojové jméno) říct ERDDAP™ jak kombinovat zdrojové sloupce pro vytvoření jednotného časového sloupce, takže již nemusíte editovat zdrojový soubor.

<SkipHeaderToRegex>

• [<skipheaderToRegex>] (# Skipheadertoregex) -- Volitelně. (Pro EDDTableFromAsciiFiles a EDDTableFromColumnarAsciiFiles pouze datové soubory.)
  Když EDDTableFromAsciiFiles přečte datový soubor, bude ignorovat všechny řádky až do řádky včetně řádku, který odpovídá tomuto regulárnímu výrazu. Výchozí je "," který nepoužívá tuto volbu. Příkladem je

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

který bude ignorovat všechny řádky až do a včetně řádku, který začíná na "\*\*Konec hlavy.

Když používáte tuto značku,<sloupecNázevRow> a<prvníDataRow> působí, jako by hlavička byla odstraněna před čtením souboru. Například byste použili sloupecNázevsRow=0 pokud jsou názvy sloupců v řádku hned za hlavičkou.

Pokud chcete použít generovat Datové soubory Xml s datovým souborem, který potřebuje tuto značku:

1. Vytvořit nový, dočasný, vzorek soubor kopírováním existující soubor a odstranění hlavičky.
2. Spustit generovat Datové soubory Xml a zadejte vzorek souboru.
3. Ručně přidejte<skipheaderToRegex> tag na datasets.xml kus.
4. Smažte dočasný soubor.
5. Použít datový soubor v ERDDAP .

<SkipLinesRegex>

Volitelně. (Pro EDDTableFromAsciiFiles a EDDTableFromColumnarAsciiFiles pouze datové soubory.)
Když EDDTableFromAsciiFiles přečte datový soubor, bude ignorovat všechny řádky, které odpovídají tomuto regulárnímu výrazu. Výchozí je "," který nepoužívá tuto volbu. Příkladem je

    <skipLinesRegex>#.\\*<skipLinesRegex>  

které budou ignorovat všechny řádky, které začínají na "#."

Když používáte tuto značku,<sloupecNázevRow> a<prvníDataRow> působí, jako by všechny odpovídající řádky byly odstraněny před čtením souboru. Například byste použili sloupecNázevsRow=0 i když existuje několik řádků začínajících například "#" na začátku souboru.

EDDTableFromFoles kostra XML

  <dataset type="EDDTableFrom...Files" datasetID\="..." active\="..." >
      <nDimensions>...</nDimensions> <!-- This was used prior to ERDDAP™
        version 1.30, but is now ignored. -->
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <updateEveryNMillis>...</updateEveryNMillis> <!-- 0 or 1. For
        EDDTableFromFiles subclasses, this uses Java's WatchDirectory system
        to notice new/deleted/changed files quickly and efficiently. -->
      <standardizeWhat>...</standardizeWhat> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <nThreads>...</nThreads> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <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> <!-- 0 or 1. Indicates if
        subdirectories of fileDir have data files, too. -->
      <pathRegex>...</pathRegex> <!-- 0 or 1. Only directory names which
        match the pathRegex (default=".\") will be accepted. -->
      <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>
        <!-- 0 or 1 -->
      <metadataFrom>...</metadataFrom> <-- The file to get metadata
        from ("first" or "last" (the default) based on file's
        lastModifiedTime). -->
      <charset>...</charset>
        <!-- (For EDDTableFromAsciiFiles and EDDTableFromColumnarAsciiFiles
        only) This OPTIONAL tag specifies the character set (case
        sensitive!) of the source files, for example, ISO-8859-1
        (the default) and UTF-8. -->
      <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> <!-- 0 or 1 (true or
        false (the default)) -->
      <cacheFromUrl>...</cacheFromUrl> <!-- 0 or 1 -->
      <cacheSizeGB>...</cacheSizeGB> <!-- 0 or 1 -->
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <dataVariable>...</dataVariable> <!-- 1 or more -->
        <-- 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>

EDDTableFromAsciiService

EDDTableFromAsciiService je v podstatě škrabač obrazovky. Je určena k řešení zdrojů dat, které mají jednoduchou webovou službu pro žádost o údaje (často HTML formulář na webové stránce) a které mohou údaje vrátit ve strukturovaném formátu ASCII (například formát textu ASCII oddělený čárkou nebo sloupcem, často s jinými informacemi před údaji a/nebo po nich) .

EDDTableFromAsciiService je supertřída všech EDDTableFromAsciiService... tříd. Nemůžete použít EDDTableFromAsciiService přímo. Místo toho použijte podtřídu EDDTableFromAsciiService pro zpracování konkrétních typů služeb:

• EDDTableFromAsciiServiceNOS získává data od NOAA NOSovy ASCII služby.

V současné době nejsou podporovány žádné jiné typy služeb. Je však obvykle relativně snadné podporovat jiné služby, pokud fungují podobným způsobem. Kontaktujte nás, pokud máte požadavek.

Podrobnosti

Následující informace se vztahují na všechny podtřídy EDDTableFromAsciiService.

• Omezení... ERDDAP™ Tabulkové žádosti o údaje mohou klást omezení na jakoukoli proměnnou. Základní služba může, ale nemusí umožňovat omezení všech proměnných. Například mnoho služeb podporuje pouze omezení jmen stanic, zeměpisné šířky, délky a času. Když tedy podtřída EDDTableFromAsciiService obdrží žádost o podmnožinu datového souboru, přenese co nejvíce omezení na zdrojovou datovou službu a poté použije zbývající omezení na data, která služba vrací, před předáním dat uživateli.
• Platný rozsah -- Na rozdíl od mnoha jiných typů souborů dat, EDDTableFromAsciiService obvykle nezná rozsah dat pro každou proměnnou, takže nemůže rychle odmítnout žádosti o data mimo platný rozsah.
• Analýza ASCII textové odpovědi -- Když EDDTableFromAsciiService dostane odpověď od ASCII Text Service, musí potvrdit, že odpověď má očekávaný formát a informace, a pak extrahovat data. Formát můžete zadat pomocí různých speciálních značek v části XML pro tento datový soubor:
  • <předData1> přes<před značkamiData10> -- Můžete zadat řadu kusů textu (kolik chceš, až do deseti.) že EDDTableFromAsciiService musí hledat v hlavičce textu ASCII vráceného službou s<předData1> přes<předData10>. To je například užitečné pro ověření, zda odpověď zahrnuje očekávané proměnné využívající očekávané jednotky. Poslední předdatová značka, kterou určíte, identifikuje text, který nastane těsně před spuštěním dat.
  • <afterData> -- To určuje text, který bude EDDTableFromAsciiService hledat v textu ASCII vráceném službou, která označuje konec dat.
  • <noData> -- Pokud EDDTableFromAsciiService najde tento text v textu ASCII vráceném službou, dojde k závěru, že neexistují žádné údaje, které by odpovídaly požadavku.

EDDTableFromAsciiService kostra XML

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

EDDTableFromAsciiServiceNOS

EDDTableFromAsciiServiceNOS provádí datové soubory EDDTable z textových datových služeb ASCII nabízených NOAA 's National Ocean Service (NOS) . Informace o tom, jak tato třída funguje a jak ji používat, naleznete v supertřídě této třídy. EDDTableFromAsciiService . Je nepravděpodobné, že někdo jiný než Bob Simons bude muset použít tuto podtřídu.

Vzhledem k tomu, že údaje v rámci odezvy ze služby NOS používají formát textového sloupce ASCII, musí mít datové proměnné jiné než zeměpisná šířka a délka zvláštní atribut, který určuje, které znaky každé datové linky obsahují například údaje této proměnné,

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

 

EDDTableFromAllDatasets

EDDTableFromAllDatasets je datový soubor vyšší úrovně, který má informace o všech ostatních datových souborech, které jsou v současné době naloženy do vašeho souboru ERDDAP . Na rozdíl od jiných typů souborů údajů neexistuje žádná specifikace pro allDatasets Soubor údajů v datasets.xml . ERDDAP™ automaticky vytvoří jeden EDDTableFromAllDatasets soubor (s datasetID = allDatasets ) . Proto allDatasets Databáze bude vytvořena v každém ERDDAP™ instalace a bude pracovat stejným způsobem v každém ERDDAP™ instalace.

The allDatasets Databáze je soubor tabulek. Má řadu informací pro každý soubor údajů. Má sloupce s informacemi o každém datovém souboru, např. datasetID , přístupné, instituce, název, minLongitude, maxLongitude, minZeměpisná šířka, maxZeměpisná šířka, minTime, maxTime, atd. Protože allDatasets je tabulkový datový soubor, můžete si jej vyžádat stejným způsobem, jak si můžete vyžádat jakýkoli jiný soubor tabulky v ERDDAP™ , a můžete určit typ souboru pro odpověď. To umožňuje uživatelům hledat soubory zájmů velmi mocnými způsoby.  

EDDTableFromAsciiFiles

EDDTableFromAsciiFiles agreguje data z čárkových, tabulkových, středníkových nebo mezerně oddělených datových souborů ASCII.

• Nejčastěji budou mít soubory jména sloupců v prvním řádku a data začínající ve druhém řádku. (První řádek souboru se nazývá řádek číslo 1.) Ale můžete použít<sloupecNázevRow> a<prvníDataRow> ve Vašem datasets.xml soubor pro upřesnění jiného čísla řádku.
• ERDDAP™ umožňuje řádkům dat mít různé počty hodnot dat. ERDDAP™ předpokládá, že chybějící hodnoty údajů jsou poslední sloupce v řádku. ERDDAP™ přidělí standardní chybějící hodnoty pro chybějící hodnoty údajů. (přidáno v1.56)
• Soubory ASCII se snadno pracují, ale nejsou nejúčinnějším způsobem, jak ukládat/vymazat data. Pro větší efektivitu uložte soubory jako NetCDF v3 .nc soubory (s jedním rozměrem, "řádkem," sdíleným všemi proměnnými) Místo toho. Můžeš. podání ERDDAP™ generovat nové soubory .
• Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Vzhledem k celkovému nedostatku metadat v ASCII souborech, budete vždy muset upravit výsledky GenerateDatasetsXml.
• UPOZORNĚNÍ: Kdy ERDDAP™ čte datové soubory ASCII, pokud na daném řádku najde chybu (např. nesprávný počet položek) , zaznamenává varovný signál (Špatná linka (án) data" ... se seznamem špatných řádků na následujících řádcích) do log.txt soubor a dále čte zbytek datového souboru. Je tedy vaší povinností pravidelně se dívat (nebo k tomu napsat scénář) pro tuto zprávu v deníku. txt tak, že můžete opravit problémy v datových souborech. ERDDAP™ je nastaven tak, aby uživatelé mohli i nadále číst všechny dostupné platné údaje, i když některé řádky souboru mají nedostatky.  

EDDTableFrom AwsXmlFiles

EDDTableFrom AwsXmlFiles agreguje data ze sady automatických počasí (AWS) XML datové soubory pomocí WeatherBug Rest XML API (která již není aktivní) .

• Tento typ souboru je jednoduchý, ale neefektivní způsob uložení dat, protože se zdá, že každý soubor obvykle obsahuje pozorování jen z jednoho časového bodu. Takže může být velký počet souborů. Pokud chcete zlepšit výkonnost, zvažte konsolidaci skupin pozorování. (Za týden?) v NetCDF v3 .nc soubory (Nejlepší: .nc Soubory s CF Geometrie diskrétního odběru vzorků (DSG) Kontiguous Ragged Array format ) a použití EDDTablefromMultidimNcFiles (nebo EDDTableFromNcCFFiles ) sloužit datům. Můžeš. podání ERDDAP™ generovat nové soubory .
• Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.  

EDDTableFromColumnarAsciiFiles

EDDTableFromColumnarAsciiFiles kumuluje data z tabulkových datových souborů ASCII s kolonami s pevnou šířkou.

• Nejčastěji budou mít soubory jména sloupců v prvním řádku a data začínající ve druhém řádku. První řádek/řádek v souboru se nazývá řádek #1. Ale můžete použít<sloupecNázevRow> a<prvníDataRow> ve Vašem datasets.xml soubor pro upřesnění jiného čísla řádku.

• The< addAttributes > pro každý< dataVariable > pro tyto datové soubory MUSÍ zahrnovat tyto dva zvláštní atributy:

  • <att name="startColumn> celé číslo <attt> -- určuje sloupec znaků v každém řádku, který je začátkem této datové proměnné.
  • <att name="stopColumn] celé číslo <attt> -- určuje sloupec znaku v každém řádku, který je 1 za koncem této datové proměnné.

První sloupec znaku se nazývá sloupec #0. Například pro tento soubor, který má časové hodnoty abutting teplotní hodnoty :

      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

proměnná časových údajů by měla

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

a proměnná časových údajů by měla

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

Tyto atributy MUSÍ být specifikovány pro všechny proměnné kromě pevná hodnota a název souboru a zdrojová jména proměnné.

• Soubory ASCII se snadno pracují, ale nejsou efektivním způsobem, jak ukládat/oddělovat data. Pro větší efektivitu uložte soubory jako NetCDF v3 .nc soubory (s jedním rozměrem, "řádkem," sdíleným všemi proměnnými) Místo toho. Můžeš. podání ERDDAP™ generovat nové soubory .
• Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Vzhledem k tomu, že je obtížné určit počáteční a koncové pozice pro každý datový sloupec a celkový nedostatek metadat v ASCII souborů, budete vždy muset upravit výsledky z GenerateDatasetsXml.  

EDDTableFromHttpGet

EDDTabulka OdHttpGet se liší od všech ostatních typů souborů dat v ERDDAP™ v tom, že má systém, ve kterém mohou konkrétní "autoré" pravidelně přidávat údaje, revidovat údaje nebo mazat údaje z datového souboru HTTP GET nebo POST žádosti z počítačového programu, skriptu nebo prohlížeče. Databázový soubor je dotazovatelný uživateli stejným způsobem, jako jsou všechny ostatní soubory údajů z EDDTable v ERDDAP . Viz popis supertřídy této třídy, EDDTableFromFoles , číst o funkcích, které jsou zděděny z této supertřídy.

Unikátní vlastnosti EDDTableFromHttpGet jsou popsány níže. Musíte si přečíst celou tuto úvodní část a pochopit ji; jinak můžete mít nerealistická očekávání nebo se dostat do problémů, které je těžké opravit.

Zamýšlené použití

Tento systém je určen pro:

• Tabulkové (in situ) data, ne síťovaná data.
• Údaje v reálném čase - Cílem je umožnit autorovi (např. senzor, automatický QC skript nebo konkrétní člověk) provést změnu datového souboru (prostřednictvím . vložit nebo .delete příkaz ) a zpřístupnit tuto změnu ERDDAP™ uživatelé, vše za méně než 1 sekundu, a možná mnohem rychleji. Většina té sekundy je síťový čas. ERDDAP™ může žádost zpracovat za cca 1 ms a údaje jsou okamžitě přístupné uživatelům. Tohle je rychle , robustní a spolehlivý systém .
• Téměř jakákoli frekvence dat - Tento systém může přijímat častá data (např. denně) prostřednictvím velmi častých údajů (např. data 100 Hz) . Pokud optimalizujete systém, zvládne vyšší frekvenci dat (snad 10 KHz dat, pokud jdete do extrémů) .
• Data z jednoho senzoru nebo sbírky podobných senzorů.
• Verze / Reprodukovatelné vědy / DOI s -- Situace, kdy musíte být schopni provést změny údajů (Například změnit vlajku kontroly kvality) , vědět, který autor udělal každou změnu, znát časové razítko, kdy autor udělal změnu, a (na vyžádání) být schopni vidět původní údaje z doby před provedením změny. Proto jsou tyto datové soubory způsobilé pro DOI án . Protože se scházejí DOI požadavek, že soubor údajů se nemění, s výjimkou agregací. Obecně platí, že údaje v reálném čase nejsou způsobilé pro DOI s, protože údaje se často zpětně mění (např. pro účely QA/QC) .  

Jakmile jsou data v souboru EDDTableFromHttpGet, může každý uživatel požadovat data stejným způsobem, jako požadují data z jakéhokoliv jiného souboru EDDTable.  

Experimentální: Opatrně.

Vzhledem k tomu, že tento systém je nový a protože ztracená data o životním prostředí nelze znovu získat, měli byste se k EDDTableFromHttpGet jako experimentální. Pokud jste přechod z jiného systému, spusťte prosím starý systém a nový systém souběžně, dokud si nejste jisti, že nový systém funguje dobře (týdny nebo měsíce, nejen hodiny nebo dny) . Ve všech případech se prosím ujistěte, že váš systém odděleně archivuje .vložte a .delete URL adresy, které jsou zaslány do EDDTableFromHttpGet database (i když jen v Apači a/nebo Tomcatových protokolech) Aspoň na chvíli. A ve všech případech se ujistěte, že datové soubory vytvořené vaším souborem EDDTableFromHttpGet jsou rutinně zálohovány až na externí paměťová zařízení. (Všimněte si, že rsync . může zálohovat datové soubory vytvořené pomocí EDDTableFromHttpZískejte velmi efektivně.)
 

. vložit a .delete

Pro jakýkoli datový soubor v ERDDAP™ , když zašlete žádost na ERDDAP™ pro podmnožinu dat v souboru zadáte typ souboru, který chcete pro odpověď, např. .csv, .htmlTable , .nc , .json . EDDTableFromHttp Získat rozšíření tohoto systému na podporu dvou dalších "typů souborů," které mohou vložit (nebo změna) nebo vymazat údaje v souboru údajů:

• . vložit
  • Žádost je formátována jako standardní HTML forma odezvy, s key=value párů, oddělena '&'. Například, 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
    říká ERDDAP™ přidat nebo změnit údaje pro stationID =46088 pro stanovený čas.
  • Autorem této změny je JohnSmith a klíčem je Klíč1.
  • URL musí obsahovat platné hodnoty (chybějící hodnoty) pro všechny http GetRequiredVariables
  • Pokud hodnoty http GetRequest Proměnné v žádosti (např. stationID a čas) odpovídají hodnoty v řádku již v datovém souboru, nové hodnoty efektivně přepisují staré hodnoty (i když staré hodnoty jsou stále přístupné, pokud uživatel požaduje údaje z předchozího verze souboru údajů) .
  • . vložit URL nesmí nikdy obsahovat &timestrom= ( ERDDAP™ generuje tuto hodnotu) nebo příkaz = (který je určen . vložit (což je příkaz=0) nebo .delete (což je příkaz= 1) ) .
  • Pokud .instalovat URL nespecifikuje hodnoty pro jiné sloupce, které jsou v datovém souboru, jsou považovány za nativní chybějící hodnoty (MAX\_VALUE pro celočíselné datové typy, NaN pro plováky a dvojité a "" pro Struny) .  
  • .delete
    • Žádost je formátována jako standardní HTML forma odezvy, s key=value párů, oddělena '&'. Například, https://some.erddap.url/erddap/tabledap/myDataset**.delete**?stationID=46088&time=2016-03-30T12:37:55Z&author=JohnSmith\_someKey1
      říká ERDDAP™ smazat údaje pro stationID =46088 ve stanovené době.
    • Autorem této změny je JohnSmith a klíčem je Klíč1.
    • URL musí určit http GetRequiredVariables v žádosti (např. stationID a čas) . Pokud tyto hodnoty odpovídají hodnotám v řádku, které jsou již v datovém souboru (které obvykle budou) , staré hodnoty jsou účinně smazány (i když staré hodnoty jsou stále přístupné, pokud uživatel požaduje údaje z předchozího verze souboru údajů) .
    • Není třeba uvádět hodnoty pro non-HttpGetRequiredVariables, jiné než autor, které jsou potřebné k ověření žádosti.  

Podrobnosti:

• .Vložit a .delete žádosti jsou formátovány jako standardní HTML formuláře odpovědi, s key=hodnota párů, odděleny '&'. Hodnoty musí být: % zakódováno . Proto je třeba zakódovat speciální znaky do formuláře %HH, kde HH je 2 číslice hexadecimální hodnota znaku. Obvykle stačí převést několik interpunkčních znaků: % na% 225, & na% 226, "na% 222,<do% 3C, = do% 3D, > do% 3E, + do% 2B, | do% 7C, \[ do % 5B, \] do %5D, prostor na%20, a převést všechny znaky nad #127 do jejich UTF-8 formuláře a pak procento enkódovat každý byte UTF-8 formuláře do%HH formátu (Požádat programátora o pomoc) .
• . Vložit a .delete žádosti musí obsahovat http GetRequiredVariables např. stationID a čas. Pro . vložit žádosti, proměnné, které nejsou uvedeny v žádosti se považují za chybějící hodnoty (MAX\_VALUE pro celočíselné proměnné, NaN pro float a dvojité proměnné a prázdný řetězec pro proměnné String) . Pro .delete žádosti, hodnoty pro non-HtpGetPožadováno Proměnné (jiný než autor, který je vyžadován) jsou ignorováni.
• .Vložit a .delete žádosti musí obsahovat jméno autora a autorův klíč přes parametr ve formuláři autor= autor\_key jako poslední parametr v žádosti. Požadovat to jako poslední zajistí, že celá žádost byla obdržena ERDDAP . Pouze autor (Ne ten klíč.) budou uloženy v datovém souboru. Musíte uvést seznam povolených autor\_key 's pomocí globálního atributu http GetKeys
• . Vložit a .delete parametry mohou být skalární (svobodný) hodnoty nebo pole jakékoli délky ve formě \[ hodnota1, hodnota2, hodnota3,..., hodnotaN \] . Pro daný požadavek musí mít všechny proměnné s polemi pole se stejným počtem hodnot (jinak je to chyba.) . Pokud má požadavek skalární hodnoty a hodnoty pole, skalární hodnoty se replikují tak, aby se staly polemi o stejné délce jako zadaná pole, např. stationID = 46088 lze považovat za stationID = \[ 46088 46088 46088 \] . Arrays jsou klíčem k vysoká propustnost . Bez polí bude náročné .vložit nebo .vymazat více než 8 řádků dat za sekundu od vzdáleného autora (kvůli všem hlavám sítě) . Pomocí polí bude snadné .vložit nebo .vymazat více než 1000 řádků dat za sekundu ze vzdáleného senzoru.
• . vložit a .delete přijmout (bez chybové zprávy) čísla plovoucích bodů, pokud jsou očekávána celá čísla. V těchto případech datový soubor zaokrouhlí hodnoty na celá čísla.
• . vložit a .delete přijmout (bez chybové zprávy) celá čísla a čísla plovoucích bodů, která jsou mimo rozsah datového typu proměnné. V těchto případech databáz ukládá hodnoty jako ERDDAP 's nativní chybějící hodnoty pro tento datový typ (MAX\_VALUE pro integer typy a NaN pro plováky a dvojité) .  

Odpověď

Pokud URL . vložit nebo .delete uspěje, HTTP kód odezvy bude 200 (Dobře.) a odpověď bude text s .json předmět, např.

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

Všimněte si, že časové značky mají milisekundovou přesnost.

Pokud URL . insert nebo .delete selže, dostanete jiný HTTP kód odezvy než 200 (Dobře.) , např. chyba 403 Zakázat, pokud předložíte nesprávnou hodnotu autora\_key. ERDDAP™ odešle HTTP kód odezvy (ne, např., .json Zformátovaná chyba) protože tak se věci dělají na internetu a protože chyby se mohou objevit kdekoliv v systému (např. v síti, která vrací chybu HTTP) . Pokud je chyba z ERDDAP™ , odpověď může obsahovat nějaký text (ne .json ) s podrobnějším vysvětlením, co se pokazilo, ale HTTP kód odezvy (200=OK, všechno ostatní jsou potíže) je správný způsob, jak zkontrolovat, zda . vložit nebo .delete podařilo. Pokud není kontrola HTTP kódu odezvy možná nebo není vhodná, hledejte "status":"úspěch" v textu odpovědi, který by měl být spolehlivým ukazatelem úspěchu.

Soubory záznamů

Když EDDTableFromHttpGet receives . vložit a .delete příkazy, jednoduše připojí informace k příslušnému souboru v sadě log souborů, z nichž každý je tabulka uložená v JSON Řádky CSV souboru . Pokud uživatel podá žádost o údaje, ERDDAP™ rychle čte příslušné soubory záznamů, aplikuje změny datového souboru v pořadí, které byly provedeny, a pak filtruje žádost prostřednictvím omezení uživatele, jako každý jiný ERDDAP™ požadavek na údaje. Rozdělení dat do různých souborů protokolu, ukládání různých informací (např. časové razítko příkazu a zda příkaz byl . vložit nebo .delete) , a různé aspekty nastavení datového souboru, vše umožňuje pro ERDDAP ukládat data do tohoto datového souboru a získávat data z tohoto souboru velmi rychle a velmi efektivně.  

Bezpečnost a autor

Každý příkaz . vložit a .delete musí obsahovat &autor= autor\_key jako poslední parametr, kde se autor\_key skládá z identifikátoru autora (jste si vybrali: jméno, iniciály, pseudonym, číslo) Podtržení a tajný klíč. The ERDDAP™ Správce bude pracovat s autory na vytvoření seznamu platných hodnot autora\_key, které lze kdykoli změnit. Když EDDTableFromHttpGet obdrží příkaz .vlož nebo .delete, zajistí, že autorID\_key je poslední parametr a je platný. Protože je to poslední parametr, ukazuje to, že celá příkazová čára dosáhla ERDDAP™ a nebyl zkrácen. Tajný klíč zajišťuje, že údaje do datového souboru mohou vkládat nebo smazat pouze konkrétní autoři. ERDDAP™ pak extrahuje autoraID a uloží to do proměnné autora, aby každý mohl vidět, kdo byl zodpovědný za danou změnu datového souboru. . vložit a .delete příkazy lze provést pouze prostřednictvím https: (bezpečné) ERDDAP™ URL. Tím se zajistí, že informace, které se předávají, jsou během přepravy utajeny.  

časové razítko

Jako součást systému záznamu, EDDTableFromHttpGet přidá časové razítko (čas, kdy ERDDAP obdržel žádost) na každý příkaz, který ukládá do logových souborů. Protože ERDDAP™ generuje časové razítko, ne autory, nezáleží na tom, zda různí autoři provádějí změny z počítačů s hodinami nastavenými na mírně odlišné časy. Časové razítko spolehlivě označuje dobu, kdy byla provedena změna datového souboru.  

HTTP POST

• "A co HTTP POST?"
  HTTP POST je lepší alternativa (ve srovnání s HTTP GET ) pro zasílání informací od klienta na HTTP server. Pokud můžete, nebo pokud opravdu chcete zlepšit bezpečnost, použijte POST místo GET odeslat informace na ERDDAP . POST je bezpečnější, protože: s GET a https , URL je přenášena bezpečným způsobem, ale celé URL (včetně parametrů, včetně autora\_key) budou napsány Apači, Tomcatovi a ERDDAP™ soubory protokolu, kde je někdo může přečíst, pokud nejsou řádně zabezpečeny. S POST jsou parametry přenášeny bezpečným způsobem a nejsou zapsány do logových souborů. POST je trochu těžší pro klienty pracovat a není podporován tak široce klientským softwarem, ale programovací jazyky jej podporují. Obsah, který zašlete do souboru dat prostřednictvím GET nebo POST, bude stejný, jen formátován jiným způsobem.  

http GetRequest Proměnné Globální atribut

Základní součástí toho, co dělá celý tento systém funkční je požadovaný globální atribut http GetRequest Proměnné, které je čárkou oddělený seznam dataVariable název zdroje, který jednoznačně identifikuje řádek údajů. To by mělo být co nejmenší a bude téměř vždy obsahovat časovou proměnnou. Například zde jsou doporučené http GetRequest Proměnné pro každou z CF Geometrie diskrétního odběru vzorků (DSG) (ID jména se samozřejmě mohou ve vašem souboru lišit.) :

• Pro časové řady: stationID , čas
• Pro trajektorie: trajektorie ID, čas
• Pro profil: čas (za předpokladu, že čas je profil\_id) , hloubka
• Pro časové řady Profil: stationID , čas (za předpokladu, že čas je profil\_id) , hloubka
• Pro trajektorii Profil: trajektorie ID, čas (za předpokladu, že čas je profil\_id) , hloubka

Bereme TimeSeries jako příklad: Vzhledem k tomu, . vložit příkaz, který zahrnuje stationID =46088 a čas=2016-06-23T19:53:00Z (a další hodnoty pro jiné proměnné) :

• Pokud pro tuto stanici a tuto dobu neexistují žádné údaje, pak bude mít za následek přidání údajů do souboru údajů.
• Pokud pro tuto stanici a tuto dobu existují údaje, pak bude mít za následek nahrazení existujícího řádku dat těmito novými daty. (Samozřejmě, od ERDDAP™ uchovává záznam každého příkazu, který obdrží, stará data jsou stále v záznamu. Pokud uživatel před touto změnou požádá o data z verze datového souboru, uvidí starší data.)
   

http Get DirectoryStrukture

• http Get Directory Struktura Globální atribut a data (Záznam) Název souboru
  Součástí toho, co dělá celý tento systém efektivně fungovat, je, že ERDDAP™ vytvoří soubor dat (log) soubory, každý s jiným kusem datového souboru. Jestli jsou dobře nastavené, ERDDAP™ bude moci rychle reagovat na většinu žádostí o údaje. Toto nastavení je určeno http GetDirectoryStructure globální atribut, což je String, který vypadá jako relativní název souboru, např., " stationID /10 let," ale ve skutečnosti je to specifikace struktury adresáře. V části, která označuje, jak adresář a názvy souborů pro data (log) Soubory budou vytvořeny.

• Pokud část je celé číslo (Ostatní 1) plus časPeriod (milisekunda, sekunda, minuta, hodina, datum, měsíc, rok nebo jejich množné číslo) , např. 10 let, pak EDDTableFromHttpGet soubor dat bude mít časovou hodnotu pro řádek dat (např. 2016-06-23T19:53:00Z) , vypočítat čas zkrácený na tuto přesnost (např. 2010) , a vytvořit složku nebo soubor Jméno z toho.

Cílem je dostat poměrně velký kus dat do každého souboru, ale mnohem méně než 2GB.

• V opačném případě musí být část specifikace dataVariable 's sourceName např. stationID . V tomto případě, EDDTableFromHttpGet vytvoří složku nebo název souboru z hodnoty této proměnné pro nový řádek dat (např. "46088") .

Vzhledem k tomu, . vložit a .delete příkaz data jsou uloženy v konkrétních datech (log) soubory, EDDTableFromHttpZískejte obvykle pouze jednu nebo několik dat (log) soubory k nalezení údajů pro daný uživatelský požadavek. A protože každá data (log) soubor má všechny relevantní informace pro jeho část datového souboru, je to rychlé a snadné pro EDDTableFromHttpZískejte konkrétní verzi (nebo aktuální verze) souboru údajů pro údaje v tomto souboru (a nemusí vytvářet požadovanou verzi celého souboru údajů) .

Obecné pokyny vycházejí z množství a četnosti údajů. Pokud předpokládáme 100 bytů za řádek dat, pak ...

    | 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* |

Například, pokud struktura adresáře je stationID /2 měsíce a vložíte data ze dvou stanic (46088 a 46155) s časovými hodnotami od prosince 2015 do května 2016, EDDTableFromHttp Get vytvoří adresáře pojmenované 46088 a 46155 a vytvoří soubory v každém pojmenovaném 2015-11 .json L, 2016-01 .json L, 2016-03 .json L, 2016-05 .json l (každý podnik v hodnotě dvou měsíců údajů pro příslušnou stanici) . Kdykoliv v budoucnu, pokud používáte .vložte nebo .delete pro změnu nebo vymazání údajů například pro stanici 46088 na 2016-04-05T14:45:00Z, EDDTableFromHttp Získat připojí tento příkaz na 46088/2016-03 .json l příslušné údaje (log) Složka. A je jasné, že je v pořádku kdykoli v budoucnu přidávat data pro další stanice, protože datový soubor vytvoří pouze další adresáře potřebné k uchování dat z nových stanic.

http GetKeys

Každý EDDTable OdHttp Získat soubor dat musí mít globální atribut http GetKeys, který určuje seznam autorů a jejich tajných klíčů jako čárku oddělený seznam autor\_key např. JohnSmith\_someKey1, HOBOLogger\_someKey2, QCScript59\_someKey3 .

• autor\_key jsou citlivé na případ a musí být zcela ASCII znaky (#33 - #126, a bez čárky, " nebo ' znaků
• Klíče jsou jako hesla, takže MUSÍ být [ng.8] znaků, těžko uhodnout, a bez vnitřních slovníkových slov. Měli byste se k nim chovat tak, jako byste k heslům přistupovali. Udržujte je v soukromí.
• První znak '\' odděluje autora od klíče, takže jméno autora nemůže obsahovat znak '\' (Ale klíč může) .
• Každý daný autor může mít jeden nebo více autorů, např. JohnSmith\_some Key1, JohnSmith\_some Key7, atd.
• Hodnota tohoto atributu můžete kdykoli změnit. Změny nabývají účinku, až bude příště soubor dat načten.
• Tyto informace budou odstraněny z globálních atributů datového souboru dříve, než budou zveřejněny.
• Každá žádost o vložení nebo odstranění údajů do datového souboru musí obsahovat &Author= autor\_key parametr. Po ověření platnosti klíče, ERDDAP™ pouze zachrání autorskou část (Ne ten klíč.) v datovém souboru.

Nastavit

Zde jsou doporučené kroky k nastavení EDDTableFromHttpGet souboru:

1. Udělejte hlavní adresář pro uložení dat tohoto datového souboru. Pro tento příklad pojďme použít /data/testGet/ . Uživatel běžící GenerateDatasetsXml a běžící uživatel ERDDAP™ musí mít oba přístup ke čtení do tohoto adresáře.  

2. Použijte textový editor k vytvoření vzorku .json l CSV soubor s příponou .json V tom adresáři. Jméno není důležité. Například, můžete tomu říkat vzorek. .json l Udělejte čáru 2 .json l CSV soubor s názvy sloupců na prvním řádku a netypickými hodnotami (správného datového typu) na druhém řádku. Zde je vzorek soubor, který je vhodný pro sběr featureType =TimeSeries data, která měří teplotu vzduchu a vody. \[ Pro featureType Trajectory, možná se změníš. stationID k trajektorii ID. \]
   \[ Pro featureType Profile, můžete změnit stationID být profileID a přidat proměnnou hloubky. \]

   \[ " stationID " "time" , "zeměpisná šířka," "podélka," "airTemp," "waterTemp," "timestrom," "autor," "command" \] \[ "myStation," "2018-06-25T17:00:00Z," 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, "SomeBody," 0 \]

Poznámka:

• Na skutečných datových hodnotách nezáleží, protože nakonec tento soubor smažete, ale měly by být správného datového typu. Zejména by časová proměnná měla používat stejný formát, jaký budou používat skutečná data ze zdroje.
• Pro všechny proměnné sourceName bude rovno destinationName , tak použijte správné/konečné názvy proměnných nyní, včetně času, zeměpisné šířky, délky a někdy hloubky nebo výšky, pokud budou zahrnuty proměnné s těmito informacemi.
• Téměř vždy bude proměnná pojmenovaná čas, který zaznamenává čas pozorování. Může to být dataType String s jednotky vhodné pro časy strun (např. yyyy-MM-dd T'HH:mm:ss.SSSZ) nebo údaje Typ dvojitý s jednotky vhodné pro numerické časy (např. sekundy od 1970-01-01T00:00:00Z nebo nějaký jiný základní čas) .
• Tři sloupce (obvykle poslední tři.) Musí to být časové razítko, autore, příkaz.
• Sloupec časového razítka bude použit pomocí EDDTableFromHttpGet to add a timemarking when it added a protection of data to the data file. Bude mít dataType double a jednotky sekundy od 1970-01-01T00:00:00Z.
• Autorský sloupec s datyType String bude použit k záznamu autora, který poskytl data tohoto řádku. Autorizovaní autoři jsou určeni http GetKeys globální atribut . Přestože klíče jsou specifikovány jako autor\_key a jsou v "žádosti" URL v této podobě, pouze autorská část je uložena v datovém souboru.
• Sloupec příkazu s datovým typem byte označuje, zda jsou data na tomto řádku vložena (0) nebo výmaz (1) .  

3. Spustit generováníDatasets Xml a řekni to.

   1. Typ datového souboru je EDDTableFromHttpGet
   2. Adresář je (pro tento příklad) /data/test Dostat/
   3. Soubor vzorku je (pro tento příklad) /data/testGet/startup .json l
   4. The http GetRequest Proměnné jsou (pro tento příklad) stationID , čas Viz popis http GetRequiredVariables dole.
   5. Pokud jsou údaje shromažďovány každých 5 minut, http GetDirectoryStruktura pro tento příklad je stationID /2 měsíce . Viz popis http Get DirectoryStrukture dole.
   6. The http GetKeys

Přidat výstup (část datasets.xml pro soubor údajů) až datasets.xml .   4. Upravit datasets.xml kus pro tento datový soubor, aby byl správný a kompletní. Hlavně nahradit všechny ??? se správným obsahem.   5. Pro<souborTableInMemory> nastavení:

• Nastavte to na true, pokud soubor souborů obvykle dostane časté . vložit a / nebo .delete žádosti (např. častěji než jednou za 10 sekund) . To pomáhá EDDTableFromHttpZískejte odpověď rychleji .vložit a / nebo .delete žádosti. Pokud to nastavíte na true, EDDTableFromHttpGet bude stále ukládat souborTable a související informace na disk pravidelně (podle potřeby přibližně každých 5 sekund) .
• Nastav to na faleš. (výchozí) v případě, že soubor údajů se obvykle dostane zřídka . vložit a / nebo .delete žádosti (např. méně než jednou za 10 sekund) .  

6. Poznámka: Je možné použít<cacheFromUrl> a související nastavení v datasets.xml pro EDDTable OdHttp Získejte soubory dat jako způsob, jak vytvořit a udržovat místní kopii vzdáleného EDDTableFromHttpGet soubor na jiném ERDDAP . V tomto případě však tento místní datový soubor odmítne žádné . vložit a .delete žádosti.

Použití EDDTable OdHttpGet Datasets

• Autoři mohou podat "žádost," která vložit údaje do souboru údajů nebo je z něj vymazat .  
• Po vložení reálných dat do datového souboru můžete a měli byste smazat původní soubor se vzorkem dat.  
• Uživatelé mohou požadovat data z datového souboru, jako to dělají pro jakýkoli jiný datový soubor EDDTable v ERDDAP . Pokud žádost neobsahuje omezení sloupce časového razítka, pak žádost získá data z aktuální verze datového souboru (soubor záznamu po zpracování všech příkazů k vložení a vymazání a opětovném třídění http GetRequiredVariables) .  
• Uživatelé mohou také podávat žádosti, které jsou specifické pro EDDTableFromHttpZískejte soubory dat:
  • Pokud žádost obsahuje<nebo<= omezení sloupce časového razítka, pak ERDDAP™ zpracovává řádky souboru záznamu až do stanoveného časového razítka. To ve skutečnosti dočasně odstraní všechny změny v datovém souboru od této hodnoty časového razítka. Více informací viz Verze .
  • Pokud žádost obsahuje >, > >, > nebo = omezení sloupce časového razítka, např. &time razítko<=0, pak ERDDAP™ vrací data z datových souborů tak, jak je, bez zpracování vkládání a vymazání příkazů.
• V budoucnu si představujeme, že nástroje budou postaveny (námi? tebou?) pro práci s těmito soubory dat. Například by mohl existovat skript, který čte raw log soubory, používá jinou kalibrační rovnici, a generuje / aktualizuje jiný datový soubor s těmito odvozenými informacemi. Všimněte si, že skript může získat původní data prostřednictvím požadavku na ERDDAP™ (který dostane data ve formátu souboru, který je nejjednodušší pro skript pracovat s) a generovat / aktualizovat nový datový soubor prostřednictvím . vložit "žádosti" na ERDDAP . Skript nepotřebuje přímý přístup k datovým souborům; může být na libovolném autorském počítači.  

Podrobné informace o EDDTableFromHttpGet

Témata jsou:

• Neměňte nastavení!
• CRUD
• Neplatné žádosti
• Rychlost
• Robustní
• Spolehlivost systému
• Verze
• "A co HTTP PUT a DELETE?!"
• Poznámky
• Díky CHORDS za základní myšlenku.

Zde jsou podrobné informace:

Neměňte nastavení!

Po vytvoření datového souboru jste k němu přidali data:

• Nepřidávejte ani neodstraňujte dataVariable s.
• Neměňte sourceName nebo destinationName z dataVariable s.
• Neměňte data. Druh dataVariable s. Ale můžete změnit dataVariable Metadata.
• Neměňte http GetRequest Proměnné globální atribut.
• Neměňte http Získat globální atribut DirectoryStructure.

Pokud potřebujete změnit některou z těchto věcí, vytvořte nový datový soubor a všechny údaje přeneste do nového datového souboru.  

CRUD

V počítačové vědě jsou čtyři základní příkazy pro práci s datovým souborem CREATE, READ, UPDATE, DELETE (CRUD) . SQL, jazyk pro práci s relačními databázemi, má ekvivalent v INSERT, SELECT, UPDATE a DELETE. V EDDTableFromHttpGet,

• .Vložit je kombinace CREATE a UPDATE.
• .delete je DELETE.
• Pravidelný systém pro požadavek podskupin dat je READ.

Proto EDDTableFromHttpGet podporuje všechny základní příkazy pro práci s datovým souborem.  

• .vložte nebo .delete žádosti bez chyb vrátí HTTP status kód=200 a JSON objekt, např.,

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

Dvě hodnoty časového razítka se vztahují na stejnou milisekundu, což je milisekunda, která bude uložena v proměnné časového razítka pro řádky dat, které byly vloženy nebo smazány. ERDDAP™ nezmění jméno a formátování těchto párů hodnot klíče v budoucnu. ERDDAP™ může v budoucnu přidat další dvojice hodnot klíče k objektu JSON.  

Neplatné žádosti

Neplatné . vložte nebo .delete žádosti vrátí HTTP chybový kód jiný než status=200 a žádná změna nebude provedena do souboru dat. To zahrnuje požadavky s nesprávnými autorskými informacemi, nesprávné názvy proměnných, různé délky pole pro různé proměnné, chybějící požadované proměnné, chybějící požadované proměnné atd. Pokud se žádost týká více než jednoho datového souboru, je možné, že část žádosti uspěje a část selže. Nicméně by to neměl být problém, pokud senzor odešle požadavek považuje jakékoli selhání za úplné selhání. Například, když řeknete ERDDAP™ k vložení (nebo smazat) stejná data dvakrát v řadě, nejhorší případ je, že tato informace je uložena dvakrát, zavřít společně v log souboru. Je těžké pochopit, jak by to mohlo způsobit potíže.  

HttpGet Speed

Pro . vložit nebo . vymazat žádosti (nepočítám http režijní náklady) , Ballpark čísla rychlost . vložit nebo .delete jsou 1ms per . vložit s 1 řádek údajů 2ms per . vložte 10 řádků dat do polí ( \[ \] )
3ms per . vložte do polí 100 řádků dat ( \[ \] )
13ms per . Vložte 1000 řádků dat do polí ( \[ \] )
Jasně pole jsou klíčem k vysoká propustnost . Bez polí bude náročné .vložit nebo .vymazat více než 8 řádků dat za sekundu od vzdáleného autora (kvůli všem hlavám sítě) . Pomocí polí bude snadné .vložit nebo .vymazat více než 1000 řádků dat za sekundu ze vzdáleného senzoru.

S velmi velkým množstvím dat na žádost, budete hit Tomcat je limit na maximální délku dotazu (výchozí je 8KB?) , ale to lze zvýšit editací nastavení maxHttpHeaderSize ve vašem tomcat /conf/server.xml HTTP/1.1 Vstup konektoru.

Kdy? ERDDAP™ čte data JSON Lines CSV (log) soubory, tam je malý časový trest ve srovnání s čtením binárních datových souborů. Měli jsme pocit, že tento časový trest při čtení byl rozumnou cenou za rychlost a robustnost systému při psaní údajů (která má zásadní význam) .

SSD

Pro větší rychlost, a Solid State Drive (SSD) uchovávat data. Mají mnohem rychlejší přístupový čas (<0.1ms) než pevné disky (3 - 12 ms) . Také mají rychlejší přenos dat. (200 - 2500 MB/s) než disky pevných disků (~200 MB/s) . Jejich náklady se v posledních letech značně snížily. I když brzy SSD měl problémy po velkém počtu píše na daný blok, tento problém je nyní výrazně snížena. Pokud stačí použít SSD pro zápis dat jednou pak přečíst mnohokrát, dokonce i spotřebitelské třídy SSD (která je podstatně levnější než SSD kategorie podniků) Mělo by to vydržet dlouho.

Robustní

Snažili jsme se, aby tento systém byl co nejjednodušší a co nejpevnější.

• Systém je navržen tak, aby měl více vláken (např. senzor, automatický QC skript a člověk) současně pracuje na stejném datovém souboru a dokonce na stejném souboru. Většinu z toho je možné pomocí log souboru přístup k ukládání dat a pomocí velmi jednoduchý typ souboru, JSON Řádky CSV souborů Uložit data.
• Další obrovskou výhodou JSON Lines CSV je, že pokud se soubor někdy zkazí (např. neplatná kvůli chybě na řádku) , je snadné otevřít soubor v textovém editoru a opravit problém.
• Další výhodou je, že pokud je chyba na řádku v souboru, systém může stále číst všechna data na řádku před a po řádku chyb. A systém může stále log další . vložit a .delete informace.
• Obrovská výhoda použití admin-přístupných standardních souborů (ve srovnání s relační databází nebo Cassandrou nebo jiným softwarem) : Neexistuje žádný jiný software, který musí být udržován a který musí být spuštěn, aby mohl ukládat nebo získávat data. A je snadné zálohovat standardní soubory kdykoliv a postupně, protože data jsou v částech (Po chvíli se bude měnit pouze aktuální soubor pro každou stanici) . Naproti tomu k vytvoření externích zálohových souborů z databází a z Cassandry vyžaduje značné úsilí a systém dolů.  

Spolehlivost systému

Je rozumné očekávat jeden server s ERDDAP™ mít 99,9% přesčas - to je asi 9 hodin volna ročně (I když to můžeš použít za jednu špatnou noc!) . Pokud jste pilní a šťastní, můžete dostat 99,99% přesčas (53 minut prostoje ročně) , Protože jen několik restartů pro aktualizace bude trvat tolik času. Musíte přijmout extrémní opatření. (samostatný záložní server, nepřerušitelný zdroj energie, záložní klimatizace, 24x7x365 personál sledovat stránky, atd.) mít malou šanci na 99,99% přesčas (5,25 minut prostoje ročně) . I tehdy je velmi nepravděpodobné, že dosáhnete 99,99% přesčasu. (nebo dokonce 99,99%) Protože problémy jsou často mimo vaši kontrolu. Například Amazon Web Service a Google nabízejí neuvěřitelně spolehlivé webové služby, ale velké části z nich jsou někdy mimo hodiny.

Přiznej si to, každý chce ERDDAP™ mít stoprocentní čas, nebo alespoň "šest devítek" (99,9999% přepážky se rovná 32 sekund prostoje za rok) Ale není možné, abys ho dostal, bez ohledu na to, kolik času, úsilí a peněz utratíš.

Ale... ERDDAP™ Uptime není skutečný cíl. Cílem je vybudovat spolehlivé systém , který neztratí žádná data. Tohle je řešitelný problém.

Řešením je: vybudovat chybovou toleranci do počítačového softwaru, který posílá data do ERDDAP . Konkrétně, tento software by měl udržovat frontu dat čekajících na přechod na ERDDAP . Když jsou data přidána do fronty, software by měl zkontrolovat odpověď ERDDAP . Pokud odpověď nezahrnuje přijatá data. Žádné chyby., pak software by měl nechat data ve frontě. Při generování a přidávání dat do fronty by se software měl pokusit znovu vložit data do fronty. (Možná s \[ \] systém) . Uspěje nebo selže. Pokud selže, zkusí to později. Pokud napíšete software pro práci tímto způsobem a pokud je software připraven na frontu několika dní v hodnotě dat, máte skutečně dobrou šanci nahrát 100% dat senzoru do ERDDAP . A uděláte to bez velkého úsilí nebo výdajů.

\[ Pozadí: Nevymysleli jsme si to. Takto počítačové sítě dosahují spolehlivosti. Počítačové sítě jsou neodmyslitelně nespolehlivé. Takže když přenesete soubor z jednoho počítače do druhého, odesílací software ví / očekává, že některé pakety mohou být ztraceny. Pokud nedostane správné uznání pro daný paket z přijímače, odešle ztracený paket. S tímto přístupem může relativně jednoduchý odesilatel a přijímačový software vybudovat spolehlivý systém přenosu souborů na vrcholu nespolehlivé sítě. \]

Proč JSON Lines CSV soubory?!

EDDTableFromHttpZískat použití JSON Řádky CSV souborů . pro uložení dat. Důvody jsou:

• Hlavním důvodem je: jednoduchost souborů JSON Lines CSV nabízí rychlý, snadný a spolehlivý způsob, jak umožnit více vláken k zápisu do daného souboru (např. synchronizací názvu souboru) .
• Pokud se soubor JSON Lines CSV někdy zkazil (např. neplatná kvůli chybě na řádku) , EDDTableFromHttpGet mohl stále číst všechna data na všech řádcích před a po řádku chyb. A .insert a .delete systém by mohl i nadále přidávat nová data do datového souboru.
• Protože soubory JSON Lines CSV jsou ASCII soubory, pokud by soubor byl někdy poškozen, bylo by snadné opravit (v textovém editoru) .
• JSON Lines CSV podporuje Unicode strings.
• JSON Lines CSV podporuje řetězce délky proměnné (není omezena na určitou maximální délku) .
• JSON Lines CSV podporuje 64-bit celá čísla (dlouhé) .
• Formální povaha a extra syntaxe JSON Lines CSV (CSV ze staré školy) poskytuje zvláštní ujištění, že daná linka nebyla poškozena.

Zpočátku jsme se snažili použít .nc 3 soubory s neomezeným rozměrem. Byly však problémy:

• Hlavním problémem bylo: Neexistuje spolehlivý způsob, jak umožnit více vláken psát na .nc 3 soubor, i když vlákna spolupracují tím, že píše synchronizovaným způsobem.
• Pokud .nc 3 soubor se zkazí, . vložit a .delete systém nemůže nadále používat soubor.
• Protože .nc 3 soubory jsou binární, pokud se soubor zkazí (což dělají kvůli problému s více vlákny) jsou mimořádně těžké nebo nemožné opravit. Nejsou žádné nástroje, které by pomohly s opravou.
• CF nemá žádný způsob, jak určit kódování řetězců, takže neexistuje oficiální způsob, jak podpořit Unicode, např. kódování UTF-8. Snažili jsme se získat CF na podporu atributu \_Encoding, ale nebyli schopni dosáhnout žádného pokroku. ( Unidata , ke svému úvěru, podporuje atribut \_Encoding.)
• .nc 3 soubory podporují pouze řetězce s pevnou délkou. Znovu jsme se snažili získat CF a Unidata podporovat řetězce proměnné délky, ale nebyli schopni dosáhnout žádného pokroku.
• .nc 3 soubory nepodporuje snadný způsob, jak rozlišit proměnné jednotlivých znaků od proměnných String. Znovu jsme se snažili získat CF a Unidata podporovat systém pro rozlišení těchto dvou typů údajů, avšak nebyli schopni dosáhnout žádného pokroku.
• .nc 3 soubory podporují pouze 8-bitové znaky s nespecifikovaným kódováním. Znovu jsme se snažili získat CF a Unidata podporovat systém pro určení kódování, ale nebyli schopni dosáhnout žádného pokroku.
• .nc 3 soubory nepodporuje 64-bit celá čísla (dlouhé) . Znovu jsme se snažili získat CF a Unidata podporovat systém po dlouhou dobu, ale nebyli schopni dosáhnout žádného pokroku.  

Verze

Protože EDDTable OdHttp Získejte záznamy všech změn datového souboru s časovým razítkem a autorem každé změny, může rychle obnovit tento datový soubor kdykoli. V jistém smyslu existuje verze pro jakýkoliv čas. Pokud žádost uživatele o údaje obsahuje časové razítko<= omezení, např. &časové razítko<=2016-06-23T16:32:22.128Z (nebo jakýkoli časový bod) , ale bez omezení autora nebo příkazu, ERDDAP™ bude na žádost reagovat prvním vytvořením verze datového souboru k tomuto okamžiku. Pak, ERDDAP™ uplatňuje jiná omezení uživatele, stejně jako u všech ostatních žádostí o údaje od ERDDAP . EDDTableFromHttpGet je nastaven tak, že tento proces je velmi rychlý a efektivní, i pro velmi velké soubory dat.

Podobně může uživatel zjistit, kdy byl datový soubor naposledy aktualizován žádostí o ...?timerazítko&timerazítko=max (časové razítko) & Distinct ()

A pro každou žádost o data, pro jakoukoli verzi datového souboru, uživatelé mohou vidět, který autor udělal, které změny, a když je udělali.

Tento systém verzí umožňuje Reprodukovatelné vědy protože kdokoliv může kdykoli požádat o údaje z verze datového souboru. Toto jemné verze není možné s žádným jiným systémem, o kterém víme. Podkladový mechanismus je velmi efektivní, protože není zapotřebí žádné další skladovací prostory, a zpracování nad rámec je skutečně minimální.

Ne každý potřebuje tento typ jemné verze, ale je mimořádně užitečný, možná nezbytný, v kontextu velké organizace pro správu dat. (např. OOI, Earth Cube, Data One a NOAA 's NCEI) kde soubor údajů může mít více autorů (např. senzor, automatický QC skript a lidský editor) .

\[ Historie: Potřeba tohoto typu verze poprvé přišla pro mě (Bobe.) při čtení a diskusi o OOI v roce 2008. V té době, OOI měl těžkopádný, pomalý, neefektivní systém pro verze založené na Git. Git je skvělý pro to, k čemu byl navržen, ale ne pro tohle. V roce 2008 jsem na diskuzi OOI navrhl rozsáhlý, účinný alternativní systém pro správu dat, včetně mnoha funkcí, které jsem přidal k ERDDAP™ od té doby, včetně tohoto systému verzí. V té době a od té doby byl OOI oddán jejich systému verzí a nezajímal se o alternativy. V roce 2016 se objevily další aspekty tohoto plánu a začal jsem jej provádět. Vzhledem k tomu, že tam bylo mnoho přerušení pracovat na jiných projektech, jsem neměl dokončit až 2018. Ani teď nevím o žádném jiném vědeckém datovém systému, který nabízí tak rychlý a snadný přístup k verzi dat z jakéhokoliv okamžiku, pro často se měnící soubory dat. Jednoduchý souborový systém to nenabízí. Relativní databáze ne. Cassandra ne. \]

HTTPS Put and Delete

• "A co HTTPS PUT a DELETE?!"
  Protokol Hypertext Transfer (HTTP) je základem World Wide Web a důvod, proč webové stránky URL začínají s "http://"nebo "https://". HTTPS je HTTP s dodatečnou bezpečnostní vrstvou. Každý den, prohlížeče, skripty a počítačové programy tvoří miliardy HTTP (S) GET žádá o získání informací ze vzdálených zdrojů. HTTP (S) zahrnuje také jiné slovesa , zejména PUT (přesměrovat data na server) A DELETE (na DELETE data ze serveru) . Ano, PUT a DELETE jsou vhodným způsobem, jak vložit data do datového souboru a z něj odstranit data přes HTTP (S) . GET podporuje každý kousek softwaru, který může pracovat s HTTP (S) . GET je opravdu snadné pracovat s. Každý již ví, jak pracovat s GET a mnozí vědí, jak používat POST (které lze použít v podstatě stejným způsobem jako GET) , Takže jsme udělali EDDTableFromHttpZískejte práci s GET a POST. Velmi málo lidí (i málo programátorů počítačů) kdy pracoval s PUT a DELETE. PUT a DELETE jsou obecně podporovány pouze počítačovými jazyky, takže jejich použití vyžaduje zručný program. Takže PUT a DELETE jsou obvykle mnohem náročnější přístup vzhledem k tomu, jak se nástroje vyvinuly.  

HttpGet Notes

• Poznámky
• Ne. dataVariable může mít dataType=char. Místo toho použijte dataType=String. Pokud opravdu potřebujete dataType=char, email Chris. John at noaa.gov .  

Díky.

• Díky CHORDS za základní myšlenku.
  Základní myšlenka pro EDDTableFromHttpGet (tj. použití HTTP GET žádost o přidání údajů do souboru údajů) je z UCAR (NOR?) Cloudové datové služby v reálném čase (OZNAČENÍ) projekt. Formát parametrů v žádosti (opakovaná name=value , odděleno pomocí &) je stejný standardní formát, který používá HTML formuláře na webových stránkách. Je to jednoduchý a brilantní nápad a ještě více proto, že se tak dokonale prolíná s ERDDAP 's existujícím systémem pro zpracování tabulkových dat. Myšlenka je jasná, ale já (Bobe.) Nepřemýšlel jsem o tom. EDDTableFromHttp Získejte využití této základní myšlenky, v kombinaci s našimi představami o tom, jak ji implementovat, aby systém v ERDDAP™ pro nahrávání dat. Kromě základní myšlenky použití GET pro vkládání dat do systému je implementace EDDTableFromHttpGet zcela odlišná a zcela nezávislá na CHORDS a má různé vlastnosti (např. soubory záznamů, ukládání dat, jiný bezpečnostní systém, podpora CRUD, opakovatelná data) . Naše vystavení CHORDS byl jen webinar. Nedívali jsme se na jejich kód ani nečetli o jejich projektu, protože jsme okamžitě věděli, že chceme systém implementovat jiným způsobem. Ale jsme jim vděční za základní myšlenku. Plná zmínka o přípravku CHORDS je 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) . Cloud-hosted v reálném čase datové služby pro geovědy (OZNAČENÍ) software. UCAR/NCAR -- Laboratoř pozorování Země. https://doi.org/10.5065/d6v1236q
   

EDDTableFrom Hyrax Soubory

EDDTableFrom Hyrax Soubory (odprekovaný) agreguje datové soubory s několika proměnnými, každý s jednou nebo více sdílenými rozměry (například čas, výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) , a sloužil Hyrax OPeNDAP server .

• Tento datový soubor je ODCHYLKY . Nejnovější a obecnější řešení je použít cache Možnost FromUrl pro EDDTable FromFiles (nebo varianta) , který tvoří místní kopii vzdálených souborů a slouží data z místních souborů. The<cacheFromUrl> možnost lze použít s libovolným typem tabulkového datového souboru. **
  Jestli to z nějakého důvodu nezvládneš, napiš Chrisovi. John at noaa.gov . Pokud před rokem 2020 neexistují žádné stížnosti, může být tento typ datového souboru odstraněn. **
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.
• Ve většině případů má každý soubor více hodnot pro levý (první) rozměr, například čas.
• Soubory často (Ale nemusíš.) mají jedinou hodnotu pro ostatní rozměry (například výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) .
• Soubory mohou mít proměnné znaku s dodatečným rozměrem (například nCharacters) .
• Hyrax servery lze identifikovat pomocí "/dods-bin/nph-dods/" nebo "/opendap/" v URL.
• Tato třída obrazovka-scrapes Hyrax webové stránky se seznamy souborů v každém adresáři. Vzhledem k tomu, že je velmi specifický pro současný formát Hyrax webové stránky. Pokusíme se přizpůsobit. ERDDAP™ rychle pokud / pokud budoucí verze Hyrax změnit, jak jsou soubory uvedeny.
• The<fileDir> nastavení je ignorováno. Protože tato třída stáhne a vytvoří místní kopii každého vzdáleného datového souboru, ERDDAP™ nutí soubor Dir to be velkýRodič rodičů /kopie/ * datasetID * /.
• Pro< sourceUrl > použijte URL základního adresáře datového souboru v Hyrax například server, < sourceUrl >http://edac-dap.northerngulfinstitute.org/dods-bin/nph-dods/WCOS/nmsp/wcos/&lt;/ sourceUrl > (Ale dejte to na jednu čáru.) (Promiň, ale ten server už není k dispozici.) . The sourceUrl Webová stránka má obvykle " OPeNDAP Index serveru \[ název adresáře \] "nahoře.
• Vzhledem k tomu, že tato třída vždy stáhne a vytvoří místní kopii každého vzdáleného datového souboru, nikdy byste neměli zabalit tento soubor do EDDtableCopy .
• Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.
• Viz příklady 1D, 2D, 3D a 4D EDDTableFromNcFiles .  

EDDTableFromNeplatnéCRAFile

EDDTableFromNeplatnéCRAFile Údaje z agregátů NetCDF (V3 nebo v4) .nc soubory, které používají specifický, neplatný, varianta CF DSG Contiguous Ragged Array (CRA) Složky. I když ERDDAP™ podporuje tento typ souboru, je to neplatný typ souboru, který by nikdo neměl používat. Skupiny, které v současné době používají tento typ souboru, jsou důrazně vybízeny k používání ERDDAP™ generovat platné soubory CF DSG CRA a přestat používat tyto soubory.

Podrobnosti: Tyto soubory mají více proměnných řádků\_size, z nichž každá má atribut vzor\_dimension. Soubory jsou non-CF-standardní soubory, protože více vzorků (obs) rozměry musí být dekódovány a vzájemně spojeny s tímto doplňkovým pravidlem a slibem, který není součástí specifikace CF DSG: "Můžete spojovat danou např. hodnotu teploty (rozměr tempa\_obs) s danou hloubkou (z\_obs rozměr, rozměr s nejvíce hodnot) , protože: teplotní řádek\_velikost (pro danou sádru) bude buď 0 nebo rovno příslušnému řádku hloubky\_velikost (pro tyto obsazení) (To je pravidlo.) . Pokud tedy teplotní řádek\_velikost není 0, pak hodnoty n teploty pro tento odlitek se vztahují přímo k hodnotám n hloubky pro tento odlitek (To je slib.) .."

Další problém s těmito soubory: proměnná Principal\_Investigator row\_size nemá atribut vzor\_dimension a neřídí se výše uvedeným pravidlem.

Ukázky souborů pro tento typ souboru lze nalézt nahttps://data.nodc.noaa.gov/thredds/catalog/ncei/wod/ \[ 2020-10-21 Tento server již není spolehlivě dostupný \] .

Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.

Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

První věc GenerovatDatasets Xml dělá pro tento typ souboru dat poté, co odpovíte na otázky, je vytisknout strukturu ncdump-jako vzorku souboru. Takže pokud zadáte pár hloupých odpovědí pro první smyčku přes GenerateDatasets Xml, aspoň uvidíš, jestli ERDDAP™ může přečíst soubor a zjistit, jaké rozměry a proměnné jsou v souboru. Pak můžete dát lepší odpovědi pro druhou smyčku přes GenerateDatasetsXml.  

EDDTableFromJsoniCSVFiles

EDDTableFromJsoniCSVFiles Údaje z agregátů JSON Řádky CSV souborů . Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.

• Jak říká jsonlines.org, tento formát je "Lepší než CSV" (A legálně, jako federální zaměstnanec s nimi nemůžu souhlasit nebo nesouhlasit -- jak šílené to je?) . CSV nebyl nikdy formálně definován a je brzděn historickými zavazadly souvisejícími s jeho připojením k původním tabulkovým programům. JSON Lines CSV je ve srovnání s tím plně definován a těží z jeho připojení k široce používanému standardu JSON, který zase těží z jeho připojení k Java Skript a Java . Bohužel existuje plná podpora pro dlouhá celá čísla a pro Unicode znaky v řetězech, a jasný způsob, jak zahrnout další speciální znaky (Zejména karty a nové linky) v řetězech.

Tento formát je vhodný zejména pro datové soubory, kde potřebujete pravidelně přidávat další řádky na konec daného datového souboru. Z tohoto důvodu a další (viz výše) , EDDTableFromHttpGet používá soubory Json Lines CSV pro ukládání dat.

• Předpokládají se, že vstupní soubory jsou zakódovány UTF-8. Nicméně vzhledem k \ u dddd formát pro kódování zvláštních znaků (např. \u20ac je kódování znaku Euro) , Máte možnost napsat soubory tak, že obsahují pouze 7-bit ASCII znaky pomocí \u dddd zakódovat všechny znaky nad 127.  
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

První věc, kterou GenerateDatasetsXml dělá pro tento typ datového souboru poté, co odpovíte na otázky, je tisk ncdump-jako struktura výběrového souboru. Takže pokud zadáte pár hloupých odpovědí pro první smyčku přes GenerateDatasets Xml, aspoň uvidíš, jestli ERDDAP™ může přečíst soubor a zjistit, jaké rozměry a proměnné jsou v souboru. Pak můžete dát lepší odpovědi pro druhou smyčku přes GenerateDatasetsXml.

• UPOZORNĚNÍ: Kdy ERDDAP™ čte JSON Linky datové soubory CSV, pokud zjistí chybu na daném řádku (např. nesprávný počet položek) , zaznamenává varovný signál (Špatná linka (án) data" ... se seznamem špatných řádků na následujících řádcích) do log.txt soubor a dále čte zbytek datového souboru. Je tedy vaší povinností pravidelně se dívat (nebo k tomu napsat scénář) pro tuto zprávu v deníku. txt tak, že můžete opravit problémy v datových souborech. ERDDAP™ je nastaven tak, aby uživatelé mohli i nadále číst všechny dostupné platné údaje, i když některé řádky souboru mají nedostatky.  

EDDTablefromMultidimNcFiles

EDDTablefromMultidimNcFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc (nebo .nc ml ) soubory s několika proměnnými, každá s jednou nebo více sdílenými rozměry. Soubory mohou mít proměnné znaku s doplňkovým rozměrem nebo bez něj (například: STRING14) . Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.

• Pokud jsou soubory multidimenzionální CF DSG varianty, použijte tento typ souborů místo EDDTableFromNcCFFiles .  
• Pro nové tabulkové soubory dat z .nc soubory, použijte tuto volbu před pokusem o starší EDDTableFromNcFiles . Některé výhody této třídy jsou:
  • Tato třída může číst více proměnných z širší škály struktur souborů. Pokud zadáte rozměryCSV (čárkou oddělený seznam názvů rozměrů) ve generováníDatasets Xml (nebo<rozměryCSV> v datasets.xml informace pro jeden z těchto souborů údajů), pak ERDDAP™ budou číst pouze proměnné ve zdrojových souborech, které používají některé nebo všechny tyto rozměry, plus všechny skalární proměnné. Pokud je rozměr ve skupině, musíte zadat celé jméno, např. " groupName/dimensionName ".
  • Tato třída může často odmítnout soubory velmi rychle, pokud se neshodují s omezeními žádosti. Čtení dat z velkých sbírek tedy bude často mnohem rychlejší.
  • Tato třída zpracovává skutečné proměnné znaku (jiné proměnné než String) Správně.
  • Tato třída může zmenšit String proměnné, když tvůrce nepoužil Netcdf-java writeStrings (což znamená znak #0 označit konec řetězce) .
  • Tato třída je lepší při řešení jednotlivých souborů, které postrádají určité proměnné nebo rozměry.
  • Tato třída může odstranit bloky řádků s chybějícími hodnotami, jak je uvedeno pro CF Geometrie diskrétního odběru vzorků (DSG) Nekompletní multidimenzionální soubory Array
     
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

První věc, kterou GenerateDatasetsXml dělá pro tento typ datového souboru poté, co odpovíte na otázky, je tisk ncdump-jako struktura výběrového souboru. Takže pokud zadáte pár hloupých odpovědí pro první smyčku přes GenerateDatasets Xml, aspoň uvidíš, jestli ERDDAP™ může přečíst soubor a zjistit, jaké rozměry a proměnné jsou v souboru. Pak můžete dát lepší odpovědi pro druhou smyčku přes GenerateDatasetsXml.

Skupina... Generovat soubory dat Xml požádá o "Skupinu." Můžete zadat "" aby hledala všechny skupiny, " některé Skupina "nebo " některéGroup/nějakýSubGroup "prohledat určitou skupinu, nebo " \[ kořen \] "aby hledala jen kořenovou skupinu. Řetězec "Skupina" se stává<skupina > ve datasets.xml Informace pro soubor údajů (i když " \[ kořen \] "se stane") .

RozměryCSV -- GenerovatNastavení dat Xml požádá o "RozměryCSV" řetězec. Toto je seznam jmen zdrojových jmen sady rozměrů oddělených čárkou. Generovat soubory dat Xml bude číst pouze datové proměnné ve vzorku .nc soubory, které používají některé nebo všechny tyto rozměry (a žádné jiné rozměry) , plus všechny skalární proměnné v souboru, a vytvořit soubor z těchto datových proměnných. Pokud je rozměr ve skupině, musíte zadat celé jméno, např. " groupName/dimensionName ". Pokud nic nespecifikujete (prázdný řetězec) , GenerátorDatasets Xml bude hledat proměnné s nejvíce rozměry, na teorii, že budou nejzajímavější, ale tam mohou být časy, kdy budete chtít vytvořit soubor z některé jiné skupiny datových proměnných, které používají některé jiné skupiny rozměrů. Pokud zadáte název rozměru, který neexistuje (např. NO\_MATCH) , ERDDAP™ najde všechny skalární proměnné. Řetězec "RozměryCSV" se stává<rozměryCSV> v datasets.xml informace pro datový soubor.

léčbaRozměryAs

Je kategorie invalidů .nc soubory (Protože se neřídí pravidly CF) které mají více rozměrů (např. lat, lon, čas) kdy měli použít jen jeden rozměr (např. čas) , například:

    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 má speciální funkci pro řešení těchto souborů: pokud přidáte globální atribut "treatDimensionsAs" do souborů globální addAttributes , můžete říct ERDDAP™ k léčbě určitých rozměrů (např. lat a lat) jako by byly jiné dimenze (např. čas) . Hodnota atributu musí být čárkou oddělený seznam, který určuje "od" rozměrů a pak rozměr "do," např. jihoameričanky, chvilka, čas
Pak ERDDAP™ bude číst soubor, jako by byl:

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

Současná velikost každého z rozměrů v seznamu musí být samozřejmě stejná; ERDDAP™ bude soubor považovat za "špatný soubor."

Všimněte si, že tyto soubory jsou neplatné, protože se neřídí pravidly CF. Takže i když ERDDAP™ může číst, důrazně doporučujeme, abyste nevytvářeli soubory, jako je tato, protože ostatní softwarové nástroje založené na CF je nebudou moci správně přečíst. Pokud již tyto soubory máte, doporučujeme je co nejdříve nahradit platnými soubory.

EDDTableFromNcFiles

EDDTableFromNcFiles Údaje z agregátů NetCDF (V3 nebo v4) .nc (nebo .nc ml ) soubory a Zarr soubory (od verze 2.25) s několika proměnnými, každá s jedním společným rozměrem (například čas) nebo více než jeden společný rozměr (například čas, výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) . Soubory musí mít stejné názvy rozměrů. Zadaný soubor může mít pro každý rozměr více hodnot a hodnoty se mohou lišit v různých zdrojových souborech. Soubory mohou mít proměnné znaku s dodatečným rozměrem (například: STRING14) . Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.

Soubory Zarr mají mírně odlišné chování a vyžadují buď souborNameRegex nebo cestuRegex zahrnout "zarr."

• Pokud .nc Soubory používají jeden z CF Geometrie diskrétního odběru vzorků (DSG) formáty souborů, zkuste použít EDDTableFromNcCFFiles než zkusím tohle.  
• Pro nové tabulkové soubory dat z .nc soubory, zkuste novější EDDTablefromMultidimNcFiles Nejdřív.  
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

První věc, kterou GenerateDatasetsXml dělá pro tento typ datového souboru poté, co odpovíte na otázky, je tisk ncdump-jako struktura výběrového souboru. Takže pokud zadáte pár hloupých odpovědí pro první smyčku přes GenerateDatasets Xml, aspoň uvidíš, jestli ERDDAP™ může přečíst soubor a zjistit, jaké rozměry a proměnné jsou v souboru. Pak můžete dát lepší odpovědi pro druhou smyčku přes GenerateDatasetsXml.

RozměryCSV -- GenerovatNastavení dat Xml požádá o "RozměryCSV" řetězec. Toto je seznam jmen zdrojových jmen sady rozměrů oddělených čárkou. Generovat soubory dat Xml najde datové proměnné v .nc soubory, které používají některé nebo všechny tyto rozměry, plus všechny skalární proměnné, a aby data z těchto datových proměnných. Pokud nic nespecifikujete (prázdný řetězec) , GenerátorDatasets Xml bude hledat proměnné s nejvíce rozměry, na teorii, že budou nejzajímavější, ale tam mohou být časy, kdy budete chtít vytvořit soubor z některé jiné skupiny datových proměnných, které používají některé jiné skupiny rozměrů.

• 1D Příklad: 1D soubory jsou poněkud odlišné od 2D, 3D, 4D, ... souborů.
  • Možná máte sadu .nc datové soubory, kde každý soubor má měsíční hodnotu dat z jedné unášené bóje.
  • Každý soubor bude mít 1 rozměr, například čas (velikost = \[ mnoho \] ) .
  • Každý soubor bude mít jednu nebo více 1D proměnných, které používají tento rozměr, například čas, zeměpisná délka, zeměpisná šířka, teplota vzduchu, ....
  • Každý soubor může mít například 2D proměnné znaků s rozměry (Time,nCharacters) .  
• 2D příklad:
  • Možná máte sadu .nc datové soubory, kde každý soubor má měsíční hodnotu dat z jedné unášené bóje.
  • Každý soubor bude mít 2 rozměry, například čas (velikost = \[ mnoho \] ) a ID (velikost = 1) .
  • Každý soubor bude mít 2 1D proměnné se stejnými názvy jako rozměry a pomocí stejného rozměru jména, například čas (čas) , id (id) . Tyto 1D proměnné by měly být zařazeny do seznamu< dataVariable > je v XML souboru.
  • Každý soubor bude mít jednu nebo více 2D proměnných, například délku, šířku, teplotu vzduchu, teplotu vody, ...
  • Každý soubor může mít například proměnné 3D znaku s rozměry (Čas, id,nCharacters) .  
• 3D příklad:
  • Možná máte sadu .nc datové soubory, kde každý soubor má měsíční hodnotu dat z jedné stacionární bóje.
  • Každý soubor bude mít 3 rozměry, například čas (velikost = \[ mnoho \] ) , lat (velikost = 1) , av (velikost = 1) .
  • Každý soubor bude mít 3 1D proměnné se stejnými názvy jako rozměry a pomocí stejného rozměru jména, například čas (čas) , lat (lat) , (ní) . Tyto 1D proměnné by měly být zařazeny do seznamu< dataVariable > je v XML souboru.
  • Každý soubor bude mít jednu nebo více 3D proměnných, například teplotu vzduchu, teplotu vody, ...
  • Každý soubor může mít například 4D proměnné znaků s rozměry (Time,lat,lon,nCharakterers) .
  • Jméno souboru může mít jméno bóje uvnitř složky.  
• Příklad 4D:
  • Možná máte sadu .nc datové soubory, kde každý soubor má měsíční hodnotu dat z jedné stanice. V každém okamžiku, stanice bere údaje v sérii hlubin.
  • Každý soubor bude mít 4 rozměry, například čas (velikost = \[ mnoho \] ) , hloubka (velikost = \[ mnoho \] ) , lat (velikost = 1) , av (velikost = 1) .
  • Každý soubor bude mít 4 1D proměnné se stejnými názvy jako rozměry a pomocí stejného rozměru jména, například čas (čas) , hloubka (hloubka) , lat (lat) , (ní) . Tyto 1D proměnné by měly být zařazeny do seznamu< dataVariable > je v XML souboru.
  • Každý soubor bude mít jednu nebo více 4D proměnných, například teplotu vzduchu, teplotu vody, ...
  • Každý soubor může mít například 5D proměnné znaků s rozměry (čas, hloubka, la, la, la, characters) .
  • Jméno souboru může mít jméno bóje uvnitř složky.  

EDDTableFromNcCFFiles

EDDTableFromNcCFFiles Údaje o agregátech NetCDF (V3 nebo v4) .nc (nebo .nc ml ) soubory, které používají jeden ze formátů souborů uvedených v CF Geometrie diskrétního odběru vzorků (DSG) Konvence. Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.

Pro soubory používající jednu z multidimenzionálních CF DSG variant použijte EDDTablefromMultidimNcFiles Místo toho.

Konvence CF DSG definují desítky formátů souborů a zahrnují četné drobné varianty. Tato třída se zabývá všemi variacemi, o kterých víme, ale možná jsme jeden propásli. (nebo více) . Takže pokud tato třída nemůže číst data z vašich CF DSG souborů, prosím. požádat o dodatečnou podporu .

Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.  

EDDTableFromNccsvFiles

EDDTableFromNccsvFiles Údaje z agregátů NCCSV ASCII .csv soubory. Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.

• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.

První věc, kterou GenerateDatasetsXml dělá pro tento typ datového souboru poté, co odpovíte na otázky, je tisk ncdump-jako struktura výběrového souboru. Takže pokud zadáte pár hloupých odpovědí pro první smyčku přes GenerateDatasets Xml, aspoň uvidíš, jestli ERDDAP™ může přečíst soubor a zjistit, jaké rozměry a proměnné jsou v souboru. Pak můžete dát lepší odpovědi pro druhou smyčku přes GenerateDatasetsXml.

• UPOZORNĚNÍ: Kdy ERDDAP™ čte NCCSV datové soubory, pokud na daném řádku najde chybu (např. nesprávný počet položek) , zaznamenává varovný signál (Špatná linka (án) data" ... se seznamem špatných řádků na následujících řádcích) do log.txt soubor a dále čte zbytek datového souboru. Je tedy vaší povinností pravidelně se dívat (nebo k tomu napsat scénář) pro tuto zprávu v deníku. txt tak, že můžete opravit problémy v datových souborech. ERDDAP™ je nastaven tak, aby uživatelé mohli i nadále číst všechny dostupné platné údaje, i když některé řádky souboru mají nedostatky.  

EDDTableFromNOS

EDDTableFromNOS (ODCHYLKY) zpracovává údaje od NOAA NOS zdroj, který používá SOAP+XML pro žádosti a odpovědi. Je to velmi specifické pro NOAA XML. Viz vzorek EDDTableFromNOS v souborech dat2.xml.  

EDDTableFromOBIS

EDDTableFromOBIS zpracovává data z Ocean Biogeographic Information System (OBIS) server (bylhttp://www.iobis.org ) . Je možné, že již neexistují žádné aktivní servery, které tento zastaralý typ OBIS serveru používají.

• OBIS servery očekávají požadavek XML a vrací XML odpověď.
• Protože všechny OBIS servery slouží stejným způsobem. (bylhttp://iobis.org/tech/provider/questions) , Nemusíte specifikovat moc, aby nastavení OBIS data v ERDDAP .
• Musíte zahrnout " creator\_email " atribut v globální addAttributes Vzhledem k tomu, že se tato informace používá v rámci licence. Vhodná e-mailová adresa lze nalézt čtením XML odezvy ze zdrojeURL.
• Můžete, ale nemusíte být schopni získat globální atribut [< subsetVariables >] (#subsetvariables) pracovat s daným OBIS serverem. Pokud to zkusíte, zkuste jednu proměnnou. (například vědecký název nebo genus) .

EDDTableFromOBIS kostra XML

  <dataset type="EDDTableFromOBIS" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <sourceCode>...</sourceCode>
        <!-- If you read the XML response from the sourceUrl, the
        source code (for example, GHMP) is the value from one of the
        <resource><code> tags. -->
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <-- 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>
        <!-- 0 or 1 -->
      <addAttributes>...</addAttributes> <!-- 0 or 1. This MUST include
        "creator\_email" -->
  </dataset>

EDDTableFromParquetFiles

EDDTableFromParquetFiles zpracovává údaje od Parket . Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.

• Parket je navržen tak, aby komprimoval velmi efektivně, takže vám může dát menší velikost souborů než jiné formáty.
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.
• UPOZORNĚNÍ: Kdy ERDDAP™ čte datové soubory Parquet, pokud na daném řádku najde chybu (např. nesprávný počet položek) , zaznamenává varovný signál (Špatná linka (án) data" ... se seznamem špatných řádků na následujících řádcích) do log.txt soubor a dále čte zbytek datového souboru. Je tedy vaší povinností pravidelně se dívat (nebo k tomu napsat scénář) pro tuto zprávu v deníku. txt tak, že můžete opravit problémy v datových souborech. ERDDAP™ je nastaven tak, aby uživatelé mohli i nadále číst všechny dostupné platné údaje, i když některé řádky souboru mají nedostatky.  

EDDTableFrom SOS

**EDDTableFrom SOS ** zpracovává data ze služby sledování senzorů (SWE/ SOS ) server.

• Tento typ datového souboru agreguje údaje ze skupiny stanic, které jsou všechny obslouženy jednou SOS server.
• Všechny stanice slouží stejné sadě proměnných (i když zdroj pro každou stanici nemusí sloužit všem proměnným) .
• SOS servery očekávají požadavek XML a vrací XML odpověď.
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili. Není snadné vytvořit soubor XML pro SOS Údaje ručně. Chcete-li najít potřebné informace, musíte navštívit sourceUrl +"? služba= SOS & Žádost= GetCapabilities "v prohlížeči; podívejte se na XML; ručně vyžádejte GetObservation a podívejte se na XML odpověď na žádost.
• S příležitostným přidáním nových typů SOS servery a změny starých serverů, je stále těžší pro ERDDAP™ automaticky detekovat typ serveru z odpovědí serveru. Použití<sosServerType> (s hodnotou IOOS\_NDBC, IOOS\_NOS, OOSTethys , nebo KDO) je nyní STRONGLIE DOPORUČUJE. Pokud máte problémy s jakýmkoliv datovým souborem tohoto typu, zkuste znovu spustit GenerátorDatasets Xml pro SOS server. Generovat Datové soubory Xml vám umožní vyzkoušet různé<sosServerType> možnosti, dokud nenajdete tu správnou pro daný server.
• SOS přehled:
• SWE (Povolit web senzoru) a SOS (Služba sledování senzorů) jsou Standardy OpenGIS® . Tato webová stránka má standardní dokumenty.
• The OGC Webové služby Společné specifikace ver 1.1.0 ( OGC 06-121r3) pokrývá výstavbu dotazů GET a POST (viz bod 7.2.3 a bod 9) .
• Pokud jste poslat getKapacity xml žádost na SOS server ( sourceUrl +"?service= SOS & Žádost= GetCapabilities ") , dostanete xml výsledek se seznam stanic a pozorované Vlastnosti, které mají data.
• ObservedProperty je formální URI odkaz na vlastnost. Například urn:ogc:fenomén:longitude:wgs84 nebohttps://mmisw.org/ont/cf/parameter/sea\_water\_temperature
• Pozorovaná vlastnost není proměnná.
• Více než jedna proměnná může mít stejný pozorovaný Majetek (například uvnitřTempu a vně Teplota by mohla pozorovat oba Majetekhttps://mmisw.org/ont/cf/parameter/air\_temperature) .
• Pokud pošlete GetObservation xml žádost na SOS server, dostanete xml výsledek s popisy jmen polí v odpovědi, jednotky pole, a data. Název pole bude zahrnovat délku, zeměpisnou šířku, hloubku (Možná.) A čas.
• Každý dataVariable pro EDDTableFrom SOS musí obsahovat atribut "observedProperty," který identifikuje observedProperty, který musí být vyžádán ze serveru pro získání této proměnné. Často, několik dataVariable s bude vyjmenována stejná směs ObservedProperty.
• DataType pro každý dataVariable server nemusí být specifikován. Pokud ano, musíte se podívat na odpovědi XML dat ze serveru a přiřadit příslušné [<dataType>s] (#datatyp) v ERDDAP™ Soubor údajů dataVariable definice.
• (V době psaní) některé SOS servery reagují na GetObservation požadavky pro více než jeden pozorovaný Vlastnost tím, že jen vrací výsledky pro první z sledovanýchProperties. (Žádná chybová zpráva!) Viz požadavek parametru konstruktoru Sledoval jsem vlastnosti separátně.
• EDDTableFrom SOS automaticky přidává

  station\_id, longitude, latitude
  globální atributy datového souboru při vytváření datového souboru.

• SOS servery obvykle expresní jednotky s UCUM systém. Většina ERDDAP™ servery expresní jednotky s UDUNITS systém. Pokud potřebujete převést mezi oběma systémy, můžete použít ERDDAP 's webovou službou převést UCUM jednotky na / z UDUNITS .

EDDTableFrom SOS kostra XML

  <dataset type="EDDTableFromSOS" datasetID\="..." active\="..." >
      <sourceUrl>...</sourceUrl>
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <sosServerType>...</sosServerType> <!-- 0 or 1, but STRONGLY
        RECOMMENDED. This lets you specify the type of SOS server
        (so ERDDAP™ doesn't have to figure it out).
        Valid values are: IOOS\_NDBC, IOOS\_NOS, OOSTethys, and WHOI. -->
      <responseFormat>...</responseFormat> <!-- 0 or 1. Use this only if
        you need to override the default responseFormat for the
        specified sosServerType. -->
      <stationIdSourceName>...</stationIdSourceName> <!-- 0 or 1.
        Default="station\_id". -->
      <longitudeSourceName>...</longitudeSourceName>
      <latitudeSourceName>...</latitudeSourceName>
      <altitudeSourceName>...</altitudeSourceName>
      <altitudeSourceMinimum>...</altitudeSourceMinimum> <!-- 0 or 1 -->
      <altitudeSourceMaximum>...</altitudeSourceMaximum> <!-- 0 or 1 -->
      <altitudeMetersPerSourceUnit>...</altitudeMetersPerSourceUnit>
      <timeSourceName>...</timeSourceName>
      <timeSourceFormat>...</timeSourceFormat>
        <!-- timeSourceFormat MUST be either
        \* For numeric data: a UDUnits\-compatible string (with the format
          "units since baseTime") describing how to interpret
          source time values (for example,
          "seconds since 1970-01-01T00:00:00Z"), where the
          base time is an ISO 8601:2004(E) formatted date time
          string (yyyy-MM-dd'T'HH:mm:ssZ).
        \* For String date time data: specify
          units suitable for string times
          describing how to interpret string times (for example, the
          ISO8601TZ\_FORMAT "yyyy-MM-dd'T'HH:mm:ssZ"). -->
      <observationOfferingIdRegex>...</observationOfferingIdRegex>
        <!-- Only observationOfferings with IDs (usually the station names)
        which match this regular expression (tutorial) will be included
        in the dataset (".+" will catch all station names). -->
      <requestObservedPropertiesSeparately>true|false(default)
        </requestObservedPropertiesSeparately>
      <sourceNeedsExpandedFP\_EQ>true(default)|false</sourceNeedsExpandedFP\_EQ>
      <addAttributes>...</addAttributes> <!-- 0 or 1 -->
      <dataVariable>...</dataVariable> <!-- 1 or more.
        \* Each dataVariable MUST include the dataType tag.
        \* Each dataVariable MUST include the observedProperty attribute.
        \* For IOOS SOS servers, \every\ variable returned in the text/csv
          response MUST be included in this ERDDAP™ dataset definition. -->
  </dataset>

EDDTableFromThreddsFiles

EDDTableFromThreddsFiles (odprekovaný) agreguje datové soubory s několika proměnnými, každý s jednou nebo více sdílenými rozměry (například čas, výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) , a sloužil THREDDS OPeNDAP server .

• Tento datový soubor je ODCHYLKY . Nejnovější a obecnější řešení je použít cache Možnost FromUrl pro EDDTable FromFiles (nebo varianta) , který tvoří místní kopii vzdálených souborů a slouží data z místních souborů. The<cacheFromUrl> lze použít s libovolným typem tabulkového datového souboru z libovolného webového zdroje, který publikuje adresářový seznam souborů. **
  Jestli to z nějakého důvodu nezvládneš, napiš Chrisovi. John at noaa.gov . Pokud před rokem 2020 neexistují žádné stížnosti, může být tento typ datového souboru odstraněn. **
• Důrazně doporučujeme použít Generovat soubory dat Xml program vytvořit hrubý návrh datasets.xml kus pro tento datový soubor. Pak to můžete upravit tak, abyste to naladili.
• Ve většině případů má každý soubor více hodnot pro levý (první) rozměr, například čas.
• Soubory často (Ale nemusíš.) mají jedinou hodnotu pro ostatní rozměry (například výška (nebo hloubka) , zeměpisná šířka, zeměpisná délka) .
• Soubory mohou mít proměnné znaku s dodatečným rozměrem (například nCharacters) .
• Servery THREDDS lze v URL identifikovat pomocí "/thredds/." Například,

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

• Servery THREDDS mají katalogy na různých místech. Tato třída VYBAVÍ, že URL obsahuje "/thredds/catalog/." Tuto proměnnou můžete obvykle najít spuštěním v prohlížeči v kořenovém katalogu a poté kliknutím na požadovaný podkatalog.
• Tato třída čte katalog.xml soubory podávané THREDDS se seznamy<katalogRefs> (odkazy na další katalog.xml podsoubory) a<Databáze > (datové soubory) .
• The<fileDir> nastavení je ignorováno. Protože tato třída stáhne a vytvoří místní kopii každého vzdáleného datového souboru, ERDDAP™ nutí soubor Dir to be velkýRodič rodičů /kopie/ * datasetID * /.
• Pro< sourceUrl > použijte URL souboru catalog.xml pro soubor dat v THREDDS serveru, například: pro tuto URL, která může být použita ve webovém prohlížeči, https://data.nodc.noaa.gov/thredds/catalog/nmsp/wcos/catalog.html \[ 2020-10-21 Tento server již není spolehlivě dostupný. \] , podání< sourceUrl >https://data.nodc.noaa.gov/thredds/catalog/nmsp/wcos/catalog.xml&lt;/ sourceUrl > (Ale dejte to na jednu čáru.) .
• Vzhledem k tomu, že tato třída vždy stáhne a vytvoří místní kopii každého vzdáleného datového souboru, nikdy byste neměli zabalit tento soubor do EDDtableCopy .
• Tento typ datového souboru podporuje VOLITELNÝ, zřídka používaný speciální štítek,<SpecialMode> režim </specialMode>, které lze použít k určení, že by měla být použita speciální, hard-kódovaná pravidla k určení, které soubory by měly být staženy ze serveru. V současné době jediný platný režim je SAMOS, který se používá s datovými soubory zhttps://tds.coaps.fsu.edu/thredds/catalog/samosstáhnout pouze soubory s číslem poslední verze.
• Vidíš tuhle třídu? EDDTableFromFoles , informace o tom, jak tato třída funguje a jak ji používat.
• Viz příklady 1D, 2D, 3D a 4D EDDTableFromNcFiles .  

EDDTableFrom WFS Soubory

EDDTableFrom WFS Soubory (ODCHYLKY) vytvoří místní kopii všech údajů z ArcGIS MapServer WFS server, takže data pak mohou být rychle re-served ERDDAP™ uživatelé.

• Musíte zadat speciálně formátovaný sourceUrl globální atribut ERDDAP™ jak požádat o informace o funkcích ze serveru. Použijte tento příklad jako šablonu:

    <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>  

(ale dát to všechno na jeden řádek)

• Musíte přidat speciální globální atribut říct ERDDAP™ jak identifikovat názvy částí dat, které by měly být staženy. To bude pravděpodobně fungovat pro všechny EDDTableFrom WFS Soubory souborů:

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

• Vzhledem k tomu, že tato třída vždy stáhne a vytvoří místní kopii každého vzdáleného datového souboru, nikdy byste neměli zabalit tento soubor do EDDtableCopy .
• Vidíš tuhle třídu? EDDTableFromFoles , pro další informace o tom, jak tato třída funguje a jak ji používat.  

EDDTableAggregateRows

EDDTableAggregateRows může vytvořit soubor údajů EDDTable ze skupiny souborů "dítěte" EdDTable.

• Zde jsou některé použití pro EDDTableAggregateRows:
  • Mohli byste vytvořit soubor EDDTableAggregateRows ze dvou různých typů souborů nebo zdrojů dat, například soubor dat s daty až do konce posledního měsíce uložené v .nc CF soubory a datový soubor s daty za běžný měsíc uloženými v relační databázi.
  • Mohli byste vytvořit EDDTableAggregateRows soubor pro řešení změny zdrojových souborů (například změna časového formátu nebo změna názvu proměnné nebo data Typ/ scale\_factor / add\_offset změna) . V tomto případě by jedno dítě získalo data ze souborů provedených před změnou a druhé dítě by získalo data ze souborů provedených po změně. Toto použití EDDTableAggregateRows je alternativou k použití NcML nebo NCO . Pokud není v názvu souboru rozlišovací funkce (takže můžete použít<fileNameRegex> k určení, který soubor patří do jakého dětského souboru), budete pravděpodobně muset uložit soubory pro dva dětské soubory do různých adresářů.
  • Mohli byste vytvořit soubor EDDTableAggregateRows, který má sdílenou podmnožinu proměnných jedné nebo více podobných, ale různých souborů souborů, například soubor údajů, který vytváří soubor profilů z kombinace datového souboru profilu, datového souboru TimeSeriesProfile a datového souboru TrajectoryProfile (které mají některé různé proměnné a některé proměnné společné -- v tom případě budete muset vytvořit speciální varianty pro dětské soubory, s pouze in-common proměnné) .
  • Můžete mít několik samostatných souborů, každý se stejným typem dat, ale z jiné stanice. Mohli byste nechat tyto soubory nedotčené, ale také vytvořit soubor EDDTableAggregateRows, který má data ze všech stanic -- každý soubor údajů o dětech může být jednoduchý EDDTableFromErddap , který ukazuje na jeden ze stávajících datových souborů stanic. Pokud to uděláte, dejte každému z EDDTableFromErddap soubory jiné datasetID než původní samostatné datové soubory, např. přidáváním "Child" originálu datasetID .
• Každé dítě<Soubor údajů> musí být úplným datovým souborem, jako by se jednalo o samostatný datový soubor. Každý musí mít stejný. dataVariable án , ve stejném pořadí , se stejným destinationName án , údaje Typy , missing\_value án , \_FillValues a jednotky . Metadata pro každou proměnnou pro soubor EDDTableAggregateRows pocházejí z proměnných v prvním dětském souboru, ale EDDTableAggregateRows budou aktualizovat actual\_range Metadata mají být skutečným rozsahem pro všechny děti.
• Doporučení: Získat každý soubor údajů o dětech jako samostatné soubory údajů. Pak se pokuste vytvořit soubor EDDTableAggregateRows řezáním a lepením datasets.xml kus pro každého do nového EDDTableAggregate Soubor řádků.
• Nastavení dat Default Sort Order -- Pořadí dětských souborů stanoví celkový standard pořadí výsledků. Uživatelé samozřejmě mohou požádat o jiný druh objednávky pro daný soubor výsledků zadáním & orderBy (" čárka oddělený seznam proměnných ") až do konce jejich dotazu.
• Zdroj globální Atributy pro EDDTableAggregateRows jsou kombinované globální atributy z prvního dětského souboru. EDDTableAggregate Řádky mohou mít globální< addAttributes > poskytovat další globální atributy nebo přepsat zdrojové globální atributy.

EDDTableAggregate Řádky kostry XML

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

EDDtableCopy

EDDtableCopy může vytvořit místní kopii mnoha typů souborů údajů EDDTable a pak rychle re-serve dat z místní kopie.

• EDDtableCopy (a pro údaje o souřadnicích, EDDGrid Kopírovat ) je velmi snadné použití a velmi efektivní řešení některých největších problémů se službou dat ze vzdálených zdrojů dat:
  • Přístup k datům ze vzdáleného zdroje dat může být pomalý.
    • Mohou být pomalé, protože jsou neodmyslitelně pomalé (například neefektivní typ serveru) ,
    • protože jsou přemoženi příliš mnoha žádostmi,
    • nebo proto, že váš server nebo vzdálený server je omezen.
  • Vzdálený datový soubor je někdy nedostupný (znovu, z různých důvodů) .
  • Spoléhání na jeden zdroj pro data se neměří dobře (například, když mnoho uživatelů a mnoho ERDDAP Využijte ho.) .  
• Jak to funguje -- EdDtableCopy řeší tyto problémy automatickým vytvářením a udržováním místní kopie dat a podáváním dat z místní kopie. ERDDAP™ může sloužit data z místní kopie velmi, velmi rychle. A vytváření a používání místní kopie zmírňuje zátěž vzdáleného serveru. A místní kopie je záloha originálu, což je užitečné pro případ, že by se něco stalo s originálem.

Na vytvoření místní kopie souboru není nic nového. Co je tady nového je, že tato třída to dělá\*snadné\*vytvořit a\*udržovat\*místní kopie údajů z\*odrůda\*typů vzdálených zdrojů dat a\*přidat metadata\*při kopírování dat.

EDDtableCopy vs<cacheFromUrl>

<cacheFromUrl> je alternativou k EdDtableCopy. Pracují jinak.

• EDDTabulka Kopírování pracuje tím, že požaduje kousky dat ze vzdálené služby a ukládá tyto kousky do místních souborů. Proto je EDDTableCopy užitečné v některých případech, kdy jsou data dostupná prostřednictvím vzdálené služby.
• [<cacheFromUrl>] (#Cachefromurl) stáhne existující soubory uvedené na vzdálené webové stránce.<cacheFromUrl> je jednodušší použít a spolehlivější, protože snadno pozná, kdy existuje nový vzdálený datový soubor nebo kdy se změnil vzdálený datový soubor, a proto je třeba jej stáhnout.

Jsou-li situace, kdy EdDtableCopy nebo<cacheFromUrl> lze použít, použít<cacheFromUrl>, protože je jednodušší a spolehlivější.  

<extrahování Jméno>

EDDTabulka Kopírování vytváří místní kopii dat tím, že požaduje kousky dat ze vzdáleného datového souboru. EDDTabulka Kopírovat určuje, které kousky požádat o & distinct () hodnoty pro<extractDestinationNames> (uvedené v datasets.xml , viz níže) , které jsou názvy proměnných ve vzdáleném datovém souboru oddělené od místa. Například,

    <extractDestinationNames>drifter profile</extractDestinationNames>  

může generovat odlišné kombinace hodnot tuláku=tig17,profile=1017, tulák=tig17,profile=1095, ... tulák=une12,profile=1223, tulák=une12,profile=1251, ....

V situacích, kdy jeden sloupec (například profil) může být vše, co je nezbytné pro jedinečnou identifikaci skupiny řádků údajů, pokud existuje velmi velký počet například profilů, může být užitečné také uvést další výpis Země určení Název (například tulák) který slouží k rozdělení profilů. To vede k menšímu počtu datových souborů v daném adresáři, což může vést k rychlejšímu přístupu.

Místní soubory

Každý kus dat je uložen v samostatném NetCDF soubor v podadresáři velkýRodič rodičů /kopie/ * datasetID * / (jak je uvedeno v setup.xml ) . Existuje jedna podadresářská úroveň pro všechny kromě posledního výpisuDestinationName. Například data pro tig17+0117 by byla uložena v velkýRodič rodičů /kopie/vzorekDataset/tig17/1017 .nc . Například data une12+1251, budou uložena v velkýRodič rodičů /kopie/vzorekDataset/une12/1251 .nc . Adresář a názvy souborů vytvořené z hodnot dat jsou modifikovány tak, aby byly bezpečné (Například prostory se nahrazují slovy "x20") Tohle nemá vliv na skutečná data.  

Nová data

Pokaždé EDDTable Kopírování je znovu načteno, kontroluje vzdálený datový soubor, aby zjistil, jaké jednotlivé kusy jsou k dispozici. Pokud soubor pro kus dat již neexistuje, je do fronty přidán požadavek na získání kusu. ERDDAP 's úkolemThread zpracovává všechny ve frontě žádosti o kousky dat, jeden po druhém. Můžete vidět statistiky pro úkolThread činnost na Stavová stránka a v Denní zpráva . (Ano. ERDDAP™ by mohl přidělit více úkolů tomuto procesu, ale to by využít spoustu vzdáleného zdroje dat šířky pásma, paměti a času CPU, a mnoho místních ERDDAP 's šířkou pásma, pamětí a CPU časem, ani jeden z nich není dobrý nápad.)

POZNÁMKA: Úplně poprvé se načte EdDtableCopy, (Pokud vše půjde dobře) Do fronty úkolThread bude přidáno mnoho žádostí o kousky dat, ale nebudou vytvořeny žádné místní datové soubory. Takže konstruktér selže, ale úkolThread bude i nadále pracovat a vytvářet místní soubory. Pokud vše půjde dobře, úkolThread vytvoří místní datové soubory a další pokus o opětovné načtení datového souboru (za ~15 minut) bude úspěšný, ale zpočátku s velmi omezeným množstvím dat.

POZNÁMKA: Poté, co má místní datový soubor nějaká data a objeví se ve vašem ERDDAP , pokud je vzdálený datový soubor dočasně nebo trvale nepřístupný, bude místní datový soubor stále fungovat.

UPOZORNĚNÍ: Pokud je vzdálený datový soubor velký a/nebo je vzdálený server pomalý (To je ten problém, že?) , bude trvat dlouho, aby kompletní místní kopii. V některých případech bude potřebný čas nepřijatelný. Například přenos 1 TB dat přes řádek T1 (0, 15 GB/s) trvá nejméně 60 dní, za optimálních podmínek. Navíc využívá spoustu šířky pásma, paměti a času CPU na vzdálených a místních počítačích. Řešením je odeslání pevného disku správci vzdálené datové sady tak, aby mohl vytvořit kopii souboru dat a odeslat pevný disk zpět vám. Použijte tato data jako výchozí bod a EDDTableCopy k nim přidá data. (To je způsob, jak Amazon EC2 Cloud Service používá k řešení problému, i když jejich systém má hodně šířky pásma.)

POZOR: Pokud daná kombinace hodnot zmizí ze vzdáleného datového souboru, EdDtableCopy nevymaže lokální zkopírovaný soubor. Jestli chceš, můžeš to smazat sám.

TabulkaCopy<zkontrolovatSourceData>

The datasets.xml pro tento datový soubor může mít volitelnou značku

    <checkSourceData>true</checkSourceData>  

Výchozí hodnota je pravdivá. Pokud / když jej nastavíte na false, data nikdy nezkontrolují zdrojový soubor, aby zjistili, zda jsou k dispozici další data.  

Doporučené použití

1. Vytvořit<Databáze > položka (Nativní typ, nikoli EdDtableCopy) pro vzdálený zdroj dat. Udělejte to správně, včetně všech požadovaných metadat.
2. Pokud je to příliš pomalé, přidejte XML kód k zabalení do souboru EDDTableCopy.
   • Použít jiný datasetID (Možná změnou datasetID starých datasetID mírně) .
   • Kopírovat<přístupný To>,<reloadEveryNMinutes> a<onChange> od vzdáleného EDDTable XML až po XML EDDTableCopy. (Jejich hodnoty pro EDDTableCopy hmoty; jejich hodnoty pro vnitřní datový soubor se stávají nepodstatnými.)
   • Vytvořit<extractDestinationNames> tag (viz výše) .
   • <orderExtractBy> je OPTIVAL space oddělený seznam jmen cílových proměnných ve vzdáleném datovém souboru. Když se každý kus dat stáhne ze vzdáleného serveru, bude blok seřazen těmito proměnnými (první proměnnou, pak druhou proměnnou, pokud je první proměnná svázána, ...) . V některých případech ERDDAP™ bude moci extrahovat data rychleji z místních datových souborů, pokud první proměnná v seznamu je numerická proměnná ( "time" počítá jako numerická proměnná) . Ale vyberte tyto proměnné způsobem, který je vhodný pro datový soubor.
3. ERDDAP™ vytvoří a udržuje místní kopii údajů.  

• UPOZORNĚNÍ: EDDTableCopy předpokládá, že hodnoty dat pro každý kus se nikdy nemění. Pokud ano, musíte ručně smazat jednotlivé soubory v velkýRodič rodičů /kopie/ * datasetID * / která se změnila a vlajka soubor údajů, který má být znovu načten, aby byly smazané kusy nahrazeny. Pokud máte e-mailové předplatné datového souboru, dostanete dva e-maily: jeden, když soubor dat poprvé načte a začne kopírovat data, a další, když se soubor dat znovu načte (automaticky) a detekuje nové místní datové soubory.  
• Změnit metadata -- Pokud potřebujete změnit některý addAttributes nebo změnit pořadí proměnných spojených se zdrojovým datovým souborem:
  1. Změňte addAttributes pro zdrojový soubor dat v datasets.xml , podle potřeby.
  2. Smazat jeden z kopírovaných souborů.
  3. Nastavit vlajka okamžitě načíst soubor údajů. Pokud použijete vlajku a máte e-mailové předplatné datového souboru, dostanete dva e-maily: jeden, když soubor dat poprvé znovu načte a začne kopírovat data, a druhý, když se soubor dat znovu načte (automaticky) a detekuje nové místní datové soubory.
  4. Smazaný soubor bude regenerován s novými metadaty. Pokud zdrojový soubor není k dispozici, databázový soubor EDDTableCopy získá metadata z regenerovaného souboru, protože je to nejmladší soubor.  
• EDDGrid Kopírovat je velmi podobný EdDtableCopy, ale pracuje s roštovými soubory dat.

EDDtableCopy kostra XML

  <dataset type="EDDTableCopy" datasetID\="..." active\="..." >
      <accessibleTo>...</accessibleTo> <!-- 0 or 1 -->
      <graphsAccessibleTo>auto|public</graphsAccessibleTo> <!-- 0 or 1 -->
      <accessibleViaFiles>true|false(default)</accessibleViaFiles>
        <!-- 0 or 1 -->
      <reloadEveryNMinutes>...</reloadEveryNMinutes> <!-- 0 or 1 -->
      <defaultDataQuery>...</defaultDataQuery> <!-- 0 or 1 -->
      <defaultGraphQuery>...</defaultGraphQuery> <!-- 0 or 1 -->
      <addVariablesWhere>...</addVariablesWhere> <!-- 0 or 1 -->
      <fgdcFile>...</fgdcFile> <!-- 0 or 1 -->
      <iso19115File>...</iso19115File> <!-- 0 or 1 -->
      <onChange>...</onChange> <!-- 0 or more -->
      <extractDestinationNames>...</extractDestinationNames> <!-- 1 -->
      <orderExtractBy>...</orderExtractBy> <!-- 0 or 1 -->
      <fileTableInMemory>...</fileTableInMemory> <!-- 0 or 1 (true or false
        (the default)) -->
      <checkSourceData>...</checkSourceData> <!-- 0 or 1 -->
      <dataset>...</dataset> <!-- 1 -->
  </dataset>

---

Podrobnosti

Zde jsou podrobné popisy běžných značek a atributů.

<úhlovýRozhodněUnits>

• [ ** <angulaDegreeUnits> ** ] (#angulární jednotky) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml který obsahuje čárku oddělený seznam jednotek řetězců, které ERDDAP™ by se mělo zacházet jako s jednotkami úhlových stupňů. Pokud má proměnná jednu z těchto jednotek, tabledap 's orderByMean filtr vypočítá průměr zvláštním způsobem, pak uvede průměr jako hodnotu od -180 do 180. Viz ERDDAP 's ED Static.java zdrojový kód soubor pro aktuální výchozí seznam. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .

<úhlováSouhlasíPravdaUnits>

• [ ** <úhel DegreeTrueUnits> ** ] (#angulargree true units) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml který obsahuje čárku oddělený seznam jednotek řetězců, které ERDDAP™ Měli bychom se chovat jako úhlové stupně. Pokud má proměnná jednu z těchto jednotek, tabledap 's orderByMean filtr vypočítá průměr zvláštním způsobem, pak uvede průměr jako hodnotu od 0 do 360. Viz ERDDAP 's ED Static.java zdrojový soubor pro aktuální výchozí seznam. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .  

<Obecný standardJména>

• [ ** <Obecný standardJména> ** ] (#commonstandardnames) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml pro upřesnění čárky oddělené seznamu společného Standardní názvy CF . např.

    <commonStandardNames>air\\_pressure, ..., wind\\_to\\_direction</commonStandardNames>  

Tento seznam se používá v DataProviderForm3.html jako komfort pro uživatele. Pokud chcete tyto informace poskytnout datasets.xml , začít kopírováním aktuálního výchozího seznamu v<DEFAULT\_commonStandardNames > v ERDDAP 's \[ tomcat \] /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util/messages.xml file.  

<cacheMinutes>

• [ ** <cacheMinutes> ** ] (#cachemintes) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml určit věk (v minutách) na kterém souboru v cache by měly být vymazány (default=60) . např.

    <cacheMinutes>60</cacheMinutes>  

Obecně platí, že pouze obrazové soubory (Protože stejné obrázky jsou často žádány opakovaně) a .nc soubory (protože musí být plně vytvořeny před odesláním uživateli) jsou utajené. I když by to mohlo vypadat, že daná žádost by měla vždy vrátit stejnou odpověď, to není pravda. Například: tabledap žádost, která zahrnuje čas> některé Čas změní se, jakmile pro datový soubor dorazí nové údaje. A požadavek Griddap, který zahrnuje \[ poslední \] pro časový rozměr se změní, jakmile pro datový soubor přijdou nová data. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . Před ERDDAP™ v2.00, to bylo uvedeno v nastavení.xml, který je stále povoleno, ale odrazen.

<cachearMinutes>

• [ ** <cacheClearMinutes> ** ] (#cacheclearminutes) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml zadat frekvenci pro kontrolu cached souborů a odstranit staré (v minutách) (výchozí=15) . např.

    <cacheClearMinutes>15</cacheClearMinutes>  

Když server dokončí zpracování požadavku, bude kontrolovat, jak dlouho byla poslední cache čistá. Pokud to bylo příliš dávno, bude fronta na úkolThread vymazat cache. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . To může být specifikováno v setup.xml, ale to je odrazeno.  

<ConvertI TálibánuRequestCSVexample>

• [ ** <ConvertI TálibánuRequestCSVexample> ** ] (#Konverti Tipolaterequestcsvexample) je VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml \[ Začneme s ERDDAP™ v2.10 \] který obsahuje příklad, který bude uveden na webové stránce Interpolate převodníku. Výchozí hodnota je: jplMU RSS T41/analyzovaný\_ sst /Bilineární/4 .

<ConvertI TipolateDatasetIDVariableList>

• [ ** <ConvertI TipolateDatasetIDVariableList> ** ] (#Konverti Tipolatedatasetidvariablelist) je VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml \[ Začneme s ERDDAP™ v2.10 \] který obsahuje seznam CSV datasetID /proměnná Příklady jmen, které budou použity jako návrhy webové stránky Interpolate převodníku. Výchozí hodnota je: jplMU RSS T41/analyzovaný\_ sst .

<convertToPublicSourceUrl>

• [ ** <convertToPublicSourceUrl> ** ] (# Konvertovat na veřejné zdrojeurl) je VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml který obsahuje "od" a "do" atribut, který určuje, jak převést odpovídající místní sourceUrl (obvykle IP číslo) do veřejnosti sourceUrl (název domény) . "z" musí mít formu " \[ něco \] // \[ něco \] /." Může jich být 0 nebo více. Více informací viz [< sourceUrl >] (#sourcerl) . Například,

    <convertToPublicSourceUrl from="https://192.168.31.18/" to="https://oceanwatch.pfeg.noaa.gov/" />  

způsobí odpovídající místní sourceUrl (např.https://192.168.31.18/thredds/dodsC/satellite/BA/ssta/5day)
do veřejnosti sourceUrl (https://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/BA/ssta/5day) . Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .

Ale z bezpečnostních důvodů a důvodů spojených se systémem předplatného, Nepoužívej tenhle pytel!
Místo toho vždy použijte název veřejné domény v< sourceUrl > označení a použití Tabulka /etc/hosté na vašem serveru převést místní doménová jména na IP čísla bez použití DNS serveru. Můžete testovat, zda je název domény správně převeden na IP číslo pomocí: ping Někteří. Doména. jméno
 

údaje:obraz/png;base64,

• Pokud uživatel požaduje .htmlTable odpověď od ERDDAP™ , pokud data v buňce String obsahují data:obraz/png;base64, následovaná base64 zakódovaným .png obrazem, ERDDAP™ zobrazí ikonu (takže uživatel může vidět obrázek, pokud nad ním vznáší) a tlačítka pro uložení textu nebo obrázku do schránky. Tato funkce byla přidána v ERDDAP™ v2.19 od Marca Alby.

drawLandMask

• ** drawLandMask ** určuje výchozí nastavení, které kontroluje kdy a jak má být peněženka kreslena ERDDAP™ Nakreslí mapu. To může být uvedeno na třech různých místech v datasets.xml (uvedené od nejnižší do nejvyšší priority) :

1. Pokud drawLandMask je uvedeno uvnitř<erddapDatasets> (není spojena s žádným konkrétním datovým souborem) , pak určuje výchozí hodnotu drawLandMask pro všechny proměnné ve všech datových souborech. Například,

    <drawLandMask>under</drawLandMask>  

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP čte datasets.xml . Pokud tato značka není přítomna, výchozí hodnota je nižší.   2. Pokud drawLandMask je určen jako globální atribut daného datového souboru, pak určuje výchozí hodnotu drawLandMask u všech proměnných v tomto datovém souboru převažuje jakékoli nastavení nižší priority. Například,

    <att name="drawLandMask">under</att>  

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ Nabije ten soubor.   3. Pokud drawLandMask je zadán jako atribut proměnné v daném datovém souboru, pak určuje výchozí hodnotu drawLandMask pro tuto proměnnou v tomto datovém souboru převažuje jakékoli nižší prioritní nastavení. Například,

    <att name="drawLandMask">under</att>  

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ Nabije ten soubor.

Uživatel může přepsat výchozí hodnotu (kde je uvedeno) výběrem hodnoty pro "Draw land mask" ze seznamu dropdown na webové stránce souboru Make A Graph, nebo zahrnutím &.land= hodnota v URL, která požaduje mapu z ERDDAP .

Ve všech situacích jsou pro atribut 4 možné hodnoty:

• "Pod" kreslí pevninu dřív, než nakreslí data na mapě. U mřížkovaných souborů se půda jeví jako konstantní světle šedá barva. U tabulkových souborů "pod" zobrazuje data topografie nad zemí a oceány.
• "přes" -- U roštových souborů "přes" čerpá pevnina poté, co nakreslí data o mapách, aby zamaskovala všechna data nad zemí. U tabulkových souborů ukazuje "přes" batymetrii oceánu a konstantní světle šedou, kde je půda, oba vykreslené pod údaji.
• "outline" kreslí obrys pevniny, politických hranic, jezer a řek.
• "vypnout" nic nenakreslí.

<emailDiagnostikaToErdData>

• [ ** <emailDiagnostikaToErdData> ** ] (#emaildiagnosticstoerddata) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml . Hodnota značky může být pravdivá (výchozí) nebo falešně. Pokud je to pravda, ERDDAP™ Pošlete zprávu Chrisovi. John v Noaa. gov (vá ERDDAP™ vývojový tým) . To by mělo být bezpečné a bezpečné, protože žádné důvěrné informace (např. žádostUrl) je součástí e-mailu. To by mělo umožnit chytit všechny obskurní, zcela neočekávané chyby, které vedou k NullPointerExceptions. V opačném případě uživatel vidí výjimky, ale ERDDAP™ Vývojový tým ne. (takže nevíme, jestli je tu nějaký problém, který je třeba napravit.) .  

<grafBackgroundColor>

• [ ** <graphBackgroundColor> ** ] (#grafbackgroundcolor) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml zadat výchozí barvu pozadí na grafech. To ovlivňuje téměř všechny grafy. Existuje několik situací, které nebyly ovlivněny. Barva je specifikována jako osmimístný hexadecimální hodnota ve formě 0xAARRGGBB, kde AA, RR, GG a BB jsou opacity, červené, zelené a modré složky. "0x" je případ citlivý, ale hexadecimální číslice nejsou citlivé. Například zcela neprůhledná (ff) zelená modrá barva s červenou=22, zelená=88, modrá=ee by byla 0xff2288e. Neprůhledná bílá je 0xffffffffffff. Výchozí je neprůhledná světle modrá (0xffffccff) , která má tu výhodu, že se liší od bílé, což je důležitá barva v mnoha paletách používaných k kreslení dat. Například,

  <graphBackgroundColor>0xffffffff</graphBackgroundColor>  

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .

<ipAddressMaxRequests>

• [ ** <ipAddressMaxRequests> ** ] (#ipaddressmax requests) je zřídka používaná volitelná značka (První podporovaná ERDDAP™ v2. 12) v rámci<erddapDatasets> tag in datasets.xml který je součástí systému, který omezuje schopnost příliš agresivních oprávněných uživatelů a škodlivých uživatelů podávat velký počet simultánních žádostí, které by degradovaly výkon systému pro ostatní uživatele. ipAdresa MaxRequests určuje maximální počet simultánních žádostí, které budou přijaty z jakékoli konkrétní IP adresy. Další žádosti obdrží HTTP 429 chyba: Příliš mnoho požadavků. Malé, statické soubory v erddap/download/ a erddap/images/ nejsou z tohoto počtu vyloučeny. Výchozí hodnota je 15. Maximálně 1000, což je šíleně vysoko -- nedělejte to! ERDDAP™ Nepřijme číslo menší než 6, protože mnoho oprávněných uživatelů (zejména webové prohlížeče a WMS klienti) vyplňte až 6 žádostí najednou. The ERDDAP™ Daily Report a podobné informace napsané do log.txt souboru s každým Major Dataset Reload, budou nyní obsahovat přehled požadavků těchto IP adres pod názvem "Requester's IP Address (Příliš mnoho žádostí) ". Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .

"Major LoadDatasets Time Series" sekce status.html obsahuje sloupec "TooMany," který uvádí počet žádostí, které přesahují nastavení ipAddressMaxRequests uživatele a tak viděl chybu "Too Many Requests." To vám umožní snadno vidět, když jsou aktivní příliš agresivní legitimní uživatelé a škodlivé uživatele, takže můžete (volitelně) podívejte se do log.txt souboru a rozhodněte se, zda chcete tyto uživatele na černou listinu.

Není nic konkrétně špatného na tom, nastavit to na vyšší číslo. Je to na tobě. Ale to umožňuje/povzbuzuje lidi, aby nastavili systémy, které používají velké množství vláken k práci na projektech a pak jim nedává žádnou zpětnou vazbu, že to, co dělají, jim nepřináší žádnou výhodu.

<ipAddressMaxRequestsActive>

• [ ** <ipAddressMaxRequestsActive> ** ] (#ipaddressmax requestsactive) je zřídka používaná volitelná značka (První podporovaná ERDDAP™ v2. 12) v rámci<erddapDatasets> tag in datasets.xml který je součástí systému, který omezuje schopnost příliš agresivních oprávněných uživatelů a škodlivých uživatelů podávat velký počet simultánních žádostí, které by degradovaly výkon systému pro ostatní uživatele. ipAddressMaxRequestsActive určuje maximální počet simultánních žádostí, které budou aktivně zpracovávány z jakékoli konkrétní IP adresy. Další žádosti budou sedět ve frontě, dokud nebudou vyřízeny předchozí žádosti. Malé, statické soubory v erddap/download/ a erddap/images/ jsou z tohoto počtu a souvisejícího throtlingu vyňaty. Výchozí hodnota je 2. Maximální povoleno je 100, což je šíleně vysoko -- nedělejte to! Můžete to nastavit na 1 být striktní, zejména pokud máte problémy s příliš agresivní nebo zlomyslné uživatele. Uživatelé budou stále rychle získat všechna data, která požadují (až ipAddressMaxRequests) Ale nebudou schopni využít systémové zdroje. Nedoporučujeme to nastavit na větší číslo, protože umožňuje příliš agresivní legitimní uživatele a škodlivé uživatele dominovat ERDDAP 's kapacitou zpracování. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .  

<ipAddressUnlimited>

• [ ** <ipAddressUnlimited> ** ] (#ipadadressunlimited) je zřídka používaná volitelná značka (První podporovaná ERDDAP™ v2. 12) v rámci<erddapDatasets> tag in datasets.xml který je součástí systému, který omezuje schopnost příliš agresivních oprávněných uživatelů a škodlivých uživatelů podávat velký počet simultánních žádostí, které by degradovaly výkon systému pro ostatní uživatele. ipAddressUnlimited je čárka-oddělený seznam IP adres, které chcete povolit neomezený přístup k vašemu ERDDAP . Podívej se do svého deníku. txt soubor zjistit, který formát váš server používá pro IP adresy. Na některých serverech budou IP adresy ve formátu #.#.#.# (kde # je celé číslo od 0 do 255) ; zatímco na ostatních to bude ve formátu #:#:#:#:#:#:#:#:#:#:# . Žádající na tomto seznamu nepodléhají ani ipAddressMaxRequests, ani ipAddressMaxRequestsActive nastavení. Tohle by mohlo být sekundární. ERDDAP™ nebo pro některé uživatele nebo servery ve vašem systému. ERDDAP™ vždy přidá " (neznámáNPPadresa) " ERDDAP™ používá, když není možné určit IP adresu requesteru, např. pro jiné procesy běžící na stejném serveru. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .

Pokud z nějakého důvodu všechny žádosti uživatele dostanou chybovou zprávu "Timeout čeká na vaše další požadavky na zpracování." pak můžete problém vyřešit přidáním IP adresy uživatele do ipAddressUnlimited list, aplikace této změny, pak odstranit z tohoto seznamu.

<loadDatasetsMinMinutes>

• [ ** <loadDatasetsMinMinutes> ** ] (#loaddatasetsminminutes) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml stanovit minimální čas (v minutách) mezi hlavním zatížením Datové soubory (kdy ERDDAP™ reprocesy datasets.xml , včetně kontroly každého datového souboru, zda je třeba jej znovu načíst podle jeho opětovného načtení Nastavení everyNMinutes, default=15) . např.

    <loadDatasetsMinMinutes>15</loadDatasetsMinMinutes>  

Pokud daný průběh zatíženíDatasets trvá méně než tentokrát, nakladač se jen opakovaně dívá do adresáře vlajky a/nebo spí, dokud neuplyne zbývající čas. Výchozí hodnota je 15 minut, což by mělo stačit téměř všem. Jediná nevýhoda nastavení tohoto na menší počet je, že zvýší frekvenci, že ERDDAP™ retruje soubory, které mají chyby, které jim brání v načtení (např. nefunguje vzdálený server) . Pokud je takových souborů mnoho a jsou často přezkoušeny, zdroj údajů by mohl považovat za otravné/agresivní chování. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . Před ERDDAP™ v2.00, to bylo uvedeno v nastavení.xml, který je stále povoleno, ale odrazen.  

<loadDatasetsMaxMinutes>

• [ ** <loadDatasetsMaxMinutes> ** ] (#loaddatasetsmaxminutes) je VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml stanovit maximální čas (v minutách) hlavní zátěž Snaha datových souborů je povolena (před zatížením Datové sady nitě považované za "nainstalované" a jsou přerušeny) (default=60) . např.

    <loadDatasetsMaxMinutes>60</loadDatasetsMaxMinutes>  

Obecně by to mělo být nastaveno nejméně dvakrát tak dlouho, pokud si rozumně myslíte, že přehrávání všech souborů dat (kumulativně) měl by brát (protože počítače a sítě jsou někdy pomalejší, než se očekávalo) To by mělo být vždy mnohem delší než načítáníDatasetsMinMinutes. Výchozí hodnota je 60 minut. Někteří lidé to nastaví na delší dobu. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . Před ERDDAP™ v2.00, to bylo uvedeno v nastavení.xml, který je stále povoleno, ale odrazen.  

<LogLevel>

• [ ** <logLevel > ** ] (#loglevel) je VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml určit, kolik diagnostických zpráv je odesláno do souboru log.txt. Může být nastaveno na "varování" (Nejmenší zprávy) , "info" (výchozí) , nebo "všechny" (nejvíce zpráv) . např.

    <logLevel>info</logLevel>  

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . Před ERDDAP™ v2.00, to bylo uvedeno v nastavení.xml, který je stále povoleno, ale odrazen.  

<částečný požadavekMaxBytes> a<Částečná žádostMaxCells>

• [ ** <partitionalRequestMaxBytes > ] (#částečněpožadavekmaxbytes-a-částečněpožadavekmaxbuňky) a [ <partitionalRequestMaxCells> ** ] (#částečněpožadavekmaxbytes-a-částečněpožadavekmaxbuňky) jsou vzácně používány VOLITELNÉ tagy v rámci<erddapDatasets> tag in datasets.xml . Pokud je to možné (A není to vždy možné.) , ERDDAP™ rozbíjí velké požadavky na data do kousků pro zachování paměti.

S 32 bity Java , v zjednodušeném smyslu, maximální počet současně velký požadavky jsou zhruba 3/4 dostupné paměti (hodnota -Xmx přenesena na Tomcat) děleno velikostí kusu (např. 1200 MB / 100 MB => 12 žádostí) . Jiné věci vyžadují paměť, takže skutečný počet žádostí bude menší. V praxi to není vždy možné. Takže jedna obrovská nebo několik velmi velkých simultánně nenáročných žádostí může způsobit problémy 32 bitů. Java .

Se 64 bity Java , hodnota -Xmx může být mnohem větší. Takže paměť je mnohem méně pravděpodobná jako omezení.

Můžete přepsat výchozí velikost bloku definováním těchto značek v datasets.xml (s různými hodnotami, než je zde uvedeno) : U sítí:<ČástRequestMaxBytes>100000000</částečněRequestMaxBytes > Pro tabulky:<parciálníRequestMaxCells>1000000</částečněRequestMaxCells >

particiousRequestMaxBytes je preferovaný maximální počet bytů pro žádost o dílčí údaje sítě (část celkové žádosti) . default=100000000 (10^8) . Větší velikosti nejsou nutně lepší. (a nejezdi nad 500 MB, protože to je výchozí limit THREDDS pro DAP odpovědi) . Ale větší velikosti mohou vyžadovat méně přístupu tun souborů (myslet na ERD 's satelitními daty s každým časovým bodem v samostatném souboru - je lepší získat více dat z každého souboru v každé částečné žádosti) .

parciálníRequestMaxCells je preferovaný maximální počet buněk (nRows \* nColumns v tabulce dat) pro žádost o dílčí údaje TABLE (část celkové žádosti) . Výchozí = 100000. Větší velikosti nejsou nutně lepší. Výsledkem je delší čekání na počáteční dávku dat ze zdroje.

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . Před ERDDAP™ v2.00, tyto byly specifikovány v nastavení.xml, který je stále povoleno, ale odrazen.  

<ŽádostBlacklist>

• [ ** <requestBlacklist> ** ] (#Request blacklist) je VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml který obsahuje čárku oddělený seznam číselných IP adres, které budou na černé listině. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .
  • To lze použít k odvrácení Popírání služebního útoku , příliš horlivý web robot , nebo jakýkoli jiný typ problémového uživatele.
  • Potížistka... Pokud ERDDAP™ zpomalí na plazí nebo zamrzne / zastaví, příčinou je často problémový uživatel, který běží více než jeden skript najednou a / nebo dělá velký počet velmi velké, extrémně neefektivní, nebo neplatné žádosti, nebo současné žádosti. Podívejte se dovnitř. log.txt zjistit, zda tomu tak je, a najít numerickou IP adresu problematického uživatele. Jestli je tohle ten problém, měl bys toho uživatele asi vymazat.

Kdy? ERDDAP™ dostane žádost z blacklisted IP adresy, vrátí HTTP Chyba 403: Zakázané. Doprovodná textová chybová zpráva podporuje uživatele, aby vám e-mail, ERDDAP Správce, aby vyřešil problémy. Pokud chtějí čas na čtení chybové zprávy (Mnozí zřejmě ne.) a kontaktovat vás, pak můžete pracovat s nimi, aby spustit jen jeden skript najednou, dělat účinnější požadavky, opravit problémy ve svém scénáři (například požadavek na údaje ze vzdáleného datového souboru, který nemůže odpovědět před načasováním) Nebo cokoliv jiného bylo zdrojem problémů.

Uživatelé si často prostě neuvědomují, že jejich požadavky jsou nepříjemné. Často si neuvědomují chyby, hrubé nedostatky nebo jiné problémy se svými scénáři. Často si to myslí, protože ERDDAP™ nabízí data zdarma, že mohou požadovat tolik dat, kolik chtějí, např. spuštěním více skriptů nebo pomocí více vláken současně.

• Můžete jim vysvětlit, že každý ERDDAP™ , Nyní záleží na tom, jak velký a silný, má konečné zdroje (CPU čas, pevný disk I/O, síťová šířka pásma, atd.) a není fér, pokud jeden uživatel požaduje data způsobem, který vytěsní ostatní uživatele nebo přetížení ERDDAP .
• Jakmile uživatel ví, jak podat 2 simultánní žádosti, často nevidí žádný důvod, proč nevyužít 5, 10 nebo 20 simultánní žádosti, protože dodatečné žádosti je nic nestojí. Je to jako asymetrická válka: zde mají útočné zbraně obrovskou výhodu (nulové náklady) přes obranné zbraně (konečná instalace se skutečnými náklady) .
• Upozorňujeme na ně, že dochází ke snížení výnosů k podávání stále více a více simultánních žádostí; dodatečné žádosti jen dále blokují požadavky jiných uživatelů; nevytvářejí pro ně obrovské zlepšení.
• Připomeň jim, že jsou i jiní uživatelé (jak příležitostní uživatelé, tak i jiní uživatelé běžící skripty) , takže to není fér od nich, aby všechny ERDDAP Zdroje.
• Poukaz na to, že techničtí obři přiměli uživatele, aby od webových služeb očekávali nekonečné zdroje. Zatímco existují způsoby, jak to nastavit mřížky/klastry/federace ERDDAP án k vytvoření ERDDAP™ systém s více zdroji, většina ERDDAP™ Správci nemají peníze ani lidi, kteří by takové systémy nastavili, a takový systém bude stále konečný. V ERD Například, je tu jedna osoba. (Já.) psaní ERDDAP™ , podávání dvou ERDDAP án (s pomocí mého šéfa) , a řízení několika zdrojů dat, vše s ročním hardwarovým rozpočtem ve výši 0 dolarů (spoléháme na příležitostné granty na zaplacení hardwaru) . To není Google, Facebook, Amazon, atd. se 100's inženýrů, a miliony dolarů příjmů recyklovat do stále větších systémů. A nemůžeme jen tak hýbat ERDDAP™ například Amazon AWS, protože náklady na ukládání dat jsou velké a poplatky za výstup dat jsou velké a variabilní, zatímco náš rozpočet na externí služby je fixní 0 dolarů.
• Mým požadavkem pro uživatele je: pro non-time-citlivé žádosti (což je zdaleka nejčastější případ) Jejich systém by měl podat jednu žádost najednou. Pokud jsou žádosti časově citlivé (např. více .pngs na webové stránce, více dlaždic pro WMS klient atd.) , pak možná 4 simultánní žádosti by měly být max (a jen na krátkou dobu) .
• Pokud vysvětlíte situaci uživateli, většina uživatelů pochopí a bude ochotna provést nezbytné změny, abyste mohli odstranit jejich IP adresu z černé listiny.  
• Pro blacklist uživatele přidejte jejich numerickou IP adresu do čárkového seznamu IP adres v<requestBlacklist> ve vašem datasets.xml Složka. Chcete- li najít problémovou IP adresu uživatele, podívejte se do ERDDAP™ velkýRodič rodičů /logs/log.txt soubor ( velkýRodič rodičů je uvedeno v setup.xml ) zjistit, zda tomu tak je, a najít IP adresu uživatele. IP adresa pro každou žádost je uvedena na řádku začínajícím "{{{{#123;#" a je 4 čísla oddělena například obdobími 123.45.67.8 . Hledání "ERROR" vám pomůže najít problémy, jako jsou neplatné žádosti.
• Můžete také nahradit poslední číslo na IP adrese\(například 202.109.200.\) blokovat rozsah IP adres, 0-255.
• Můžete také nahradit poslední 2 čísla v IP adrese\.\ (například 121.204.\.\) blokovat širší rozsah IP adres, 0-255.0-255.
• Například,

    <requestBlacklist>98.76.54.321, 202.109.200.\\*, 121.204.\\*.\\*</requestBlacklist>

• Nemusíš restartovat. ERDDAP™ pro změny<requestBlacklist> nabýt účinku. Změny budou detekovány příště ERDDAP™ kontroluje, zda je třeba znovu načíst některé soubory údajů. Nebo můžete urychlit proces návštěvou setDataset URL vlajky pro jakýkoli datový soubor.
• Vaše ERDDAP™ denní zpráva obsahuje seznam/tálně těch nejaktivnějších povolených a blokovaných žadatelů.
• Pokud chcete zjistit, jaká doména/instituce souvisí s numerickou IP adresou, můžete použít bezplatnou, reverzní DNS webovou službu jako https://network-tools.com/ .
• Mohou nastat chvíle, kdy má smysl blokovat určité uživatele na vyšší úrovni, například škodlivé uživatele. Například můžete blokovat jejich přístup ke všemu na vašem serveru, nejen ERDDAP . Na Linux, jedna taková metoda je použít iptables . Například můžete přidat pravidlo, které zablokuje vše přicházející z 198.51.100.0 příkazem iptables -I INPUT -s 198.51.100.0 -J DROP

<ZpomalilTalloubleMillis>

• [ ** <slowDownTroubleMillis> ** ] (# Slowdowntroublemillis) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml který obsahuje celé číslo s uvedením počtu milisekund (výchozí=1000) zastavit při reakci na všechny neúspěšné žádosti, např. neznámý datový soubor, požadavek příliš velký, uživatel na černé listině. např.

  <slowDownTroubleMillis>2000</slowDownTroubleMillis>

Pokud scénář podává jednu žádost okamžitě za druhou, pak by mohl rychle podat jednu špatnou žádost za druhou. S tímto nastavením můžete zpomalit selhávání skriptu, takže ERDDAP™ není zaplaven špatnými požadavky. Pokud člověk podá špatnou žádost, ani si nevšimnou tohoto zpoždění. Doporučení:

• Je-li to problém, je to rozptýlené zapírání služby (DDOS) útok 100+ útočníků, nastavte to na menší počet (100?) . Zpomalit je všechny příliš dlouho vede k příliš mnoho aktivním vláknům.
• Pokud je problém z 1-10 zdrojů, nastavte to na 1000 ms (výchozí) , ale větší číslo (jako 10000) je také rozumný. To je zpomaluje, takže plýtvají méně síťových zdrojů. Také, 1000 ms nebo tak nebude otravovat lidské uživatele, kteří mají špatnou žádost.

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .  

<předplatnéEmailBlacklist>

• [ ** <předplatné EmailBlacklist> ** ] (#Předplatnémail blacklist) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml který obsahuje čárku oddělený seznam e-mailových adres, které jsou okamžitě načerno systém předplatného , například

  <subscriptionEmailBlacklist>bob@badguy.com, john@badguy.com</subscriptionEmailBlacklist>  

Tohle je systém necitlivý na případy. Pokud je do tohoto seznamu přidána e-mailová adresa, pokud má tato e-mailová adresa předplatné, předplatné bude zrušeno. Pokud se e-mailová adresa v seznamu pokusí přihlásit, žádost bude zamítnuta. Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .  

Standardní text

• Standardní text -- Existuje několik VOLITELNÝCH tagů (nejčastěji se používají vzácně) v rámci<erddapDatasets> tag in datasets.xml zadat text, který se objeví na různých místech v ERDDAP . Pokud chcete změnit výchozí text, zkopírujte existující hodnotu ze značky stejného jména v tomcat /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util.messages.xml do datasets.xml , pak upravit obsah. Výhoda mít tyto v datasets.xml je, že můžete zadat nové hodnoty kdykoliv, i když ERDDAP™ Utíká. Jakékoli změny hodnot těchto značek nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . Jména tag popisují svůj účel, ale pro hlubší pochopení viz výchozí obsah zpráv.xml.

• <standardLicense>

• <StandardKontakt>

• <standardDataLicenses>

• <StandardDisclaimerOfEndorsement>

• <StandardDisclaimerOfExternalLinks>

• <Norma GeneralDisclaimer>

• <standardní PrivacyPolicy>

• <startHeadHtml5>

• <startBodyHtml5> je dobrá značka pro změnu s cílem přizpůsobit vzhled horní části každé webové stránky ve vašem ERDDAP . Můžete to použít k přidání dočasné zprávy na ERDDAP™ domovská stránka (např. "Podívejte se na nový soubor dat JPL MUR SST v4.1 ..." nebo "Toto ERDDAP™ bude offline pro údržbu 2019-05-08T17:00:00 PDT až 2019-05-08T20:00:00 PDT.") . Jeden vtip dát tuto značku do datasets.xml je: při restartu ERDDAP , první žádost o ERDDAP™ vrátí výchozí start BodyHtml5 HTML, ale každý další požadavek bude používat startBodyHtml5 HTML uvedené v datasets.xml .

• <ShortDescription Html> je dobrá značka pro změnu pro přizpůsobení popisu ERDDAP . Všimněte si, že můžete snadno změnit toto přidat dočasnou zprávu na domovské stránce (např. "Toto ERDDAP™ bude offline pro údržbu 2019-05-08T17:00:00 PDT až 2019-05-08T20:00:00 PDT.") .

• <EndBodyHtml5>

Před ERDDAP™ v2.00, tyto byly specifikovány v nastavení.xml, který je stále povoleno, ale odrazen.  

<neobvyklé Aktivita>

• [ ** <neobvykláaktivita> ** ] (#neobvyklá aktivita) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml k určení maximálního počtu žádostí mezi dvěma řadami souborů LoadDatasets, které jsou považovány za normální (výchozí hodnota=10000) . Pokud je toto číslo překročeno, e-mail je odeslán na e-mailEverythingTo (jak je uvedeno v setup.xml) . např.

  <unusualActivity>10000</unusualActivity>  

Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka . Před ERDDAP™ v2.00, to bylo uvedeno v nastavení.xml, který je stále povoleno, ale odrazen.  

<Aktualizace MaxEvents>

• [ ** <updateMaxEvents> ** ] (#updatemaxevents) je vzácně používaná VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml zadat maximální počet událostí změny souboru (výchozí=10) který bude řešen [<updateEveryNMillis>] (#update everynmillis) systém před přepnutím na opětovné načtení datového souboru. Například,

  <updateMaxEvents>10</updateMaxEvents>  

UpdateEveryNMillis system má běžet velmi rychle těsně před zpracováním požadavku uživatele. Pokud existuje mnoho událostí změny souboru, pak pravděpodobně nemůže běžet rychle, takže místo toho volá po opětovném načtení souboru. Jestliže ERDDAP™ se zabývá soubory dat, které musí být aktualizovány, i když dochází ke změnám velkého počtu datových souborů, můžete to nastavit na větší číslo (100?) .

<uživatel>

• [ ** <uživatel > ** ] (# user) je VOLITELNÁ tag v rámci<erddapDatasets> tag in datasets.xml které identifikuje uživatelské jméno uživatele, heslo (pokud autentizace=custom) , a role (seznam oddělených čárek) . Použití uživatelského jména a hesla se mírně liší podle hodnoty [<autentizace>] (/docs/server-admin/dodatečné informace#authentication) ve Vašem ERDDAP 's nastavit.xml soubor.
  • Tohle je část ERDDAP 's bezpečnostní systém za omezení přístupu k některým datům pro některé uživatele.
  • Oddělit<user > tag pro každého uživatele. Volitelně, pokud autentizace=oauth2, můžete nastavit dvě<uživatel > značky pro každého uživatele: jeden pro případ, kdy se uživatel přihlásí přes Google, jeden pro kdy uživatel přihlásí přes Orcid, pravděpodobně se stejnými rolemi.
  • Pokud není<user> tag pro klienta, bude mít přístup pouze k veřejným souborům dat, tj. souborům, které nemají [<accessTo>] (#přístupný) Tagu.
  • uživatelské jméno Pro autentizaci=zákaz je uživatelské jméno obvykle kombinací písmen, číslic, podtrhuje a period. Pro autentizaci=email je uživatelské jméno e-mailovou adresou uživatele. Může to být jakákoli e-mailová adresa. Pro autentizaci=google je uživatelské jméno plnou adresou uživatele Google. To zahrnuje účty vedené společností Google, jako je @noaa.gov účty. Pro autentizaci=orcid je uživatelské jméno číslo účtu uživatele Orcid (s pomlčkami) . Pro autentizaci=oauth2 je uživatelské jméno úplná e-mailová adresa uživatele Google nebo číslo účtu uživatele Orcid (s pomlčkami) .
  • heslo Pro autentizaci=email, google, orcid, nebo oauth2, nespecifikujte atribut hesla. Pro autentizaci=custom musíte pro každého uživatele zadat atribut hesla.
    • Hesla, která uživatelé zadávají, jsou případově citlivá a musí mít 8 nebo více znaků, takže je těžší je rozlousknout. V současné době lze i 8 znaků rychle a levně rozluštit hrubou silou pomocí clusteru počítačů na AWS. ERDDAP™ Vymáhá minimálně 8 znaků, pouze když se uživatel pokusí přihlásit (ne když<user > tag je zpracováván, protože tento kód vidí pouze hash dist hesla, ne prostý text heslo).
    • setup.xml<Heslo Kódování> určuje, jak jsou hesla uložena v<uživatel > značky v datasets.xml . V zájmu zvýšení bezpečnosti jsou tyto možnosti:
      • MD5 (Nepoužívej to!) -- pro atribut hesla zadejte hash dist uživatele.
      • UEPMD5 (Nepoužívej to!) -- pro atribut hesla zadejte MD5 hash dist uživatelské jméno : ERDDAP : heslo . Uživatelské jméno a " ERDDAP "jsou zvyklí sůl hodnotu hašiše, takže je obtížnější dekódovat.
      • SHA256 (nedoporučuje se) -- pro atribut hesla zadejte SHA-256 hash dist uživatelského hesla.
      • UEPSHA256 (výchozí, doporučené heslo Kódování. Ale mnohem lepší: použijte Google, orchideje, nebo Oauth2 možnosti ověřování.) -- pro atribut hesla zadejte SHA-256 hash dist uživatelské jméno : ERDDAP : heslo . Uživatelské jméno a " ERDDAP " se používají k osolení hašišové hodnoty, takže je obtížnější dekódovat.
    • Na Windows můžete generovat hodnoty MD5 Heslo dist pomocí stahování programu MD5 (např. MD5 ) a použití (například) : md5 -djsmith: ERDDAP : aktuálníHeslo
    • Na Linux/Unix můžete generovat hodnoty MD5 dist pomocí vestavěného md5sum programu (například) : echo-n "Jsmith: ERDDAP : aktuálníHeslo " | md5sum
    • Uložený prostý text hesla jsou případově citlivé. Uložené formy hesel MD5 a UEPMD5 nejsou případově citlivé.
    • Například (pomocí UEPMD5) , pokud uživatelské jméno="jsmith" a heslo="myPassword"<user > tag je:

            <user username="jsmith"  
            password="57AB7ACCEB545E0BEB46C4C75CEC3C30"  
            roles="JASmith, JASmithGroup" />  

kde bylo uložené heslo generováno s md5 -djsmith: ERDDAP :myPassword

• role jsou čárkou oddělený seznam rolí, pro které je uživatel oprávněn. Jakýkoli<Soubor údajů > může mít [<accessTo>] (#přístupný) tag, který obsahuje seznam rolí, ke kterým lze přistupovat. U daného uživatele a daného datového souboru, pokud jedna z rolí v seznamu úloh uživatele odpovídá jedné z rolí uvedených v seznamu datového souboru<accessableTo> role, pak je uživatel oprávněn k přístupu k tomuto datovému souboru.

Každý uživatel, který se přihlásí, je automaticky uveden v roli \[ Kdokoliv Přidán In \] , zda existuje<tag pro uživatele BAR datasets.xml nebo ne. Takže pokud má daný datový soubor

            <accessibleTo>\\[anyoneLoggedIn\\]</accessibleTo>  

pak každý uživatel, který je přihlášen, bude oprávněn k přístupu k tomuto souboru dat, i když neexistuje<tag pro uživatele BAR datasets.xml .

• Jakékoli změny hodnoty této značky nabudou účinku příště ERDDAP™ čte datasets.xml , včetně odpovědi na soubor údajů vlajka .  

<CestaRegex>

• [ ** <pathRegex> ** ] (#pathragex) umožňuje zadat regulární výraz, který omezuje cestu (které podadresáře) budou zahrnuty do souboru údajů. Výchozí je .\*, která odpovídá všem cestám. To je vzácně používané, vzácně potřebné, VOLITELNÁ tag pro EDDGrid Databáze souborů FromFiles, datové soubory EDDTableFromFoles a několik dalších typů souborů dat. Nicméně, když to potřebuješ, opravdu to potřebuješ.

Aby to fungovalo, musíš být opravdu dobrý s pravidelnými výrazy. Vidíš tohle? dokumentace regexu a reflexní tutoriál . Zejména potřebujete vědět o zachycovacích skupinách (něco uvnitř závorky) , a "nebo" symbol " | ". Společně vám umožní určit libovolný počet možností, např. (možnost1 | možnost2 | možnost3) . Taky žádná z možností nemůže být nic, např., ( | možnost2 | možnost3) . Také je třeba vědět, že zachycovací skupiny mohou být vnořeny do hnízda, tj. každá možnost v zachycovací skupině může obsahovat další skupinu, např. ( | možnost2 ( | možnost2 b | option2c) | možnost3) což říká, že možnost 2 nemůže být následována ničím, nebo option2b, nebo option2c. Pro cestuRegexes bude každá volba jedním jménem složky následovaným /, např., bar/ .

Obtížná část cestyRegex je: ERDDAP™ Rekurzivně sestupuje strom adresáře, cestaRegex musí přijmout všechny cesty, se kterými se setká na své cestě do adresářů s daty. Regex je s hnízděnými zajatci je dobrý způsob, jak se s tím vypořádat.

Příklad: Předpokládejme, že máme následující strukturu adresáře:

/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  
...  

a zadaný souborAdresář je /foo/bar/, a chceme jen .nc soubory v D \[ 0-9 \] {4}/ a/ subdirectories. Řešením je nastavit cestuRegex na /foo/bar/ ( | D \[ 0-9 \] {4}/ ( | a/) )
To znamená: Cesta musí začít s /foo/bar/ To může následovat nic nebo D \[ 0-9 \] {4}/ To může následovat nic nebo a/

Ano, cesta Regex se dá neuvěřitelně těžko formulovat. Pokud se zaseknete, zeptejte se počítačového programátora (Nejbližší věc ve skutečném světě kouzelnickému zaříkávání?) nebo poslat Chrisovi e-mail. John v Noaa.gov.

<Databáze>

• [ ** <Databáze > ** ] (#Dataset) VOLITELNĚ (ale vždy použité) označení uvnitř<erddapDatasets> tag in datasets.xml že (pokud zahrnete všechny informace mezi<Soubor údajů > a</dataset>) zcela popisuje jeden datový soubor. Například,

  <dataset type="EDDGridFromDap" datasetID="erdPHssta8day" active="true"> ... </dataset>  

MŮŽE být nějaký počet značek datového souboru ve vašem datasets.xml Složka. V rámci<Soubor údajů > značka:  

• type=" a Typ " je požadovaný atribut v rámci<Soubor údajů > značka v datasets.xml který identifikuje typ datového souboru (např. EDDGrid /gridd nebo EDDTable/tabulární soubor dat) a zdroj údajů (například databáze, soubory nebo vzdálená OPeNDAP server) . Viz Seznam typů datových souborů .  

Soubor údajů Id

• ** datasetID =" aDatasetID "** je požadovaný atribut v rámci<Databáze > značka, která přiřazuje krátký (obvykle<15 znaků), jedinečné, identifikační jméno datového souboru.
• The datasetID Musí to být písmeno. (A-Z, a-z) následované libovolným počtem A-Z, A-Z, 0-9 a \_ (ale nejlepší pokud<Celkem 32 znaků).
• Soubor dat ID jsou citlivé na případ, ale nevytvářejte dva datasetID s, které se liší pouze v horních/ dolních písmenech. To způsobí problémy na Windows počítačích (Váš a/nebo uživatelský počítač) .
• Osvědčené postupy: Doporučujeme použít velbloud Případ .
• Osvědčené postupy: Doporučujeme, aby první část byla zkratkou nebo zkratkou jména zdrojové instituce a druhá část zkratkou jména datového souboru. Pokud je to možné, vytvoříme název, který odráží název zdroje pro datový soubor. Například jsme použili datasetID ="erdPH sst a8day" pro soubor údajů z NOAA NMFS SWFSC Oddělení environmentálního výzkumu ( ERD ) který je určen zdrojem jako satelit/PH/ sst 8 dní.
• Pokud změníte název datového souboru, starý datový soubor (se starým jménem) budou stále žít v ERDDAP . To je "orfan" soubor, protože specifikace pro něj v datasets.xml je pryč. To musí být řešeno:
  1. Pro ERDDAP™ V2.19 a později nemusíš dělat nic. ERDDAP™ automaticky odstraní tyto sirotčí soubory.
  2. Pro ERDDAP™ V2.18 a dříve musíte udělat něco pro odstranění osiřelých souborů: Vytvořit datový soubor aktivní="false," např.

                <dataset type="EDDTableFromNcFiles" datasetID="*theOldName*" active="false" />  

Po dalším velkém zatížení datové soubory, Tuto značku můžete odstranit poté, co je starý datový soubor neaktivní.  

aktivní

• active=" boolean " je VOLITELNÝ atribut v rámci<Soubor údajů > značka v datasets.xml který označuje, zda je soubor údajů aktivní (způsobilé pro použití v ERDDAP ) nebo ne.
• Platné hodnoty jsou pravdivé (výchozí) a falešné.
• Vzhledem k tomu, že výchozí hodnota je pravdivá, nemusíte používat tento atribut, dokud nechcete dočasně nebo trvale odstranit tento soubor z ERDDAP .
• Pokud jen odstraníte soubor Active="true" z datasets.xml , soubor údajů bude stále aktivní v ERDDAP™ ale nikdy nebude aktualizován. Takový datový soubor bude "orfan" a bude jako takový uveden ve statutu. html webová stránka přímo pod seznamem souborů, které se nepodařilo načíst.
• Pokud nastavíte aktivní="false," ERDDAP™ bude deaktivovat soubor údajů, když se příště pokusí aktualizovat soubor údajů. Když to uděláš, ERDDAP™ nevyhazuje žádné informace, které by mohly být uloženy o datovém souboru a rozhodně nedělá nic s aktuálními údaji.
• Za účelem odstranění datového souboru ERDDAP™ , viz Vynutit odstranění dat .  

** Několik značek se může objevit mezi<Soubor údajů > a</dataset> značky. **
Existuje určitá odchylka, ve které značky jsou povoleny, které typy souborů dat. Viz dokumentace pro konkrétní typ datového souboru pro detaily.

<přístupný Na...

• [ ** <přístupný To> ** ] (#přístupný) je VOLITELNÁ tag v rámci<tag datového souboru >, který určuje čárkový seznam role které mají přístup k tomuto souboru údajů. Například,

  <accessibleTo>RASmith, NEJones</accessibleTo>  

  • Tohle je část ERDDAP 's bezpečnostní systém za omezení přístupu k některým datům pro některé uživatele.
  • Pokud tato značka není přítomna, všichni uživatelé (i když se nepřihlásili) bude mít přístup k tomuto datovému souboru.
  • Pokud je tato značka přítomna, bude tento soubor viditelný a přístupný pouze pro přihlášené uživatele, kteří mají jednu z uvedených rolí. Tento soubor nebude viditelný pro uživatele, kteří nejsou přihlášeni.
  • Každý uživatel, který se přihlásí, je automaticky uveden v roli \[ Kdokoliv Přidán In \] , zda existuje<tag pro uživatele BAR datasets.xml nebo ne. Takže pokud má daný datový soubor

      <accessibleTo>\\[anyoneLoggedIn\\]</accessibleTo>  

pak každý uživatel, který je přihlášen, bude oprávněn k přístupu k tomuto souboru dat, i když neexistuje<tag pro uživatele BAR datasets.xml .  

<grafyPřístupnépro>

• [ ** <grafyPřístupnéTo> ** ] (#grafsaccessibleto) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml která určuje, zda jsou grafika a metadata pro datový soubor k dispozici veřejnosti. Nabízí způsob, jak částečně přepsat datový soubor [<accessTo>] (#přístupný) Nastavení. Přípustné hodnoty jsou:
  • auto -- Tato hodnota (nebo absence<grafyPříslušnéTo> tag pro datový soubor) umožňuje přístup k grafům a metadatům z datového souboru napodobovat soubor dat<accessableTo> nastavení. Takže pokud je datový soubor soukromý, jeho grafy a metadata budou soukromé. A pokud je datový soubor veřejný, jeho grafy a metadata budou veřejné.
  • veřejný -- Toto nastavení umožňuje přístup k grafům a metadatům datového souboru komukoli, dokonce i uživatelům, kteří nejsou přihlášeni, i když je soubor dat jinak soukromý, protože má<accessedTo> tag.  

<přístupný ViaFiles>

• [ ** <accessibleViaFiles > ** ] (#Accessibleviafiles) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml místo EDDGrid AgregátExistujícíRozměr , EDDGrid Kopírovat , EDDGrid OdEDDTable , EDDGrid FromErddap , EDDGrid OdEtopa , EDDGrid FromFiles (včetně všech podtříd) , EDDGrid SideBySide , EDDtableCopy EDDTableFromErddap , EDDTableFrom EDDGrid a EDDTableFromFoles (včetně všech podtříd) Data. Může mít hodnotu pravdy nebo lži. Například,

  <accessibleViaFiles>true</accessibleViaFiles>  

Pokud je hodnota pravdivá, ERDDAP™ bude to tak, aby uživatelé mohli procházet a stahovat zdrojové soubory datového souboru prostřednictvím ERDDAP 's "files" systém . Viz "files" systém Dokumentace pro více informací.

Výchozí hodnota<accessibleViaFiles > pochází z<defaultAccessibleViaFiles> v setup.xml . Má výchozí hodnotu false, ale doporučujeme přidat tento tag do nastavení.xml s hodnotou true.

Doporučení -- Doporučujeme zpřístupnit všechny příslušné soubory prostřednictvím systému souborů nastavením<defaultAccessibleViaFiles> to true in setup.xml, protože existuje skupina uživatelů, pro které je to preferovaný způsob, jak získat data. Kromě jiných důvodů "files" systém usnadňuje uživatelům sledovat, které soubory jsou k dispozici a kdy se naposledy změnily, a tak umožňuje uživateli udržovat si vlastní kopii celého datového souboru. Pokud obecně nechcete zpřístupnit soubory prostřednictvím systému souborů, nastavit<defaultAccessibleViaFiles > to false. V obou případech stačí použít<přístupnéViaFiles> pro několik souborů údajů, které jsou výjimkami z obecné politiky stanovené<defaultAccessibleViaFiles> (například při použití datového souboru .nc ml soubory, které nejsou opravdu užitečné pro uživatele) .  

<přístupný Via WMS >

• [ ** <přístupný Via WMS > ** ] (#Accessibleviawms) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml pro všechny EDDGrid podtřídy. Může mít hodnotu pravdy. (výchozí) nebo falešně. Například,

  <accessibleViaWMS>true</accessibleViaWMS>  

Pokud je hodnota falešná, ERDDAP 's WMS server nebude pro tento soubor k dispozici. To se běžně používá pro soubory údajů, které mají některé hodnoty délky větší než 180 (který je technicky neplatný WMS Služby) , a pro které nabízíte také variantu datového souboru s hodnotami délky zcela v rozmezí -180 až 180 přes EDDGrid LonPM180 . Pokud je hodnota pravdivá, ERDDAP™ se pokusí zpřístupnit datový soubor prostřednictvím ERDDAP 's WMS server. Ale pokud je datový soubor zcela nevhodný pro WMS (Například neexistují údaje o délce nebo šířce) , pak soubor nebude k dispozici prostřednictvím ERDDAP 's WMS server, bez ohledu na toto nastavení.  

<přidat Proměnné Kde?

• [<addVariablesKde >] (#Addvariableswhere) je VOLITELNÝ tag uvnitř<Soubor údajů > tag pro všechny soubory údajů z databáze EDDTable.

Žádosti o libovolný datový soubor podle protokolu EDDTable mohou zahrnovat &add Proměnné kde (" atribut Název "," atribut Hodnota ") , který říká ERDDAP™ přidat všechny proměnné do datového souboru, kde atributName=attributeValue na seznam požadovaných proměnných. Například pokud uživatel přidá &add Proměnné kde (" ioos\_category ""Vítr") na dotaz, ERDDAP přidá všechny proměnné v datovém souboru, které mají ioos\_category =Wind atribut seznamu požadovaných proměnných (například windSpeed, windDirection, windGustSpeed) . atribut Název a atribut Hodnota jsou citlivé na případy.

In datasets.xml , pokud část datového souboru.xml pro datový soubor má

<addVariablesWhere>*attributeNamesCSV*<addVariablesWhere>  

například:

<addVariablesWhere>ioos\\_category,units<addVariablesWhere>  

formulář pro přístup k údajům (.html webová stránka) pro soubor bude obsahovat widget (pro každý atributJméno v čárce odděleném seznamu) přímo pod seznamem proměnných, které umožňují uživatelům určit hodnotu atributu. Pokud uživatel zvolí hodnotu atributu pro jeden nebo více jmen atributů, budou k žádosti přidány prostřednictvím &add Proměnné kde (" atribut Název "," atribut Hodnota ") . Proto tento štítek datasets.xml umožňuje zadat seznam jmen atributů, které se zobrazí ve formuláři pro přístup k datům pro tento datový soubor, a umožňuje uživatelům přidat &addVariables Kde funkce na žádost. The atributNázevsCSV Seznam je citlivý na případy.

<nadmořská výškaMeteřiPerSourceUnit>

• [ ** <nadmořské výškyMatersPerSourceUnit> ** ] (#Altitudemetrypersourceunit) je VOLITELNÝ tag uvnitř<Databáze > značka v souborech dat. xxml pro EDDTableFrom SOS Soubory údajů (Jen!) která udává číslo, které se vynásobí výchozí nadmořskou výškou nebo hodnotami hloubky pro jejich přeměnu na hodnoty výšky (v metrech nad hladinou moře) . Například,

  <altitudeMetersPerSourceUnit>-1</altitudeMetersPerSourceUnit>  

Tato značka MUSÍ být použita, pokud hodnoty vertikální osy datového souboru nejsou metry, pozitivní=up. Jinak je to VOLITELNÉ, protože výchozí hodnota je 1. Například,

• Pokud je zdroj již měřen v metrech nad hladinou moře, použijte 1 (nebo nepoužívejte tuto značku, protože 1 je výchozí hodnota) .
• Pokud se zdroj měří v metrech pod hladinou moře, použijte -1.

    <altitudeMetersPerSourceUnit>-1</altitudeMetersPerSourceUnit>

• Pokud se zdroj měří v km nad mořem, použijte 0.001.  

<defaultDataQuery>

• [ ** <defaultDataQuery> ** ] (#defaultdataquery) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml To říká ERDDAP™ použít zadaný dotaz (část URL za "?") pokud je soubor .html Typ (formulář pro přístup k údajům) je požadováno bez dotazu.
  • Tohle budete pravděpodobně potřebovat jen zřídka.
  • Potřebujete XML kód (ne procentní kód) výchozí dotazy, protože jsou v XML dokumentu. Například se stane & ,<se stane<, > se stává > .
  • Prosím, zkontrolujte si práci. Je snadné udělat chybu a nedostat to, co chcete. ERDDAP™ Pokusí se očistit vaše chyby -- ale nespoléhejte se na to, protože\*Jak\*se může změnit.
  • Pro soubory dat o souřadnicích je společným použitím tato hodnota určena pro jinou hodnotu výchozí hloubky nebo nadmořské výšky. (například: \[ 0 \] místo \[ poslední \] ) . V každém případě byste měli vždy uvést všechny proměnné, vždy použít stejné hodnoty rozměrů pro všechny proměnné a téměř vždy použít \[ 0 \] , \[ poslední \] nebo \[ 0: poslední \] pro hodnoty rozměrů. Například:

      <defaultDataQuery>u\\[last\\]\\[0\\]\\[0:last\\]\\[0:last\\],v\\[last\\]\\[0\\]\\[0:last\\]\\[0:last\\]</defaultDataQuery>

  • Pro tabledap Databáze, pokud neurčíte žádné omezení, žádost vrátí celý soubor údajů, který může být neprakticky velký, v závislosti na datovém souboru. Pokud nechcete určit žádná omezení, spíše než mít prázdný<defaultDataQuery> (což je stejné jako nespecifikovat selhání DataQuery) , musíte explicitně vyjmenovat všechny proměnné, které chcete zahrnout do defaultDataQuery.
  • Pro tabledap Nejběžnějším použitím těchto údajů je určit jiný výchozí časový rozsah (vzhledem k max. (čas) Například &time >=max (čas) -1day, nebo vzhledem k teď, například, &time >= now- 1 den) . Nezapomeňte, že požadavek na žádné datové proměnné je stejný jako určení všech datových proměnných, takže obvykle můžete jen zadat nové časové omezení. Například:

      <defaultDataQuery>&amp;time&gt;=max(time)-1day</defaultDataQuery>  

nebo

    <defaultDataQuery>&amp;time&gt;=now-1day</defaultDataQuery>  

<defaultGraphQuery>

• [ ** <defaultGraphQuery> ** ] (#defaultgraphquery) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml To říká ERDDAP™ použít zadaný dotaz (část URL za "?") pokud soubor .graph Typ (zformovat graf) je požadováno bez dotazu.
  • Tohle budete pravděpodobně potřebovat jen zřídka.
  • Potřebujete XML kód (ne procentní kód) výchozí dotazy, protože jsou v XML dokumentu. Například se stane & ,<se stane<, > se stává > .
  • Prosím, zkontrolujte si práci. Je snadné udělat chybu a nedostat to, co chcete. ERDDAP™ Pokusí se očistit vaše chyby -- ale nespoléhejte se na to, protože\*Jak\*se může změnit.
  • U datových souborů mřížky je nejčastějším použitím těchto údajů určit jinou hodnotu výchozí hloubky nebo rozměr výšky. (například: \[ 0 \] místo \[ poslední \] ) a/nebo upřesnit, že konkrétní proměnná je grafizována. V každém případě budete téměř vždy používat \[ 0 \] , \[ poslední \] nebo \[ 0: poslední \] pro hodnoty rozměrů. Například:

      <defaultGraphQuery>temp\\[last\\]\\[0\\]\\[0:last\\]\\[0:last\\]&amp;.draw=surface&amp;.vars=longitude|latitude|temp</defaultGraphQuery>  

  (ale dát to všechno na jeden řádek)
  • Pro tabledap Databázové soubory, pokud neurčíte žádné omezení, bude požadavek grafizovat celý datový soubor, který může trvat dlouho, v závislosti na datovém souboru.
  • Pro tabledap Nejběžnějším použitím těchto údajů je určit jiný výchozí časový rozsah (vzhledem k max. (čas) Například &time >=max (čas) -1day, nebo vzhledem k teď, například, &time >= now- 1 den) . Nezapomeňte, že požadavek na žádné datové proměnné je stejný jako určení všech datových proměnných, takže obvykle můžete jen zadat nové časové omezení. Například:

      <defaultGraphQuery>&amp;time&gt;=max(time)-1day</defaultGraphQuery>  

nebo

    <defaultGraphQuery>&amp;time&gt;=now-1day</defaultGraphQuery>  

<DimensionValuesInMemory>

• [ ** <rozměr HodnotyInMemory> ** ] (# Dimensionvalueinmemory) (pravda (výchozí) nebo falešné) je VOLITELNÝ a vzácně používaný štítek uvnitř<Databáze > značka pro všechny EDDGrid Soubor údajů, který uvádí ERDDAP™ kde zachovat výchozí hodnoty rozměrů (také známý jako axisVariable án) :

  • true = v paměti (který je rychlejší, ale používá více paměti)
  • false = na disku (který je pomalejší, ale nepoužívá žádnou paměť)

Například,

<dimensionValuesInMemory>false</dimensionValuesInMemory>  

Měli byste to použít pouze s nevýchozí hodnotou false, pokud ERDDAP™ má mnoho souborů s velmi velkými rozměry (Například miliony hodnot, např. v EDDGrid Databáze souborů FromAudioFiles) a ERDDAP 's In Use použití paměti je vždy příliš vysoká. Viz paměť: momentálně používá řádek na \[ Vaše Doména \] /erddap/status.html sledovat ERDDAP™ používání paměti.  

<souborTableInMemory>

• [ ** <souborTableInMemory> ** ] (# filetableinmemory) (Pravda nebo lež (výchozí) ) je VOLITELNÝ tag uvnitř<Databáze > značka pro všechny EDDGrid FromFiles a EDDTable Databáze FromFiles, která říká ERDDAP™ kde uchovávat souborTable (který má informace o každém zdrojovém datovém souboru) :

  • true = v paměti (který je rychlejší, ale používá více paměti)
  • false = na disku (který je pomalejší, ale nepoužívá žádnou paměť)

Například,

<fileTableInMemory>true</fileTableInMemory>  

Pokud to nastavíte na true pro jakýkoli datový soubor, dávejte pozor na paměť: v současné době používá řádek na \[ Vaše Doména \] /erddap/status.html zajistit, aby ERDDAP™ Pořád má spoustu volné paměti.  

<fgdcFile>

• [ ** <fgdcFile > ** ] (#fgdcfile) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml To říká ERDDAP™ použít předvyrobený soubor FGDC namísto ERDDAP™ pokuste se vytvořit soubor. Použití:

    <fgdcFile>*fullFileName*</fgdcFile>  

plný Název souboru může odkazovat na místní soubor (Někde na serverovém souborovém systému) nebo URL vzdáleného souboru. Pokud plný Název souboru \="" nebo soubor není nalezen, soubor nebude mít žádná metadata FGDC. To je také užitečné, pokud chcete potlačit metadata FGDC pro konkrétní datový soubor. Nebo můžete dát<fgdcActive>false</fgdcActive> in setup.xml to tell ERDDAP™ nenabízíme FGDC metadata pro jakýkoli datový soubor.  

<iso19115 Soubor>

• [ ** <iso19115File> ** ] (#iso19115file) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml To říká ERDDAP™ použít předvyrobený soubor ISO 19115 namísto ERDDAP™ pokuste se vytvořit soubor. Použití:

  <iso19115File>*fullFileName*</iso19115File>  

  plný Název souboru může odkazovat na místní soubor (Někde na serverovém souborovém systému) nebo URL vzdáleného souboru. Pokud plný Název souboru \="" nebo soubor není nalezen, soubor nebude mít žádné ISO 19115 metadata. To je také užitečné, pokud chcete potlačit ISO 19115 metadata pro konkrétní datový soubor. Nebo můžete dát<iso19115Active>false</iso19115Active> in setup.xml to tell ERDDAP™ nenabízíme ISO 19115 metadata pro jakýkoli datový soubor.  

<matchAxis NDigits>

• [ ** <zápasAxisNDigits> ** ] (#matchaxisndigraphics) je VOLITELNÁ tag v rámci EDDGrid <Soubor údajů > značka pro EDDGrid datové soubory, které jsou agregace, např. agregace souborů. Pokaždé, když je soubor dat znovu načten, ERDDAP™ kontroluje, zda hodnoty os každé složky agregace jsou stejné. Přesnost zkoušky určuje zápasAxisNDigits , který určuje celkový počet číslic, které musí odpovídat při zkoušení hodnot dvojité přesné osy, 0 - 18 (výchozí) . Při testování hodnot float os se zkouška provádí se zápasemAxisNDigits/2. Hodnota 18 nebo vyšší říká EDDGrid udělat přesný test. Hodnota 0 říká EDDGrid nesmí provádět žádné zkoušky, které se nedoporučuje, s výjimkou níže popsaných.

I když EDDGrid umožňuje, aby součásti agregace měly mírně odlišné hodnoty os, uživateli je zobrazena pouze jedna sada hodnot os. Sada je ze stejné složky, která poskytuje zdrojová metadata datového souboru. Například: EDDGrid Databáze FromFiles, která je specifikována<metadataod > nastavení (default=last) .

Použití matchAxisNDigits\=0 je ve většině případů silně deprimován, protože vypne všechny kontroly. I minimální kontrola je užitečná, protože zajišťuje, že komponenty jsou vhodné pro agregaci. Všichni předpokládáme, že všechny komponenty jsou vhodné, ale není tomu tak vždy. Jedná se tedy o důležitý test duševního zdraví. Dokonce i hodnoty zápasuAxisNDigits1, 2, 3 nebo 4 jsou odrazeny, protože různé hodnoty osy často naznačují, že komponenty byly vytvořeny (Vyhozený?) jiným způsobem a nejsou proto vhodné pro agregace.

Existuje jeden případ, kdy je použití matchAxisNDigits\=0 užitečné a doporučené: s agregacemi vzdálených souborů, např. dat v kbelících S3. V tomto případě, pokud datový soubor používá cacheFromUrl, cacheSizeGB, matchAxisNDigits\=0, a EDDGrid Systém FromFiles pro Agregace prostřednictvím Název souboru , pak EDDGrid nemusí číst všechny vzdálené soubory, aby udělal agregace. To umožňuje velmi rychle načíst soubory z dat v kbelících S3 (na rozdíl od absurdně pomalu, pokud EDDGrid musí stáhnout a přečíst všechny soubory) .

<NThreads>

• Začneme s ERDDAP™ verze 2.00, pokud je podtřída EDDTableFromFoles nebo EDDGrid čte data ze svého zdroje, dokáže číst jeden kus dat (např. jeden zdrojový soubor) v čase (v jednom vlákně) (To je výchozí hodnota.) nebo více než jeden kus dat (např. 2+ zdrojové soubory) v čase (do 2 nebo více nití) při zpracování každé žádosti.  

  • Pravidlo palce: Pro většinu souborů souborů na většině systémů použijte nThreads=1, výchozí. Pokud máte výkonný počítač (spousta CPU jader, spousta paměti) , pak zvážit nastavení nThreards na 2, 3, 4, nebo vyšší (ale nikdy více než počet CPU jader v počítači) pro soubory údajů, které by mohly mít prospěch:

    • Většina EDDTableFromFoles bude přínosem.
    • Datasety, kde něco způsobí zpoždění před tím, než může být část dat skutečně zpracována, budou přínosem například:
      • Datové soubory s vnější komprimované (např. .gz ) binární (např. .nc ) Soubory, protože ERDDAP™ musí dekompresovat celý soubor, než začne číst soubor.
      • Datové soubory, které používají cacheSizeGB , protože ERDDAP™ často musí soubor stáhnout, než ho bude moci přečíst.
      • Datasety s datovými soubory uloženými v paralelním systému s vysokou šířkou pásma, protože může na požádání dodat více dat, rychleji. Příklady paralelních souborových systémů zahrnují JBOD , pNFS , GlusterFS , Amazon S3, a Google Cloud Storage.  

Varování: Při použití nThreads > 1, dávejte pozor ERDDAP 's použitím paměti, použitím nití a celkovou citlivostí (viz ERDDAP 's status page ) . Viz připomínky k těmto otázkám níže.  

• Pro daný datový soubor může toto nastavení nThreads pocházet z různých míst:

  • Pokud datasets.xml část pro datový soubor má<nThreads> značka (v rámci<Soubory údajů > tag, nikoli jako globální atribut) s hodnotou > 1, že hodnota nThreads se používá. Pro každý soubor můžete zadat jiné číslo.
  • Jinak, pokud datasets.xml má<nTableThreads> tag (pro EDDTable Databáze souborů) nebo<nGridThrads> tag (místo EDDGrid Soubory údajů) v hodnotě > 30 € za 100 kg čisté hmotnosti 1, mimo<Soubor > značka, že hodnota nThreads se používá.
  • Jinak se použije 1 vlákno, což je bezpečná volba, protože používá nejmenší množství paměti.  

Pro originál ERDDAP™ instalace , používáme <nTableThreads> 6</nTableThrads > (Je to silný server.) Obtížné žádosti nyní vyžadují 30% z předchozího času.  

Sledování využívání zdrojů

Když experimentujete s různými nastaveními nThreads (a možná obtížné žádosti o vzorek na vaše ERDDAP ) , můžete sledovat využívání zdrojů počítače:

• Na Macs použít vyhledávač: Aplikace: Nástroje : Monitor aktivity
• Na Linuxu použijte horní část
• Na Windows 10 použijte Ctrl + Shift + Esc otevřít správce úloh  

Varování: snížená odezva

V izolaci, ERDDAP™ splní požadavek na soubor dat s vyšším nastavením nThreads rychleji, než když nThreads=1. Ale zatímco se tato žádost zpracovává, další požadavky od jiných uživatelů budou poněkud vytěsněny a dostanou pomalejší odpověď. Také, když ERDDAP™ reaguje na danou žádost, jiné výpočetní zdroje (např. přístup na disk, síťová šířka pásma) může být omezující, zejména s vyšší nastavení nThreads. Proto s vyššími nastaveními nThreads, celková systémová citlivost bude horší, když se zpracovává více žádostí - to může být velmi nepříjemné pro uživatele! Kvůli tomu: nikdy nenastavte nThreads na více než počet CPU jader v počítači. nThreads=1 je nejspravedlivější nastavení od každé žádosti (mezi několika současnými žádostmi) dostane stejný podíl na výpočetních zdrojích. Ale čím silnější počítač, tím méně to bude problém.  

Varování: Vyšší paměť Použití pro EDDGrid Datové soubory

Použití paměti při zpracování požadavků je přímo úměrné nastavení nThreads. Dostatečně bezpečné pravidlo palce je: musíte nastavit ERDDAP 's nastavením paměti alespoň 2GB + (2GB \* nThreads) . Některé požadavky na některé datové soubory budou potřebovat více paměti. Například nastavení nThreads=3 pro všechny EDDGrid Soubor dat znamená, že nastavení -Xmx by mělo být alespoň -Xmx8000M. Pokud je nastavení paměti větší než 3/4 fyzickou paměť počítače, zmenšte nastavení nThreards tak, abyste mohli snížit nastavení paměti.

Použití paměti žádostí o zpracování vláken na soubory EDDTable je téměř vždy nižší, protože soubory jsou obvykle mnohem menší. Nicméně, pokud má daný soubor údajů EDDTable obrovský (Ostatní, j. n.) datové soubory, dále výše uvedené poznámky se vztahují i na tyto soubory údajů.

Ať už je nastavení nThreads jakékoliv, pozorně sledujte statistiky využití paměti na vašem ERDDAP 's status page . Nikdy byste se neměli přiblížit k maximalizaci využití paměti v ERDDAP ; jinak dojde k vážným chybám a chybám.

Dočasně nastaveno na 1

Pokud je současné využití paměti dokonce mírně vysoké, ERDDAP™ nastaví nThreards pro tuto žádost na 1. Takže, ERDDAP™ Uchovává paměť, když je paměť vzácná.  

Zmenšující se návrat

Tam jsou klesající výnosy ke zvýšení nastavení nThreads: 2 vlákna budou mnohem lepší než 1 (Pokud budeme ignorovat dynamické přetáčení) . Ale 3 bude jen kus lepší než 2. A 4 bude jen okrajově lepší než 3.

V jedné zkoušce obtížného dotazu na velký soubor údajů z EDDTable byla doba odezvy 1, 2, 3, 4, 5, 6 vláken 38, 36, 20, 18, 13, 11 sekund. (Nyní používáme nTableThreads=6 na tomto serveru.)

nThreads=2: Ačkoliv, tam je často významný přínos pro určení nThreads=2 místo nThreads=1, to často nebude mít velký rozdíl v hodinový čas potřebný k reakci na žádost daného uživatele. Důvodem je: s nThreads=1, většina moderní CPU vůle často dynamicky přesčas (zvýšení turbo) dočasně zvýšit rychlost hodin procesoru. Takže s nThreads=1, jedno jádro bude často pracovat vyšší rychlostí hodin než každé ze dvou jader, pokud jste použili nThreads=2. Bez ohledu na to, stále si myslíme, že je lepší použít nThrads=2 spíše než nThrads=1, protože toto nastavení přinese lepší výsledky v širší škále situací. A samozřejmě, pokud váš počítač má dostatečné CPU jádra, ještě vyšší nastavení nThreadů by mělo přinést lepší výsledky.

Jak bylo uvedeno výše, velmi vysoká nastavení nThreads může vést k rychlejší odpovědi na některé žádosti, ale riziko celkového poklesu ERDDAP™ citlivost a použití vysoké paměti (jak je uvedeno výše) Zatímco tyto žádosti jsou zpracovávány znamená, že obecně není dobrý nápad.

CPU Jádra

Neměli byste nikdy nastavit nThreads na číslo větší než počet CPU jader v procesoru počítače. V podstatě všechny moderní procesory mají více jader (např. 2, 4 nebo 8) . Některé počítače dokonce mají více procesorů (např. 2 procesory \* 4 jádra/CPU = 8 jader procesoru) . Chcete-li zjistit, kolik procesorů a jader počítač má:

• Na Macs, použijte Klíč pro volbu : Apple Menu : Systémové informace
• Na Linuxu použijte kočku /proc/cpuinfo
• Na Windows 10 použijte Ctrl + Shift + Esc otevřít Správce úloh: Výkon (Logické procesory zobrazují celkový počet CPU jader)

Ano, většina procesorů dnes říká, že podporují 2 vlákna na jádro (přes hypervaziva ) , ale 2 vlákna sdílet výpočetní zdroje, takže neuvidíte dvakrát průchodnost na procesoru pod těžkým zatížením. Například počítač s jedním procesorem se 4 jádry může tvrdit, že podporuje až 8 vláken, ale nikdy byste neměli překročit nThreads=4 v tom, že ERDDAP . Pamatuj si to:

• NThreads nastavení v ERDDAP™ je na žádost. ERDDAP™ často řeší více žádostí současně.
• ERDDAP™ provádí jiné věci než žádosti o zpracování, např. opětovné načtení dat.
• Kdy? ERDDAP™ reaguje na danou žádost, jiné výpočetní zdroje (např. přístup na disk, síťová šířka pásma) může být omezující. Čím vyšší budete nastavit nThreads, tím pravděpodobnější, že tyto další zdroje budou maximalizovány a zpomalí ERDDAP 's obecnou citlivostí.
• Operační systém dělá věci jiné než spustit ERDDAP .

Takže je lepší nenastavit nastavení nThreadů na více než počet jader v procesoru počítače.  

Vaše míle květen Vary (YMMV)

Výsledky různých nastavení nThreads se budou značně lišit u různých požadavků na různé soubory dat na různých systémech. Pokud opravdu chcete znát vliv různých nastavení nThreads, spusťte realistické testy.  

Proč nThreads na žádost?

Někteří z vás si myslí: "Proč je nThreads na žádost? Kdybych to kódoval, použil bych jedno stálé pracovní vlákno a frontu na zprávy pro lepší výkon." Problém s použitím jednoho dělnického poolu a fronty zpráv je, že jeden obtížný požadavek by zaplavit frontu s mnoha pomalými úkoly. To by účinně zablokovalo ERDDAP™ od i zahájení práce na úkolech týkajících se jiných žádostí až do počáteční žádosti byla (v podstatě) Hotovo. Dokonce i jednoduché následné žádosti by reagovaly velmi pomalu. ERDDAP 's použitím nThreads na žádost vede k mnohem spravedlivější využití výpočetních zdrojů.  

nThreads vs. více pracovních počítačů

Bohužel, ERDDAP 's nThreads systém nebude nikdy tak účinný jako skutečné paralelizace prostřednictvím více pracovních počítačů, s každým pracuje na kusu dat, ve způsobu, jakým Hadoop nebo Apache Spark jsou obvykle používány. Když je úkol skutečně paralelizován/distribuován na více počítačů, každý počítač může využít všechny své zdroje na svou část úkolu. S ERDDAP 's systémem nThreads, každá z vláken soutěží o stejnou šířku pásma počítače, diskové disky, paměť, atd. Bohužel, většina z nás nemá prostředky ani prostředky na založení ani pronájem (o webových službách Amazon (AWS) nebo Google Cloud Platform (GCP) ) masivní sítě počítačů. Na rozdíl od relační databáze, která může vrátit řádky výsledků v libovolném pořadí, ERDDAP™ slibuje, že vrátí řádky výsledků v konzistentním pořadí. Toto omezení dělá ERDDAP 's nThreads implementace méně efektivní. Ale... ERDDAP 's nThreads je užitečné v mnoha případech.

Existují však způsoby, jak ERDDAP™ stupnice pro rychlé zvládnutí obrovského počtu žádostí vytvořením mřížka/klastr/federace ERDDAP án .  

<palety>

• Začneme s ERDDAP™ verze 2.2, datasets.xml může zahrnovat<palety> značka (v rámci<erddapDatasets>), který přepíše<palety > hodnota značky ze zpráv.xml (nebo se vrátí k hodnotě zprávy.xml, pokud tag datasets.xml je prázdná) . To vám umožní změnit seznam dostupných palet, zatímco ERDDAP™ Utíká. Umožňuje také provést změnu a mít ji přetrvávající, když nainstalujete novou verzi ERDDAP . UPOZORNĚNÍ: palety uvedené v datasets.xml musí být superset palet uvedených ve zprávách.xml; jinak ERDDAP™ Hodí výjimku a přestane zpracování datasets.xml . To zajišťuje, že všechny ERDDAP™ instalace alespoň podporují stejné základní palety. UPOZORNĚNÍ: ERDDAP™ kontroluje, že palety souborů uvedených ve zprávách.xml skutečně existují, ale nekontroluje paletové soubory uvedené v datasets.xml . Je vaší povinností zajistit, aby byly soubory přítomny.

Také začínáme s ERDDAP™ verze 2.12, pokud vytvoříte podadresář cptfiles v ERDDAP™ adresář obsahu, ERDDAP™ zkopíruje všechny soubory \*.cpt v tomto adresáři do \[ tomcat \] /webapps/erddap/WEB-INF/cptfiles adresář pokaždé ERDDAP™ Začneme. Pokud tedy vložíte do tohoto adresáře vlastní soubory cpt, budou tyto soubory použity ERDDAP™ , bez extra úsilí na vaší straně, i když nainstalujete novou verzi ERDDAP .

UPOZORNĚNÍ: Pokud přidáte vlastní palety do svého ERDDAP™ a máte EDDGrid FromErddap a/nebo EDDTableFromErddap soubory ve vašem ERDDAP™ , pak uživatelé uvidí své vlastní paletové možnosti na ERDDAP™ Vytvořit graf webové stránky, ale pokud se je uživatel pokusí použít, dostanou graf s výchozím (obvykle duha) paleta. Je to proto, že obraz je vytvořen ovladačem ERDDAP™ která nemá vlastní paletu. Jediná řešení jsou nyní e-mailem vzdálené ERDDAP™ správce, který přidá vaše vlastní palety do své/ji ERDDAP nebo e-mail Chris. John v noaa.gov požádat, aby palety byly přidány do normy ERDDAP™ distribuce.

<onChange>

• [ ** <onChange> ** ] (#Změnit) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml která určuje činnost, která bude provedena při vytvoření tohoto souboru údajů (kdy ERDDAP™ restartováno) a kdykoli se tento datový soubor jakýmkoli způsobem změní.
  • V současné době pro EDDGrid podtřídy, jakákoli změna metadat nebo proměnné osy (například nový časový bod pro data v reálném čase) je považována za změnu, ale opětovné načtení datového souboru se nepovažuje za změnu (sama) .
  • V současné době se u podtříd EDDTable jakékoli opětovné načtení datového souboru považuje za změnu.
  • V současné době jsou povoleny pouze dva druhy akcí:
    • "http://"nebo "https://"-- Pokud akce začíná na "http://"nebo "https://", ERDDAP™ pošle HTTP GET požadavek na zadanou URL adresu. Odpověď bude ignorována. Například, URL může říct některé jiné webové služby, aby něco udělat.
      • Pokud má URL dotaz (po "?") , to musí být již % zakódováno . Musíte zakódovat speciální znaky do omezení (jiné než počáteční "&" a hlavní '=' omezení) do formuláře %HH, kde HH je 2 číslice hexadecimální hodnota znaku. Obvykle stačí převést několik interpunkčních znaků: % na% 225, & na% 226, "na% 222,<do% 3C, = do% 3D, > do% 3E, + do% 2B, | do% 7C, \[ do % 5B, \] do %5D, prostor na%20, a převést všechny znaky nad #127 do jejich UTF-8 formuláře a pak procento enkódovat každý byte UTF-8 formuláře do%HH formátu (Požádat programátora o pomoc) . Například stationID Podvozky a jejich části a součásti se stává & stationID % 3E=% 2241004%22 Procentuální kódování je obecně nutné, když přístup ERDDAP přes jiný software než prohlížeč. Prohlížeče obvykle zvládnout procento kódování pro vás. V některých situacích, musíte procent enkódovat všechny znaky jiné než A-Za-z0-9\_-!.~ ' () \*, ale stále nezakódujte počáteční "&" nebo hlavní '=' v omezeních. Programovací jazyky mají k tomu nástroje (např. viz Java 's java.net.URLEncoder a Java Skript je [encodeURIComponent()] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) ) a existují webové stránky, které pro vás tvoří procento enkódování/dekódování .
      • Od datasets.xml je XML soubor, musíte také kódovat ALL '&', '<"a ">" v URL jako "&," "<' a '>' po procentu kódování.
      • Příklad: Pro URL, které můžete zadat do prohlížeče jako: https://www.company.com/webService?department=R%26D&param2=value2
        Měli byste určit<onChange> značka prostřednictvím (na jednom řádku)

          <onChange>https://www.company.com/webService?department=R%26D&amp;param2=value2</onChange>

    • mailto: -- Pokud akce začíná na "mailto:," ERDDAP™ zašle e-mail na následující e-mailovou adresu, v níž uvede, že datový soubor byl aktualizován/změnil. Například:<onChange>mailto:john.smith@company.com</onChange > Pokud máte dobrý důvod ERDDAP™ na podporu jiného typu akce, pošlete nám e-mail popisující, co chcete.
  • Tato značka je volitelná. Může jich být tolik, kolik budeš chtít. Pro každou akci použijte jeden z těchto značek.
  • To je analogické s ERDDAP 's e-mailem / URL předplatné systém, ale tyto akce nejsou uloženy trvale (tj. jsou uloženy pouze v objektu EDD) .
  • Pro odstranění předplatného stačí odstranit<onChange> tag. Změna bude zaznamenána až bude příště soubor údajů znovu načten.  

<znovu načíst každý NMinutes>

• [ ** <reload EveryNMinutes> ** ] (# reload everynminutes) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml téměř všech typů souborů údajů, které určují, jak často by měl být soubor údajů znovu načítán. Například,

  <reloadEveryNMinutes>60</reloadEveryNMinutes>

  • Obecně platí, že soubory, které se často mění (například získat nové datové soubory) je třeba často znovu nabíjet například každých 60 minut.

  • Datasety, které se mění zřídka, by měly být opakovaně načítány, například každých 1440 minut (denně) nebo 10080 minut (týdenní) .

  • Tato značka je VOLITELNÁ, ale doporučená. Výchozí hodnota je 10080.

  • Příkladem je:<reloadEveryNMinutes>1440</reload EveryNMinutes>

  • Když je soubor dat znovu načten, všechny soubory v souboru velkýRodič rodičů /cache/ * datasetID * adresář se smaže.

  • Bez ohledu na to, co je nastaveno, nebude soubor dat načten častěji než<loadDatasetsMinMinutes> (výchozí hodnota = 15) , jak je uvedeno v setup.xml . Takže pokud chcete, aby byly soubory znovu načítány velmi často, musíte nastavit jak reloadEveryNMinutes a loadDatasets MinMinutes na malé hodnoty.

  • Nenastavovat znovunačítáníEveryNMinutes na stejnou hodnotu jako loadDatasets MinMinutes, protože uplynulý čas bude pravděpodobně (například) 14:58 nebo 15:02, takže data budou znovu načtena pouze asi v polovině hlavních reloadů. Místo toho, použijte menší (například 10) nebo větší (například 20) reload Každý NMinutes má hodnotu.

  • Bez ohledu na reloadEveryNMinutes, můžete ručně říct ERDDAP™ co nejdříve znovu načíst konkrétní datový soubor Soubor s vlajkou .

  • Pro podivné programátory -- ERDDAP™ , opětovné načtení všech souborů dat je řešeno dvěma jednotlivými účelově vázanými vlákny. Jedno vlákno spustí menší opětovné načtení, pokud najde vlajkový soubor nebo hlavní opětovné načtení (který kontroluje všechny soubory dat, aby zjistil, zda je třeba je znovu načíst) . Druhé vlákno načítá data po jednom. Tato vlákna fungují v pozadí a zajišťují, aby byly všechny soubory údajů aktualizovány. Vlákno, které skutečně reloads připravuje novou verzi datového souboru, pak jej vymění na místo (v podstatě nahrazuje starou verzi atomicky) . Takže je velmi možné, že následující sled událostí nastane (To je dobře.) :

    1. ERDDAP™ začne znovu načítat soubor údajů (vytvoření nové verze) v pozadí.
    2. Uživatelské 'A' podává žádost k datovému souboru. ERDDAP™ k vytvoření odezvy používá aktuální verzi datového souboru. (To je dobře. Uživatel neměl žádné zpoždění a současná verze datového souboru by nikdy neměla být příliš zastaralá.)
    3. ERDDAP™ dokončuje vytvoření nové reloadované verze datového souboru a swapy této nové verze do výroby. Všechny následující nové žádosti jsou řešeny novou verzí datového souboru. Pro konzistence je požadavek uživatele A stále vyplněn původní verzí.
    4. Uživatelské 'B' podává žádost k datovému souboru a ERDDAP™ použije novou verzi datového souboru k vytvoření odezvy.
    5. Nakonec jsou vyplněny požadavky uživatele A a uživatele B (Možná. A je první, možná B je první.) .

Slyším někoho říkat, "Jen dvě trojky! Ha! To je ubohý! Měl by to nastavit tak, aby opětovné nabíjení souborů dat používalo tolik vláken, kolik je potřeba, takže se to všechno dělá rychleji a s malým nebo žádným zpožděním." Ano i ne. Problém je v tom, že načítání více dat najednou vytváří několik těžkých nových problémů. Musí být vyřešeny nebo vyřešeny. Současný systém funguje dobře a má zvládnutelné problémy (například možnost zpoždění před vlajkou) . (Pokud potřebujete pomoc s jejich řízením, podívejte se na naše oddíl o získání dodatečné podpory .) Související aktualizace EveryNMillis . systém funguje v rámci reakčních vláken, takže může a vede k více soubory souborů jsou aktualizovány (ne naplno načíst) současně.

Proaktivní vs. reaktivní

ERDDAP 's reload system is proaktivní -- data jsou znovu načtena brzy po jejich opětovném načtení EveryNMinutes time is up (To znamená, že se z nich stane "příběh," ale nikdy příliš otupělý) , zda soubor údajů dostává žádosti od uživatelů nebo ne. Takže... ERDDAP™ Data jsou vždy aktuální a jsou připravena k použití. To je v rozporu s reaktivním přístupem THREDDS: žádost uživatele je to, co říká THREDDS zkontrolovat, zda je soubor dat zastaralý (to může být velmi zatuchlé) . Pokud je zatuchlý, THREDDS nechá uživatele čekat (často na několik minut) Zatímco data jsou znovu načítána.

<aktualizace EveryNMillis>

• [ ** <updateEveryNMillis> ** ] (#update everynmillis) je VOLITELNÁ tag v rámci<Soubor údajů > značka v datasets.xml některé typy souborů údajů, které pomáhají ERDDAP™ práce s datovými soubory, které se mění velmi často (často tak zhruba každou sekundu) . Na rozdíl od ERDDAP Je pravidelný, aktivní, [<reload EveryNMinutes >] (# reload everynminutes) systém pro úplné načtení každého datového souboru, tento VOLITELNÝ doplňkový systém je reaktivní (spuštěno žádostí uživatele) a rychlejší, protože je to postupné (pouze aktualizovat informace, které je třeba aktualizovat) . Například, pokud žádost o EDDGrid Soubor dat FromDap se vyskytuje více než stanovený počet milisekund od poslední aktualizace, ERDDAP™ uvidíme, jestli jsou nějaké nové hodnoty pro ty nejlevější. (první, obvykle "time" ) rozměr a pokud ano, stáhněte si tyto nové hodnoty dříve, než se postaráte o požadavek uživatele. Tento systém je velmi dobrý v udržování rychle se měnícího souboru aktuálního s minimálními nároky na zdroj dat, ale za cenu mírného zpomalení zpracování některých žádostí uživatelů.
  • Pro použití tohoto systému, přidat (například) :

    <updateEveryNMillis>1000</updateEveryNMillis>  

bezprostředně po<reloadEveryNMinutes> Označení datového souboru v datasets.xml . Počet milisekund, které zadáte může být stejně malý jako 1 (zajistit, aby soubor údajů byl vždy aktuální) . Hodnota 0 (výchozí) nebo záporné číslo vypne systém.

• Vzhledem k jejich přírůstkové povaze by aktualizace měly skončit velmi rychle, takže by uživatelé nikdy neměli čekat dlouho.
• Pokud druhá žádost o údaje dorazí před dokončením předchozí aktualizace, druhá žádost nespustí další aktualizaci.
• V celé dokumentaci se pokusíme použít slovo "reload" pro pravidelné, úplné opětovné načítání souborů a "update" pro tyto nové přírůstkové, částečné aktualizace.
• Pro testovací účely jsou některé diagnostiky vytištěny pro log.txt, pokud [<LogLevel >] (#loglevel) v datasets.xml je nastaven na "všechny."
• Pokud používáte přírůstkové aktualizace a zejména pokud nejlevější (první) Například čas, osa je velká, možná budete chtít nastavit<reloadEveryNMinutes > na větší číslo (1440?) , tak, aby aktualizace dělat většinu práce udržet soubor údajů aktuální, a plné opětovné načítání se provádí zřídka.
• Poznámka: tento nový systém aktualizace metadat (například čas actual\_range , time\_coverage\_end, ...) ale nespouští na Change (emailem nebo dotykem URL) nebo změnit RSS krmiva (Možná by to mělo...) .
• Pro všechny datové soubory, které používají podtřídy EDDGrid FromFiles a EDDTableFromFoles :
  • UPOZORNĚNÍ: při přidání nového datového souboru do datového souboru kopírováním do adresáře, který ERDDAP™ Podívejte, je tu nebezpečí, že ERDDAP™ všimne si částečně písemného souboru; pokusí se jej přečíst, ale selže, protože soubor je nekompletní; prohlásí soubor za "špatný" soubor a odstraní jej (dočasně) z datového souboru. Abychom se tomu vyhnuli, DOPORUČIT SE STRONGLII že kopírujete nový soubor do adresáře s dočasným jménem (např. 20150226 .nc Tmp) který neodpovídá souboru souborů dat NázevRegex (\*\ .nc ) , pak přejmenovat soubor na správný název (např. 20150226 .nc ) . Pokud použijete tento přístup, ERDDAP™ bude ignorovat dočasný soubor a všimne si správně pojmenovaný soubor pouze tehdy, když je dokončen a připraven k použití.
  • Pokud změníte existující datové soubory na místě (například přidání nového datového bodu) ,<updateEveryNMillis> bude fungovat dobře, pokud se změny objeví atomicky (v okamžiku) a soubor je vždy platný soubor. Například netcdf-java knihovna umožňuje přidání do neomezeného rozměru "klasické" .nc V3 soubor se provede atomovy. <updateEveryNMillis> bude špatně fungovat, pokud je soubor neplatný při provádění změn.
  • <updateEveryNMillis> bude pracovat dobře pro soubory, kde se jeden nebo několik souborů změní v krátkém čase.
  • <updateEveryNMillis> bude špatně pracovat pro soubory souborů, kde se velký počet souborů mění v krátkém čase (pokud se změny neobjeví atomově) . Pro tyto datové soubory je lepší nepoužívat<aktualizovatEveryNMillis> a nastavit a vlajka říct ERDDAP™ znovu načíst soubor údajů.
  • <updateEveryNMillis> neaktualizuje informace související s [< subsetVariables >] (#subsetvariables) . Normálně to není problém, protože subsetVariables mít informace o věcech, které se příliš často nemění (například seznam názvů stanic, zeměpisné šířky a délky) . Pokud subsetVariables změny údajů (například při přidání nové stanice do datového souboru) , pak kontaktujte URL vlajky pro soubor údajů, který má sdělit ERDDAP™ znovu načíst soubor údajů. Jinak, ERDDAP™ nevšimne si nové podmnožiny Proměnné informace až do příštího opětovného načtení datového souboru (<reloadEveryNMinutes>).
  • Naše obecné doporučení je použít:

      <reloadEveryNMinutes>1440</reloadEveryNMinutes>  
      <updateEveryNMillis>10000</updateEveryNMillis>

  • Problémy? Na Linuxových počítačích, pokud používáte<updateEveryNMillis> s EDDGrid FromFiles nebo EDDTableFromFoles třídy, můžete vidět problém, kde datový soubor selže načíst (příležitostně nebo důsledně) s chybovou zprávou: "IOException: Uživatelský limit inotify instancí dosaženo nebo příliš mnoho otevřených souborů." Příčinou může být chyba v Java což způsobuje, že případy nejsou shromažďovány odpadky. Tento problém se vyhnout v ERDDAP™ V1.66 a vyšší. Takže nejlepší řešení je přepnout nejnovější verzi ERDDAP . Pokud to nevyřeší problém (tj. pokud máte opravdu velký počet souborů pomocí<updateEveryNMillis>), můžete tento problém napravit voláním:

    sudo sysctl fs.inotify.max\\_user\\_watches=65536  
    sudo sysctl fs.inotify.max\\_user\\_instances=1024  
    sudo sysctl -p  

Nebo použijte vyšší čísla, pokud problém přetrvává. Výchozí hodnota hodinek je 8192. Výchozí hodnota pro případy je 128.

• Můžete tam dát<updateMaxEvents>10</updateMaxEvents> v datasets.xml (s ostatními nastaveními v blízkosti horní části) změnit maximální počet změn souboru (výchozí=10) která bude zpracována systémem updateEveryNMillis. Větší číslo může být užitečné pro soubor údajů, kde je velmi důležité, aby byly vždy aktualizovány. Viz aktualizace dokumentaceMaxEvents .
• Pro podivné programátory -- tyto přírůstkové aktualizace, na rozdíl od ERDDAP Je plná. reloadEveryNMinutes systém, objeví se v rámci uživatelského požadavku vlákna. Jakýkoliv počet souborů dat může být aktualizován současně. Existuje kód. (a zámek) zajistit, aby na aktualizaci daného datového souboru v daném okamžiku pracovalo pouze jedno vlákno. Umožnit více simultánních aktualizací bylo snadné; umožnit více simultánních celých reloadů by bylo těžší.  

<sourceCanCanstrainStringEQNE>

• [ ** <sourceCanCanstrainStringEQNE> ** ] (# sourcecantrainstringeqne) je VOLITELNÁ tag v tabulce<Soubor údajů > značka v datasets.xml který určuje, zda zdroj může omezit proměnné String pomocí operátorů = a !=.
  • Pro EDDTableFromDapSequence to platí pouze pro vnější sekvence String proměnné. Předpokládá se, že zdroj nezvládne žádná omezení na proměnné vnitřní sekvence.
  • Tato značka je volitelná. Platné hodnoty jsou pravdivé (výchozí) a falešné.
  • Pro EDDTableFromDapSequence OPeNDAP DRDS servery, to by mělo být nastaveno na true (výchozí) .
  • Pro EDDTableFromDapSequence Dapper servery, tohle by mělo být nastaveno na false.
  • Příkladem je:

        <sourceCanConstrainStringEQNE>true</sourceCanConstrainStringEQNE>  

 

<zdrojCanCanstrainStringGTLT>

• [ ** <zdrojCanCanstrainStringGTLT> ** ] (#sourcecantrainstringgtlt) je VOLITELNÁ tag v tabulce<Soubor > značka, která určuje, zda zdroj může omezit proměnné String pomocí<,<=, > a > hospodářské subjekty.
  • Pro EDDTableFromDapSequence to platí pouze pro vnější sekvence String proměnné. Předpokládá se, že zdroj nezvládne žádná omezení na proměnné vnitřní sekvence.
  • Platné hodnoty jsou pravdivé (výchozí) a falešné.
  • Tato značka je volitelná. Default je pravdivý.
  • Pro EDDTableFromDapSequence OPeNDAP DRDS servery, to by mělo být nastaveno na true (výchozí) .
  • Pro EDDTableFromDapSequence Dapper servery, tohle by mělo být nastaveno na false.
  • Příkladem je:

        <sourceCanConstrainStringGTLT>true</sourceCanConstrainStringGTLT>  

 

<zdrojCanCanstrainStringRegex>

• [ ** <sourceCanCanstrainStringRegex> ** ] (# sourcecanconstriningregex) je VOLITELNÁ tag v tabulce<tag datového souboru >, který určuje, zda zdroj může omezit proměnné String pomocí pravidelných výrazů, a pokud ano, co je operátor.
  • Platné hodnoty jsou "=" (vá DAP standardní) , "=" (mylně podporován mnoha lidmi DAP servery) nebo "" (naznačující, že zdroj nepodporuje pravidelné výrazy) .
  • Tato značka je volitelná. Výchozí je ""
  • Pro EDDTableFromDapSequence OPeNDAP DRDS servery, to by mělo být nastaveno na "" (výchozí) .
  • Pro EDDTableFromDapSequence Dapper servery, to by mělo být nastaveno na "" (výchozí) .
  • Příkladem je:

        <sourceCanConstrainStringRegex>=~</sourceCanConstrainStringRegex>  

<zdrojCanDoDistinct>

• [ ** <sourceCanDoDistinct> ** ] (# sourcecandodistant) je VOLITELNÝ tag v databázi EdDtableFromDatabase<tag datového souboru >, který určuje, zda má zdrojová databáze zvládnout & Distinct () omezení v uživatelských dotazech.
  • Tato značka je volitelná. Platné hodnoty jsou ne ( ERDDAP™ ovládá odlišné; výchozí) , částečné (zdroj ovládá odlišné a ERDDAP™ Zvládne to znovu.) , a ano (zdroj zvládá odlišné) .
  • Jestliže užíváte ne a ERDDAP™ Dochází mu paměť, když se s ním zachází jinak, použijte ano.
  • Pokud používáte ano a zdrojová databáze pracuje příliš pomalu, použijte ne.
  • parciální vám dává nejhorší z obou: to je pomalé, protože zpracování databáze odlišné je pomalé a může dojít paměť v ERDDAP .
  • Databáze interpretují DISTINCT jako požadavek na pouze jedinečné řádky výsledků, zatímco ERDDAP™ interpretuje jej jako žádost o setříděný seznam unikátních řádků výsledků. Pokud to nastavíte na částečné nebo ano, ERDDAP™ automaticky také říká databázi, aby třídila výsledky.
  • Jeden malý rozdíl ve výsledcích: Ne. | částečné, ERDDAP™ bude třídit "" na začátku výsledků (před ne-""" řetězce) . S ano, databáze může (Postgres bude) Sort "" na konci výsledků (po non-"" řetězce) . Budu hádat, že to také ovlivní třídění krátkých slov oproti delším slovům, která začínají krátkým slovem. Například, ERDDAP™ bude třídit "Simon" před "Simony."
  • Příkladem je:

        <sourceCanDoDistinct>yes</sourceCanDoDistinct>  

 

<sourceCanOrderBy>

• [ ** <zdroj CanOrderBy> ** ] (#Sourcecanorderby) je VOLITELNÝ tag v databázi EdDtableFromDatabase<tag datového souboru >, který určuje, zda má zdrojová databáze zvládnout & orderBy (...) omezení v uživatelských dotazech.
  • Tato značka je volitelná. Platné hodnoty jsou ne ( ERDDAP™ kliky orderBy (...) ; výchozí) , částečné (zdrojové kliky orderBy a ERDDAP™ Zvládne to znovu.) , a ano (zdrojové kliky orderBy (...) ) .
  • Jestliže užíváte ne a ERDDAP™ dochází mi paměť při manipulaci orderBy (...) , použijte ano.
  • Pokud používáte ano a kliky na zdrojovou databázi orderBy (...) příliš pomalu, použijte ne.
  • částečné dává vám nejhorší z obou: je to pomalé, protože databázové zpracování orderBy (...) je pomalý a může dojít paměť v ERDDAP .
  • Jeden malý rozdíl ve výsledcích: Ne. | částečné, ERDDAP™ bude třídit "" na začátku výsledků (před ne-""" řetězce) . S ano, databáze může (Postgres bude) Sort "" na konci výsledků (po non-"" řetězce) . To může také ovlivnit třídění krátkých slov oproti delším slovům, která začínají krátkým slovem. Například, ERDDAP™ bude třídit "Simon" před "Simony," ale nejsem si jistý, jak je bude databáze třídit.
  • Příkladem je:

        <sourceCanOrderBy>yes</sourceCanOrderBy>  

 

<zdrojNeedsExpandedFP\_EQ>

• [ ** <zdrojNeedsExpandedFP\_EQ> ** ] (#sourceneedsexpandedfp_eq) je VOLITELNÁ tag v tabulce<Soubor > značka, která určuje (pravda (výchozí) nebo falešné) pokud zdroj potřebuje pomoct s dotazy s<číselný Proměnná >=<floatingPointValue> (a !=, ><=). Například,

  <sourceNeedsExpandedFP\\_EQ>false</sourceNeedsExpandedFP\\_EQ>

  • Pro některé zdroje dat, číselné dotazy zahrnující =, !=,<= nebo > nesmí pracovat podle přání s čísly plovoucích bodů. Například hledání délky=220.2 může selhat, pokud je hodnota uložena jako 220.20000000000001.
  • Tento problém vzniká, protože plovoucí bod čísla jsou není zrovna v počítačích .
  • Pokud zdrojNeedsExpandedFP\_EQ je nastaven na true (výchozí) , ERDDAP™ modifikuje dotazy zaslané do zdroje dat, aby se zabránilo tomuto problému. Je vždy bezpečné a v pořádku nechat tento soubor být.  

< sourceUrl >

• [ ** < sourceUrl > ** ] (#sourcerl) je společná značka v rámci globálního datového souboru< addAttributes > tag, který určuje URL, který je zdrojem dat.
  • Příkladem je:

      <sourceUrl>https://oceanwatch.pfeg.noaa.gov/thredds/dodsC/satellite/VH/chla/1day</sourceUrl>  

  (ale dát to všechno na jeden řádek)
  • In ERDDAP™ , všechny datové soubory budou mít " sourceUrl " v kombinovaných globálních atributech, které jsou zobrazeny uživatelům.
  • U většiny typů souborů dat je tato značka povinná. Viz popis typu datového souboru, aby bylo možné zjistit, zda je to vyžadováno či nikoli.
  • Pro některé datové soubory je oddělená< sourceUrl > značka není povolena. Místo toho musíš poskytnout " sourceUrl " globální atribut , obvykle v globální \ > addAttributes <. Pokud neexistuje skutečná zdrojová URL (například pokud jsou data uložena v místních souborech) , Tento atribut má často jen místodržitel hodnotu, například,<att name="name] (místní soubory) </att> .
  • Pro většinu souborů dat je to základ URL, který se používá k požadavku na data. Například: DAP servery, toto je URL, do kterého lze přidat .dods, .das, .dds nebo .html.
  • Od datasets.xml je XML soubor, musíte také enkódovat '&', '<"a ">" v URL jako "&," "<' a '>'.
  • U většiny typů souborů údajů ERDDAP™ přidá originál sourceUrl ("localSourceUrl" ve zdrojovém kódu) do globální atributy (kde se stane "publicSourceUrl" ve zdrojovém kódu) . Když zdroj dat je místní soubory, ERDDAP™ přidat sourceUrl =" (místní soubory) " globálním atributům jako bezpečnostní opatření. Pokud je zdrojem dat databáze, ERDDAP™ přidat sourceUrl =" (databáze zdrojů) " globálním atributům jako bezpečnostní opatření. Pokud některé vaše datové soubory používají neveřejné sourceUrl 's (obvykle proto, že jejich počítač je ve vašem DMZ nebo na lokální LAN) můžete použít [<convertToPublicSourceUrl>] (# Konvertovat na veřejné zdrojeurl) značky pro upřesnění, jak převést místní sourceUrl s na veřejnost sourceUrl s.
  • A sourceUrl může začít http:// , https:// , ftp://, a možná další předpony. https spojení čte a kontroluje digitální certifikát zdroje, aby bylo zajištěno, že zdroj je tím, kým říkají, že jsou. Ve vzácných případech může tato kontrola selhat s chybou "javax.net.ssl.SSLProtocolVýjimkou: handshake alarm: uncognized\_name." To je pravděpodobně způsobeno doménovým jménem na certifikátu, který neodpovídá doménovému názvu, které používáte. Můžete a měli byste si přečíst podrobnosti o sourceUrl 's certifikátem ve vašem webovém prohlížeči, zejména seznam "DNS Name" v sekci "Subjekt Alternative Name."

V některých případech sourceUrl používáte jméno domény uvedené v osvědčení. Například, https://podaac-opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/bude házet tuto chybu, ale https://opendap.jpl.nasa.gov/opendap/allData/ccmp/L3.5a/monthly/flk/, Který používá název domény na certifikátu, nebude. Řešením v těchto případech je proto najít a použít název domény na osvědčení. Pokud ho nenajdete v certifikátu, kontaktujte poskytovatele dat.

V ostatních případech může být název domény uvedený v osvědčení pro skupinu jmen. Pokud k tomu dojde nebo je problém jinak neřešitelný, prosím, e-mail Chris. John v Noaa.gov nahlásí problém.  

<addAttributes>

• [ ** < addAttributes > ** ] (#addattributy) je VOLITELNÁ tag pro každý soubor údajů a pro každou proměnnou, která umožňuje ERDDAP Správci kontrolují atributy metadat spojené s datovým souborem a jeho proměnnými.
  • ERDDAP™ kombinuje atributy ze zdroje datového souboru ("sourceAttributes") a " addAttributes "který definujete datasets.xml (které mají přednost) k vytvoření "kombinovaných atributů," což je co ERDDAP™ uživatelé vidí. Můžete tedy použít addAttributes redefinovat hodnoty zdrojových atributů, přidat nové atributy nebo odstranit atributy.
  • The< addAttributes > značka obsahuje 0 nebo více ** <att > ** podtagy, které se používají k určení jednotlivých atributů.
  • Každý atribut se skládá z názvu a hodnoty (který má specifický datový typ, například, dvojitý) .
  • S daným jménem může existovat pouze jeden atribut. Jestli je jich víc, tak ten poslední má přednost.
  • Hodnota může být jedna hodnota nebo mezerně oddělený seznam hodnot.
  • Syntaxe
    • Pořadí<att > subtags within addAttributes není důležité.
    • The<attt> podtag formát je

        <att name="*name*" \\[type="*type*"\\] >*value*</att>

    • Název místa určení všech atributů MUSÍ začít písmenem (A-Z, a-z) a MUSÍ obsahovat pouze znaky A-Z, a-z, 0-9 nebo '\_'.
    • Pokud<attt> podtag nemá hodnotu nebo hodnotu nuly, tento atribut bude odstraněn z kombinovaných atributů. Například,<att name="rows" /> odstraní řádky z kombinovaných atributů. Například,<att name="coordinations¶null</att> odstraní souřadnice z kombinovaných atributů.

atribut Typ

• [VOLITELNÁ hodnota typu pro<att > subtags] (#atributetyp) označuje datový typ hodnot. Výchozím typem je String. Příkladem atributu String je:

  <att name="creator\\_name">NASA/GSFC OBPG</att>

  • Platné typy pro jednotlivé hodnoty jsou byte (8-bitové celé číslo) , krátké (16-bit podepsané celé číslo) , int (32-bit podepsané celé číslo) , dlouhá (64-bit podepsané celé číslo) , plavat (32-bitový plovoucí bod) , dvojitá (64-bitový plovoucí bod) , Char, a String. Například,

    <att name="scale\\_factor" type="float">0.1</att>

Viz tyto poznámky o datový typ znaku . Viz tyto poznámky o Dlouhý datový typ .

• Platné typy pro seznamy hodnot oddělených od prostoru (nebo jednotné hodnoty) jsou byteList, shortList, unsignedShortList, charList, intList, longList, floatList, double Seznam. Například,

  <att name="actual\\_range" type="doubleList">10.34 23.91</att>  

UnsignedShortList vám umožní zadat seznam nesignovaných kraťasů, ale budou převedeny na seznam odpovídajících znaků Unicode (např. "65 67 69" bude přeměněno na "A C E." Pokud zadáte charList, zakódujte jakékoliv speciální znaky (např. prostor, dvojité uvozovky, backslash,<#32 nebo >#127), jak byste je zakódovali v datové sekci NCCSV souboru (např., "," "\"" nebo """," "\\," " \n ", "\ u20ac") . Není žádný strunný list. Uložte hodnoty String jako multi-line String. Například,

<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>  

 

Globální Atributy

• [ ** Globální Atributy / Global< addAttributes > ** ] (#Global-atributes) -- < addAttributes > je VOLITELNÁ tag v rámci<Databáze > značka, která se používá ke změně atributů, které se vztahují na celý datový soubor.

  • ** Použijte globální< addAttributes > změnit globální atributy datového souboru. ** ERDDAP™ kombinuje globální atributy ze zdroje datového souboru (** zdrojAtributy ) a globální addAttributes který definujete v datasets.xml (které mají přednost) vytvořit globální kombinovanéAtributy ** , které jsou co ERDDAP™ uživatelé vidí. Můžete tedy použít addAttributes redefinovat hodnoty zdrojových atributů, přidat nové atributy nebo odstranit atributy.
  • Viz [ ** < addAttributes > informace] (#addattributy) která se vztahuje na globální a variabilní < addAttributes > ** .
  • FGDC a ISO 19115-2/19139 Metadata -- Normálně, ERDDAP™ automaticky generuje ISO 19115-2/19139 a FGDC (FGDC-STD-001-1998) Soubory XML metadat pro každý datový soubor s využitím informací z metadat datového souboru. Takže, dobrá metadata datového souboru vede k dobrému ERDDAP -vygenerovala metadata ISO 19115 a FGDC. Zvažte, prosím, vložit hodně času a úsilí do zlepšení metadat vašich souborů (Což je stejně dobrá věc.) . Většina atributů metadat datového souboru, které se používají pro generování metadat ISO 19115 a FGDC jsou z Standard metadat ACDD a jsou uvedeny níže.
  • Mnohé globální atributy jsou zvláštní v tom, že ERDDAP™ Hledá je a používá je různými způsoby. Například odkaz na infoUrl je zahrnuta na webových stránkách se seznamy souborů dat a dalších míst, aby uživatelé mohli zjistit více o datovém souboru.
  • Pokud uživatel vybere podmnožinu dat, globální atributy vztahující se k délce proměnné, zeměpisné šířce, výšce (nebo hloubka) , a časové rozsahy (např. Southernmost\_severní, Northernmost\_severní, time\_coverage\_start, time\_coverage\_end) jsou automaticky generovány nebo aktualizovány.
  • Jednoduchý globální vzorek< addAttributes > je:

    <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>  

Prázdný atribut cwhdf\_version způsobuje atribut zdroj cwhdf\_version (pokud existuje) která se odstraní ze konečného seznamu atributů.

• Poskytování těchto informací pomáhá ERDDAP™ dělat lepší práci a pomáhá uživatelům pochopit soubory dat. Dobré metadata činí datový soubor použitelný. Nedostatečná metadata činí datový soubor k ničemu. Prosím, udělejte si čas na dobrou práci s atributy metadat.

Zvláštní globální atributy v ERDDAP™

Potvrzení

• Potvrzení a uznání (z ACDD standard metadat) je DOPORUČENÝ způsob uznání skupiny nebo skupin, které poskytly podporu (zejména finanční) pro projekt, který vytvořil tato data. Například,

<att name="acknowledgment">AVISO</att>

Všimněte si, že ACDD 1.0 a 1.1 používají hláskování "poznámky" (což je obvyklé pravopis v USA.) , ale ACDD 1.3 to změnilo na "poznání" (což je obvyklé pravopis ve Velké Británii.) . Chápu to tak, že změna byla v podstatě nehoda a že rozhodně nepoznali důsledky změny. To je bordel! Po celém světě jsou miliony datových souborů, které mají "poznání" a miliony, které mají "poznání." To zdůrazňuje pošetilost "jednoduchých" změn normy a zdůrazňuje potřebu stability norem. Protože ACDD 1.3 (což je verze ACDD, že ERDDAP™ Podpora) říká "poznání," ERDDAP™ (GenerovatDatasety Xml) podporuje.  

cdm\_altitude\_proxy

• cdm\_altitude\_proxy je pouze pro soubory EDDTable, které nemají proměnnou výšky nebo hloubky, ale mají proměnnou, která je proxy pro nadmořskou výšku nebo hloubku (například tlak, sigma, láhevČíslo) , můžete použít tento atribut k identifikaci této proměnné. Například,

<att name="cdm\\_altitude\\_proxy">pressure</att>  

Pokud cdm\_data\_type je Profile nebo TrajectoryProfile a neexistuje žádná proměnná výšky nebo hloubky, cdm\_altitude\_proxy MUSÍ být definováno. Pokud je definován cdm\_altitude\_proxy, ERDDAP™ přidá do proměnné následující metadata: \_Souřadnice AxisType=Height and axis=Z.  

cdm\_data\_type

• cdm\_data\_type (z ACDD standard metadat) je globální atribut, který označuje Unidata Společný datový model datový typ datového souboru. Například,

<att name="cdm\\_data\\_type">Point</att>  

CDM se stále vyvíjí a může se opět změnit. ERDDAP™ splňuje související a podrobnější požadavky Geometrie diskrétního odběru vzorků (DSG) kapitola CF 1.6 Konvence metadat (dříve nazývané úmluvy o sledování CF bod) .

• Buď je soubor globální zdrojAtributy nebo jeho globální< addAttributes > MUSÍ obsahovat atribut cdm\_data\_type. Několik typů souborů údajů (jako EDDTable FromObis) automaticky to nastaví.
• Pro EDDGrid Soubory dat, možnosti cdm\_data\_type jsou Grid (výchozí a zdaleka nejčastější typ pro EDDGrid Soubory údajů) , MovingGrid, Other, Point, Profile, RadialSweep, TimeSeries, TimeSeriesProfile, Swath, Trajektorie a TrajektoryProfile. V současné době, EDDGrid nevyžaduje, aby byla specifikována žádná související metadata, ani nekontroluje, zda data odpovídají typu cdm\data\. To se pravděpodobně v blízké budoucnosti změní.
• EDDTable používá cdm\_data\_type přísně, po specifikaci CF DSG spíše než CDM, který z nějakého důvodu nebyl aktualizován, aby byl v souladu s DSG. Pokud metadata datového souboru neodpovídá ERDDAP 's požadavky cdm\_data\_type' (viz níže) , datový soubor nebude načíst a bude generovat chybová zpráva . (To je dobře, v tom smyslu, že chybová zpráva vám řekne, co je špatně, abyste to mohli napravit.) A pokud data datového souboru neodpovídají nastavení metadat datového souboru (Například pokud existuje více než jedna hodnota zeměpisné šířky pro danou stanici v souboru časových řad) , některé žádosti o údaje vrátí nesprávné údaje v odpovědi. Takže se ujisti, že to všechno uděláš správně.

Pro všechny tyto soubory údajů, v úmluvách a Metadata\_Conventions globální atributy, viz CF-1.6 (ne CF-1,0, 1.1, 1.2, 1.3, 1.4 nebo 1.5) , protože CF-1.6 je první verze, která zahrnuje změny související s diskrétní odběr vzorků geometrie (DSG) Konvence.

• ** ERDDAP™ nemá jednoduchý vztah k CF DSG**
• ERDDAP™ může vytvořit platný datový soubor DSG ze zdrojového souboru, který je již platným DSG souborem (án) , nebo ze zdrojového souboru, který není nastaven pro DSG, ale lze jej provést prostřednictvím změn metadat (některé z nich jsou ERDDAP -specifický s cílem poskytnout obecnější přístup k upřesnění nastavení DSG) .
• ERDDAP™ provádí hodně zkoušek platnosti, když načítá soubor údajů. Pokud má datový soubor cdm\_data\_type (nebo featureType ) atribut úspěšně zatížení v ERDDAP™ , pak ERDDAP™ tvrdí, že datový soubor splňuje požadavky DSG (jinak, ERDDAP™ bude hodit výjimku vysvětlit první problém, který našel) . UPOZORNĚNÍ: Zdá se, že úspěšně naložený soubor dat splňuje požadavky DSG (má správnou kombinaci atributů) , ale stále může být špatně nastaven, což vede k nesprávným výsledkům .nc CF a .nc Soubory odpovědí CFMA. (Software je v některých ohledech chytrý a v jiných netušící.)
• Když se podíváte na metadata souboru v ERDDAP™ , zdá se, že DSG soubor je v ERDDAP 's vnitřním formátem (obří, databázová tabulka) . Není v jednom z DSG formátů (Například rozměry a metadata nejsou správné) , ale informace potřebné pro zpracování datového souboru jako DSG data jsou v metadatech (například cdm\_data\_type=TimeSeries a cdm\_timeseries\_variables= aCsvListOfStationRelatedVarables v globálních metadatech a cf\_role=timeseries\_id pro některé proměnné) .
• Pokud uživatel požaduje podmnožinu datového souboru v .nc CF (a .nc soubor ve formátu DSG kontiguous Ragged Array) nebo .nc Soubor CFMA (a .nc soubor ve formátu DSG Multidimenzional Array) , že soubor bude platný CF DSG soubor. UPOZORNĚNÍ: Nicméně, pokud byl soubor dat nastaven nesprávně (takže sliby z metadat nejsou pravdivé) , pak soubor odpovědi bude technicky platný, ale bude být nějakým způsobem nesprávné.  

EDDTable cdm_data_types

• Pro soubory EDDTable jsou možnosti cdm\_data\_type (a související požadavky v ERDDAP ) jsou

Bod

• Bod -- je pro soubor měření provedených v nesouvisejících časech a místech.
• Stejně jako u všech cdm\_data\_typů jiných než jiných, musí mít bodové datové soubory délku, šířku a časové proměnné.

Profil

• Profil -- je soubor měření všech provedených najednou, v jedné zeměpisné šířce, ale ve více než jedné hloubce (nebo výška) . Soubor údajů může být souborem těchto profilů, například 7 profilů z různých míst. Tento cdm\_data\_type neznamená žádné logické spojení mezi žádným z profilů.

• Jedna z proměnných (například profil\_číslo) MUSÍ mít variabilní atribut cf\_role=profile\_id pro identifikaci proměnné, která jednoznačně identifikuje profily.

  <att name="cf\\_role">profile\\_id</att>  

Pokud žádná jiná proměnná není vhodná, zvažte použití časové proměnné.

cdm\_profile\_variables

• Soubor údajů MUSÍ obsahovat globální atribut cdm\_profile\_variables , kde hodnota je čárkou oddělený seznam proměnných, které mají informace o každém profilu. Pro daný profil musí být hodnoty těchto proměnných konstantní. Například,

  <att name="cdm\\_profile\\_variables">profile\\_number,time,latitude,longitude</att>

Seznam MUSÍ obsahovat proměnnou cf\_role=profile\_id a všechny další proměnné s informacemi o profilu, a čas, zeměpisná šířka a délka. Seznam nebude nikdy zahrnovat nadmořskou výšku, hloubku ani žádné proměnné pozorování.  

\[ Opinion: cdm\_data\_type=Profil by měl být používán zřídka. V praxi je daný datový soubor obvykle buď TimeSeriesProfile (profily v pevné poloze) nebo TrajektoryProfile (profily podél trajektorie) , a to by mělo být řádně identifikováno jako takové. \]

Časové řady

• Časové řady -- je sled měření (Například teplota mořské vody) 1 písm. a) a čl. (nebo výška) Umístění. (Ber to jako "station.") Databáze může být sbírkou těchto TimeSeries, například posloupnost z každé ze 3 různých míst.
• Jedna z proměnných (například stanice\_id) MUSÍ mít variabilní atribut cf\_role=timeseries\_id pro identifikaci proměnné, která jednoznačně identifikuje stanice.

  <att name="cf\\_role">timeseries\\_id</att>

cdm\_timeseries\_variables

• Soubor údajů MUSÍ obsahovat globální atribut cdm\_timeseries\_variables , kde hodnota je čárkou oddělený seznam proměnných, které mají informace o každé stanici. Pro danou stanici musí být hodnoty těchto proměnných konstantní. Například,

  <att name="cdm\\_timeseries\\_variables">station\\_id,station\\_type,latitude,longitude</att>

Seznam MUSÍ obsahovat proměnnou cf\_role=timeseries\_id a všechny ostatní proměnné s informacemi o stanici, která téměř vždy zahrnuje zeměpisnou šířku a délku (a výška nebo hloubka, pokud jsou přítomny) . Seznam nikdy nebude obsahovat časové nebo pozorovací proměnné.

• Pro některé kotvené bóje může mít datový soubor dvě sady proměnných zeměpisné šířky a délky:
  1. Jeden pár hodnot zeměpisné šířky a délky, které jsou konstantní (tj. pevné umístění kotviště) . In ERDDAP™ , dát tyto proměnné destinationName s zeměpisné šířky a délky a zahrnout tyto proměnné do seznamu cdm\_timeseries\_variables.
  2. Přesné hodnoty zeměpisné šířky a délky spojené s každým pozorováním. In ERDDAP™ , dát tyto proměnné různé destinationName án (např. přesné a přesné Lon) a nezahrnují tyto proměnné do seznamu cdm\_timeseries\_variables. Důvodem je: z teoretického hlediska soubor dat DSG TimeSeries, zeměpisná šířka a délka (a výška nebo hloubka, pokud jsou přítomny) Umístění stanice musí být konstantní.

TimeSeriesProfil

• TimeSeriesProfil -- je pro sekvenci profilů pořízených v jednom, pevném, zeměpisné poloze. Každý profil je soubor měření provedených ve více výškách nebo hloubkách. Databáze může být sbírkou těchto TimeSeriesProfiles, například sled profilů pořízených na každém z 12 různých míst.
• Jedna z proměnných (například stanice\_id) MUSÍ mít variabilní atribut cf\_role=timeseries\_id pro identifikaci proměnné, která jednoznačně identifikuje stanice.

    <att name="cf\\_role">timeseries\\_id</att>

• Jedna z proměnných (například profil\_číslo) MUSÍ mít variabilní atribut cf\_role=profile\_id pro identifikaci proměnné, která jednoznačně identifikuje profily.

  <att name="cf\\_role">profile\\_id</att>  

  (Zadaný profil\_id musí být jedinečný pouze pro dané časové řady\_id.) Pokud žádná jiná proměnná není vhodná, zvažte použití časové proměnné.
• Databáze MUSÍ obsahovat globálníAttribute cdm\_timeseries\_variables, kde hodnota je čárkou oddělený seznam proměnných, které mají informace o každé stanici. Pro danou stanici musí být hodnoty těchto proměnných konstantní. Například,

  <att name="cdm\\_timeseries\\_variables">station\\_id,station\\_type,latitude,longitude</att>

Seznam MUSÍ obsahovat proměnnou cf\_role=timeseries\_id a všechny ostatní proměnné s informacemi o stanici, která téměř vždy zahrnuje zeměpisnou šířku a délku. Seznam nikdy nebude zahrnovat čas, výšku, hloubku nebo jakékoli proměnné pozorování.

• Soubor údajů MUSÍ zahrnovat globálníAttribute cdm\_profile\_variables, kde hodnota je čárkou oddělený seznam proměnných, které mají informace o každém profilu. Pro daný profil musí být hodnoty těchto proměnných konstantní. Například,

  <att name="cdm\\_profile\\_variables">profile\\_number,time</att>

Seznam MUSÍ obsahovat proměnnou cf\_role=profile\_id a všechny další proměnné s informacemi o profilu, který téměř vždy obsahuje čas. Seznam nebude nikdy zahrnovat zeměpisnou šířku, délku, výšku, hloubku nebo jakékoli proměnné pozorování.

Trajektorie

• Trajektorie -- je sled měření na trajektorii (cesta prostorem a časem) (např. teplota moře\_voda\_teplota pořízené lodí při pohybu vodou) . Databáze může být sbírkou těchto trajektorií, například posloupnosti z každé ze 4 různých lodí.
• Jedna z proměnných (například ship\_id) Musí mít atribut cf\_role=trajektory\_id pro identifikaci proměnné, která jednoznačně identifikuje trajektorie.

  <att name="cf\\_role">trajectory\\_id</att>

cdm\_trajektory\_variables

• Soubor údajů MUSÍ obsahovat globální atribut cdm\_trajektory\_variables , kde hodnota je čárkou oddělený seznam proměnných, které mají informace o každé trajektorii. Pro danou trajektorii musí být hodnoty těchto proměnných konstantní. Například,

  <att name="cdm\\_trajectory\\_variables">ship\\_id,ship\\_type,ship\\_owner</att>

Seznam MUSÍ obsahovat proměnnou cf\_role=trajectory\_id a všechny další proměnné s informacemi o trajektorii. Seznam nebude nikdy zahrnovat čas, zeměpisnou šířku, délku nebo jakékoli proměnné pozorování.

TrajektorieProfile

• TrajektorieProfile -- je sekvence profilů na trajektorii. Databáze může být sbírkou těchto TrajectoryProfiles, například sled profilů pořízených 14 různými loděmi.
• Jedna z proměnných (například ship\_id) MUSÍ mít variabilní atribut cf\_role=trajektory\_id pro identifikaci proměnné, která jednoznačně identifikuje trajektorie.

  <att name="cf\\_role">trajectory\\_id</att>

• Jedna z proměnných (například profil\_číslo) MUSÍ mít variabilní atribut cf\_role=profile\_id pro identifikaci proměnné, která jednoznačně identifikuje profily.

  <att name="cf\\_role">profile\\_id</att>  

  (Zadaný profil\_id musí být jedinečný pouze pro danou trajektorii\_id.) Pokud žádná jiná proměnná není vhodná, zvažte použití časové proměnné.
• Soubor údajů MUSÍ zahrnovat globálníAttribute cdm\_trajektory\_variables, kde hodnota je čárkou oddělený seznam proměnných, které mají informace o každé trajektorii. Pro danou trajektorii musí být hodnoty těchto proměnných konstantní. Například,

  <att name="cdm\\_trajectory\\_variables">ship\\_id,ship\\_type,ship\\_owner</att>

Seznam MUSÍ obsahovat proměnnou cf\_role=trajectory\_id a všechny další proměnné s informacemi o trajektorii. Seznam nebude nikdy obsahovat proměnné související s profilem, čas, zeměpisná šířka, zeměpisná délka nebo jakékoli proměnné pozorování.

• Soubor údajů MUSÍ zahrnovat globálníAttribute cdm\_profile\_variables, kde hodnota je čárkou oddělený seznam proměnných, které mají informace o každém profilu. Pro daný profil musí být hodnoty těchto proměnných konstantní. Například,

  <att name="cdm\\_profile\\_variables">profile\\_number,time,latitude,longitude</att>

Seznam MUSÍ obsahovat proměnnou cf\_role=profile\_id a všechny další proměnné s informacemi o profilu, který téměř vždy zahrnuje čas, zeměpisnou šířku a délku. Seznam nebude nikdy zahrnovat nadmořskou výšku, hloubku ani žádné proměnné pozorování.

Ostatní

• Ostatní -- nemá žádné požadavky. Použijte jej, pokud datový soubor neodpovídá jedné z dalších možností, zejména pokud datový soubor neobsahuje zeměpisnou šířku, délku a časové proměnné.  

Související poznámky

• Všechny soubory EDDTable s cdm\_data\_typem jiným než "Ostatní" musí mít délku, šířku a časové proměnné.
• Datasety s profily MUSÍ mít proměnnou výšky, proměnnou hloubky nebo cdm\_altitude\_proxy proměnná.
• Pokud nemůžete vytvořit soubor dat v souladu se všemi požadavky na ideální cdm\_data\_type, použijte "Point" (který má několik požadavků) nebo "Ostatní" (který nemá žádné požadavky) Místo toho.
• Tyto informace používá ERDDAP™ různými způsoby, například, ale hlavně pro výrobu .nc Soubory CF ( .nc soubory, které odpovídají Contiguous Ragged Array Representations spojené s cdm\_data\_type) a .nc Soubory CFMA ( .nc soubory, které jsou v souladu s Multidimenzionální Array Reprezentations spojené s datovým souborem cdm\_data\_type) podle definice v Geometrie diskrétního odběru vzorků (DSG) kapitola CF úmluvy o metadatech, které byly dříve označovány jako "konvence o pozorování bodů CF."
• Tip: Pro tyto soubory dat je správné nastavení pro subsetVariables je obvykle kombinací všech proměnných uvedených v atributech cdm\_...\_variables. Například pro TimeSeriesProfile použijte cdm\_timeseries\_variables plus cdm\_profile\_variables.

contributor\_name

• ** contributor\_name ** (z ACDD standard metadat) je DOPORUČENÝ způsob identifikace osoby, organizace nebo projektu, který přispěl k tomuto datovému souboru (například původní tvůrce dat, před tím, než je tvůrce tohoto datového souboru přepracoval) . Například,

    <att name="contributor\\_name">NOAA OceanWatch - Central Pacific</att>  

Pokud se "sponzor" ve skutečnosti nevztahuje na datový soubor, vynechat tento atribut. Ve srovnání s creator\_name To je někdy více zaměřeno na zdroj financování.

contributor\_role

• ** contributor\_role ** (z ACDD standard metadat) je DOPORUČENÝ způsob určení úlohy contributor\_name . Například,

    <att name="contributor\\_role">Source of Level 2b data</att>  

Pokud se "sponzor" ve skutečnosti nevztahuje na datový soubor, vynechat tento atribut.

Sjezdy

• Sjezdy (z CF standard metadat) Velmi časté: (Může být požadováno v budoucnu.) Hodnota je čárkou oddělený seznam standardů metadat, které tento datový soubor sleduje. Například:

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

Společné úmluvy o metadatech používané v ERDDAP™ jsou:

• COARDS Sjezdy je prekurzor CF.
• Klima a předpovědi (CF) Sjezdy je zdrojem mnoha doporučených a požadovaných atributů v ERDDAP . Současná verze CF je označena jako "CF-1.6."
• The NetCDF Atributová úmluva pro Discovery datových souborů (ACDD) je zdrojem mnoha doporučených a požadovaných atributů v ERDDAP . Originální verze 1.0 ACDD (brilantní dílo Ethana Davise) , byl identifikován jako Unidata Dataset Discovery v1.0 Proud (od roku 2015) 1.3 verze ACDD je označena jako ACDD-1, 3 . Pokud vaše datové soubory používají Unidata Dataset Discovery v1.0, doporučujeme přepněte své soubory dat pro použití ACDD-1.3 .

Pokud se váš datový soubor řídí nějakým dodatečným standardem metadat, přidejte název do CSV seznamu v atributu Conventions.

coverage\_content\_type

• ** coverage\_content\_type ** (z ISO 19115 standard metadat) je DOPORUČENÝ způsob, jak určit typ roštových dat (v EDDGrid Soubory údajů) . Například,

<att name="coverage\\_content\\_type">modelResult</att>  

Jediné povolené hodnoty jsou pomocnéInformace, obraz, modelResult, fyzický Měření (výchozí hodnota při generování metadat podle ISO 19115) , kvalitaInformace, referenceInformace a tematickéKlasifikace. (Nepoužívej tuto tag pro soubory EDDTable.)

creator\_name

• ** creator\_name ** (z ACDD standard metadat) je DOPORUČENÝ způsob identifikace osoby, organizace nebo projektu (pokud ne konkrétní osoba nebo organizace) , nejzodpovědnější za tvorbu (nebo poslední přepracování) těchto údajů. Například,

<att name="creator\\_name">NOAA NMFS SWFSC ERD</att>  

Pokud byly údaje rozsáhle přepracovány (Například satelitní data z úrovně 2 do úrovně 3 nebo 4) , pak obvykle reprocesor je uveden jako tvůrce a původní tvůrce je uveden přes contributor\_name . Ve srovnání s projekt , To je pružnější, protože to může identifikovat osobu, organizaci, nebo projekt.

creator\_email

• ** creator\_email ** (z ACDD standard metadat) je DOPORUČENÝ způsob identifikace e-mailové adresy (správně upravený) který poskytuje způsob, jak kontaktovat tvůrce. Například,

<att name="creator\\_email">erd.data@noaa.gov</att>  

creator\_url

• ** creator\_url ** (z ACDD standard metadat) je RECOMMENDED způsob, jak identifikovat URL pro organizaci, která vytvořila soubor údajů, nebo URL s informacemi tvůrce o tomto datovém souboru (ale to je spíš účel infoUrl ) . Například,

<att name="creator\\_url">https://www.pfeg.noaa.gov</att>  

date\_created

• ** date\_created ** (z ACDD standard metadat) je způsob, jak zjistit datum, kdy byly údaje poprvé vytvořeny (například zpracované do této formy) , ve formátu ISO 8601. Například,

<att name="date\\_created">2010-01-30</att>  

Pokud jsou údaje pravidelně přidávány do souboru údajů, je to první datum, kdy byly k dispozici původní údaje.

date\_modified

• ** date\_modified ** (z ACDD standard metadat) je DOPORUČENÝ způsob, jak určit datum poslední úpravy údajů (například při opravě chyby nebo při přidání nejnovějších údajů) , ve formátu ISO 8601. Například,

<att name="date\\_modified">2012-03-15</att>  

date\_issued

• ** date\_issued ** (z ACDD standard metadat) je DOPORUČENÝ způsob, jak určit datum, kdy byly údaje poprvé zpřístupněny ostatním, například ve formátu ISO 8601 2012-03-15. Například,

<att name="date\\_issued">2010-07-30</att>  

Například soubor údajů může mít date\_created ze dne 2010-01-30, ale byl zveřejněn pouze 2010-07-30. date\_issued je méně často používán než date\_created a date\_modified . Pokud date\_issued je vynechán, předpokládá se, že je stejný jako date\_created .

globální drawLandMask

• ** drawLandMask ** -- Jedná se o VOLITELNÝ globální atribut používaný ERDDAP™ (a žádné standardy metadat) který určuje výchozí hodnotu pro volbu "Draw Land Mask" ve formuláři Make A Graph ( * datasetID * .graph) a pro parametr &.land v URL žádající mapu dat. Například,

<att name="drawLandMask">over</att>  

Viz drawLandMask přehled .

featureType

• ** featureType ** (z CF standard metadat) je ignorován a/nebo placen. Pokud je datový soubor cdm\_data\_type je vhodné, ERDDAP™ automaticky ji použije k vytvoření featureType atribut. Takže není třeba, abys to přidal.

Jestliže však užíváte EDDTableFromNcCFFiles vytvořit soubor souborů, které budou následovat CF Geometrie diskrétního odběru vzorků (DSG) standardní , soubory musí mít sám featureType správně definované, takže ERDDAP™ může správně přečíst soubory. To je součástí požadavků CF DSG pro tento typ souboru.  

historie

• historie (z CF a ACDD Standardy metadat) je globální atribut RECOMMENDED multi-line String s řádkou pro každý proces, kterým byly údaje podrobeny. Například,

<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>

• V ideálním případě má každá řada ISO 8601:2004 (E) Zformátované datum+timeZ (např. 2011-08-05T08:55:02Z) následuje popis zpracovatelského kroku.
• ERDDAP™ vytvoří to, pokud už neexistuje.
• Pokud už existuje, ERDDAP™ připojí nové informace ke stávajícím informacím.
• historie je důležitá, protože umožňuje klientům vrátit se zpět k původnímu zdroji dat.

infoUrl

• ** infoUrl ** je požadovaný globální atribut s URL webové stránky s více informacemi o tomto datovém souboru (obvykle na internetových stránkách zdrojové instituce) . Například,

<att name="infoUrl">http://www.globec.org/</att>

• Buď je soubor globální zdrojAtributy nebo jeho globální< addAttributes > Musí obsahovat tento atribut.
• infoUrl je důležité, protože umožňuje klientům dozvědět se více o datech z původního zdroje.
• ERDDAP™ zobrazí odkaz na infoUrl o formuláři pro přístup k datům datového souboru ( * datasetID * .html) , Vytvořit graf webové stránky ( * datasetID * .graph) , a další webové stránky.
• Pokud má URL dotaz (po "?") , to musí být již % zakódováno . Musíte zakódovat speciální znaky do omezení (jiné než počáteční "&" a hlavní '=' , pokud existuje) do formuláře %HH, kde HH je 2 číslice hexadecimální hodnota znaku. Obvykle stačí převést několik interpunkčních znaků: % na% 225, & na% 226, "na% 222,<do% 3C, = do% 3D, > do% 3E, + do% 2B, | do% 7C, \[ do % 5B, \] do %5D, prostor na%20, a převést všechny znaky nad #127 do jejich UTF-8 formuláře a pak procento enkódovat každý byte UTF-8 formuláře do%HH formátu (Požádat programátora o pomoc) . Například stationID Podvozky a jejich části a součásti se stává & stationID % 3E=% 2241004%22 Procentuální kódování je obecně nutné, když přístup ERDDAP přes jiný software než prohlížeč. Prohlížeče obvykle zvládnout procento kódování pro vás. V některých situacích, musíte procent enkódovat všechny znaky jiné než A-Za-z0-9\_-!.~ ' () \*, ale stále nezakódujte počáteční "&" nebo hlavní '=' . Programovací jazyky mají k tomu nástroje (např. viz Java 's java.net.URLEncoder
  a Java Skript je [encodeURIComponent()] (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) ) a existují webové stránky, které pro vás tvoří procento enkódování/dekódování .
• Od datasets.xml je XML soubor, musíte také kódovat ALL '&', '<"a ">" v URL jako "&," "<' a '>' po procentu kódování.
• infoUrl je jedinečná pro ERDDAP . Není to ze standardu metadat.

instituce

• instituce (z CF a ACDD Standardy metadat) je požadovaný globální atribut s krátkou verzí názvu instituce, která je zdrojem těchto údajů (obvykle zkratka, obvykle<20 znaků). Například,

<att name="institution">NASA GSFC</att>

• Buď je soubor globální zdrojAtributy nebo jeho globální< addAttributes > Musí obsahovat tento atribut.
• ERDDAP™ zobrazí instituci pokaždé, když zobrazí seznam souborů údajů. Pokud je zde název instituce delší než 20 znaků, bude v seznamu souborů údajů viditelné pouze prvních 20 znaků (ale celá instituce může být vidět tím, že kurzor myši přes sousední "?" ikona) .
• Pokud přidáte instituci na seznam< categoryAttributes > v ERDDAP 's setup.xml soubor, uživatelé mohou snadno najít soubory dat ze stejné instituce prostřednictvím ERDDAP 'Search for Datasets by Category' na domovské stránce.

Klíčová slova

• Klíčová slova (z ACDD standard metadat) je seznam slov a krátkých frází, které jsou odděleny čárkou (například: GCMD Věda Klíčová slova ) které obecně popisují soubor údajů a nezakládají žádné jiné znalosti datového souboru (například pro oceánografická data zahrnují oceán) . Například,

<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>  

Od datasets.xml je XML dokument, znaky &,<, a > v atributu, jako jsou klíčová slova (např. znaky ve vědeckých klíčových slovech GCMD) musí být zakódováno jako &<, a > resp. Při načtení datového souboru ERDDAP ,

• "Země věda > " je přidána na začátek každého klíčového slova GCMD, které chybí.
• Klíčová slova GCMD jsou převedena na titulní případ (tj. první písmena jsou kapitalizována) .
• Klíčová slova jsou přeřazena do seřazeného pořadí a všechny nové znaky jsou odstraněny.  

keywords\_vocabulary

• ** keywords\_vocabulary ** (z ACDD standard metadat) je atribut DOPORUČENÉ: pokud se řídíte pokyny pro slova / fráze v atributu klíčová slova (například, GCMD věda Klíčová slova) , dát název tohoto pokynu sem. Například,

<att name="keywords\\_vocabulary">GCMD Science Keywords</att>  

licence

• licence (z ACDD standard metadat) je globální atribut STRONGLIE s licencí a/nebo omezeními používání. Například,

<att name="license">\\[standard\\]</att>

• Pokud " \[ standardní \] " se vyskytuje v hodnotě atributu, bude nahrazen standardem ERDDAP™ licence od<standardní značkaLicence> ERDDAP 's \[ tomcat \] /webapps/erddap/WEB-INF/classes/gov/noaa/pfel/erddap/util/messages.xml file.  

Metadata\_Conventions

• ** Metadata\_Conventions ** je ze zastaralých ACDD 1. 0 (který byl identifikován v Metadata\_Conventions jako " Unidata Dataset Discovery v1.0") Standard metadat. Hodnota atributu byla čárkou odděleným seznamem úmluv metadat použitých tímto datovým souborem. Pokud datový soubor používá ACDD 1.0, tento atribut je například STRONGLY RECOMMENDED,

<att name="Metadata\\_Conventions">COARDS, CF-1.6, Unidata Dataset Discovery v1.0</att>  

Ale... ERDDAP™ Nyní doporučujeme ACDD-1.3. Jestliže máte přepnul vaše soubory dat k použití ACDD-1.3 , použití Metadata\_Conventions STRONGLIE SLEVA: stačí použít [<Úmluva >] (#konvence) Místo toho.

processing\_level

• ** processing\_level ** (z ACDD standard metadat) je textový popis zpracování (například: Úroveň zpracování dat ze Země NASA Například úroveň 3) nebo úroveň kontroly jakosti (např. kvalita vědy) údajů. Například,

<att name="processing\\_level">3</att>  

projekt

• projekt (z ACDD standard metadat) je VOLITELNÝ atribut pro identifikaci projektu, kterého je datový soubor součástí. Například,

<att name="project">GTSPP</att>  

Pokud data nejsou součástí projektu, nepoužívejte tento atribut. Ve srovnání s creator\_name , to je zaměřeno na projekt (osoba nebo organizace, které se mohou účastnit více projektů) .

publisher\_name

• ** publisher\_name ** (z ACDD standard metadat) je DOPORUČENÝ způsob, jak identifikovat osobu, organizaci nebo projekt, který vydává tento datový soubor. Například,

<att name="publisher\\_name">JPL</att>  

Například, jste vydavatel, pokud jiná osoba nebo skupina vytvořen data a vy jste jen re-serving přes ERDDAP . Pokud se "vydavatel" ve skutečnosti nevztahuje na datový soubor, vynechat tento atribut. Ve srovnání s creator\_name , vydavatel pravděpodobně nijak významně neupravoval nebo znovu nezpracovával data; vydavatel jen dodává data do nového místa.

publisher\_email

• ** publisher\_email ** (z ACDD standard metadat) je DOPORUČENÝ způsob identifikace e-mailové adresy (správně formátovaný např. john\_smith@great.org) který poskytuje způsob, jak kontaktovat vydavatele. Například,

<att name="publisher\\_email">john\\_smith@great.org</att>  

Pokud se "vydavatel" ve skutečnosti nevztahuje na datový soubor, vynechat tento atribut.

publisher\_url

• ** publisher\_url ** (z ACDD standard metadat) je RECOMMENDED způsob, jak identifikovat URL pro organizaci, která zveřejnila soubor údajů, nebo URL s informacemi vydavatele o tomto souboru dat (ale to je spíš účel infoUrl ) . Například,

<att name="publisher\\_url">https://podaac.jpl.nasa.gov</att>  

Pokud se "vydavatel" ve skutečnosti nevztahuje na datový soubor, vynechat tento atribut.

real\_time

• ** real\_time ** je globální atribut String (není z žádné normy) uvádí, zda se jedná o datový soubor v reálném čase. Například,

<att name="real\\_time">true</att>  

Jestli je to lež (výchozí) , ERDDAP™ bude cache odpovědi na žádosti o typy souborů, kde celý soubor musí být vytvořen před ERDDAP™ může začít odesílat odpověď uživateli a znovu je používat po dobu cca 15 minut (např. .nc , . png) . Jestli je to pravda, ERDDAP™ nebude nikdy cache souborů odezvy a vždy vrátí nově vytvořené soubory.

sourceUrl atribut

• ** sourceUrl ** je globální atribut s URL zdroje dat. Například,

<att name="sourceUrl">https://opendap.co-ops.nos.noaa.gov/ioos-dif-sos/SOS</att>  

(ale dát to všechno na jeden řádek)

• ERDDAP™ obvykle vytváří tento globální atribut automaticky. Dvě výjimky jsou EDDTableFrom Hyrax Soubory a EDDTableFromThreddsFiles.
• Pokud jsou zdrojem místní soubory a soubory byly vytvořeny vaší organizací, použijte

    <att name="sourceUrl">(local files)</att>

• Pokud je zdrojem místní databáze a data byla vytvořena vaší organizací, použijte

    <att name="sourceUrl">(local database)</att>

• sourceUrl je důležité, protože umožňuje klientům vrátit se zpět k původnímu zdroji dat.
• sourceUrl je jedinečná pro ERDDAP . Není to ze standardu metadat.

standard\_name\_vocabulary

• ** standard\_name\_vocabulary ** (z ACDD standard metadat) je atribut DOPORUČENÉ k identifikaci názvu kontrolované slovní zásoby, ze které proměnné standard\_name Jsou obsazeny. Například,

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

pro verzi 77 Standardní tabulka názvu CF .  

subsetVariables

• ** subsetVariables ** (pouze pro soubory EDDTable) je globální atribut, který umožňuje zadat čárku oddělený seznam [< dataVariable >] (# Dataproměnná) destinationName s pro identifikaci proměnných s omezeným počtem hodnot (uvedl jiný způsob: proměnné, pro které má každá z hodnot mnoho duplikátů) . Například,

    <att name="subsetVariables">station\\_id, longitude, latitude</att>  

Pokud je tento atribut přítomen, bude mít datový soubor * datasetID * .subset webové stránky (a odkaz na něj na každém seznamu souborů údajů) což umožňuje uživatelům rychle a snadno vybrat různé podmnožiny dat.

• Pokaždé, když je soubor dat načten, ERDDAP zatížení a ukládání na disku stůl se všemi odlišnými () kombinace podskupiny Hodnoty proměnné. ERDDAP™ může číst, že subsetVariables stůl a velmi rychle jej zpracovat (zejména ve srovnání se čtením spousty datových souborů nebo získáním dat z databáze nebo jiné externí služby) .
• To umožňuje ERDDAP™ dělat 3 věci:
  1. Umožňuje ERDDAP™ vložit seznam možných hodnot do seznamu dropdownů na formulář Data Access, vytvořit grafickou webovou stránku a .subset webové stránky.
  2. Umožňuje ERDDAP™ nabídnout .subset webovou stránku pro tento datový soubor. Tato stránka je zajímavá, protože je snadné najít platné kombinace hodnot těchto proměnných, které pro některé datové soubory a některé proměnné je velmi, velmi těžké (téměř nemožné) . Pak všechny uživatelské požadavky pro odlišné () Podkategorie Proměnná data budou velmi rychlá.
  3. Pokud existuje požadavek uživatele, který odkazuje pouze na podmnožinu těchto proměnných, ERDDAP™ může rychle přečíst subsetVariables stůl a reagovat na žádost. To může ušetřit spoustu času a úsilí pro ERDDAP .
• Pořadí destinationName s určujete pořadí na * datasetID * .subset webová stránka, takže obvykle zadat nejdůležitější proměnné nejprve, pak nejméně důležité. Například pro datové soubory s daty časových řad pro několik stanic můžete použít například:

      <att name="subsetVariables">station\\_id, longitude, latitude</att>  

tak, aby hodnoty byly tříděny podle stanice\_id.

• Samozřejmě, je to vaše volba, které proměnné zahrnout do subsetVariables seznam, ale navrhované použití je:

Obecně uveďte proměnné, pro které chcete ERDDAP™ Zobrazení seznamu možností pro stažení na datovém formuláři datového přístupu datového souboru (.html) a Make-A-Graf (.graph) webové stránky.

Obecně uveďte proměnné s informacemi o vlastnostech datového souboru (stanice, profily a/nebo trajektorie, zejména z cdm\_timeseries\_variables , cdm\_profile\_variables , cdm\_trajektory\_variables ) . Pro tyto proměnné existuje jen několik různých hodnot, takže dobře fungují se seznamem drop-down.

Nezahrnujte nikdy žádné datové proměnné spojené s jednotlivými pozorováními (např. čas, teplota, slanost, aktuální rychlost) v subsetVariables seznam. Existuje příliš mnoho různých hodnot pro tyto proměnné, takže seznam drop-down by bylo pomalé zatížení a je těžké pracovat s (nebo nepracuje) .

• Pokud je počet různých kombinací těchto proměnných větší než asi 1 000 000, měli byste zvážit omezení subsetVariables že jste určit snížit počet různých kombinací pod 1 000 000; jinak, * datasetID * .subset webové stránky mohou být generovány pomalu. V extrémních případech nesmí soubor údajů zadávat ERDDAP™ protože generování seznamu odlišných kombinací využívá příliš mnoho paměti. Pokud ano, musíte odstranit některé proměnné z subsetVariables seznam.
• Pokud je počet různých hodnot jedné podmnožiny větší než 20 000, měli byste zvážit, že do seznamu subsetVariables ; jinak, to trvá dlouhou dobu, aby předal * datasetID * .subset, * datasetID * .graf a * datasetID * .html webové stránky. Také, na Mac, je velmi těžké, aby výběry ze seznamu drop down s více než 500 položek, protože chybí scroll bar. Kompromisem je: odstranění proměnných ze seznamu, kdy uživatelé pravděpodobně nevyberou hodnoty ze seznamu dolů.
• Měli byste otestovat každý soubor dat, abyste zjistili, zda subsetVariables nastavení je v pořádku. Pokud je zdrojový datový server pomalý a trvá to příliš dlouho (nebo selže) stáhnout data, buď snížit počet určených proměnných nebo odstranit subsetVariables globální atribut.
• Subset Proměnné jsou velmi užitečné. Takže pokud je váš datový soubor vhodný, vytvořte prosím subsetVariables atribut.
• EDDTableFrom SOS automaticky přidává

      <att name="subsetVariables">station\\_id, longitude, latitude</att>  

při vytvoření datového souboru.

• Možné varování: pokud uživatel používá * datasetID * .subset webová stránka vybere hodnotu, která má kočárReturn nebo nový znak, * datasetID * .subset selže. ERDDAP™ nemůže pracovat kolem tohoto problému, protože některé HTML detaily. V každém případě je téměř vždy dobrý nápad odstranit kočárReturn a nové znaky z dat. Chcete-li vám pomoci vyřešit problém, pokud EDDTable. subsetVariables Metoda DataTable v ERDDAP detekuje hodnoty dat, které způsobí potíže, e-mailem varování se seznam urážlivých hodnot na e-mail Všechno Pro e-mailové adresy uvedené v setup.xml. Tak víte, co je třeba napravit.
• Předvyrobené podskupinové tabulky. Normálně, když ERDDAP™ načítá soubor údajů, požaduje odlišné () podmnožina proměnných datové tabulky ze zdroje dat, jen přes normální požadavek na data. V některých případech nejsou tato data dostupná ze zdroje dat nebo jejich získání ze zdroje dat může být na serveru datového zdroje obtížné. Pokud ano, můžete poskytnout tabulku s informacemi v .json nebo .csv soubor se jménem tomcat / content/ erddap/ subset/ * datasetID * .json (nebo .csv) . Pokud je přítomen, ERDDAP™ bude číst jednou při načtení datového souboru a používat jej jako zdroj podmnožinových dat.
• Pokud dojde k chybě při jejím čtení, soubor souborů selže v načtení.
• Musí mít stejné názvy sloupců. (například stejný případ) jako< subsetVariables >, ale sloupce mohou být v libovolném pořadí.
• Může mít navíc sloupce (budou odstraněny a nově uvolněné řádky budou odstraněny) .
• Chybějící hodnoty by měly chybět (není falešný čísla jako -99) .
• .json soubory může být trochu těžší vytvořit, ale vypořádat se s Unicode znaky dobře. .json soubory jsou snadno vytvořit, pokud je vytvořit s ERDDAP .
• .csv soubory jsou snadno pracovat s, ale vhodné pouze pro ISO 8859-1 znaků. .csv soubory MUSÍ mít jména sloupců v prvním řádku a data v následujících řádcích.
• Pro velké soubory dat nebo kdy< subsetVariables > je chybně konfigurována, tabulka kombinací hodnot může být dostatečně velká, aby způsobila příliš mnoho dat nebo chyby OutOfMemory. Řešením je odstranit proměnné ze seznamu< subsetVariables > pro které existuje velký počet hodnot, nebo odstranit proměnné podle potřeby, dokud velikost této tabulky není přiměřená. Bez ohledu na chybu, části ERDDAP™ které subsetVariables systém nefunguje dobře (např., webové stránky se načítají velmi pomalu) když je příliš mnoho řádků (např. více než milion) v tom stole.
• subsetVariables nemá nic společného s určením, které proměnné mohou uživatelé používat v omezeních, tj. jak mohou uživatelé požadovat podmnožiny datového souboru. ERDDAP™ vždy umožňuje omezení odkazovat na některou z proměnných.

Časové jednotky

Čas a časové razítko sloupce by měly mít ISO 8601:2004 (E) Zformátované datum+čas Z řetězce (např. 1985-01-31T15:31:00Z) .  

shrnutí

• shrnutí (z CF a ACDD Standardy metadat) je požadovaný globální atribut s dlouhým popisem datového souboru (obvykle<500 znaků). Například,

<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>

• Buď je soubor globální zdrojAtributy nebo jeho globální< addAttributes > Musí obsahovat tento atribut.
• shrnutí je velmi důležité, protože umožňuje klientům přečíst popis datového souboru, který má více informací než název, a tím rychle pochopit, co je datový soubor.
• Poradenství: napište shrnutí, aby bylo možné popsat datový soubor náhodné osobě, se kterou se setkáte na ulici nebo kolegovi. Nezapomeňte zahrnout Pět W a jedna H. : Kdo vytvořil soubor dat? Jaké informace byly shromážděny? Kdy byly shromážděny údaje? Kde ho sebrali? Proč byl vybrán? Jak byla shromážděna?
• ERDDAP™ zobrazí souhrn ve formuláři pro přístup k datům datového souboru ( * datasetID * .html) , Vytvořit graf webové stránky ( * datasetID * .graph) , a další webové stránky. ERDDAP™ souhrn používá při vytváření dokumentů FGDC a ISO 19115.

testOutOfDate

• ** testOutOfDate ** (volitelný ERDDAP - specifický atribut globálních metadat, nikoli z žádného standardu) specifikuje zjednodušujícím způsobem, kdy jsou data pro datový soubor v reálném čase považována za zastaralá, specifikovaná jako now- nJednotky Například: now- 2 dny pro data, která se obvykle objevují 24-48 hodin po časové hodnotě. Pro předpověď dat použijte nyní + nJednotky , například nyní+6dny pro předpověď dat, která jsou maximálně 8d v budoucnu. (Viz now- nJednotky Popis syntaxe .) Pokud je maximální časová hodnota datového souboru čerstvější než stanovená doba, považuje se datový soubor za aktuální. Je-li maximální časová hodnota starší než stanovená doba, považuje se datový soubor za aktuální. Pro zastaralé datové soubory existuje pravděpodobně problém se zdrojem dat, takže ERDDAP™ není schopen získat přístup k údajům z novějších časových bodů.

The testOutOfDate hodnota je zobrazena jako sloupec ve sloupci allDatasets Soubor údajů ve Vašem ERDDAP . Používá se také k výpočtu indexu OutOfDate, což je další sloupec v allDatasets Soubor dat. Pokud index je<1, datový soubor se považuje za aktuální. Pokud index je<=1, datový soubor se považuje za zastaralý. Pokud index je<=2 je datový soubor považován za velmi zastaralý.

The testOutOfDate hodnota je také použita ERDDAP™ generovathttps://yourDomain/erddap/outOfDateDatasets.htmlwebová stránka ( příklad ) který ukazuje soubory údajů, které mají< testOutOfDate > značky, s datovými soubory zařazenými podle toho, jak jsou zastaralé. Pokud změníte typ souboru (od .html do .csv, .jsonlCSV , .nc , .tsv , ...) , můžete získat tyto informace v různých formátech souborů.

Pokud je to možné, GenerovatDatasetsXml přidává a testOutOfDate atribut globální addAttributes datového souboru. Tato hodnota je návrh založený na informacích dostupných pro GenerateDatasetsXml. Pokud hodnota není vhodná, změňte ji.

"Ven-of-date" zde je velmi odlišné od [<reload EveryNMinutes >] (# reload everynminutes) , který se zabývá tím, jak aktuální ERDDAP Je to znalost datového souboru. The< testOutOfDate > systém předpokládá, že ERDDAP Znalost datového souboru je aktuální. K otázce< testOutOfDate > řešení je: zdá se, že je něco špatně se zdrojem dat, což způsobuje, že novější údaje nejsou přístupné ERDDAP ?

název

• název (z CF a ACDD Standardy metadat) je požadovaný globální atribut s krátkým popisem datového souboru (obvykle<= 95 znaků). Například,

<att name="title">VIIRSN Level-3 Mapped, Global, 4km, Chlorophyll a, Daily</att>

• Buď je soubor globální zdrojAtributy nebo jeho globální< addAttributes > Musí obsahovat tento atribut.
• název je důležitý, protože každý seznam souborů dat předložených ERDDAP (jiné než výsledky hledání) uvádí data v abecedním pořadí podle názvu. Takže pokud chcete určit pořadí souborů dat, nebo mít některé soubory souborů seskupené dohromady, musíte vytvořit tituly s ohledem na to. Mnoho seznamů souborů údajů (například v reakci na vyhledávání kategorií) , Zobrazit podmnožinu celého seznamu a v jiném pořadí. Název každého datového souboru by tedy měl zůstat sám.
• Pokud název obsahuje slovo "OCHRANA" (všechna velká písmena) , pak datový soubor dostane nižší pořadí při vyhledávání.  

< axisVariable >

• [ ** < axisVariable > ** ] (#oxisvariable) se používá k popisu rozměru (také nazývané "osa") . Pro EDDGrid Soubory údajů, jeden nebo více axisVariable Štítky jsou povinné a všechny dataVariable án vždy sdílet / používat všechny proměnné osy. ( Proč? Co když ne? )
  Pro každý rozměr datových proměnných musí existovat proměnná osy. Proměnné osy MUSÍ být specifikovány v pořadí, v jakém je datové proměnné používají. (EDDTable soubory nelze použít< axisVariable > značky.) Příkladem je:

  <axisVariable>
      <sourceName\>MT</sourceName>
      <destinationName\>time</destinationName>
      <addAttributes>
        <att name="units">days since 1902-01-01T12:00:00Z</att>
      </addAttributes>
  </axisVariable>

< axisVariable > podporuje tyto podtagy:

< sourceName \>

• [< sourceName \>] (#zdrojové jméno) -- název datového zdroje proměnné. To je jméno, které ERDDAP™ použije se při požadavku na údaje ze zdroje údajů. To je jméno, které ERDDAP™ bude hledat, kdy jsou data vrácena ze zdroje dat. Tohle je případ citlivý. To je nutné.

< destinationName \>

• [< destinationName \>] (Název místa určení) je název proměnné, která bude zobrazena a použita ERDDAP™ uživatelé.
  • Tohle je volitelné. Pokud chybí, sourceName používá se.
  • To je užitečné, protože umožňuje změnit záhadné nebo podivné sourceName .
  • destinationName je případ citlivý.
  • destinationName MUSÍME začít písmenem (A-Z, a-z) a MUSÍ následovat 0 nebo více znaků (A-Z, a-z, 0-9 a \_) . ('-' bylo dovoleno předtím ERDDAP™ verze 1.10.) Toto omezení umožňuje, aby názvy os proměnných byly stejné v ERDDAP™ , ve souborech odpovědí a ve všech softwarech, kde budou tyto soubory použity, včetně programovacích jazyků (jako Python , Matlab a Java Skript) kde existují podobná omezení pro názvy proměnných.
  • In EDDGrid datové soubory, zeměpisná délka, zeměpisná šířka, výška, hloubka a čas proměnné osy jsou zvláštní.  

axisVariable <addAttributes>

• [< addAttributes >] (#variable-addattributes) definuje VOLITELNOU sadu atributů ( název = hodnota ) které jsou přidány do atributů zdroje pro proměnnou, aby se kombinované atributy pro proměnnou. Pokud proměnná je zdrojAtributy nebo< addAttributes > zahrnují scale\_factor nebo add\_offset atributy, jejich hodnoty budou použity k vybalení dat ze zdroje před odesláním klientovi (výsledek Hodnota = zdroj Hodnota \* scale\_factor + add\_offset ) . Vybalená proměnná bude stejného datového typu (například plovák) jako scale\_factor a add\_offset hodnoty.  

< dataVariable >

• [ ** < dataVariable > ** ] (# Dataproměnná) je požadováno (pro téměř všechny datové soubory) Štítek uvnitř<Soubor údajů > značka, která se používá k popisu datové proměnné. Musí být 1 nebo více případů této značky. Příkladem je:

  <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 > podporuje tyto podtagy:

< sourceName >

• [< sourceName >] (#zdrojové jméno) -- název datového zdroje proměnné. To je jméno, které ERDDAP™ použije se při požadavku na údaje ze zdroje údajů. To je jméno, které ERDDAP™ bude hledat, kdy jsou data vrácena ze zdroje dat. Tohle je případ citlivý. To je nutné.

Skupiny

CF přidala podporu pro skupiny s CF v1.8. Od ~2020, NetCDF nástroje podpory uvedení proměnných do skupin ve .nc Složka. V praxi to znamená, že proměnné mají dlouhý název, který identifikuje skupinu (án) a název proměnné, například skupina1a/group2c/varName ). ERDDAP™ podporuje skupiny převodem "/" v proměnné< sourceName > do "\_" je v proměnné< destinationName > například skupina1a\_group2c\_varName . (Když to vidíte, měli byste si uvědomit, že skupiny nejsou nic víc než syntaxní sjezd.) Pokud jsou proměnné uvedeny v ERDDAP™ , Všechny proměnné ve skupině se objeví společně, napodobující základní skupinu. \[ Pokud ERDDAP™ , zejména GenerateDatasets Xml, nevystupuje tak dobře, jak by to šlo se zdrojovými soubory, které mají skupiny, prosím, odeslat vzorek soubor Chrisovi. John at noaa.gov . \]

Databáze EDDTableFromFoles mohou používat speciálně kódované pseudo sourceName s definovat nové datové proměnné, např. pro podporu globálního atributu jako datové proměnné. Viz Tato dokumentace .

HDF Struktura

Začneme s ERDDAP™ v2.12 EDDGrid FromNcFiles a EDDGrid FromNcFiles Vybalené mohou číst data z "struktur" v .nc 4 a .hdf 4 soubory. Pro identifikaci proměnné, která je ze struktury,< sourceName > musí používat formát: FullStructureName | Název člena , například skupina1/myStruct | Můj pane.

Název zdroje pevné hodnoty

V souboru EDDTable, pokud chcete vytvořit proměnnou (s jedinou pevnou hodnotou) který není ve zdrojovém souboru, použijte:

    <sourceName>=*fixedValue*</sourceName>  

Prvotní rovná se značka říká ERDDAP™ to a fixed Hodnota bude následovat.

• Pro číselné proměnné musí být pevná hodnota jedinou konečnou hodnotou nebo NaN (necitlivé případy, např. \=NaN) .
• Pro proměnné String musí být pevná hodnota jednoduchá, String ve stylu JSON (se speciálními znaky utekl s \ znaky) , např. \="Můj \"Special\" String" .
• Pro proměnnou časového razítka uveďte pevnou hodnotu jako číslo v "seconds since 1970-01-01T00:00:00Z" a použití jednotky=sekundy od 1970-01-01T00:00:00Z .

Ostatní značky pro< dataVariable > pracovat jako by to byla pravidelná proměnná. Například vytvořit proměnnou zvanou nadmořská výška s pevnou hodnotou 0,0 (plavat) , použití:

<sourceName>=0</sourceName>
<destinationName\>altitude</destinationName>
<dataType>float</dataType>

Pro neobvyklé situace můžete dokonce určit actual\_range addAttribute, který přepíše očekávané hodnoty destinationMin a destinationMax (což by se jinak rovnalo pevné Hodnota) .  

Název zdroje skriptu/zadané proměnné

Začneme s ERDDAP™ v2.10, v an EDDTableFromFoles , EDDtableFromDatabase nebo EDDTableFromFileNames Soubor údajů,< sourceName > může být výraz (rovnice, která hodnotí jedinou hodnotu) , pomocí formátu

    <sourceName>=*expression*</sourceName>  

nebo scénář (série příkazů, které vrací jedinou hodnotu) , pomocí formátu

    <sourceName>=*script*</sourceName>  

ERDDAP™ spoléhá na Projekt Apache Java Jazyk výrazu (JEXL) (licence: Apač ) vyhodnotit výrazy a spustit skripty. Výpočet pro danou novou proměnnou se provádí v rámci jednoho řádku výsledků, opakovaně pro všechny řádky. Výrazy a skripty používají Java - a Java Syntaxe podobná skriptu a může použít některý z provozovatele a metody, které jsou zabudovány do JEXL . Skripty mohou také používat metody (funkce) z těchto tříd:

• Kalendář2 , což je obal pro některé statické, časové a kalendářové metody v com.cohort.util.Calendar2 ( licence ) . Například, Kalendář2.parseToEpochSecond ( zdrojTime, datum TimeFormat ) bude zkoumat zdroj Časový řetězec přes datumTimeFormat řetězec a vrátit "seconds since 1970-01-01T00:00:00Z" (epochsekundární) Dvojitou hodnotu.
• Matematika , což je obal pro téměř všechny statické, matematicky související metody v Java.lang. Matematika . Například, Math.atan2 ( y, x ) přijímá obdélníkové souřadnice (y, x) a vrací polární souřadnice (pole dvojníků s \[ r, theta \] ) .
• Matematika2 , což je obal pro téměř všechny statické matematicky související metody v com.cohort.util. Matematika2 ( licence ) . Například, Matematika 2. kolo ( d, nPlaces ) bude zaokrouhlit d na uvedený počet číslic vpravo od desetinné hodnoty.
• String, který vám umožní přístup ke všem statickým metodám souvisejícím se stringem Java.lang. String . String objects in ERDDAP™ výrazy a skripty mohou použít některý z jejich souvisejících Java metody, jak je popsáno v java.lang. Provázková dokumentace. Například String.valueOf (d) změní dvojitou hodnotu d na řetězec (i když můžete také použít ""+d) .
• String2color , který je obalem pro většinu statických, String- a pole souvisejících metod v com.cohort.util.String2 ( licence ) . Například String2 .z eropad ( číslo, nDigits ) přidá 0 nalevo od čísla String tak, aby celkový počet číslic byl nDigits (např. String2 .z eropad ("6," 2) vrátí "06") .
• řádek , který má nestatické metody pro přístup k datům z různých sloupců v aktuálním řádku tabulky zdrojových dat. Například řádek.sloupecString ("rok") čte hodnotu ze sloupce "rok" jako String, zatímco řádek. sloupec Int ("rok") čte hodnotu ze sloupce "rok" jako celé číslo.

Z bezpečnostních důvodů nemohou výrazy a skripty používat jiné třídy než ty 6. ERDDAP™ vymáhá toto omezení vytvořením výchozí černé listiny (které černé listy všechny třídy) a pak bílý seznam (který výslovně umožňuje 6 výše popsaných tříd) . Pokud potřebujete jiné metody a/nebo jiné třídy, abyste mohli pracovat, pošlete prosím své žádosti Chrisovi. John at noaa.gov .

Účinnost

Pro soubory EDDTableFromFoles je pouze velmi, velmi minimální (pravděpodobně není patrné) zpomalení žádostí o údaje z těchto proměnných. Pro EDDTableFromDatabase existuje obrovský trest za rychlost pro žádosti, které zahrnují omezení těchto proměnných (např. (&longitude0360>30&longitude0360)<40) protože omezení nelze přenést do databáze, takže databáze musí vrátit mnohem více dat do ERDDAP™ (který je velmi časově náročný) takže ERDDAP™ může vytvořit novou proměnnou a uplatnit omezení. Abych se vyhnul nejhoršímu případu (kde nejsou do databáze přenesena žádná omezení) , ERDDAP™ hodí chybovou zprávu, aby databáze nemusela vrátit celý obsah tabulky. (Pokud to chcete obejít, přidejte omezení ke sloupci non-skriptu, který bude vždy pravdivý, např. &time<3000-01-01.) Z tohoto důvodu, s EdDtableFromDatabase, je pravděpodobně vždy lepší vytvořit odvozený sloupec v databázi spíše než použít sourceName = popis ERDDAP .

Přehled, jak vyjádřit (Nebo skript) Používá se:

V reakci na žádost uživatele o tabulková data, ERDDAP™ získává data ze série zdrojových souborů. Každý zdrojový soubor vytvoří tabulku syrových (přímo ze zdroje) data. ERDDAP™ pak prochází tabulkou surových dat, řádek po řádku, a vyhodnotí výraz nebo skript jednou pro každý řádek, aby se vytvořil nový sloupec, který má tento výraz nebo skript jako sourceName .

GenerovatDatasetsXml

Všimněte si, že generovatDatasety Xml je zcela nevědomý, když je potřeba vytvořit proměnnou s< sourceName Ostatní výraz </ sourceName >. Musíte vytvořit proměnnou v datasets.xml ručně.

Příklady vyjádření:

Zde jsou některé kompletní příklady datových proměnných, které používají výraz pro vytvoření nového sloupce dat. Očekáváme, že tyto příklady (a jejich varianty) bude zahrnovat asi 95% využití všech získaných výrazů sourceName s.

Kombinace samostatných "datum" a "time" sloupce do jednotného časového sloupce:

    <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>

To sourceName výraz dělá nový "time" sloupec konkatováním Stringových hodnot z "datum" ( yyyy-MM-dd ) a "time" (HH:mm:ss) sloupce v každém řádku zdrojového souboru a přeměnou tohoto řetězce na "seconds since 1970-01-01" (epochsekundární) Dvojitou hodnotu.

Nebo kurz, budete muset přizpůsobit řetězec časového formátu se vypořádat s konkrétním formátem v každém souboru zdroj datum a čas sloupce, viz dokumentace časových jednotek .

Technicky vzato nemusíš používat Kalendář2.parseToEpochSecond () převést kombinované datum+čas na epochsekundy. Můžete prostě předat datum + čas String na ERDDAP™ a uveďte formát (např. yyyy-MM-dd 'T'HH:mm:ss'Z' přes atribut jednotek. Ale existují významné výhody pro převod do epochSekund -- zejména, EDDTableFromFoles pak může snadno sledovat rozsah časových hodnot v každém souboru a tak rychle rozhodnout, zda se podívat do daného souboru při reakci na žádost, která má časová omezení.

S tím souvisí potřeba vytvořit jednotný sloupec date+time ze zdroje se samostatným rokem, měsícem, datem, hodinou, minutou, sekundou. Řešení je velmi podobné, ale budete často muset nula-pad mnoho z polí, takže, například, měsíc (1 - 12) a datum (1 - 31) vždy mají 2 číslice. Zde je příklad s rokem, měsícem, datem:

    <sourceName>=Calendar2.parseToEpochSeconds(row.columnString("year") + 
        String2.zeroPad(row.columnString("month"), 2) + 
        String2.zeroPad(row.columnString("date"), 2), "yyyyMMdd")</sourceName>

S tím související problém je potřeba vytvořit jednotný sloupec zeměpisné šířky nebo délky kombinací dat v samostatném stupni, minutách a sekundách sloupce, každý uložen jako celá čísla. Například,

    <sourceName>=row.columnInt("deg") + row.columnInt("min")/60.0 + 
        row.columnInt("sec")/3660.0</sourceName>

Převod sloupce s názvem "lon" s hodnotami délky od 0 do 360° do sloupce nazvaného "loučení" s hodnotami od -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>

To sourceName výraz dělá nový sloupec "délka" převodem dvojité hodnoty ze sloupce "lon" v každém řádku zdrojového souboru (pravděpodobně s hodnotami 0 - 360) , A tím, že převést to na -180 na 180 dvojnásobek hodnoty.

Pokud místo toho chcete převést hodnoty výchozí délky -180 - 180° na 0 - 360°, použijte

    <sourceName>=Math2.angle0360(row.columnDouble("lon"))</sourceName>

Pojmenování dvou proměnných délky: Pokud bude mít datový soubor 2 proměnné délky, doporučujeme použít destinationName = délka pro proměnnou -180 - 180° a destinationName =longitude0360 (a dlouhý název=\"Longitude 0-360°") u proměnné 0 - 360°. To je důležité, protože uživatelé někdy používají Advanced Search k vyhledávání dat v rámci určitého rozsahu délky. Toto vyhledávání bude fungovat lépe, pokud má zeměpisná délka trvale -180 - 180° hodnot pro všechny datové soubory. Také geospantial\_lon\_min, geospatial\_lon\_max, Westernmost\_Easting a Easternmost\_Eastings globální atributy budou pak nastaveny konzistentním způsobem (s hodnotami délky -180 až 180°) ;

Převod sloupce s názvem "TempF" s hodnotami teploty ve stupni\_ F do sloupce s názvem "TempC" s teplotami ve stupních\_ 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>

To sourceName výraz dělá nový sloupec "tempC" převodem plovákového stupně\_ Hodnota F ze sloupce "TempF" v každém řádku zdrojového souboru do plovoucího stupně\_ Hodnota C.

Všimněte si, že váš datový soubor může mít jak původní teplotu F proměnná a nová teplota C proměnná tím, že má jinou proměnnou s

    <sourceName>tempF</sourceName>

Převod "rychlost" a "směr" sloupců do dvou sloupců s u,v komponenty

• Pro vytvoření proměnné U použijte

    <sourceName>=row.columnFloat("speed") \\* Math.cos(row.columnFloat("direction"))</sourceName>

• Pro vytvoření proměnné v použijte

    <sourceName>=row.columnFloat("speed") \\* Math.sin(row.columnFloat("direction"))</sourceName>

Nebo, vzhledem k u, v:

• K vytvoření proměnné rychlosti použijte

    <sourceName>=Math.atan2(row.columnDouble("v"), row.columnDouble("u"))\\[0\\]</sourceName>

• Pro vytvoření směrové proměnné použijte

    <sourceName>=Math.toDegrees(Math.atan2(row.columnDouble("v"), row.columnDouble("u"))\\[1\\])</sourceName>

Příklad skriptu:

Zde je příklad použití skriptu, nejen výraz, jako sourceName . Očekáváme, že scénáře, na rozdíl od výrazů, nebudou potřeba často. V tomto případě je cílem vrátit chybějící hodnotu non-NaN (- 99) pro hodnoty teploty mimo určitý rozsah. Všimněte si, že skript je část za "=".

    <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>

Tvrdá vlajka

Pokud změníte výraz nebo skript definovaný v sourceName , musíte nastavit Tvrdá vlajka pro datový soubor, takže ERDDAP™ smaže všechny cachované informace pro datový soubor a znovu přečte každý datový soubor (pomocí nového výrazu nebo skriptu) příště nabije soubor dat. Alternativně můžete použít DasDds což odpovídá nastavení tvrdé vlajky.

Procentuální kód

To je jen vzácně relevantní: Protože výrazy a scénáře jsou napsány v datasets.xml , což je XML dokument, musíte procent enkódovat<, \> a & znaky v výrazech a skriptech jako<, > a & .

Časté problémy

Běžný problém je, že vytvoříte proměnnou s sourceName = výraz ale výsledný sloupec dat má chybějící hodnoty. Případně některé řádky nového sloupce mají chybějící hodnoty a vy si myslíte, že by neměly. Základní problém je, že něco je špatně s výrazem a ERDDAP je převést tuto chybu na chybějící hodnotu. Abych vyřešil problém,

• Podívej se na ten výraz a uvidíš, jaký by mohl být problém.
• Podívejte se dovnitř. log.txt , která zobrazí první chybovou zprávu vygenerovanou během vytvoření každého nového sloupce.

Časté příčiny jsou:

• Použil jsi špatný případ. Výrazy a scénáře jsou případově citlivé.
• Vynechal jsi jméno třídy. Například, musíte použít Math.abs () , nejen svaly () .
• Nedělala jsi typ konverze. Například pokud je datovým typem parametru String a máte dvojí hodnotu, musíte převést dvojitou na String přes ""+d.
• Název sloupce ve výrazu neodpovídá přesně názvu sloupce v souboru (nebo jméno může být v některých souborech jiné) .
• Ve výrazu je chyba syntaxe (např. chybějící nebo extra ") ").

Pokud uvíznete nebo potřebujete pomoc, prosím uveďte podrobnosti a viz naše oddíl o získání dodatečné podpory .

< destinationName >

• [< destinationName >] (Název místa určení) -- název proměnné, která bude zobrazena a použita ERDDAP™ uživatelé.
  • Tohle je volitelné. Pokud chybí, sourceName používá se.
  • To je užitečné, protože umožňuje změnit záhadné nebo podivné sourceName .
  • destinationName je případ citlivý.
  • destinationName MUSÍME začít písmenem (A-Z, a-z) a MUSÍ následovat 0 nebo více znaků (A-Z, a-z, 0-9 a \_) . ('-' bylo dovoleno předtím ERDDAP™ verze 1.10.) Toto omezení umožňuje v ERDDAP™ , ve souborech odpovědí a ve všech softwarech, kde budou tyto soubory použity, včetně programovacích jazyků (jako Python , Matlab a Java Skript) kde existují podobná omezení pro názvy proměnných.
  • V datových souborech EDDTable zeměpisná délka, zeměpisná šířka, výška (nebo hloubka) , a čas datové proměnné jsou zvláštní.  

<údaje Typ>

• [<dataType>] (#datatyp) -- určuje datový typ pocházející ze zdroje. (V některých případech například při čtení dat ze souborů ASCII určuje, jak by měla být data pocházející ze zdroje uložena.)
  • To vyžadují některé typy souborů údajů a jiné je ignorují. Typy datových souborů, které to vyžadují pro jejich dataVariable jsou: EDDGrid FromXxxFiles, EDDTableFromXxxFiles, EDDTableFromM WFS , EDDTableFromNOS, EDDTableFrom SOS . Jiné typy souborů ignorují tuto značku, protože získávají informace ze zdroje.  
  • Platné hodnoty jsou některé z norem ERDDAP™ datové typy plus boolean (viz níže) . Názvy DataType jsou citlivé na případy.  

booleovské údaje

• "Boolean" je zvláštní případ.
• Vnitřní, ERDDAP™ nepodporuje booleánský typ, protože booleáni nemohou ukládat chybějící hodnoty a většina typů souborů nepodporuje booleans. Také, DAP nepodporuje booleany, takže neexistuje standardní způsob, jak se ptát na booleovské proměnné.
• Upřesnění "boolean" pro data Zadat datasets.xml způsobí uložení a zastoupení booleánských hodnot jako bajtů: 0=false, 1=true, 127= missing\_value .
• Uživatelé mohou určit omezení pomocí číselných hodnot (například "isAlive=1") .
• ERDDAP™ Správci někdy potřebují použít data "boolean" Zadat datasets.xml říct ERDDAP™ jak komunikovat se zdrojem dat (např. pro čtení booleánských hodnot z relační databáze a jejich převod na 0, 1, nebo 127) .  
• Pokud chcete změnit proměnnou dat z datového typu ve zdrojových souborech (například krátká) do některých dalších údajů Typ datového souboru (např. int) , Nepoužívejte<dataType> zadat, co chcete. (Pracuje pro některé typy souborů dat, ale ne pro jiné.) Místo toho:
  • Použití<dataType> zadat, co je v souborech (například krátká) .
  • V< addAttributes > pro proměnnou, přidat a scale\_factor atribut s novými údaji Typ (např. int) a hodnotu 1, například,

            <att name="scale\\_factor" type="int">1</att>  

dataVariable <addAttributes>

• [< addAttributes >] (#variable-addattributes) -- definuje soubor atributů ( název = hodnota ) které jsou přidány do atributů zdroje pro proměnnou, aby se kombinované atributy pro proměnnou. Tohle je volitelné. Pokud proměnná je zdrojAtributy nebo< addAttributes > zahrnují scale\_factor nebo add\_offset atributy, jejich hodnoty budou použity k vybalení dat ze zdroje před odesláním klientovi. Vybalená proměnná bude stejného datového typu (například plovák) jako scale\_factor a add\_offset hodnoty.

Proměnná<addAttributes>

• [ ** Variabilní Atributy / Proměnná< addAttributes > ** ] (#variable-addattributes) --< addAttributes > je VOLITELNÁ tag v rámci< axisVariable > nebo< dataVariable > tag, který se používá ke změně atributů proměnné.

  • ** Použít proměnné< addAttributes > změnit atributy proměnné. ** ERDDAP™ kombinuje atributy proměnné ze zdroje datového souboru (** zdrojAtributy ) a proměnná je addAttributes který definujete v datasets.xml (které mají přednost) k vytvoření proměnné " kombinovanéAtributy ** "což je co ERDDAP™ uživatelé vidí. Můžete tedy použít addAttributes redefinovat hodnoty zdrojových atributů, přidat nové atributy nebo odstranit atributy.
  • Viz [ ** < addAttributes > informace] (#addattributy) která se vztahuje na globální a variabilní < addAttributes > ** .
  • ERDDAP™ hledá a využívá mnoho z těchto atributů různými způsoby. Například, barevnéBar hodnoty jsou nutné, aby proměnná k dispozici přes WMS , tak, že mapy mohou být vyrobeny s konzistentní barvyBars.
  • Zeměpisná délka, zeměpisná šířka, výška (nebo hloubka) , a časové proměnné získat spoustu vhodných metadat automaticky (například: jednotky ) .
  • Vzorek< addAttributes > u datové proměnné je:

      <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>

Prázdné čísloObservations atribut způsobuje zdrojové čísloObservations atribut (pokud existuje) která se odstraní ze konečného seznamu atributů.

• Poskytování těchto informací pomáhá ERDDAP™ dělat lepší práci a pomáhá uživatelům pochopit soubory dat. Dobré metadata činí datový soubor použitelný. Nedostatečná metadata činí datový soubor k ničemu. Prosím, udělejte si čas na dobrou práci s atributy metadat.

Komentáře o proměnných atributů, které jsou zvláštní v ERDDAP :

actual\_range

• ** actual\_range ** je atribut proměnné RECOMMENDED. Například,

<att name="actual\_range" type="floatList"\>0.17 23.58</att>

• Tento atribut je z CDC COARDS a CF 1. 7+ Standardy metadat.
• Pokud existuje, musí to být pole dvou hodnot téhož datového typu jako cílový datový typ proměnné s uvedením skutečné (není teoretický nebo povolený) minimální a maximální hodnoty údajů pro tuto proměnnou.
• Pokud jsou data zabalena scale\_factor nebo add\_offset , actual\_range musí mít vybalené hodnoty a být stejného datového typu jako vybalené hodnoty.
• Pro některé zdroje dat (například všechny EDDTableFrom... Soubory souborů) , ERDDAP™ určuje actual\_range každé proměnné a nastaví actual\_range atribut. S jinými zdroji dat (například relační databáze, Cassandra, DAP PER, Hyrax ) , to může být obtížné nebo zátěž pro zdroj vypočítat rozsah, takže ERDDAP™ Nežádá o to. V tomto případě je nejlepší, pokud můžete nastavit actual\_range (zejména u proměnných délky, zeměpisné šířky, výšky, hloubky a času) přidáním actual\_range atribut každé proměnné [< addAttributes >] (#addattributy) pro tento soubor údajů v datasets.xml Například:

<att name="actual\_range" type="doubleList"\>-180 180</att>

• Pro numerické proměnné času a času , stanovené hodnoty by měly být relevantním zdrojem (místo určení) číselné hodnoty. Například pokud jsou výchozí hodnoty času uloženy jako "dny od roku 1985- 01- 01," pak actual\_range by měly být uvedeny v "dnech od roku 1985-01-01." A pokud chcete odkazovat na Now jako druhá hodnota pro téměř-real-time data, která jsou pravidelně aktualizována, měli byste použít NaN . Například pro upřesnění datového rozpětí 1985-01-17 až do TEĎ použijte

<att name="actual\_range" type="doubleList"\>16 NaN</att>

• Pokud actual\_range je známo (buď ERDDAP™ výpočet nebo přidáním přes< addAttributes >), ERDDAP™ zobrazí jej uživateli na formuláři pro přístup k datům ( * datasetID * .html) a vytvořit grafické webové stránky ( * datasetID * .graph) pro tento datový soubor a používat jej při vytváření metadat FGDC a ISO 19115. Také, posledních 7 dní času actual\_range jsou použity jako výchozí podmnožina času.
• Pokud actual\_range je známo, uživatelé mohou použít min () a max () funkce v požadavcích, které jsou často velmi užitečné.
• Pro všechny soubory EDDTable... pokud actual\_range je známo (buď tím, že to určíte, nebo ERDDAP™ výpočet) , ERDDAP™ bude moci rychle odmítnout jakékoli žádosti o údaje mimo tento rozsah. Například, pokud nejnižší časová hodnota datového souboru odpovídá 1985-01-17, pak žádost o všechna data od 1985-01-01 do 1985-01-16 bude okamžitě odmítnuta chybovou zprávou "Váš dotaz nevytvořil žádné odpovídající výsledky." To dělá actual\_range velmi důležitý kus metadat, jak to může uložit ERDDAP™ hodně úsilí a ušetřit uživateli spoustu času. A to zdůrazňuje, že actual\_range hodnoty nesmí být užší než skutečný rozsah údajů; jinak ERDDAP™ může chybně říci: "Neexistují žádná odpovídající data," pokud ve skutečnosti existují relevantní data.
• Pokud uživatel vybere podmnožinu dat a požádá o typ souboru, který obsahuje metadata (například: .nc ) , ERDDAP™ Změny actual\_range v souboru odezvy, aby odrážel rozsah podmnožiny.
• Viz také data\_min a data\_max , které jsou alternativním způsobem, jak upřesnit actual\_range . Nicméně, jsou deprecovány teď, když actual\_range je definována CF 1.7+.  

Atributy barevné lišty

Existuje několik VOLITELNÉ proměnné atributy, které zadávají navrhované výchozí atributy pro barevnou lištu (slouží k převodu hodnot dat do barev na obrazech) pro tuto proměnnou.

• Pokud jsou tyto informace k dispozici, použijí se jako výchozí informace pomocí mřížky a tabledap Kdykoli si vyžádáte obrázek, který používá barevnou lištu.

• Například v případě, že jsou datová délka zeměpisné šířky nastavena jako pokrytí na mapě, barevná lišta určuje, jak jsou hodnoty dat převedeny na barvy.

• Mít tyto hodnoty umožňuje ERDDAP™ vytvořit obrázky, které používají konzistentní barevnou lištu napříč různými požadavky, i když se hodnoty času nebo jiných rozměrů liší.

• Tyto názvy atributů byly vytvořeny pro použití v ERDDAP . Nejsou ze standardu metadat.

• Vlastnosti vztahující se k barevnému panelu jsou:

  • ** colorBarMinimum ** určuje minimální hodnotu v barvěBar. Například,

  <att name="colorBarMinimum" type="double"\>-5</att>

  • Pokud jsou data zabalena scale\_factor nebo add\_offset , uveďte colorBarMinimum jako nevybalenou hodnotu.
  • Hodnoty údajů nižší než colorBarMinimum jsou zastoupeny stejnou barvou jako colorBarMinimum hodnoty.
  • Příznak by měl být type="double" , bez ohledu na typ datové proměnné.
  • Hodnota je obvykle pěkné kulaté číslo.
  • Osvědčené postupy: Doporučujeme hodnotu mírně vyšší než minimální hodnota dat.
  • Neexistuje žádná výchozí hodnota.

• ** colorBarMaximum ** určuje maximální hodnotu v barvěBar. Například,

<att name="colorBarMaximum" type="double"\>5</att>

• Pokud jsou data zabalena scale\_factor nebo add\_offset , uveďte colorBarMinimum jako nevybalenou hodnotu.
• Hodnoty údajů vyšší než colorBarMaximum jsou zastoupeny stejnou barvou jako colorBarMaximum hodnoty.
• Příznak by měl být type="double" , bez ohledu na typ datové proměnné.
• Hodnota je obvykle pěkné kulaté číslo.
• Osvědčené postupy: Doporučujeme hodnotu mírně nižší než maximální hodnota dat.
• Neexistuje žádná výchozí hodnota.
• barva BarPalette určuje paletu pro barvuBar. Například,

        <att name="colorBarPalette">WhiteRedBlack</att>

• Všechny ERDDAP™ instalace podporují tyto standardní palety: BlackBlueWhite, BlackRedWhite, BlackWhite, BlueWhiteRed, LightRainbow, Ocean, OceanDepth, Rainbow, RedWhiteBlue, ReverseRainbow, Topography, TopographyDepth \[ přidáno do v1.74 \] WhiteBlack, WhiteBlueBlack a WhiteRedBlack.
• Pokud jste nainstalovali další palety , můžete odkazovat na jeden z nich.
• Pokud tento atribut není přítomen, výchozí je BlueWhiteRed pokud \-1\* colorBarMinimum = colorBarMaximum ; jinak výchozí je Duha.
• BarScale určuje stupnici pro barvuBar. Například,

        <att name="colorBarScale">Log</att>

• Platné hodnoty jsou Lineární a Log.
• Pokud je hodnota Log, colorBarMinimum musí být větší než 0.
• Pokud tento atribut není přítomen, výchozí hodnota je lineární.
• barva Kontinuální určuje, zda barvaBar má souvislou paletu barev, nebo zda barvaBar má několik diskrétních barev. Například,

        <att name="colorBarContinuous">false</att>

• Platné hodnoty jsou řetězce pravdivé a falešné.
• Pokud tento atribut není přítomen, je výchozí hodnota pravdivá.
• barvaBarNOddíly určuje výchozí počet oddílů v barvěBar. Například,

        <att name="colorBarNSections" type="int">6</att>

• Platné hodnoty jsou pozitivní celá čísla.
• Pokud tento atribut není přítomen, výchozí hodnota je \-1, která říká ERDDAP™ vybrat počet sekcí na základě rozsahu barevBar.

WMS

Hlavní požadavky na přístup k proměnné prostřednictvím ERDDAP 's WMS server jsou:

• Soubor údajů musí být EDDGrid ... data.
• Datová proměnná MUSÍ být roštovaná proměnná.
• Datová proměnná MUSÍ mít proměnné délky a šířky. (Jiné proměnné osy jsou VOLITELNÉ.)
• Musí být nějaké hodnoty délky mezi -180 a 180.
• The colorBarMinimum a colorBarMaximum atributy MUSÍ být specifikovány. (Další atributy barev jsou VOLITELNÉ.)

data\_min a data\_max

• ** data\_min ** a ** data\_max ** -- Toto jsou deprecované proměnné atributy definované ve Světovém experimentu s cirkulací oceánu (WOCE) popis metadat. Například,

<att name="data\_min" type="float"\>0.17</att>
<att name="data\_max" type="float"\>23.58</att>

• Doporučujeme použít actual\_range , místo data\_min a data\_max , protože actual\_range je nyní definován specifikací CF.
• Pokud jsou přítomny, musí být stejného typu údajů jako datový typ proměnné určení a musí uvádět skutečný (není teoretický nebo povolený) minimální a maximální hodnoty údajů pro tuto proměnnou.
• Pokud jsou data zabalena scale\_factor nebo add\_offset , data\_min a data\_max musí být vybaleny hodnoty pomocí rozbaleného datového typu.  

proměnná drawLandMask

• ** drawLandMask ** -- Jedná se o VOLITELNÝ atribut proměnné používaný ERDDAP™ (a žádné standardy metadat) který určuje výchozí hodnotu pro volbu "Draw Land Mask" ve formuláři Make A Graph ( * datasetID * .graph) a pro parametr &.land v URL žádající mapu dat. Například,

    <att name="drawLandMask">under</att>  

Viz drawLandMask přehled .

Kódování

• \_ Kódování
• Tento atribut lze použít pouze s proměnnými String .
• Tento atribut se důrazně doporučuje.
• Tento atribut je z NetCDF Uživatelská příručka (NUG) .
• Vnitřní ERDDAP™ , Struny jsou posloupnost 2-bajtových znaků, které používají Unicode UCS-2 znaková sada .
• Mnoho typů souborů podporuje pouze 1-bajtové znaky v Strings a proto tento atribut potřebuje k identifikaci přiřazeného charset (AKA kódová stránka) která definuje, jak zmapovat 256 možných hodnot do souboru 256 znaků vytažených ze sady znaků UCS-2 a/nebo kódovacího systému, např. UTF-8 (který vyžaduje mezi 1 a 4 byty na znak) .
• Hodnoty pro \_Encoding jsou případově citlivé.
• Teoreticky, ERDDAP™ mohou podporovat \_kódování identifikátorů z Tento seznam IANA Ale v praxi, ERDDAP™ v současné době jen podporuje
  • ISO-8859-1 (všimněte si, že má pomlčky, ne podtržení) , která má výhodu, že je identická s prvními 256 znaky Unicode a
  • UTF-8.
• Při čtení zdrojových souborů je výchozí hodnota ISO-8859-1, kromě netcdf-4 souborů, kde je výchozí hodnota UTF-8.
• Jedná se o pokračující problém, protože mnoho zdrojových souborů používá charsety nebo kódování, které jsou odlišné od ISO-8859-1, ale neidentifikujte znakovou sadu nebo kódování. Například mnoho zdrojových datových souborů má některá metadata zkopírovaná a vložená z Microsoft Word na Windows a tak mají fantastické pomlčky a apostrofy z znakové sady specifické pro Windows místo pomlček ASCII a apostrophes. Tyto postavy pak ukázat jako zvláštní znaky nebo '?' v ERDDAP .  

souborAccessBaseUrl

• ** souborAccessBaseUrl a souborAccessSuffix** jsou velmi zřídka používané atributy, které nejsou z žádného standardu. Pokud má EDDTable sloupec názvy souborů přístupných k webu (např. obraz, video nebo audio soubory) , můžete přidat

    <att name="fileAccessBaseUrl">*someBaseURL*</a>  

zadat základní URL (končí s /) potřeba, aby jména souborů byla kompletní URL. V neobvyklých případech, například když má sloupec odkazy na soubory .png, ale hodnoty chybí ".png," můžete přidat

    <att name="fileAccessSuffix">*someSuffix*</a>  

(například<att name="fileAccessSuffix.png</a>) zadat příponu, která má být přidána, aby jména souborů byla kompletní URL. Pak pro .htmlTable odpovědi, ERDDAP™ zobrazí název souboru jako odkaz na plnou URL (základ Url plus název souboru plus přípona) .

Jestli chceš ERDDAP™ sloužit souvisejícím souborům, oddělovat EDDTableFromFileNames Soubor údajů pro tyto soubory (může se jednat o soukromý soubor údajů) .

souborAccessArchive Url

• souborAccessArchive Url je velmi zřídka používaný atribut, který není z žádného standardu. Pokud má EDDTable sloupec názvy souborů přístupných k webu (např. obraz, video nebo audio soubory) které jsou přístupné prostřednictvím archivu (např. .zip soubor) přístupná přes URL, použití<att name="fileAccessArchiveUrl] URL </att> zadat URL pro archiv.

Jestli chceš ERDDAP™ sloužit archivnímu souboru, oddělovat EDDTableFromFileNames Soubor údajů pro tento soubor (může se jednat o soukromý soubor údajů) .

ioos\_category

• ** ioos\_category ** -- Jedná se o požadovaný atribut proměnné, pokud<proměnnéMusíHaveIoosKategorie> je nastavena na true (výchozí) v setup.xml ; jinak je to VOLITELNÉ. Například,<att name=" ioos\_category ">Slanost</att > Kategorie jsou z NOAA Integrovaný systém pozorování oceánu (IOOS) .

• (K psaní) Nejsme si vědomi formálních definic těchto jmen.

• Hlavní názvy jsou ze Zdenky Willisové.ppt "Integrovaný systém pozorování oceánu" (IOOS) NOAA 's přístupem k budování počáteční provozní schopnosti' a z US IOOS plán (Strana 1-5) .

• Je pravděpodobné, že tento seznam bude v budoucnu revidován. Pokud máte nějaké požadavky, prosím, e-mail Chris. John v Noaa.gov.

• ERDDAP™ podporuje větší seznam kategorií než IOOS, protože Bob Simons přidal další jména (většinou založené na jménech vědeckých oborů, např. biologie, ekologie, meteorologie, statistika, taxonomie) pro jiné typy údajů.

• Aktuální platné hodnoty ERDDAP™ jsou Bathymetrie, Biologie, Spodní znak, CO2, Barevné rozpuštěné organické hmoty, Kontaminanty, Proudy, Rozpuštěné živiny, Rozpuštěné O2, Ekologie, Ryby Hojnost, Ryby Druhy, Teplá Flux, Hydraologie, Distribuce ledu, Identifikátor, Umístění, Meteorologie, Barva oceánu, Optické vlastnosti, Ostatní, Patogeny, Fytoplankton Druhy, Tlak, Produktivita, Kvalita, Slanost, Úroveň moře, Statistiky, Průtok proudu, Povrchové vlny, Taxonomie, Teplota, Čas, Total Suspended Matter, Neznámý, Wind, Zooplankton Druhy, a Zooplankton Abundance.

• Mezi různými pojmy je určité překrytí a nejednoznačnost - snažte se.

• Pokud přidáte ioos\_category na seznam< categoryAttributes > v ERDDAP 's setup.xml soubor, uživatelé mohou snadno najít datové soubory s podobnými údaji prostřednictvím ERDDAP 'Search for Datasets by Category' na domovské stránce. Zkuste použít ioos\_category hledat soubory údajů o zájmech.

• Tam byl diskuse o ERDDAP™ a ioos\_category v ERDDAP™ Google Group.

Můžete být v pokušení nastavit<proměnnéMusíHaveIoosKategorie> false tak, aby tento atribut nebyl vyžadován. ("Pfft! Co je mi do toho?") Některé důvody k tomu, aby to bylo správné (výchozí) a použití ioos\_category jsou:

• Pokud nastavení.xml<proměnnéMusí mítIoosKategorie> je pravda, GenerovatDatasetsXml vždy vytváří / navrhuje ioos\_category atribut pro každou proměnnou v každém novém datovém souboru. Tak proč to tam nenechat?
• ERDDAP™ umožňuje uživatelům vyhledávat soubory zájmů podle kategorií. ioos\_category je velmi užitečná vyhledávací kategorie, protože joos\_kategorie (např. teplota) jsou docela široké. To dělá ioos\_category mnohem lepší pro tento účel než například mnohem jemnější CF standard\_name án (které nejsou pro tento účel tak dobré, protože všechny synonyma a mírné varianty, například, moře\_povrch\teplota versus moře\ voda\_teplota) . (Použití ioos\_category za tímto účelem je kontrolován< categoryAttributes > ve vašem setup.xml souboru.) Zkuste použít ioos\_category hledat soubory údajů o zájmech.
• Tyto kategorie jsou z NOAA Integrovaný systém pozorování oceánu (IOOS) . Tyto kategorie jsou zásadní pro popis mise IOOS. Pokud jste uvnitř NOAA , podpora ioos\_category je dobrá Jedna... NOAA co dělat. (Sleduj. Jedna NOAA video a inspirovat se!) Pokud jste v nějaké jiné americké nebo mezinárodní agentuře, nebo pracujete s vládními agenturami, nebo pracujete s jinými Ocean Observing System, není dobrý nápad spolupracovat s kanceláří IOOS USA?
• Dříve nebo později možná budete chtít někoho jiného. ERDDAP™ odkaz na vaše soubory dat prostřednictvím EDDGrid FromErddap a EDDTableFromErddap . Pokud druhý ERDDAP™ vyžaduje ioos\_category , vaše soubory musí mít ioos\_category v případě EDDGrid OdErddap a EddtableFromErddap do práce.
• Je mnohem jednodušší zahrnout ioos\_category když vytvoříte soubor dat (Je to jen další věc, která ERDDAP™ vyžaduje přidání datového souboru do ERDDAP ) , než přidat to po faktu (Pokud jste se rozhodli ji použít v budoucnu) .  

long\_name

• ** long\_name ** ( COARDS , CF a ACDD Standardy metadat) je atribut proměnné v ERDDAP . Například,

    <att name="long\\_name">Eastward Sea Water Velocity</att>

• ERDDAP™ používá long\_name pro značení os na grafech.
• Osvědčené postupy: Kapitalizovat slova v long\_name jako by to byl titul (Získejte první slovo a všechna slova bez článku) . Nezahrnujte jednotky do long\_name . Dlouhé jméno by nemělo být příliš dlouhé (obvykle<20 znaků), ale mělo by být více popisné než destinationName , což je často velmi stručné.
• Pokud " long\_name "není definován v proměnné" zdrojAtributy nebo< addAttributes >, ERDDAP™ bude generovat tím, že čistí standard\_name (pokud je přítomen) nebo destinationName .  

missing\_value

• ** missing\_value ** a \_Fill Hodnota ( COARDS a CF ) jsou proměnné atributy, které popisují číslo (například -9999) která se používá k vyjádření chybějící hodnoty. Například,

<att name="missing\_value" type="double"\>-9999</att>

Pro String proměnné, výchozí pro oba je "" (prázdný řetězec) . Pro numerické proměnné je výchozí hodnota pro obě proměnné NaN.

• ERDDAP™ podporuje obojí missing\_value a \_FillValue, protože některé datové zdroje jim přiřazují trochu jiný význam.
• Pokud jsou přítomny, měly by mít stejný datový typ jako proměnná.
• Pokud jsou data zabalena scale\_factor nebo add\_offset , missing\_value a hodnoty \_FillValue by měly být rovněž zabaleny. Podobně pro sloupec s hodnotami String date/time, které používají lokální time\_zone , missing\_value a hodnoty \_FillValue by měly používat místní časové pásmo.
• Pokud proměnná používá tyto speciální hodnoty, missing\_value a/nebo \_FillValue atributy jsou povinné.
• Pro proměnné času a času (zda je zdrojem řetězec nebo číselný) , missing\_value s a \_FillValues se objeví jako "" (prázdný řetězec) když je čas napsán jako String a jako NaN, kdy je čas napsán jako dvojitý. Hodnoty zdroje pro missing\_value a \_FillValue se neobjeví v metadatech proměnné.
• Pro proměnné String, ERDDAP™ vždy konvertuje jakékoliv missing\_value s nebo \_FillValue hodnoty dat do "" (prázdný řetězec) . Hodnoty zdroje pro missing\_value a \_FillValue se neobjeví v metadatech proměnné.
• Pro číselné proměnné: The missing\_value a \_FillValue se objeví v metadatech proměnné. Pro některé výstupní datové formáty, ERDDAP™ tato speciální čísla zůstanou nedotčena, např. uvidíte -9999. Pro ostatní výstupní datové formáty (zejména textové formáty jako .csv a .htmlTable ) , ERDDAP™ nahradí tato speciální čísla s NaN nebo "" .
• Některé datové typy mají vlastní chybějící hodnoty, které nemusí být výslovně označeny missing\_value nebo atributy \_FillValue: float a dvojité proměnné mají NaN (Není číslo) , Hodnoty Stringu používají prázdný řetězec a hodnoty znaku mají znak \uffff (znak #65535, což je hodnota Unicode for Not a Character) . Datové typy Integer nemají vlastní chybějící hodnoty.
• Pokud má celá proměnná chybějící hodnotu (například prázdná pozice v souboru .csv) , ERDDAP™ bude interpretovat hodnotu jako definovanou missing\_value nebo \_FillValue pro tuto proměnnou. Pokud žádný není definován, ERDDAP™ bude interpretovat hodnotu jako výchozí chybějící hodnotu pro tento datový typ, což je vždy maximální hodnota, kterou může tento datový typ držet: 127 pro byte proměnné, 32767 pro zkratku, 2147483647 pro int, 9223372036854775807 dlouho, 255 pro ubyte, 65535 pro ukrote, 4294967295 pro uint a 184467440737095516115 pro ulong.

ADD \_FillValue ATTRIBUTES ?

• ADD \_FillValue ATTRIBUTES ?
  Pokaždé ERDDAP™ načítá soubor údajů, kontroluje, zda proměnné s celočíselný zdroj datové typy mají definované missing\_value nebo atribut \_FillValue. Pokud proměnná ne, pak ERDDAP™ vytiskne zprávu do souboru záznamu (začínající na "Přidat \_FillValue Attribute?") doporučuje ERDDAP™ Správce přidá \_Fill Hodnota atributu pro tuto proměnnou v datasets.xml . Je velmi užitečné pro každou proměnnou mít \_FillValue nebo missing\_value protože chybějící hodnoty jsou vždy možné, např. pokud daný soubor v souboru nemá danou proměnnou, ERDDAP™ musí být schopen tuto proměnnou prezentovat jako všechny chybějící hodnoty této proměnné. Pokud se rozhodnete, že proměnná by neměla mít atribut \_FillValue, můžete přidat <att names="\_FillValue>null</att > místo toho, který potlačí zprávu pro to datasetID +variační kombinace v budoucnu.

Pokaždé ERDDAP™ spustí se, shromažďuje všechna doporučení do zprávy, která je zapsána do souboru protokolu (začínáme s " ADD \_FillValue ATTRIBUTES ?") , e-mailem ERDDAP™ správce a napsaný do datového souboru CSV v \[ velkýRodič rodičů \] /logy/ adresář. Pokud chcete, můžete použít program GenerateDatasetsXml (a možnost AddFillValueAttributes) použít všechny návrhy v CSV souboru na datasets.xml Složka. Pro všechny datasetID /proměnné kombinace v tomto souboru, pokud se rozhodnete, že není třeba přidat přiřazený, můžete změnit atribut<att names="\_FillValue>null</att > k potlačení tohoto doporučení datasetID +variační kombinace v budoucnu.

Tohle je důležité! Jak často říká Bob: bylo by to špatné (a trapné) pokud byly některé důkazy o globálním oteplování způsobeny neidentifikovanými chybějícími hodnotami v údajích (Například hodnoty teplot 99 nebo 127 stupňů\_ C, které měly být označeny jako chybějící hodnoty, a tím zkreslily střední a/nebo střední statistiky vyšší) .

• \_FillValue a missing\_value hodnoty dané proměnné v různých zdrojových souborech musí být konzistentní; jinak ERDDAP™ přijme soubory s jednou sadou hodnot a všechny ostatní soubory odmítne jako "Špatné soubory." Abych vyřešil problém,
  • Pokud jsou soubory roštovány .nc soubory, můžete použít EDDGrid FromNcFilesUnpacked .
  • Pokud jsou soubory tabulkové datové soubory, můžete použít EDDTableFrom... ' standardizovat Co? říct ERDDAP standardizovat zdrojové soubory, jak jsou čteny do ERDDAP .
  • Pro těžší problémy, můžete použít NcML nebo NCO vyřešit problém.  

scale\_factor

• ** scale\_factor ** (výchozí hodnota = 1) a ** add\_offset ** (výchozí = 0) ( COARDS a CF ) jsou VOLITELNÉ proměnné atributy, které popisují data, která jsou zabalena do jednoduššího datového typu prostřednictvím jednoduché transformace.
• Pokud jsou přítomny, jejich datový typ se liší od typu zdrojových dat a popisuje datový typ cílových hodnot. Například zdroj dat mohl uložit float datové hodnoty s jednou desetinnou čárkou zabalenou jako krátké inty (int16) , použitím scale\_factor = 0, 1 a add\_offset Například

<att name="scale\_factor" type="float"\>0.1</att>
<att name="add\_offset" type="float"\>0</att>

V tomto příkladu, ERDDAP™ vybalí data a prezentuje je uživateli jako float data hodnoty.

• Pokud je přítomen, ERDDAP™ bude extrahovat hodnoty z těchto atributů, odstranit atributy a automaticky rozebrat data pro uživatele: místo určení Hodnota = zdroj Hodnota \* scale\_factor + add\_offset
  Nebo, řekl jiný způsob: unpackedValue = baleno Hodnota \* scale\_factor + add\_offset
• The scale\_factor a add\_offset hodnoty dané proměnné v různých zdrojových souborech musí být konzistentní; jinak ERDDAP™ přijme soubory s jednou sadou hodnot a všechny ostatní soubory odmítne jako "Špatné soubory." Abych vyřešil problém,
  • Pokud jsou soubory roštovány .nc soubory, můžete použít EDDGrid FromNcFilesUnpacked .
  • Pokud jsou soubory tabulkové datové soubory, můžete použít EDDTableFrom... ' standardizovat Co? říct ERDDAP standardizovat zdrojové soubory, jak jsou čteny do ERDDAP .
  • Pro těžší problémy, můžete použít NcML nebo NCO vyřešit problém.  

standard\_name

• ** standard\_name ** (z CF standard metadat) je atribut proměnné v ERDDAP . CF vede seznam povolených Standardní názvy CF . Například,

    <att name="standard\\_name">eastward\\_sea\\_water\\_velocity</att>

• Pokud přidáte standard\_name k atributům proměnných a k přidání standard\_name na seznam< categoryAttributes > v ERDDAP 's setup.xml soubor, uživatelé mohou snadno najít datové soubory s podobnými údaji prostřednictvím ERDDAP 'Search for Datasets by Category' na domovské stránce.
• Pokud zadáte CF standard\_name u proměnné atribut jednotek proměnné nemusí být totožný s kanonickými jednotkami uvedenými pro standardní název v tabulce názvu CF Standard Name, ale jednotky MUSÍ být konvertibilní ke kanonickým jednotkám. Například všechny CF související s teplotou standard\_name "K" (Kelvin) jako kanonické jednotky. Takže proměnná s teplotou související standard\_name Musí mít jednotky K, stupeň\_C, stupeň\_F, nebo některé varianty UDUnits těchto názvů, protože jsou všechny vzájemně proměnitelné.
• Osvědčené postupy: Část síly kontrolované slovní zásoby pochází z používání pouze podmínek v seznamu. Takže doporučujeme držet se pojmů definovaných v kontrolovaném slovníku, a doporučujeme ne vymýšlet termín, pokud není vhodný v seznamu. Pokud potřebujete další podmínky, podívejte se, zda výbor norem je přidá do kontrolované slovní zásoby.
• standard\_name hodnoty jsou jediné hodnoty atributu CF, které jsou případově citlivé. Všechny jsou vždy malé. Začínáme ERDDAP™ v1.82, GenerateDatasets budou převádět velká písmena na malá písmena. A když je soubor načten ERDDAP , velká písmena se tiše mění na malá písmena.  

time\_precision

• time\_precision je VOLITELNÝ atribut používaný ERDDAP™ (a žádné standardy metadat) místo proměnné času a času , které mohou být v mřížkových datových souborech nebo tabulárních datech a axisVariable s nebo dataVariable s. Například,

    <att name="time\\_precision">1970-01-01</att>  

time\_precision určuje přesnost, která má být použita vždy ERDDAP™ formátuje časové hodnoty z této proměnné jako řetězce na webových stránkách, včetně .htmlTable reakce. Ve formátech souborů, kde ERDDAP™ formáty krát jako řetězce (například .csv a .json ) , ERDDAP™ pouze time\_precision - stanovený formát, pokud zahrnuje zlomkové sekundy; ERDDAP™ používá 1970-01-01T00:00:00 Formát Z.

• Platné hodnoty jsou 1970-01, 1970-01-01, 1970-01T00Z, 1970-01-01T00:00Z, 1970-01-01T00:00Z (výchozí) , 1970-01-01T00:00:0.0Z, 1970-01-01T00:00:00.00Z, 1970-01-01T00:00:0.000Z. \[ 1970 není možnost, protože je jedno číslo, takže ERDDAP™ nemůže vědět, jestli je to formátovaný časový řetězec (rok) nebo pokud je to nějaký počet sekund od 1970-01-01T00:00:00Z. \]
• Pokud time\_precision není zadána nebo hodnota není shodná, použije se výchozí hodnota.
• Tady, jako v jiných částech ERDDAP™ Předpokládá se, že všechna pole formátovaného času, která nejsou zobrazena, mají minimální hodnotu. Například 1985-07, 1985-07-01, 1985-07-01T00Z, 1985-07-01T00:00Z a 1985-07-01T00:00:00 Z jsou všechny považovány za rovnocenné, i když s různou úrovní přesnosti implikované. To odpovídá ISO 8601:2004 "extended" Specifikace formátu času .
• UPOZORNĚNÍ: Měl (a) byste užívat pouze omezené množství time\_precision pokud všechny hodnoty údajů pro proměnnou mají pouze minimální hodnotu pro všechna pole, která jsou skryta.
• Například můžete použít time\_precision z 1970-01-01, pokud mají všechny hodnoty dat hodinu = 0, minuta = 0, a druhá =0 (např. 2005-03-04T00:00:00Z a 2005-03-05T00:00:00Z) .
• Například, nepoužívejte time\_precision ze dne 1970-01-01, pokud existují hodnoty non-0 hodiny, minuty nebo sekund, (např. 2005-03-05T12:00:00Z) protože hodnota nedefaultní hodiny by nebyla zobrazena. Jinak, pokud uživatel požádá o všechna data s time=2005-03-05, žádost nečekaně selže.  

time\_zone

• ** time\_zone **
• time\_zone je VOLITELNÝ atribut používaný ERDDAP™ (a žádné standardy metadat) místo proměnné času a času , které mohou být v mřížkových datových souborech nebo souborech tabulek.
• Výchozí je " Zulu " (což je moderní časová zóna verze GMT) .
• Základní informace: "časové offsety" (např. Pacific Standard Time, -08:00, GMT-8) jsou pevné, specifické, offsety vzhledem k Zulu (GMT) . Naproti tomu "časové zóny" jsou mnohem složitější věci, které jsou ovlivněny úsporou denního světla (např. "US/Pacific") , které měly různá pravidla na různých místech v různých časech. Časová pásma mají vždy jména, protože nemohou být shrnuta jednoduchou offsetovou hodnotou. (viz sloupec "TZ database names" v tabulce v https://en.wikipedia.org/wiki/List\_of\_tz\_database\_time\_zones ) . ERDDAP 's time\_zone atribut vám pomůže vypořádat se s místními daty z určitého časového pásma (např. 1987-03-25T17:32:05 Tichý oceán Čas) . Pokud máte řetězec nebo numerická data času s (pevný) časový posun, měli byste jednoduše upravit data na Zulu (Což je co ERDDAP™ chce) určením jiného základního času v atributu jednotek (např. "hodiny od 1970-01-01T08:00Z," zaznamenejte T08 pro upřesnění časové kompenzace) , a vždy zkontrolujte výsledky, abyste získali výsledky, které chcete.
• Pro proměnné časového razítka se zdrojovými daty ze Strings vám tento atribut umožňuje určit časové pásmo, které vede ERDDAP™ převést na místní čas-zóna zdrojové časy (někteří ve standardním čase, někteří v denním světle šetří čas) do Zulu časy (které jsou vždy ve standardním čase) . Seznam platných názvů časových pásem je pravděpodobně totožný se seznamem ve sloupci TZ https://en.wikipedia.org/wiki/List\_of\_tz\_database\_time\_zones . Společná americká časová pásma jsou: USA/Hawaii, USA/Alaska, USA/Pacific, USA/Mountain, USA/Arizona, USA/Central, USA/Východ.
• Pro proměnné časového razítka s číselnými zdrojovými daty můžete zadat " time\_zone " atribut, ale hodnota musí být " Zulu "nebo "UTC." Pokud potřebujete podporu pro jiná časová pásma, prosím e-mail Chris. John at noaa.gov .  

odkaz_time_adjust

• odkaz_time_adjust Začínáme ERDDAP™ 2.29.0, časové proměnné fungují trochu jinak. Ve vzácných případech, s největší pravděpodobností při užívání dny od a rok před 1582 (tak dny od 0000-01-01 nebo den od 1-1- 1 00:00: 0. 0 ) budete muset uvést pro úpravu proměnné datum. Důvodem je ERDDAP™ pomocí java.time knihovny spravovat data interně. Existují některé soubory, které vyžadují použití staré GregorianKalendář knihovny, aby bolavé správné data.

<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>

jednotky

• jednotky ( COARDS , CF a ACDD standard metadat) definuje jednotky hodnot dat. Například,

    <att name="units">degree\\_C</att>

• "jednotky" jsou povinné buď jako zdrojAttribute, nebo jako addAttribute pro "time" proměnné a je STRONGLIE DOPORUČEN pro jiné proměnné, kdykoli je to vhodné (Což je skoro vždy.) .

• Obecně doporučujeme UDjednotky \ kompatibilní jednotky, které vyžadují COARDS a CF standardy.

• Dalším společným standardem je UCUM -- Unified Code for Units of Measure. OGC služby jako např. SOS , WCS a WMS vyžaduje UCUM a často se na UCUM odkazuje jako na UOM (Jednotky opatření) .

• Doporučujeme použít jednu jednotku standard pro všechny soubory souborů ve vašem ERDDAP . Měl bys to říct. ERDDAP™ který standard používáte<jednotky\_standard>, ve Vašem setup.xml Složka.

• Jednotky dané proměnné v různých zdrojových souborech musí být konzistentní. Pokud máte sběr datových souborů, kde jedna podmnožina souborů používá různé hodnoty jednotek než jedna nebo více dalších podskupin souborů (například, "days since 1985-01-01" versus "days since 2000-01-01," "stupeň\_Celsius" versus "deg\_C," nebo "uzel" versus "m/s") musíte najít způsob, jak standardizovat hodnoty jednotek, jinak, ERDDAP™ načte pouze jednu podmnožinu souborů. Přemýšlejte o tom: pokud má jeden soubor windSpeed jednotky=knots a druhý má windSpeed jednotky=m/s, pak by hodnoty ze dvou souborů neměly být zahrnuty do stejného souhrnného souboru.

  • Pokud jsou soubory roštovány .nc soubory, v mnoha situacích můžete použít EDDGrid FromNcFilesUnpacked .
  • Pokud jsou soubory tabulkové datové soubory, v mnoha situacích můžete použít EDDTableFrom... ' standardizovat Co? říct ERDDAP standardizovat zdrojové soubory, jak jsou čteny do ERDDAP .
  • Pro těžší problémy, můžete použít NcML nebo NCO vyřešit problém.

• Norma CF sekce 8.1 říká, že pokud jsou data proměnné zabalena přes scale\_factor nebo add\_offset , "Jednotky proměnné by měly být reprezentativní pro rozbalená data."

• Pro proměnné času a času, buď proměnná je zdrojAtributy nebo< addAttributes > (který má přednost) Musí mít jednotky což je buď

• Pro proměnné časové osy nebo proměnné časových údajů s číselnými údaji: UDjednotky \ kompatibilní řetězec (s formátem jednotky od baseTime ) popis toho, jak interpretovat hodnoty času zdroje (například sekundy od 1970-01-01T00:00:00Z) .

jednotky může být některý z:

    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.  

Technicky vzato, ERDDAP™ NETÝKÁ SE UDUNITS standardní při převodu "years since" a "months since" časové hodnoty do "seconds since" . The UDUNITS standard definuje rok jako pevnou jedinou hodnotu: 3.15569259747e7 sekund. A UDUNITS definuje měsíc jako rok/12. Bohužel, většina/všechny soubory údajů, které jsme viděli, že použití "years since" nebo "months since" jasně zamýšlejí hodnoty jako kalendářní roky nebo kalendářní měsíce. Například, 3 "months since 1970-01-01" má obvykle znamenat 1970-04-01. Takže, ERDDAP™ interpretuje "years since" a "months since" jako kalendářní roky a měsíce, a ne přesně sledovat UDUNITS standardní.

The baseTime musí být ISO 8601:2004 (E) Name ( yyyy-MM-dd 'T'HH:mm:ssZ, například, 1970-01-01T00:00:00Z) , nebo některé změny, že (například s chybějícími částmi na konci) . ERDDAP™ se snaží pracovat s širokou škálou variant tohoto ideálního formátu, například "1970-1-1 0:0:0" je podporován. Pokud informace o časovém pásmu chybí, předpokládá se, že se jedná o Zulu časové pásmo (AKA GMT) . I kdyby byl stanoven jiný časový posun, ERDDAP™ Nikdy nepoužívá Daylight Saving Time. Pokud základnaTime používá jiný formát, musíte použít< addAttributes > zadat nový řetězec jednotek, který používá změnu ISO 8601:2004 (E) formát (např. změna dnů od 1. ledna 1985 do dnů od roku 1985-01-01.

Můžete to otestovat. ERDDAP 's schopností vypořádat se s konkrétní jednotky od baseTime s ERDDAP 's Časový převodník . Doufejme, že můžete připojit číslo (první časová hodnota ze zdroje dat?) a jednotky řetězec, klikněte na Convert, a ERDDAP™ bude moci převést na ISO 8601:2004 (E) Zformátovaný časový řetězec data. Převodník vrátí chybovou zprávu, pokud řetězec jednotek není rozpoznatelný.

Časové jednotky řetězce

• Pro atribut jednotek pro proměnné času nebo času s daty String, musíte uvést Java.time.DatumForhmota vzor (který je většinou kompatibilní s java.textem. SimpleDateFormat) který popisuje, jak interpretovat časy strun.

Pro běžně používané časové formáty, které jsou variantami ISO 8601:2004 (E) standardní formát (např. 2018-01-02T00:00:00Z) , můžete zadat varianty yyyy-MM-dd 'T'HH:mm:ssZ, například použití yyyy-MM-dd pokud má strunný čas pouze datum. Pro jakýkoli formát začínající na rrrr-M, ERDDAP používá speciální parser, který je velmi odpouštějící drobných variant ve formátu. Parser zvládá časová pásma ve formátu "Z," "UTC," "GMT," ±XX:XX, ±XXXX a ±XX. Pokud části data nejsou specifikovány (například minuty a sekundy) , ERDDAP™ předpokládá nejnižší hodnotu pro toto pole (Například pokud nejsou zadány sekundy, předpokládá se sekundy =0) .

Pro všechny ostatní formáty strun je třeba přesně zadat řetězec formátu DateTimeForhmotu kompatibilní s časem. Jako yyyy-MM-dd 'T'HH:mm:ssZ, tyto formátové řetězce jsou postaveny z znaků, které určují určitý typ informací z časového řetězce, např. m znamená minutu za hodinu. Pokud opakujete znak formátu určitý početkrát, dále zpřesní význam, např. m znamená, že hodnota může být specifikována libovolným počtem číslic, mm znamená, že hodnota musí být specifikována dvěma číslicemi. The Java dokumentace pro DateTimeForhmota je hrubý přehled a nedává tyto podrobnosti jasně najevo. Takže tady je seznam vzorových variací znaků a jejich význam v rámci ERDDAP™ (která se někdy trochu liší od Java 's DateTimeForhmota) :

Znaky	Příklady	Význam
u, y, Y	\-4712, 0, 1, 10, 100, 2018	roční číslo, libovolný počet číslic. ERDDAP™ léčí y (roční období) a Y (týdenní rok, protože se často špatně používá místo y) jako u, astronomické číslo roku . Astronomické roky jsou pozitivní nebo negativní celá čísla, která nepoužívají BCE (BC) nebo CE (AD) era designators: 2018=2018CE, ..., 2=2CE, 1=1CE, 0=1BCE, -1=2BCE, -2=3BCE, ...
uuuu, rrrr, RRRR	\-4712, 0000, 0001, 0010, 0100, 2018	4 číslice astronomického roku čísla (Ignorovat všechny předchozí '-')
Př	1, 01, 12	měsíční číslo, libovolný počet číslic (1= leden)
MM	01, 12	2 číslice (0 polstrovaný) měsíční číslo
MMM	Jan, Jan, JAN	3 písmeno anglického měsíce jméno, případ necitlivý
MMMM	Jan, Jan, Jan, Leden, leden, leden	3 písmeno nebo celé anglické jméno měsíce, případ necitlivý
d	1, 01, 31	číslo dne měsíce, jakýkoli počet číslic
dd	01, 31	2 číslice (0 polstrovaný) Den v měsíci. První číslice může být prostor.
D	1, 001, 366	Den v roce, libovolný počet číslic, 001=Jan 1
DDD	001, 366	den v roce, 3 číslice, 001=Jan 1
OEEZ	Thu, THU, Thu	3 písmeno den v týdnu, hodnota je ignorována při analýze
OEEZ	Thu, THU, Thu, čtvrtek, čtvrtek, čtvrtek	3 písmeno nebo celý anglický den v týdnu, případ necitlivý, hodnota je ignorována při analýze
H	0, 00, 23	H hodina dne (0- 23) , libovolný počet číslic
HH	00, 23	HH hodina dne (00- 23) , 2 číslice. První číslice může být prostor.
a	AM, AM, PM, PM	AM nebo PM, citlivé na případy
h	12, 1, 01, 11	hodinová hodina (12, 1, 2, ... 11) , libovolný počet číslic
hh	12, 01, 11	hodinová hodina (12, 1, 2, ... 11) , 2 číslice. První číslice může být prostor.
K	0, 1, 11	hodina (0, 1, ...11) , libovolný počet číslic
KK	00, 01, 11	hodina-am-pm, 2 číslice
m	0, 00, 59	minuta za hodinu, libovolný počet číslic
mm	00, 59	minuta za hodinu, 2 číslice
án	0, 00, 59	druhá minuta, libovolný počet číslic
ss	00, 59	druhá minuta, 2 číslice
S	0, 000, 9, 999	zlomek sekundy, jako kdyby po desetinné čárce, jakýkoliv počet číslic
SS	00, 99	Setiny sekundy, 2 číslice
SSS	000, 999	tisíce sekund, 3 číslice
A	0, 0000, 86399999	milisekunda dne, libovolný počet číslic
AAAAAAAA	00000000, 86399999	milisekunda dne, 8 číslic
N	0, 00000000000000, 86399999999999	nanosekundu dne, libovolný počet číslic. In ERDDAP™ Tohle je zkrácené na nMillis.
NNNNNNNNNNNNNNN	00000000000000, 86399999999999999	Nanosekunda dne, 14 číslic. In ERDDAP™ Toto je zkráceno na nMillis.
n	0, 00000000000, 59999999999	nanosekundu sekundy, libovolný počet číslic. In ERDDAP™ Toto je zkráceno na nMillis.
nnnnnn[nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn]][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn][nn]]][nn][nn][nn][nn][nn]	00000000000, 59999999999	nanosekunda sekundy, 11 číslic. In ERDDAP™ Toto je zkráceno na nMillis.
XXX, ZZZ	Z, -08:00, +01:00	časové pásmo s formátem "Z" nebo ± (2 číslice hodiny offset) : (2 číslice minuty offset) . Tohle zabírá. prostor jako + (nestandardní) . ZZZ podpora 'Z' je nestandardní, ale zabývá se společnou uživatelskou chybou.
XX, ZZ	Z -0800, +100	časové pásmo s formátem "Z" nebo ± (2 číslice hodiny offset) : (2 číslice minuty offset) . Tohle zabírá. prostor jako + (nestandardní) . ZZ podpora 'Z' je nestandardní, ale zabývá se běžným uživatelským omylem.
X, Z	Z, -08, +01	časové pásmo s formátem "Z" nebo ± (2 číslice hodiny offset) : (2 číslice minuty offset) . Tohle zabírá. prostor jako + (nestandardní) . Z podpora 'Z' je nestandardní, ale zabývá se běžným uživatelským omylem.
xxx	\-08:00, +01:00	časové pásmo s formátem ± (2 číslice hodiny offset) : (2 číslice minuty offset) . Tohle zabírá. prostor jako + (nestandardní) .
xx	\-0800, +0100	časové pásmo s formátem ± (2 číslice hodiny offset) (2 číslice minuty offset) . Tohle zabírá. prostor jako + (nestandardní) .
x	\-08, +01	časové pásmo s formátem ± (2 číslice hodiny offset) . Tohle zabírá. prostor jako + (nestandardní) .
'	"T," "Z," "GMT"	start a konec série doslovných znaků
' ' (dvě jediné citace)	' '	dvě jediné citace označuje doslovnou jedinou nabídku
\[ \]	\[ \]	začátek (" \[ ") a konec (" \] ") volitelného oddílu. Tato notace je podporována pouze pro doslovné znaky a na konci řetězce formátu.
# { }	# { }	vyhrazeno pro budoucí použití
G,L,Q,e,c,V,z,O,p		Tyto formátovací znaky jsou podporovány Java 's DateTimeForhmota, ale momentálně není podporován ERDDAP . Pokud potřebujete podporu, pošlete Chrisovi email. John at noaa.gov .

Poznámky:

• V datovém čase s interpunkcí mohou mít číselné hodnoty variabilní počet číslic (Například v americkém formátu "1/2/1985" může být měsíc a datum 1 nebo 2 číslice) formát musí tedy používat jednopísmenné žetony, např. M/d/rrrr, které přijímají libovolný počet číslic za měsíc a datum.
• Je-li počet číslic pro položku konstantní, např. 01/02/1985, uveďte počet číslic ve formátu, např. MM/dd/rrrr pro dvoumístný měsíc, dvoumístné datum a čtyřmístný rok.
• Tyto formáty jsou složité pracovat s. Zadaný formát může pracovat pro většinu, ale ne pro všechny, časové řetězce pro danou proměnnou. Vždy zkontrolujte, zda formát, který zadáte, funguje podle očekávání ERDDAP pro všechny časové řetězce proměnné.
• Pokud je to možné, GenerateDatasetXml navrhne řetězce ve formátu času.
• Pokud potřebujete pomoct vytvořit formátovací řetězec, prosím email Chris. John at noaa.gov .

Hlavní proměnná časových dat (pro soubor tabulkových dat) a proměnná hlavní časové osy (pro mřížkované soubory dat) jsou uznávány destinationName Čas. Jejich metadata jednotek musí být řetězec jednotek kompatibilních s UDUnits pro číselné časové hodnoty, např. "den od 1970-01-01" (pro tabulkové nebo mřížkované soubory dat) nebo jednotky vhodné pro časy strun , např. "M/d/rrrr" (pro soubor tabulkových dat) .

Různé časové jednotky v různých gridd .nc Soubory - Pokud máte sbírku mřížkovaných .nc soubory, kde pro časovou proměnnou jedna podmnožina souborů používá různé časové jednotky než jedna nebo více dalších podmnožin souborů, můžete použít EDDGrid FromNcFilesUnpacked . Převádí časové hodnoty na "seconds since 1970-01-01T00:00:00Z" na nižší úrovni, a tím skrývá rozdíly, takže můžete vytvořit jeden soubor ze sbírky heterogenních souborů.

Proměnné časového údaje

Proměnné časového údaje -- Každá jiná proměnná ( axisVariable nebo dataVariable , EDDGrid nebo EDDTable soubor) může být proměnná timeStamp. Časové proměnné jsou proměnné, které mají časové jednotky a data, ale mají< destinationName > jiná než čas. TimeStamp proměnné se chovají jako hlavní čas proměnné v tom, že převést zdroj je časový formát do "seconds since 1970-01-01T00:00:00Z" a/nebo ISO 8601:2004 (E) formát). ERDDAP™ rozpozná čas Proměnné známek podle jejich časové souvislosti " jednotky " Metadata, která musí odpovídat tomuto pravidelnému výrazu " \[ a-zA-Z \] + + +od + \[ 0-9 \] .+" (pro číselné datum Například časy, "seconds since 1970-01-01T00:00:00Z" ) nebo být datem String ve formátu času obsahující "uuuuu," "rrrr" nebo "RRRR" (Například, " yyyy-MM-dd T'HH:mm:ssZ") . Ale použij prosím destinationName "time" pro hlavní datum Časová proměnná.

Vždy zkontrolujte svou práci, abyste si byli jisti, že časové údaje, které se objeví v ERDDAP™ je správná časová data. Práce s daty o čase je vždy ošemetná a chybovitá.

Viz více informací o časových proměnných . ERDDAP™ má nástroj pro Převést numerické Čas do/z doby řetězce . Viz Jak ERDDAP™ Obchoduje s časem .  

valid\_range

• ** valid\_range ** nebo ** valid\_min ** a ** valid\_max ** -- Jedná se o VOLITELNÉ proměnné atributy definované v CF Konvence metadat. Například,

<att name="valid\_range" type="floatList"\>0.0 40.0</att>

nebo

<att name="valid\_min" type="float"\>0.0</att>
<att name="valid\_max" type="float"\>40.0</att>

• Pokud jsou přítomny, měly by mít stejný datový typ jako proměnná a uvádět platné minimální a maximální hodnoty údajů pro tuto proměnnou. Uživatelé by měli považovat hodnoty mimo tento rozsah za neplatné.
• ERDDAP™ nepoužívá valid\_range . Řekl jsem to jinak: ERDDAP™ nepřevádí hodnoty dat mimo valid\range \ Fill Hodnota nebo missing\_value . ERDDAP™ Prostě předá tato metadata a aplikaci nechá na vás. Proč? Na to jsou ta metadata. Pokud by poskytovatel údajů chtěl, mohl převést hodnoty údajů mimo rámec valid\_range být \_FillValues. ERDDAP™ nehádá poskytovatele dat. Tento přístup je bezpečnější: pokud se později ukáže, že valid\_range byl příliš úzký nebo jinak nesprávný, ERDDAP™ nevymaže data.
• Pokud jsou data zabalena scale\_factor nebo add\_offset , valid\_range , valid\_min a valid\_max by měl být balený datový typ a hodnoty. Od ERDDAP™ platí scale\_factor a add\_offset při zatížení souboru dat, ERDDAP™ vybalí valid\_range , valid\_min a valid\max hodnoty tak, aby metadata místa určení (zobrazeno uživatelům) označuje rozbalený datový typ a rozsah. Nebo, pokud vybalené\ valid\_range je přítomen atribut, bude přejmenován valid\_range kdy ERDDAP™ načítá data.

<Odstranit MVRows>

• [ ** <removeMVRows> ** ] (#removemvrows) je VOLITELNÝ tag v záložce datasets.xml pro EDDTableFromFoles (včetně všech podtříd) Databáze, i když se používá pouze pro EDDTableFromMultidimNcFiles. Může mít hodnotu pravdy nebo lži. Například pravda Tím se odstraní jakýkoliv blok řádků na konci skupiny, kde jsou všechny hodnoty missing\_value , \_FillValue, nebo CoHort ...Array nativní chybějící hodnota (nebo char=#32 pro CharArrays) . To je pro CF DSG Multidimenzional Array typ souboru a podobné soubory. Pokud je to pravda, je to správná zkouška a tak vždy načte všechny proměnné max dim, takže to může trvat déle. Výchozí hodnota je falešná. Doporučení -- Pokud je to pro váš datový soubor možné, doporučujeme nastavení odstranit MVRows na false. Nastavení odstraněníMVRows do true může výrazně zpomalit požadavky, i když může být potřeba pro některé soubory dat.