[{"data":1,"prerenderedAt":1070},["ShallowReactive",2],{"page-\u002Fformat\u002Fspec\u002Fv2\u002Foverview":3,"navigation":692},{"collection":4,"page":5},"spec",{"id":6,"title":7,"body":8,"description":683,"extension":684,"meta":685,"navigation":686,"path":687,"rawbody":688,"seo":689,"stem":690,"__hash__":691},"spec\u002Fformat\u002Fspec\u002Fv2\u002Foverview.md",".well File Format Specification — Version 2.4: Overview",{"type":9,"value":10,"toc":666},"minimark",[11,20,81,104,109,115,158,162,221,224,227,245,255,259,262,264,267,278,284,287,289,292,298,304,307,357,359,362,368,370,373,378,384,390,396,398,401,600,602,605,608,656,658],[12,13,15,19],"h1",{"id":14},"well-file-format-specification--version-24-overview",[16,17,18],"code",{},".well"," File Format Specification — Version 2.4: Overview",[21,22,23,27,28,31,32,31,34,37,38,41,42,31,45,31,48,31,51,31,54,57,58,31,61,31,64,67,68,71,72,74,75,77,78,80],"p",{},[24,25,26],"strong",{},"Version:"," 2.4 ",[24,29,30],{},"Extension:"," ",[16,33,18],{},[24,35,36],{},"Encoding:"," UTF-8 ",[24,39,40],{},"Base format:"," JSON ",[24,43,44],{},"MIME type:",[16,46,47],{},"application\u002Fvnd.well+json",[24,49,50],{},"JSON Schema:",[16,52,53],{},"https:\u002F\u002Fwelldot.org\u002Fschema\u002Fv2\u002Fwell.schema.json",[24,55,56],{},"JSON Schema draft:"," 2020-12 ",[24,59,60],{},"JSON-LD Context (optional):",[16,62,63],{},"https:\u002F\u002Fwelldot.org\u002Fcontext\u002Fv2.jsonld",[24,65,66],{},"Status:"," v2.0 ratified — shipped in ",[16,69,70],{},"@welldot\u002Fcore"," v0.2.0 · v2.1 shipped in ",[16,73,70],{}," v0.3.0 · v2.3 shipped in ",[16,76,70],{}," v0.4.0 · v2.4 shipped in ",[16,79,70],{}," v0.5.0",[21,82,83,31,86,91,92,91,96,91,100],{},[24,84,85],{},"See also:",[87,88,90],"a",{"href":89},"\u002Fformat\u002Fspec\u002Fv2\u002Fformat-reference","format-reference.md"," · ",[87,93,95],{"href":94},"\u002Fformat\u002Fspec\u002Fv2\u002Fobject-schemas","object-schemas.md",[87,97,99],{"href":98},"\u002Fformat\u002Fspec\u002Fv2\u002Finteroperability","interoperability.md",[87,101,103],{"href":102},"\u002Fformat\u002Fspec\u002Fv2\u002Fwater-quality","water-quality.md",[105,106,108],"h2",{"id":107},"overview","Overview",[21,110,111,112,114],{},"The ",[16,113,18],{}," v2 specification is split into five documents. This one gives the context: what changed in each revision (v2.4, v2.3, v2.1 and from v1), why the format exists, the design principles the other parts follow, and the known limitations. The other four are:",[116,117,118,132,148,153],"ul",{},[119,120,121,123,124,127,128,131],"li",{},[87,122,90],{"href":89}," — the top-level fields, versioning and deprecation, datetimes, recommended vocabularies, ",[16,125,126],{},"well_id",", ",[16,129,130],{},"location",", units, profiles, extensibility, cross-reference rules and precision.",[119,133,134,136,137,140,141,127,144,147],{},[87,135,95],{"href":94}," — every object schema, the ",[16,138,139],{},"hydrodynamic_events"," ledger, ",[16,142,143],{},"aquifer_analysis",[16,145,146],{},"history_logs",", the operational blocks (pumps, permits, meters, production, operating regime) and a complete example.",[119,149,150,152],{},[87,151,103],{"href":102}," — water samples and results, their units, the parameter vocabulary and regulatory profiles.",[119,154,155,157],{},[87,156,99],{"href":98}," — the JSON-LD context, the relationship to GWML2 and JSON Schema validation.",[105,159,161],{"id":160},"table-of-contents","Table of contents",[116,163,164,178,184,197,203,209,215],{},[119,165,166,170],{},[87,167,169],{"href":168},"#changes-in-v24","Changes in v2.4",[116,171,172],{},[119,173,174],{},[87,175,177],{"href":176},"#deprecations","Deprecations",[119,179,180],{},[87,181,183],{"href":182},"#changes-in-v23","Changes in v2.3",[119,185,186,190],{},[87,187,189],{"href":188},"#changes-in-v21","Changes in v2.1",[116,191,192],{},[119,193,194],{},[87,195,177],{"href":196},"#deprecations-1",[119,198,199],{},[87,200,202],{"href":201},"#changes-from-v1","Changes from v1",[119,204,205],{},[87,206,208],{"href":207},"#purpose","Purpose",[119,210,211],{},[87,212,214],{"href":213},"#design-principles","Design Principles",[119,216,217],{},[87,218,220],{"href":219},"#known-limitations-of-v2","Known Limitations of v2",[222,223],"hr",{},[105,225,169],{"id":226},"changes-in-v24",[21,228,229,230,233,234,236,237,240,241,244],{},"v2.4 files write ",[16,231,232],{},"\"version\": \"2.4\"","; parsers up to ",[16,235,70],{}," 0.4.0 reject them. Beyond that, v2.4 is an additive revision: every valid v2.3 document stays valid when its ",[16,238,239],{},"version"," is rewritten, and the integer ",[16,242,243],{},"2"," still means \"v2.0 to v2.3, revision unknown\".",[246,247,252],"pre",{"className":248,"code":250,"language":251},[249],"language-text","v2.4 additions:\n- version is the string \"M.m\" (^\\d+\\.\\d+$), compared as two integers,\n  never as text; patch levels are not allowed; readers accept 1, 2 and\n  \"M.m\"\n- location.properties.timezone (optional, IANA name): the local date of\n  an instant is its date converted to this zone; a missing timezone in\n  a file with condition fulfillments emits the warning missing_timezone\n- logger_series (hydrodynamic event type): a continuous level series\n  recorded by an installed sensor, with sensor_depth, interval,\n  barometric_compensation and aggregation (none, hourly, daily with\n  depth_min \u002F depth_max); not a controlled test, not a static level\n- LevelReading.datetime: the instant of a reading, required in a\n  logger_series, where elapsed is absent\n- Offline packaging: an optional ZIP (.wellz) with the .well file at\n  the root and attachments at relative paths; relative uri allowed and\n  sha256 required only inside the package\n- Application extensions: x-\u003Cvendor>-\u003Cname> is RECOMMENDED\n  (e.g. x-welldot-custom)\n\nv2.4 clarifications:\n- A known hydrodynamic event type is validated against its own schema\n  and no longer falls back to the open x- rule; step counts per type\n  are SHOULD (a free count is valid), and steps must be valid\n  PumpingStep entries\n- An optional field without a value is omitted, never written as null\n  (storativity is no longer nullable); v2 integer files that still\n  carry it are tolerated on read\n- Ledgers MAY be edited in place; editing is NOT RECOMMENDED after a\n  record has been exported, and corrects remains the way to retract a\n  measurement. Result.validation is editable too\n- Repeated records (collective permits, campaign blanks) share the\n  same id and SHOULD have identical content; consumers MAY merge them\n  by id. A fulfillment event_id or sample_id resolves only in the file\n  of the well that produced it\n- Unresolved references MUST be preserved when a file is re-exported,\n  never silently removed\n- A duplicated operating_regime.effective_from and an\n  estimated_volume period_end not after period_start are warnings\n- daily_operating_time above 24 is normalized to 24 with a warning\n  (the stored value stays as written); a negative value is an error\n- Attachment.document_type condition_evidence is typically found in\n  permits[].conditions[].fulfillments\n- The attachment lists (id uniqueness, \"root is not an aggregate\",\n  where attachments are allowed) name the same set of records\n- history_logs updated_at may be earlier than datetime for a pre-dated\n  entry; neither ordering emits a warning\n- well_id: producers SHOULD mark exactly one entry primary: true; \"the\n  first entry is canonical\" is only the fallback\n","text",[16,253,250],{"__ignoreMap":254},"",[256,257,177],"h3",{"id":258},"deprecations",[21,260,261],{},"None.",[222,263],{},[105,265,183],{"id":266},"changes-in-v23",[21,268,269,270,273,274,277],{},"v2.3 is an additive minor revision. Every valid v2.1 document is a valid v2.3 document, and documents keep declaring ",[16,271,272],{},"\"version\": 2",". It adds the operational blocks (equipment, documents, permits, metering, production and operating regime) and the water quality block (",[16,275,276],{},"water_samples",").",[246,279,282],{"className":280,"code":281,"language":251},[249],"v2.3 additions:\n- attachments (optional Attachment[]): root-level documents about the\n  well as a whole (drilling report, as-built drawing, registry record…)\n- Attachment becomes a common type and gains document_type\n  (drilling_report, as_built_drawing, registry_record, photo,\n  permit_document, condition_evidence, pump_curve, field_sheet,\n  test_report, lab_report, invoice)\n- pump_installations (optional PumpInstallation[]): pump installation\n  history, with nameplate, intake depth, riser and electrical data\n- permits (optional Permit[]): legal instruments governing abstraction\n  (outorga, dispensa, cadastro) with validity, granted flow, daily\n  operating time, volume limits, monthly schedule and conditions\n  (condicionantes) whose deadlines are derived from ISO 8601 date\n  durations; renewals are linked with supersedes. Each permit carries\n  its identifier and\u002For request_identifier (verbatim, any format), a\n  closed administrative status (requested, granted, suspended,\n  revoked, denied, withdrawn), an administrative history (filing,\n  process, notifications, fees, with done\u002Fdue_date and attachments)\n  and, on each condition, a responsible and the fulfillments of its\n  deadlines (datetime, due_date, author, event_id, sample_id,\n  attachments)\n- meters (optional Meter[]): totalizer (hidrômetro) installation\n  history; device facts only (type, serial, nominal diameter,\n  max_reading for rollover)\n- production (optional ProductionEntry[]): ledger of\n  meter_reading entries (register values in m³) and estimated_volume\n  entries (volumes estimated for a period without a meter); volumes\n  are derived from consecutive readings, never stored as totals.\n  Volumes declared to a regulator are not production data: they are\n  the fulfillment of the permit's reporting condition\n- operating_regime (optional OperatingRegime[]): declared flow rate,\n  daily operating time and days per week, each entry in force from\n  effective_from\n- history_logs category status_change, with status (active,\n  maintenance, inactive, decommissioned, abandoned): the well's\n  operating status; current status is unknown without one\n- history_logs category maintenance gains maintenance_type,\n  pump_installation_id and meter_id\n- history_logs gains hydrodynamic_event_ids and sample_ids (any\n  category): references to the data an entry produced or observed,\n  never copies of measured values\n- hydrodynamic_events[].corrects: retracts an earlier event (ledger\n  correction)\n- hydrodynamic_events[].attachments, aquifer_analysis[].attachments\n- Canonical units kW (power), V (voltage), mm² (cable cross-section),\n  m³ (volume), h (daily operating time only)\n- water_samples (optional WaterSample[]): ledger of water samples,\n  each with its field and laboratory results in one list\n  (distinguished by measured_in), sampling point (point depth or\n  isolated interval, or the production pump), purge and stabilization\n  readings, laboratory and chain of custody, field QA\u002FQC\n  (field_duplicate, split_sample via parent_sample_id; blanks),\n  per-result filtration, lab flags and data validation; corrected\n  reports and revalidations are new samples with corrects\n- Parameter identity { code, vocabulary } with vocabularies welldot,\n  cas and x-…; the welldot parameter vocabulary (98 codes) is\n  published as versioned data in @welldot\u002Fcore, with CAS\n  equivalences; the unit of a welldot or cas parameter comes from its\n  code (substances always mg\u002FL), and unit (UCUM) exists only for x-\n  codes\n- Canonical units mg\u002FL, µS\u002Fcm at 25 °C, °C, mV, NTU \u002F FNU \u002F FAU \u002F FTU\n  (by code), Hazen (uH), MPN\u002F100 mL, CFU\u002F100 mL, CFU\u002FmL, Bq\u002FL and µm\n- _resolution convention: analyzed_at_resolution and\n  laboratory.received_at_resolution set to \"day\" mark an instant\n  known only by its date; consumers MUST ignore the time of day\n- permit condition fulfillments gain sample_id (e.g. a water-quality\n  monitoring condition)\n- well_screen[].slot_type (screen design: continuous_slot, slotted,\n  bridge_slot, louver, perforated, nold); type remains the screen\n  material\n- Recommended vocabularies for drilling_method, construction materials\n  (well_case \u002F well_screen \u002F reduction type, riser_material),\n  well_screen slot_type,\n  centralizer steels, cement_pad.type, history_logs severity,\n  measurement_method and aquifer_analysis method; every recommended\n  vocabulary is published by @welldot\u002Fcore with en\u002Fpt labels\n\nv2.3 clarifications:\n- Block kinds: every top-level array is a ledger, a mutable record or\n  an installation; the kind decides how records are corrected\n- Open vocabulary values are stored as their key, never as a\n  translated label\n- Datetime families: legal documents use calendar dates (YYYY-MM-DD),\n  everything else uses RFC 3339 instants\n- Naming rules: no units in field names; nameplate values use the\n  rated_ prefix; time intervals use period_start \u002F period_end\n- supersedes (legal succession between permits) is distinct from\n  corrects (ledger retraction)\n- Permit status and condition deadlines are derived on the local civil\n  date at the well site, never stored\n- Volume derivation is normative: rollover via max_reading, never\n  across two meters, unknown (never zero or negative) where readings\n  do not cover; metered volume takes precedence over estimated\n  volumes\n- history_logs category change_of_use is no longer a recommended\n  value; a change of use is an event entry (the current use lives in\n  well_purpose)\n- Jurisdiction neutrality: water quality limits, exceedances and\n  national rules are never written to the file; limit sets (WHO, EU,\n  Brazil…) are data in @welldot\u002Fcore and local requirements enter\n  through profiles\n",[16,283,281],{"__ignoreMap":254},[21,285,286],{},"v2.3 contains no deprecations.",[222,288],{},[105,290,189],{"id":291},"changes-in-v21",[21,293,294,295,297],{},"v2.1 is an additive minor revision. Every valid v2.0 document is a valid v2.1 document, and documents keep declaring ",[16,296,272],{},".",[246,299,302],{"className":300,"code":301,"language":251},[249],"v2.1 additions:\n- well_purpose (optional string[]): intended use(s) of the well —\n  production, monitoring, piezometer, water_level_indicator (INA),\n  observation, exploration, injection, dewatering\n- centralizers (optional Centralizer[]): casing\u002Fscreen centralizers\n  as depth interval + spacing\n- history_logs category `change_of_use`\n\nv2.1 clarifications:\n- well_type describes the construction method only\n- Level sign convention: water levels above ground are negative\n  (made explicit; already implied by \"ground level as zero\")\n",[16,303,301],{"__ignoreMap":254},[256,305,177],{"id":306},"deprecations-1",[308,309,310,326],"table",{},[311,312,313],"thead",{},[314,315,316,320,323],"tr",{},[317,318,319],"th",{},"Deprecated",[317,321,322],{},"Replacement",[317,324,325],{},"Removal",[327,328,329],"tbody",{},[314,330,331,337,354],{},[332,333,334],"td",{},[16,335,336],{},"well_type: \"artesian\"",[332,338,339,340,343,344,347,348,351,352],{},"Construction method in ",[16,341,342],{},"well_type"," (usually ",[16,345,346],{},"tubular",") + negative ",[16,349,350],{},"static_level"," in ",[16,353,139],{},[332,355,356],{},"v3",[222,358],{},[105,360,202],{"id":361},"changes-from-v1",[246,363,366],{"className":364,"code":365,"language":251},[249],"v2.0 additions:\n- location object (supersedes top-level lat\u002Flng\u002Felevation)\n- well_id (array of authority-scoped identifiers)\n- profiles (JSON Schema URLs for regulatory and domain-specific constraints)\n- texture object (multi-vocabulary, replaces v1 fgdc_texture string)\n- hydrodynamic_events (ledger of water-level observations)\n- aquifer_analysis (interpreted aquifer parameter sets)\n- history_logs (operational log of interventions and incidents,\n  with updated_at edit timestamp)\n- optional @context (reserved for JSON-LD interoperability)\n- optional *_precision fields on key measurements\n- WellScreen.screen_slot renamed from screen_slot_mm\n\nv2.0 tightenings:\n- All numeric values are SI by spec. The format does not encode a\n  units declaration; see § Units for the canonical mapping. v1 was\n  de facto SI in practice and no v1 file in existence declared\n  non-SI units, so this is a clarification rather than a breaking\n  change. Display and input units are application concerns.\n\nv2.0 preserves all v1 fields. Parsers must accept v1 documents\nunchanged and must accept the following v1-to-v2 normalizations:\n- Top-level lat\u002Flng\u002Felevation → location.lat\u002Flng\u002Felevation\n- fgdc_texture: \"\u003Ccode>\" → texture: { code, vocabulary: \"fgdc\" }\n- screen_slot_mm → screen_slot (value preserved; both versions are\n  in millimeters)\n- bole_hole → bore_hole (v1 typo compatibility)\n- diam_pol (inches) → diameter (mm), multiplied by 25.4\n",[16,367,365],{"__ignoreMap":254},[222,369],{},[105,371,208],{"id":372},"purpose",[21,374,111,375,377],{},[16,376,18],{}," format is an open standard for representing water well data. It is designed to serve three distinct but complementary use cases:",[21,379,380,383],{},[24,381,382],{},"Visualization."," The format contains sufficient constructive and geological detail to produce accurate technical well profile drawings — including borehole geometry, casing strings, screens, gravel packs, lithological columns, fractures, and caves — at true depth scale.",[21,385,386,389],{},[24,387,388],{},"Registration."," The format captures the administrative and physical identity of a well, providing a complete static record suitable for submission to regulatory bodies, inclusion in national well registries, and long-term archival.",[21,391,392,395],{},[24,393,394],{},"Research."," The structured geological and constructive data, combined with the hydrodynamic event ledger and interpreted aquifer parameters, enables cross-well analysis, aquifer characterization, and hydrogeological research. Field vocabulary choices are aligned with international standards.",[222,397],{},[105,399,214],{"id":400},"design-principles",[116,402,403,412,421,427,436,445,455,461,540,557,566,574,580,594],{},[119,404,405,408,409,411],{},[24,406,407],{},"Self-describing"," — full field names are used throughout; a ",[16,410,18],{}," file can be read and understood without consulting the spec.",[119,413,414,417,418,420],{},[24,415,416],{},"Versioned"," — includes a ",[16,419,239],{}," field for forward compatibility; parsers must reject unrecognized versions.",[119,422,423,426],{},[24,424,425],{},"Self-contained"," — a single file encodes the complete record of one well.",[119,428,429,432,433,435],{},[24,430,431],{},"Units are SI, declared by spec"," — all numeric values in a ",[16,434,18],{}," file are stored in SI units. The format does not encode a per-file units declaration. See § Units for the canonical unit of each quantity. Conversion to and from a user's preferred display or input units is an application concern.",[119,437,438,441,442,277],{},[24,439,440],{},"CRS is declared, not assumed"," — geographic coordinates are accompanied by an explicit coordinate reference system declaration. The default is WGS84 (",[16,443,444],{},"EPSG:4326",[119,446,447,450,451,454],{},[24,448,449],{},"Ground level as zero"," — all depth values are measured from ground level (0); elevation above the WGS84 ellipsoid (or declared datum) is stored separately in ",[16,452,453],{},"location.elevation",". Water levels above ground are negative.",[119,456,457,460],{},[24,458,459],{},"Geographic north"," — all azimuth values are referenced to geographic north.",[119,462,463,466,467],{},[24,464,465],{},"Three block kinds"," — every top-level array is one of three kinds, and the kind decides how records are corrected:\n",[116,468,469,500,518],{},[119,470,471,474,475,127,477,127,480,482,483,486,487,127,490,127,493,496,497,499],{},[24,472,473],{},"Ledger"," (",[16,476,139],{},[16,478,479],{},"production",[16,481,276],{},") — grows by appending. Entries MAY be edited in place, but editing is NOT RECOMMENDED after an entry has been exported. A measurement correction (a re-measurement, a revised laboratory report) is best written as a new entry whose ",[16,484,485],{},"corrects"," points to the retracted entry; a retracted entry stays in the file but is excluded from every derivation. The format provides ",[16,488,489],{},"id",[16,491,492],{},"datetime",[16,494,495],{},"sequence"," and ",[16,498,485],{}," to support this discipline; it does not enforce it.",[119,501,502,474,505,127,507,127,510,513,514,517],{},[24,503,504],{},"Mutable record",[16,506,146],{},[16,508,509],{},"permits",[16,511,512],{},"operating_regime",") — edited in place; ",[16,515,516],{},"updated_at"," records the last edit.",[119,519,520,474,523,127,526,529,530,533,534,537,538,297],{},[24,521,522],{},"Installation",[16,524,525],{},"pump_installations",[16,527,528],{},"meters",") — equipment present in the well for a period (",[16,531,532],{},"installed_at"," \u002F ",[16,535,536],{},"removed_at","); edited in place with ",[16,539,516],{},[119,541,542,545,546,127,549,552,553,556],{},[24,543,544],{},"Derived values are never stored raw"," — ",[16,547,548],{},"s\u002FQ",[16,550,551],{},"Q\u002Fs",", drawdown ",[16,554,555],{},"s",", and any other value computable from stored fields must not appear as stored fields. Applications compute them on demand.",[119,558,559,562,563,565],{},[24,560,561],{},"Jurisdiction neutrality"," — the file records what was measured, never what it means under a given rule. Water quality limits, exceedances and national requirements are not stored and no field names a national standard; limit sets (WHO, EU, Brazil, …) are versioned data in ",[16,564,70],{},", chosen by the consumer at display time, and local obligations (required parameters, sampling frequencies) enter through profiles.",[119,567,568,545,571,573],{},[24,569,570],{},"Interpreted results are versioned",[16,572,143],{}," records which method was used, who performed the analysis, and which events were used as input. Multiple analyses may coexist.",[119,575,576,579],{},[24,577,578],{},"Graceful incompleteness"," — a record with only a flow rate and a dynamic level is valid. A record with only a static level measurement is valid. Validators must not reject incomplete events.",[119,581,582,545,585,587,588,590,591,593],{},[24,583,584],{},"Mutable operational log with edit traceability",[16,586,146],{}," entries are editable to allow correction of field errors. Each entry carries a separate ",[16,589,516],{}," timestamp that records when the entry itself was last modified, distinct from the ",[16,592,492],{}," field that records when the logged event occurred.",[119,595,596,599],{},[24,597,598],{},"Preserve unknown members"," — parsers must preserve and pass through any unrecognized fields or top-level blocks without modification, following the GeoJSON foreign members convention. This ensures forward compatibility.",[222,601],{},[105,603,220],{"id":604},"known-limitations-of-v2",[21,606,607],{},"The following are recognized limitations of this version, reserved for future versions:",[116,609,610,626,634,640,646],{},[119,611,612,615,616,127,619,127,622,625],{},[24,613,614],{},"No internationalization of text fields."," All free-text fields (",[16,617,618],{},"description",[16,620,621],{},"notes",[16,623,624],{},"author",", etc.) are opaque strings with no language tag. A file produced in Brazil will have Portuguese content; one from Norway will have Norwegian. v3 will consider BCP 47 language objects for text fields, with backward-compatible string fallback.",[119,627,628,31,631,633],{},[24,629,630],{},"No interpreted water quality assessment.",[16,632,276],{}," records samples and measured results only. Interpreted assessments (water class, hydrochemical facies as a stored judgment, fitness for use) have no block yet; facies, ion balance and exceedances are derived on demand.",[119,635,636,639],{},[24,637,638],{},"Collective permits are repeated per well."," A grant covering several wells is repeated in each well's file until cross-file references arrive in v3.",[119,641,642,645],{},[24,643,644],{},"No geophysical logs block."," Downhole geophysical surveys (resistivity, gamma ray, caliper) are out of scope for v2 and reserved for v3.",[119,647,648,651,652,655],{},[24,649,650],{},"No multi-well linking."," Storativity determination requires observation well data. The top-level ",[16,653,654],{},"references"," field name is reserved for v3 to link wells across files.",[222,657],{},[21,659,660],{},[661,662,663,665],"em",{},[16,664,18],{}," Format Specification v2.4",{"title":254,"searchDepth":667,"depth":667,"links":668},2,[669,670,671,675,676,679,680,681,682],{"id":107,"depth":667,"text":108},{"id":160,"depth":667,"text":161},{"id":226,"depth":667,"text":169,"children":672},[673],{"id":258,"depth":674,"text":177},3,{"id":266,"depth":667,"text":183},{"id":291,"depth":667,"text":189,"children":677},[678],{"id":306,"depth":674,"text":177},{"id":361,"depth":667,"text":202},{"id":372,"depth":667,"text":208},{"id":400,"depth":667,"text":214},{"id":604,"depth":667,"text":220},"Version: 2.4 Extension: .well Encoding: UTF-8 Base format: JSON MIME type: application\u002Fvnd.well+json JSON Schema: https:\u002F\u002Fwelldot.org\u002Fschema\u002Fv2\u002Fwell.schema.json JSON Schema draft: 2020-12 JSON-LD Context (optional): https:\u002F\u002Fwelldot.org\u002Fcontext\u002Fv2.jsonld Status: v2.0 ratified — shipped in @welldot\u002Fcore v0.2.0 · v2.1 shipped in @welldot\u002Fcore v0.3.0 · v2.3 shipped in @welldot\u002Fcore v0.4.0 · v2.4 shipped in @welldot\u002Fcore v0.5.0","md",{},true,"\u002Fformat\u002Fspec\u002Fv2\u002Foverview","# `.well` File Format Specification — Version 2.4: Overview\n\n**Version:** 2.4 **Extension:** `.well` **Encoding:** UTF-8 **Base format:** JSON **MIME type:** `application\u002Fvnd.well+json` **JSON Schema:** `https:\u002F\u002Fwelldot.org\u002Fschema\u002Fv2\u002Fwell.schema.json` **JSON Schema draft:** 2020-12 **JSON-LD Context (optional):** `https:\u002F\u002Fwelldot.org\u002Fcontext\u002Fv2.jsonld` **Status:** v2.0 ratified — shipped in `@welldot\u002Fcore` v0.2.0 · v2.1 shipped in `@welldot\u002Fcore` v0.3.0 · v2.3 shipped in `@welldot\u002Fcore` v0.4.0 · v2.4 shipped in `@welldot\u002Fcore` v0.5.0\n\n**See also:** [format-reference.md](.\u002Fformat-reference.md) · [object-schemas.md](.\u002Fobject-schemas.md) · [interoperability.md](.\u002Finteroperability.md) · [water-quality.md](.\u002Fwater-quality.md)\n\n## Overview\n\nThe `.well` v2 specification is split into five documents. This one gives the context: what changed in each revision (v2.4, v2.3, v2.1 and from v1), why the format exists, the design principles the other parts follow, and the known limitations. The other four are:\n\n- [format-reference.md](.\u002Fformat-reference.md) — the top-level fields, versioning and deprecation, datetimes, recommended vocabularies, `well_id`, `location`, units, profiles, extensibility, cross-reference rules and precision.\n- [object-schemas.md](.\u002Fobject-schemas.md) — every object schema, the `hydrodynamic_events` ledger, `aquifer_analysis`, `history_logs`, the operational blocks (pumps, permits, meters, production, operating regime) and a complete example.\n- [water-quality.md](.\u002Fwater-quality.md) — water samples and results, their units, the parameter vocabulary and regulatory profiles.\n- [interoperability.md](.\u002Finteroperability.md) — the JSON-LD context, the relationship to GWML2 and JSON Schema validation.\n\n## Table of contents\n\n- [Changes in v2.4](#changes-in-v24)\n  - [Deprecations](#deprecations)\n- [Changes in v2.3](#changes-in-v23)\n- [Changes in v2.1](#changes-in-v21)\n  - [Deprecations](#deprecations-1)\n- [Changes from v1](#changes-from-v1)\n- [Purpose](#purpose)\n- [Design Principles](#design-principles)\n- [Known Limitations of v2](#known-limitations-of-v2)\n\n---\n\n## Changes in v2.4\n\nv2.4 files write `\"version\": \"2.4\"`; parsers up to `@welldot\u002Fcore` 0.4.0 reject them. Beyond that, v2.4 is an additive revision: every valid v2.3 document stays valid when its `version` is rewritten, and the integer `2` still means \"v2.0 to v2.3, revision unknown\".\n\n```\nv2.4 additions:\n- version is the string \"M.m\" (^\\d+\\.\\d+$), compared as two integers,\n  never as text; patch levels are not allowed; readers accept 1, 2 and\n  \"M.m\"\n- location.properties.timezone (optional, IANA name): the local date of\n  an instant is its date converted to this zone; a missing timezone in\n  a file with condition fulfillments emits the warning missing_timezone\n- logger_series (hydrodynamic event type): a continuous level series\n  recorded by an installed sensor, with sensor_depth, interval,\n  barometric_compensation and aggregation (none, hourly, daily with\n  depth_min \u002F depth_max); not a controlled test, not a static level\n- LevelReading.datetime: the instant of a reading, required in a\n  logger_series, where elapsed is absent\n- Offline packaging: an optional ZIP (.wellz) with the .well file at\n  the root and attachments at relative paths; relative uri allowed and\n  sha256 required only inside the package\n- Application extensions: x-\u003Cvendor>-\u003Cname> is RECOMMENDED\n  (e.g. x-welldot-custom)\n\nv2.4 clarifications:\n- A known hydrodynamic event type is validated against its own schema\n  and no longer falls back to the open x- rule; step counts per type\n  are SHOULD (a free count is valid), and steps must be valid\n  PumpingStep entries\n- An optional field without a value is omitted, never written as null\n  (storativity is no longer nullable); v2 integer files that still\n  carry it are tolerated on read\n- Ledgers MAY be edited in place; editing is NOT RECOMMENDED after a\n  record has been exported, and corrects remains the way to retract a\n  measurement. Result.validation is editable too\n- Repeated records (collective permits, campaign blanks) share the\n  same id and SHOULD have identical content; consumers MAY merge them\n  by id. A fulfillment event_id or sample_id resolves only in the file\n  of the well that produced it\n- Unresolved references MUST be preserved when a file is re-exported,\n  never silently removed\n- A duplicated operating_regime.effective_from and an\n  estimated_volume period_end not after period_start are warnings\n- daily_operating_time above 24 is normalized to 24 with a warning\n  (the stored value stays as written); a negative value is an error\n- Attachment.document_type condition_evidence is typically found in\n  permits[].conditions[].fulfillments\n- The attachment lists (id uniqueness, \"root is not an aggregate\",\n  where attachments are allowed) name the same set of records\n- history_logs updated_at may be earlier than datetime for a pre-dated\n  entry; neither ordering emits a warning\n- well_id: producers SHOULD mark exactly one entry primary: true; \"the\n  first entry is canonical\" is only the fallback\n```\n\n### Deprecations\n\nNone.\n\n---\n\n## Changes in v2.3\n\nv2.3 is an additive minor revision. Every valid v2.1 document is a valid v2.3 document, and documents keep declaring `\"version\": 2`. It adds the operational blocks (equipment, documents, permits, metering, production and operating regime) and the water quality block (`water_samples`).\n\n```\nv2.3 additions:\n- attachments (optional Attachment[]): root-level documents about the\n  well as a whole (drilling report, as-built drawing, registry record…)\n- Attachment becomes a common type and gains document_type\n  (drilling_report, as_built_drawing, registry_record, photo,\n  permit_document, condition_evidence, pump_curve, field_sheet,\n  test_report, lab_report, invoice)\n- pump_installations (optional PumpInstallation[]): pump installation\n  history, with nameplate, intake depth, riser and electrical data\n- permits (optional Permit[]): legal instruments governing abstraction\n  (outorga, dispensa, cadastro) with validity, granted flow, daily\n  operating time, volume limits, monthly schedule and conditions\n  (condicionantes) whose deadlines are derived from ISO 8601 date\n  durations; renewals are linked with supersedes. Each permit carries\n  its identifier and\u002For request_identifier (verbatim, any format), a\n  closed administrative status (requested, granted, suspended,\n  revoked, denied, withdrawn), an administrative history (filing,\n  process, notifications, fees, with done\u002Fdue_date and attachments)\n  and, on each condition, a responsible and the fulfillments of its\n  deadlines (datetime, due_date, author, event_id, sample_id,\n  attachments)\n- meters (optional Meter[]): totalizer (hidrômetro) installation\n  history; device facts only (type, serial, nominal diameter,\n  max_reading for rollover)\n- production (optional ProductionEntry[]): ledger of\n  meter_reading entries (register values in m³) and estimated_volume\n  entries (volumes estimated for a period without a meter); volumes\n  are derived from consecutive readings, never stored as totals.\n  Volumes declared to a regulator are not production data: they are\n  the fulfillment of the permit's reporting condition\n- operating_regime (optional OperatingRegime[]): declared flow rate,\n  daily operating time and days per week, each entry in force from\n  effective_from\n- history_logs category status_change, with status (active,\n  maintenance, inactive, decommissioned, abandoned): the well's\n  operating status; current status is unknown without one\n- history_logs category maintenance gains maintenance_type,\n  pump_installation_id and meter_id\n- history_logs gains hydrodynamic_event_ids and sample_ids (any\n  category): references to the data an entry produced or observed,\n  never copies of measured values\n- hydrodynamic_events[].corrects: retracts an earlier event (ledger\n  correction)\n- hydrodynamic_events[].attachments, aquifer_analysis[].attachments\n- Canonical units kW (power), V (voltage), mm² (cable cross-section),\n  m³ (volume), h (daily operating time only)\n- water_samples (optional WaterSample[]): ledger of water samples,\n  each with its field and laboratory results in one list\n  (distinguished by measured_in), sampling point (point depth or\n  isolated interval, or the production pump), purge and stabilization\n  readings, laboratory and chain of custody, field QA\u002FQC\n  (field_duplicate, split_sample via parent_sample_id; blanks),\n  per-result filtration, lab flags and data validation; corrected\n  reports and revalidations are new samples with corrects\n- Parameter identity { code, vocabulary } with vocabularies welldot,\n  cas and x-…; the welldot parameter vocabulary (98 codes) is\n  published as versioned data in @welldot\u002Fcore, with CAS\n  equivalences; the unit of a welldot or cas parameter comes from its\n  code (substances always mg\u002FL), and unit (UCUM) exists only for x-\n  codes\n- Canonical units mg\u002FL, µS\u002Fcm at 25 °C, °C, mV, NTU \u002F FNU \u002F FAU \u002F FTU\n  (by code), Hazen (uH), MPN\u002F100 mL, CFU\u002F100 mL, CFU\u002FmL, Bq\u002FL and µm\n- _resolution convention: analyzed_at_resolution and\n  laboratory.received_at_resolution set to \"day\" mark an instant\n  known only by its date; consumers MUST ignore the time of day\n- permit condition fulfillments gain sample_id (e.g. a water-quality\n  monitoring condition)\n- well_screen[].slot_type (screen design: continuous_slot, slotted,\n  bridge_slot, louver, perforated, nold); type remains the screen\n  material\n- Recommended vocabularies for drilling_method, construction materials\n  (well_case \u002F well_screen \u002F reduction type, riser_material),\n  well_screen slot_type,\n  centralizer steels, cement_pad.type, history_logs severity,\n  measurement_method and aquifer_analysis method; every recommended\n  vocabulary is published by @welldot\u002Fcore with en\u002Fpt labels\n\nv2.3 clarifications:\n- Block kinds: every top-level array is a ledger, a mutable record or\n  an installation; the kind decides how records are corrected\n- Open vocabulary values are stored as their key, never as a\n  translated label\n- Datetime families: legal documents use calendar dates (YYYY-MM-DD),\n  everything else uses RFC 3339 instants\n- Naming rules: no units in field names; nameplate values use the\n  rated_ prefix; time intervals use period_start \u002F period_end\n- supersedes (legal succession between permits) is distinct from\n  corrects (ledger retraction)\n- Permit status and condition deadlines are derived on the local civil\n  date at the well site, never stored\n- Volume derivation is normative: rollover via max_reading, never\n  across two meters, unknown (never zero or negative) where readings\n  do not cover; metered volume takes precedence over estimated\n  volumes\n- history_logs category change_of_use is no longer a recommended\n  value; a change of use is an event entry (the current use lives in\n  well_purpose)\n- Jurisdiction neutrality: water quality limits, exceedances and\n  national rules are never written to the file; limit sets (WHO, EU,\n  Brazil…) are data in @welldot\u002Fcore and local requirements enter\n  through profiles\n```\n\nv2.3 contains no deprecations.\n\n---\n\n## Changes in v2.1\n\nv2.1 is an additive minor revision. Every valid v2.0 document is a valid v2.1 document, and documents keep declaring `\"version\": 2`.\n\n```\nv2.1 additions:\n- well_purpose (optional string[]): intended use(s) of the well —\n  production, monitoring, piezometer, water_level_indicator (INA),\n  observation, exploration, injection, dewatering\n- centralizers (optional Centralizer[]): casing\u002Fscreen centralizers\n  as depth interval + spacing\n- history_logs category `change_of_use`\n\nv2.1 clarifications:\n- well_type describes the construction method only\n- Level sign convention: water levels above ground are negative\n  (made explicit; already implied by \"ground level as zero\")\n```\n\n### Deprecations\n\n| Deprecated              | Replacement                                                                                               | Removal |\n| ----------------------- | --------------------------------------------------------------------------------------------------------- | ------- |\n| `well_type: \"artesian\"` | Construction method in `well_type` (usually `tubular`) + negative `static_level` in `hydrodynamic_events` | v3      |\n\n---\n\n## Changes from v1\n\n```\nv2.0 additions:\n- location object (supersedes top-level lat\u002Flng\u002Felevation)\n- well_id (array of authority-scoped identifiers)\n- profiles (JSON Schema URLs for regulatory and domain-specific constraints)\n- texture object (multi-vocabulary, replaces v1 fgdc_texture string)\n- hydrodynamic_events (ledger of water-level observations)\n- aquifer_analysis (interpreted aquifer parameter sets)\n- history_logs (operational log of interventions and incidents,\n  with updated_at edit timestamp)\n- optional @context (reserved for JSON-LD interoperability)\n- optional *_precision fields on key measurements\n- WellScreen.screen_slot renamed from screen_slot_mm\n\nv2.0 tightenings:\n- All numeric values are SI by spec. The format does not encode a\n  units declaration; see § Units for the canonical mapping. v1 was\n  de facto SI in practice and no v1 file in existence declared\n  non-SI units, so this is a clarification rather than a breaking\n  change. Display and input units are application concerns.\n\nv2.0 preserves all v1 fields. Parsers must accept v1 documents\nunchanged and must accept the following v1-to-v2 normalizations:\n- Top-level lat\u002Flng\u002Felevation → location.lat\u002Flng\u002Felevation\n- fgdc_texture: \"\u003Ccode>\" → texture: { code, vocabulary: \"fgdc\" }\n- screen_slot_mm → screen_slot (value preserved; both versions are\n  in millimeters)\n- bole_hole → bore_hole (v1 typo compatibility)\n- diam_pol (inches) → diameter (mm), multiplied by 25.4\n```\n\n---\n\n## Purpose\n\nThe `.well` format is an open standard for representing water well data. It is designed to serve three distinct but complementary use cases:\n\n**Visualization.** The format contains sufficient constructive and geological detail to produce accurate technical well profile drawings — including borehole geometry, casing strings, screens, gravel packs, lithological columns, fractures, and caves — at true depth scale.\n\n**Registration.** The format captures the administrative and physical identity of a well, providing a complete static record suitable for submission to regulatory bodies, inclusion in national well registries, and long-term archival.\n\n**Research.** The structured geological and constructive data, combined with the hydrodynamic event ledger and interpreted aquifer parameters, enables cross-well analysis, aquifer characterization, and hydrogeological research. Field vocabulary choices are aligned with international standards.\n\n---\n\n## Design Principles\n\n- **Self-describing** — full field names are used throughout; a `.well` file can be read and understood without consulting the spec.\n- **Versioned** — includes a `version` field for forward compatibility; parsers must reject unrecognized versions.\n- **Self-contained** — a single file encodes the complete record of one well.\n- **Units are SI, declared by spec** — all numeric values in a `.well` file are stored in SI units. The format does not encode a per-file units declaration. See § Units for the canonical unit of each quantity. Conversion to and from a user's preferred display or input units is an application concern.\n- **CRS is declared, not assumed** — geographic coordinates are accompanied by an explicit coordinate reference system declaration. The default is WGS84 (`EPSG:4326`).\n- **Ground level as zero** — all depth values are measured from ground level (0); elevation above the WGS84 ellipsoid (or declared datum) is stored separately in `location.elevation`. Water levels above ground are negative.\n- **Geographic north** — all azimuth values are referenced to geographic north.\n- **Three block kinds** — every top-level array is one of three kinds, and the kind decides how records are corrected:\n  - **Ledger** (`hydrodynamic_events`, `production`, `water_samples`) — grows by appending. Entries MAY be edited in place, but editing is NOT RECOMMENDED after an entry has been exported. A measurement correction (a re-measurement, a revised laboratory report) is best written as a new entry whose `corrects` points to the retracted entry; a retracted entry stays in the file but is excluded from every derivation. The format provides `id`, `datetime`, `sequence` and `corrects` to support this discipline; it does not enforce it.\n  - **Mutable record** (`history_logs`, `permits`, `operating_regime`) — edited in place; `updated_at` records the last edit.\n  - **Installation** (`pump_installations`, `meters`) — equipment present in the well for a period (`installed_at` \u002F `removed_at`); edited in place with `updated_at`.\n- **Derived values are never stored raw** — `s\u002FQ`, `Q\u002Fs`, drawdown `s`, and any other value computable from stored fields must not appear as stored fields. Applications compute them on demand.\n- **Jurisdiction neutrality** — the file records what was measured, never what it means under a given rule. Water quality limits, exceedances and national requirements are not stored and no field names a national standard; limit sets (WHO, EU, Brazil, …) are versioned data in `@welldot\u002Fcore`, chosen by the consumer at display time, and local obligations (required parameters, sampling frequencies) enter through profiles.\n- **Interpreted results are versioned** — `aquifer_analysis` records which method was used, who performed the analysis, and which events were used as input. Multiple analyses may coexist.\n- **Graceful incompleteness** — a record with only a flow rate and a dynamic level is valid. A record with only a static level measurement is valid. Validators must not reject incomplete events.\n- **Mutable operational log with edit traceability** — `history_logs` entries are editable to allow correction of field errors. Each entry carries a separate `updated_at` timestamp that records when the entry itself was last modified, distinct from the `datetime` field that records when the logged event occurred.\n- **Preserve unknown members** — parsers must preserve and pass through any unrecognized fields or top-level blocks without modification, following the GeoJSON foreign members convention. This ensures forward compatibility.\n\n---\n\n## Known Limitations of v2\n\nThe following are recognized limitations of this version, reserved for future versions:\n\n- **No internationalization of text fields.** All free-text fields (`description`, `notes`, `author`, etc.) are opaque strings with no language tag. A file produced in Brazil will have Portuguese content; one from Norway will have Norwegian. v3 will consider BCP 47 language objects for text fields, with backward-compatible string fallback.\n- **No interpreted water quality assessment.** `water_samples` records samples and measured results only. Interpreted assessments (water class, hydrochemical facies as a stored judgment, fitness for use) have no block yet; facies, ion balance and exceedances are derived on demand.\n- **Collective permits are repeated per well.** A grant covering several wells is repeated in each well's file until cross-file references arrive in v3.\n- **No geophysical logs block.** Downhole geophysical surveys (resistivity, gamma ray, caliper) are out of scope for v2 and reserved for v3.\n- **No multi-well linking.** Storativity determination requires observation well data. The top-level `references` field name is reserved for v3 to link wells across files.\n\n---\n\n_`.well` Format Specification v2.4_\n",{"title":7,"description":683},"format\u002Fspec\u002Fv2\u002Foverview","uz2bfYd8DjnAYxvFV5MBznl5TyxOKbJYXFRL59mrxeU",{"docs_en":693,"spec":1009,"changelogs":1052},[694,714,733,788,897,951],{"title":695,"path":696,"stem":697,"children":698},"Ai","\u002Fai","ai",[699,702,706,710],{"title":700,"path":696,"stem":701},"Introduction","ai\u002Findex",{"title":703,"path":704,"stem":705},"Converting reports with an assistant","\u002Fai\u002Fconversion-skill","ai\u002Fconversion-skill",{"title":707,"path":708,"stem":709},"llms.txt and Markdown pages","\u002Fai\u002Fllms","ai\u002Fllms",{"title":711,"path":712,"stem":713},"MCP server","\u002Fai\u002Fmcp","ai\u002Fmcp",{"title":715,"path":716,"stem":717,"children":718},"Contributing","\u002Fcontributing","contributing",[719,721,725,729],{"title":700,"path":716,"stem":720},"contributing\u002Findex",{"title":722,"path":723,"stem":724},"Writing docs","\u002Fcontributing\u002Fwriting-docs","contributing\u002F1.writing-docs",{"title":726,"path":727,"stem":728},"Update rules","\u002Fcontributing\u002Fupdate-rules","contributing\u002F2.update-rules",{"title":730,"path":731,"stem":732},"Content components","\u002Fcontributing\u002Fcomponents","contributing\u002Fcomponents",{"title":734,"path":735,"stem":736,"children":737},"Core","\u002Fcore","core",[738,740,753,782],{"title":700,"path":735,"stem":739},"core\u002Findex",{"title":741,"path":742,"stem":743,"children":744,"page":752},"Getting Started","\u002Fcore\u002Fgetting-started","core\u002F1.getting-started",[745,748],{"title":522,"path":746,"stem":747},"\u002Fcore\u002Fgetting-started\u002Finstallation","core\u002F1.getting-started\u002F1.installation",{"title":749,"path":750,"stem":751},"First use","\u002Fcore\u002Fgetting-started\u002Ffirst-use","core\u002F1.getting-started\u002F2.first-use",false,{"title":754,"path":755,"stem":756,"children":757,"page":752},"Guides","\u002Fcore\u002Fguides","core\u002F2.guides",[758,762,766,770,774,778],{"title":759,"path":760,"stem":761},"Parsing and validating","\u002Fcore\u002Fguides\u002Fparsing-and-validating","core\u002F2.guides\u002F1.parsing-and-validating",{"title":763,"path":764,"stem":765},"Serializing and sharing","\u002Fcore\u002Fguides\u002Fserializing-and-sharing","core\u002F2.guides\u002F2.serializing-and-sharing",{"title":767,"path":768,"stem":769},"Unit conversion","\u002Fcore\u002Fguides\u002Funit-conversion","core\u002F2.guides\u002F3.unit-conversion",{"title":771,"path":772,"stem":773},"Vocabularies and textures","\u002Fcore\u002Fguides\u002Fvocabularies-and-textures","core\u002F2.guides\u002F4.vocabularies-and-textures",{"title":775,"path":776,"stem":777},"Water quality vocabulary","\u002Fcore\u002Fguides\u002Fwater-quality-vocabulary","core\u002F2.guides\u002F5.water-quality-vocabulary",{"title":779,"path":780,"stem":781},"Versions and time zones","\u002Fcore\u002Fguides\u002Fversions-and-time-zones","core\u002F2.guides\u002F6.versions-and-time-zones",{"title":783,"path":784,"stem":785,"children":786},"API reference","\u002Fcore\u002Fapi","core\u002Fapi\u002Findex",[787],{"title":783,"path":784,"stem":785},{"title":789,"path":790,"stem":791,"children":792},"Format","\u002Fformat","format",[793,795,815,844,868,887,893],{"title":700,"path":790,"stem":794},"format\u002Findex",{"title":741,"path":796,"stem":797,"children":798,"page":752},"\u002Fformat\u002Fgetting-started","format\u002F1.getting-started",[799,803,807,811],{"title":800,"path":801,"stem":802},"What is .well?","\u002Fformat\u002Fgetting-started\u002Fwhat-is-well","format\u002F1.getting-started\u002F1.what-is-well",{"title":804,"path":805,"stem":806},"For geologists","\u002Fformat\u002Fgetting-started\u002Ffor-geologists","format\u002F1.getting-started\u002F2.for-geologists",{"title":808,"path":809,"stem":810},"For developers","\u002Fformat\u002Fgetting-started\u002Ffor-developers","format\u002F1.getting-started\u002F3.for-developers",{"title":812,"path":813,"stem":814},"Your first .well file","\u002Fformat\u002Fgetting-started\u002Ffirst-well-file","format\u002F1.getting-started\u002F4.first-well-file",{"title":816,"path":817,"stem":818,"children":819,"page":752},"Concepts","\u002Fformat\u002Fconcepts","format\u002F2.concepts",[820,824,828,832,836,840],{"title":821,"path":822,"stem":823},"Depths and intervals","\u002Fformat\u002Fconcepts\u002Fdepths-and-intervals","format\u002F2.concepts\u002F1.depths-and-intervals",{"title":825,"path":826,"stem":827},"Units and precision","\u002Fformat\u002Fconcepts\u002Funits-and-precision","format\u002F2.concepts\u002F2.units-and-precision",{"title":829,"path":830,"stem":831},"Vocabularies","\u002Fformat\u002Fconcepts\u002Fvocabularies","format\u002F2.concepts\u002F3.vocabularies",{"title":833,"path":834,"stem":835},"Profiles","\u002Fformat\u002Fconcepts\u002Fprofiles","format\u002F2.concepts\u002F4.profiles",{"title":837,"path":838,"stem":839},"Versions and deprecation","\u002Fformat\u002Fconcepts\u002Fversions-and-deprecation","format\u002F2.concepts\u002F5.versions-and-deprecation",{"title":841,"path":842,"stem":843},"Extensibility","\u002Fformat\u002Fconcepts\u002Fextensibility","format\u002F2.concepts\u002F6.extensibility",{"title":754,"path":845,"stem":846,"children":847,"page":752},"\u002Fformat\u002Fguides","format\u002F3.guides",[848,852,856,860,864],{"title":849,"path":850,"stem":851},"Writing a .well by hand","\u002Fformat\u002Fguides\u002Fwriting-by-hand","format\u002F3.guides\u002F1.writing-by-hand",{"title":853,"path":854,"stem":855},"Converting a report","\u002Fformat\u002Fguides\u002Fconverting-a-report","format\u002F3.guides\u002F2.converting-a-report",{"title":857,"path":858,"stem":859},"Validating","\u002Fformat\u002Fguides\u002Fvalidating","format\u002F3.guides\u002F3.validating",{"title":861,"path":862,"stem":863},"Extending for your own needs","\u002Fformat\u002Fguides\u002Fextending","format\u002F3.guides\u002F4.extending",{"title":865,"path":866,"stem":867},"Building an editor or database on .well","\u002Fformat\u002Fguides\u002Fbuilding-on-well","format\u002F3.guides\u002F5.building-on-well",{"title":108,"path":869,"stem":870,"children":871},"\u002Fformat\u002Freference","format\u002F4.reference\u002Findex",[872,873,877,881],{"title":108,"path":869,"stem":870},{"title":874,"path":875,"stem":876},"JSON Schema","\u002Fformat\u002Freference\u002Fjson-schema","format\u002F4.reference\u002F1.json-schema",{"title":878,"path":879,"stem":880},"Example wells","\u002Fformat\u002Freference\u002Fexamples","format\u002F4.reference\u002F2.examples",{"title":882,"path":883,"stem":884,"children":885},"Object reference","\u002Fformat\u002Freference\u002Fobjects","format\u002Freference\u002Fobjects\u002Findex",[886],{"title":882,"path":883,"stem":884},{"title":888,"path":889,"stem":890,"children":891},"About the spec","\u002Fformat\u002Fspec","format\u002F5.spec\u002Findex",[892],{"title":888,"path":889,"stem":890},{"title":894,"path":895,"stem":896},"Changelog","\u002Fformat\u002Fchangelog","format\u002F6.changelog",{"title":898,"path":899,"stem":900,"children":901},"Render","\u002Frender","render",[902,904,914,946],{"title":700,"path":899,"stem":903},"render\u002Findex",{"title":741,"path":905,"stem":906,"children":907,"page":752},"\u002Frender\u002Fgetting-started","render\u002F1.getting-started",[908,911],{"title":522,"path":909,"stem":910},"\u002Frender\u002Fgetting-started\u002Finstallation","render\u002F1.getting-started\u002F1.installation",{"title":749,"path":912,"stem":913},"\u002Frender\u002Fgetting-started\u002Ffirst-use","render\u002F1.getting-started\u002F2.first-use",{"title":754,"path":915,"stem":916,"children":917,"page":752},"\u002Frender\u002Fguides","render\u002F2.guides",[918,922,926,930,934,938,942],{"title":919,"path":920,"stem":921},"Panels and layout","\u002Frender\u002Fguides\u002Fpanels-and-layout","render\u002F2.guides\u002F1.panels-and-layout",{"title":923,"path":924,"stem":925},"Layers and labels","\u002Frender\u002Fguides\u002Flayers-and-labels","render\u002F2.guides\u002F2.layers-and-labels",{"title":927,"path":928,"stem":929},"Theming","\u002Frender\u002Fguides\u002Ftheming","render\u002F2.guides\u002F3.theming",{"title":931,"path":932,"stem":933},"Locale and units","\u002Frender\u002Fguides\u002Flocale-and-units","render\u002F2.guides\u002F4.locale-and-units",{"title":935,"path":936,"stem":937},"Legends","\u002Frender\u002Fguides\u002Flegends","render\u002F2.guides\u002F5.legends",{"title":939,"path":940,"stem":941},"Zoom, pan and highlights","\u002Frender\u002Fguides\u002Finteraction","render\u002F2.guides\u002F6.interaction",{"title":943,"path":944,"stem":945},"Using it in a framework","\u002Frender\u002Fguides\u002Fframeworks","render\u002F2.guides\u002F7.frameworks",{"title":783,"path":947,"stem":948,"children":949},"\u002Frender\u002Fapi","render\u002Fapi\u002Findex",[950],{"title":783,"path":947,"stem":948},{"title":952,"path":953,"stem":954,"children":955},"Utils","\u002Futils","utils",[956,958,968,1004],{"title":700,"path":953,"stem":957},"utils\u002Findex",{"title":741,"path":959,"stem":960,"children":961,"page":752},"\u002Futils\u002Fgetting-started","utils\u002F1.getting-started",[962,965],{"title":522,"path":963,"stem":964},"\u002Futils\u002Fgetting-started\u002Finstallation","utils\u002F1.getting-started\u002F1.installation",{"title":749,"path":966,"stem":967},"\u002Futils\u002Fgetting-started\u002Ffirst-use","utils\u002F1.getting-started\u002F2.first-use",{"title":754,"path":969,"stem":970,"children":971,"page":752},"\u002Futils\u002Fguides","utils\u002F2.guides",[972,976,980,984,988,992,996,1000],{"title":973,"path":974,"stem":975},"Geometry and volumes","\u002Futils\u002Fguides\u002Fgeometry-and-volumes","utils\u002F2.guides\u002F1.geometry-and-volumes",{"title":977,"path":978,"stem":979},"Water levels and pumping tests","\u002Futils\u002Fguides\u002Fpumping-tests","utils\u002F2.guides\u002F2.pumping-tests",{"title":981,"path":982,"stem":983},"Permits","\u002Futils\u002Fguides\u002Fpermits","utils\u002F2.guides\u002F3.permits",{"title":985,"path":986,"stem":987},"Operation and production","\u002Futils\u002Fguides\u002Foperation","utils\u002F2.guides\u002F4.operation",{"title":989,"path":990,"stem":991},"Water quality","\u002Futils\u002Fguides\u002Fwater-quality","utils\u002F2.guides\u002F5.water-quality",{"title":993,"path":994,"stem":995},"Logger import","\u002Futils\u002Fguides\u002Flogger-import","utils\u002F2.guides\u002F6.logger-import",{"title":997,"path":998,"stem":999},"SIAGAS import","\u002Futils\u002Fguides\u002Fsiagas-import","utils\u002F2.guides\u002F7.siagas-import",{"title":1001,"path":1002,"stem":1003},"Formatting","\u002Futils\u002Fguides\u002Fformatting","utils\u002F2.guides\u002F8.formatting",{"title":783,"path":1005,"stem":1006,"children":1007},"\u002Futils\u002Fapi","utils\u002Fapi\u002Findex",[1008],{"title":783,"path":1005,"stem":1006},[1010],{"title":789,"path":790,"stem":791,"children":1011,"page":752},[1012],{"title":1013,"path":889,"stem":1014,"children":1015,"page":752},"Spec","format\u002Fspec",[1016,1025,1034],{"title":1017,"path":1018,"stem":1019,"children":1020,"page":752},"Reference","\u002Fformat\u002Fspec\u002Freference","format\u002Fspec\u002Freference",[1021],{"title":1022,"path":1023,"stem":1024},"FGDC Texture Patterns Reference","\u002Fformat\u002Fspec\u002Freference\u002Ffgdc-textures","format\u002Fspec\u002Freference\u002Ffgdc-textures",{"title":1026,"path":1027,"stem":1028,"children":1029,"page":752},"V1","\u002Fformat\u002Fspec\u002Fv1","format\u002Fspec\u002Fv1",[1030],{"title":1031,"path":1032,"stem":1033},".well File Format Specification","\u002Fformat\u002Fspec\u002Fv1\u002Fwell-format","format\u002Fspec\u002Fv1\u002Fwell-format",{"title":1035,"path":1036,"stem":1037,"children":1038,"page":752},"V2","\u002Fformat\u002Fspec\u002Fv2","format\u002Fspec\u002Fv2",[1039,1042,1045,1048,1049],{"title":1040,"path":89,"stem":1041},".well File Format Specification — Version 2.4: Format Reference","format\u002Fspec\u002Fv2\u002Fformat-reference",{"title":1043,"path":98,"stem":1044},".well File Format Specification — Version 2.4: Interoperability","format\u002Fspec\u002Fv2\u002Finteroperability",{"title":1046,"path":94,"stem":1047},".well File Format Specification — Version 2.4: Object Schemas","format\u002Fspec\u002Fv2\u002Fobject-schemas",{"title":7,"path":687,"stem":690},{"title":1050,"path":102,"stem":1051},".well File Format Specification — Version 2.4: Water Quality","format\u002Fspec\u002Fv2\u002Fwater-quality",[1053,1058,1064],{"title":734,"path":735,"stem":736,"children":1054,"page":752},[1055],{"title":70,"path":1056,"stem":1057},"\u002Fcore\u002Fchangelog","core\u002FCHANGELOG",{"title":898,"path":899,"stem":900,"children":1059,"page":752},[1060],{"title":1061,"path":1062,"stem":1063},"@welldot\u002Frender","\u002Frender\u002Fchangelog","render\u002FCHANGELOG",{"title":952,"path":953,"stem":954,"children":1065,"page":752},[1066],{"title":1067,"path":1068,"stem":1069},"@welldot\u002Futils","\u002Futils\u002Fchangelog","utils\u002FCHANGELOG",1793050495100]