Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

Yes !

Config modifiée et du coup vous pouvez maintenant utiliser 
http://proxy-ign.openstreetmap.fr/bdortho/{z}/{x}/{y}.jpg dans iD sans 
oublier l'attribution "BDOrtho IGN" dans les changeset ou en source sur 
les objets créés...



Le 01/07/2016 à 12:39, osm.sanspourr...@spamgourmet.com a écrit :


1.

En fait sur les pages ID on voit que les tuiles demandées telles
que

https://ecn.t2.tiles.virtualearth.net/tiles/a031331031023230310.jpeg?g=587=en-gb=z
ont bien un referer.


2.
Referer:
http://www.openstreetmap.org/id
3.


Le 01/07/2016 à 12:25, osm.sanspourr...@spamgourmet.com a écrit :


Effectivement ce que bhousel propose c'est :

- soit de changer le token quand on détecte un abus

- soit d'utiliser un cookie qui sera créé après acceptation des 
conditions d'utilisation.


Il a clos le ticket.

Philippe, oui un referer se contourne mais il montre une volonté de 
violer la licence et demande un peu de travail pas à la portée de 99 
% des utilisateurs. L'idée c'est d'éviter que n'importe qui réutilise 
les tuiles à n'importe quel dessein.


Jean-Yvon


Le 27/06/2016 à 18:42, Philippe Verdy - verd...@wanadoo.fr a écrit :
Le "referer:" aussi est facile à reprendre, même pour une navigation 
sur un site tiers avec un navigateur normal, la requête peut être 
effectuée en Javascript avec les champs MIME qu'on veut (et faciles 
à obtenir juste avec la console réseau du navigateur). Cependant ça 
élimite les utilisations les plus simples avec un framework 
OpenLayers ou similaire non modifié.


Sans identification du client (inscription de compte, mot de passe, 
etc.), ou sans mise à jour régulière des clés sur le serveur web 
référent (qui doit avoir alors une connexion avec le fournisseur de 
carto tiers pour autoriser pendant un temps limité des sessions pour 
chaque client connnecté au serveur référent, le client devant 
redemander une clé au serveur référent qui la renouvellera avec le 
serveur tiers, ou bien le client devra ouvrir une session SSL 
résidente en utilisant des clés négociées par l'intermédiaire du 
serveur référent, sur laquelle transiteront ensuite les requêtes de 
tuiles en HTTPS), il n'est pas tellement possible de sécuriser cette 
restriction d'accès.






___
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



--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[osm . sanspourriel]

1.

   En fait sur les pages ID on voit que les tuiles demandées telles que
   
https://ecn.t2.tiles.virtualearth.net/tiles/a031331031023230310.jpeg?g=587=en-gb=z
   ont bien un referer.


2.
   Referer:
   http://www.openstreetmap.org/id
3.


Le 01/07/2016 à 12:25, osm.sanspourr...@spamgourmet.com a écrit :


Effectivement ce que bhousel propose c'est :

- soit de changer le token quand on détecte un abus

- soit d'utiliser un cookie qui sera créé après acceptation des 
conditions d'utilisation.


Il a clos le ticket.

Philippe, oui un referer se contourne mais il montre une volonté de 
violer la licence et demande un peu de travail pas à la portée de 99 % 
des utilisateurs. L'idée c'est d'éviter que n'importe qui réutilise 
les tuiles à n'importe quel dessein.


Jean-Yvon


Le 27/06/2016 à 18:42, Philippe Verdy - verd...@wanadoo.fr a écrit :
Le "referer:" aussi est facile à reprendre, même pour une navigation 
sur un site tiers avec un navigateur normal, la requête peut être 
effectuée en Javascript avec les champs MIME qu'on veut (et faciles à 
obtenir juste avec la console réseau du navigateur). Cependant ça 
élimite les utilisations les plus simples avec un framework 
OpenLayers ou similaire non modifié.


Sans identification du client (inscription de compte, mot de passe, 
etc.), ou sans mise à jour régulière des clés sur le serveur web 
référent (qui doit avoir alors une connexion avec le fournisseur de 
carto tiers pour autoriser pendant un temps limité des sessions pour 
chaque client connnecté au serveur référent, le client devant 
redemander une clé au serveur référent qui la renouvellera avec le 
serveur tiers, ou bien le client devra ouvrir une session SSL 
résidente en utilisant des clés négociées par l'intermédiaire du 
serveur référent, sur laquelle transiteront ensuite les requêtes de 
tuiles en HTTPS), il n'est pas tellement possible de sécuriser cette 
restriction d'accès.






___
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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[osm . sanspourriel]

Effectivement ce que bhousel propose c'est :

- soit de changer le token quand on détecte un abus

- soit d'utiliser un cookie qui sera créé après acceptation des 
conditions d'utilisation.


Il a clos le ticket.

Philippe, oui un referer se contourne mais il montre une volonté de 
violer la licence et demande un peu de travail pas à la portée de 99 % 
des utilisateurs. L'idée c'est d'éviter que n'importe qui réutilise les 
tuiles à n'importe quel dessein.


Jean-Yvon


Le 27/06/2016 à 18:42, Philippe Verdy - verd...@wanadoo.fr a écrit :
Le "referer:" aussi est facile à reprendre, même pour une navigation 
sur un site tiers avec un navigateur normal, la requête peut être 
effectuée en Javascript avec les champs MIME qu'on veut (et faciles à 
obtenir juste avec la console réseau du navigateur). Cependant ça 
élimite les utilisations les plus simples avec un framework OpenLayers 
ou similaire non modifié.


Sans identification du client (inscription de compte, mot de passe, 
etc.), ou sans mise à jour régulière des clés sur le serveur web 
référent (qui doit avoir alors une connexion avec le fournisseur de 
carto tiers pour autoriser pendant un temps limité des sessions pour 
chaque client connnecté au serveur référent, le client devant 
redemander une clé au serveur référent qui la renouvellera avec le 
serveur tiers, ou bien le client devra ouvrir une session SSL 
résidente en utilisant des clés négociées par l'intermédiaire du 
serveur référent, sur laquelle transiteront ensuite les requêtes de 
tuiles en HTTPS), il n'est pas tellement possible de sécuriser cette 
restriction d'accès.




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Philippe Verdy]

La plus fiable ? hmmm pas du tout. Les changesets évoluent ou pas sur
OSM indépendamment des mises à jour du TMS. La date sera donc toujours
fausse.

Vous supposez que dès que le TMS est modifié il va y avoir une modif dans
OSM (on ne sait ça prend du temps, des mois voire des années sur les
niveaux de zoom élevés, et il y a aura des mises à jour OSM un peu partout
sans que le TMS soit mis à jour (tuiles de 2012 par exemple mais avec des
données quelconques dans OSM de 2016 qui viennent à tout moment).


Le 28 juin 2016 à 12:52, Nicolas Dumoulin  a écrit :

> Le Mon, 27 Jun 2016 19:08:44 +0200,
> Christian Quest  a écrit :
> > La date du changeset suffit, non ?
>
> Oui.
>
> Pour ce qui est de produire ou extraire la date des prises de vue,
> comme le dit Jean-Yvon il faudrait des métadonnées supplémentaires que
> nous n'avons pas. On va donc se contenter de la date du changeset qui
> reste l'info la plus fiable pour l'instant.
>
> --
> Nicolas Dumoulin
>
>
> ___
> 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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Philippe Verdy]

Pourquoi un second TMS ? Ca ne peut pas être ajouté directement par le
Framework javascript (qui peut lire les métadonnées des tuiles dans le
cache du navigateur, et les afficher en superposition comme du texte). Pas
besoin d'autre serveur.

Selon le framework utilisé il doit bien y avoir un "hook" Javascript
permettant de détecter l'évènement "onload" quand la tuile s'est chargée.
Par défaut l'image est juste chargée et affichée, mais on doit pouvoir
faire autre chose, et alors positionner le libellé dans un coin, dans une
couche transparente superposée (qu'on peut activer ou pas dans le menu des
couches en cochant la case ad hoc)...

Le 28 juin 2016 à 13:52,  a écrit :

> Effectivement une exigence de la licence est de dater, sauf qu'il n'est
> pas précisé ce qu'ils entendent par date de référence.
>
> Soit c'est 2016 (date d'utilisation du TMS) soit c'est ce que dit Philippe.
>
> Sauf que pour faciliter le travail (je ne vois pas madame Michu mettre un
> Wireshark pour regarder les entêtes HTTP des tuiles) je pensais plus à un
> second TMS qui afficherait les dates, que l'on pourrait mettre en
> transparence afin de savoir aussi quand on trace d'après un cliché la date
> des informations. Et pour faire simple
>
> |--|--|--|
> | 2016 | 2015 | 2015 |
> |--|--|--|
> | 2016 | 2015 | 2015 |
> |--|--|--|
> | 2014 | 2015 | 2015 |
> |--|--|--|
>
> P.S. : monsieur Michu non plus. C'est le mari de madame Michu ?
>
> Nicolas, tu veux dire que l'année de référence est donc forcément l'année
> du changement (et le changement c'est maintenant 2016 ;-)).
>
> Dans ce cas l'exigence du partenariat (date de référence) serait un
> non-sens et en dirait long sur la connaissance d'OSM par l'IGN.
>
> Jean-Yvon
> Le 28/06/2016 à 11:34, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> Quel changeset? On parle du TMS de la BD Ortho, indépendamment des
> changesets qu'on peut produire en s'appuyant dessus sur OSM. Ce qui est
> intéressant de connaitre ce sont les dates des clichés (plus même que les
> dates de génération des tuiles, qui sont orthrectifiées et sont par endoit
> des assemblages de clichés juxtaposés pais pas forcément à la même date).
> L'ennui c'est qu'en cas d'assemblage sur une tuile, il est difficile de
> tracer la date de chaque cliché. Donc au mieux cela devrait donner la date
> de génération de la tuile (ou de la métatuile plus grande dont pourrait
> être extraite la tuile demandée).
> Au minimum, cette info devrait être dans les entêtes MIME HTTP (ce qui
> permet ensuite de gérer les caches en aval en cas de mise à jour sur le
> serveur). Et je ne sais pas si le serveur TMS peut gérer dans ses
> métadonnées un historique de versions, ou propose un moyen de les
> consulter, s'il y a conservation de versions plus anciennes).
>
> Uniquement des requête HTTP "HEAD /chemin de la tuile" sur le serveur
> devrait retourner l'info, et la navigation normale devrait faire des "GET
> /chemin de la tuile" avec if "If-Updated-Since:" contenant la version dont
> dispose un client dans son cache. Tout ça c'est du HTTP/1.1 très standard.
> Les métadonnées ou requêtes spécifiques pour obtenir une liste des versions
> historiques et leur chemin d'accès c'est peut-être beaucoup demander.
>
> (OSM non plus ne garde pas ses tuiles historiques dans son rendu,
> cependant il devrait aussi gérer les dates de mises à jour pour une gestion
> efficace des caches clients, qui lui fait aussi économiser de la bande
> passante et améliore beaucoup l'expérience utilisateur avec une plus grande
> fluidité pour ne pas recharger les mêmes tuiles déjà en cache et pas mises
> à jour côté serveur)
>
> Le 27 juin 2016 à 19:08, Christian Quest  a
> écrit :
>
>> La date du changeset suffit, non ?
>>
>> Le 27 juin 2016 à 17:53,  a écrit :
>>
>>> Le 27/06/2016 à 10:44, Christian Quest - 
>>> cqu...@openstreetmap.fr a écrit :
>>>
>>> La convention est en pièce jointe sur: http://openstreetmap.fr/bdortho
>>>
>>> Manque juste la définition de l'année de référence.
>>> Est-ce l'année de consultation (2016) ou l'année des photos ?
>>> Dans le second cas il faudrait avoir un accès facile à la donnée.
>>> Par exemple un TMS donnant par tuile l'année de la photo.
>>>
>>> Jean-Yvon
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

J'ai publié un tableau csv des années de prise de vues de la bdortho par
département.
Ce n'est pas forcément très homogène, surtout sur le zoom le plus élevé ou
l'on peut avoir des images plus anciennes et la date n'est pas clairement
indiquée par l'IGN.
Il y a 2 sujets bien différents:
- respecter la convention: la date du changeset permet de savoir quelle
millésime de la bdortho était utilisé au moment de la contribution
- permettre aux contributeurs de savoir de qd date l'ortho visible... et là
ce n'est pas si simple. Je vais vérifier si les dates dans les entêtes http
retournés par l'api du Geoportail contiennent ces infos et proposer un
layer dédié pour ça si c'est jouable.

Le mardi 28 juin 2016,  a écrit :

> Effectivement une exigence de la licence est de dater, sauf qu'il n'est
> pas précisé ce qu'ils entendent par date de référence.
>
> Soit c'est 2016 (date d'utilisation du TMS) soit c'est ce que dit Philippe.
>
> Sauf que pour faciliter le travail (je ne vois pas madame Michu mettre un
> Wireshark pour regarder les entêtes HTTP des tuiles) je pensais plus à un
> second TMS qui afficherait les dates, que l'on pourrait mettre en
> transparence afin de savoir aussi quand on trace d'après un cliché la date
> des informations. Et pour faire simple
>
> |--|--|--|
> | 2016 | 2015 | 2015 |
> |--|--|--|
> | 2016 | 2015 | 2015 |
> |--|--|--|
> | 2014 | 2015 | 2015 |
> |--|--|--|
>
> P.S. : monsieur Michu non plus. C'est le mari de madame Michu ?
>
> Nicolas, tu veux dire que l'année de référence est donc forcément l'année
> du changement (et le changement c'est maintenant 2016 ;-)).
>
> Dans ce cas l'exigence du partenariat (date de référence) serait un
> non-sens et en dirait long sur la connaissance d'OSM par l'IGN.
>
> Jean-Yvon
> Le 28/06/2016 à 11:34, Philippe Verdy - verd...@wanadoo.fr
>  a écrit :
>
> Quel changeset? On parle du TMS de la BD Ortho, indépendamment des
> changesets qu'on peut produire en s'appuyant dessus sur OSM. Ce qui est
> intéressant de connaitre ce sont les dates des clichés (plus même que les
> dates de génération des tuiles, qui sont orthrectifiées et sont par endoit
> des assemblages de clichés juxtaposés pais pas forcément à la même date).
> L'ennui c'est qu'en cas d'assemblage sur une tuile, il est difficile de
> tracer la date de chaque cliché. Donc au mieux cela devrait donner la date
> de génération de la tuile (ou de la métatuile plus grande dont pourrait
> être extraite la tuile demandée).
> Au minimum, cette info devrait être dans les entêtes MIME HTTP (ce qui
> permet ensuite de gérer les caches en aval en cas de mise à jour sur le
> serveur). Et je ne sais pas si le serveur TMS peut gérer dans ses
> métadonnées un historique de versions, ou propose un moyen de les
> consulter, s'il y a conservation de versions plus anciennes).
>
> Uniquement des requête HTTP "HEAD /chemin de la tuile" sur le serveur
> devrait retourner l'info, et la navigation normale devrait faire des "GET
> /chemin de la tuile" avec if "If-Updated-Since:" contenant la version dont
> dispose un client dans son cache. Tout ça c'est du HTTP/1.1 très standard.
> Les métadonnées ou requêtes spécifiques pour obtenir une liste des versions
> historiques et leur chemin d'accès c'est peut-être beaucoup demander.
>
> (OSM non plus ne garde pas ses tuiles historiques dans son rendu,
> cependant il devrait aussi gérer les dates de mises à jour pour une gestion
> efficace des caches clients, qui lui fait aussi économiser de la bande
> passante et améliore beaucoup l'expérience utilisateur avec une plus grande
> fluidité pour ne pas recharger les mêmes tuiles déjà en cache et pas mises
> à jour côté serveur)
>
> Le 27 juin 2016 à 19:08, Christian Quest  > a écrit :
>
>> La date du changeset suffit, non ?
>>
>> Le 27 juin 2016 à 17:53, > > a
>> écrit :
>>
>>> Le 27/06/2016 à 10:44, Christian Quest -
>>> 
>>> cqu...@openstreetmap.fr
>>>  a écrit :
>>>
>>> La convention est en pièce jointe sur: http://openstreetmap.fr/bdortho
>>>
>>> Manque juste la définition de l'année de référence.
>>> Est-ce l'année de consultation (2016) ou l'année des photos ?
>>> Dans le second cas il faudrait avoir un accès facile à la donnée.
>>> Par exemple un TMS donnant par tuile l'année de la photo.
>>>
>>> Jean-Yvon
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> 
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>> 

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[osm . sanspourriel]

Effectivement une exigence de la licence est de dater, sauf qu'il n'est 
pas précisé ce qu'ils entendent par date de référence.


Soit c'est 2016 (date d'utilisation du TMS) soit c'est ce que dit Philippe.

Sauf que pour faciliter le travail (je ne vois pas madame Michu mettre 
un Wireshark pour regarder les entêtes HTTP des tuiles) je pensais plus 
à un second TMS qui afficherait les dates, que l'on pourrait mettre en 
transparence afin de savoir aussi quand on trace d'après un cliché la 
date des informations. Et pour faire simple


|--|--|--|
| 2016 | 2015 | 2015 |
|--|--|--|
| 2016 | 2015 | 2015 |
|--|--|--|
| 2014 | 2015 | 2015 |
|--|--|--|

P.S. : monsieur Michu non plus. C'est le mari de madame Michu ?

Nicolas, tu veux dire que l'année de référence est donc forcément 
l'année du changement (et le changement c'est maintenant 2016 ;-)).


Dans ce cas l'exigence du partenariat (date de référence) serait un 
non-sens et en dirait long sur la connaissance d'OSM par l'IGN.


Jean-Yvon

Le 28/06/2016 à 11:34, Philippe Verdy - verd...@wanadoo.fr a écrit :
Quel changeset? On parle du TMS de la BD Ortho, indépendamment des 
changesets qu'on peut produire en s'appuyant dessus sur OSM. Ce qui 
est intéressant de connaitre ce sont les dates des clichés (plus même 
que les dates de génération des tuiles, qui sont orthrectifiées et 
sont par endoit des assemblages de clichés juxtaposés pais pas 
forcément à la même date).
L'ennui c'est qu'en cas d'assemblage sur une tuile, il est difficile 
de tracer la date de chaque cliché. Donc au mieux cela devrait donner 
la date de génération de la tuile (ou de la métatuile plus grande dont 
pourrait être extraite la tuile demandée).
Au minimum, cette info devrait être dans les entêtes MIME HTTP (ce qui 
permet ensuite de gérer les caches en aval en cas de mise à jour sur 
le serveur). Et je ne sais pas si le serveur TMS peut gérer dans ses 
métadonnées un historique de versions, ou propose un moyen de les 
consulter, s'il y a conservation de versions plus anciennes).


Uniquement des requête HTTP "HEAD /chemin de la tuile" sur le serveur 
devrait retourner l'info, et la navigation normale devrait faire des 
"GET /chemin de la tuile" avec if "If-Updated-Since:" contenant la 
version dont dispose un client dans son cache. Tout ça c'est du 
HTTP/1.1 très standard. Les métadonnées ou requêtes spécifiques pour 
obtenir une liste des versions historiques et leur chemin d'accès 
c'est peut-être beaucoup demander.


(OSM non plus ne garde pas ses tuiles historiques dans son rendu, 
cependant il devrait aussi gérer les dates de mises à jour pour une 
gestion efficace des caches clients, qui lui fait aussi économiser de 
la bande passante et améliore beaucoup l'expérience utilisateur avec 
une plus grande fluidité pour ne pas recharger les mêmes tuiles déjà 
en cache et pas mises à jour côté serveur)


Le 27 juin 2016 à 19:08, Christian Quest > a écrit :


La date du changeset suffit, non ?

Le 27 juin 2016 à 17:53, > a écrit :

Le 27/06/2016 à 10:44, Christian Quest -
cqu...@openstreetmap.fr  a écrit :


La convention est en pièce jointe sur:
http://openstreetmap.fr/bdortho

Manque juste la définition de l'année de référence.
Est-ce l'année de consultation (2016) ou l'année des photos ?
Dans le second cas il faudrait avoir un accès facile à la donnée.
Par exemple un TMS donnant par tuile l'année de la photo.

Jean-Yvon

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr




-- 
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


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Nicolas Dumoulin]

Le Mon, 27 Jun 2016 19:08:44 +0200,
Christian Quest  a écrit :
> La date du changeset suffit, non ?

Oui.

Pour ce qui est de produire ou extraire la date des prises de vue,
comme le dit Jean-Yvon il faudrait des métadonnées supplémentaires que
nous n'avons pas. On va donc se contenter de la date du changeset qui
reste l'info la plus fiable pour l'instant.

-- 
Nicolas Dumoulin


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Philippe Verdy]

Quel changeset? On parle du TMS de la BD Ortho, indépendamment des
changesets qu'on peut produire en s'appuyant dessus sur OSM. Ce qui est
intéressant de connaitre ce sont les dates des clichés (plus même que les
dates de génération des tuiles, qui sont orthrectifiées et sont par endoit
des assemblages de clichés juxtaposés pais pas forcément à la même date).
L'ennui c'est qu'en cas d'assemblage sur une tuile, il est difficile de
tracer la date de chaque cliché. Donc au mieux cela devrait donner la date
de génération de la tuile (ou de la métatuile plus grande dont pourrait
être extraite la tuile demandée).
Au minimum, cette info devrait être dans les entêtes MIME HTTP (ce qui
permet ensuite de gérer les caches en aval en cas de mise à jour sur le
serveur). Et je ne sais pas si le serveur TMS peut gérer dans ses
métadonnées un historique de versions, ou propose un moyen de les
consulter, s'il y a conservation de versions plus anciennes).

Uniquement des requête HTTP "HEAD /chemin de la tuile" sur le serveur
devrait retourner l'info, et la navigation normale devrait faire des "GET
/chemin de la tuile" avec if "If-Updated-Since:" contenant la version dont
dispose un client dans son cache. Tout ça c'est du HTTP/1.1 très standard.
Les métadonnées ou requêtes spécifiques pour obtenir une liste des versions
historiques et leur chemin d'accès c'est peut-être beaucoup demander.

(OSM non plus ne garde pas ses tuiles historiques dans son rendu, cependant
il devrait aussi gérer les dates de mises à jour pour une gestion efficace
des caches clients, qui lui fait aussi économiser de la bande passante et
améliore beaucoup l'expérience utilisateur avec une plus grande fluidité
pour ne pas recharger les mêmes tuiles déjà en cache et pas mises à jour
côté serveur)

Le 27 juin 2016 à 19:08, Christian Quest  a écrit :

> La date du changeset suffit, non ?
>
> Le 27 juin 2016 à 17:53,  a écrit :
>
>> Le 27/06/2016 à 10:44, Christian Quest - cqu...@openstreetmap.fr a
>> écrit :
>>
>> La convention est en pièce jointe sur: 
>> http://openstreetmap.fr/bdortho
>>
>> Manque juste la définition de l'année de référence.
>> Est-ce l'année de consultation (2016) ou l'année des photos ?
>> Dans le second cas il faudrait avoir un accès facile à la donnée.
>> Par exemple un TMS donnant par tuile l'année de la photo.
>>
>> Jean-Yvon
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> 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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

La date du changeset suffit, non ?

Le 27 juin 2016 à 17:53,  a écrit :

> Le 27/06/2016 à 10:44, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> La convention est en pièce jointe sur: 
> http://openstreetmap.fr/bdortho
>
> Manque juste la définition de l'année de référence.
> Est-ce l'année de consultation (2016) ou l'année des photos ?
> Dans le second cas il faudrait avoir un accès facile à la donnée.
> Par exemple un TMS donnant par tuile l'année de la photo.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Philippe Verdy]

Le "referer:" aussi est facile à reprendre, même pour une navigation sur un
site tiers avec un navigateur normal, la requête peut être effectuée en
Javascript avec les champs MIME qu'on veut (et faciles à obtenir juste avec
la console réseau du navigateur). Cependant ça élimite les utilisations les
plus simples avec un framework OpenLayers ou similaire non modifié.

Sans identification du client (inscription de compte, mot de passe, etc.),
ou sans mise à jour régulière des clés sur le serveur web référent (qui
doit avoir alors une connexion avec le fournisseur de carto tiers pour
autoriser pendant un temps limité des sessions pour chaque client connnecté
au serveur référent, le client devant redemander une clé au serveur
référent qui la renouvellera avec le serveur tiers, ou bien le client devra
ouvrir une session SSL résidente en utilisant des clés négociées par
l'intermédiaire du serveur référent, sur laquelle transiteront ensuite les
requêtes de tuiles en HTTPS), il n'est pas tellement possible de sécuriser
cette restriction d'accès.

Au mieux le fournisseur de tuiles peut comptabiliser le nombre, le volume,
la fréquence des requêtes à son serveur avec la même clé, pour compliquer
la vie des sites qui abuseraient de la fonction de fourniture gratuite
d'imagerie sans rien contribuer au projet finançant cette fourniture de
tuiles "gratuites".

Ou restreindre l'usage d'une même clé à une seule IP voire quelques unes
pour ceux qui ont des adresses IP dynamiques qui changent sans arrêt car
ils sont connectés via un proxy tel qu'un accès Internet mobile (les accès
internet mobiles ne procuent pas en général d'adresse IPv4 unique pour
chaque client, le mobile est connecté avec une adresse IPv4 "locale" de
type 192.168.* ou 10.* ou 172.16.* et ne communique directement qu'avec le
proxy du fournisseur dans le même espace d'adresse et les sessions ont une
durée de vie limitée, le client ne sait pas sur quelle adresse IPv4
publique passe sa navigation Internet car elle peut changer à tout moment
entre deux requêtes, le fournisseur mobile en gérant un certain nombre en
parallèle, partagées en NAT entre ses abonnés. IPv6 devrait permettre
d'éviter ces proxy/NAT, qui en plus sont très lents mais fonctionnent
encore à vitesse raisonnable sur les réseaux 2G/3G où cette lenteur ne se
fait pas sentir; cependant IPv6 n'est toujours pas déployé en France vers
les abonnés internet mobile)...



Le 27 juin 2016 à 17:31, Christian Quest  a écrit :

> Malheureusement non, le token étant public n'importe qui peut l'utiliser
> hors iD.
>
> Le 27 juin 2016 à 16:38, althio  a écrit :
>
>>
>>
>> 2016-06-27 12:19 GMT+02:00 althio :
>>
>>>
>>> ​
>>> 2016-06-27 10:44 GMT+02:00 Christian Quest :
>>> > L'accès reste limité à JOSM, il manque le referer dans les accès
>>> provenant
>>> > d'iD permettant d'éviter un usage autre que dans un éditeur. Si
>>> quelqu'un a
>>> > le courage de regarder le code d'iD pour voir si il serait possible de
>>> > l'avoir, et de proposer une pull-request, ça serait super chouette ;)
>>>
>>> Question ouverte sur :
>>> https://github.com/openstreetmap/iD/issues/3197
>>>
>>
>>
>> Première réponse : access_token
>>
>> Est-ce que c'est applicable à notre configuration ?
>>
>>
>> From: Bryan Housel
>> Subject: Re: [openstreetmap/iD] referer string for imagery request (#3197)
>>
>> The way we handle this in the Mapbox Imagery layer is to append an
>> access_token parameter to the request: see editor-layer-index
>> sources/world/MapBoxSatellite.json
>> 
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> 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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[osm . sanspourriel]

Le 27/06/2016 à 10:44, Christian Quest - cqu...@openstreetmap.fr a écrit :


La convention est en pièce jointe sur: http://openstreetmap.fr/bdortho

Manque juste la définition de l'année de référence.
Est-ce l'année de consultation (2016) ou l'année des photos ?
Dans le second cas il faudrait avoir un accès facile à la donnée.
Par exemple un TMS donnant par tuile l'année de la photo.

Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

Malheureusement non, le token étant public n'importe qui peut l'utiliser
hors iD.

Le 27 juin 2016 à 16:38, althio  a écrit :

>
>
> 2016-06-27 12:19 GMT+02:00 althio :
>
>>
>> ​
>> 2016-06-27 10:44 GMT+02:00 Christian Quest :
>> > L'accès reste limité à JOSM, il manque le referer dans les accès
>> provenant
>> > d'iD permettant d'éviter un usage autre que dans un éditeur. Si
>> quelqu'un a
>> > le courage de regarder le code d'iD pour voir si il serait possible de
>> > l'avoir, et de proposer une pull-request, ça serait super chouette ;)
>>
>> Question ouverte sur :
>> https://github.com/openstreetmap/iD/issues/3197
>>
>
>
> Première réponse : access_token
>
> Est-ce que c'est applicable à notre configuration ?
>
>
> From: Bryan Housel
> Subject: Re: [openstreetmap/iD] referer string for imagery request (#3197)
>
> The way we handle this in the Mapbox Imagery layer is to append an
> access_token parameter to the request: see editor-layer-index
> sources/world/MapBoxSatellite.json
> 
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[althio]

2016-06-27 12:19 GMT+02:00 althio :

>
> ​
> 2016-06-27 10:44 GMT+02:00 Christian Quest :
> > L'accès reste limité à JOSM, il manque le referer dans les accès
> provenant
> > d'iD permettant d'éviter un usage autre que dans un éditeur. Si
> quelqu'un a
> > le courage de regarder le code d'iD pour voir si il serait possible de
> > l'avoir, et de proposer une pull-request, ça serait super chouette ;)
>
> Question ouverte sur :
> https://github.com/openstreetmap/iD/issues/3197
>


Première réponse : access_token

Est-ce que c'est applicable à notre configuration ?


From: Bryan Housel
Subject: Re: [openstreetmap/iD] referer string for imagery request (#3197)

The way we handle this in the Mapbox Imagery layer is to append an
access_token parameter to the request: see editor-layer-index
sources/world/MapBoxSatellite.json

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[althio]

​
2016-06-27 10:44 GMT+02:00 Christian Quest :
> L'accès reste limité à JOSM, il manque le referer dans les accès provenant
> d'iD permettant d'éviter un usage autre que dans un éditeur. Si quelqu'un
a
> le courage de regarder le code d'iD pour voir si il serait possible de
> l'avoir, et de proposer une pull-request, ça serait super chouette ;)

Question ouverte sur :
https://github.com/openstreetmap/iD/issues/3197
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Nicolas Dumoulin]

Le Mon, 27 Jun 2016 10:44:36 +0200,
Christian Quest  a écrit :

> Tout semble ok, je n'ai pas eu de remontée de problème particulier.
> 
> L'accès reste limité à JOSM, il manque le referer dans les accès
> provenant d'iD permettant d'éviter un usage autre que dans un
> éditeur. Si quelqu'un a le courage de regarder le code d'iD pour voir
> si il serait possible de l'avoir, et de proposer une pull-request, ça
> serait super chouette ;)
> 
> La convention est en pièce jointe sur: http://openstreetmap.fr/bdortho

Ok, merci à toi et Romain :-)
J'ai ajouté dans les listes citées sur le wiki.

-- 
Nicolas Dumoulin


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

Tout semble ok, je n'ai pas eu de remontée de problème particulier.

L'accès reste limité à JOSM, il manque le referer dans les accès provenant
d'iD permettant d'éviter un usage autre que dans un éditeur. Si quelqu'un a
le courage de regarder le code d'iD pour voir si il serait possible de
l'avoir, et de proposer une pull-request, ça serait super chouette ;)

La convention est en pièce jointe sur: http://openstreetmap.fr/bdortho



Le 27 juin 2016 à 10:04, Nicolas Dumoulin  a écrit :

> Salut,
>
> Est-ce que le test est validé ?
>
> Si oui, on va pouvoir documenter au moins dans :
>  - http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France
>  - http://wiki.openstreetmap.org/wiki/Vertical_Aerial_Photographs#France
>  - https://josm.openstreetmap.de/wiki/Maps
>
> Est-ce qu'on publie une copie de la convention ?
>
> Merci
>
> Le Fri, 27 May 2016 18:09:44 +0200,
> Christian Quest  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
>
>
>
> --
> Nicolas Dumoulin
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Romain MEHUT]

Bonjour,

Ici https://josm.openstreetmap.de/wiki/Maps/France c'est déjà documenté.

Romain

Le 27 juin 2016 à 10:04, Nicolas Dumoulin  a écrit :

> Salut,
>
> Est-ce que le test est validé ?
>
> Si oui, on va pouvoir documenter au moins dans :
>  - http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France
>  - http://wiki.openstreetmap.org/wiki/Vertical_Aerial_Photographs#France
>  - https://josm.openstreetmap.de/wiki/Maps
>
> Est-ce qu'on publie une copie de la convention ?
>
> Merci
>
> Le Fri, 27 May 2016 18:09:44 +0200,
> Christian Quest  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
>
>
>
> --
> Nicolas Dumoulin
>
>
> ___
> 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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Nicolas Dumoulin]

Salut,

Est-ce que le test est validé ?

Si oui, on va pouvoir documenter au moins dans :
 - http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France
 - http://wiki.openstreetmap.org/wiki/Vertical_Aerial_Photographs#France
 - https://josm.openstreetmap.de/wiki/Maps

Est-ce qu'on publie une copie de la convention ?

Merci

Le Fri, 27 May 2016 18:09:44 +0200,
Christian Quest  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



-- 
Nicolas Dumoulin


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Landry Breuil]

2016-06-06 15:34 GMT+02:00 FR :
> Le 06/06/2016 10:50, g...@laposte.net a écrit :
>>
>> Autre remarque, je trouve regrettable de noter en source [année de
>> reference = 2016] après la mention "IGN France" alors que les photos
>> datent parfois de plusieurs années. (mais je ne vois pas comment
>> retrouver  l’année vraie des photos)
>>
> Bonjour
> Osmose n'aime pas "source=BDOrtho IGN 2016"
> message d'erreur "tag source illégal ou incomplet"

Oui, j'ai vu ca sur certains objets taggués avec
'source=Orthophotographie CRAIG/IGN 2013'.. peut-etre des restes du
passé ou 'source=.*IGN.*' était considéré illégal dans les analyses
osmose ?

Landry

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[FR]

Le 06/06/2016 10:50, g...@laposte.net a écrit :

Autre remarque, je trouve regrettable de noter en source [année de
reference = 2016] après la mention "IGN France" alors que les photos
datent parfois de plusieurs années. (mais je ne vois pas comment
retrouver  l’année vraie des photos)


Bonjour
Osmose n'aime pas "source=BDOrtho IGN 2016"
message d'erreur "tag source illégal ou incomplet"
FR


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Eric Sibert]

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


C'est une très bonne nouvelle alors qu'à une époque, on parlait de  
refaire nous même l'orthorectification...



Merci de remonter les problèmes que vous rencontrerez


Tout va bien. J'ai l'impression qu'en montagne, le calage est meilleur  
qu'avec Bing.


Eric



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

Le 06/06/2016 à 11:41, Romain MEHUT a écrit :
Le 6 juin 2016 à 10:50, > a 
écrit :


Juste pour info :

Vous aurez remarqué que pour les zooms 6 à 12 l'ensemble de la
planète est mise a disposition !
Pour les zones désertiques ou reculée cela peut être utile.

Autre remarque, je trouve regrettable de noter en source [année de
reference = 2016] après la mention "IGN France" alors que les
photos datent parfois de plusieurs années.


+ 1 pour juste écrire "BDOrtho IGN"


Le millésime est en effet explicitement conservé dans les métadonnées du 
changeset ;)



(mais je ne vois pas comment retrouver  l’année vraie des photos)


Les années sont indiquées ici : 
https://gist.github.com/cquest/e0682246cce5dc562f8f1b3135466b4b


Attention, sur les derniers niveaux de zooms (19) on a parfois une 
version plus ancienne à certains endroits.
Dans ce cas, dans JOSM, je désactive "zoom auto" avec un clic droit sur 
le fond.


--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Romain MEHUT]

Le 6 juin 2016 à 10:50,  a écrit :

> Juste pour info :
>
> Vous aurez remarqué que pour les zooms 6 à 12 l'ensemble de la planète est
> mise a disposition !
> Pour les zones désertiques ou reculée cela peut être utile.
>
> Autre remarque, je trouve regrettable de noter en source [année de
> reference = 2016] après la mention "IGN France" alors que les photos datent
> parfois de plusieurs années.
>

+ 1 pour juste écrire "BDOrtho IGN"


> (mais je ne vois pas comment retrouver  l’année vraie des photos)
>

Les années sont indiquées ici :
https://gist.github.com/cquest/e0682246cce5dc562f8f1b3135466b4b

Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[gnrc]

Juste pour info : 

Vous aurez remarqué que pour les zooms 6 à 12 l'ensemble de la planète est mise 
a disposition ! 
Pour les zones désertiques ou reculée cela peut être utile. 

Autre remarque, je trouve regrettable de noter en source [année de reference = 
2016] après la mention "IGN France" alors que les photos datent parfois de 
plusieurs années. (mais je ne vois pas comment retrouver l’année vraie des 
photos) 

- Mail original -

De: "Christian Quest" <cqu...@openstreetmap.fr> 
À: "Discussions sur OSM en français" <talk-fr@openstreetmap.org> 
Envoyé: Vendredi 27 Mai 2016 18:09:44 
Objet:  [OSM-talk-fr] Test accès BD Ortho depuis JOSM... 

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

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Landry Breuil]

2016-05-29 10:44 GMT+02:00 Nicolas Dumoulin :
> Le Fri, 27 May 2016 18:09:44 +0200,
> Christian Quest  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 !).
>
> Merci Christian pour la réactivité !
>
> Dans le 63, l'imagerie du CRAIG
> reste meilleure : meilleure résolution et prise à midi.
> Y a pas photo :-)

J'allais dire.. "mais c'est pas possible, c'est la même..." mais en
fait j'ai l'impression que l'IGN a uniquement intégré notre ortho
départementale à 25cm, et fait l'impasse sur les orthos à 10cm sur les
agglomérations, ce qui pourrait expliquer la différence que tu vois..
vu que ca a donné lieu à des vols différents (sur la même période
d'été 2013).



Landry

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Florian LAINEZ]

J'ai également le cas d'un endroit où lorsque l'on zoome assez, il vieille
imagerie prend le relai.
sur cet exemple (https://www.openstreetmap.org/node/3203175369) :
-en zoom large on voit bien les nouveaux bâtiments dont la construction
s'est terminée il y a un an
-en zoom serré, la photo date d'avant le début des travaux il y a 3 ans

Est-ce que c'est tout le temps le cas ?

Le 29 mai 2016 à 10:57, Nicolas Dumoulin  a écrit :

> Le Sun, 29 May 2016 10:44:34 +0200,
> Nicolas Dumoulin  a écrit :
> > Dans le 63, l'imagerie du CRAIG
> > reste meilleure : meilleure résolution et prise à midi.
> > Y a pas photo :-)
>
> Sauf dans certaines forêt ou la saison est plus avantageuse pour
> l'IGN :-) Je vois des chemins que je ne voyais pas.
> Donc, il faut (au moins) les deux !
>
>
> --
> Nicolas Dumoulin
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Nicolas Dumoulin]

Le Sun, 29 May 2016 10:44:34 +0200,
Nicolas Dumoulin  a écrit :
> Dans le 63, l'imagerie du CRAIG
> reste meilleure : meilleure résolution et prise à midi.
> Y a pas photo :-)

Sauf dans certaines forêt ou la saison est plus avantageuse pour
l'IGN :-) Je vois des chemins que je ne voyais pas.
Donc, il faut (au moins) les deux !


-- 
Nicolas Dumoulin


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Nicolas Dumoulin]

Le Fri, 27 May 2016 18:09:44 +0200,
Christian Quest  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 !).

Merci Christian pour la réactivité !

Dans le 63, l'imagerie du CRAIG
reste meilleure : meilleure résolution et prise à midi.
Y a pas photo :-)

-- 
Nicolas Dumoulin


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Nicolas Dumoulin]

Le Fri, 27 May 2016 23:10:49 +0200,
DH  a écrit :
> Prenons date et regardons, dans une semaine, un mois, un an, les
> objets sourcés BDOrtho IGN 2016 (c'est mieux de sourcer les objets ©).
> Je serai curieux du résultat.

Et les changesets ! Moi, je n'ajoute pas la source ortho sur tous les
objets ;-)

-- 
Nicolas Dumoulin


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Philippe Verdy]

Note: cette idée de "métaserveur" de tuiles je suis en train de
l'exprimenter localement dans un greffon Java pour JOSM. Le "serveur" est
en fait sur mon PC, il gère lui-même ses caches et sa file d'attente, mais
dans JOSM il me suffit de pointer le serveur TMS sur mon petit service
local.

Au passage j'ai viré complètement le pseudo-"cache" de tuiles intégré à
JOSM (défectueux car il ne se purge pas correctement et ne gère pas les
expirations, rapidement il sature mon stockage local avec des tuiles
obsolètes depuis longtemps, et j'étais sans arrêt en train de le purger, ce
qui demande quelques minutes de travail quand il y a des milliers de
fichiers de tuiles et de fichiers tag à effacer): à la place JOSM utilise
un cache externe standard et conforme (Squid), il me suffit juste de
configurer JOSM pour utiliser un proxy de mon choix (mon Squid), qui en
plus est beaucoup plus performant et gère beaucoup mieux le stockage.

Dans JOSM en revanche il n'y a plus qu'un petit cache web en mémoire (max
128Mo ça me suffit largement) par lequel transite tout le traffic web HTTP
ou HTTPS (les tuiles, les JSON, les requêtes de données XML à la base, les
mises à jours de plugins...) car j'ai reconfiguré le cache web par défaut
de la VM Java (pour qu'il ne pollue pas non plus l'espace dans les données
utilisateur Java): toute requête HTTP ou HTTPS qui retourne plus de 1 Mo
n'est même pas gardé dans ce cache mémoire, car c'est mon proxy local
(Squid) qui prend ça en charge (au passage il me sert aussi pour autre
chose que JOSM, notamment les navigateurs que j'ai configurés aussi pour
utiliser ce proxy web, partagé aussi sur plusieurs PC). Les I/O disque
local ont largement diminué, JOSM est beaucoup plus réactif et utilise
moins de mémoire, son garbage collector est moins sollicité aussi.



Prochaine étape: intégrer ce squid en mode "transparent" (sans aucune
configuration nécessaire sur les PC ou mobiles, autre que de désactiver ou
réduire les caches locaux) sur mon routeur Internet auquel j'ai adjoint un
stockage USB externe (j'ai déjà un routeur transparent Ethernet/Ethernet)
entre ma box et mon réseau local Ethernet (ou Wifi), ce routeur contient
déjà un antivirus et un outil d'administration de parefeu plus efficace que
celui de la box de mon opérateur, ainsi qu'un serveur de stockage et de
médias.

Ce routeur est sous Linux (avec un shell BusyBox, pas de X11), c'est en
fait un mini PC (à processeur compatible x86 et non ARM) mais avec plus de
mémoire que ce qu'on trouve habituellement et plus de connectivité de
stockage, et ça boote bien plus vite qu'un PC (ou que la box du FAI qui met
plusieurs minutes et qui perturbe le fonctionnement du réseau local !) et
consomme même moins d'énergie que la box du FAI ! Le réseau local est
constamment disponible même si la box du FAI ne l'est pas toujours (on ne
sait jamais quand le FAI décide de la rebooter à distance).

On pourrait faire ce type de routeur sur une Raspberry, voire n'importe
quel vieux PC recyclé (mais moins efficace car boot plus lent à moins de
changer de BIOS et peu économe en énergie et souvent encombrant et pas
toujours avec la connectivité qu'on voudrait pour y mettre un stockage type
NAS).

D'ailleurs je ne comprends pas pourquoi on ne trouve pas ça préconfiguré
sur le marché : on trouve des serveurs de médias, des NAS, parfois un
parefeu voire un antivirus en général assez mauvais, mais rien intégrant
des caches efficicaces (y compris pour les mobiles connectés en Wifi).
Aucune des "box" des FAI ne gère ça.

En plus ces box imposent un DNS mal fichu et souvent intrusif, (pour le DNS
je suis passé chez OpenDNS pour ne pas utiliser les DNS du FAI, d'autant
plus que le client-proxy DNS intégré aux box sature trop vite et répond
alors n'importe quoi !)
Et le serveur UPnP (pour la configuration NAT+PAT) est tout aussi mal fichu
dans toutes les "box"

Au passage mon routeur gère aussi la compatibilité IPv6 (pas besoin de
terminaison locale de tunnel sur les PC ou mobiles connectés, IPv6 est
fourni nativement, le(s) tunnel(s) sont établis par mon routeur, la box du
FAI ne s'occupe de rien et ne voit qu'un "PC anonyme" connecté en IPv4 sur
un port Ethernet mais qui n'utilise jamais le DNS du FAI ni l'UPnP de la
box, qui elle-même fonctionne beaucoup mieux et plante moins souvent un
fois qu'on y a désactivé tous les services non nécessaires!), en attendant
que le FAI propose une réelle connexion IPv6 native, sans tunnel dont la
terminaison est sur un serveur surchargé et mal administré (comme le fait
encore Orange qui n'a pas avancé d'un pouce depuis une douzaine d'années...
SFR en a fait encore moins, Bouygues ne propose rien non plus, Free propose
un IPv6 qui fonctionne mais avec de forts bridages).

Microsoft propose pour Windows son tunnel-broker pour IPv6-sur-IPv4 mais il
est lui aussi très lent et limité en protocoles et services, il le supporte
en fait uniquement pour connecter sa communauté de joueurs XBox, chaque jeu
utilisant ensuite son propre 

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[DH]

Le 27/05/2016 18:09, Christian Quest 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 ;)




Trop cool
Merci Christian.
Prenons date et regardons, dans une semaine, un mois, un an, les objets 
sourcés BDOrtho IGN 2016 (c'est mieux de sourcer les objets ©).

Je serai curieux du résultat.

Denis


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Philippe Verdy]

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  a écrit :

> Voilà, j'ai mis en place un proxy 

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

J'ai bien écrit "depuis JOSM" ? Essaye avec JOSM... et qu'avec lui ;)


Le 27/05/2016 à 19:06, Guillaume AMAT a écrit :


Super !

Par contre je n'ai que des 403... Je suis le seul ?

Ex : http://proxy-ign.openstreetmap.fr/bdortho/14/8165/5903.jpg

Guillaume



--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[osm . sanspourriel]

Le seul peut-être pas mais chez moi ça marche.

Pas de différence flagrante de qualité avec d'autres orthophotos de 
bonne qualité. Sauf à l'extérieur de la France ;-).


Jean-Yvon


Le 2016-05-27 à 19:06, Guillaume AMAT - guilla...@amat.io a écrit :


Super !

Par contre je n'ai que des 403... Je suis le seul ?

Ex : http://proxy-ign.openstreetmap.fr/bdortho/14/8165/5903.jpg

Guillaume


Le 27/05/2016 à 18:09, Christian Quest 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


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Florian LAINEZ]

Oh yeah ! https://twitter.com/overflorian/status/736242749360508928

Le 27 mai 2016 à 18:09, Christian Quest  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
>
>


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Guillaume AMAT]

Super !

Par contre je n'ai que des 403... Je suis le seul ?

Ex : http://proxy-ign.openstreetmap.fr/bdortho/14/8165/5903.jpg

Guillaume


Le 27/05/2016 à 18:09, Christian Quest 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

[OSM-talk-fr] Test accès BD Ortho depuis JOSM...

[Christian Quest]

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