Tab file not configured

[sjib]

In the new project file the tab "file" seems not be configured:

• [x] no value list for kind
• [x] no link to organisation for provider / dataowner
• [x] no possibility to select data_media
• [ ] no possibility to select the file and automatically add the file name (in identifier) and relative_path.

This looked much better on qgep and in the presentation of Zermatt (see slide 9)

[sjib]

The mask for adding new files looks much better now:

I have changed to 3.34.8 now - but I still do not get the files connected listed and cannot save a new file - they do not show up.

[sjib]

• [x] no possibility to select the file and automatically add the file name (in identifier)

• [ ] and relative_path (this part I still have to fill in manually. It would be nice if it crops of the relative_path based on the absoulte path defined in data_media.

May be we need some code here. Also it does not automatically show images / videos I have imported via INTERLIS into the class file.

[sjib]

We have a view vw_file that has an additional _url attribut that takes puts together absolute and relative path

SELECT f.obj_id,
    f.identifier,
    f.kind,
    f.object,
    f.classname,
    COALESCE(dm.path || f.path_relative, f.path_relative) AS _url,
    f.fk_dataowner AS dataowner,
    f.fk_provider AS provider,
    f.remark
   FROM tww_od.file f
     LEFT JOIN tww_od.data_media dm ON dm.obj_id::text = f.fk_data_media::text;

If I create a file entry manually the identifier gets also a path, depending on what settings the form for the file has either identifier = filename xxx.jpg (second example) or a filename with a relative path (first example).

Maybe we have to change the vw_file._url so it contains the full path and filename: C:\Daten\QGEP\inspectiondata\20210120\fotos\1.045-1.040_0001.jpg and use _url to display and select a document.

And then use some fonctionality to split that full path again into

• identifier (only 1.045-1.040_0001.jpg)
• relative_path inspectiondata\20210120\fotos\ (cut of absolute path of linked data_media object)

Question: Do we really need to link different classes to file? Does this not only makes the tab complicated? What about all other classes (maybe not needed so often?)

@urskaufmann @kay-korrodi @taetscher what do you think? Any other ideas or experiences?

[Kay-Korrodi]

Thank you for your question. My opinion: I only need files for reach and structure/manhole. (I do not need it for node and cover, the cover is in my opinion only an information for the structure and the node is a sideproduct 😆) The links should be full paths. I think when you want to open it from any device it is importand to have full links. The problems i had on qgep: the links were to short. it would be helpfull if they are longer on tww / if you work with cloud based servers they will be longer for sure...

When you have plans (PAW) as pdf / jpg or what ever from a project you will use this one plan for all reachs but here is the question if it is not better to have an area of the plan sice that can be shown on the gis. we do not use it on all reachs or manholes at the same time / makes no sence for me. We only use files for Photos / Plans of the manhole or structer or callculations. These are always just for one object. well for the reach its the same.

for files it is very importand to have a good system how you save and keep in mind that the path should not be changed... (Not importand for your question)

For links to pallon we use the "Haltunsereignis"

i am not sure if this helps but well it is just to show you how we work at zermatt

[taetscher]

I would +1 the answer from @Kay-Korrodi - having access to a full path is nice, but only if there are no conflicts with restrictions in string length. Capping attributes that contain URLs at a certain length to me does not seem very useful when connecting data from different sources, where the user might not always be able to control the lenght of URLs (it may also be that I am missing something basic here. If so, please let me know). Using two attributes and combining base-path and filename - while possible - to me seems unnecessarily cumbersome.

If I understand your question about linking files to different classes correctly (whether or not a file should be linkable to every other class in the datamodel) I would suggest implementing that as modeled in VSA-KEK, which in the latest .ili states that

!!@ comment = "Die Klasse Datei kann eine Assoziation mit jeder Klasse des VSA-DSS Datenmodells eingehen." CLASS Datei EXTENDS VSA_BaseClass =

In the KEK 2020.1 .ili there are, however, also length restrictions for filepaths:

!!@ comment = "" Relativpfad = TEXT*200;

and

!!@ comment = "" Pfad = TEXT*1023;

I assume KEK was modelled at a time when hosting large datasets of inspection data on cloud-servers was not a thing, so maybe URL length restrictions should be discussed with the next iteration of the KEK datamodel.

In essence, I would suggest following the .ili definitions as closely as possible in order to be able to guarantee that valid exports of data in a TEKSI WW database are possible without complex data manipulation.

---

Maybe we have to change the vw_file._url so it contains the full path and filename: C:\Daten\QGEP\inspectiondata\20210120\fotos\1.045-1.040_0001.jpg and use _url to display and select a document. And then use some fonctionality to split that full path again into identifier (only 1.045-1.040_0001.jpg) relative_path inspectiondata\20210120\fotos\ (cut of absolute path of linked data_media object)

From another project I have code that should do what you described here. I'll paste it below, maybe it's useful

CREATE OR REPLACE FUNCTION dokumente_kataster.populate_docname_from_url()
  RETURNS "trigger" AS
$BODY$
DECLARE
BEGIN
  NEW.docname := reverse(split_part(reverse(reverse(split_part(reverse(NEW.doc_url), '\', 1))), '/', 1));
  RETURN NEW;
END
$BODY$
  LANGUAGE 'plpgsql' VOLATILE;

[Kay-Korrodi]

Good Morning boys of gis There is a question from my side: why you need as identifier anyway the name of the document it can also be a globalid... i do not see any use in identifier as document name especially when you work with a documentmanagementsystems where documents can have just an id (globalid) as name... Kind regards from the mountains 😺