L'ennui surtout de ce tableau est que les millésimes les plus récents ne sont pas forcément les plus précis mais limité à 50cm de résolution contre 20cm pour les millésimes précédents (attention aux deux étoiles bleues sur certains départements). Le tableau ne mentionne pas les prises de vues plus précises à 5cm pour Paris (il manque une étoile rouge pour la ligne 75 de ce tableau).
Si on veut un CSV, il faudrait plusieurs colonnes en indiquant la meilleure résolution (donnée complémentaire : le millésime) ou la dernière prise de vue (donnée complémentaire : la résolution) : sur la plupart des départements, les deux millésimes correspondent et cela permet d'utiliser une seule source pour tous les niveaux de zoom. Sinon il faut déterminer le niveau de zoom à partir duquel la résolution est observable si on veut basculer automatiquement de l'un à l'autre (ou sinon proposer deux modes : dernier millésime, ou meilleure résolution). Ensuite il faut traduire ces résolutions métriques en niveaux de "zoom" pour OSM (ce n'est pas automatique, car cela dépend de la latitude moyenne du département, le "zoom" OSM utilisant une projection Mercator non orthométrique alors que les prises de vue sont "normalement" orthométriques à la résolution indiquée). Pour faire cette conversion il faut donc d'abord compléter une feuille de calcul avec une colonne pour indiquer la latitude moyenne permettant de calculer le le niveau de zoom correspondant à la résolution métrique. En faisant une conversion Mercator inverse. Et vérifier ensuite le calage obtenu et comparer aux métadonnées WMS. D'une façon ou d'une autre il faut aussi convertir les images "orthométriques" en images compatibles avec le Mercator. Certains éditeurs (comme JOSM) peuvent utiliser directement la source et adapter les images coté client en Mercator; sinon cela se fait sur un serveur qui créera une base d'image adaptée (cela peut non seulement corriger la projection, mais aussi changer l'orientation du nord géographique) : cette conversion côté serveur dérivé devra faire les assemblages des sources pour convenablement adapter les bordures (non carrées) de départements issus de sources différentes et de résolution différentes et trouver un moyen pour que leur fusion soit assez "clean", tout en évitant des trous laissés par endroit (cela devrait être exceptionnel) Atttention aussi : les images les plus précises (théoriquement) sur une département peuvent contenir des zones floutées à résolution bien moins bonne (cela concerne surtout les zones militaires). Mais je ne pense pas que les métadonnées WMS des sources mentionnent exhaustivement la liste des zones concernées avec leur géométrie où un floutage a été appliqué, ni la résolution effective de ce floutage. Monter un tel serveur WMS dérivé a un coût et demande pas mal de ressources (stockage et prétraitement) : tant qu'à faire, on pourrait combiner d'autres sources orthophotographiques et avoir des métadonnées sur les différentes résolutions proposées (y compris celles hors de ce tableau, notamment les sources des SIG de certaines collectivités locales : communes ou intercommunalités, et celles d'autres organismes (comme les prises de vues côtières) Il est en fait très difficile d'analyser ces sources d'imageries car leur métadonnées sont insuffisantes pour permettre une sélection automatique selon un des deux objectifs distincts : meilleure résolution, ou dernier millésime (et dans les éditeurs avoir le moyen de passer d'une vue à l'autre facilement : cela demande donc deux serveurs d'images. C'est donc plus qu'un CSV qu'il faut, mais une structure plus complexe (déjà il faut une feuille de calcul, mais en plus il faut des données de géométrie et pouvoir détailler des zones lacunaires, aucune source actuellement n'a une résolution métrique réellement homogène partout dans sa zone de couverture, et cette zone en plus n'est pas un simple rectangle). Si on doit finalement synthétiser cela la meilleure représentation n'est pas le CSV mais un fichier .osm ou GeoJSON permettant de combiner géométries des zones de couverture est zones floutées, et leur résolution effective (dans des "tags" de métadonnées) ainsi que des données de calage de l'orthogéométrie (orientation, décalage: une matrice de transformation linéaire applicable à des bandes de latitude pas trop grandes dans lesquelles la transformation n'introduit pas trop d'écart par rapport à la résolution orthométrique des images sources)... Ce format GeoJSON (ou .osm équivalent) reste à inventer et ensuite utiliser, il peut combiner des zones d'imageries de formes non rectangulaire, et de toutes les sources, on peut ensuite déterminer automatiquement des listes de polygones communs à ces sources pour découper les bandes et pour chaque polygone obtenu donner la liste des sources, leur millésime et leur résolution orthométrique effective. Un éditeur avancé pourra proposer alors automatiquement la meilleure vue pour chaque polygone (la plus précise ou la plus récente, ou proposer la listes des autres sources. Attention aussi car les orthorectifications des sources ne sont pas exactement les mêmes d'un millésime à l'autre (car leur MNT a évolué) : caler les assemblages de vues peut produire des artefacts de discontinuité d'une zone à l'autre (même depuis la même source où on les voit déjà... car ces sources sont déjà elles-mêmes des assemblages). Actuellement il n'y a encore Le sam. 18 août 2018 à 23:32, deuzeffe <opensm....@deuzeffe.org> a écrit : > Grmblblblbl : > > https://www.geoportail.gouv.fr/depot/fiches/photographiesaeriennes/geoportail_dates_des_prises_de_vues_aeriennes.pdf > > On 17/08/2018 16:48, deuzeffe wrote: > > Je regarde ça. > > > > On 17/08/2018 12:36, Christian Quest wrote: > >> La source de l'umap ce sont les shapefile de mosaique de la BDORtho > >> 5m... republiés dans OpenEventDatabase > >> > >> Par contre, il faut aussi prévoir la mise à jour de cette source, car > >> là ça commence à dater. Ce n'est pas parfait non plus car c'est la BD > >> Ortho 5m (donc gros pixels) alors qu'on a maintenant des zones avec du > >> 5cm (Paris). > >> > >> Sinon, l'IGN publie les années de prises de vues de la BD Ortho > >> département par département, ce qui peut être largement suffisant > >> comme info: http://professionnels.ign.fr/mises-a-jour > >> > >> Pour 2017 on trouve: > >> > >> 21-24-25-39-47-87-971-972-978 à 20cm > >> > >> 21-24-25-39-75-92-93-971-972-978 06-07-21-47 56 13-25-39-47-87-971 à > 50cm > >> > >> Malheureusement, ces tableaux ne sont pas très simple à lire car on a > >> des millésimes différent en fonction des niveaux de zoom. > >> > >> Si un courageux veut remettre ça au propre dans un beau CSV ça serait > >> fort utile. > >> > >> > >> Le 15/08/2018 à 02:26, marc marc a écrit : > >>> Le 15. 08. 18 à 02:16, Jérôme Seigneuret a écrit : > >>>> la date de la prise de vu comme on peut l'avoir sur Google Earth ou > >>> il y a les 2 lorsque les 2 sont disponibles. > >>> la date de capture dans josm s'affiche chez moi avec > >>> comme mention "métadonnée capture date" > >>> et est visible par exemple avec la couche Bing > >>> oui je sais c'est triste comme exemple :) > >>> > >>> Mais si quelqu'un est motivée pour coder l'injection des infos > >>> dans les headers du proxy BDOrtho osm-fr, c'est techniquement possible > >>> et un coup de main n'est jamais refusé :) > >>> sinon c'est sur ma longue liste de chose à faire... et pas la moindre > >>> idée de ce que cela va impliquer en boulot (j'ai pas encore regardé > >>> la source de l'umap de Christian) > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > 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
