Choix - OD4M.dev

06-05-2020 21-07-2020 30-11-2020 En ce qui concerne le parcours d'un point (représentant une entrée) le long d'un bâtiment, la préselection du bâtiment permet de s'affranchir de calculs de distances lourds car concernant beaucoup de bâtiments.

Les contributions – c'est à dire envoyer les changesets sont envoyés par le serveur, une fois validées par les contributeur-e-s. La contribution passe par une étape de caractérisation (des portes, des trottoirs) et géographique Nous faisons le choix d'envoyer les contributions en même temps : - pour éviter une opération supplémentaire - pour ne pas retarder la validation, puisque la vérification est déjà faite par l'utilisateur - pour ne pas "perdre" des contributions inopinément

Les changesets peuvent concerner : - [X] Ajout d'une porte - [X] Modification d'une porte - [ ] Ajout de note - [ ] Ajout de chemins piétons / passages piétons / bordures de trottoirs

Choix techniques

Backend

garder les tokens secrets fournis par osm côté serveur ✓
le lien avec le front se fait sur la base d'une session ✓
API
- gabarit avec Express ;
- voir les avantages de Loopback , qu'est ce qui est déjà mis en place ?
Osm-Request
utilisable côté serveur ?
oui, avec un bridge XMLHttpRequest pour node
et class XMLDocument

OSM-UI-React

mises à jour des outils et dépendances :
- Node : v14 ✓
- Storybook --> ^5.3 ✓
- styled-components 3.4
méthodes obsolètes à migrer
- méthodes de vie React
- withInfo dans StoryBook ✓
modifications de composants
- export icones AwesomeFont corrigé ✓
- transfert de référence sur le composant Map, pour accéder à l'élément Leaflet ✓
- transitions des notifications
- icones sur boutons
- themes des boutons non visibles (bug)
ajouts de composants
- DragList ✓
- Polygon avec thème ✓
migrations
- modifier les transitions (SideBar, Modal), utiliser FramerMotion (successeur de Pose)

Architecture

discussion avec Jean-Marie, puis sur irc #osm-dev :
- les requetes se passent-elles via un serveur od4m, ou directement vers
- plutôt des requetes pour Overpass api, ou Osm api ?
- où se situe le cache ?
  - côté serveur (cache partagé) ;
    - mon serveur, ou le reverse proxy ? (1)
  - côté client (éviter les requetes inutiles, mais demande de stocker)
- questions liées aux données (rgpd) :
  - stocker des préférences...
  - stocker les modifications faites avec l'outil
    - on peut retrouver ça à la connexion via osm api si besoin ; filtrer les 'od4m'
  - stocker les modifications commencées localement (hdd), juste le temps de la session ?
  - qu'est ce qui est vraiment utile ?
facts :
- La mise à jour d'un element (PUT) est impossible si le numéro de version a changé depuis le GET (voir doc API)
irc:
- <TomH> well mostly "how you edit data in osm" is to fetch from the osm api and then send to the osm api!
- <simonpoole> well "most" editors use the osm-api, that's what is there for
- <simonpoole> im amy case you are much more likely to run in to rate limiting from the overpass api than from the osm api
- voir la discussion irc

Philosophie de MapContrib v1

Choix sur l'outil OD4M

Choix techniques