Conversation
Use `XMLStreamWriter` instead of `StringBuilder`.
…r USE_SURFACE_RING_CURVE CurvePolygon now serializes as gml:Surface with gml:PolygonPatch; gml:Ring holds curve members directly (it is implicitly a CompositeCurve). CompoundCurve serializes as gml:CompositeCurve. Adds Spock tests for LineString, Polygon, CurvePolygon (CircularString and CompoundCurve rings), and CompoundCurve.
Introduce an optional `alias` property on FeatureSchema as an identifier-style alternative property name (distinct from the display-oriented `label`). Encoders that opt in via a `useAlias` flag receive the alias as the property name; explicit `rename` transformations still take precedence. Plumbed via a new 3-arg getSchemaTransformations(mapping, inCollection, useAlias) overload and a useAlias-aware constructor on SchemaTransformerChain. The chain injects a synthetic rename to the alias only when no explicit (non-pathOnly) rename exists at the property's exact path; pathOnly renames do not suppress the alias. Avoids the duplication of large `rename` transformation maps in per-format building-block configurations when an application schema (e.g. AdV NAS) has both a short and a mnemonic name per property.
Add a default boolean useAlias() predicate on PropertyTransformations (defaults to false) and have FeatureTokenTransformerMappings forward that predicate to the 3-arg getSchemaTransformations() overload added in the previous commit. This is the encoding-side wiring for the alias mechanism: only the feature-encoding pipeline reads useAlias(). Schema-derivation paths (WithTransformationsApplied for queryables, sortables, JSON Schema documents, etc.) call the 2-arg getSchemaTransformations() and so continue to use schema names regardless of any format configuration's alias preference. When useAlias=true, walk the feature schema and inject each property's alias as an explicit rename into propertyTransformations before applyRename. This re-keys every downstream transformation (wrap for virtual objects, auto-DATETIME formatter, value transformers, …) by the aliased path, so schema lookups, SchemaTransformerChain, and TokenSliceTransformerChain all see consistent aliased paths. useAlias() is propagated through PropertyTransformations.mergeInto and withSubstitutions.
applyRename rebuilt the propertyTransformations map keyed by the rename target. For a top-level rename (e.g. qag -> qualitaetsangaben) the single-element rename matched the renamed full path. For nested renames the key was only the leaf rename, not the cumulative renamed path - so the lookup at runtime (which uses the full target path) missed any transformation registered for the inner property. Two symptoms when nested renames were configured: 1. The auto-added DATETIME formatter (provider-level, keyed by the original full path) was re-keyed by just the leaf rename. A DATETIME leaf inside a renamed object came through as the raw JDBC string instead of ISO-8601. 2. Wrap transformers for virtual objects (intermediate OBJECT levels without sourcePath) were similarly mis-keyed. The token-slice wrap step did not fire for those intermediates, so OBJECT/OBJECT_END tokens were never synthesized and the renamed inner objects disappeared from the output. Both symptoms have the same root cause and the same fix: walk the parent chain and apply each segment's rename so the new key is the full renamed path.
…ersion Move alias handling out of PropertyTransformations and SchemaTransformerChain. Aliases are now converted to explicit rename transformations by a single utility, FeatureSchemaAliases.injectAliasRenames, called by ldproxy at the format-extension boundary. The xtraplatform-spatial pipeline downstream of that point no longer knows about aliases — it just sees regular renames and reuses the existing rename cascade machinery for everything else (wrap transformers on virtual objects, auto-DATETIME formatters, value transformers, ...). Removed: - PropertyTransformations.useAlias() predicate and its propagation through mergeInto and withSubstitutions - 3-arg PropertyTransformations.getSchemaTransformations overload - SchemaTransformerChain.useAlias field, 4-arg constructor, in-chain alias-injection branch, and hasExplicitRename helper Added: - FeatureSchemaAliases public utility with injectAliasRenames(pt, schema) - FeatureSchemaAliasesSpec covering nested paths, no-aliases, existing transformations, and a feature-type alias being ignored The cross-module boundary now carries only PropertyTransformations; the useAlias signal stays inside ldproxy's AliasConfiguration where it belongs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of ldproxy/ldproxy#1619.