There is a lot of configuration files in UDV (basically one per example demo plus one per module demo and per extension demo) with a lot of duplicates in these files.

They should be factorized (e.g. one per module) and then combined for example demos using multiple modules.

In Contribute, in the creation process, we have the possibility to select a subject among a list of given subjects.
It would be interesting to be able to add a new subject if if is not present in the list.

I need to work with a specific feature-branch of iTowns (that is not in the npm registry yet).

Specifying a dependency as a github URL doesn't work for an iTowns (as a dependency of our project) because
(itowns) npm prepublish is not executed when a dependency-package gets installed. In other terms npm fetches the required commitish version of iTowns but doesn't run the npm prepublish on the retrieved sources of iTowns.

This limiting design of npm (known since 2013, happens sometimes to be problematic (like for our need).

npm-git-install seems to be an effective temporary fix. Alas if you consider the following package.json file then an npm install on UDV-Core does indeed trigger npm-git install that in turn runs iTows npm prepublish but the build directory used for that build seems to be removed by npm-git.

{
  "name": "UDV-Core",
  "version": "0.0.1",
  "description": "An iTowns based set of overlay display modules for City exploration",
  "main": "src/Main.js",
  "scripts": {
    "build": "webpack -p",
    "doc": "jsdoc Setup3DScene.js",
    "doclint": "npm run doc -- -t templates/silent",
    "install": "npm-git install",
    "lint": "eslint \"src/**/*.js\" \"Main.js\" \"Setup3DScene.js\"",
    "start": "cross-env NODE_ENV=development webpack-dev-server -d --inline --hot",
    "test": "npm run lint",
    "transpile": "cross-env BABEL_DISABLE_CACHE=1 babel src --out-dir lib",
    "//": "\"prepublish\": \"npm run build && npm run transpile\""
  },
  "files": [
    "Tools",
    "Modules"
  ],
  "repository": {
    "type": "git",
    "url": "git+https://github.com/MEPP-team/UDV.git"
  },
  "license": "(LGPL-2.1)",
  "bugs": {
    "url": "https://github.com/MEPP-team/UDV/issues"
  },
  "homepage": "https://github.com/MEPP-team/UDV/",
  "dependencies": {
    "babel-runtime": "^6.20.0",
    "es6-promise": "^4.0.5",
    "moment": "^2.19.0",
    "npm-git-install": "^0.3.0"
  },
  "devDependencies": {
    "babel-cli": "^6.22.2",
    "babel-core": "^6.22.1",
    "babel-loader": "^7.0.0",
    "babel-plugin-minify-dead-code-elimination": "^0.2.0",
    "babel-plugin-transform-runtime": "^6.22.0",
    "babel-plugin-webpack-loaders": "^0.9.0",
    "babel-preset-env": "^1.6.0",
    "chart.js": "^2.4.0",
    "cross-env": "^3.1.4",
    "eslint": "^3.14.0",
    "eslint-config-airbnb-base": "^11.3.0",
    "eslint-import-resolver-webpack": "^0.8.1",
    "eslint-loader": "^1.7.1",
    "eslint-plugin-import": "^2.2.0",
    "imports-loader": "^0.7.1",
    "jsdoc": "^3.4.3",
    "mocha": "^3.4.2",
    "node-fetch": "^1.7.0",
    "raw-loader": "^0.5.1",
    "require-from-string": "^1.2.1",
    "webpack": "^2.6.1",
    "webpack-dev-server": "^2.4.5"
  },
  "gitDependencies": {
    "itowns": "https://github.com/iTowns/itowns"
  }
}

The result is that npm-git happens to be of no help in our case. Maybe this is due to the fact that iTowns uses peerDependencies that cannot be installed automagically ?

When placing a document, the opacity is set at 50% and cannot be changed. This make the placement process difficult for some document where the image is not easy to distinguish from the background city.

A handy way to improve the placement would be to add an opacity slider, similar to the document visualizer. The default value could be 50%, but the user would have the choice to change it if they want to.

In UDV-Core/examples/Demo.html

<script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.0/jquery.min.js"></script>

The dependency on Jquery is already expressed (with this PR) in package.json.
The import of Jquery thus doesn't need to depend on on an external server (ajax.googleapis.com) to be active.
Use the "classic" import mechanism to remove that URL (and the dependency towards an active external server as well as the need for IP connectivity).

The current app handles dates as a shortened ISO 8601 format (yyyy-mm-dd). This format is enough for approximate dates, but for more precise time specifications (like the publication time of a comment) a stricter format is required. The ISO 8601 format currently implemented can be extended with a time info and a timezone (example : 1977-04-22T01:00:00-05:00).

The problem

Camera controls are not working normally and movements in the 3D scene are not intuitive. This is most likely due to a picking problem in iTowns which has been resolved in the last release.

Actions

Rebase Itowns - 3D Tiles temporal on the last version of iTowns.

Context

In the index.html page, links to demos are provided. The first section lists 4 demos :

• Temporal + ConsultDoc demo
• Authentication + Documents to validate demo
• All modules demo
• Augmented model of mediation demo

Problem

As each module has its own demo in the second section of the page, is it really useful to keep 3 demos with different combinations of modules ? We could just have the demo containing all modules as a general demonstration of the project. For debugging, each module has its own demo.

Screenshot

To create a document, we can give for example its publication date, in format "DD-MM-YYYY". It would be good to give the possibility for the user to only give "YYYY" or "MM-YYYY".

Context

For the moment, the search fields and the displayed properties of a document in validation are hardcoded in the front-end.

Problem

If the document model change, the developpers would have to change the code of the module to be up-to-date with the new model. It would be more practical to generate these fields according to the config file provided, like in ConsultDoc module.

When using UD-Viz, one has no simple way (through the GUI itself) to retrieve information (sources/characteristics/description) concerning the displayed data. For example when a 3DTiles is displayed we have no mean to know where it comes from: which computational process produced it, what is the exact geographical scope, at which historical date corresponds what is displayed...

Assuming that each data set has a some description field (metadata?) have UD-Viz display that textual information.

Note: the current technical way of doing this, consists in trapping the networked access to the data with the browser debugging tool, taking the URL, using wget on that URL and inspect the retrieved data...

Actually, if we want to create a new demo, we need to copy and paste the code of a previous one.
The idea is to have a generic class Demo, in which we have some methods that can connect or disconnect functionalities, such as the temporal, consulDoc, etc.
Thus, to create a new demo, we will just need to create a new instance of this class and configure what we want to display on it, using its methods.

Guided Tour Module was originally designed for the first prototype of UDV-Core (click on Visit on rict.liris) and is broken since then. It must be rehabilitated and must be designed using an MVC architecture like the other modules.
Additionally, it should be possible to have a list of different visits

The opacity of a document displayed in superposition to the scene cannot be changed anymore.

Example of the bug:

Contributing with documents without being signed is not possible. Doing so outputs an error message in the console (namely Unhandled promise rejection Login needed for this request).

In this case, we should add a pop-up window informing the user that he must register/sign in to contribute.

How things are

The information required for the definition demo is currently scattered

• for the "code" part: a demo specific directory
• for the "data" part: generalDemoConfig.json. Notice that currently generalDemoConfig.json gathers the information required for many demonstrations, making this file too big, ill-structured, almost unreadable and bloated.

Besides many (most of them) demos are too specific to belong within the UD-Viz repository.
In fact they belong within UD-Reproducibility/Demos
where they should be relocated.

Hence creating a new demonstration becomes a weird (undocumented) process that
is hard to infer out of such a confusing situation.

How things should be

For the sake of modularity, each demo

• should be entirely defined within directory in UD-Reproducibility/Demos (and no information should "contaminate" the UD-Viz repository)
• should have a Demo.html and a Demo.js files (defining the code i.e. the modules is assembles)
• should have its own configuration file (the part of generalDemoConfig.json) concerning that demo), its CSS, the logos it wishes to use, the layers and data extents...

What needs to be changed

1. Modify/extend the BaseDemo.js class so that

   • the logos used by the html() getter can be easily configured by a specific demo (this "html() getter"
     could call another getter on a logs attribute whose setter whould be called by a demo ?)
   • ease the (demo) usage of its configuration : logo-imu and logo-liris should not be hardwired

2. Move the example/Demos to UD-Reproducibility/Demos

3. Disseminate generalDemoConfig.json to those demos

When using properties from the batch table, all mechanisms linked to those properties, such as display them or link a document to an object by a property , are made only using one given property, which is "cityobject.database_id".
Maybe we can set a rule that everytime we create a tileset, instead of using "cityobject.database_id" or "ifc.if", we must use a generic term "id" as an attribute.
Also, we may need to add the possibility to display all attributes linked to an object, somewhere near here

When resizing the screen, some windows shrink and their buttons overlap (this happen for ConsultDoc or Contribute. If their buttons are in an absolute position, the window should not shrink. If the window can be resized, the buttons should not be placed using absolute coordinates.

In our demo, we currently use:

• The 2009 terrain imagery
• The 2012 terrain elevation

Update these sources to the 2015 versions:

• The 2015 terrain imagery
• The 2015 terrain elevation

This may boil down to just changing the links in UD-Viz.

In "ConsultDoc" module (in the PR #12, this issue was about the "Documents" module), the camera travel doesn't work. The camera moves directly from one point to another, the movement is not smooth anymore.

Is the folder "Extensions" still needed ? Should we merge it with the "Modules" ?

Problem

An authentication module has been recently added to the project, allowing users to create personal accounts. However, they have no way either to delete their personal informations or to retrieve them.

Solution

Add the services in the back-end to allow a user to get all information about themselves, and to delete their account. Update the front-end to allow users to access these services.

Use elint to enforce it.

In the panel control, in the "Temporal Mode" folder, nothing happens whenactivating the option "use overlay".
Disable the button in the meantime.

Lead: SAB, soutien LTA

The problem

This PR is a first step towards a MVC architecture as the code from the views, the controller and the model are separated in different files for the ConsultDoc module.

However the next step to reach a MVC architecture would be that the views and the model don't know about the controller (which is currently not the case). A way to manage this would be by using events triggered by the views and the model and trapped by the controller. The step after that would be to generalize this approach to the other modules (e.g. temporal) and between modules.

Actions

• Create a master Controller which manages the relationships between modules

The following modules are concerned:

• ConsultDoc
• Temporal
• Contribute

PR #13 introduces (within file DocumentController.js) a hard wired dependency towards an external data server in the form of the line

this.url = "http://rict.liris.cnrs.fr/APIVilo3D/APIExtendedDocument/web/"; // ...
```
Place this information within a configuration file (and have the code import that file).

Issue #28 should be dealt with in parallel

The problem

Some files from UDV repository are outdated or misplaced (e.g. Architecture.md , todo.md, etc.)

Actions

Update, move or delete the outdated or misplaced files of UDV repository.

• javascript code should have headers
• RICT (wiki) : use the _banner mechanism (think of CC license ? Refer to Py3Dtiles specification license)

The problem

This work has been started in #115 .

However, we still use very old versions of some packages (e.g. babel and webpack). Some of them are indicated as deprecated by npm when running npm install:

npm WARN deprecated [email protected]: 🙌  Thanks for using Babel: we recommend using babel-preset-env now: please read https://babeljs.io/env to update!
npm WARN deprecated @babel/[email protected]: 🚨 As of Babel 7.4.0, this
npm WARN deprecated package has been deprecated in favor of directly
npm WARN deprecated including core-js/stable (to polyfill ECMAScript
npm WARN deprecated features) and regenerator-runtime/runtime
npm WARN deprecated (needed to use transpiled generator functions):
npm WARN deprecated 
npm WARN deprecated   > import "core-js/stable";
npm WARN deprecated   > import "regenerator-runtime/runtime";
npm WARN deprecated [email protected]: CircularJSON is in maintenance only, flatted is its successor.

> [email protected] postinstall /home/vincent/Documents/dev/UDV/UDV-Core/node_modules/core-js
> node scripts/postinstall || echo "ignore"

Thank you for using core-js ( https://github.com/zloirock/core-js ) for polyfilling JavaScript standard library!

The project needs your help! Please consider supporting of core-js on Open Collective or Patreon: 
> https://opencollective.com/core-js 
> https://www.patreon.com/zloirock 

Also, the author of core-js ( https://github.com/zloirock ) is looking for a good job -)


> [email protected] postinstall /home/vincent/Documents/dev/UDV/UDV-Core/node_modules/uglifyjs-webpack-plugin
> node lib/post_install.js

npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN [email protected] requires a peer of three@^0.107.0 but none is installed. You must install peer dependencies yourself.
npm WARN [email protected] requires a peer of webpack@>=1.12.9 <3.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN [email protected] requires a peer of webpack@^4.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

Possible solution

• Remove unused dependencies
• Update all dependencies to the latest version.

WARNING: updating babel and webpack will require to update the babel and webpack config files (webpack.config.js, webpack-babel.config.js, etc.). One might find some inspiration in the iTowns repository

The need

The underlying need is to point to a reduced dataset in order to avoid comple scene data loading.

Technical detail

Provide the couple lines that a some_demo.js code should hard-code in order to easily position the camera pointing to the area of interest.

Most of the elements already exist: refer to

• CameraPositioner demo
• Positioning the camera is done within PositionerWindow.js

Context

When running a research on documents, the filtered results are displayed in the document browser.

The problem

The documents are filtered correctly. However, the document browser is not updated with the first result (the index is updated correctly but not the document metadata and image).

Steps to reproduce the bug

• Open the document browser
• Navigate to any document but the first using the arrows
• Open the document research pane
• Search for 'plan' keyword

Actual behaviour

When orienting a document from the ConsultDoc module:

• The document is displayed in superimposition to the scene
• The opacity slider is at minimum but the opacity value is 50
• The camera moves
• When the document is superimposed to the scene, the animation with the opacity slider going from 0 to 100 is launched and the document is fading with opacity from 0 to 1

Expected behaviour

When orienting a document from the ConsultDoc module:

• The camera moves to go to the position where the document must be displayed
• Then, document superimposition window is displayed and the opacity animation is launched.

This behaviour can be seen in Vilo3D demo.

The problem

Currently, when we need to modify iTowns, we create a fork and work on a branch. Then, we configure UDV to import this branch instead of iTown's master branch.

This is bad because new features are on branches of personal repositories and we need to rebase these branches continually. Moreover, when there will be more than one functionnality added to iTowns this way, the framework will start being heavy.

Note that the right way would be to make a PR to iTowns. This is not possible in some cases (e.g. temporal dimension handling for 3D Tiles) because it is not a standard functionnality (yet :) ) and thus iTowns won't accept it.

In this particular case, it seems that it is possible to extend iTowns with new functionnalities directly from the component using it (UDV in our case) (see this issue); especially by creating Providers and Processing directly from the component using it.

Actions

• Try to implement the temporal dimension handling by extending iTowns within UDV
• Document the process

Guided tours need to be tested. To this end one might need to populate a database with a guided tour to verify it is working.

Two things might need to be done client side to enhance the user experience:

• Remove the Explore button displayed when activating guided tours from the left side menu and open directly the window of guided tours.
• Manage the case when there is no guided tours in the database (as done for documents for instance)

Context

The UDV web client only provide an interface to consult and navigate through guided tours. The contributors have no way of creating / updating / deleting a guided tour, even though the services exist in the back-end API.

Solution

A new interface must be created to allow users to contribute to guided tours. It might be an extension (similar to "Contribute" which was an extension to "ConsultDoc"), or just a new part of the existing module (like "DocToValidate" which allows to consult, udpate, delete, comment in one module)

Replace the Labex IMU logo with the Université de Lyon logo

City Objects demo is broken.

The following error is raised TypeError: this.config.extents[area] is undefined

Names of the demos and logo should be updated:

• The name on the upper-left corner (UDV) must be updated to UD-Viz and become linkable to the UD-Viz github repository
• LIRIS and IMU logos must be moved to the left side (next to Sign In)
• Rename the demos from the index.html page (http://rict.liris.cnrs.fr/UDVDemo/UDV/UDV-Core/) :
  • Demos -> Thematic Demos
  • UDV Full modules demo -> All Components demos
  • UDV-stable demo -> UD-SV for cultural heritage - Fab-Pat
• Thematic demos have their thematic name writtent in the center of the upper bar; e.g. "UD-SV for cultural heritage - Fab Pat" at the top of the Fab-Pat demo
• On the right side of the upper bar: Add a "Data Partners" "category" and add the logo of the Grand Lyon and of Auvergne Rhone Alpes

When these modifications are done, send the link of the demo to patrimoine Aura.

The location on the minimap doesn't work anymore: for a same (x,y,z) position the location on the minimap changes when rotating the camera.

Example of location for the same position but with different camera rotation:

During the visualization of a link which targets a city object, the building is shown in a different color. However, it does not work if it is not in "front" of the camera (ie. if the tile is not currently loaded). The user has to move the camera where he/she thinks the building is located to display it correctly.

A better approach for doing this would be to first move the camera to an appropriate location, and then change the color of the building.

As it is right now, the tiles manager class only handle one layer
In order to be able to easily use multiple source and perform action on those layers, such as select objects, there is a need to think at a solution to handle multiple layers.
It can be fixed either by extending the layer attribute as a list, thus modifying inherent methods, or by creating a layer manager, able to handle multiples TilesManager, which seems to be a lot more work to do.

Back up the data in UDV-Core/examples/Vilo3D/ and remove this folder from UDV.

It was indeed used for the first prototype of UDV-Core and is not needed anymore as this demo doesn't work and as UDV don't use the data it contains anymore.

It could be nice to have an index.html file at the root of UDV listing the examples, the demos of each module and of each extension.

Problem

When creating a document for the second time in the session, it will not display when trying to place it (when the 'place doc' window is active). If the 'send' button is pressed, the document will still be created. It's only the previzualisation that is broken.

Steps to reproduce

1. Create a document
2. Create another one. Hit the 'place doc' button. The file should be displayed but does not appear.

Screenshots

Expected behaviour

Actual behaviour

When using the Documents or the GuidedTour modules, the windows appear behind the side menu and cannot be used until the menu is closed. Their initial position should be right to the side menu (and should eventually be movable).

In order to increase ergonomy, it would be useful for the user to be able to navigate in the town by entering addresses/place names.

For each demonstration, we manually fix the geographic extent of the ground map that we will load. This ground is loaded once at the beginning but it always stay the same, even when we move in the scene, making it possible to "float" on the scene and not having grounds anymore.
It would be interesting to have the possibility to automatically load the map while moving in the scene, which would always provide a ground.
This may be done by changing the extent depending on our position, or maybe it exists other solution to do it.

This line is not elegant.

Fix this by using a scheme similar to the one used e.g. for extents in GeneralDemoConfig.js...

When deleting the last document, the informations on the browser are not updated. Title, description, etc. are still the same as the last document deleted.