openkfw / open-geodata-model

Open Geodata Model for Mapping Project Sites in ODA
https://openkfw.github.io/open-geodata-model/
Other
4 stars 8 forks source link

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

Open JohannSfk opened 1 year ago

JohannSfk commented 1 year ago

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 commented 1 year ago

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:

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 ?

Maja4Dev commented 1 year ago

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).