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

2016-05-27 Par sujet 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...

2016-05-27 Par sujet 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...

2016-05-27 Par sujet 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] [OverpassT] Filter résultats?

2016-05-27 Par sujet Shohreh 
Antoine Riche wrote
> Le doc ne parle pas de sortie en GPX : 
> http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29

OverpassTurbo permet d'exporter en GPX et KML.


Antoine Riche wrote
> Si tu peux faire avec du CSV remplace le [out:xml] ou [out:json] en haut
> de la requête par [out:csv(name,::lat,::lon)]. Et pour convertir les
> magasins représentés par un polygone (bâtiment) met un out center; en bas.

Le problème, c'est que j'ai ensuite besoin d'importer les données dans mon
téléphone, en GPX ou KML.

Merci.



--
View this message in context: 
http://gis.19327.n5.nabble.com/OverpassT-Filter-resultats-tp5874255p5874274.html
Sent from the France mailing list archive at Nabble.com.

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

2016-05-27 Par sujet 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...

2016-05-27 Par sujet 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] [OverpassT] Filter résultats?

2016-05-27 Par sujet Antoine Riche 

Bonsoir.

Le doc ne parle pas de sortie en GPX : 
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29


Si tu peux faire avec du CSV remplace le [out:xml] ou [out:json] en haut 
de la requête par [out:csv(name,::lat,::lon)]
Et pour convertir les magasins représentés par un polygone (bâtiment) 
met un out center; en bas.


Exemple : http://overpass-turbo.eu/s/gtX

Antoine.

Le 27/05/2016 à 16:30, Shohreh a écrit :

Bonjour

Je voulais récupérer la liste des boutiques vélos dans une ville. Par
défaut, OT récupére /tous les champs disponibles/ alors que j'ai juste
besoin de la /location géographique et du nom/.

Exemple:

Cycland-1.5415835,46.228232node/2093672235152Cyclandyesbicyclesurvey

Est-il possible de modifier la partie output pour ne récupérer dans le
fichier GPX que les deux champs dont j'ai besoin?

Merci.



--
View this message in context: 
http://gis.19327.n5.nabble.com/OverpassT-Filter-resultats-tp5874255.html
Sent from the France mailing list archive at Nabble.com.

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

2016-05-27 Par sujet 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...

2016-05-27 Par sujet 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...

2016-05-27 Par sujet 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

Re: [OSM-talk-fr] umap + framacalc + adresses.data.gouv.fr

2016-05-27 Par sujet Jérôme Seigneuret 
Merci pour cette info



2016-05-27 13:18 GMT+02:00 Nicolas Dumoulin :

> À toutes fins utiles, le script php
>
> --
> 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

[OSM-talk-fr] [OverpassT] Filter résultats?

2016-05-27 Par sujet Shohreh 
Bonjour

Je voulais récupérer la liste des boutiques vélos dans une ville. Par
défaut, OT récupére /tous les champs disponibles/ alors que j'ai juste
besoin de la /location géographique et du nom/.

Exemple:

Cycland-1.5415835,46.228232node/2093672235152Cyclandyesbicyclesurvey

Est-il possible de modifier la partie output pour ne récupérer dans le
fichier GPX que les deux champs dont j'ai besoin?

Merci.



--
View this message in context: 
http://gis.19327.n5.nabble.com/OverpassT-Filter-resultats-tp5874255.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] umap + framacalc + adresses.data.gouv.fr

2016-05-27 Par sujet Nicolas Dumoulin 
Salut,

Au SotMFR a été évoqué l'usage de tableurs google pour alimenter une
carte umap. Mon sang n'a fait qu'un tour !
J'ai donc essayé avec framacalc, ça marche bien (il suffit
d'ajouter .csv à l'URL du calc). Et puis, si on donnait des adresses à
prémacher au géocodeur avant de les donner à manger à umap ?
Et bingo :
http://umap.openstreetmap.fr/fr/map/jardins-portes-ouvertes_87671

J'ai fait un petit script php de test qui fait le boulot. Si ça vous
inspire …
bon, il reste des jardins à rentrer dans le tableur d'ici demain ;-)

Petit bémol, une seul erreur dans le calc, et aucun point n'est
chargé ! Genre : un espace dans le code postal !
N.B. : j'ai pas essayé avec la dernière version de umap.
-- 
Nicolas Dumoulin


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

Re: [OSM-talk-fr] umap + framacalc + adresses.data.gouv.fr

2016-05-27 Par sujet Nicolas Dumoulin 
À toutes fins utiles, le script php

-- 
Nicolas Dumoulin

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

[OSM-talk-fr] Maproulette et JOSM

2016-05-27 Par sujet Eric 
Bonjour,

En essayant le nouveau Maproulette, j'ai un soucis avec JOSM : quand je
demande à éditer la zone, je me retrouve en pleine mer et non dans la zone
souhaitée. Ca n'a pas l'air d’être lié à l’état "beta" de cette version de
Maproulette, la version standard fait pareil.
Est-ce une projection à régler dans JOSM ou un paramétrage quelconque ? Je
ne trouve pas d'infos dans les wikis et je suis un peu sec ...

Exemple : http://maproulette.org:8080/map/6/944

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