Skip to content
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

Standard für Prozess Geo-Daten-Pflege #9

Open
JohannSfk opened this issue May 22, 2023 · 2 comments
Open

Standard für Prozess Geo-Daten-Pflege #9

JohannSfk opened this issue May 22, 2023 · 2 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@JohannSfk
Copy link

Wir erhalten Geodaten in regelmäßigen Abständen, z.B: bei Reports der Consultants.

Als ersten Effekt könnte dies zunächst zur Folge haben, dass diese Daten redundant hochgeladen werden und an einem Ort zig Dubletten entstehen.

Es könnten grundsätzlich auch alle vorhandenen Daten eines Projekts neu gesendet werden, oder es könnten nur geänderte Daten gesendet werden.
Dies hat als nächstes zur Folge, dass der Anwender alle erhaltenen Daten auf Änderungen untersuchen muss.
Absichtlich Redundant werden die Daten aber auch dadurch, dass GeoDaten von Projekte "in Planung" gesendet werden könnten und auch später im Verlauf mit Umsetzungsphasen. Dann entstehen auch wieder historisch gewachsene und unnötige Datensätze mit doppelten Pins auf der Landkarte.
Potenziell entsteht "ein Wust" an Daten.
Neben diesen Konsistenzfragen ist der Pflegeprozess, gerade bei doppelten Daten oder einzelnen Änderungen EXTREM unnötig aufwendig!

Wichtig wäre daher, wenn die Datenanlieferung Standardisiert würde und z.B. nach aller-erster Meldung nur noch Datenänderungen zu einem Projektdatensatz hinzugeladen werden.
Dies setzt aber wieder eine eindeutige ID der Geodatensätze voraus (?!).
Alternativ könnten immer alle Daten neu gemeldet werden, wodurch aber auch das Risiko entsteht, dass Daten durch Überschreiben gelöscht werden.

@fretchen
Copy link
Collaborator

fretchen commented May 31, 2023

Hi,

so let us try to puzzle through the exact process that you have in mind and then it might get a bit easier to find a solution. My most important question:

  1. Will we be able to solve the problem through a well designed data template. Then it sounds like we can try to solve the issue here.
  2. Will this involve some kind of nicely thought-through storage of the templates (versioning etc). Then we might have to delegate the question to the repo that focuses on the storage etc.

So let me try to understand what you have in mind:

  1. A consultant provides us with a filled out excel sheet. They do the best they can, but errors and missing entries are always possible.
  2. An update comes in, whatever the update is.

The question is then how the update can be stored right ? So this sounds too me as if we are describing a problem that is more about the storage then the template itself ? Suppose the following:

  • The data set for each project has a unique identifer.
  • Only the most recent excel sheet is considered up-to-date.

Does this approach have any of the problems that you described above ?

As how to close this issue

It sounds like might have to think about a short paragraph somewhere in the documentation that describes the recommended way of storing updates once we agreed on one ?

@Jo-Schie what do you think ?
@Maja4Dev ideas ?

@fretchen fretchen added bug Something isn't working good first issue Good for newcomers labels May 31, 2023
@Maja4Dev
Copy link
Collaborator

Maja4Dev commented Jul 3, 2023

Every project location has a unique identifier, see the documentation.

My approach would be that each kexcel template upload automatically replaces the former version. But you can insert quality routines into this process (e.g. archiving the earlier versions including a (semiautomated) review of changes).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants