Re: [OSM-talk-fr] Intégration des monuments historiques dans Osm

[osm . sanspourriel]

Un bon point de départ qui fait penser à l'intégration de FANTOIR.

Avec un peu les mêmes défauts.

Je ne reviens pas sur le gros plus ;-).

Pour l'intégration j'ai juste fait un test sur un cas (le premier du 
Finistère)


L'outil propose :

 * ref:mhs=PA00089823
 * wikidata=Q3583603
 * heritage:operator=mhs
 * heritage=2
 * mhs:inscription_date=1914-11-12
 * wikipedia=fr:Église Saint-Pierre-et-Saint-Paul d'Argol
 * name=Eglise Saint-Pierre et Saint-Paul
 * source:heritage=data.gouv.fr, Ministère de la Culture - 2016

Intéressant.
Si je clique sur le lien import JOSM, je vois (comme je m'en doutais) 
que l'église était déjà dans OSM.

Donc par défaut ça fait un doublon.
Il faudrait qu'à proximité on cherche un objet ayant ces caractéristiques.
Je vois qu'il existe une Église Saint-Pierre-et-Saint-Paul.
C'est à cette église que je veux ajouter les données (et avoir le choix 
pour les conflits, ici l'accent est bon dans OSM, quant aux tirets, je 
ne suis pas spécialiste en bondieuserie, Jean-Louis ou JB sauront mieux 
les usages, idéalement pour les conflits, l'outil nous aide (règles sur 
les majuscules, les accents, les tirets ici pour les lieux de culte).
Comme tout le bâti est intégré (enfin presque), il est probable que 
l'objet soit déjà dans OSM.


Soit on arrive à le trouer soit on propose à l'utilisateur de le 
sélectionner.


Ici j'ai sélectionné l'objet OSM et celui créé par WOM, utilisé le 
comparateur d'attribut JOSM et ajouté les attributs manquants. Vu la 
manip, j'en ai raté (et modifié à nouveau).


Idéalement (mais je ne sais si l'interface JOSM le permet), l'ensemble 
des modifications indiquerait comme source :
Mérimée:2016 (ou source:heritage=data.gouv.fr, Ministère de la Culture - 
2016), pas la modification individuelle.


Mais pourquoi ne pas se baser sur Osmose ? Il faudrait mettre les 
différents développeurs dans une pièce et ne les laisser sortir que 
quand ils se sont mis d'accord sur quelques outils :-D.
A minima avoir un point d'entrée (le Wiki ?) pour savoir quel-s outil-s 
sont à disposition.

Et si possible une interface permettant de passer d'un outil à l'autre.
Ici si on est sur Osmose, la page 
http://wom.jearro.fr//D/29_pages/29_merwip.html peut être déduite (sauf 
erreur) par la position (29 = Finistère). Dans l'autre sens latitude et 
longitude estimées sont utilisables.


Second essai : je vais voir ce qui cloche.
Tour Vauban : c'est PA00089855, pas IA29001320 
, 
trouvé depuis 
http://www.culture.gouv.fr/public/mistral/mersri_fr?ACTION=RETROUVER_1=TOUT_1=_2=localisation_2=Camaret%2dsur%2dMer_3=titre_3=_4=description_4=_5=historique_5=_6=date%20protection_6=_7=propri%e9t%e9_7=_8=type%20d%27%e9tude_8=_9=REF_9=_10=DOSURLP_10=%20=1=0=%28%28Camaret%2dsur%2dMer%29%20%3aLOCA%20%29=nobody=4%24%2534P=9=1==1=100=100=Tous 
(grâce au lien faux ;-)).
Que faire ? corriger la référence ? Est-ce que l'outil me proposera 
d'ajouter les attributs manquants ou une réf lui suffit-il ?
Tiens je crois avoir trouvé un tag nord-finistérien (ou plutôt du Pays 
de Brest) : Url:Merimee :

http://overpass-turbo.eu/s/jhR
Étonnant non ?

Toujours sur http://wom.jearro.fr//D/29_pages/29_osmwip.html et grâce à 
http://www.culture.gouv.fr/public/mistral/mersri_fr?_1=TOUT_1=XXX_2=localisation_2=_3=titre_3=_4=description_4=_5=historique_5=_6=date%20protection_6=_7=propri%e9t%e9_7=_8=type%20d%27%e9tude_8=_9=REF_9=_10=DOSURLP_10=%20=nobody=4%24%2534P_SPECIFIC=9_ONLY=_SYNONYMOUS=1=RETOUR 
ou XXX est le nom dans OSM :

:
PA00090049 Château de Trémazan
Pour les autres entrée erronées, que faire ? Il semble que la personne 
se soit basée sur une base de données régionale (incorrecte ?). Essayer 
de contacter cette personne ? Allez, je contacte Fvig.


Le manoir de Saint-Pol-Roux n'apparaît pas (Manoir de Boultous sous 
OSM), les autres non plus mais il fait partie du patrimoine culturel de 
Bretagne. Et je ne vois pas de référence Mérimée sur ce site.


http://patrimoine.region-bretagne.fr/gertrude-diffusion/recherche/globale?texte=%22Manoir+de+Boultous%22

Ou si vous préférez un fond OpenStreetMap :

http://patrimoine.region-bretagne.fr/gertrude-diffusion/recherche/globale?texte=%22Manoir+de+Boultous%22=Saint-Pol-Roux=carte

Jean-Yvon


Le 12/10/2016 à 13:09, jean navarro - jean.nava...@laposte.net a écrit :

Bonjour

  Suite à une rencontre entre mappeurs lyonnais et fans de 
wikipédia, j'ai commis un site web qui montre comment les monuments 
historiques de la base ouverte Mérimée (data.gouv) sont intégrés dans 
les bases wikipédia et OSM.
L'idée de départ était de répondre à la question : "Si je veux 
intégrer les monuments historiques, dans mon secteur, que dois-je 
faire, par où commencer ?"
 Avec ces pages, pour l'Ain par exemple, on voit qu'il reste un 
travail sur la ville de Pérouges... aller sur le terrain et essayer de 
différencier les maisons classées.


Maintenant la France entière est couverte 

Re: [OSM-talk-fr] enforcement et """zone dangeureuse"""

[willemijns]

Hello, ou je rajoute ces infos additionnelles ? c'est ca que j'ai pas
compris...

On Wed, Oct 12, 2016, at 14:39, Gnrc [via GIS] wrote:
> 
> 
> Hello 
> ta maniere de taguer est bonne : il faut bien indiquer dans les rôles
> "device", "from" et 
> "to". Il est toutefois possible de ne pas mentionner "to" si le radar est
> directement tagué sur le way, dans ce cas "device" s'y substitue. Nota:
> je prefere mettre la radar a coté de la chaussée, cela evite de le perdre
> en cas d'effacement de la route. 
> 
> Par contre, comme sur les autres exemples que tu cites, il est
> interessant d'ajouter : 
> enforcement=maxspeed 
> maxspeed=?? 
> name=ce-que-tu-veux(pour le reconnaitre en cas d'extraction de jeux de
> donnees osm) 
> description=ce-que-tu-juge-bon 
> 
> mon exemple
> http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=1329409 
> 
> Bon tagging 
> 
> 
> - Mail original -
> 
> De: "willemijns"  
> À: talk-fr@openstreetmap.org 
> Envoyé: Mardi 11 Octobre 2016 22:33:05 
> Objet: [OSM-talk-fr] enforcement et """zone dangeureuse""" 
> 
> Hello, 
> 
> J'ai affiné ce r*dar oups """zone dangeureuse""" dans la relation en URL 
> http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=6626221 mais
> il 
> semble avoir quelque chose qui cloche car un autre du même genre plus
> ancien 
> et qui n'est pas de moi indique plus de tag comme 
> http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=1631275 
> 
> j'ai lu qu'il fallait mettre en relation enforcement du "device", "from"
> et 
> "to" et tous les anciens n'ont pas de "to" c'est cela qui foire ??? 
> 
> 
> 
> -- 
> View this message in context:
> http://gis.19327.n8.nabble.com/enforcement-et-zone-dangeureuse-tp5884188.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
> 
> 
> 
> 
> ___
> If you reply to this email, your message will be added to the discussion
> below:
> http://gis.19327.n8.nabble.com/enforcement-et-zone-dangeureuse-tp5884188p5884228.html
> 
> To unsubscribe from enforcement et """zone dangeureuse""", visit
> http://gis.19327.n8.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code=5884188=c2ViYXN0aWVuQHdpbGxlbWlqbnMuY29tfDU4ODQxODh8LTUxNTYyNDE4Mw==




--
View this message in context: 
http://gis.19327.n8.nabble.com/enforcement-et-zone-dangeureuse-tp5884188p5884249.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] Nouvelle interface Osmose

[osm . sanspourriel]

Le 12/10/2016 à 11:43, Vincent Bergeot - vinc...@bergeot.org a écrit :

Bonjour,

Le 11/10/2016 à 22:06, Nicolas Bétheuil a écrit

En regardant le pad, j'avoue ne pas forcément réussir à comprendre ce 
dont on parle.


Peux tu préciser ?


Je pense que Nicolas trouve qu'on parle jargon.
QA : Assurance Qualité (Quality Assurance en étranger).
C'est la partie qui utilise des règles pour savoir si les données 
entrées sont conforme au modèle de données OSM.
Par exemple en France un nom de commune ne comporte pas d'espace (mais 
des tirets quadratins).
L(objet est donc de faciliter les corrections (ou de signaler les faux 
positifs - exceptions à la règle par exemple).


OD : Données Ouvertes (Open Data en étranger ;-))
Le but est de compléter OSM (ou pourquoi pas la base de données 
ouvertes). Par exemple les sites de pratiques sportives, les 
boîtes-aux-lettres : des données sont connues d'OSM, d'autres de la base 
en question. L'outil doit aider à comparer les deux sources et proposer 
le meilleur des deux mondes (ce qui n'est pas trivial : par exemple le 
positionnement des boîtes-aux-lettres de la Poste peut être déplorable, 
certaines fois c'est une aide pour trouver les bàl manquantes, les noms 
sont SOUVENT EN MAJUSCULES voir sans lettres accentuees contrairement 
aux usages mais il se peut que le NOM EN MAJUSCULES NON ACCENTUEES soit 
plus complet que le nom OSM).


Toute l'interface est à repenser pour être plus ergonomique.
Si les propositions c'est de l'hébreu ou du chinois, simple à toi de 
faire une contre-proposition à partir d'une page blanche. Nouveau 
contributeur de la liste de discussion, tu n'es pas "pollué" par nos 
habitudes.

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

Re: [OSM-talk-fr] Différence affichage cadastre iD/jOSM

[Philippe Verdy]

C'est là que je pense qu'il aurait mieux valu que les serveurs de tuiles
sachent faire une combinaison des images acoolées, par un algo relativement
simple de filtrage, superposant deux images orthorectifiées polygonales su
un fond fond, en conservant le contraste maximum des deux images asemblées.

Là ça affiche un morceau d'une image ou un morceau de l'autre selon la
position du point central qui varie quand on zoome, et même bouge quand on
glisse la carte à l'écran... ce n'est franchement pas pratique.
La superposition aurait fait apparaitre des traits en double par endroit
(sans conflation, mais on se serait arrangé pour faire une conflation
visuelle).

En comparaison le cadastre espagnol lui fournit des images précombinées
(sans tenir compte des limites des planches qui ne conicident pas avec les
limites des tuiles) et n'a pas besoin qu'on fixe une commune particulière,
et c'est nettement plus facile à utiliser

Et ça évite aussi qu'on traailel sur les données d'une seule commune sans
tenir compte de la commune voisine quand la conflation n'a pas réellement
eu lieu: visuellement là aussi une conflation manuelle suffit et les
espagnols ne sont pas non plus tombés dans le piège des imports
automatiques qui en France ont déjà produit des doublons un peu partout, ou
donné lieu à des modifications incohérentes dans le sens d'une commune ou
dans le sens de sa voisine...

...alors qu'en terme de précision réelle il n'y a pas de différence
significative entre une planche ou l'autre et que la conflation manuelle
permet aussi de s'accorder avec d'autres sources, et notamment une imagerie
aérienne, afin d'obtenir une carte géométriquement cohérente avec les
proportions relatives et orientations localement respectées:

Dans tous les cas on reste dans les marges d'erreurs de chacune des sources
utilisées, et la comparaison des sources avec une conflation visuelle
manuelle permet même d'obtenir des données en fin de compte plus précises
que chacune des sources originales prises individuellement: ceci est un
réel bonus que permet OSM, où justement on demande un travail de
préparation et de fusion et non un import brut: toutes les sources qu'on
utilise ont de toute façon des marges d'approximation et notre travail est
justement de les apprécier car on s'appuie sur plus de données ainsi que
sur l'expérience de terrain, où les sources officielles disponibles ne
seront pas à jour avant longtemps.

Je ne critique pas ici les sources du fait de ce qu'ont y trouve pas, elles
ont chacune leurs limites, elles sont utiles pour avoir cependant des vues
assez détaillées et les plus exhaustives possibles, mais on doit tenir
compte du fait que les imprécisions sont un état de fait, d'autant plus que
la montée en précision ne se fait pas du jour au lendemain et reste un
patient travail qui restera toujours à réviser plus tard. On a voulu un OSM
précis au plan local pour y mettre des tas dedonénes que pleins de sources
ne cherchent pas à codifier, c'est à nous de trouver de la cohérence,
aucune source n'a une géométrie absolue (hormi les rares points de
référence géodésiques, qui cependant eux aussi feront l'objet de révisions
quelques 10 ou 20 ans plus tard, dans le cadre d'un nouveau schéma de
triangulation et de nouvelles méthodes de calcul).

Je pense même qu'OSM peut aussi aider chacune des sources à trouver les
points de désaccord car on fournit d'autres points identifiables qui
peuvent servir à ces sources pour réviser leurs propres données. Elles ne
sont pas obligées non plus de reprendre nos données à la lettre, cahcun
apprécie en fonction des données qu'il a à gérer et de ses besoins
(d'autant plus que nous non plus on n'a pas accès à tout ce que peuvent
utiliser les collectivités en dehors de ce qui est dans le cadastre public:
on ne voit pas des tas de plans récents liés au travaux de terrain des
géomètres et aux plans de marchés publics on n'a pas le détail des permis
de construire, pas les études d'architectes, pas non plus des tas d'études
géologiques ni les relevés internes des exploitants de réseaux: chacun fait
de son mieux avec les données qu'il a et tout le monde s'adapte
progressivement)


Le 12 octobre 2016 à 16:43, Tyndare  a écrit :

>
> iD et JOSM n'utilisent pas la même source de donnée pour déterminer la
> liste des images disponibles par défaut selon la région affichée mais j'ai
> l'impression que la définition pour les tuiles du cadastre utilisent
> pourtant bien le même serveur TMS:
> http://tms.cadastre.openstreetmap.fr/*/tout/{zoom}/{x}/{y}.png
>
> Comme expliqué à l'origine par Frédéric Rodrigo, pour éviter les problèmes
> de saut aux frontières, il est possible de n'afficher les tuiles que d'une
> seule commune en particulier en spécifiant dans l'éditeur un serveur
> personnalisé qui utilise l'URL précédant dans lequel on remplace le * par
> le code INSEE de la commune voulue:
>
> https://lists.openstreetmap.org/pipermail/talk-fr/2015-Febru
> ary/075223.html
>
> Je crois que la 

Re: [OSM-talk-fr] enforcement et """zone dangeureuse"""

[Christian Quest]

name sert à nommer, pas à décrire...

Ici ce "name" est en fait la localisation géographique, que l'on a par 
la géométrie des objets (via un géodage inversé), ça pourrait être un 
"is_in" qui lui aussi est devenu relativement obsolète depuis qu'on a 
l'intégralité des découpages administratifs.



Le 12/10/2016 à 16:20, Romain MEHUT a écrit :
Le 12 octobre 2016 à 14:38, > a écrit :


Hello
ta maniere de taguer est bonne : il faut bien indiquer dans les
rôles "device", "from" et
"to". Il est toutefois possible de ne pas mentionner "to" si le
radar est directement tagué sur le way, dans ce cas "device" s'y
substitue. Nota: je prefere mettre la radar a coté de la chaussée,
cela evite de le perdre en cas d'effacement de la route.

Par contre, comme sur les autres exemples que tu cites, il est
interessant d'ajouter :
enforcement=maxspeed
maxspeed=??
name=ce-que-tu-veux(pour le reconnaitre en cas d'extraction de
jeux de donnees osm)


Pas d'accord pour un "name" si rien de visible ou connu ne permet 
effectivement de lui attribuer un nom.


description=ce-que-tu-juge-bon

mon exemple
http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=1329409



Dans cet exemple, le "name" n'a donc bien aucun sens pour l'objet visé.

Romain


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



--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Différence affichage cadastre iD/jOSM

[Tyndare]

iD et JOSM n'utilisent pas la même source de donnée pour déterminer la 
liste des images disponibles par défaut selon la région affichée mais 
j'ai l'impression que la définition pour les tuiles du cadastre 
utilisent pourtant bien le même serveur TMS:

http://tms.cadastre.openstreetmap.fr/*/tout/{zoom}/{x}/{y}.png

Comme expliqué à l'origine par Frédéric Rodrigo, pour éviter les 
problèmes de saut aux frontières, il est possible de n'afficher les 
tuiles que d'une seule commune en particulier en spécifiant dans 
l'éditeur un serveur personnalisé qui utilise l'URL précédant dans 
lequel on remplace le * par le code INSEE de la commune voulue:


https://lists.openstreetmap.org/pipermail/talk-fr/2015-February/075223.html

Je crois que la configuration par défaut pour JOSM est définie ici:
https://josm.openstreetmap.de/wiki/Maps/France#Cadastre

et que celle pour iD est définie ici:
https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/fr/FR-Cadastre.geojson



On 12/10/2016 12:01, David Marchal wrote:

Bonjour à tous.

Question idiote : pourquoi l'affichage du cadastre est-il aussi propre sur iD, 
alors que, sur jOSM, il est tout moche : noms tronqués, tracé de limites 
sautant sans arrêt… L'affichage d'iD n'est pas irréprochable, mais il me semble 
bien meilleur que celui de jOSM, alors pourquoi ne pas utiliser le même serveur 
de tuiles ?

Dans l'attente de vos lumières,

Cordialement.
___
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] enforcement et """zone dangeureuse"""

[Romain MEHUT]

Le 12 octobre 2016 à 14:38,  a écrit :

> Hello
> ta maniere de taguer est bonne : il faut bien indiquer dans les rôles
> "device", "from" et
> "to". Il est toutefois possible de ne pas mentionner "to" si le radar est
> directement tagué sur le way, dans ce cas "device" s'y substitue. Nota: je
> prefere mettre la radar a coté de la chaussée, cela evite de le perdre en
> cas d'effacement de la route.
>
> Par contre, comme sur les autres exemples que tu cites, il est interessant
> d'ajouter :
> enforcement=maxspeed
> maxspeed=??
> name=ce-que-tu-veux(pour le reconnaitre en cas d'extraction de jeux de
> donnees osm)
>

Pas d'accord pour un "name" si rien de visible ou connu ne permet
effectivement de lui attribuer un nom.


> description=ce-que-tu-juge-bon
>
> mon exemple http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=
> 1329409
>

Dans cet exemple, le "name" n'a donc bien aucun sens pour l'objet visé.

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

Re: [OSM-talk-fr] enforcement et """zone dangeureuse"""

[gnrc]

Hello 
ta maniere de taguer est bonne : il faut bien indiquer dans les rôles "device", 
"from" et 
"to". Il est toutefois possible de ne pas mentionner "to" si le radar est 
directement tagué sur le way, dans ce cas "device" s'y substitue. Nota: je 
prefere mettre la radar a coté de la chaussée, cela evite de le perdre en cas 
d'effacement de la route. 

Par contre, comme sur les autres exemples que tu cites, il est interessant 
d'ajouter : 
enforcement=maxspeed 
maxspeed=?? 
name=ce-que-tu-veux(pour le reconnaitre en cas d'extraction de jeux de donnees 
osm) 
description=ce-que-tu-juge-bon 

mon exemple http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=1329409 

Bon tagging 


- Mail original -

De: "willemijns"  
À: talk-fr@openstreetmap.org 
Envoyé: Mardi 11 Octobre 2016 22:33:05 
Objet: [OSM-talk-fr] enforcement et """zone dangeureuse""" 

Hello, 

J'ai affiné ce r*dar oups """zone dangeureuse""" dans la relation en URL 
http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=6626221 mais il 
semble avoir quelque chose qui cloche car un autre du même genre plus ancien 
et qui n'est pas de moi indique plus de tag comme 
http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=1631275 

j'ai lu qu'il fallait mettre en relation enforcement du "device", "from" et 
"to" et tous les anciens n'ont pas de "to" c'est cela qui foire ??? 



-- 
View this message in context: 
http://gis.19327.n8.nabble.com/enforcement-et-zone-dangeureuse-tp5884188.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

[OSM-talk-fr] Intégration des monuments historiques dans Osm

[jean navarro]

Bonjour

  Suite à une rencontre entre mappeurs lyonnais et fans de 
wikipédia, j'ai commis un site web qui montre comment les monuments 
historiques de la base ouverte Mérimée (data.gouv) sont intégrés dans 
les bases wikipédia et OSM.
L'idée de départ était de répondre à la question : "Si je veux intégrer 
les monuments historiques, dans mon secteur, que dois-je faire, par où 
commencer ?"
 Avec ces pages, pour l'Ain par exemple, on voit qu'il reste un 
travail sur la ville de Pérouges... aller sur le terrain et essayer de 
différencier les maisons classées.


Maintenant la France entière est couverte avec un classement départemental.

Ces pages proposent aussi quelques outils d'intégration dans OSM pour 
les codes wikidata des monuments et sur la page "Mérimée, Wp", un lien 
caché "Tags pour OSM" qui ouvre une fenêtre avec les tags qui vont bien.


donc à voir :
http://wom.jearro.fr


vos commentaires et contributions seront bienvenus.


cordialement
JeaRRO
http://wiki.openstreetmap.org/wiki/User:JeaRRo

ps : il y a des villes qui ne sont pas encore traitées : pages wikipédia 
non standard


La base mérimée : 
http://www.data.gouv.fr/fr/datasets/monuments-historiques-liste-des-immeubles-proteges-au-titre-des-monuments-historiques/


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

[OSM-talk-fr] Différence affichage cadastre iD/jOSM

[David Marchal]

Bonjour à tous.

Question idiote : pourquoi l'affichage du cadastre est-il aussi propre sur iD, 
alors que, sur jOSM, il est tout moche : noms tronqués, tracé de limites 
sautant sans arrêt… L'affichage d'iD n'est pas irréprochable, mais il me semble 
bien meilleur que celui de jOSM, alors pourquoi ne pas utiliser le même serveur 
de tuiles ?

Dans l'attente de vos lumières,

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

Re: [OSM-talk-fr] Nouvelle interface Osmose

[Vincent Bergeot]

Bonjour,

Le 11/10/2016 à 22:06, Nicolas Bétheuil a écrit :

Bonsoir,

Je suis nouveau sur la ml. J'ai déjà un peu contribué à osm, par 
l'interface web ou encore par josm.
Je me demandais ce qui pourrais m'aider en tant que contributeur pour 
ajouter des points qui viennent de source de données en open data, 
parfois volumineuse (plusieurs centaines voir milliers de points), 
bien qualifiée avec des coordonées.
J'avais commencé à prendre l'exemple du jeux de données sur les points 
de collecte de verre à paris 
(http://opendata.paris.fr/explore/dataset/mobilierpropreteparis2011/). 
Il y en a plusieurs, mais ce sont tous les mêmes.
De façon à ce que chaque contributeur puisse ajouter au grès de ses 
balades ou repérage, il faudrait qu'il puisse juste confirmer des 
points existants. En regardant mapcontrib, le jeux de données semble 
n'être que dans la session utilisateur. Est-ce exact ?


non, voici un thème avec une couche avec les données ouvertes par la 
ville et une requête overpass sur amenity=recycling : 
https://www.mapcontrib.xyz/t/e899ed-OD_point_de_collecte_a_verre_Paris


Ce n'est pas satisfaisant en terme de lisibilité mais cela permet de 
jeter quand même un oeil dessus.


Et je ne pense pas que cela soit le boulot de mapcontrib mais si il peut 
(mal) le faire. Un des objectifs est plutôt de pouvoir intégrer dans un 
thème mapcontrib les résultats d'osmose et donc de viser plutôt ce dont 
tu parles, une intégration facilitée lors de sortie terrain (sur github, 
lien avec osmose : 
https://github.com/MapContrib/MapContrib/issues?q=is%3Aissue+is%3Aopen+osmose+label%3Aapp%3Aosmose)


En regardant le pad, j'avoue ne pas forcément réussir à comprendre ce 
dont on parle.


Peux tu préciser ?




Ce que j'imaginerais comme interface, dans un premier temps bien sur, 
en fonction de la geoloc du smartphone, t'es pas loin, donc tu peux 
dire si le poi existe ou pas, ce qui l'ajouterais à osm.
La complexité que je ne résous pas est de fusionner les points déjà 
référencés ou de supprimer les points n'existant plus.


c'est effectivement ce que sait faire osmose, si le fichier de données 
ouvertes lui a été déclaré.
Par exemple les données ouvertes de nantes et bordeaux métropole ont été 
"déclarées" et osmose sait dire :


 * présents dans osm et la base de données ouvertes par la collectivité
 * présents dans osm mais pas dans la base
 * présents dans la base mais pas dans osm

Et en fonction de proposer des intégrations.

Exemple ici : 
http://osmose.openstreetmap.fr/fr/map/#item=8121=6=46.4=3.69=Mapnik=T





Qu'en pensez vous ?



Beaucoup de bien car cela rejoint des besoins pour plusieurs personnes :)

au plaisir







Le 10 octobre 2016 à 09:41, Guillaume AMAT > a écrit :


Salut,

À tous, merci pour vos retours et Florian, merci pour ta proposition.

Frédéric, j'ai vu passer cette issue effectivement. Je pense aussi
qu'il faut remplacer les popups par des colonnes, plus pratiques à
l'usage.

Aussi, que penses-tu de l'interface destinée aux producteurs de
données qu'évoque Florian ? Tu penses que certains s'en empareront ?

Je suis en train de terminer un gros boulot sur MapContrib. Après
ça je m'attaque aux premiers jets de maquettes. En attendant, j'ai
ouvert un pad pour y placer les idées/besoins et modeler tout ça
ensemble :
https://semestriel.framapad.org/p/refonte-interface-osmose


À bientôt,
Guillaume



Le 09/10/2016 à 11:28, Frédéric Rodrigo a écrit :

Salut tout le monde,

À noter qu'il y a également une issue sur le github :
https://github.com/osm-fr/osmose-frontend/issues/40


Frédéric.


Le 29/09/2016 à 14:25, Florian LAINEZ a écrit :

Salut Guillaume,
Je suis très intéressé pour travailler avec toi sur
l'évolution de l'interface d'osmose.
Avec Loic de chez Jawg nous avions esquissé une
proposition qui va dans le même sens.

L'idée était, tout comme tu le suggères, de créer une
interface spéciale "open data" pour permettre aux
producteurs de données de comparer leur jeux de données
avec la donnée OSM.
Voici ce qu'il en était ressorti :


---
Besoin :

1. Un outil de QA permettant de comparer les données en
Open Data aux données OpenStreetMap.
 - Une partie située sur une carte pour les données
géolocalisées
 - Une partie sous forme de liste pour des données
numériques (% données manquantes, erreurs etc...)

2. Enrichir cet outil pour les contributeurs, en leur
permettant de contribuer les modifications directement
dans la page, après s'être loggés