[OSM-talk-fr] Repère géodésique et limite communale

2016-07-27 Par sujet Balaïtous
Bonjour,

J'ai une erreur "Survey point out of boundary" :
http://osmose.openstreetmap.fr/en/error/7331972186

Ce point (http://www.openstreetmap.org/node/669987012) est un sommet,
j'ai ajouté les tags correspondants, et d'après le cadastre, il sert de
limite communale.
Est-ce que je peux l'intégrer à la limite de commune, ou faut-il
dupliquer le point ?

Balaïtous

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


Re: [OSM-talk-fr] Annonce de sortie : MapContrib 0.10.0

2016-07-27 Par sujet Philippe Verdy
Oui les ressources coutent cher, c'est bien pour ça qu'il faudrait imaginer
un système de collaboration pour partager les couts et permettre des
maintenances sans interrompre le service global. Il manque à Overpass  une
instance gérée par la Fondation OSM, et un système d'équilibrage de charge
(permettant de répartir les requêtes). La Fondation Wikimedia pourrait
aussi nous aider (il y a de nombreux projets wikiemdia qui pourraient
bénéficier de données vectorielles dynamiques, y compris Wikipédia dans sa
version francophone qui en fait usage, mais pas la version anglophone
actuellement).

L'ennui c'est que toutes les instances veulent fournir une base "monde". Il
sertait intéreessant d'imaginer un index "quad tile" sur 4 serveurs
principaux, dont un est "maître" (et reçoit les mises à jour en priorité
les 3 autres ayant des priorités moindres). Le partage de ressources
pourrait aussi concerner la génération des "areas" (très couteuse sur le
monde entier), et des listes de requêtes à réaliser feature par feature
avec un système de prise en main et relachement et fourniture des résultats
obtenus aux autres serveurs via un cache.

On a des caches et un partage efficace actuelement uniquement pour les
tuiles bitmaps, rien pour les couches vectorielles capables de répondre à
bien des requêtes.
Mais comment synchroniser efficacement les serveurs autrement qu'avec les
minute diffs de la base OSM mondiale?
Peut-on avoir des serveurs déidiés à certaines zones (qui auraient des
données mises à jour plus régulièrement mais consultées par un cache par un
autre serveur. On aurait quand même une réponse même si les données en
cache sont anciennes mais chaque serveur soumettrait des demandes de
rafraichissemnt aux autres en relayant les requêtes pour remettre à jour
son propre cache. Le tout fonctionnant globalement "à la demande" et non
pas purement géographiquement.

Je ne suis pas sûr que la méthode de mises à jour via les minute diffs de
la base monde permet de gérer l'équilibrage de charges et le partage de
ressources pusique tout le monde doit faire la même chose dans sa base. Ca
demanderait alors un système de mises à jour différents, par souscription
ou diffusion (avec acquittement si on est toujours intéressé).
Il serait essentiel pour que cela fonctionne que tout le monde respecte les
prescriptions de gestion de proxy/cache du protocole HTTP/1.1 standard
(notamment les dates de validitité).
Il serait essentiel aussi de pouvoir localiser une liste de serveurs
pouvant répondre à la recherche de certains "features"/"tags", pour que
tout le monde n'ait pas à s'occuper de la totalité des données, mais aussi
d'assurer quer toutes les données seront disponibles au moins quelque part
(avec au moins un miroir, plus si les statsitiques d'usage montrent un
intérêt particilier à certaines données).

Mais tout ça demande du travail pour inventer un protocole. Et des
discussions pour connaitre les moyens partageables et responsabilités de
chacun. Ca mériterait une vraie discussion à SOTM Monde dans un atelier
dédié. Il me parait essentiel de renforcer l'infrastructure et faciliter
les collaborations et partager les moyens. Le petit CDN des tuiles bitmaps
ne suffit plus du tout. Il y a de très bons développeurs de protocole pour
MediaWiki qui pourraient aider à ce projet et ils ont des outils pour
mesurer les besoins, évaluer les possibilités, faire des tests A/B, lancer
des expérimentations, améliorer les protocoles, suivre les éléments à
rendre obsolète et remplacer par d'autres plus performants. OSM n'a pas
tout ça (et maintenant a moins de moyens depuis le départ de Mapquest qui
développe son propre système et semble même prêt à utiliser des données
propriétaires par des licences d'utilisation plus restrictives ou plus
intrusives pour les visiteurs des cartes hébergées par lui)

Et avec le temps ce manque de collaboration devient de plus en plujs
critique car les données sont de plus en plus volumineuses et lourdes à
gérer. Les couts ne cessent donc de monter pour tout le monde au lieu de se
maintenir à un niveau permettant plus de participants pour la plateforme
technique. Il est possible qu'à l'avenir la fondation OSM elle-même ne
parvienne plus à gérer ces couts et que les appels de dons ne suffiront pas
plus que les offres généreuses de partentaires tiers (pouvant fournir des
la bande passante, des serveurs, de la capacité de calcul, de la
connectivité et un temps de réponse acceptable dans le monde entier, et un
support de veille pour assurer la maintenance du service avec un taux de
panne faible).

Mais pour Overpass, et même l'API OSM de base, on sent que tout cela tient
à un fil.  Et c'est très gênant pour les contributeurs de données dans les
zones HOT où des imports massifs de données brutes sont demandé avec des
pics de charge qui explosent par endroit, et où de très nombreuses
corrections et vérifications sont nécessaires ensuite. La capacité limitée
des serveurs ne permet pas de rendre les résultat attendus 

[OSM-talk-fr] Fwd: Problème limite communale ?

2016-07-27 Par sujet Pierre-Yves Berrard
Problème résolu.
La confusion vient du fait que les libellés de communes ne sont pas du bon
côté des limites sur Mapnik.
(contrairement au rendu FR)

Bonne soirée.

-- Message transféré --
De : Pierre-Yves Berrard 
Date : 27 juillet 2016 à 23:00
Objet : Problème limite communale ?
À : OSM talk-fr 


Bonjour,

Je sèche sur cette note : http://www.openstreetmap.org/note/645751

D'après la planche cadastrale, les données osm semblent correctes.
Par contre, un coup d'oeil sur la plaque de rue dans g. street view
confirme les dires de la note.

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


[OSM-talk-fr] Osmose erreur "ref=* or possibly missing highway in the area" et route 500

2016-07-27 Par sujet Balaïtous
Bonjour,

Je voulais m'attaquer un peu à ces erreurs, mais que signifie
exactement le message ?

D'après ce que j'ai pu comprendre c'est soit qu'il manque une route,
soit quelle est présente mais sans référence.

A partir de quelle base de donnée ce rapport d'erreur est-il établi ?

Par ailleurs, avec quelles données est tracée la couche route500 de :
http://tile.openstreetmap.fr/?zoom=16&lat=48.93747&lon=4.87882&layers=0
000B000FFFTF

Après téléchargement des données ROUTE500 2016, la section de la route
au sud du Pla de l'Izard (le parking juste au nord du lac de Soulcem),
n'est pas référencée dans le réseau départemental, or sur le lien
précédent il y a des références D8 au niveau du barrage.
Idem avec les données route 500 2015.

Donc d'où viens cette référence D8 présente sur la couche route 500 de
tile.openstreetmap.fr (il y a d'autres exemples similaires)

Sur le terrain, l'entretient au delà de parking du Pla de l'Izard
s'apparente beaucoup plus à celui d'un chemin communal.

Balaïtous


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


[OSM-talk-fr] Problème limite communale ?

2016-07-27 Par sujet Pierre-Yves Berrard
Bonjour,

Je sèche sur cette note : http://www.openstreetmap.org/note/645751

D'après la planche cadastrale, les données osm semblent correctes.
Par contre, un coup d'oeil sur la plaque de rue dans g. street view
confirme les dires de la note.

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


Re: [OSM-talk-fr] Annonce de sortie : MapContrib 0.10.0

2016-07-27 Par sujet Guillaume AMAT

Bonsoir François,

Déjà merci pour votre retour positif, ça fait plaisir :)
Et d'ailleurs, le tutoiement ne me dérange pas du tout sur cette liste 
de diffusion.


Malgré la « fragilité » (relative) d'OverPass, je trouve étonnant que 
vos requêtes ne fonctionnent pas la plupart du temps. Passent-elles sur 
OverPass Turbo ? Combien de temps mettent-elles ?


Un première version du cache a été développée mais le résultat est quand 
même assez bancale... La génération se heurte elle aussi aux limites 
d'OverPass :/
C'est pour ça que je ne l'ai pas encore rendu disponible sur les 
instances officielles.


L'idée d'utiliser une autre instance d'OverPass a été évoquée mais où ? 
Je crois savoir que ça demande pas mal de ressources et les ressources 
coûtent cher.


Bonne soirée,
Guillaume


Le 26/07/2016 à 10:58, François Lacombe a écrit :

Bonjour Guillaume,

Merci pour le travail que vous faites, l'outil s'étoffe de plus en plus :)

Relativement à ce point sur le rafraichissement, en chargeant les 
données en live, je ne peux pas utiliser mapcontrib.
Bien souvent mes requêtes n'ont pas de réponse, quelque soit le moment 
de la journée ou alors il faut attendre plusieurs minutes.


Cette idée de cache avec des chargements uniques au moment le plus 
opportun serait un énorme plus


Ou alors choisir une instance d'overpass qui est moins sollicitée 
parce qu'il est vrai qu'il faut bien pouvoir tester ces requêtes à un 
moment donné avant de les "figer" dans le thème.

On a pas la main là-dessus n'est-ce pas ?

Bonne continuation

François

Le 20 juillet 2016 à 11:40, Guillaume AMAT > a écrit :


Pour l'instant il n'y a pas de rafraichissement. Les couches
OverPass sont chargées à l'arrivée sur un thème et quand on se
déplace.



Le 20/07/2016 11:33, Francescu GAROBY a écrit :

Tout a l'air de fonctionner, maintenant...

Quelle est la fréquence de rafraîchissement, au fait ?

Francescu

Le 20 juillet 2016 à 11:24, Guillaume AMAT mailto:guilla...@amat.io>> a
écrit :

C'est bon maintenant !
Pfff, le faux départ, c'est con... ;)

Désolé pour le temps perdu,
Guillaume

Le 20/07/2016 10:57, Guillaume AMAT a écrit :
Ah si vu !
Un souci au login pour certaines personnes. Je corrige vite.

Le 20/07/2016 10:47, Guillaume AMAT a écrit :
Étrange que vous ayez tous cette erreur, tout va bien de mon
côté.
Dans le doute j'ai redémarré le proxy qui est devant.
Ça va mieux pour vous ?

Le 20/07/2016 10:15, Philippe Verdy a écrit :
Problème: http://www.mapcontrib.xyz [1] [6] fait une
erreur 502
BAD
GATEWAY pour l'instant (erreur temporaire de connexion de ton
proxy?).

Seule http://www.cartes.xyz [2] [7] fonctionne pour
l'instant...


Le 20 juillet 2016 à 08:47, Guillaume AMAT
mailto:guilla...@amat.io>> a
écrit :

Bonjour à tous,

Aujourd'hui sort la version 0.10.0 de MapContrib ! :)

Pour rappel, MapContrib est une application web de
contribution
thématique à OpenStreetMap. Elle se veut simple, universelle
(fonctionne sur tous les supports) et mobile (allez la
tester dans
la rue !).

MapContrib a été présentée au SOTM FR 2016 [1] et le sera
aussi
au SOTM de Bruxelles en septembre [2].

Du point de vue utilisateur, cette version apporte entres
autres :

* À l'ajout d'un POI, le placement de celui-ci se fait via une
croix affichée au-dessus de la carte.
* La possibilité de déplacer un POI de type nœud.
* De nouveaux types de couches, basés sur des fichiers
GPX, CSV
et GeoJSON.
* L'ajout d'une colonne d'information sur les couches. Elle
affiche les requêtes OverPass utilisées, les fichiers de
données
originaux, un bouton de téléchargement des données de la
couches
au format GeoJSON, etc.
* La possibilité de géolocaliser automatiquement
l'utilisateur.
* Le comportement de la recherche de la page d'accueil est
plus
clair et cohérent.
* Le bouton bleu « info » dans les champs de contribution est
maintenant actif et renvoie sur la page taginfo de la clef
courante.
* Les résultats de la recherche de lieu (géocodage) sont plus
lisibles et apportent plus d'informations.
* La possibilité d'afficher les infos de POI dans des fenêtres
modales oue des colonnes, à la place des infobulles
classiques.
* Et comme toujours, une multitude 

Re: [OSM-talk-fr] Problème d'accès à FR-BAN et FR-Cadastre !

2016-07-27 Par sujet Tyndare


Arghhh effectivement, je savais pourtant bien qu'il ne faut pas essayer 
de corriger ce qui marche.


Normalement les bâtiments wall=no devraient réapparaître dans les exports.


On 27/07/2016 11:13, Pierre-Yves Berrard wrote:

Constaté aussi pour les wall=no.

PY

Le 27 juillet 2016 à 10:58, Nicolas Moyroud > a écrit :


Merci effectivement ça a l'air bon pour le water.
J'ai remarqué un autre bug dans les exports en ce qui concerne le
fichier house-simplifie. Tous les polygones en wall=no ne sont
plus présents. Constaté sur 2 communes différentes. Je n'ai pas
regardé ce que ça donnait dans le fichier house non simplifié.

Nicolas

Le 26/07/2016 11:54, Tyndare a écrit :

Résultat à vérifier mais normalement c'est fait.


On 20/07/2016 10:04, Nicolas Moyroud wrote:

Bonjour,

Si à l'occasion tu as le temps de t'occuper du problème
des données data/eau découpées en petits morceaux ça
m'aiderait bien. :-)

Nicolas



___
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] TLPE et OSM : coment la publicité extérieure aide à compléter OSM !

2016-07-27 Par sujet Pierre Touzard
/>> Il y a aussi des photos des commerces correspondants ?/

Dans notre protocole technique nous filmons les rues. Nous ne produisons pas
à proprement parler des photos des commerces mais plutôt des photos des
rues.
Nous travaillons actuellement à un script qui pourrait nous permettre de
verser les photos sur Mapillary étant donnée qu'effectivement les images
sont retraitées automatiquement (floutage des éléments sensibles).

Concernant la licences des données nous allons bientôt annoncer qu'elle est
entièrement compatible avec OSM (ODbL).


Pierre T.










--
View this message in context: 
http://gis.19327.n5.nabble.com/TLPE-et-OSM-coment-la-publicite-exterieure-aide-a-completer-OSM-tp5877786p5879265.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] Problème d'accès à FR-BAN et FR-Cadastre !

2016-07-27 Par sujet Pierre-Yves Berrard
Constaté aussi pour les wall=no.

PY

Le 27 juillet 2016 à 10:58, Nicolas Moyroud  a écrit :

> Merci effectivement ça a l'air bon pour le water.
> J'ai remarqué un autre bug dans les exports en ce qui concerne le fichier
> house-simplifie. Tous les polygones en wall=no ne sont plus présents.
> Constaté sur 2 communes différentes. Je n'ai pas regardé ce que ça donnait
> dans le fichier house non simplifié.
>
> Nicolas
>
> Le 26/07/2016 11:54, Tyndare a écrit :
>
>> Résultat à vérifier mais normalement c'est fait.
>>
>>
>> On 20/07/2016 10:04, Nicolas Moyroud wrote:
>>
>>> Bonjour,
>>>
>>> Si à l'occasion tu as le temps de t'occuper du problème des données
>>> data/eau découpées en petits morceaux ça m'aiderait bien. :-)
>>>
>>> Nicolas
>>>
>>>
>
> ___
> 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] Problème d'accès à FR-BAN et FR-Cadastre !

2016-07-27 Par sujet Nicolas Moyroud

Merci effectivement ça a l'air bon pour le water.
J'ai remarqué un autre bug dans les exports en ce qui concerne le 
fichier house-simplifie. Tous les polygones en wall=no ne sont plus 
présents. Constaté sur 2 communes différentes. Je n'ai pas regardé ce 
que ça donnait dans le fichier house non simplifié.


Nicolas

Le 26/07/2016 11:54, Tyndare a écrit :

Résultat à vérifier mais normalement c'est fait.


On 20/07/2016 10:04, Nicolas Moyroud wrote:

Bonjour,

Si à l'occasion tu as le temps de t'occuper du problème des données 
data/eau découpées en petits morceaux ça m'aiderait bien. :-)


Nicolas




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