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

Tab file not configured #272

Open
3 of 4 tasks
sjib opened this issue Jun 25, 2024 · 6 comments
Open
3 of 4 tasks

Tab file not configured #272

sjib opened this issue Jun 25, 2024 · 6 comments
Labels
QGIS project Concern the .qgs QGIS project

Comments

@sjib
Copy link
Contributor

sjib commented Jun 25, 2024

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

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

20240625_tab_file_form_not_configured2
20240625_tab_file_form_not_configured

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

@sjib sjib added the QGIS project Concern the .qgs QGIS project label Jun 25, 2024
@sjib
Copy link
Contributor Author

sjib commented Jul 16, 2024

The mask for adding new files looks much better now:
20240716_add_file_3 34 8_dialog_relative_path_not_automatically_added

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
Copy link
Contributor Author

sjib commented Jul 16, 2024

  • 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
Copy link
Contributor Author

sjib commented Jul 16, 2024

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

20240716_vw_file_data

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;

20240716_tww_od file_data

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

20240716_data_media_data

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

20240716_beziehungen_project
20240716_document_beziehungseditor

@urskaufmann @Kay-Korrodi @taetscher what do you think? Any other ideas or experiences?

@Kay-Korrodi
Copy link

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.
Screenshot 2024-07-16 181550

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"
Screenshot 2024-07-16 181702

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

@taetscher
Copy link

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
Copy link

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 😺

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QGIS project Concern the .qgs QGIS project
Projects
None yet
Development

No branches or pull requests

3 participants