Re: [OSM-dev-fr] Beta Osmose Leaflet

[Frédéric Rodrigo]

Normalement on a tout pris en compte, tu peux nous confirmer que c'est bon.
Le select sur mobile est également corrigé.

Frédéric.

Le 24/02/2014 12:18, didier2020 a écrit :

Le lundi 24 février 2014 à 11:36 +0100, Frédéric Rodrigo a écrit :

Le 24/02/2014 09:07, didier2020 a écrit :

+1 pour la possibilité de recherche de lieu
+1 pour le "truc" qui s'anime pour faire patienter
+ pour la sélection des calques, je préfère une action clic sur le
bouton layer qui ouvre et ferme plutôt que le survol ( c'est juste une
préférence)


Test sous linux/chromium (version libre de chrome):
- l'animation ne fonctionne pas et les "Osmose error" n'apparaissent pas

Je ne constate pas ce problème avec le dernier linux/chromium.
Tu peux confirmer que ce n'était pas juste temporaire ? On a des doutes
sur la capacité du serveur a répondre tout le temps en temps raisonnable
pour une utilisation interactive de Osmose.

autant pour moi, mon premier essai était sur debian 6.
Avec debian 7 / Chromium et Iceweasel (FF libre) fonctionnent comme sous
windows.
Avec debian 6 / Firefox 64 fonctionne comme sous windows.


Test sous seven/firefox+ie7+chrome:

- pour la sélection des erreurs (tout-rien-inverser) :
inverser agit sur les calques (pas les "layers" de base, mais les
autres)

On avait ce problème au début partout, mais je ne vois plus d'où ça peut
venir, et en plus spécifique à une plateforme.

cf ci-dessus, ce n'est pas spécifique a une plateforme.


Tu peux cibler un peu
plus s'il te plait ?



clic sur inverser :
- cela ajoute un "#" dans la barre d'adresse.
- la selection des layers "secondaire" s'inverse
- la selection de la gravité ne fonctionne plus correctement tant qu'on
laisse le "#" dans la barre d'adresse
clic sur "tout" ou "rien" n'a pas d'influence sur ces memes layers.




- l'animation pour patienter ne se voit pas si on sélectionne uniquement
le layer 'Osmose error heatmap"

Ça c'est normal, elle n'est là que pour les marqueurs.


- permalink :
je clique sur permalink => ok dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...)
=> clic sur permalink ne fait rien apparaitre dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...) ET
modification d'item
=> clic sur permalink ne fait pas apparaitre la localisation
(lat,lon,zoom) dans la barre d'adresse

ok, vu.

Merci de ton retour


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



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



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

Re: [OSM-dev-fr] Beta Osmose Leaflet

[Frédéric Rodrigo]

Super merci, c'est bien ça. Tout et rien avait été corrigé mais pas 
inverser.



Le 24/02/2014 15:33, didier2...@free.fr a écrit :

piste? : il n'y a pas de notion de parent coté menu ou coté layer ?

  // Invert item check
   _invertAllItem: function () {
 $("input[type='checkbox']").each(function () {

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



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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[Christian Quest]

Le 24 février 2014 14:37, V de Chateau-Thierry  a écrit :

> > De : "Christian Quest"
> >
> > Après ma rencontre chez médipost où on a beaucoup parlé d'adresses, je
> suis arrivé à la
> > conclusion que lorsqu'on parle d'adresse, on ne parle pas tous de la
> même chose... d'où
> > le problème pour avoir un consensus.
> >
> > Un seul modèle ne peut donc répondre à toutes les facettes de ce que
> peut être une
> > adresse ou alors il faut que ce soit un modèle extensible. Justement...
> OSM fonctionne
> > sur ce principe d'extensions.
> >
> > Il faudra sûrement aller plus loin que le modèle actuel pour que tout le
> monde y trouve
> > son compte.
> >
> > Alors de quoi parle-t-on ?
> >
> > - de parcelles
> > - de bâtiments
> > - de plaques adresse
> > - d'accès depuis la voirie la plus proche
> > - de point plus "métier": position de la boite aux lettres, du compteur
> EDF/eau, des
> > entrées, de la livraison...
> > autre ?
>
> D'accord avec cette pluralité. Dans la liste que tu dresses, un seul
> élément nous est
> systématiquement fourni par des sources simples d'accès (cadastre, bing),
> c'est le
> bâtiment.



Euh... le cadastre indique plutôt l'équivalent des plaques et seules les
plaques sont vérifiables sur le terrain... d'où mon double penchant pour
favoriser ce modèle là.



> D'où ma conviction, déjà exprimée ici dans un fil précédent, que c'est
> le(s)
> bâtiment(s) qui doit se faire l'étendard de l'info d'adresse.
>

Tu vois ça commence déjà... le ou les ?  ;)


Une précision cependant : en discutant sur la manière de modéliser, je ne
> pense quasi pas
> à ce que chacun voudra faire sur un terrain qu'il peut arpenter en piéton,
> qu'il peut
> scruter, affiner, détailler. Chacun chez soi saura mapper les adresses aux
> petits
> oignons, par justement la possibilité de positionner les accès piéton et
> voiture, les
> portes d'entrée, les boîtes aux lettres, etc.
> Je discute ici plutôt d'un modèle minimal que chacun serait à même
> d'appliquer sur des
> territoires où il contribue sans les connaître, un peu comme il arrive
> qu'on fasse un
> import de bâti sur un patelin où on n'a jamais mis les pieds. C'est un mal
> nécessaire
> si on veut que l'adresse devienne un matériau utilisable dans OSM car
> suffisamment
> répandu.
>
>

Je pense qu'il faut trouver un juste milieu entre une modélisation de base,
simple, vérifiable sur le terrain, puis un modèle plus complet où chaque
adresse peut avoir plus de détails (les bâtiments à défaut d'avoir la
parcelle qui engloberait tout les bâtiments qui sont dessus), les entrées,
BAL, compteurs divers... et là à moins d'avoir un polygone englobant comme
la parcelle je crois qu'on est bon pour une relation, non ?


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Beta Osmose Leaflet

[didier2020]

piste? : il n'y a pas de notion de parent coté menu ou coté layer ?

 // Invert item check
  _invertAllItem: function () {
$("input[type='checkbox']").each(function () {

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

Re: [OSM-dev-fr] Fichier comparaison cours d'eau

[Ab_fab]

Les points relevés par Sylvain (M.) sont toujours d'actualité pour le Rhin
et le Rhône, mais pour le reste c'est beaucoup mieux.
Toujours quelques points particuliers en bas de tableau qui passent mal,
mais ce n'est pas bien méchant.
1266 cours d'eau référencés, c'est vraiment pas mal.
Le kilométrage a fait une belle progression aussi (même en laissant de côté
les km que l'on ne devrait pas référencer)


Le 17 février 2014 16:07, sly (sylvain letuffe)  a
écrit :

>  On lundi 17 février 2014, Sylvain Maillard wrote:
>
> > Salut,
>
>
>
> hello,
>
>
>
> > les "trous" dont tu parles, c'est tous le bas de la liste des cours d'eau
>
> > qui aparaissent en 0% ?
>
>
>
> Et qui sont véritablement dans osm.
>
> Il en existe qui ne sont pas dans osm et eux, c'est normal qu'ils soient
> listés à 0%, mais il y en a plein qui ne devraient pas être à 0%.
>
>
>
> Je viens de tenter une opération, on va voir ce soir si le calcul arrive à
> combler quelques trous...
>
>
>
> > il y a sans doute quelques améliorations qui pourraient être faites:
>
>
>
> Ça ! Les idées d'améliorations ne manquent pas, mais je vais déjà tenter
> de le faire marcher tout court, et ça sera déjà pas mal.
>
> Bien sûr, si quelqu'un voit en cet outil un bon potentiel et a envie de
> rajouter des fonctions, c'est avec plaisir !
>
>
>
> > - on a 156% du Rhône, mais parce que la relation osm part de la source du
>
> > Rhône en suisse. Est-ce qu'il serait possible de ne pas prendre en compte
>
> > les tronçons hors de france ? (même chose pour le Rhin: 690% !)
>
> >
>
> >
>
> >
>
> > Sylvain
>
> >
>
> >
>
> >
>
> >
>
> > Le 17 février 2014 15:05, sly (sylvain letuffe)  a
>
> > écrit :
>
> >
>
> > > On jeudi 6 février 2014, sly (sylvain letuffe) wrote:
>
> > >
>
> > >
>
> > >
>
> > > > ps: je vais sans doute faire un ré-import total de la base, et à
> partir
>
> > > de
>
> > >
>
> > > > là,
>
> > >
>
> > > > il faudra ouvrir l'oeil afin de voir à partir de quand ça déconne,
> sur
>
> > > quel
>
> > >
>
> > > > rivière et voir si une édition en particulier aurait pu être le
>
> > > déclencheur.
>
> > >
>
> > > > Je remettrais un mail pour dire quand c'est fait et si c'est fait.
>
> > >
>
> > >
>
> > >
>
> > > J'ai donc ré-importé toute la base, et un calcul a été refait hier soir
>
> > > (un autre devrait survenir ce soir 19h00)
>
> > >
>
> > >
>
> > >
>
> > > Le résultat n'est pas glorieux :
>
> > >
>
> > >
>
> > >
> http://suivi.openstreetmap.fr/longeur-cours-eau-france/comparaison-sandre.html
>
> > >
>
> > >
>
> > >
>
> > > C'est pas autant troué que la dernière fois, mais ça l'est déjà quand
> même
>
> > >
>
> > > (par exemple "Le Lot", mais bien d'autre encore)
>
> > >
>
> > >
>
> > >
>
> > > Mais j'ai mal géré mon histoire, j'ai relancé les mises à jour tout de
>
> > > suite après l'import, ce qui fait que je n'ai pas laissé le temps de
> voir
>
> > > si le problème était déjà là à la fin de l'import, où s'il était lié au
>
> > > mise à jour ultérieures.
>
> > >
>
> > > Coté des limites administratives, qui manquaient, elles aussi en nombre
>
> > > dans cette base, tout semble s'être réparé :
>
> > >
>
> > > http://suivi.openstreetmap.fr/communes/communes.csv.txt
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > >
>
> > > --
>
> > >
>
> > > sly
>
> > >
>
> > > qui suis-je : http://sly.letuffe.org
>
> > >
>
> > >
>
> > >
>
> > > ___
>
> > > dev-fr mailing list
>
> > > dev-fr@openstreetmap.org
>
> > > https://lists.openstreetmap.org/listinfo/dev-fr
>
> > >
>
> > >
>
> >
>
>
>
>
>
> --
>
> sly
>
> qui suis-je : http://sly.letuffe.org
>
>
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Overpass API et Talend

[Christian Quest]

Qu'attend au juste le connecteur OSM de Talend ?

De l'XML façon OSM ?

Si oui, alors l'overpass peut lui servir ça, il suffit de demander un
résultat en XML, et éventuellement avec les metadonnées si Talend en a
besoin.

Exemple: http://overpass-turbo.eu/s/2C4




Le 24 février 2014 14:50, sly (sylvain letuffe)  a
écrit :

>  On lundi 24 février 2014, Eric Pommereau wrote:
>
> > Bonjour,
>
>
>
> Hello,
>
>
>
> > Quelqu'un a déjà testé le traitement d'une requête overpass API dans
> l'ETL
>
> > Talend ?
>
> > Deux composant OsmWayInput / OsmNodesInput le permettent
>
>
>
> Je préfère le dire tout de suite, j'ai rien compris à ces trois phrases,
> je connais pourtant assez bien l'API 0.6 et l'Overpass API, mais le fait
> d'introduire des éléments sur un logiciel dont on a jamais entendu parlé
> sur cette liste n'aide pas à la compréhension de ta question et donc
> augmente encore la difficulté à y répondre.
>
>
>
> Habituellement, dans un cas comme ça, je ne répond pas (vu que je ne sais
> pas/ne comprends pas) mais comme je n'avais rien compris non plus à ton
> précédent message sur les "Contours de communes et arrondissements PLM"
> alors que c'est aussi un sujet que je comprend bien dans osm, je me dis que
> peut-être tu devrais simplifier la formulation de ton problème, sachant que
> la thématique à l'air intéressante.
>
>
>
>
>
> Revenons à ce cas concret, je ne sais pas non plus ce qu'est "ETL talend",
> mais si c'est un "truc" qui appel des données osm par une API il faut voir
> à quel point il peut être paramétré et customisé (as-tu accès au code ?
> es-tu développeur de l'outil ? quelles options peuvent être touchées ?)
>
>
>
> Si tu ne peux pas toucher le code, pas choisir le "end point" de l'api
> appelé, alors c'est vite vu, tu ne pourra pas faire grand chose...
>
>
>
> > mais sur l'api,
>
>
>
> Sais-tu quelle est l'api appelée ? est-ce l'api 0.6 de
> http://api.openstreetmap.org/api/0.6/ ?
>
> une xapi ?
>
>
>
>
>
> > non sur overpass. Quelle est la différence entre les deux ?
>
>
>
> Elles peuvent sortir exactement le même type de contenu (des noeuds, ways
> et relation en provenance d'osm au format .osm) mais n'ont pas du tout les
> mêmes méthodes d'appel :
>
> http://wiki.openstreetmap.org/wiki/Api06
>
> http://wiki.openstreetmap.org/wiki/Overpass_API
>
>
>
> En outre, l'api 0.6 fourni sur http://api.openstreetmap.org a pour
> objectif d'être utilisé principalement pour l'édition des données et non
> pour la consommation des données.
>
> Une utilisation importante pourrait amener à un bannissement.
>
>
>
> > Et existe-t-il
>
> > un moyen de faire correspondre les sorties
>
>
>
> ça veut dire quoi ? si c'est pour avoir le même format en sortie, voir la
> réponse de frédéric et l'option "meta"
>
>
>
> --
>
> sly
>
> qui suis-je : http://sly.letuffe.org
>
>
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Overpass API et Talend

[sly (sylvain letuffe)]

On lundi 24 février 2014, Eric Pommereau wrote:
> Bonjour,

Hello,

> Quelqu'un a déjà testé le traitement d'une requête overpass API dans l'ETL
> Talend ?
> Deux composant OsmWayInput / OsmNodesInput le permettent 

Je préfère le dire tout de suite, j'ai rien compris à ces trois phrases, je 
connais pourtant assez bien l'API 0.6 et l'Overpass API, mais le fait 
d'introduire des éléments sur un logiciel dont on a jamais entendu parlé sur 
cette liste n'aide pas à la compréhension de ta question et donc augmente 
encore la difficulté à y répondre.

Habituellement, dans un cas comme ça, je ne répond pas (vu que je ne sais 
pas/ne comprends pas) mais comme je n'avais rien compris non plus à ton 
précédent message sur les "Contours de communes et arrondissements PLM" alors 
que c'est aussi un sujet que je comprend bien dans osm, je me dis que peut-
être tu devrais simplifier la formulation de ton problème, sachant que la 
thématique à l'air intéressante.


Revenons à ce cas concret, je ne sais pas non plus ce qu'est "ETL talend", 
mais si c'est un "truc" qui appel des données osm par une API il faut voir à 
quel point il peut être paramétré et customisé (as-tu accès au code ? es-tu 
développeur de l'outil ? quelles options peuvent être touchées ?)

Si tu ne peux pas toucher le code, pas choisir le "end point" de l'api appelé, 
alors c'est vite vu, tu ne pourra pas faire grand chose...

> mais sur l'api,

Sais-tu quelle est l'api appelée ? est-ce l'api 0.6 de 
http://api.openstreetmap.org/api/0.6/ ?
une xapi ?


> non sur overpass. Quelle est la différence entre les deux ? 

Elles peuvent sortir exactement le même type de contenu (des noeuds, ways et 
relation en provenance d'osm au format .osm) mais n'ont pas du tout les mêmes 
méthodes d'appel :
http://wiki.openstreetmap.org/wiki/Api06
http://wiki.openstreetmap.org/wiki/Overpass_API

En outre, l'api 0.6 fourni sur http://api.openstreetmap.org a pour objectif 
d'être utilisé principalement pour l'édition des données et non pour la 
consommation des données.
Une utilisation importante pourrait amener à un bannissement.

> Et existe-t-il
> un moyen de faire correspondre les sorties 

ça veut dire quoi ? si c'est pour avoir le même format en sortie, voir la 
réponse de frédéric et l'option "meta"

-- 
sly
qui suis-je : http://sly.letuffe.org
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[Pieren]

2014-02-24 14:14 GMT+01:00 Christian Quest :

> Les parcelles ne sont pas dans OSM et on n'a pas de projet à moyen terme
> pour les intégrer.

Selon moi, adresses postales et parcelles sont deux choses totalement
séparées. On fait le mélange lorsqu'on voit les données au travers du
prisme DGFiP.

> Qu'en dites-vous ?

Qu'il faut en discuter ailleurs que sur la liste dev-fr...

Pieren

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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[V de Chateau-Thierry]

> De : "Christian Quest"
>
> Après ma rencontre chez médipost où on a beaucoup parlé d'adresses, je suis 
> arrivé à la
> conclusion que lorsqu'on parle d'adresse, on ne parle pas tous de la même 
> chose... d'où
> le problème pour avoir un consensus.
>
> Un seul modèle ne peut donc répondre à toutes les facettes de ce que peut 
> être une
> adresse ou alors il faut que ce soit un modèle extensible. Justement... OSM 
> fonctionne
> sur ce principe d'extensions.
>
> Il faudra sûrement aller plus loin que le modèle actuel pour que tout le 
> monde y trouve
> son compte.
>
> Alors de quoi parle-t-on ?
>
> - de parcelles
> - de bâtiments
> - de plaques adresse
> - d'accès depuis la voirie la plus proche
> - de point plus "métier": position de la boite aux lettres, du compteur 
> EDF/eau, des
> entrées, de la livraison...
> autre ?

D'accord avec cette pluralité. Dans la liste que tu dresses, un seul élément 
nous est
systématiquement fourni par des sources simples d'accès (cadastre, bing), c'est 
le
bâtiment. D'où ma conviction, déjà exprimée ici dans un fil précédent, que 
c'est le(s)
bâtiment(s) qui doit se faire l'étendard de l'info d'adresse.
Une précision cependant : en discutant sur la manière de modéliser, je ne pense 
quasi pas
à ce que chacun voudra faire sur un terrain qu'il peut arpenter en piéton, 
qu'il peut
scruter, affiner, détailler. Chacun chez soi saura mapper les adresses aux 
petits
oignons, par justement la possibilité de positionner les accès piéton et 
voiture, les
portes d'entrée, les boîtes aux lettres, etc.
Je discute ici plutôt d'un modèle minimal que chacun serait à même d'appliquer 
sur des
territoires où il contribue sans les connaître, un peu comme il arrive qu'on 
fasse un
import de bâti sur un patelin où on n'a jamais mis les pieds. C'est un mal 
nécessaire
si on veut que l'adresse devienne un matériau utilisable dans OSM car 
suffisamment
répandu.

vincent

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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[Christian Quest]

Après ma rencontre chez médipost où on a beaucoup parlé d'adresses, je suis
arrivé à la conclusion que lorsqu'on parle d'adresse, on ne parle pas tous
de la même chose... d'où le problème pour avoir un consensus.

Un seul modèle ne peut donc répondre à toutes les facettes de ce que peut
être une adresse ou alors il faut que ce soit un modèle extensible.
Justement... OSM fonctionne sur ce principe d'extensions.

Il faudra sûrement aller plus loin que le modèle actuel pour que tout le
monde y trouve son compte.

Alors de quoi parle-t-on ?

- de parcelles
- de bâtiments
- de plaques adresse
- d'accès depuis la voirie la plus proche
- de point plus "métier": position de la boite aux lettres, du compteur
EDF/eau, des entrées, de la livraison...
autre ?

Les parcelles ne sont pas dans OSM et on n'a pas de projet à moyen terme
pour les intégrer.
Les bâtiments... ils peuvent être liés à une ou plusieurs adresses ou
l'inverse (plusieurs adresses pour un même bâtiment)
Les plaques adresses: c'est un truc un peu virtuel... qui correspond plus
ou moins à une entrée (mais j'ai de beaux contre exemple en photo... plaque
adresse, mais aucune entrée, juste un poteau de parking !)
Les accès: en gros ça donne une position en bord de voirie, c'est peut être
le plus universel
Les points métiers sont modélisables mais en étendant le modèle actuel.

Qu'en dites-vous ?



Le 24 février 2014 13:47, V de Chateau-Thierry  a écrit :

> Bonjour,
>
> > De : "Christian Quest"
> >
> > L'idéal serait d'arriver à trouver un consensus sur la modélisation et
> de ne proposer
> > que des fichiers correspondant à ce consensus histoire d'avoir au final
> des données
> > homogènes sur toute la France (à défaut de pouvoir homogénéiser sur le
> monde entier).
>
> Tout à fait d'accord avec ça. Mais comment parvenir à ce consensus ?
> Est-ce que, dans un
> premier temps, on met à dispo tous les "parfums" de fichiers ( 6
> actuellement, bientôt 8
> si on attaque la version mixte limites de parcelles / façades) et au bout
> de 6 mois, avec
> du recul, on lance un sondage ? Ou bien on constate quel modèle est devenu
> prépondérant
> en base ? Ce sont des idées en vrac, je n'ai pas d'avis sur la méthode,
> mais je partage
> vraiment la cible, à savoir qu'on définisse sur la France un modèle
> accepté comme celui
> qu'on recommande à tout nouveau contributeur sur le sujet.
>
> vincent
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>



-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[Nicolas Dumoulin]

Le lundi 24 février 2014 13:47:31 V de Chateau-Thierry a écrit :
> Bonjour,
> 
> > De : "Christian Quest"
> > 
> > L'idéal serait d'arriver à trouver un consensus sur la modélisation et de
> > ne proposer que des fichiers correspondant à ce consensus histoire
> > d'avoir au final des données homogènes sur toute la France (à défaut de
> > pouvoir homogénéiser sur le monde entier).
> Tout à fait d'accord avec ça. Mais comment parvenir à ce consensus ? Est-ce
> que, dans un premier temps, on met à dispo tous les "parfums" de fichiers (
> 6 actuellement, bientôt 8 si on attaque la version mixte limites de
> parcelles / façades) et au bout de 6 mois, avec du recul, on lance un
> sondage ?

+1
Je trouve que c'est en se confrontant à la saisie qu'on mesure la diversité 
des situations, et en testant les différents schémas qu'on évalue leur 
pertinence.
Perso, je n'ai pas encore vraiment saisi beaucoup d'adresses, mais testé les 
différents schémas, et j'ai beaucoup appris ! :-)
Il serait peut-être temps (l'outil me semble prêt) de diffuser sur talk-fr pour 
avoir d'autres opinions et pouvoir ensuite trouver ce consensus.

Bonne baignade

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[V de Chateau-Thierry]

Bonjour,

> De : "Christian Quest"
>
> L'idéal serait d'arriver à trouver un consensus sur la modélisation et de ne 
> proposer
> que des fichiers correspondant à ce consensus histoire d'avoir au final des 
> données
> homogènes sur toute la France (à défaut de pouvoir homogénéiser sur le monde 
> entier).

Tout à fait d'accord avec ça. Mais comment parvenir à ce consensus ? Est-ce 
que, dans un
premier temps, on met à dispo tous les "parfums" de fichiers ( 6 actuellement, 
bientôt 8
si on attaque la version mixte limites de parcelles / façades) et au bout de 6 
mois, avec 
du recul, on lance un sondage ? Ou bien on constate quel modèle est devenu 
prépondérant
en base ? Ce sont des idées en vrac, je n'ai pas d'avis sur la méthode, mais je 
partage
vraiment la cible, à savoir qu'on définisse sur la France un modèle accepté 
comme celui
qu'on recommande à tout nouveau contributeur sur le sujet.

vincent

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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[Christian Quest]

Le 24 février 2014 11:26, Tyndare  a écrit :

>
>
> Le 23 février 2014 21:54, Vincent de Château-Thierry  a
> écrit :
>
>> Le 23/02/2014 10:28, Christian Quest a écrit :
>>
>>> Il manque à mon avis un fichier mix entre les points isolés et les
>>>
>>> points sur façade.
>>>
>>> En effet, ma façon manuelle de positionner les adresses est la suivante:
>>> - si la façade du bâtiment donne sur la rue, je met le point adresse en
>>> façade du bâtiment sur un noeud du polygone
>>> - si le bâtiment principal ne donne pas sur la rue, je met le point
>>> adresse en limite de parcelle
>>>
>>> J'ai l'impression que je ne suis pas le seul à procéder comme ça et là
>>> je suis obligé de passer d'un fichier à l'autre ce qui bien sûr ne fait
>>> pas vraiment gagner de temps au final.
>>>
>>
> Cela correspond aussi à ma façon de mapper, je vais essayer de faire
> quelque chose dans ce sens (mais il me faut un peu de temps, je voudrais
> essayer d'utiliser l'angle que fait le numéro dessiné sur le cadastre pour
> déterminer la direction ou projeter le numéro).
>

Ah oui, c'est une info qui peut aider, mais il faut faire attention car il
y aura forcément des numéros non orientés vu la disparité dans les données
vectorielles du cadastre.



>
>> Le parti pris implicite dans les fichiers, c'est une modélisation homogène
>> au sein d'un même fichier (1 fichier = 1 rue) sachant qu'il y a déjà une
>> combinatoire entre 3 implantations et 2 modélisations. Le risque d'usine
>> à gaz n'est jamais loin...
>
>
> Pour ce qui est de mon code, je crois que j'ai déjà atteint le niveau
> usine à gaz vu que j'ai du mal à me relire...
> Si ce fichier mix intermédiaire correspond mieux à ceux que certains
> attendent peut-être que l'on pourra supprimer la version < isolés découpés par rue>>.
>
>
L'idéal serait d'arriver à trouver un consensus sur la modélisation et de
ne proposer que des fichiers correspondant à ce consensus histoire d'avoir
au final des données homogènes sur toute la France (à défaut de pouvoir
homogénéiser sur le monde entier).



> Par contre il a un fichier <>, un
> seul gros fichier, qui est actuellement caché, et je me pose la question de
> le rendre publique.
> Je m'en sert souvent, non pas pour intégrer, mais pour vérifier une zone
> déjà mappée, ou quand je ne comprends pas pourquoi le découpage par rue a
> exclus certains numéros de tel ou telle rue. Je trouve qu'il a une vrais
> utilité.
> Je le génère dorénavant avec l'option upload="false" pour que JOSM
> dissuade son envoie directe dans OSM.
>
> Que pensez vous de rendre ce fichier accessible à tous ?
>  Ou alors sous condition, comme pour les fichiers eau ?
>
>

Il faut éviter que l'outil d'extraction soit utilisé hors OSM et un tel
fichier risquerai d'être trop facilement exploité hors OSM.
Il n'en reste pas moins très utile... justement pour créer par exemple une
base adresses "brute" pouvant servir à faire du géocodage (pour des besoins
internes OSM).

Il ne faut pas oublier les conditions de notre autorisation d'exploiter les
données du cadastre:
- mention de la source et du millésime,
- intégration dans une base composite (donc pas que des données du cadastre)
- pas de reproduction intégrale


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Beta Osmose Leaflet

[didier2020]

Le lundi 24 février 2014 à 11:36 +0100, Frédéric Rodrigo a écrit : 
> Le 24/02/2014 09:07, didier2020 a écrit :
> > +1 pour la possibilité de recherche de lieu
> > +1 pour le "truc" qui s'anime pour faire patienter
> > + pour la sélection des calques, je préfère une action clic sur le
> > bouton layer qui ouvre et ferme plutôt que le survol ( c'est juste une
> > préférence)
> >
> >
> > Test sous linux/chromium (version libre de chrome):
> > - l'animation ne fonctionne pas et les "Osmose error" n'apparaissent pas
> 
> Je ne constate pas ce problème avec le dernier linux/chromium.
> Tu peux confirmer que ce n'était pas juste temporaire ? On a des doutes 
> sur la capacité du serveur a répondre tout le temps en temps raisonnable 
> pour une utilisation interactive de Osmose.
autant pour moi, mon premier essai était sur debian 6.
Avec debian 7 / Chromium et Iceweasel (FF libre) fonctionnent comme sous
windows. 
Avec debian 6 / Firefox 64 fonctionne comme sous windows. 

> 
> > Test sous seven/firefox+ie7+chrome:
> >
> > - pour la sélection des erreurs (tout-rien-inverser) :
> > inverser agit sur les calques (pas les "layers" de base, mais les
> > autres)
> On avait ce problème au début partout, mais je ne vois plus d'où ça peut 
> venir, et en plus spécifique à une plateforme.
cf ci-dessus, ce n'est pas spécifique a une plateforme.

> Tu peux cibler un peu 
> plus s'il te plait ?
> 


clic sur inverser :
- cela ajoute un "#" dans la barre d'adresse.
- la selection des layers "secondaire" s'inverse
- la selection de la gravité ne fonctionne plus correctement tant qu'on
laisse le "#" dans la barre d'adresse
clic sur "tout" ou "rien" n'a pas d'influence sur ces memes layers.



> > - l'animation pour patienter ne se voit pas si on sélectionne uniquement
> > le layer 'Osmose error heatmap"
> Ça c'est normal, elle n'est là que pour les marqueurs.
> 
> > - permalink :
> > je clique sur permalink => ok dans la barre d'adresse
> > + si je clic sur une catégorie (structurel, tags manquants ...)
> > => clic sur permalink ne fait rien apparaitre dans la barre d'adresse
> > + si je clic sur une catégorie (structurel, tags manquants ...) ET
> > modification d'item
> > => clic sur permalink ne fait pas apparaitre la localisation
> > (lat,lon,zoom) dans la barre d'adresse
> ok, vu.
> 
> Merci de ton retour
> 
> 
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr



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

Re: [OSM-dev-fr] Overpass API et Talend

[Frédéric Rodrigo]

Le 24/02/2014 11:19, Eric Pommereau a écrit :

Bonjour,

Quelqu'un a déjà testé le traitement d'une requête overpass API dans
l'ETL Talend ?

Deux composant OsmWayInput / OsmNodesInput le permettent mais sur l'api,
non sur overpass. Quelle est la différence entre les deux ? Et
existe-t-il un moyen de faire correspondre les sorties (ou trouver une
autre solution...)


Jamais testé avec Talend, mais si tu utilises le mode meta de 
OverpassAPI ça te retourne les mêmes info que l'API standard. Mais tu 
n'en as peut être même pas besoin.


Frédéric.


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

Re: [OSM-dev-fr] Beta Osmose Leaflet

[Frédéric Rodrigo]

Le 24/02/2014 09:07, didier2020 a écrit :

+1 pour la possibilité de recherche de lieu
+1 pour le "truc" qui s'anime pour faire patienter
+ pour la sélection des calques, je préfère une action clic sur le
bouton layer qui ouvre et ferme plutôt que le survol ( c'est juste une
préférence)


Test sous linux/chromium (version libre de chrome):
- l'animation ne fonctionne pas et les "Osmose error" n'apparaissent pas


Je ne constate pas ce problème avec le dernier linux/chromium.
Tu peux confirmer que ce n'était pas juste temporaire ? On a des doutes 
sur la capacité du serveur a répondre tout le temps en temps raisonnable 
pour une utilisation interactive de Osmose.



Test sous seven/firefox+ie7+chrome:

- pour la sélection des erreurs (tout-rien-inverser) :
inverser agit sur les calques (pas les "layers" de base, mais les
autres)
On avait ce problème au début partout, mais je ne vois plus d'où ça peut 
venir, et en plus spécifique à une plateforme. Tu peux cibler un peu 
plus s'il te plait ?



- l'animation pour patienter ne se voit pas si on sélectionne uniquement
le layer 'Osmose error heatmap"

Ça c'est normal, elle n'est là que pour les marqueurs.


- permalink :
je clique sur permalink => ok dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...)
=> clic sur permalink ne fait rien apparaitre dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...) ET
modification d'item
=> clic sur permalink ne fait pas apparaitre la localisation
(lat,lon,zoom) dans la barre d'adresse

ok, vu.

Merci de ton retour


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

Re: [OSM-dev-fr] Service de pré-intégration d'adresses

[Tyndare]

Le 23 février 2014 21:54, Vincent de Château-Thierry  a
écrit :

> Le 23/02/2014 10:28, Christian Quest a écrit :
>
>> Il manque à mon avis un fichier mix entre les points isolés et les
>> points sur façade.
>>
>> En effet, ma façon manuelle de positionner les adresses est la suivante:
>> - si la façade du bâtiment donne sur la rue, je met le point adresse en
>> façade du bâtiment sur un noeud du polygone
>> - si le bâtiment principal ne donne pas sur la rue, je met le point
>> adresse en limite de parcelle
>>
>> J'ai l'impression que je ne suis pas le seul à procéder comme ça et là
>> je suis obligé de passer d'un fichier à l'autre ce qui bien sûr ne fait
>> pas vraiment gagner de temps au final.
>>
>
Cela correspond aussi à ma façon de mapper, je vais essayer de faire
quelque chose dans ce sens (mais il me faut un peu de temps, je voudrais
essayer d'utiliser l'angle que fait le numéro dessiné sur le cadastre pour
déterminer la direction ou projeter le numéro).

>
> Le parti pris implicite dans les fichiers, c'est une modélisation homogène
> au sein d'un même fichier (1 fichier = 1 rue) sachant qu'il y a déjà une
> combinatoire entre 3 implantations et 2 modélisations. Le risque d'usine à
> gaz n'est jamais loin...


Pour ce qui est de mon code, je crois que j'ai déjà atteint le niveau usine
à gaz vu que j'ai du mal à me relire...
Si ce fichier mix intermédiaire correspond mieux à ceux que certains
attendent peut-être que l'on pourra supprimer la version <>.

Par contre il a un fichier <>, un
seul gros fichier, qui est actuellement caché, et je me pose la question de
le rendre publique.
Je m'en sert souvent, non pas pour intégrer, mais pour vérifier une zone
déjà mappée, ou quand je ne comprends pas pourquoi le découpage par rue a
exclus certains numéros de tel ou telle rue. Je trouve qu'il a une vrais
utilité.
Je le génère dorénavant avec l'option upload="false" pour que JOSM dissuade
son envoie directe dans OSM.

Que pensez vous de rendre ce fichier accessible à tous ?
Ou alors sous condition, comme pour les fichiers eau ?


Tyndare.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

[OSM-dev-fr] Overpass API et Talend

[Eric Pommereau]

Bonjour,

Quelqu'un a déjà testé le traitement d'une requête overpass API dans l'ETL
Talend ?

Deux composant OsmWayInput / OsmNodesInput le permettent mais sur l'api,
non sur overpass. Quelle est la différence entre les deux ? Et existe-t-il
un moyen de faire correspondre les sorties (ou trouver une autre
solution...)

Bonne journée.

Eric
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Beta Osmose Leaflet

[didier2020]

+1 pour la possibilité de recherche de lieu
+1 pour le "truc" qui s'anime pour faire patienter
+ pour la sélection des calques, je préfère une action clic sur le
bouton layer qui ouvre et ferme plutôt que le survol ( c'est juste une
préférence)


Test sous linux/chromium (version libre de chrome):
- l'animation ne fonctionne pas et les "Osmose error" n'apparaissent pas

Test sous seven/firefox+ie7+chrome:

- pour la sélection des erreurs (tout-rien-inverser) :
inverser agit sur les calques (pas les "layers" de base, mais les
autres)
- l'animation pour patienter ne se voit pas si on sélectionne uniquement
le layer 'Osmose error heatmap"
- permalink :
je clique sur permalink => ok dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...)
=> clic sur permalink ne fait rien apparaitre dans la barre d'adresse
+ si je clic sur une catégorie (structurel, tags manquants ...) ET
modification d'item
=> clic sur permalink ne fait pas apparaitre la localisation
(lat,lon,zoom) dans la barre d'adresse

en tout cas : bravos (oui avec un s) 



Le dimanche 23 février 2014 à 22:29 +0100, Frédéric Rodrigo a écrit : 
> Bonjour,
> 
> Nous finalisons une réécriture de l'interface d'Osmose en Leaflet. 
> L'aspect de l'interface reste le même. Juste quelques petites sucreries 
> en plus (géolocalisation navigateur et recherche d'adresses). 
> L'interface doit aussi fonctionner sur mobile.
> 
> On est preneur de tests et des remontés de problèmes :
> 
> http://beta.osmose.openstreetmap.fr/fr/map/
> 
> Pour l'instant le seul problème connu et sans solution est le select de 
> la gravité qui marche mal sous osx et mobile.
> 
> Cette beta interagit avec les mêmes données que la version normale, 
> c'est juste l'interface web qui change.
> 
> Merci d'avance,
> Frédéric.
> 
> Note : également merci à Yohan pour ces conseils en javascript.
> 
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr



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