[OSM-talk-fr] date de l'imagerie

Philippe Verdy verdy_p at wanadoo.fr
Dim 19 Aou 00:56:21 UTC 2018


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.pub at 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 at openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-fr
> >>
> >
> > _______________________________________________
> > Talk-fr mailing list
> > Talk-fr at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20180819/05c01c7d/attachment.html>


Plus d'informations sur la liste de diffusion Talk-fr