Skip to content

History / has_correct_winding

Revisions

  • Spell operators and value types the way the engine registers them (#1161) The token table is case folded, so a page that writes UInt32, AsList or NrOfRows teaches a spelling that costs the reader a case mix-up warning on the first run. This rewrites those spellings across 142 pages to the names the engine actually registers, taken from the running engine rather than from memory: the 2342 operator group names that DocData()/OperatorGroups/name reports, plus the property names in TicPropDefConst.h. Four kinds of change, all case only: * value types in configuration examples -- String, Float64, SPoint, UInt32, Bool, Void and the *Seq variants -> lower case, which is what ValueWrap.cpp has registered (AsLowerCase of the C++ type name) since 20.9. * the boolean literals True/TRUE/False/FALSE in expressions and data lists. Property VALUES keep their spelling: StorageReadOnly = "False" is data. * operator names, in examples and in the syntax/definition lines of the operator pages: asList, asItemList, expand, currentDir, makeDir, get_x, get_y, pointrow, pointcol, id, range, subset, replace, quote, dquote, isNegative, isPositive, isZero, the *seq conversions -- and the other way for the ones the engine capitalises: BaseUnit, IsDefined, LowerBound, UpperBound, Round, RoundUp, RoundDown, RoundToZero, LowerCase, AsHex, SubItem, SubItem_PropValues, GeoDmsVersion, EXEC_EC. * nrofrows, both as the operator and as the unit property. Five examples named an item after the operator it called, which folds onto the operator's own token: MakeDir, GeoDMSVersion, Quote. Those items are renamed (newFolder, versionString, Quoted). DocData's sub-item is name, not Name. IntegrityCheck and expr property values are parsed as expressions, so the operator inside the string counts too. Value-type gains a "spelling" section and Naming-conventions a bullet saying that operator names must be written as registered -- most lower case, but not all -- both linking to the case mix-up section of Tree-item-name. NOT touched, and left as one decision rather than half-made here: the mixed-case PROPERTY names. The engine registers Label, Expr, Descr, Metric, Format, Source, Using, Projection, ValueType, IsHidden, and the pages (like nearly every real configuration) write label, expr, descr, source, using. Whether the wiki follows the engine or the engine follows the corpus is the same question #1161 deferred for the ~57 property names; it should be settled once, in one place. Also left: SQL keywords inside SqlString values, Python API names, and example item names that merely collide with an engine name (Name, District, Area, Union, Left). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

    @MaartenHilferink MaartenHilferink committed Aug 28, 2026
  • Document the winding-order operators (GeoDMS #302) New pages for reverse_polygon, fix_winding_order, fix_polygon and has_correct_winding, listed under a "Ring order (winding)" heading in polygon-operators. Point-order-in-polygons: replace the "check the sign of area()" advice with has_correct_winding, and add a symptom-to-operator table. The sign test is kept but demoted, because it only catches a feature whose rings are ALL flipped; one flipped lake makes the total too large rather than negative. Also spells out why reversing the whole point sequence does not work on a multi-polygon. Area: the same caveat, where readers of that page will hit it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

    @MaartenHilferink MaartenHilferink committed Aug 25, 2026