8000 Feature generation Strategy (question) · Issue #3 · 3l-gee/delorean · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Feature generation Strategy (question) #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
3l-gee opened this issue Mar 18, 2025 · 1 comment
Open

Feature generation Strategy (question) #3

3l-gee opened this issue Mar 18, 2025 · 1 comment
Assignees
Labels
question Further information is requested

Comments

@3l-gee
Copy link
Owner
3l-gee commented Mar 18, 2025

links

Generating AIXM feature presents several challenges. They have to follow strict validation rules, business rules as well as temporality constraints. The data generation of AIXM feature should follow the following principle.

  • Feature can be created / decomissioned
  • Feature can be edited (new timeslice)
  • Feature can be corrected (same timeslice times new correction number)
  • Changes should be prevented if they are illegal (data, business and temporal)
  • Changes should correct the features version slices structure (new change closes last change)
@3l-gee 3l-gee added the question Further information is requested label Mar 18, 2025
@3l-gee 3l-gee self-assigned this Mar 18, 2025
@3l-gee 3l-gee pinned this issue Mar 18, 2025
@3l-gee
Copy link
Owner Author
3l-gee commented Apr 17, 2025

After some testing, idea 2 is now clearer:

Feature should always show all its attributes, Feature should also make its associations to and from accessible. Associations can be to objects or to features. In the XML form of aixm, features are associated via xlinks containing href and a title, whereas objects are contained directly in the feature.

Postgresql :

The view will contain everything that is required to display for the user as well as what must be given back to handel changes, updates, actions and forms.

View :

  • delorean internal :
    • type of change : change / correction
  • feature attributes :
    • aixm_attribute _name : value uom / (nilreason)
  • feature associations from :
    • object :
      • aixm_attribute _name : value uom / (nilreason)
    • feature :
      • aixm_property_name : value uom / (nilreason)
      • aixm_associations_role _title : title / (nilreason)
      • aixm_associations_role_href : href / (nilreason)
  • feature associations to (in cases that make sense):
    • feature :
      • aixm_property_name : value uom / (nilreason)
      • aixm_associations_role _title : title / (nilreason)
      • aixm_associations_role_href : href / (nilreason)

Function & Trigger:

While the user should be allowed to edit the feature as they wish, the aixm timeslices model must reflect their changes in the form of timeslices, which means that edits must be captured and processed as inserts in the feature and in the object, with the required correction in the timeslices. This is challenging in cases where there is a join table where the unique ID needs to be generated and inserted so that everything fits together.

  • on view edit (change)
    • Insert feature table
    • Insert object table
    • Insert other feature table
    • update timeslices
  • on view edit (correction)
    • Insert feature table
    • Insert object table
    • Insert other feature table
    • update timeslices
  • on view insert
    • Insert feature table
    • Insert object table
    • Insert other feature table
Timeslice Handling:
  • Each edit or correction results in a new timeslice entry.

  • correctionNumber, sequenceNumber, and validTime are updated automatically based on existing logic.

  • Helper functions (to be defined) will handle sequence management, validation of overlap/gaps, and setting appropriate timestamps.

ID Generation Logic:
  • Unique IDs required for insertions (feature IDs, object IDs, association IDs) will be generated via PostgreSQL sequences.

  • These will be created for each relevant table, and ID generation will be handled inside the trigger functions to ensure consistency across insertions.

  • In cases involving association tables (feature-to-feature or feature-to-object), new IDs must also be generated on the fly and stored correctly.

QGIS :

QGIS will handle the display, data generation and navigation through forms, actions and styles, which will be loaded into the DB project and made available to the user once Delorean is set up.

Layer :

  • Action to open the feature table, while selecting the right feature.
  • Style to displayer the feature
  • Form to hide id, and format the result

Layout :

(TODO)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant
0