we can discuss here about possible solutions based on this doc

https://docs.google.com/document/d/1E8t_42lZJWBUTb9CVyo_JYXZ0YaRR0Z22eTN6pjL8Mg/edit

I think that one of the first step should be to agree on the way we use the db. I will try to resume the ones we discussed and write down pros and cons.

1. We use editing mode as it is right now.
   *+ keep usual way of editing
   *- we cannot use object that are not in the db yet, and therefore we cannot create objects in a chain
2. We save the element in the db as soon as they are created
   *+ can create objects in chain
   *- not usual way of editing in qgis
   *- no undo redo
3. We create the uuid in qgis
   *+ we can create objects in chain
   *+ we can use undo redo
   *+ we keep editing mode style, i.e. start and stop editing
4. We use negative ids of qgis
   *+ the same as for choice 3
   *- we need to create rules for insertion by using the correct ids and doing the insertion in a special order to avoid the break of foreign keys.

In all of the four cases, it should not be a problem to use something else than Postgres. It might be useful for a small town with a single user to use qgis with SQLite, as there is no special setup...

We need a table listing all tables and their 2 character abbreviations in different languages.

Proposal:

CREATE TABLE qgep.is_dictionary
(
id integer NOT NULL,
tablename text,
name_en text,
shortcut_en character(2),
name_de text,
shortcut_de character(2),
name_fr text,
shortcut_fr character(2),
CONSTRAINT pkey_qgep_is_dictonary_id PRIMARY KEY (id ),
CONSTRAINT unq_qgep_is_dictonary_tablename UNIQUE (tablename )
)
WITH (
OIDS=FALSE
);

The content of the tablename column and the shortcut columns should be all lowercase. Please take into account when generating the INSERT statements.

The "is_" prefix stands for infrastructure, as opposed to "vl_" (value list) and "od_" (ordinary data ;-))

Individual reaches should be labeled (E1, E2, E3, etc.) - should be labeled along the reach close to the manhole.

Order: first the bigger reaches and then the smaller ones or clock-wise.
Only the important channels (Sammelkanal, etc.)

Sample should be attached (graphic)

in order to display the manholes with a color related to their current usage it would be necessary to have a "usage_current" field either at the "od_manhole" table or at the "od_wastewater_structure" table.

Currently, we have "usage_current" at the tables "od_channel" and "od_pump".

There is a function that can read the "usage_current" from the incoming "od_channel"s, but for performance reasons it would be better to store this field directly and update it from a trigger, rather than calculating it from a database function for each view of each manhole.

We need to create icons for the QGEP editing toolbar. Is there already something around from GepView?

Upload zip-file with current version of qgep plugin and a corresponding XML file describing the plugin.

http://plugins.qgis.org/plugins/plugins.xml

One should be able to print out the length-profile with provieded separate scales for length and elevation.

Idea: if possible integrate this as a new item type in print composer

Description here: https://github.com/qgep/QGEP/wiki/Demo-project

• Navigation tools: zoom/pan, zoom to full extent
• Mouse over for exact elevations at nodes
• Additional attribute display with tooltips for reaches/channels and manholes
• link between profile and map with highlighting

Try to get this financed from others. Crowd funding.

asdf

I think that one of the first step should be to agree on the way we use the db. I will try to resume the ones we discussed and write down pros and cons.

1. We use editing mode as it is right now.
2. keep usual way of editing
3. we cannot use object that are not in the db yet, and therefore we cannot create objects in a chain
4. We save the element in the db as soon as they are created
5. can create objects in chain
6. not usual way of editing in qgis
7. no undo redo
8. We create the uuid in qgis
9. we can create objects in chain
10. we can use undo redo
11. we keep editing mode style, i.e. start and stop editing
12. We use negative ids of qgis
13. the same as for choice 3
14. we need to create rules for insertion by using the correct ids and doing the insertion in a special order to avoid the break of foreign keys.

In all of the four cases, it should not be a problem to use something else than Postgres. It might be useful for a small town with a single user to use qgis with SQLite, as there is no special setup...

On various tables we must translate the datenherr/datenlieferant to english.

E.g. od_wastewater_structure

In the table od_catchment_area the four foreign keys to the table od_wastewater_network element are missing.

It would be better if the PDF with the ER-diagram would be selectable/searchable text.

Postgres Datatypes Definition: www.postgresql.org/org/docs/9.3/interactive/datatype-numeric.html

Details: http://wiki.ispirer.com/sqlways/postgresql/data-types/decimal_numeric
Schema numeric[p,s], p is maximum number of ALL digits, s after decimal point

5000.00 is numeric [7,3] not [4,3]

• "examination" should be replaced by "inspection" (as in TV inspection)

In the value lists, all the elements have underscores instead of spaces and not accent.

I suppose this is wanted, but why?

Need to discuss if we can extend the data model to allow rotation of manhole symbols (e.g. Oelabscheider).

If yes, which table should it be added to? od_wastewater_node or od_manhole or other table?

How should this be solved?

• A table with a view showing the most recent and active entries
• A table where all the insert/update/delete modifications are saved per attribute

Interesting entry on stackoverflow:
http://stackoverflow.com/questions/1662355/dynamic-foreign-keys-how-to-implement

With the most recent file generated by Stefan I have the following fourissues:

-- table od_water_course_segment
-- the attribute from_geometry is added two times --> should one if it be the to_geometry?

--table od_chute
--od_chute is added twice. The second CREATE TABLE statement has to be eliminated.

--table od_param_ca_general
--lenght_flow_path --> length_flow_path (typo)

--table od_param_ca_mouse1
--slope_flow_path is added twice with different data types (smallint or decimal(5,2))?

should be a core QGIS feature.

Ideas:

• Total length of reaches
• list of all catchment areas
• total area of catchment areas
• connected parcels/buildings

It needs to be discussed how we handle default value.

Should be a solution in QGIS core, because it is a problem also in other application modules.

Default values could be set either:

• database level
• overridden in QGIS project in the fields properties

Read as much information from the database schema as possible:

• constraints
• relations (foreign keys)
• table inheritance
  * Widget type depending on data type

the attribute "detail_geometry_geometry" should probably be shortened to "detail_geometry" ?

First version of webpage with basic information, screenshots, membership forms and project milestones/development list.

Ad tables to handle area

See if the table inheritance should be introduced into our data model (Subclass hierarchy)

Add feature: zoom to selected

Interlis Export/Migration contains reach progression geometry within special_structure - should be avoided

Currently we can import Interlis 1 with ogr2ogr into Postgis.

We need to improve the importer for better usability and more options.

Need for an easy to use Interlis export.

Pirmin Kalberer (Sourcepole) will work on SEXTANTE improvements regarding Interlis.

• GUI forms and plugin GUI will be translated with QtLinguist
• table names and value lists will be automatically exported from the main database (through Metadatabase) --> create a .ts file from the database
• Generate a view for export of the dictionary and the value lists

In addition to printing it would be good being able to export to the DXF and SVG format for further processing/layouting in CAD and graphic apps.

Potentially useful: dxflib from ribbonsoft: http://www.ribbonsoft.com/en/what-is-dxflib

For SVG, qt already has a backend - but not perfect.

Currently we only display simple nodes and lines and elevations. No manhole dimensions and no special_structures and dimensions of reaches. Koni and Urs provided sample drawings as a reference.

Draw key dimensions and attributes below diagram for manholes, special_structures and channels.

Take into account scale thresholds for levels of detail.

Potentially allow expression builder for labels.

See examples at
https://github.com/qgep/QGEP/blob/master/gepview/beispiel_laengenprofile.pdf
https://github.com/qgep/QGEP/blob/master/gepview/length-profile_example_arbon_situation.pdf
https://github.com/qgep/QGEP/blob/master/gepview/length-profile_example_arbon_profile.pdf

This needs to be added in the data model (table "Ueberlauf") and the networking algorithm.

Question: do we need an option to enable/disable the Überläufe?

We will need support for 1 : 1 relations. 1:1 relations are used for parent-child relationships in our datamodel.

Examples:

• Special structure => Wastewater structure.
• Cover => Structure part

Currently we always show a list of related features (1:N) while in a 1:1 situation there is always only zero or one related feature, so the list can be hidden.

For the GEP-Plan we need to allow data-defined background color and alpha values in text diagrams.

The clean way would be to allow classification for the background color (categories and rules), however, the quicker, less expensive way would be to support rgba fill values based on an attribute value.

A second file "indexes_extended_model.sql" needs to created or all put into one extended file.

Almost any od_xx table has the two attributes "dataowner" and "provider". Currently these are only text fields. I think it would be more elegant if these could be relations to the table "od_organisation" - With the current setup there is a lot of duplication and it is harder to update the information of the dataowner and provider.

Any thoughts?

add feature: zoom to selected features

We need to create a python or perl-script that reads in the english .qgs project file, parses the tablename and replaces it with german or french names based on the qgep.is_dictionary table

Key part to implement edition of the data. Implementations for manhole, reach and special structure. Should be one the first/next things to implement.

When a series of reaches is selected after searching for the shortest path, a button should be offered to set visible extent so all selected features can be seen.
The same applies to found trees (downstream / upstream)

For the reach labels there should be language specific abbreviations in the table qgep.vl_reach_material with the following columns:

abbr_en
abbr_de
abbr_fr