pnx-si / geopaysages Goto Github PK
View Code? Open in Web Editor NEWApplication web permettant de publier un observatoire photographique des paysages
License: GNU General Public License v3.0
Application web permettant de publier un observatoire photographique des paysages
License: GNU General Public License v3.0
Au chargement de la page d'un site (comparator
), les 2 photos comparées par défaut sont les 2 premières de la série.
Ce serait sympa de pouvoir comparer par défaut la plus ancienne et la plus récente pour que ce soit un peu "spectaculaire" pour le visiteur en arrivant sur la page :)
J'ai vu que c'était géré par comparedPhotoIndexes
et comparedPhotos
dans backend/static/js/comparator.js
En modifiant manuellement la 2e valeur du tableau ça fonctionne mais je sèche sur la manière de faire ça proprement en récupérant la valeur d'index max pour la série de photos de chaque site (variable selon les sites).
En installant l'app sur Debian 10, cette commande lancée par install_env.sh à échouée :
sudo apt-get install postgresql postgresql-contrib postgis postgresql-9.6-postgis-2.3 postgresql-9.6-postgis-2.3-scripts
A la place j'ai fais :
sudo apt-get install postgresql
sudo apt-get install postgis postgresql-11-postgis-2.5
On dirai que ça fait le job.
Cet outil a vocation à être déployé par d'autres structures (parcs nationaux, parcs régionaux, départements....), sur le même modèle que Geotrek ou GeoNature.
Dans ces différents projets on a eu une approche la plus générique pour permettre à chacun de customiser et de paramétrer l'application (surcouche CSS, répertoire custom
pour modifier les images, logos, textes de présentations...). Voir par exemple l'application Flask GeoNature-atlas : https://github.com/PnEcrins/GeoNature-atlas/blob/develop/docs/installation.rst#configuration-de-lapplication
C'est pour cela que le CCTP de GeoPaysages indique :
En plus d'être libre de droit et basée sur des technologies open source, l'application doit être générique pour une mise en place facilitée par d'autres structures que le PNV. Des éléments ergonomiques, graphiques, techniques et fonctionnels doivent être intégrés sous forme de variables et être centralisés dans un minimum de fichiers de propriétés et de customisation. Ces fichiers doivent être conçus pour être facilement utilisables, lisibles...
et
Certains éléments ergonomiques et graphiques sont aussi customisables (bandeau, header, footer, couleur...). Tous ces éléments génériques présents dans le CSS doivent être mis dans un fichier CSS de customisation modifiable par un administrateur. Il vient surcharger le ou les fichiers CSS de l'application. Ce fichier ne doit pas être écrasé lors d'une mise à jour applicative. Des administrateurs de l'application pourront ajouter des propriétés CSS existantes pour modifier des attributs qui remplaceront les attributs présents dans les CSS par défaut.
De ce que je comprends actuellement, c'est très peu le cas. Les fonds carto, les images, les logos, les textes sont éclatés et en dur dans les différents fichiers de l'application.
Je viens d'installer GeoPaysages 1.0.0-rc.3.7 sur un serveur Debian 9.9.
Quand j'essaie d'ouvrir la BDD avec pgadmin j'ai ce message :
Codage de la base de données
La base de données geopaysages a été créé pour stocker des données dans le codage SQL_ASCII. Ce codage est seulement défini pour les caractères sur sept bits ; la signification des caractères dont le huitième bit est positionné (caractères non ASCII allant de 127 à 255) n'est pas définie. En conséquence, il n'est pas possible pour le serveur de convertir les données vers d'autres codages.
Si vous stockez des données non ASCII dans la base, vous êtes fortement encouragé à utiliser un bon codage représentant la locale de votre ensemble de caractères pour retrouver le bénéfice des conversions automatiques vers les différents codages client si nécessaire. Si vous stockez des données non ASCII dans une base de données SQL_ASCII, vous pouvez rencontrer des problèmes avec des caractères étranges écrit ou lu depuis la base de données, problèmes causés par des soucis de conversion de code. Ceci pourrait vous amener beaucoup de problèmes en accédant à la base de données avec des programmes clients et des pilotes différents.
Pour la grande majorité des installations, le codage Unicode (UTF8) apportera la plus grande flexibilité.
Je ne sais pas si c'est normal et souhaitable. Et j'ai l'impression que cela occasionne d'autres problèmes.
La valeur de ce champs ne semble pas utilisée.
J'ai passé ce champs à TRUE pour des photos, et celles-ci n'apparaissent pas dans la Galerie photos.
Les images qui sont uploadées depuis l'ADMIN le sont avec root
, je ne suis pas sur que cela soit souhaitable ?
Il y a une ligne en plus dans le fichier /front-backOffice/src/app/config.ts.tpl
customFiles: '<server_name>/static/custom/'
Avant de lancer update_app.sh il faut ajouter cette ligne dans le fichier existant /front-backOffice/src/app/config.ts
Quelle version de UsersHub-authentification-module doit-on utiliser ?
La version master ne correspond pas aux inserts fournis par le parc national de la Vanoise
1- "### POST /api/auth/login HTTP/1.1" 500 -
(psycopg2.ProgrammingError) ERREUR: la colonne v_userslist_forall_applications.pass_plus n'existe pas
LINE 1: ...tilisateurs_v_userslist_forall_applications_pass, utilisateu…
2- ### ERREUR: la colonne t_applications.id_parent n'existe pas
LINE 3: WHERE utilisateurs.t_applications.id_parent = '10' AND utili…
Pour les suivis scientifiques de sites, on peut avoir beaucoup de photos sur un seul site (2000), voir si il est utile de filtrer les photos proposées. Afficher un date_picker ne proposant que les dates où il y a une photo ? Pouvoir n'afficher qu'une photo par mois ou semaine ?
A étudier et maquetter en lien avec #76
Plusieurs messages des fichiers de langue sont spécifiques au PnVanoise.
Il est possible de modifier les fichiers de langue, mais les modifications seront à refaire à chaque mise à jour et dans chaque langue...
Un mécanisme avec un paramètre du nom de la structure aurait été surement plus pertinent
Il faut aussi revoir la doc car les commandes indiquées pour recompiler les fichiers de langue ne sont pas OK :
geopaysages@GeoPaysages:~$ cd geopaysages/
geopaysages@GeoPaysages:~/geopaysages$ . venv/bin/activate
(venv) geopaysages@GeoPaysages:~/geopaysages$ . pybabel compile -d i18n
-bash: import : commande introuvable
-bash: import : commande introuvable
from: can't read /var/mail/babel.messages.frontend
-bash: /home/geopaysages/geopaysages/venv/bin/pybabel: ligne 10: erreur de syntaxe près du symbole inattendu « ( »
-bash: /home/geopaysages/geopaysages/venv/bin/pybabel: ligne 10: ` sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])'
Il faut faire :
(venv) geopaysages@GeoPaysages:~/geopaysages$ pybabel compile -d backend/i18n
deactivate
https://github.com/PnX-SI/GeoPaysages/blob/master/backend/tpl/gallery.html#L23
A remplacer par le titre de la photo, ou du site ?
Impossible d'enregistrer un site si plus d'une photo. A partir de deux photos, au moment d'enregistrer j'ai un message "Une erreur est survenue sur le serveur".
Pouvoir intégrer la dernière photo d'un site dans un site web externe (parc national, partenaire...).
Créer une petite page web simple contenant la dernière photo d'un site (en 100% de large pour s'adapter au site où elle est intégrée) + sa date et son auteur et copyright
Si un site n'a pas de photo, alors le backoffice est en erreur et la liste des sites ne se charge pas. Un site devrait pouvoir ne pas avoir de photo.
Les logs indiquent :
[2019-05-16 18:48:12,120] ERROR in app: Exception on /api/sites [GET]
Traceback (most recent call last):
File "/home/geopaysages/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 2292, in wsgi_app
response = self.full_dispatch_request()
File "/home/geopaysages/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1815, in full_dispatch_request
rv = self.handle_user_exception(e)
File "/home/geopaysages/geopaysages/venv/lib/python3.5/site-packages/flask_cors/extension.py", line 161, in wrapped_function
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/home/geopaysages/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1718, in handle_user_exception
reraise(exc_type, exc_value, tb)
File "/home/geopaysages/geopaysages/venv/lib/python3.5/site-packages/flask/_compat.py", line 35, in reraise
raise value
File "/home/geopaysages/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1813, in full_dispatch_request
rv = self.dispatch_request()
File "/home/geopaysages/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1799, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/home/geopaysages/geopaysages/backend/api.py", line 35, in returnAllSites
id_photo=site.get('t_photos')[0])
IndexError: list index out of range
Quelques petits retour du test d'install:
les repertoires de log /var/log/oppv_vanoise/
ne sont pas créer lors de l'install_app. Du coup tel quel, le lancement du supervisor ne fonctionne pas.
la commande que doit lancer le supervisor pour lancer gunicorn ne fonctionne pas chez moi:
directory=/home/demogeonature/geopaysages/backend
command=/home/demogeonature/venv/bin/gunicorn app:app -b localhost:8001
autostart=true
autorestart=true
Si je lance /home/demogeonature/venv/bin/gunicorn app:app -b localhost:8001
à la main, j'ai cette erreur :/home/demogeonature/venv/bin/gunicorn app:app -b localhost:8001
(mon venv est bien créé et mon chemin est correct).
J'ai essayé de lancé le serveur en mode dev (FLASK_APP=./app.py FLASK_DEBUG=1 flask run), il se lance correctement, mais j'ai une timeout sur mon navigateur.
En testant la v2 du comparateur photos je constate que :
comparator-v2.html
n'est pas implémentée,comparator-v2.js
Je viens d'installer l'application en suivant les procédures mais je rencontre un problème avec le backoffice. Dans le fichier de conf de nginx il pointe sur le répertoire app_admin/index.html à la racine de site.
J'ai bien le répertoire mais je n'ai pas le fichier index.html qui me permet de lancer le backoffice.
L'application UsersHub (https://github.com/PnEcrins/UsersHub) permet d'administrer une schéma PG utilisateurs
regroupant les utilisateurs, les groupes d'utilisateur, leurs droits, les listes d'utilisateurs, les différentes applications...
Ce schéma peut être répliqué ou accédé par des BDD tiers pour ne pas avoir à gérer des comptes utilisateurs dans chacunes de nos applications mais les gérer de manière centralisées.
Pour utiliser facilement l'authentification dans une application Flask, un sous-module a été créé : https://github.com/PnX-SI/UsersHub-authentification-module.
Il peut-être installé automatiquement lors de l'installation de l'application et on bénéficie directement dans l'application de toutes ses routes. Exemple : https://github.com/PnX-SI/GeoNature/blob/master/backend/requirements.txt#L13
Dans le CCTP (http://geonature.fr/documents/autres/geopaysages/2017-11-13-CDC-OPPV-PNV.pdf), il est indiqué une table des utilisateurs de cette manière :
t_utilisateur = table de gestion des profils et des utilisateur du back-office et des auteurs de photo
id_role = identifiant unique de l'utilisateur
id_right = niveau de droits de l'utilisateur (1 à 6, 6 étant super-administrateur. Le libellé des valeurs
sera fourni) => Les valeurs de ce champ seront utilisées pour définir les droits des utilisateurs sur les
fonctionnalités du back-office.
author_photo = auteur de photo (oui/non)
id_application = identifiant de l'application OPP défini dans UsersHub
name = nom de l'utilisateur
first_name = prénom de l'utilisateur
organization = structure de rattachement de l'utilisateur
mail = e-mail de l'utilisateur
path_author_photo = chemin de la photo de l'auteur de photo des paysages
Cela comprend quelques incohérences avec le schéma utilisateurs
de UsersHub qui se base sur une table t_roles
regroupant utilisateurs et groupes. Il y a aussi des vues (et leurs routes) qui permettent de récupérer les droits d'un utilisateur en fonction de ses éventuelles groupes et par application.
En effet dans le CCTP, si on utilise UsersHub, alors il est plutôt prévu que l'application n'utilise pas directement le schéma utilisateur
mais plutôt l'utilise pour remplir la table t_utilisateur
.
A voir ce qui est le plus pertinent.
Dans tous les cas, il est indiqué dans le CCTP des valeurs en dur de utilisateurs.cor_role_menu.id_menu = 100
. Il est important que celles-ci soient configurables pour permettre de s'adapter à différents cas.
Là aussi je dirai qu'il y a un problème d’appellation.
Car là aussi, la carte est juste un outil mais pas le contenu, donc pas le bon nom de route ni de page.
Il s'agit de la page de recherche, ou la page des sites.
La route devrait être http://domain/sites/ ou http://domain/search
Le nom de la page dans le Menu et son titre quand on l'affiche devraient être : "Les sites" (de préférence) ou "Rechercher un site".
Et sur cette page, les filtres ne me semblent pas très ergonomiques. Et la recherche d'un site n'est pas simple car il manque la liste des sites, avec une interaction Carte <> Liste. C'est peut-être prévu ?
Je pense que j'aurai construit cette page sur ce modèle :
Bandeau vertical de filtres en haut (avec des listes déroulantes à choix multiples)
Liste à gauche / Carte à droite (ou inversement)
En testant l'appli sur iOS et Safari, je remarque un bug sur l'affichage des dates dans les boutons sélecteurs du comparateur v2 :
Lié semble-t'il au formatage des dates sans timestamp : https://github.com/PnX-SI/GeoPaysages/blob/dev/backend/static/js/comparator-v2.js#L19
Il faudrait simplement modifier le formatage avec un T
au lieu d'un
et ça fonctionne : https://stackoverflow.com/a/13363791
J'ai installé GeoPaysages de manière standard mais la console indique :
You are running Vue in development mode.
Make sure to turn on production mode when deploying for production.
Je ne suis pas sur que cela soit souhaitable désormais ?
En échangeant avec @geobrun sur ce sujet, on se disait qu'il serait sympa de faciliter la personnalisation de l'icône du marqueur des sites à la place de celui par défaut de Leaflet affiché dans les cartes.
Pas si simple à faire de manière générique mais voici une proposition :
map_custom_marker
dans la table geopaysages.conf
. Celui-ci prend comme valeur une chaîne de caractère au format JSON dont les items sont les options de la méthode Leaflet L.Icon
et formatée comme suit : {
"iconUrl": "../../static/custom/images/custom_marker.png",
"shadowUrl": "../../static/custom/images/custom_marker_shadow.png",
"iconSize": [40, 40],
"shadowSize": [46, 20],
"iconAnchor": [20, 40],
"shadowAnchor": [12, 18],
"popupAnchor": [0, -20]
}
Si le paramètre est NULL
ou non-renseigné (absent de geopaysages.conf
), on permet que le comportement actuel par défaut (marqueur Leaflet) persiste - Permet de rester simple et de le désactiver si on ne veut pas s'embêter avec ça ou si on y connait rien à Leaflet.
On renseigne tout de même le paramètre lors de l'installation pour proposer un exemple de personnalisation du marqueur (désactivable donc en supprimant le paramètre dans la table ou en passant sa valeur à NULL
).
On documente tout ça avec un renvoi vers la doc Leaflet ad-hoc qui reste relativement accessible sur ce point (même pour un néophyte que je suis) : ici et là par exemple.
Qu'en pensez-vous ? intéressé par une PR ?
C'est tout prêt dans ce commit sur mon fork : 85bc141
;)
Nous avons mis en place des moyens de traduire l'app, certes.
Mais, il n'y a aucun moyen d'accéder à l'app autrement que par la langue fr
Pour ce faire nous devrions modifier les routes pour qu'elles prennent en param la langue.
Par ex :
/sites/<int:id_site>
deviendrait
/<lang>/sites/<int:id_site>
Quand on saisit sur un écran moyen (PC portable par exemple) et qu'on enregistre, le Mask de chargement ne s'affiche que sur la partie haute de la page donc on ne le voit pas forcément :
Une alternative à cela serait que la page fasse globalement 100% de haut, sans scroll.
Avec une carte qui ferait 100% de haut et serait fixe (max-height:70vh
sur col-map
) et idem pour le formulaire dans lequel on scrolle (overflow-y: auto;max-height: 85vh;
sur col-table
). Cela faciliterait aussi l'ergonomie globale de la saisie :
Suite aux discussions entre différents PNR et avec @geobrun, on trouvait utile de pouvoir afficher la valeur du champ "référence" d'un site (ref_site
) dans la pop-up qui s'affiche au survol dans la carte "Sites d'observation".
En plus du nom du site et de la commune et comme c'est le cas dans la liste des sites de la sidebar.
Comme ce champ n'est pas renseigné obligatoirement voire pas utilisé du tout par certains, je vous propose de le faire avec un paramètre dans la table magique geopaysages.conf
.
Si ce paramètre map_popup_ref_site
est renseigné avec la valeur True
, le champ ref_site
s'affichera.
Sinon, on reste sur nom du site + nom de la commune.
Qu'en pensez-vous ? intéressé par une PR ?
C'est tout prêt dans ce commit sur mon fork : 0426a85
;)
C'est étonnant que la route d'un site soit nommé /comparator/
Il s'agit de la fiche d'un site, le comparateur n'est qu'un outil dans celle-ci.
Plutôt afficher les fiches des sites sur une route de type http://domain/site/5
Idem pour le titre des fiches de chaque site qui indique en premier "COMPARAISON DE PHOTOS".
C'est juste la fiche du site.
Import massif initial depuis FTP ou dossier d'images
Import quotidien des nouvelles photos
Paramétrage du script d'import (chemin et nom des fichiers)
Redimensionnement des images (paramétrable pour les différentes tailles, à la volée ou lors de l'import)
L'import massif initial d'un point d'observations utilisera le même script que l'import quotidien.
Charge à l'admin de le lancer à la main pour ne pas attendre le cron et d'en modifier les paramètres si besoin après le 1ère import
Pas de rollback, ni d'outils de correction en cas d'import de données erronées.
On récupère le fichier original sur un serveur pour les besoins de traitements (droits d'édition d'image )
Lire les EXIF/IPTC, redimensionner si besoin...
Conventions de nommage de fichiers sur FTP : nomenclature AAA-mm-jj-hh-mm, copyright dans l'IPTC. Pour l'import massif, même source, même copyright
On télécharge le fichier original sur le FTP (avec un utilisateur Lecteur uniquement) pour pouvoir travailler le fichier sur le serveur GeoPaysages
On redimensionne, écrit dans la BDD, supprime éventuellement le fichier source si il n'est plus utilisé
Idéalement utiliser le nom du fichier pour retrouver la date rapidement sans ouvrir les EXIF ou IPTC (annee-mois-jour_h-m-s par exemple). Sinon utiliser la date de création du fichier pour éviter de devoir lire les EXIF.
L'ID du site est en paramètre fixe dans l’exécution du script.
Un dossier par site sur le FTP indiqué dans le paramètre de l'import.
Éventuellement un dossier par jour par site.
Prévoir un maximum de paramètres dans l'import, quitte à ce que cela soit prévu que dans un contexte pour commencer.
Voir pour le copyright si on peut le lire dans IPTC.
Il n'est pas prévu de pouvoir indiquer et afficher un auteur pour les photos ?
Voir https://github.com/PnX-SI/GeoPaysages/blob/master/backend/requirements.txt
Ainsi que les PR de mises à jour de sécurité et les alertes de sécurité (https://github.com/PnX-SI/GeoPaysages/network/alerts)
L'installation de la v1.0.0-rc.3.1 a bien fonctionné.
Néanmoins je rencontre ensuite des problèmes.
Quand j'essaie d'accéder à l'application, j'ai une Internal error.
Le fichier /var/log/oppv_vanoise/oppv_vanoise.err.log
indique :
'SQLALCHEMY_TRACK_MODIFICATIONS adds significant overhead and '
[2019-01-31 10:05:55,595] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
File "/home/geonatureadmin/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 2292, in wsgi_app
response = self.full_dispatch_request()
File "/home/geonatureadmin/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1815, in full_dispatch_requ$
rv = self.handle_user_exception(e)
File "/home/geonatureadmin/geopaysages/venv/lib/python3.5/site-packages/flask_cors/extension.py", line 161, in wrapped_$
return cors_after_request(app.make_response(f(*args, **kwargs)))
File "/home/geonatureadmin/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1718, in handle_user_except$
reraise(exc_type, exc_value, tb)
File "/home/geonatureadmin/geopaysages/venv/lib/python3.5/site-packages/flask/_compat.py", line 35, in reraise
raise value
File "/home/geonatureadmin/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1813, in full_dispatch_requ$
rv = self.dispatch_request()
File "/home/geonatureadmin/geopaysages/venv/lib/python3.5/site-packages/flask/app.py", line 1799, in dispatch_request
return self.view_functions[rule.endpoint](**req.view_args)
File "/home/geonatureadmin/geopaysages/backend/routes.py", line 45, in home
sites.append(sites[x])
IndexError: list index out of range
Certainement car je n'ai encore aucun site dans la BDD. Mais ce cas devrait être géré ?
Ou fournir un site exemple lors de l'installation de la BDD ?
Du coup j'ai essayé d'accéder au Backoffice pour créer un site. J'y accède bien, mais impossible de me connecter, j'obtiens une erreur 405 avec l'utilisateur admin / admin
POST http://51.77.158.17/app_admin/auth/login 405 (Not Allowed)
En intégrant nos données dans mon instance de dev/tests, je constate un comportement qui m’interroge et qui diffère de celui des autres pages :
La vignette de la photo affichée dans la pop-up des sites n'est pas celle définie comme principale (chez nous, la photo la plus ancienne par exemple) comme c'est le cas dans les blocs de la page d'accueil ou dans la page galerie.
Actuellement la vignette affichée est la dernière ajoutée dans une liste des photos de chaque site si je comprend bien :
https://github.com/PnX-SI/GeoPaysages/blob/dev/backend/static/js/sites.js#L182
En théorie, la photo affichée en vignette serait donc la dernière ajoutée.
Mais dans mon cas, les photos n'ont pas forcément été ajoutées à leurs sites en allant de la plus ancienne à la plus récente. Du coup la photo qui s'affiche dans la popup est assez aléatoire parmi celles de la série...
Je serais d'avis à reproduire dans la pop-up le comportement des autres pages où l'on affiche la photo définie comme principale. Celle défini dans le champ main_photo
de la table t_site
(en BDD) ou via le back-office dans le champ "afficher dans la galerie" (formulaire d'ajout/modif de photos).
Qu'en pensez-vous ?
Testé et fonctionnel chez moi avec 8403f17
A maquetter
Quand on uploade une image supérieure à 1 Mo, le backoffice est en erreur mais sans l'indiquer à l'utilisateur.
La console indique :
polyfills.7037a817a5bb670ed2ca.js:1 POST http://xxxxxxx/api/addPhotos 413 (Request Entity Too Large)
main.5123fae288e7c554e7b2.js:1 err upload photo e {headers: t, status: 413, statusText: "Request Entity Too Large", url: "http://xxxxxx/api/addPhotos", ok: false, …}
C'est ce qui m'a amené à avoir des sites sans photo (#57). Au moment de sauvegarder le site était créé mais pas les photos que j'y avais associé car celles-ci faisait 1,4 Mo.
Les configurations des fonds de cartes sont gérées différemment selon les pages qui appellent des cartes Leaflet.
Dans la "carte intéractive" (/map) et dans la fiche du site (/comparator) c'est géré tel que décrit dans la doc avec des entrées dans la table geopaysages.conf
de la BD. Facile à modifier, nickel !
Mais le comportement est différent pour les cartes suivantes car c'est géré en dur dans les fichiers JS ad-hoc :
./backend/static/js/home.js
)./front-backOffice/src/app/manage-sites/manage-sites.component.ts
)./front-backOffice/src/app/add-site/add-site.component.ts
)Ne serait-il pas possible/judicieux d'homogénéiser cela pour que toutes les conf des fonds de cartes (et le fond par défaut) soit gérées comme pour la carte intéractive (dans la table geopaysages.conf
) ?
Il est important que le schéma contenant les différentes tables, vues et fonctions de l'application soient dans un schéma dédié et non pas dans le schéma public
comme actuellement pour faciliter la portabilité de la BDD et permettre d'intégrer la BDD de l'application dans une BDD existante.
Quand je lance la commande . pybabel compile -d i18n, je rencontre un problème dans le pybabel : ci-dessous le message :
-bash: import : commande introuvable
-bash: import : commande introuvable
from: can't read /var/mail/babel.messages.frontend
-bash: /home/adminsitopp/geopaysages/venv/bin/pybabel: ligne 10: erreur de syntaxe près du symbole inattendu « ( »
-bash: /home/adminsitopp/geopaysages/venv/bin/pybabel: ligne 10: ` sys.argv[0] = re.sub(r'(-script.pyw?|.exe)?$', '', sy s.argv[0])'
Ce bouton ne semble pas avoir d'action, ni de champs correspondant dans la BDD.
Pas utile de publier ou non une photo selon moi.
Par contre, publier un site est fonctionnel et utile.
J'ai cette erreur à la fin du install_app.sh
pendant l'installation des paquets python:
error: invalid command 'bdist_wheel'
----------------------------------------
Failed building wheel for blueprint
Running setup.py clean for blueprint
Running setup.py bdist_wheel for Flask-Babel ... error
Complete output from command /home/demogeonature2/geopaysages/venv/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-1fmygzcp/Flask-Babel/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /tmp/tmplgkjs9ekpip-wheel- --python-tag cp35:
/usr/lib/python3.5/distutils/dist.py:261: UserWarning: Unknown distribution option: 'long_description_content_type'
warnings.warn(msg)
usage: -c [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
or: -c --help [cmd1 cmd2 ...]
or: -c --help-commands
or: -c cmd --help
error: invalid command 'bdist_wheel'
----------------------------------------
Failed building wheel for Flask-Babel
Running setup.py clean for Flask-Babel
Failed to build blueprint Flask-Babel
Installing collected packages: six, pycparser, cffi, bcrypt, blueprint, click, itsdangerous, Werkzeug, MarkupSafe, Jinja2, Flask, pytz, Babel, Flask-Babel, Flask-Cors, marshmallow, flask-marshmallow, SQLAlchemy, inflect, flask-sqlacodegen, Flask-SQLAlchemy, GeoAlchemy2, marshmallow-sqlalchemy, Pillow, psycopg2, psycopg2-binary, pypnusershub
Running setup.py install for blueprint ... done
Running setup.py install for Flask-Babel ... done
Running setup.py install for pypnusershub ... done
Successfully installed Babel-2.6.0 Flask-1.0.2 Flask-Babel-0.12.2 Flask-Cors-3.0.6 Flask-SQLAlchemy-2.3.2 GeoAlchemy2-0.5.0 Jinja2-2.10 MarkupSafe-1.0 Pillow-5.3.0 SQLAlchemy-1.1.13 Werkzeug-0.14.1 bcrypt-3.1.4 blueprint-3.4.2 cffi-1.11.5 click-6.7 flask-marshmallow-0.9.0 flask-sqlacodegen-1.1.6.1 inflect-1.0.1 itsdangerous-0.24 marshmallow-2.15.6 marshmallow-sqlalchemy-0.14.1 psycopg2-2.7.5 psycopg2-binary-2.7.5 pycparser-2.19 pypnusershub-1.1.2 pytz-2018.9 six-1.11.0
Creating configuration files
Testé sur un debian9
Ps: tous les scripts ".sh" ne sont pas exécutables et nécessite un "chmod +x"
L'utilisateur oppvuser
est en dur dans le fichier https://github.com/PnX-SI/GeoPaysages/blob/master/install_configuration/oppvdb.sql
du coup si on change l'utilisateur de BDD dans le settings.ini
, le script ne fonctionne pas.
Après avoir testé cette V2 du comparateur dans notre contexte OPP (PNR), je trouve que celui-ci ne correspond pas tout à fait au contexte "habituels" des OPP avec, le plus souvent, des reconductions de photos sur des pas de temps plutôt espacés (annuelles voire pluriannuelles par exemple).
Voici mon analyse + des propositions de légères évolutions :
L'outil de filtres par date de début et fin me semble complexifier un peu la navigation lorsque que l'on a pas de grosses séries de photos sur les sites. Chez nous l'OPP est un des plus anciens (depuis 1994) mais avec des reconductions annuelles, cela ne nous fait pas plus de 30 photos par sites (donc maximum 3 pages dans lesquels naviguer). De plus le filtre fonctionne avec des plages de dates précises jj/mm/yyyy
qui n'ont guère de sens dans le cas de photos renseignées avec des dates imprécises (cf. dernier point)
Solution proposée : pouvoir masquer le filtre par dates via un paramètre comparator_date_filter
dans la table conf
de la BDD. Celui-ci prend comme valeur True
ou False
. Si le paramètre n'est pas défini, le filtre s'affiche par défaut.
Voir commit bf584ed
Dans les cas où l'on a un seul pas de temps de reconduction des photos (annuelle par exemple), le bouton sélecteur de pas de temps n'est pas très utile et seuls les boutons précédent/suivant ont vraiment du sens.
Solution proposée : pouvoir masquer le bouton sélecteur de pas de temps via un paramètre comparator_date_step_button
(True
ou False
) dans la table conf
de la BDD.
Voir commit bbc50b7
l'affichage de la date complète dans les sélecteurs et les filtres n'est pas des plus adaptée. Sur les photos anciennes, nous n'avons pas les dates précises des clichés. Dans ce cas, nous avons tout même renseigné le champ filter_date
(format date) avec 1994-01-01 par exemple afin qu'un filtrage par date (même imprécise) soit tout de même possible et surtout, pour respecter la contrainte non-null de ce champ dans le formulaire d'ajout de photos du back-office (en passant, la contrainte NOT NULL correspondante n'existe pas en BDD).
Du coup, c'est un peu moche d'afficher ces dates approximatives dans le bouton de filtre et le sélecteur qui en dépend...
Solution proposée : pouvoir choisir le formatage des dates affichées dans les boutons via un paramètre comparator_date_format
dans la table conf
de la BDD. Avec la valeur year
on affiche la date au format YYYY
. Avec month
--> MM/YYYY
.
Le comportement par défaut reste l'affichage de la date complète au format "day" --> DD/MM/YYYY
(si paramètre non-renseigné). Ce paramètre permet aussi de filtrer en conséquence les pas de temps disponibles dans le bouton ad-hoc (exemple : si month
est défini, les pas de temps disponibles seront 1 mois
et 1 an
). Utile dans le cas où les dates de photos sont parfois imprécises (photos ancienns, cartes postales...).
Voir commit 6c2ed78
Ce n'est probablement pas parfait voire perfectible niveau code mais cela reste assez simple et ajoute de la généricité au comparateur je trouve.
Qu'en pensez vous ?
On a renommé /comparator/:id en /site/:id
C'est pas mal, mais on aurait plutôt dû faire /sites/:id
Ainsi la page /map pourrait devenir /sites et là on aurait quelque chose de logique.
Non ?
Il est prévu que l'application puisse être multilingue au niveau du Frontend en se basant sur des fichiers de langue.
Lors de la mise à jour applicative via le script geopaysages/update_app.sh, les pages personnelles créées depuis le fichier sample.html ne sont pas récupérées. Cela demande de tout refaire, c'est à dire récupérer depuis l'archive faite par le script update_app.sh
Donc voir la pertinence de cette issue pour son développement.
Vu avec Vincent Bourgeois. Le plus couteux en développement est la partie python.
Il semblerait qu'aucune zone ou page ne soit prévue pour présenter le portail, la démarche, le contexte. Assez brut et déconcertant du coup. Et peu explicite.
Il faudrait prévoir à minima :
Sur le modèle de ce qui a été fait dans GeoNature-atlas par exemple
Lorsque l'on créé un site, on ne peut pas le valider sans y associer une photo.
Cependant, dans notre cas, on importe les images, on ne les charge pas par l'admin.
Du coup on souhaite créer le site, puis lancer un import, et donc pouvoir créer un site sans y ajouter de photo.
A voir si c'est faisable.
Pourquoi pas passer cette contrainte en paramètre ?
Les retours à la ligne dans les champs de textes ne sont pas interprétés dans la fiche d'un site (présentation et témoignage).
Comme ce sont les deux seuls attributs dans lesquels on peut intégrer du contenu descriptif, il serait très utile de pouvoir styliser et structurer un peu le contenu ces blocs de textes.
A minima en interprétant les caractères de saut de ligne (\n
) voire, idéalement, en interprétant de l'HTML (avec un éditeur simple côté backoffice).
Un exemple dans notre contexte :
Différents champs de notre BD historique contiennent des textes (analyses paysagère du site) que j'ai concaténés selon une certaine structure pour voir (incluant des sauts de lignes).
Aperçu du rendu d'un même texte :
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.