Y a-t-il moyen d'enrichir les métadonnées sur ce poroxy pour qu'il mentionne des corrections de date effective de mise à jour, afin de pouvoir alors utiliser une autre source ortho plus récente ?
L'idée serait d'associer à une donnée en cache sur une zone indiquant une date de la ramener à une date antérieure plus correcte (juste enregistrer ces deux dates sur cette zone définie comme un ensemble de tuiles: toutes les tuiles dont la BD Ortho mentionnant une date entre les deux sera ramenée à la plus ancienne; si plus tard la BD Ortho met à jour cette zone avec des tuiles valides, elle indiquera avec cette tuile une date hors de cet intervalle, et alors le cache de dates corrigées pourrait être supprimé automatiquement au moins sur cette tuile; on peut garder en cache le contour de la zone avec la technique des "quadtiles" pour en réduire le volume, par exemple si cela concerne un département entier comprenant de nombreuses tuiles; évidemment ce cache est dépendant du niveau de zoom, chaque niveau ayant ses mises à jour) --- Ensuite on pourrait imaginer de mettre en place un *autre* serveur (beaucoup plus compliqué!) permettant de combiner les sources d'ortho ayant chacune ce système de cache de dates, pour les comparer et ne retenir que la plus récente dans les requétes par défaut (mais les métadonnées pourraient lister plusieurs versions venant de différentes sources, ces sources étant classées par date, et permettant de voir certaines évolutions. La précision des dates devrait aller jusqu'à l'heure précise à la seconde (afin de détecter certaines mises à jour incrémentales dans une zone, ou quand la couverture vient d'une même série orthogreaphique mais "travaillée" différemment selon les sources, et qu'on pourrait différencier). Le système pourrait également gérer une préférence entre plusieurs sources quand elles portent sur des dates assez proches (par exemple moins d'un mois d'écart entre elles) On pourrait alors combiner les sources (BdOrtho, Bing, Orthos des collectivités locales... toutes celles accessibles par un TMS ou WMS, y compris celles accédées via un proxy comme ci-dessus) Avec les métadonnées seraient prises en compte également les corrections de décalage de chaque source: le serveur assurant alors automatiquement le décalage pour réaligner les sources entre elles (en refabriquant des tuiles à la volée dans son cache local (plus qu'un simple "proxy web" qui garde les tuiles intactes) Y compris en effectuant si possible des transformations de géométrie (par exemple application/correction d'un modèle de terrain, rotation/réorientation du nord, changement de projection...) par application d'une simple transformée linéaire visant à repositionner les 4 points de la tuile source et le point central (en découpant cette tuile source le long des 2 diagonales en 4 triangles, chaque triangle ayant alors sa matrice bien définie) : pour le faire, le serveur devrait disposer d'un accélérateur graphique (bien refroidi!) capable de découper les tuiles sources (sur les parties imprécises/floutées/crantées), puis calculer ces transformées (correctement lissées...) et de produire des recombinaisons des images obtenues pour produire la tuile finale (à garder en cache évidemment). Si l'accélérateur graphique est surchargé et ne peut répondre en un temps réaisonnable (file d'attente pleine ou supérieure à une dizaine de secondes), en attendant le serveur peut juste retourner une des tuiles sources (la plus récente) mais avec en métadonnée une date d'expiration courte (~1 minute si la tuile demandée a pu entrer dans la file d'attente, permettant de réinterroger plus tard lorsque la tuile plus précise a été régénérée, sinon ~1 heure si la file d'attente est pleine), et la mention qu'elle n'est pas encore réalignée à sa géométrie correcte: il lui suffit de retourner une redirection temporaire (avec l'expiration de ~1 minute ou ~1 heure) vers la source supposée la meilleure (le serveur n'aura pas à s'occuper de la charger, le client le fera lui-même). Evidemment un tel serveur demanderait beaucoup de ressources matérielles (traitement graphique), beaucoup plus de stockage local (pour cacher les tuiles sources, et les tuiles recombinées, ainsi que toutes les métadonnées nécessaires) et aussi de la bande passante pour interroger plusieurs sources d'ortho et garder/ordonner par date leurs infos de mise à jour et licences, et produire sur les tuiles combinées des infos listant les sources utilisées pour la produire quand ces sources ne sont pas strictement alignées sur le même modèle ortho ou quand toute la tuile n'est pas exploitable notemment en bordure de zone de couverture, où on devrait pouvoir aussi éliminer un morceau/le rendre transparent pour afficher à la place une autre source couvrant la zone même si elle est plus ancienne ou moins précise car le serveur ferait alors les "raccords"). Le 27 mai 2016 à 18:09, Christian Quest <cqu...@openstreetmap.fr> a écrit : > Voilà, j'ai mis en place un proxy pour tester l'accès à la BD Ortho suite > à la signature de la convention avec l'IGN vendredi dernier (déjà une > semaine !). > > Afin de respecter les termes de la convention, j'ai installé un proxy sur > un de nos serveurs, qui assure en plus un peu de cache (8Go conservé > maximum 30j). > J'ai aussi simplifié l'URL car celles du géoportail piquent les yeux ;) > > Donc dans JOSM, vous pouvez ajouter: > tms[19]:http://proxy-ign.openstreetmap.fr/bdortho/{zoom}/{x}/{y}.jpg > > Rappel: la convention n'autorise qu'un usage pour compléter et mettre à > jour les données OSM, donc un usage dans nos outils d'édition. > > Pensez à mettre "source=BDOrtho IGN 2016" sur les changeset ou les objets. > > Voici aussi un fichier CSV avec les dates de prises de vue et la > résolution par département: > https://gist.github.com/cquest/e0682246cce5dc562f8f1b3135466b4b > > Sur certains départements, le(s) dernier(s) niveau(x) de zoom peuvent être > plus anciens que l'année indiquée. C'est le cas sur le 89. > > Merci de remonter les problèmes que vous rencontrerez > -- > Christian Quest - OpenStreetMap France > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
