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

2017-07-20 Par sujet osm . sanspourriel 
D'accord avec les remarques de Philippe mais il y a des groupement 
régionaux (CREA, Geobretagne, etc...) qui ont déjà les infra qui vont 
bien (pour geobretagne c'est georchestra basé sur GeoServer et GeoWebCache).
C'est à base de logiciels libres et Geobretagne a fait des petits. Il 
n'y a pas une agence en Normandie ?

Car c'est à mon avis à eux de proposer le service.
Pas aux GAFA

Violaine avait eu ce besoin pour un Mapathon (une imagerie aérienne à 
mettre à dispo des éditeurs style JOSM) et elle l'a fait en quelques 
heures (une, deux ?), en tous cas avant le début du Mapathon mais pas 
sans stress. Ça pourrait être automatisé.

Fil de discussion "Charger imagerie en local sur JOSM".
Peut-être qu'elle a pris le temps de faire un bon doc.

Ça permet de récupérer du TMS, notamment en 512x512 pour JOSM.
Le faire chez soi, ça le fait.

Je dis une à deux heures, mais parce que j'avais résolu les problèmes 
avant : je savais que faire.


On pourrait imaginer un proxy OSM qui suivant la tuile choisie irait la 
demander à Geobretagne par exemple si c'est en Bretagne mais au CREA si 
c'est en Auvergne.

Avec comme pour le serveur TMS cadastre le problème des zones frontalières.
Car il est difficile de savoir s'il vaut mieux mettons  la tuile du Mont 
Saint-Michel de la photo de la Bretagne ou celle de la Normandie.
Je suis à proximité d'une frontière départementale et Geobretagne avait 
choisi la photo provenant de l'imagerie de mon département.
Assez logique pourtant la qualité était moins bonne que celle du 
département voisin.
Le problème à été résolu : nouvelles photos formant un continuum de 
meilleure qualité.


Marc, le problème de :
/cela permet d'estimer la surface qui pourrait être traité on la met 
dispo à usage interne pendant 1 mois. le mois d'après, on passe à la 
zone suivante


/C'est que tu imposes la zone à traiter.
Or si une zone est mal faite, c'est cette zone là que l'utilisateur veut 
modifier, indépendamment de la zone actuellement en ligne.
Ce que tu proposes c'est un peu ce que Christian fait avec OpenSolarMap 
: si on veut globalement améliorer un critère, ça marche.


Faire avec des comptes pseudo gratuits, pourquoi pas.
Je n'ai pas trop compris pourquoi le tile@home était tombé : est-ce que 
tout le flux passait par l'université et non les appels redirigés ?

Est-ce une architecture intéressante ? Dépassée ?

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

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

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

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

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

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


Le 20 juillet 2017 à 21:52, marc marc  a écrit :

> idée de solution :
> se demander ce qu'on va faire de ortho haute définition : vérifier
> l'existant ? corriger des erreurs de cadastre ? meilleur localisation
> des routes ? autre ?
> en déduire un ordre de grandeur de temps nécessaire pour 1km2
> compter le nombre de personne intéressé pendant 1 mois
> cela permet d'estimer la surface qui pourrait être traité
> on la met dispo à usage interne pendant 1 mois.
> le mois d'après, on passe à la zone suivante
> il ne resterait alors plus que le problème :
> - couper l'archive ou les archives initiales en zone. je n'ai cependant
> aucune idée sous quelle forme l'info est actuellement.
> - stoker ces éléments d'ici leur utilisation soit "hors ligne"
> soit en mode distribué via x comptes pseuo-gratuit en attendant mieux
>
> Le 20. 07. 17 à 14:44, Christian Quest a écrit :
> > Il y a un paquet de nouvelles ortho en haute-def qui sont disponibles
> > sous licence ouverte depuis quelques temps... on en a même parlé lors

Re: [OSM-talk-fr] catégories dans traduction page wiki

2017-07-20 Par sujet Philippe Verdy 
En gros pour une page d'article (c'est différent pour une page de
catégorie) tu commence par ajouter le préfixe de langue (FR:) au nom de la
catégorie anglaise, ensuite tu regardes si la catégorie est redirigée vers
un nom traduit après ce suffixe, et tu reviens sur la page pour utiliser le
nom traduit (avec son préfixe FR:) de la catégorie redirigée.

Cependant en ce moment la catégorisation du wiki ne marche pas, elle n'est
pas mise à jour par les nouveaux membres ajoutés ni avec les membres qui en
sont retirés, et de même les liste des liens menant à la page (barre
latérale: Outils/Pages Liées) n'est pas non plus mise à jour quand d'autres
pages sont modifiées pour pointer sur la nouvelle page.

C'est un bogue du wiki depuis début juin (depuis le déploiement de
MediaWiki 1.28.0, pas encore corrigé par MediaWiki depuis plusieurs mois et
toujours pas corrigé dans les versions 1.29 et 1.30 et leurs patches sensés
éviter le problème). Bref on n'a plus de mises à jour du tout des
catégories qui ne font qu'afficher leur état dans lequel elles étaient le 5
juin (la seule chose qui change c'est éventuellemetn le texte de leur page
de description, pas leurs membres.


2017-07-20 20:32 GMT+02:00 lenny.libre :

> Bonjour,
>
> J'ai traduit une page du wiki, je l'ai renommée et les redirections
> semblent fonctionner
>
> https://wiki.openstreetmap.org/wiki/FR:JOSM/Greffons/PT_Assistant
>
> Par contre, quand j'arrive au  § catégories de la page sur les traductions
> http://wiki.openstreetmap.org/wiki/FR:Traduction_du_wiki#Cat.C3.A9gorie
>
> Je ne comprends pas bien ce qu'il faut faire
>
> Merci d'avance
>
> Leni
>
>
> ___
> 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] Sécuriser Overpass API : quelles solutions ?

2017-07-20 Par sujet marc marc 
Bonsoir,

Je suis fan de la haute disponibilité et solution équivalente.

Il y a 2 overpass api planté : allemande et française.
Une première solution applicative est d'avoir la liste de toute les 
serveurs overpass api et de passer au suivant en cas d'erreur dans un 
ordre statique ou dans un ordre dépendant de la localisation de ce qu'on 
demande.
Ce choix peux se faire dan l'app ou idéalement il faudrait des "proxy 
d'api" ultra léger qui s'en chargent.
C'est la structure classique d'une infra HA (reverse proxy redondant 
devant des serveur applicatifs redondant)

Mais l'expérience m'a appris que le plus stable est souvent le cache.
N'ayant pas pu tester Jungle Bus (incompatibilité), je me demandais que 
pouvait demander l'application de si dynamique ?
Un arrêt de bus, cela ne bouge pas souvent, une ligne de bus non plus.
Sauf erreur de ma part, osm a une copie locale de la base mondiale.
N'est-il pas envisageable d'avoir la votre qui se mettrait à jour avec 
des diffs concernant les quelques types d'objets concernés ?
J'imagine cela en mode push, sous forme de diff, sur le même modèle que 
osm.fr reçoit lui-même des infos pour garder sa copie locale à jour.
Le seul hic c'est que les export de diff n'ont peut-être pas encore de 
filtre autre que géographique. Trimble Data a l'air de le faire sur 
requête manuelle, il faudrait l'équivalent en push.

L'autre partie de la solution c'est d'avoir une alerte quand l'api est 
en rade afin d'éviter qu'elle le reste trop longtemps et de pouvoir en 
trouver aussi plus facilement la cause.
Peut-être que cela existe déjà mais je n'ai rien vu sur la ml tech.

--

Le 20. 07. 17 à 21:07, Florian LAINEZ a écrit :
> Salut,
> Aujourd'hui on a eu -encore !- une interruption de service sur 
> l'overpass API. Cela a impacté l'appli Jungle Bus mais j'imagine tout un 
> tas d'autres services qui se basent dessus.
> J'ai l'impression que cela se produit souvent. Je constate dans mes 
> projets que ce service reste le maillon faible technique et impose de 
> mettre en place une pénible redondance.
> 
> Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les causes 
> profondes ?
> Y aurait-il une solution que nous pourrions mettre en place pour venir 
> en soutien à nos amis les teutons qui gèrent le bouzin ?
> Est-ce plutôt un besoin de dev ou d’hébergement ?
> Bref, on résout le problème ? ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-20 Par sujet Philippe Verdy 
Le 20 juillet 2017 à 23:32,  a écrit :

> Précisions et c'est une réponse à Marc qui me posait une question en MP.
>
> C'est aussi un indice sur la réponse de François.
>
> Actuellement c'est "uniquement" le out meta qui ne marche plus, out body
> et out skel marchent.
>
> C'est c'est une requête CSV, soit tu mets ", ::count" en colonne et tu
> mets des out count; pour voir s'il trouve :
>
> http://overpass-turbo.eu/s/qvq
>
> 32 mais pas de données.
>
> http://overpass-turbo.eu/s/qvr
>
> Tu as bien deux fois 32, mais des lignes vides car tu demandes des méta
> données extraite d'un ensemble qui ne les comprend pas.
>
> Un retour d'une requête en json est plus explicite.
>
> *Une erreur est survenue lors de l'exécution de la requête overpass !
> Voici ce que l'API overpass a retourné :*
>
> *runtime error: open64: 763 Unknown error 763
> /opt/osm-3s/v0.7.54/db/user_data.bin File_Blocks::read_block: Index
> inconsistent*
>

J'ai signalé hier la même anomalie (*read_block: Index inconsistent*) sur
Osmose (erreur retournée pour des requêtes indépendamment de la position
mais concernant certaines valeurs recherchées de tags). Là aussi corruption
de la base de données dans un de ses index (mais si ce n'est que ça, c'est
réparable facilement sans avoir à tout recharger; un index ça se régéère si
les données ne sont pas seulement dans cet index mais seulement copiées en
partie vers celui-ici)

Même erreur il ya quelques jours sur le serveur de rendu Mapnik d'OSM.org
(là encore sur sa base SQL interne, ce qui empêchait totalement de
recalculer certaines zones utilisant certains tags, ou alors le faisait
planter et redémarrer en boucle sans traiter les zones commencées mais
abandonnées en cours après plusieurs échecs successifs)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-20 Par sujet Philippe Verdy 
L'Overpass API allemande jsutement a planté aussi (à cause d'une perte
d'alimentation chez l'hébergeur pourtant sensé avoir des alimentations de
secours, ce qui a entrainé des pertes de donénes au redémarrage et
l'absence de certains secteurs de données pour des fichiers qui pourtant
étaient sensés avoir une taille supérieure: ces secteurs n'ont pas été
écrits ni même marqués comme alloués alors que la taille de fichier était à
jour, et cela a entrainé une erreur lors de la décompression remplissant un
fichier décompressé de tas de zéros, à cause d'un autre bogue dans l'outil
de décompression qui ne d'étactait pas l'erreur, puis des tonnes
d'incohérences et un plantage dans le chargement des "diffs" pour la mise à
jour de sa base, qui ensuite a planté).

En cause aussi le système de fichier qui n'a pas assuré la cohérence de
l'ordre des écritures, ou bien des anomalies dans les pilotes qui n'ont pas
assuré l'ordonnancement correct malgré le fait qu'il s'agissait d'un
système de fichiers "journalisé" parait-il. Mais aussi en cause certains
réglages d'optimisation des pilotes de disque (pour les performances au
détriment de la cohérence) pour le réglage des caches, aussi bien ceux sur
les contrôleurs des disques physiques que ceux des contrôleurs RAID ou les
caches des interfaces SATA/PCI et sans doute aussi des bogues dans la
gestion de l'énergie au sein des BIOS (ou pilotes de périphériques devant
remplacer les fonctions du BIOS), et peut-être aussi des bogues dans la
synchronisation des coeurs de processeurs récents

(il y a par exemple un bogue sérieux sur une ligne récente de CPU
multicoeurs Intel parmi les plus chers de la gamme pour serveur, pour
lequel des recherches compliquées ont été menées suite à un plantage
inexplicable d'une machine virtuelle avec certaines séquences
d'instructions générées par un compilateur JIT pourtant réputé: le
compialteur n'est pas en cause, mais on a des cas critiques avec certaines
séquences liées à certaines longueurs de "boucles" de code en fonction
causé par une mauvaise synchronisation des pipelines de code suite à des
états d'attente entre plusieurs niveaux de cache interne des processeurs:
certains de ces processeurs ont été déclassés par Intel mais pas retirés du
marché, en désactivant des coeurs et une partie des pipelines et des
caches, mais en attendant certains fabricants OEM sont restés en attente de
matériel et ont du revoir leurs livraisons ou changer de ligne de
processeur, mais des serveurs défectueux ont déjà été livrés et Intel
cherche toujours un moyen de détecter et prévenir ces bogues par un
firmware... et il n'a encore rien publié car il semble qu'il n'y ait aucune
façon simple de prévenir le problème autrement qu'en modifiant les
logiciels utilisés et notamment en désactivant certaines optimisations de
code dans les compilateurs, des optimisations pourtant éprouvées depuis
longtemps)

(il y a un autre exemple récent ces jours-ci avec l'annonce récente par
Microsoft qu'il ne supporait plus les mises à jours de Windows 10 sur
certaines gammes récentes de processeurs très courants sur les tablettes et
mobiles, à cause d'une fonctionnalité défaillante sur ces processeurs, pour
laquelle Microsoft voulait ne plus supporter la prise en charge par
logiciel via un firmware correctif)

(d'autres exemples comme ça il y en a des tas, les listes de bogues
matériels des processeurs sont impressionnantes et notamment pour les
processeurs les plus évolués devant équiper les serveurs qui en principe
devraient être immunisés des problèmes liés à l'alimentation et supporter
matériellement et par logiciel des systèmes de redondance permettant une
reprise rapide, et de détection rapide et contournable des anomalies;
certains de ces bogues existent même pour des processeurs équipant du
matériel spatial, on a eu le cas avec plusieurs satellites pour la
navigation qui sont hors d'usage du fait de graves anomalies sur leurs
horloges qui sont tombées les unes après les autres et ne sont pas
corrigeables ou réduisent considérablement leur précision au point que ces
appareils se servent plus car on ne sait même corriger certaines anomalies
de mesure en injectant des correctifs sur leur logiciel embarqué)

Conclusion: personne n'est à l'abri, des bogues il y en a partout, on doit
faire avec et surtout on doit pouvoir les détecter à tout moment et tout
niveau des traitements sans jamais faire confiance à ce qui est fait par
une couche logicielle sensée être déjà complètement testée: en pratique il
n'existe aucun système permettant de prouver qu'un code est correct et
encore moins de savoir si leur conception initiale fixait toutes les
contraintes vérifiables et on sait que certaines contraintes ne sont pas
vérifiables en temps fini par un quelconque algorithme ou raisonnement
mathématique le plus rigoureux (et il n'existe pas encore un seul langage
de programmation permettant de vérifier toutes les contraintes nécessaires,
même avec les langages dits "fonctionnels" qui ont

Re: [OSM-talk-fr] articles OSM dans Géomatique Expert

2017-07-20 Par sujet Benoit Fournier 
Pour la partie "Des outils Python pour mesurer la qualité des données OSM",
voir aussi :
http://oslandia.com/en/2017/07/03/openstreetmap-data-analysis-how-to-parse-the-data-with-python/

2017-07-20 11:48 GMT+02:00 Benoit Fournier :
> http://www.geomag.fr/revue/geomatique-expert-n117-juillet-2017
>
> Le dernier numéro de Géomatique Expert fait la part belle à
> OpenStreetMap, l'Open Data et l'Open Source avec de grands articles.
>
> Au sommaire :
>
> - La conférence 2017 State of the Map France
> - Des outils Python pour mesurer la qualité des données OSM
> - Une brève histoire d’Inspire
> - Open data et tourisme
> - Le point sur QGis et d’autres projets
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-20 Par sujet osm . sanspourriel 

Précisions et c'est une réponse à Marc qui me posait une question en MP.

C'est aussi un indice sur la réponse de François.

Actuellement c'est "uniquement" le out meta qui ne marche plus, out body 
et out skel marchent.


C'est c'est une requête CSV, soit tu mets ", ::count" en colonne et tu 
mets des out count; pour voir s'il trouve :


http://overpass-turbo.eu/s/qvq

32 mais pas de données.

http://overpass-turbo.eu/s/qvr

Tu as bien deux fois 32, mais des lignes vides car tu demandes des méta 
données extraite d'un ensemble qui ne les comprend pas.


Un retour d'une requête en json est plus explicite.

/Une erreur est survenue lors de l'exécution de la requête overpass ! 
Voici ce que l'API overpass a retourné :/


/runtime error: open64: 763 Unknown error 763 
/opt/osm-3s/v0.7.54/db/user_data.bin File_Blocks::read_block: Index 
inconsistent/


Un moteur de recherche te donne une réponse : le forum allemand d'osm: 
https://forum.openstreetmap.org/viewtopic.php?id=59136


Status : c'est par ici
https://wiki.openstreetmap.org/wiki/Overpass_API/status
L'alimentation de secours a planté et le disque a été corrompu.
Ce que n'attendait pas Roland Olbricht qui demande en attendant 
d'utiliser l'instance russe.

https://lists.openstreetmap.org/pipermail/talk/2017-July/078321.html
pis le fichier corrompu c'est celui des utilisateurs, d'où la plante 
spécifique sur le out meta.


wambacher précise :  To use another server instance e.g. add

{{data:overpass,server=http://overpass.osm.rambler.ru/cgi/interpreter/}}

to your query in Overpass Turbo.

Déjà par rapport à la solution de François je poserai les deux requêtes 
que si la première n'a pas marché.

Comme Roland lit le français je lui signale ce fil de discussion.
Démarrer une VM en cas de problème c'est juste trop tard.
Il faut donc plutôt une solution plus simple : quelques instances (ici 
2), surveillées (c'est le cas 
https://wiki.openstreetmap.org/wiki/Overpass_API/status) et un DNS 
dynamique (IP fail over pour OVH).
Tu aurais instance1 et instance2, en général instance1 pointe sur le 
serveur allemand et instance2 sur le serveur russe.
Si le serveur allemand plante (comme ici), on bascule instance1 sur le 
serveur russe.


C'est de l'infra sans doute plus simple à mettre en place.

Et pour nous utilisateurs on peut consulter la page status et changer de 
serveur si nécessaire.


Quand à remonter la VM, je crois qu'on va avec des TP Ansible pour faire ça.
Ce serait effectivement bien de pouvoir monter facilement un tel service.
Quitte à limiter pour l'instant la zone de données ?

Jean-Yvon

Le 20/07/2017 à 21:07, Florian LAINEZ - winner...@free.fr a écrit :

Salut,
Aujourd'hui on a eu -encore !- une interruption de service sur 
l'overpass API. Cela a impacté l'appli Jungle Bus mais j'imagine tout 
un tas d'autres services qui se basent dessus.
J'ai l'impression que cela se produit souvent. Je constate dans mes 
projets que ce service reste le maillon faible technique et impose de 
mettre en place une pénible redondance.


Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les 
causes profondes ?
Y aurait-il une solution que nous pourrions mettre en place pour venir 
en soutien à nos amis les teutons qui gèrent le bouzin ?

Est-ce plutôt un besoin de dev ou d’hébergement ?
Bref, on résout le problème ? ;)

--

*Florian Lainez*

@overflorian 


___
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] admin_level sur des chemins non fermés

2017-07-20 Par sujet Philippe Verdy 
Non la cause le plus fréquente n'est pas qu'il manque un chemin mais qu'un
chemin a été scindé sans mettre à jour toutes les relations dépendantes.
Le chemin n'est donc pas effacé, il a conservé ses attributs, mais des
relations sont cassées quand même.
Les cas de suppression de chemins (ou suppression d'attributs) sont très
rares.

Cette anomalie arrive souvent par un usage incorrect de JOSM (oubli de
charger les relations dépendantes) quand on a chargé juste une partie des
relations et de leurs chemins enfants, puis qu'on modifie un de ces chemins
sans charger les autres relations), mais il y a des cas aussi avec tous les
autres éditeurs, y compris iD (même si c'est moins fréquent), car le
serveur ne retourne pas toujours à l'éditeur toutes les relations
dépendantes, même dans une zone de recherche géographique dont on charge
tous les éléments.

Pour diverses raisons (y compris des problèmes momentanés de liaison
Internet), il peut manquer ces relations (et il n'y a aucune indication de
cette incohérence puisque le nombre de relations parentes n'est pas indiqué
dans les métadonnées d'un objet, le contrôle de cohérence ne portant que
sur l'objet lui-même (tags, noeuds des chemins, et membres enfants des
relations) qui sont également les seules à affecter le numéro de version
d'un objet (et sa date de dernière modification) ou à indiquer le numéro de
changeset qui a pu l'affecter: il n'y a pas de propagation que ce soit en
amont ou en aval d'un objet vers un autre objet (donc également le
déplacement d'un noeud ou le changement de ses tags n'a aucune incidence
sur le versionnement de ses chemins ou relations parents).

Note bien que dans les pays supposés ne pas utiliser ces tags 'redondants"
on voit partout des anomalies sur les rendus où des frontières sont
invisibles. Cela affecte même Mapnik. la raison semble en être le coût
élevé pour aller chercher toutes les relations parentes d'un objet, et
notamment les relations frontières qui sont souvent très complexes et
lourdes en données (ne serait-ce qu'un "petit" pays comme la France à cause
de ses frontières maritimes, mais même pour l'Allemagne ou encore la Suisse
qui n'a pas de frontière maritime complique c'est un volume important du
fait de la précision des données. Et la complexité s'étant aussi aux
niveaux inférieurs (regarde par exemple la Bretagne).

Ce n'est pas aussi pathologique que tu le penses et il y a même une
exception totale concernant les lignes de côtes qui ne sont pas du tout
représentées par des relations fermées et qui imposent également un sens de
tracé, car sinon c'est beaucoup trop lourd en données.

Pour le reste les objets sont assez petits pour ne pas avoir besoin de
telles redondances: les frontières restent une exception même si pour elles
on a pu mettre des relations (en levant toutefois certaines barrières qui
existaient dans le nombre de membres par relations qui a du être relevé
notamment pour la France, les USA, le Canada ou la Russie, mais là encore
c'est très lourd de chercher si une frontière est une frontière nationale
de ces pays en chargeant ses relations membres et le serveur ne retourne
même pas toujours cette information quand on le lui demande et qu'il est un
peu trop chargé de travail).


Le 20 juillet 2017 à 22:13, marc marc  a écrit :

> Pour répondre brièvement
>
> Le 20. 07. 17 à 13:47, Philippe Verdy a écrit :
> > > cette redondance (partielle)
> > > est encore très pratique pour pas mal de recherches.
> > un exemple ?
> > Justement pour réparer quand une relation est cassée.
> si quelqu'un efface un chemin, la relation est cassée et tes tags de
> "secours" sont perdus également.
> quand cela a lieu sur une ligne de bus ou dans un pays sans ces doublon,
> on utilise les changeset pour "remonter" le temps.
> autre solution : réelles sauvegardes hors osm des relations critiques
> les limites des communes changent peu, c'est ultra efficace.
> C'est ce qui est fait il me semble pour les points géodésiques.
>
> > il y a encore des moteurs de rendu
> > qui ont besoin de cette redondance partielle, ne serait-ce que pour
> > représenter les "pointillés"
> D'autres pays voisins s'en passent très, jamais vu de problème de rendu
> des limites parfois très tortueuse qu'ils ont.
> Rédiges un rapport de bug si un rendu particulier a un soucis au lieu
> d'avoir des milliers de tag comme béquille.
>
> Bref, toutes les fonctionnalités que tu cites existent dans des pays
> n'utilisant pas ce système de tags dupliqués.
> Peut-être faudrait-il un jour se demander si leur utilité théorique
> n'est pas largement engloutie par la complexité que cela entraîne sur
> des stats aussi basique qu'une liste des noms des communes de France.
>
> D'ici là, comme ce n'est pas mur, je passe au sujet suivant :-)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet Jérôme Amagat 
je crois que le rendu osm fr se sert de ces tag admin_level sur les way et
c'est pour ça qu'il manque des morceaux de frontières sur le rendu à de
faible zoom. par exemple ici on voit des manques sur des pays d’Afrique :
http://tile.openstreetmap.fr/?zoom=5=-9.41895=26.29572=B00FF

Je viens de regarder très rapidement plusieurs frontières dans des pays
voisins et je suis à chaque fois tombé sur un way avec le tag admin_level=*

Le 20 juillet 2017 à 22:13, marc marc  a écrit :

> Pour répondre brièvement
>
> Le 20. 07. 17 à 13:47, Philippe Verdy a écrit :
> > > cette redondance (partielle)
> > > est encore très pratique pour pas mal de recherches.
> > un exemple ?
> > Justement pour réparer quand une relation est cassée.
> si quelqu'un efface un chemin, la relation est cassée et tes tags de
> "secours" sont perdus également.
> quand cela a lieu sur une ligne de bus ou dans un pays sans ces doublon,
> on utilise les changeset pour "remonter" le temps.
> autre solution : réelles sauvegardes hors osm des relations critiques
> les limites des communes changent peu, c'est ultra efficace.
> C'est ce qui est fait il me semble pour les points géodésiques.
>
> > il y a encore des moteurs de rendu
> > qui ont besoin de cette redondance partielle, ne serait-ce que pour
> > représenter les "pointillés"
> D'autres pays voisins s'en passent très, jamais vu de problème de rendu
> des limites parfois très tortueuse qu'ils ont.
> Rédiges un rapport de bug si un rendu particulier a un soucis au lieu
> d'avoir des milliers de tag comme béquille.
>
> Bref, toutes les fonctionnalités que tu cites existent dans des pays
> n'utilisant pas ce système de tags dupliqués.
> Peut-être faudrait-il un jour se demander si leur utilité théorique
> n'est pas largement engloutie par la complexité que cela entraîne sur
> des stats aussi basique qu'une liste des noms des communes de France.
>
> D'ici là, comme ce n'est pas mur, je passe au sujet suivant :-)
>
> Cordialement,
> Marc
> ___
> 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] admin_level sur des chemins non fermés

2017-07-20 Par sujet marc marc 
Pour répondre brièvement

Le 20. 07. 17 à 13:47, Philippe Verdy a écrit :
> > cette redondance (partielle)
> > est encore très pratique pour pas mal de recherches.
> un exemple ?
> Justement pour réparer quand une relation est cassée.
si quelqu'un efface un chemin, la relation est cassée et tes tags de 
"secours" sont perdus également.
quand cela a lieu sur une ligne de bus ou dans un pays sans ces doublon, 
on utilise les changeset pour "remonter" le temps.
autre solution : réelles sauvegardes hors osm des relations critiques
les limites des communes changent peu, c'est ultra efficace.
C'est ce qui est fait il me semble pour les points géodésiques.

> il y a encore des moteurs de rendu 
> qui ont besoin de cette redondance partielle, ne serait-ce que pour 
> représenter les "pointillés"
D'autres pays voisins s'en passent très, jamais vu de problème de rendu 
des limites parfois très tortueuse qu'ils ont.
Rédiges un rapport de bug si un rendu particulier a un soucis au lieu 
d'avoir des milliers de tag comme béquille.

Bref, toutes les fonctionnalités que tu cites existent dans des pays 
n'utilisant pas ce système de tags dupliqués.
Peut-être faudrait-il un jour se demander si leur utilité théorique 
n'est pas largement engloutie par la complexité que cela entraîne sur 
des stats aussi basique qu'une liste des noms des communes de France.

D'ici là, comme ce n'est pas mur, je passe au sujet suivant :-)

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

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

2017-07-20 Par sujet marc marc 
idée de solution :
se demander ce qu'on va faire de ortho haute définition : vérifier 
l'existant ? corriger des erreurs de cadastre ? meilleur localisation 
des routes ? autre ?
en déduire un ordre de grandeur de temps nécessaire pour 1km2
compter le nombre de personne intéressé pendant 1 mois
cela permet d'estimer la surface qui pourrait être traité
on la met dispo à usage interne pendant 1 mois.
le mois d'après, on passe à la zone suivante
il ne resterait alors plus que le problème :
- couper l'archive ou les archives initiales en zone. je n'ai cependant 
aucune idée sous quelle forme l'info est actuellement.
- stoker ces éléments d'ici leur utilisation soit "hors ligne"
soit en mode distribué via x comptes pseuo-gratuit en attendant mieux

Le 20. 07. 17 à 14:44, Christian Quest a écrit :
> Il y a un paquet de nouvelles ortho en haute-def qui sont disponibles 
> sous licence ouverte depuis quelques temps... on en a même parlé lors de 
> notre dernier CA ;)
> 
> Actuellement il y a plus d'une quarantaine de départements et quelques 
> agglos avec des définitions qui sont en général de 20cm/pixel voire 10 
> et les prochaines devraient même aller jusque 5cm/pixel !
> 
> Voilà pour la bonne nouvelle... maintenant la moins bonne...
> 
> C'est LOURD, très lourd comme vous pouvez l'imaginer. La moitié de la 
> France est ainsi couverte, soit plus de 250.000km2, avec environ 25 
> millions de pixels/km2... soit 6250 milliards de pixels...
> 
> J'évalue le stockage nécessaire à 5To. Actuellement on n'a pas cette 
> capacité sur l'infra OSM-France à dédier uniquement pour cet usage.
> 
> Je compte tester avec les orthos les plus récentes sur un serveur perso 
> (dans ma cave) où j'ai 8To... ça fait partie de mes devoirs de vacances ;)
> Si ça vaut le coup et que c'est gérable, on peut envisager de mettre à 
> niveau un des serveurs chez free pour ce contenu (ils ont 8 emplacements 
> pour des disques 2,5" donc potentiellement 32To au max en HDD).
> 
> A plus court terme, il faut aussi voir aussi si ces orthos ne sont pas 
> mise à disposition en TMS ou WMTS, donc tuilées pour un usage direct 
> dans nos outils habituels ce qui nous évite de les héberger nous même.
> 
> 
> Le 20/07/2017 à 13:48, marc marc a écrit :
>> Il faudrait peut-être leur écrire pour demander le taille.
>> si osm.fr est limité en bande passante, je pense que cela serrait quand
>> même pratique en interne quitte a limiter volontairement la bande
>> passante de ce service précis.
>> Si le problème est l'espace disque, c'est évidement plus délicat.
>> Comment fonctionne le partenariat avec la Fondation Free ?
>> l'asso demande au cas par cas de ses besoins ?
>> ou c'est figé ?
>>
>> Le 20. 07. 17 à 11:43, Philippe Verdy a écrit :
>>> C'est "dispo" peut-être mais sur demande par mail. Ca veut dire qu'ils
>>> n'ont pas les moyens d'héberger un serveur TMS/WMS
>>> Peut-être que la Fondation Free a encore des moyens pour héberger ça en
>>> ligne. Je ne suis pas convaincu qu'OSM France ait ces moyens car on voit
>>> déjà comment on l'espace de stockage et la bande passante sont déjà des
>>> problèmes de capacité.
>>>
>>> Le 20 juillet 2017 à 10:48, David Crochet a écrit :
>>>  c'est intéressant ?
>>>  
>>> http://www.geonormandie.fr/accueil/les_actualites/actualites_de_geonormandie/109_845/lorthophotographie_regionale_haute_resolution_de_20152016_est_disponible_
>>>  
>>>
>>
> 

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

Re: [OSM-talk-fr] Sécuriser Overpass API : quelles solutions ?

2017-07-20 Par sujet François Lacombe 
Hello Florian

Niveau robustesse il n'y a pas 36 solutions, il faut un cluster avec un
loadbalancer
Avec un bon hyperviseur, tu detruit carrement une vm qui plante pour en
remonter une aussi sec

Mais ca reste couteux alors il faut deja adresser ses requêtes a
différentes instances, au moins de et ru je pense

Ce qui est sur est que ca va vite couter un peu de monnaie pour monter une
infra disponible
CDN & co ne seront efficaces que pour des requetes courantes et surtout
abondamment utilisées, ce qui n'est majoritairement pas le cas

A+

François

Le 20 juil. 2017 9:08 PM, "Florian LAINEZ"  a écrit :

> Salut,
> Aujourd'hui on a eu -encore !- une interruption de service sur l'overpass
> API. Cela a impacté l'appli Jungle Bus mais j'imagine tout un tas d'autres
> services qui se basent dessus.
> J'ai l'impression que cela se produit souvent. Je constate dans mes
> projets que ce service reste le maillon faible technique et impose de
> mettre en place une pénible redondance.
>
> Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les causes
> profondes ?
> Y aurait-il une solution que nous pourrions mettre en place pour venir en
> soutien à nos amis les teutons qui gèrent le bouzin ?
> Est-ce plutôt un besoin de dev ou d’hébergement ?
> Bref, on résout le problème ? ;)
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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] Sécuriser Overpass API : quelles solutions ?

2017-07-20 Par sujet Florian LAINEZ 
Salut,
Aujourd'hui on a eu -encore !- une interruption de service sur l'overpass
API. Cela a impacté l'appli Jungle Bus mais j'imagine tout un tas d'autres
services qui se basent dessus.
J'ai l'impression que cela se produit souvent. Je constate dans mes projets
que ce service reste le maillon faible technique et impose de mettre en
place une pénible redondance.

Est-ce que vous sauriez à quoi cela est dû ? Quelles en sont les causes
profondes ?
Y aurait-il une solution que nous pourrions mettre en place pour venir en
soutien à nos amis les teutons qui gèrent le bouzin ?
Est-ce plutôt un besoin de dev ou d’hébergement ?
Bref, on résout le problème ? ;)

-- 

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

[OSM-talk-fr] catégories dans traduction page wiki

2017-07-20 Par sujet lenny.libre 

Bonjour,

J'ai traduit une page du wiki, je l'ai renommée et les redirections 
semblent fonctionner


https://wiki.openstreetmap.org/wiki/FR:JOSM/Greffons/PT_Assistant

Par contre, quand j'arrive au  § catégories de la page sur les 
traductions 
http://wiki.openstreetmap.org/wiki/FR:Traduction_du_wiki#Cat.C3.A9gorie


Je ne comprends pas bien ce qu'il faut faire

Merci d'avance

Leni


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

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

2017-07-20 Par sujet Philippe Verdy 
Avec tout le monde qui était à la conférence FOSSGIS-Europe, et étant donné
le lieu où c'est situé, voilà un beau projet pour laquelle l'école en
question pourrait obtenir des moyens et héberger ça avec la bénédiction de
tas de collectivités qui ne doivent atendre que ça pour se libérer des
contrats propriétaires et de la tentation constante d'utiliser les GAFA qui
en retour ne leur donne pas grand chose alors qu'ils monétisent et
profitent énormément de ces données.

Si le secteur public ne le fait pas, de toute façon les GAFA auront accès à
ces données (le droit le leur permet et les collectivités ne peuvent même
pas légalement s'y opposer) et les utiliseront sur leurs services et même
si les conditions de l'opendata ne leur conviennent pas ils demanderont
juste de payer une licence symbolique pour un usage propriétaire et
illimité sans clause de retour: les collectivités à court d'argent
pourraient se laisser tenter et accepter l'aumône proposée qui leur
apportera un peu d'argent une fois puis plus rien ensuite après (pire:
elles devront encore payer les contrats de service pour accéder à ces
données via les APIs propriétaires, car ces données seront traitées et
augmentées, sans marquage particulier pour faire la différence, et non plus
dans leur forme initiale, et il sera très difficile même pour les
collectivités en question de demander des rectifications

On le voit facilement chez Google et Facebook qui font mine de "nettoyer"
pour certains clients de certains pays (mais ils refusent aussi assez
souvent) mais ensuite fait ce qu'il veut partout ailleurs: il n'y a aucune
rectification juste des filtrages supplémentaires au bon vouloir, et
souvent même des tas de demandes refusées et sans aucun appel possible). Il
y a bien les recours judiciaires mais ça coûte cher et ça prend un temps
fou (le mal est souvent déjà fait: c'est totalement hors de contrôle et
même la loi ne protège pas autant les personnes morales que les personnes
physiques qui pourtant sont elles aussi abusées sur Internet par ces
grosses sociétés qui distribuent les données où elles veulent et comme
elles le veulent avec des tas de critères clairement discriminatoires).


Le 20 juillet 2017 à 14:44, Christian Quest  a
écrit :

> Il y a un paquet de nouvelles ortho en haute-def qui sont disponibles sous
> licence ouverte depuis quelques temps... on en a même parlé lors de notre
> dernier CA ;)
>
> Actuellement il y a plus d'une quarantaine de départements et quelques
> agglos avec des définitions qui sont en général de 20cm/pixel voire 10 et
> les prochaines devraient même aller jusque 5cm/pixel !
>
> Voilà pour la bonne nouvelle... maintenant la moins bonne...
>
> C'est LOURD, très lourd comme vous pouvez l'imaginer. La moitié de la
> France est ainsi couverte, soit plus de 250.000km2, avec environ 25
> millions de pixels/km2... soit 6250 milliards de pixels...
>
> J'évalue le stockage nécessaire à 5To. Actuellement on n'a pas cette
> capacité sur l'infra OSM-France à dédier uniquement pour cet usage.
>
> Je compte tester avec les orthos les plus récentes sur un serveur perso
> (dans ma cave) où j'ai 8To... ça fait partie de mes devoirs de vacances ;)
> Si ça vaut le coup et que c'est gérable, on peut envisager de mettre à
> niveau un des serveurs chez free pour ce contenu (ils ont 8 emplacements
> pour des disques 2,5" donc potentiellement 32To au max en HDD).
>
> A plus court terme, il faut aussi voir aussi si ces orthos ne sont pas
> mise à disposition en TMS ou WMTS, donc tuilées pour un usage direct dans
> nos outils habituels ce qui nous évite de les héberger nous même.
>
>
> Le 20/07/2017 à 13:48, marc marc a écrit :
>
>> Il faudrait peut-être leur écrire pour demander le taille.
>> si osm.fr est limité en bande passante, je pense que cela serrait quand
>> même pratique en interne quitte a limiter volontairement la bande
>> passante de ce service précis.
>> Si le problème est l'espace disque, c'est évidement plus délicat.
>> Comment fonctionne le partenariat avec la Fondation Free ?
>> l'asso demande au cas par cas de ses besoins ?
>> ou c'est figé ?
>>
>> Le 20. 07. 17 à 11:43, Philippe Verdy a écrit :
>>
>>> C'est "dispo" peut-être mais sur demande par mail. Ca veut dire qu'ils
>>> n'ont pas les moyens d'héberger un serveur TMS/WMS
>>> Peut-être que la Fondation Free a encore des moyens pour héberger ça en
>>> ligne. Je ne suis pas convaincu qu'OSM France ait ces moyens car on voit
>>> déjà comment on l'espace de stockage et la bande passante sont déjà des
>>> problèmes de capacité.
>>>
>>> Le 20 juillet 2017 à 10:48, David Crochet a écrit :
>>>  c'est intéressant ?
>>>  http://www.geonormandie.fr/accueil/les_actualites/actualite
>>> s_de_geonormandie/109_845/lorthophotographie_regionale_
>>> haute_resolution_de_20152016_est_disponible_
>>>
>>
>>
> --
> Christian Quest - OpenStreetMap France
>
>
>
> ___
> Talk-fr mailing list
>

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

2017-07-20 Par sujet Christian Quest 
Il y a un paquet de nouvelles ortho en haute-def qui sont disponibles 
sous licence ouverte depuis quelques temps... on en a même parlé lors de 
notre dernier CA ;)


Actuellement il y a plus d'une quarantaine de départements et quelques 
agglos avec des définitions qui sont en général de 20cm/pixel voire 10 
et les prochaines devraient même aller jusque 5cm/pixel !


Voilà pour la bonne nouvelle... maintenant la moins bonne...

C'est LOURD, très lourd comme vous pouvez l'imaginer. La moitié de la 
France est ainsi couverte, soit plus de 250.000km2, avec environ 25 
millions de pixels/km2... soit 6250 milliards de pixels...


J'évalue le stockage nécessaire à 5To. Actuellement on n'a pas cette 
capacité sur l'infra OSM-France à dédier uniquement pour cet usage.


Je compte tester avec les orthos les plus récentes sur un serveur perso 
(dans ma cave) où j'ai 8To... ça fait partie de mes devoirs de vacances ;)
Si ça vaut le coup et que c'est gérable, on peut envisager de mettre à 
niveau un des serveurs chez free pour ce contenu (ils ont 8 emplacements 
pour des disques 2,5" donc potentiellement 32To au max en HDD).


A plus court terme, il faut aussi voir aussi si ces orthos ne sont pas 
mise à disposition en TMS ou WMTS, donc tuilées pour un usage direct 
dans nos outils habituels ce qui nous évite de les héberger nous même.



Le 20/07/2017 à 13:48, marc marc a écrit :

Il faudrait peut-être leur écrire pour demander le taille.
si osm.fr est limité en bande passante, je pense que cela serrait quand
même pratique en interne quitte a limiter volontairement la bande
passante de ce service précis.
Si le problème est l'espace disque, c'est évidement plus délicat.
Comment fonctionne le partenariat avec la Fondation Free ?
l'asso demande au cas par cas de ses besoins ?
ou c'est figé ?

Le 20. 07. 17 à 11:43, Philippe Verdy a écrit :

C'est "dispo" peut-être mais sur demande par mail. Ca veut dire qu'ils
n'ont pas les moyens d'héberger un serveur TMS/WMS
Peut-être que la Fondation Free a encore des moyens pour héberger ça en
ligne. Je ne suis pas convaincu qu'OSM France ait ces moyens car on voit
déjà comment on l'espace de stockage et la bande passante sont déjà des
problèmes de capacité.

Le 20 juillet 2017 à 10:48, David Crochet a écrit :
 c'est intéressant ?
 
http://www.geonormandie.fr/accueil/les_actualites/actualites_de_geonormandie/109_845/lorthophotographie_regionale_haute_resolution_de_20152016_est_disponible_




--
Christian Quest - OpenStreetMap France


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

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

2017-07-20 Par sujet Philippe Verdy 
Je ne pense pas qu'on devrait demander explicitement à une fondation
privée, même si elle est déjà remerciée pour sa contribution. Et qu'on a
intérêt à multiplier les partenariats (notamment avec les organismes
publics divers) pour conserver une relative indépendance (et aussi éviter
qu'à l'avenir on se trouve pris à la gorge si un gros contributeur cesse
son soutien, afin de limiter l'impact ou d'avoir d'autres solutions de
secours, quitte à dégrader un peu le service sans nécessairement l'arrêter).

On devrait donc former plus partenariats avec les collectivités, les
organismes publics, les universités et écoles (comme celle où se déroule en
ce moment la FOSSGIS-Europe à Marne-la-Vallée: une école nationale
d'infogéographie a besoin de contenus pour travailler et enseigner et faire
de la recherche et devrait avoir des moyens pour héberger le contenu pour
les régions qui n'en auraient pas les moyens ou la compétence technique
pour le gérer directement, sans qu'elles aient nécessairement à faire appel
à des sociétés privées comme Google trop souvent).

Les collectivités peuvent s'entraider, partager des moyens, des équipes
techniques, des capacités de calcul et de stockage. Elles sont nombreuses à
avoir des besoins sur le cloud, et ont besoin de compétences techniques
pour sécuriser et péréniser le tout et ça demande une veille active.
Souvent il leur faut passer des marchés publics avec des sociétés privées,
mais il vaut mieux qu'elles conservent le contrôle plutôt que de créer des
concessions de service qui ensuite vont faire payer cher leurs services
pour tout le monde et mettre des tas de restrictions d'usage ou filtrer les
données mises à disposition et multliplier les procédures et coûts pour la
moindre modification qui ne serait pas dans leur contrat de concession
initiale.

Si on fait des concessions privées, la collectivité ne fera que supporter
les coûts, mais ne tirera aucun bénéfice alors que ces concessions
monétiseront un maximum les données sans rien donner de plus en échange. Et
la reprise par les collectivités des concessions est une opération couteuse
et lourde, difficile à faire juridiquement car les contrats sont blindés et
souvent assortis de clauses compensatoires en cas d'interruption
prématurée: les concessionnaires demandent des garanties fortes qu'ils
pourront exploiter les données comme ils le veulent et devenir exploitants
pour tout, et devenir le seul pôle de communication possible avec un
calendrier figé qui ne les obligera jamais plus que ce qui était dans le
marché. La monétisation des concessions par les exploitants est constatée
partout (et rarement dans le sens du service public dont ils ont la charge,
on l'a vu en France comme ailleurs par exemple en Afrique, avec les
concessions sur l'eau, l'assainissement, l'énergie, les routes et
infrastructures, la santé, et même maintenant les taxes, les finances
publiques et la justice, ou même le contrôle comptable et légal de toutes
les autres délégations de service public).



Le 20 juillet 2017 à 13:48, marc marc  a écrit :

> Il faudrait peut-être leur écrire pour demander le taille.
> si osm.fr est limité en bande passante, je pense que cela serrait quand
> même pratique en interne quitte a limiter volontairement la bande
> passante de ce service précis.
> Si le problème est l'espace disque, c'est évidement plus délicat.
> Comment fonctionne le partenariat avec la Fondation Free ?
> l'asso demande au cas par cas de ses besoins ?
> ou c'est figé ?
>
> Le 20. 07. 17 à 11:43, Philippe Verdy a écrit :
> > C'est "dispo" peut-être mais sur demande par mail. Ca veut dire qu'ils
> > n'ont pas les moyens d'héberger un serveur TMS/WMS
> > Peut-être que la Fondation Free a encore des moyens pour héberger ça en
> > ligne. Je ne suis pas convaincu qu'OSM France ait ces moyens car on voit
> > déjà comment on l'espace de stockage et la bande passante sont déjà des
> > problèmes de capacité.
> >
> > Le 20 juillet 2017 à 10:48, David Crochet a écrit :
> > c'est intéressant ?
> > http://www.geonormandie.fr/accueil/les_actualites/
> actualites_de_geonormandie/109_845/lorthophotographie_
> regionale_haute_resolution_de_20152016_est_disponible_
> ___
> Talk-fr mailing list
> Talk-fr@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] orthophoto HR 2016 de normandie

2017-07-20 Par sujet marc marc 
Il faudrait peut-être leur écrire pour demander le taille.
si osm.fr est limité en bande passante, je pense que cela serrait quand 
même pratique en interne quitte a limiter volontairement la bande 
passante de ce service précis.
Si le problème est l'espace disque, c'est évidement plus délicat.
Comment fonctionne le partenariat avec la Fondation Free ?
l'asso demande au cas par cas de ses besoins ?
ou c'est figé ?

Le 20. 07. 17 à 11:43, Philippe Verdy a écrit :
> C'est "dispo" peut-être mais sur demande par mail. Ca veut dire qu'ils 
> n'ont pas les moyens d'héberger un serveur TMS/WMS
> Peut-être que la Fondation Free a encore des moyens pour héberger ça en 
> ligne. Je ne suis pas convaincu qu'OSM France ait ces moyens car on voit 
> déjà comment on l'espace de stockage et la bande passante sont déjà des 
> problèmes de capacité.
> 
> Le 20 juillet 2017 à 10:48, David Crochet a écrit :
> c'est intéressant ?
> 
> http://www.geonormandie.fr/accueil/les_actualites/actualites_de_geonormandie/109_845/lorthophotographie_regionale_haute_resolution_de_20152016_est_disponible_
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet Philippe Verdy 
Le 20 juillet 2017 à 13:03, marc marc  a écrit :

> Le 19. 07. 17 à 13:59, David Crochet a écrit :
> Le 19. 07. 17 à 14:11, Philippe Verdy a écrit :
> > cette redondance (partielle)
> > est encore très pratique pour pas mal de recherches.
> un exemple ?
>

Justement pour réparer quand une relation est cassée. C'est juste
informatif de ce qui pouvait être là avant et évite de sélectionner le
mauvais chemin à reprendre pour réparer les relations cassées.

De plus les requêtes sur les relations parentes d'un chemin ne fonctionnent
pas toujours (le serveur en oublie très souvent dans ses résultats!) ou
sont très lentes. Et il y a encore des moteurs de rendu qui ont besoin de
cette redondance partielle, ne serait-ce que pour représenter les
"pointillés" et aussi parce que certaines frontières sont incomplètes (et
ne seront jamais complètement fermées). Le modèle a encore besoin de cette
redondance partielle.

En revanche pour des relations administratives actuelles (je ne parle pas
des autres types de frontières), il devrait toujours y avoir une relation
fermée: un simple tag admin_level sur un chemin est toujours insuffisant
pour décrire la frontière, c'est toujours une relation qu'on ira chercher.
Reste à savoir comment ces relations sont renseignées et là tu es tombé sur
une relation mal fichue qui n'avait rien à voir avec une frontière mais
très mal taguée voire pas du tout: c'est la conversion de cette relation
qui a entrainé un effet de bord en créant une pseudo-frontière en allant
chercher des tags manquants n'importe où: cela ne devrait jamais avoir
lieu, ce traitement de "compatibilité" devrait être en liste noire pour
certains tags et notamment pour "admin_level" qui ne peut pas être récupéré
s'il n'y a pas un tag "boundary=administrative" correspondant et déjà
présent dans la relation où un admin_level manquerait:

il faudrait modifier l'outil de conversion SQL vers GIS pour qu'il bannisse
la récupération ascendante des tags "admin_level" manquants. Ce type de
traitement a surtout servi pour les multipolygone de landuse (qui ont
normalement été tous nettoyés masivement récemment mais il en réapparaît ça
et là). Tant pis si ça veut dire que certains polygones disparaissent des
rendus ou des recherches faute de tags suffisants. Et tant pis si des
polygones sont incomplets (mal fermés): on peut s'en sortir en "bouchant
les trous" par des segments fictifs mais sans ajouter aucun autre tag ni
chercher à les importer d'autres chemins voisins, et le rendu sera plus ou
moins corrigé partiellement avec des "artefacts" visibles restant près de
ces trous (mais ce type d'anomalie est déjà pris en compte dans les outils
de contrôle qualité qui les recherchent pour les signaler car la plupart
des trous sont maintenant minuscules et pas faciles à débusquer sur la
carte sauf en tombant dessus à un niveau de zoom avancé et à condition que
le rendu soit à jour à ce niveau, ce qui prend du temps)

Mais on a des cas particuliers dans certaines régions où les frontières
sont contestées par plusieurs entités qui se recouvrent partiellement (les
exemples sont en fait nombreux sur la carte du monde et on a même des cas
sur les frontières françaises avec nos voisins, notamment avec l'Italie ou
en outre-mer, bien que là ce soit surtout les frontières maritimes qui sont
beaucoup plus simples et dont les chemins ne servent pas aussi à délimiter
autre chose).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] opening_hours pathologiques

2017-07-20 Par sujet marc marc 
Le 20. 07. 17 à 00:26, osm.sanspourr...@spamgourmet.com a écrit :
> Les magasins de seconde main (mais il y a sûrement d'autres cas) ont des 
> horaires de réception des dons différents des horaires de vente.
> Mettre peut-être artificiellement deux nœuds, un à la réception et 
> l'autre à la vente ?

je n'aurais mis qu'un objet puisqu'il n'y a qu'un "magasin"
avec opening_hours= peu importe ce qu'on peux y 
faire, la porte est ouverte, on peux y rentrer et trouver quelqu'un.
OU avec les heures de la fonction la + utilisée (la vente ?)

opening_hours:give=
avec une note opening_hours:give:note="phone call before" si besoin
Le problème c'est qu'aucune app ne le gérera avant longtemps.
Et nombreuses sont les apps à ne montrer qu'une liste précise de tag.

C'est peut-être plus "utilisable" de mettre l'info uniquement dans une 
note/description dont on peux espérer que le contenu serra affiché à 
l'utilisateur qui consulte le poi.

En me relisant, faire un 2ieme POI style "poubelle de recyclage" serrait 
probablement plus utilisable. avec évidement un tag + positif que 
poubelle pour les dons :) et un indoor=yes pour bien monter qu'il n'est 
qu'un sous-élément du POI général.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] admin_level sur des chemins non fermés

2017-07-20 Par sujet marc marc 
Le 19. 07. 17 à 13:59, David Crochet a écrit :
> si ce chemin fait parti de plusieurs relations, 
> quelle étiquette va  t'il prendre de quel relation ?
Selon moi aucun tag de relation ne devrait être dupliqué sur le chemin.
Le chemin a les tag qui décrivent sa fonction en tant que chemin.
La limite administrative est décrite par les tags sur les relations.
Tu peux toujours et facilement trouver si un chemin est une limite 
administrative (il fait partie d'une relation "boundary")
A l'inverse, trouver les chemins qui n'ont pas de parent décrivant la 
même chose est complexe, voir fin de message-

Le 19. 07. 17 à 14:11, Philippe Verdy a écrit :
> Tu peux penser que taguer les admin_level sur les chemins membres
> est redondant,
Oui je pense que c'est redondant voir même sémantiquement erroné.
Par analogie pour décrire une foret entouré par 4 chemins. la 
description de la forêt est uniquement sur le polygone.
On ne tag par chaque chemin comme étant une chemin+limite de forêt.
Autre analogie, les rues utilisée par une ligne de bus n'ont aucun tag 
disant "ceci est un morceau de ligne de bus no 42". l'info est 
uniquement présente sur la relation.

Le 19. 07. 17 à 14:11, Philippe Verdy a écrit :
> cette redondance (partielle)
> est encore très pratique pour pas mal de recherches.
un exemple ?

Le 20. 07. 17 à 01:50, Jérôme Amagat a écrit :
 > (ce admin_level sur les way en france fait doublon et est inutile car
 > toutes les relations représentant les différent admin_level (commune
 > arrondissement departement...) existent et on peut en déduire pour
 > chaque way quelle frontière c'est. Mais c'est la règle actuellement)
Merci pour ce bon résumé. je n'y toucherais donc pas.

Du coup, une requête basique comme lister le nom de toutes les communes 
est complexe puis que le même tag va à la fois faire ressortir des 
chemins individuels constituant les frontières communales et les petites 
communes décrites par un chemin fermé.
il faut donc lister tous les éléments qui ont le tag.
Il faut en retirer les chemins ayant un tag dupliqué càd si le chemin 
fait partie d'un polygone ayant le même tag.
Idem si le chemin fait partie d'une relation ayant le même tag.
Et c'est insuffisant puis qu'on pourrait avoir une relation de polygone 
ou une relation de relation...
Quelqu'un a déjà ce genre de requête sous le coude ? histoire de ne pas 
réinventer la roue...

Merci pour vos éclaircissements, sans jeux de mot :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Repères de crues

2017-07-20 Par sujet Philippe Verdy 
J'ai malgré tout du mal à savoir comment croiser ces infos publiques avec
des données à caractère personnel, à mois que les dits repères sont
installés sur des immeubles ou propriétés privées dont on chercherait à
connaitre nommément le propriétaire.
Ou alors la phrase s'adresse aux compagnies d'assurances qui chercheraient
à évaluer le risque crue pour tarifer ses services aux résidents de la
zone, donc croiseraient leurs données personnelles avec l'adresse
géolocalisée où se situent ces repères de crues: cet usage n'est pas
interdit mais le gouvernement demanderait indirectement le paiement de
droits sur la licence. Mais est-ce que ces repères de crue sont suffisants
pour évaluer les risques quand les données officielles sont plutôt les
plans publics des zones à risque  et qui sont destinés à être visibles par
tous(l'inondation n'est pas le seul risque)
Et ces repères de crue sont des risques historiques non évalués sur le long
terme, ni sur leur fréquence quand nombre d'entre eux vont dater d'un
siècle et que des travaux ont depuis été réalisés qui déplacent ces
risques. Ils sont là d'abord pour garder en mémoire des faits exceptionnels
pour qu'on en tienne compte dans les nouveaux aménagements.


Le 20 juillet 2017 à 00:42,  a écrit :

> *contenant des informations à caractère personnel *
> Donc pas de soucis pour osm mais potentiellement pour des ré-utilisateurs
> des données ?
>
>
> Le 20/07/2017 à 00:29, Donat ROBAUX - dona...@gmail.com a écrit :
>
> Bonjour à tous,
>
> Je me rappelle avoir vu passer un message concernant les repères de crues.
> En faisant ma cartographie des églises, je suis tombé là dessus:
> https://www.reperesdecrues.developpement-durable.gouv.fr/ (ne me demandez
> pas comment...)
>
> C'est un site participatif avec fond OSM. Les données sont a priori en
> open-data d'après ce que j'ai compris de la licence.
>
>
>
> *Dès lors qu’il respecte les conditions décrites supra, le ré-utilisateur
> est autorisé à :  - reproduire, copier, publier et transmettre «
> l’Information » ;  - diffuser et redistribuer « l’Information » ;
>  - adapter, modifier, extraire et transformer à partir de «
> l’Information », notamment pour créer des « Informations dérivées » ;*
>
> Une phrase me laisse toutefois songeur: *Cependant, tout croisement des
> informations contenues sur le
> site www.reperesdecrues.developpement-durable.gouv.fr
> , en particulier
> de la géolocalisation des repères de crues, avec d’autres bases de données
> contenant des informations à caractère personnel telles que définies par la
> CNIL est formellement interdit.*
>
> Donat
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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

[OSM-talk-fr] articles OSM dans Géomatique Expert

2017-07-20 Par sujet Benoit Fournier 
http://www.geomag.fr/revue/geomatique-expert-n117-juillet-2017

Le dernier numéro de Géomatique Expert fait la part belle à
OpenStreetMap, l'Open Data et l'Open Source avec de grands articles.

Au sommaire :

- La conférence 2017 State of the Map France
- Des outils Python pour mesurer la qualité des données OSM
- Une brève histoire d’Inspire
- Open data et tourisme
- Le point sur QGis et d’autres projets

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

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

2017-07-20 Par sujet Philippe Verdy 
C'est "dispo" peut-être mais sur demande par mail. Ca veut dire qu'ils
n'ont pas les moyens d'héberger un serveur TMS/WMS et que ce sont juste des
collections archivées de photos juste hébergé sur un serveur à faible
capacité.
Ca ressemble à un appel à contribution pour héberger le TMS/WMS... Ca
viendra sans doute d'une société commerciale existante qui voudra en avoir
une copie (du genre de DigitalGlobe ou même Google et Bing...). Il aurait
été intéressant que la région normande aille voir si cela intéressait une
université de la région (ou d'une région voisine comme l'IRISA Bretagne) ou
un service de l'Etat (IGN, Meteo France...) ou européen (le CERN a de très
gros moyens de stockage et de réseau, une orthophoto normande est un volume
ridicule par rapport à ce qu'ils génèrent en données et consomment en
réseau).
Peut-être que la Fondation Free a encore des moyens pour héberger ça en
ligne. Je ne suis pas convaincu qu'OSM France ait ces moyens car on voit
déjà comment on l'espace de stockage et la bande passante sont déjà des
problèmes de capacité.

Le 20 juillet 2017 à 10:48, David Crochet  a écrit :

> Bonjour
>
> c'est intéressant ? http://www.geonormandie.fr/acc
> ueil/les_actualites/actualites_de_geonormandie/109_845/
> lorthophotographie_regionale_haute_resolution_de_20152016_est_disponible_
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] orthophoto HR 2016 de normandie

2017-07-20 Par sujet David Crochet 

Bonjour

c'est intéressant ? 
http://www.geonormandie.fr/accueil/les_actualites/actualites_de_geonormandie/109_845/lorthophotographie_regionale_haute_resolution_de_20152016_est_disponible_


Cordialement

--
David Crochet


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