[OSM-talk-fr] orthophoto HR 2016 de normandie

Jeu 20 Juil 23:19:12 UTC 2017

c'est une solution envisageable: faire une demande pour mettre ça sur un ou
plusieurs gros disques mis à disposition à la demande de quelques uns (par
un hébergement limité permettant juste de télécharger des groupes de
fichiers découpés en blocs correspondant à des zones assez petites (un
département ou arrondissement, voire une grosse commune urbaine mais pas
beaucoup plus loin pour Caen, Rouen ou Le Havre) mais pas trop gros pour
que chacun puisse mettre ça sur un cloud public pas cher ou même gratuit
(mais avec une bande passante limitée).
Ensuite se faire des mini-serveurs WMS pour ces zones, et travailler en
petits groupes qui se refileront l'adresse entre eux (pour éviter que trop
de monde aille puiser dedans et consommer toute la bande passante dont ils
ont besoin).
Mais ça mériterait un greffondans JOSM par exemple (ou une option dans le
greffon actuel) pour gérer un cache local particulier (qui serait protégé
de l'opération de purge automatique de tous les calques qui sont visibles
en même temps: la purge serait manuelle dans le dossier du cache), mais
aussi faire un téléchargement de ce cache en tâche de fond.

Autre option intéressante à réfléchir: ajouter à ce cache JOSM une fonction
de partage P2P (Torrent?) des tuiles (ou jeux de tuiles d'un même dossier
du cache pour un niveau de zoom donné) pour soulager les serveurs WMS
actuels (utilisable si la licence des WMS permet la redistribution
collaborative) en incorporant dans JOSM la fonction de "seeding" d'un
nouveau torrent en plus de celle de recherche des peers. Mais je ne connais
pas bien les implémentations actuelles du protocole Torrent en Java ou si
il vaut mieux passer par une implémentation native avec une DLL (Windows)
ou une .so (Linux) et une classe d'interface native Java (x86, x64, arm?).
Des implémentations en pure Java (sans code natif) du protocole existent
depuis près de 15 ans et ont du s'améliorer depuis (aussi bien leur code
que les machines Java qui n'ont cessé de gagner en performance).

Il y a aussi d'autres protocoles P2P (les plus intéressants étant ceux
basés sur Kademlia pour l'indexation et la recherche des peers). Mais il
faut aussi inclure en plus (indépendamment du protocole P2P utilisé) un
client de configuration UPNP et d'autres systèmes de configuration
dynamique des NAT et parefeux et eventuellement aussi des tunnels sur IPv6
ou des tunnels TCP virtuel sur UDP/IPv4) pour que les partages soient
accessibles et routables depuis les clients distants (sans quoi le partage
ne fonctionnera pas bien car trop de participants ne pourront pas rendre
leurs contenu local accessible de l'extérieur sans configuration complexe
de leur réseau local ou box internet ou de leur logiciel parefeu local).
C'est compliqué aujourd'hui avec la prolifération des systèmes de NAT et de
leurs options (pas toujours sous contrôle de l'abonné connecté à un FAI et
parfois avec des blocages de protocoles imposés par eux).

Pour se rendre compte de la difficulté, il suffit de voir les sites de
support de jeux connectés; Microsoft aussi a développé sa solution pour
Windows 8/10, basée sur des tunnels IPv6 virtuels (protocole Teredo) et une
prise en charge en aval de Teredo sur pleins de systèmes de routage local
ou NAT mais avec l'aide d'un serveur central pour coordonner les accès et
stabiliser les routages ou les renouveler régulièrement. Mais là encore
cela ne marche pas toujours non plus (Microsoft ayant oublié ceux qui ont
un accès IPv6 natif mais une connectivité IPv4 très limitée et pas assez
stable pour tenir des tunnels ouverts assez longtemps, notamment pour les
réseaux d'accès mobiles asiatiques, et ayant oublié une configuration UPNP
comparable en IPv6 pour configurer les passerelles natives IPv6, ou
l'allocation locale d'adresse IPv6 supplémentaires dans le bloc alloué à
l'abonné et éviter ainsi les translations NAT et PAT ainsi que le surcoût
des protocoles d'encapsulation pour les tunnels).

Le 20 juillet 2017 à 21:52, marc marc <marc_marc_irc at hotmail.com> a écrit :

> idée de solution :
> se demander ce qu'on va faire de ortho haute définition : vérifier
> l'existant ? corriger des erreurs de cadastre ? meilleur localisation
> des routes ? autre ?
> en déduire un ordre de grandeur de temps nécessaire pour 1km2
> compter le nombre de personne intéressé pendant 1 mois
> cela permet d'estimer la surface qui pourrait être traité
> on la met dispo à usage interne pendant 1 mois.
> le mois d'après, on passe à la zone suivante
> il ne resterait alors plus que le problème :
> - couper l'archive ou les archives initiales en zone. je n'ai cependant
> aucune idée sous quelle forme l'info est actuellement.
> - stoker ces éléments d'ici leur utilisation soit "hors ligne"
> soit en mode distribué via x comptes pseuo-gratuit en attendant mieux
>
> Le 20. 07. 17 à 14:44, Christian Quest a écrit :
> > Il y a un paquet de nouvelles ortho en haute-def qui sont disponibles
> > sous licence ouverte depuis quelques temps... on en a même parlé lors de
> > notre dernier CA ;)
> >
> > Actuellement il y a plus d'une quarantaine de départements et quelques
> > agglos avec des définitions qui sont en général de 20cm/pixel voire 10
> > et les prochaines devraient même aller jusque 5cm/pixel !
> >
> > Voilà pour la bonne nouvelle... maintenant la moins bonne...
> >
> > C'est LOURD, très lourd comme vous pouvez l'imaginer. La moitié de la
> > France est ainsi couverte, soit plus de 250.000km2, avec environ 25
> > millions de pixels/km2... soit 6250 milliards de pixels...
> >
> > J'évalue le stockage nécessaire à 5To. Actuellement on n'a pas cette
> > capacité sur l'infra OSM-France à dédier uniquement pour cet usage.
> >
> > Je compte tester avec les orthos les plus récentes sur un serveur perso
> > (dans ma cave) où j'ai 8To... ça fait partie de mes devoirs de vacances
> ;)
> > Si ça vaut le coup et que c'est gérable, on peut envisager de mettre à
> > niveau un des serveurs chez free pour ce contenu (ils ont 8 emplacements
> > pour des disques 2,5" donc potentiellement 32To au max en HDD).
> >
> > A plus court terme, il faut aussi voir aussi si ces orthos ne sont pas
> > mise à disposition en TMS ou WMTS, donc tuilées pour un usage direct
> > dans nos outils habituels ce qui nous évite de les héberger nous même.
> >
> >
> > Le 20/07/2017 à 13:48, marc marc a écrit :
> >> Il faudrait peut-être leur écrire pour demander le taille.
> >> si osm.fr est limité en bande passante, je pense que cela serrait quand
> >> même pratique en interne quitte a limiter volontairement la bande
> >> passante de ce service précis.
> >> Si le problème est l'espace disque, c'est évidement plus délicat.
> >> Comment fonctionne le partenariat avec la Fondation Free ?
> >> l'asso demande au cas par cas de ses besoins ?
> >> ou c'est figé ?
> >>
> >> Le 20. 07. 17 à 11:43, Philippe Verdy a écrit :
> >>> C'est "dispo" peut-être mais sur demande par mail. Ca veut dire qu'ils
> >>> n'ont pas les moyens d'héberger un serveur TMS/WMS
> >>> Peut-être que la Fondation Free a encore des moyens pour héberger ça en
> >>> ligne. Je ne suis pas convaincu qu'OSM France ait ces moyens car on
> voit
> >>> déjà comment on l'espace de stockage et la bande passante sont déjà des
> >>> problèmes de capacité.
> >>>
> >>> Le 20 juillet 2017 à 10:48, David Crochet a écrit :
> >>>      c'est intéressant ?
> >>>
> >>> http://www.geonormandie.fr/accueil/les_actualites/
> actualites_de_geonormandie/109_845/lorthophotographie_
> regionale_haute_resolution_de_20152016_est_disponible_
> >>>
> >>
> >
>
> _______________________________________________
> 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/20170721/cf768fb7/attachment.htm>