date:20100625

2010/6/25 Yann SLADEK 

>  Je suis d'accord avec ce qui a été dit, vu le boulot pré import, il doit y
> avoir un moyen de faire ca proprement (facon CLC) et plus rapidement (si on
> veut faire correctement une commune, c'est au moins 1h00)
> Par contre, je pense qu'il serait judicieux de ne plus rendre les données
> accessibles (notamment sur cquest.com)
>
> Yann
>
>
Chercher à améliorer l'outil est, bien entendu, une bonne chose. Mais de là
à demander d'arrêter les contributions actuelles, non. OSM a toujours
fonctionné comme ça, par erreur/correction. Là, c'est comme si vous
demandiez aux rédacteurs wikipedia de ne soumettre que des articles
complets, référencés et sans fautes de français. Ou aux contributeurs
français de ne plus tracer à partir de leur GPS en ville parce que ça serait
plus "efficace" d'utiliser le cadastre qui est meilleur en zone urbaine.
- vouloir distinguer la source humaine du script ? Pourquoi pas. Mais ça
n'est pas indispensable. Si ç'est pour automatiser les tâches de maintenance
ultérieures, il faudra de toutes les manières traiter de la même façon les
sources humaines et les sources automatiques car toutes les deux peuvent et
seront altérées dans la base par d'autres contributeurs.

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

Re: [OSM-talk-fr] Re : Un aperçu des erreurs à c orrigées lié à l'import semi auto

2010-06-25 Par sujet Guillaume Allegre

Le Fri 25 Jun 2010 à 00:58 +0200, Benoît ROUSSEAU a ecrit :

> Zut ! Un grand classique. :p
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/
> Import_semi-automatique_des_b%C3%A2timents/
> Aper%C3%A7u_des_erreurs_rencontr%C3%A9es

Merci pour ce travail utile et salutaire.

Il va falloir différencier les problèmes dus aux données extraites des PDF, 
(erreurs de "validator" et artefacts de parcelles) des problèmes 
d'intégration à l'existant.
Dans la première catégorie, on peut espérer pouvoir corriger automatiquement 
certaines erreurs (ou aider à détecter les problèmes).


-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

[OSM-talk-fr] Re : Les adresses... -- dev ient molo molo sur l'anarchie du bâti

2010-06-25 Par sujet THEVENON Julien

De : Christophe Merlet 



C'est quand même surprenant tout ces messages qui appellent à la
modération sur l'import du bâti alors que juste avant l'arrivée de ce
script bien peu de personnes trouvait a redire sur ceux qui importaient
frénétiquement à la main ce bâti en y passant des journée entière au
détriment de la voirie.

Quand c est fait a la main bâtiment par bâtiment on peut supposer que les gens 
font ca correctement et donc qu'il n y aura pas de retouche a faire
La visiblement certains partent du principe que l important c est d importer un 
maximum de choses le plus rapidement possible et que tant pis pour la qualité 
des outils arriveront plus tard pour corriger les erreurs qu'ils ont la flemme 
de corriger maintenant, c est ca qui me gène personnellement...
Si les imports sont fait correctement et que par la suite il y a faire des 
AJOUTS plutôt que des CORRECTIONS ca me parait mieux, un gros import 
décentralisé et collaboratif mais avec un peu de cohérence et de qualité ca a 
son charme :-)

Julien



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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti

2010-06-25 Par sujet Balooval

Je tiens juste à apporter mon témoignage:

Toute la journée d'hier j'ai importé le bâti d'une quinzaine de village de
mon coin ( http://wiki.openstreetmap.org/wiki/France:Gard ). Tout en lisant
les message inquiets sur cette liste, inquiets au point qu'aujourd'hui
certains suggèrent même de ne plus rendre accessible les fichiers tirés des
pdf.
Je pense avoir correctement importé les données, je n'ai pas pris trop de
risques, m'étant limité aux toutes petites communes (moins de risque de
plantage à l'upload, relativement léger à traiter dans josm, et sans
batiments préalablement présents).

Bref, ce que je voulais dire c'est que pour une fois l'import de données "en
masse" est accessible au plus grand nombre. Pas besoin de savoir faire des
requêtes PostGre (?), scripts pythons ou autres. Ce n'est pas réservé à
"l'élite" (sans animosité aucune!). Voilà pourquoi je pense continuer. Bien
sûr je reste attentif a vos messages, comprend qu'une réflexion pourrait
améliorer les choses, mais que voulez-vous, je pars du principe qu'il vaut
mieux une donnée incomplète que pas de donnée du tout.

Et puis ça m'amuse tellement de contribuer que s'il faut repasser sur mes
imports ce sera avec plaisir :)
A+

Le 25 juin 2010 09:19, Pieren  a écrit :

> 2010/6/25 Yann SLADEK 
>
>  Je suis d'accord avec ce qui a été dit, vu le boulot pré import, il doit y
>> avoir un moyen de faire ca proprement (facon CLC) et plus rapidement (si on
>> veut faire correctement une commune, c'est au moins 1h00)
>> Par contre, je pense qu'il serait judicieux de ne plus rendre les données
>> accessibles (notamment sur cquest.com)
>>
>> Yann
>>
>>
> Chercher à améliorer l'outil est, bien entendu, une bonne chose. Mais de là
> à demander d'arrêter les contributions actuelles, non. OSM a toujours
> fonctionné comme ça, par erreur/correction. Là, c'est comme si vous
> demandiez aux rédacteurs wikipedia de ne soumettre que des articles
> complets, référencés et sans fautes de français. Ou aux contributeurs
> français de ne plus tracer à partir de leur GPS en ville parce que ça serait
> plus "efficace" d'utiliser le cadastre qui est meilleur en zone urbaine.
> - vouloir distinguer la source humaine du script ? Pourquoi pas. Mais ça
> n'est pas indispensable. Si ç'est pour automatiser les tâches de maintenance
> ultérieures, il faudra de toutes les manières traiter de la même façon les
> sources humaines et les sources automatiques car toutes les deux peuvent et
> seront altérées dans la base par d'autres contributeurs.
>
> Pieren
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti

2010-06-25 Par sujet Clement Menier


Balooval wrote:

Je tiens juste à apporter mon témoignage:

Toute la journée d'hier j'ai importé le bâti d'une quinzaine de 
village de mon coin ( http://wiki.openstreetmap.org/wiki/France:Gard 
). Tout en lisant les message inquiets sur cette liste, inquiets au 
point qu'aujourd'hui certains suggèrent même de ne plus rendre 
accessible les fichiers tirés des pdf.
Je pense avoir correctement importé les données, je n'ai pas pris trop 
de risques, m'étant limité aux toutes petites communes (moins de 
risque de plantage à l'upload, relativement léger à traiter dans josm, 
et sans batiments préalablement présents).


Bref, ce que je voulais dire c'est que pour une fois l'import de 
données "en masse" est accessible au plus grand nombre. Pas besoin de 
savoir faire des requêtes PostGre (?), scripts pythons ou autres. Ce 
n'est pas réservé à "l'élite" (sans animosité aucune!). Voilà pourquoi 
je pense continuer. Bien sûr je reste attentif a vos messages, 
comprend qu'une réflexion pourrait améliorer les choses, mais que 
voulez-vous, je pars du principe qu'il vaut mieux une donnée 
incomplète que pas de donnée du tout.


Et puis ça m'amuse tellement de contribuer que s'il faut repasser sur 
mes imports ce sera avec plaisir :)

A+


Je me retrouve complétement dans ce témoignage.

Au vu de la lecture des messages de ces derniers jours, je pense qu'il y 
a des zones plus simples que d'autres:
 * très peu d'erreur de la part du cadastre (moins de 10 minutes de 
travail par commune)

 * un accord parfait du fichier .osm avec le bati cadastre
 * aucune erreur d'envoi via josm par paquet de 500 (mais bon j'ai 
jamais eu plus de de 1 objets à envoyer).

 * bâti inexistant (ou très faible)
 * routes mappées à partir du cadastre donc tout colle parfaitement.

J'avoue un peu redouter la phase où il nous faudra avec Pierre-Alain 
attaquer la ville de Cognac, mais ce n'est qu'une ville et on prendra le 
temps.


Et comme l'indique Balooval, si il y a des erreurs (communes aux 
alentours de Jarnac et Cognac pour ma part), et bien nous serons motivés 
pour tout bien corriger ;-)


Clément.

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

Re: [OSM-talk-fr] [BeCiklo] On en est où ?

2010-06-25 Par sujet Gérard

Superbe bon début, bravo!

Je ne suis pas sur de faire des bêtises si j'édite le Xml, alors je préfère
commenter ici. Où alors est ce qu'il y a le moyen de tester les lignes Xml
qu'on rajouterait pour voir si au moins on introduit pas une grossière
erreur de syntaxe? Peut être quelques conseils basiques sur l'édition Xml
seraient bien utile aux apprentis sorciers en puissance. Et à supposer que
l'ajout soit OK, on fait quoi pour maintenir une légende humainement lisible
(par opposition au code Xml) quelque par? On utilise la page de discussion
http://wiki.openstreetmap.org/wiki/FR_talk:BeCikloXmlPistes ?

En tentant de comprendre xml, sur les path, j'ai noté qu'un éventuel
bicycle=no se traduit par quelque chose de différent que s'il n'y a pas ce
no (bravo d'y avoir pensé), mais je n'ai pas réussi à comprendre comment le
no sera rendu?
Pour les highway residential, considérer aussi un éventuel tag
bicycle=designated pour indiquer les rues calmes et conseillées même si
dépourvues d'aménagement spécifiquement cycliste. On pourrait utiliser un
pointillé bleu?

Le 24 juin 2010 15:41, Lord Awikatchikaen  a
écrit :

> ok j'ai mixé les deux :
>
> 1/ path + surface (paved,asphalt, concrete ou vide) ou smoothness
> (excellent good ou vide) -> vert
> 2/ path  + smoothness (intermediate, bad, very_bad ou vide) et surface
> différent de (paved asphalt et concrete)  -> vert pointillé
>
>
> 2010/6/24 sly (sylvain letuffe) 
>
> On jeudi 24 juin 2010, Lord Awikatchikaen wrote:
>> > pour les trajets vert la promenade de l'orge est plutot bien pour le
>> VTT, je
>> > la fais quelque fois. Certes pour le vélo de ville c'est plus dur il n'y
>> a
>> > pas trop moyen de faire la distinction. ou alors faire évoluer les tags
>> pour
>> > avoir du "pathtype"... mais on est plutôt sur le rendu. La ou on
>> pourrait
>> > jouer c'est sur le tag "surface". Si path + paved ou asphalt c'est ok
>> pour
>> > vélo et VTT. sinon que pour VTT
>>
>> Ou alors, (au risque de devenir lourd à force d'en faire la pub) :
>> http://wiki.openstreetmap.org/wiki/Key:smoothness
>>
>> smoothness -> good (c'est praticable en Vélo de course/vélo de ville)
>> smoothness -> bad (c'est praticable en VTC)
>> smoothness -> very_horrible (c'est praticable en VTT )
>>
>>
>>
>> --
>> sly
>> Sylvain Letuffe sylv...@letuffe.org
>> qui suis-je : http://slyserv.dyndns.org
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti

> 2010/6/25 Yann SLADEK 
>
>>  Je suis d'accord avec ce qui a été dit, vu le boulot pré import, il
>> doit y
>> avoir un moyen de faire ca proprement (facon CLC) et plus rapidement (si
>> on
>> veut faire correctement une commune, c'est au moins 1h00)
>> Par contre, je pense qu'il serait judicieux de ne plus rendre les
>> données
>> accessibles (notamment sur cquest.com)
>>
>> Yann
>>
>>
> Chercher à améliorer l'outil est, bien entendu, une bonne chose. Mais de
> là
> à demander d'arrêter les contributions actuelles, non. OSM a toujours
> fonctionné comme ça, par erreur/correction. Là, c'est comme si vous
> demandiez aux rédacteurs wikipedia de ne soumettre que des articles
> complets, référencés et sans fautes de français. Ou aux contributeurs
> français de ne plus tracer à partir de leur GPS en ville parce que ça
> serait
> plus "efficace" d'utiliser le cadastre qui est meilleur en zone urbaine.

tout a fait
a ce moment là tout le monde arrête tout et dans 50 ans quand on auras des
données libres partout, alors a ce moment on importera dans OSM.
Ca n'est pas du tout l'esprit des bdd coopératives.

Sur les quelques communes que j'ai importé semi-automatiquement il y avait
quelques bâtiments déjà existant. Le bâtiment automatique était bien plus
précis que le bâtiment existant, par contre les métadonnées associées au
bâtiment existant étaient plus précise, forcement. Si on fait gaffe lors
de la fusion, on a le meilleur des deux monde non ?

-- 
JB


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

[OSM-talk-fr] Parc du Vercors - base occupation des sols

2010-06-25 Par sujet Guillaume Allegre

Suite à une demande que j'avais faite au PNR Vercors fin mai, voici
ma réponse aux interrogations de mon interlocuteur
(le chargé de mission TIC du Parc, et chargé du SIG).

Parmi les questions, on peut noter la suivante :
>  qui peut modifier cette couche, et en quoi le parc pourrait-il
>  être responsable en cas de mauvaise utilisation de la couche ou
>  peut il être responsable des modifications apportées par qq'un d'autre ?

J'ai répondu (voir plus bas), mais si vous connaissez des exemples ou 
des arguments plus convaincants, partagez.
Je pense que ça peut être la base d'une rédaction d'un argumentaire générique
pour tous les producteurs de données publiques à contacter 
(collectivités locales, services publics, IGN... non, là j'déconne !)



> Le Fri 25 Jun 2010 à 08:37 +0200, y_buthion a ecrit :

> > si nous te fournissons la couche Occupation du sol 1995-2005 :
> > 
> >* le nom du Parc en tant que source sera-t-il mentionné ?
> 
> Oui (sauf si vous ne le voulez pas, bien sûr).
> Tous les objets OSM peuvent être équipés d'une balise "source", qui est 
> une métadonnée.
> Par exemple, tous les imports de la base Corine Land Cover sont balisées
> source="Union européenne – SOeS, CORINE Land Cover, 2006".
> Pour référence : 
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Corine_Land_Cover/Précisions
> 
> 
> >* qui peut modifier cette couche, et en quoi le parc pourrait il
> >  être responsable en cas de mauvaise utilisation de la couche ou
> >  peut il être responsable des modifications apportées par qq'un
> >  d'autre ?
> 
> Ce sont des questions récurrentes en effet, ce qui est bien compréhensible.
> 
> - tout le monde peut modifier les objets OSM ; c'est le principe, rien n'est 
> verrouillable dans OSM (pour l'instant en tous cas).
> 
> - l'historique d'un objet OSM est consultable (comme dans Wikipedia), et on 
> peut toujours savoir si l'objet est "d'origine" ou a été modifié depuis
> l'import initial
> 
> - sur la responsabilité du Parc : je ne suis pas juriste et c'est une question
> de droit plus que de technique, mais la nature de la base de données OSM
> (massivement collaborative et multi-sources) fait que ça m'étonnerait que
> quelqu'un base une action judiciaire dessus.
> Si tu as un exemple de scénario précis, merci de me le donner, je poserai
> la question sur la liste de discussions.
> 
> - important : la licence utilisée est une licence libre ; actuellement, 
> c'est Creative Commons + Paternité + Partage des conditions initiales 
> à l'identique (CC-BY-SA).
> Des discussions sont en cours pour changer vers une licence mieux adaptée
> aux bases de données : Open Database License. Cf 
> http://wiki.openstreetmap.org/wiki/Open_Database_License
> Je pense que l'importation ne pourra s'envisager que si le Parc accepte
> les deux licences.
> 
> 
> Petite annexe technique :
> Pour info, contrairement aux SIG, OSM n'a pas de notion de couches. 
> Ce sont les balises (tags) associées aux objets qui jouent ce rôle.
> Les objets sont de 3 types : les points (nodes), les ways (polylignes) et 
> les relations. Voir http://wiki.openstreetmap.org/wiki/Data_Primitives
> 
> Dans le cas présent, les objets importés se traduiraient majoritairement en 
> polygones "landuse" OSM : http://wiki.openstreetmap.org/wiki/Landuse
> Et peut-être d'autres choses (natural=water...). On peut toujours discuter
> des points techniques.
> 
> On n'a pas pour l'instant de logiciel tout prêt pour importer massivement des
> données, par contre, on a quelques bénévoles très compétents dans l'écriture
> des moulinettes qui vont bien ;-)



-- 
 ° /\Guillaume AllègreMembre de l'April
  /~~\/\   allegre.guilla...@free.fr  Promouvoir et défendre le logiciel libre
 /   /~~\tél. 04.76.63.26.99  http://www.april.org

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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti

2010-06-25 Par sujet Ab_fab

J'ai un peu le même feeling

L'utilisation du script est une aide précieuse pour lancer le mapping des
bâtiments, mais il y a un "service après-vente" à assurer ensuite (affiner
la nature des batiments).
Le fonctionnement commune par commune, sur le même mode que pour les limites
administratives me plait mieux, parce que la personne qui aura initié
l'import fera très probablement dans la foulée l'insertion des informations
complémentaires.

Il est nécessaire de bétonner l'outil pour éliminer au plus tôt dans le
processus d'import les erreurs / artefacts qui auront été identifiés comme
récurrents et pour lesquels une correction automatique est nécessaire. Sans
compter les nouvelles fonctions.

D'ailleurs, s'il est possible de lancer une traçabilité de son évolution, je
vote pour (indice de révision, date). N'étant pas développeur, je suis mal
placé pour donner la voie à suivre.
Mais en tant que "end user" potentiel, j'ai envie d'utiliser l'outil le plus
robuste, qui m'évitera le "Hall of shame" des dupe nodes, et surtout d'avoir
à passer beaucoup de temps à tout mettre d'équerre.

Idem pour les dépots de fichiers OSM.
Comment savoir par quelle évolution du script ils ont été générés ?

Honnêtement, même en ayant du temps pour suivre les discussions, je ne sais
pas où on en est.
Lever le pied pour intégrer ce genre de choses me parait raisonnable.

La frénésie des jours passés est simplement à la hauteur de l'attente.
Il semble que tout le monde était dans les starting-blocks.
Cumulé à l'indisponibilité du site et à la crainte de voir la génération de
PDF "généreux en infos" disparaitre du site du cadastre, c'est amusant à
voir :-)



Le 25 juin 2010 09:57, Balooval  a écrit :

> Je tiens juste à apporter mon témoignage:
>
> Toute la journée d'hier j'ai importé le bâti d'une quinzaine de village de
> mon coin ( http://wiki.openstreetmap.org/wiki/France:Gard ). Tout en
> lisant les message inquiets sur cette liste, inquiets au point
> qu'aujourd'hui certains suggèrent même de ne plus rendre accessible les
> fichiers tirés des pdf.
> Je pense avoir correctement importé les données, je n'ai pas pris trop de
> risques, m'étant limité aux toutes petites communes (moins de risque de
> plantage à l'upload, relativement léger à traiter dans josm, et sans
> batiments préalablement présents).
>
> Bref, ce que je voulais dire c'est que pour une fois l'import de données
> "en masse" est accessible au plus grand nombre. Pas besoin de savoir faire
> des requêtes PostGre (?), scripts pythons ou autres. Ce n'est pas réservé à
> "l'élite" (sans animosité aucune!). Voilà pourquoi je pense continuer. Bien
> sûr je reste attentif a vos messages, comprend qu'une réflexion pourrait
> améliorer les choses, mais que voulez-vous, je pars du principe qu'il vaut
> mieux une donnée incomplète que pas de donnée du tout.
>
> Et puis ça m'amuse tellement de contribuer que s'il faut repasser sur mes
> imports ce sera avec plaisir :)
> A+
>
> Le 25 juin 2010 09:19, Pieren  a écrit :
>
>> 2010/6/25 Yann SLADEK 
>>
>>  Je suis d'accord avec ce qui a été dit, vu le boulot pré import, il doit
>>> y avoir un moyen de faire ca proprement (facon CLC) et plus rapidement (si
>>> on veut faire correctement une commune, c'est au moins 1h00)
>>> Par contre, je pense qu'il serait judicieux de ne plus rendre les données
>>> accessibles (notamment sur cquest.com)
>>>
>>> Yann
>>>
>>>
>> Chercher à améliorer l'outil est, bien entendu, une bonne chose. Mais de
>> là à demander d'arrêter les contributions actuelles, non. OSM a toujours
>> fonctionné comme ça, par erreur/correction. Là, c'est comme si vous
>> demandiez aux rédacteurs wikipedia de ne soumettre que des articles
>> complets, référencés et sans fautes de français. Ou aux contributeurs
>> français de ne plus tracer à partir de leur GPS en ville parce que ça serait
>> plus "efficace" d'utiliser le cadastre qui est meilleur en zone urbaine.
>> - vouloir distinguer la source humaine du script ? Pourquoi pas. Mais ça
>> n'est pas indispensable. Si ç'est pour automatiser les tâches de maintenance
>> ultérieures, il faudra de toutes les manières traiter de la même façon les
>> sources humaines et les sources automatiques car toutes les deux peuvent et
>> seront altérées dans la base par d'autres contributeurs.
>>
>> Pieren
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
--
ab_fab

"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Re : Un aperçu des erreurs à corrigées lié à l'import semi auto

2010-06-25 Par sujet Christophe Merlet

Le vendredi 25 juin 2010 à 00:58 +0200, Benoît ROUSSEAU a écrit :
> THEVENON Julien a écrit : 
> >  De : Benoît ROUSSEAU 
> > 
> >  Bonsoir,
> > 
> >    J'ai initié une page incomplète et non exhaustive des
> > "erreurs" que je cherche à résoudre avant un import bâti semi auto.
> >    Elle n'est pour l'instant liée à aucune autre page. Si vous
> > avez des éléments pour la compléter, n'hésitez pas et remaniez comme
> > vous le souhaitez.
> > 
> > Tu peux donner le lien stp ?
> > 
> Zut ! Un grand classique. :p
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents/Aper%C3%A7u_des_erreurs_rencontr%C3%A9es

Très bien.
Grâce a toi je sais comment corriger les erreurs de jointures. J'avais
le tord de sélectionner le point et le segment sur lequel je voulais me
joindre :(

J'ai mis à jour le wiki pour les Pyrénées-Atlantiques
http://wiki.openstreetmap.org/wiki/France:Pyr%C3%A9n%C3%A9es-Atlantiques
J'y indique les communes importées (une quarantaine) et le fait qu'il
faut corriger mes imports d'avant aujourd'hui sur ce point... Ce que je
vais bien sûr faire moi même ;o)


Librement,


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

[OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet Julien Angot

Bonjour,

En attendant un consensus sur l'import du bâti, je trace les lignes du
tramway de Rouen (qui est d'ailleurs mi-tramway mi-subway) avec ses
stations, mais je bloque sur certains points.

1er) Devons nous tracer deux voies l'une à coté de l'autre ou une seule voie
? Après avoir fouillé sur le wiki (
http://wiki.openstreetmap.org/wiki/Tag:railway%3Dtram) je vois qu'il est
possible de faire les deux, mais je voulais savoir si cela avait changé
depuis et si il y avait eu un consensus pour la France ?

2e) Le tramway de Rouen possède un réseau sous-terrain et plusieurs station
aussi. Pour le réseau je pense rester sur un "railway=tram+layer=-1", mais
pour les stations les stations que dois je mettre ? Rester en
"railway=tram_stop" ou "railway=subway_entrance" ?

Merci d'avance.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet OSM42

Le tramway de rouen est bien un tramway sur l'ensemble de sa ligne et 
pas un métro comme on entend parfois dans les rues de Rouen :-)  
(alimentation électrique par voie aérienne via pantographe).


Le 25/06/2010 10:44, Julien Angot a écrit :

Bonjour,

En attendant un consensus sur l'import du bâti, je trace les lignes du 
tramway de Rouen (qui est d'ailleurs mi-tramway mi-subway) avec ses 
stations, mais je bloque sur certains points.


1er) Devons nous tracer deux voies l'une à coté de l'autre ou une 
seule voie ? Après avoir fouillé sur le wiki 
(http://wiki.openstreetmap.org/wiki/Tag:railway%3Dtram) je vois qu'il 
est possible de faire les deux, mais je voulais savoir si cela avait 
changé depuis et si il y avait eu un consensus pour la France ?


2e) Le tramway de Rouen possède un réseau sous-terrain et plusieurs 
station aussi. Pour le réseau je pense rester sur un 
"railway=tram+layer=-1", mais pour les stations les stations que dois 
je mettre ? Rester en "railway=tram_stop" ou "railway=subway_entrance" ?


Merci d'avance.


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


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

Re: [OSM-talk-fr] [BeCiklo] On en est où ?

2010-06-25 Par sujet Ab_fab

Un bac à sable de styles serait tip-top

Pouvoir mettre côte à côte des tuiles d'une même zone (quelques km carrés)
mais avec deux styles différents, aux divers niveaux de zoom

-> Piocher le fichier XML d'un style existant déjà enregistré
-> Faire ses modifs dans le fichier
-> Renvoyer vers le serveur, si possible avec une trace du style originel et
une description humaine de la teneur des modifs
-> Le serveur génère les tuiles pour la même zone pour permettre la
comparaison entre deux rendus
(un peu comme là : [1] (grosse imagination requise !)
-> Le serveur laisse le fichier XML à disposition pour les autres
utilisateurs ou des améliorations

Toujours plus facile à dire qu'à faire :-)

[1] http://teczno.com/cascadenik-openstreetmap-II/

Le 25 juin 2010 10:25, Gérard  a écrit :

> Superbe bon début, bravo!
>
> Je ne suis pas sur de faire des bêtises si j'édite le Xml, alors je préfère
> commenter ici. Où alors est ce qu'il y a le moyen de tester les lignes Xml
> qu'on rajouterait pour voir si au moins on introduit pas une grossière
> erreur de syntaxe? Peut être quelques conseils basiques sur l'édition Xml
> seraient bien utile aux apprentis sorciers en puissance. Et à supposer que
> l'ajout soit OK, on fait quoi pour maintenir une légende humainement lisible
> (par opposition au code Xml) quelque par? On utilise la page de discussion
> http://wiki.openstreetmap.org/wiki/FR_talk:BeCikloXmlPistes ?
>
> En tentant de comprendre xml, sur les path, j'ai noté qu'un éventuel
> bicycle=no se traduit par quelque chose de différent que s'il n'y a pas ce
> no (bravo d'y avoir pensé), mais je n'ai pas réussi à comprendre comment le
> no sera rendu?
> Pour les highway residential, considérer aussi un éventuel tag
> bicycle=designated pour indiquer les rues calmes et conseillées même si
> dépourvues d'aménagement spécifiquement cycliste. On pourrait utiliser un
> pointillé bleu?
>
> Le 24 juin 2010 15:41, Lord Awikatchikaen  a
> écrit :
>
> ok j'ai mixé les deux :
>>
>> 1/ path + surface (paved,asphalt, concrete ou vide) ou smoothness
>> (excellent good ou vide) -> vert
>> 2/ path  + smoothness (intermediate, bad, very_bad ou vide) et surface
>> différent de (paved asphalt et concrete)  -> vert pointillé
>>
>>
>> 2010/6/24 sly (sylvain letuffe) 
>>
>> On jeudi 24 juin 2010, Lord Awikatchikaen wrote:
>>> > pour les trajets vert la promenade de l'orge est plutot bien pour le
>>> VTT, je
>>> > la fais quelque fois. Certes pour le vélo de ville c'est plus dur il
>>> n'y a
>>> > pas trop moyen de faire la distinction. ou alors faire évoluer les tags
>>> pour
>>> > avoir du "pathtype"... mais on est plutôt sur le rendu. La ou on
>>> pourrait
>>> > jouer c'est sur le tag "surface". Si path + paved ou asphalt c'est ok
>>> pour
>>> > vélo et VTT. sinon que pour VTT
>>>
>>> Ou alors, (au risque de devenir lourd à force d'en faire la pub) :
>>> http://wiki.openstreetmap.org/wiki/Key:smoothness
>>>
>>> smoothness -> good (c'est praticable en Vélo de course/vélo de ville)
>>> smoothness -> bad (c'est praticable en VTC)
>>> smoothness -> very_horrible (c'est praticable en VTT )
>>>
>>>
>>>
>>> --
>>> sly
>>> Sylvain Letuffe sylv...@letuffe.org
>>> qui suis-je : http://slyserv.dyndns.org
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
--
ab_fab

"Il n'y a pas de pas perdus"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet René-Luc D'Hont


Sur OSMTransport tu peux visualiser l'état de la ligne de tramway de Rouen :
http://3liz.fr/public/osmtransport/index.php?country=France&location=Rouen

Il y a aussi les lignes du TEOR (ligne de bus aménégé ;-)

René-Luc D'Hont
Ancien Rouennais

Le 25/06/2010 10:46, OSM42 a écrit :
Le tramway de rouen est bien un tramway sur l'ensemble de sa ligne et 
pas un métro comme on entend parfois dans les rues de Rouen :-)  
(alimentation électrique par voie aérienne via pantographe).


Le 25/06/2010 10:44, Julien Angot a écrit :

Bonjour,

En attendant un consensus sur l'import du bâti, je trace les lignes 
du tramway de Rouen (qui est d'ailleurs mi-tramway mi-subway) avec 
ses stations, mais je bloque sur certains points.


1er) Devons nous tracer deux voies l'une à coté de l'autre ou une 
seule voie ? Après avoir fouillé sur le wiki 
(http://wiki.openstreetmap.org/wiki/Tag:railway%3Dtram) je vois qu'il 
est possible de faire les deux, mais je voulais savoir si cela avait 
changé depuis et si il y avait eu un consensus pour la France ?


2e) Le tramway de Rouen possède un réseau sous-terrain et plusieurs 
station aussi. Pour le réseau je pense rester sur un 
"railway=tram+layer=-1", mais pour les stations les stations que dois 
je mettre ? Rester en "railway=tram_stop" ou "railway=subway_entrance" ?


Merci d'avance.


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



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


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

Re: [OSM-talk-fr] [BeCiklo] On en est où ?

> Superbe bon début, bravo!
>
> Je ne suis pas sur de faire des bêtises si j'édite le Xml, alors je
> préfère
> commenter ici. Où alors est ce qu'il y a le moyen de tester les lignes Xml
> qu'on rajouterait pour voir si au moins on introduit pas une grossière
> erreur de syntaxe? Peut être quelques conseils basiques sur l'édition Xml
> seraient bien utile aux apprentis sorciers en puissance.

pour un premier test pour voir si tu n'a pas flingué le fichier, tu peut
l'ouvrir avec firefox ou Internet Explorer.
Si il y a une erreur de syntaxe le navigateur te le signalera.


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

Re: [OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet Frantz


Bonjour,

Le 25/06/2010 10:44, Julien Angot a écrit :

Bonjour,

En attendant un consensus sur l'import du bâti,


Je suis en train de rattraper à la main un revert loupé, mais ça avance ;-)
Désolé pour le dérangement le temps de la réparation...

je trace les lignes du tramway de Rouen (qui est d'ailleurs mi-tramway 
mi-subway) avec ses stations, mais je bloque sur certains points.


1er) Devons nous tracer deux voies l'une à coté de l'autre ou une 
seule voie ? Après avoir fouillé sur le wiki 
(http://wiki.openstreetmap.org/wiki/Tag:railway%3Dtram) je vois qu'il 
est possible de faire les deux, mais je voulais savoir si cela avait 
changé depuis et si il y avait eu un consensus pour la France ?


Les 2/3 du réseau sont tracés avec les 2 voies et les aiguillages, le 
dernier tiers avec 1 seule voie, je vote pour finir les bouts de 2ème 
voie manquants ;-)

(problème dans les tunnels, le cadastre n'indique rien)

Si on est plusieurs à avancer sur Rouen et l'agglo (pardon, la CREA 
:-D), on pourra peut-être se retrouver un de ces 4 ?


--
Frantz



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

Re: [OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet Julien Angot

>  Sur OSMTransport tu peux visualiser l'état de la ligne de tramway de Rouen
> :
> http://3liz.fr/public/osmtransport/index.php?country=France&location=Rouen
>
> Il y a aussi les lignes du TEOR (ligne de bus aménégé ;-)
>
> René-Luc D'Hont
> Ancien Rouennais
>
>
Oui oui je connais, je m'en sert justement. Mais, la ligne Georges
braque-boulingrin n'est constitué que d'un way et technopôle-boulingrin sur
2 way. C'est pour ça que je souhaiterai harmoniser un peu tout cela.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Re : Les adresses... -- dev ient molo molo sur l'anarchie du bâti


esperanza a écrit , Le 25/06/2010 09:11:

Comment fusionner deux bâtiments jointifs dans JOSM rapidement ?
Merci d'avance.
E.


+1 !
moi aussi je me pose la question !

helene


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

Re: [OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet René-Luc D'Hont


Le 25/06/2010 11:07, Julien Angot a écrit :


Sur OSMTransport tu peux visualiser l'état de la ligne de tramway
de Rouen :
http://3liz.fr/public/osmtransport/index.php?country=France&location=Rouen


Il y a aussi les lignes du TEOR (ligne de bus aménégé ;-)

René-Luc D'Hont
Ancien Rouennais


Oui oui je connais, je m'en sert justement. Mais, la ligne Georges 
braque-boulingrin n'est constitué que d'un way et 
technopôle-boulingrin sur 2 way. C'est pour ça que je souhaiterai 
harmoniser un peu tout cela.


Oki compris ;-)
En tout cas ça fait plaisir de voir Rouen avancé ;-)



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


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

[OSM-talk-fr] Bâtiments jointifs


helene a écrit :

esperanza a écrit , Le 25/06/2010 09:11:

Comment fusionner deux bâtiments jointifs dans JOSM rapidement ?
Merci d'avance.
E.


+1 !
moi aussi je me pose la question !

helene


Je vous renvoi un courriel de FrViPofm

--

Pour zoomer sur le problème :
clic-droit sur l'item dans la liste du validator
zoom par le curseur de JOSM plutôt qu'à la molette (à la molette, on a 
des chances de zoomer à côté)


Pour sélectionner deux polygones jointifs :
clic sur le trait mitoyen (le premier polygone est sélectionné) puis 
sans déplacer la souris, maj+alt gr + clic (le second polygone est 
sélectionné aussi)


Pour fusionner deux polygones jointifs ou se chevauchant :
sélection des deux polygones puis maj+J

Je garde l'index de la main gauche au dessus de la touche maj, c'est le 
petit doigt qui navigue de 'alt gr' à 'J'. C'est assez rapide.


--
FrViPofm



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

[OSM-talk-fr] Organisation du wiki

C'est plutôt compliqué de naviguer dans le wiki du projet France, il me 
semble que ce n'est pas une arborescence (au sens mathématique du terme) 
; dites moi si je me trompe.


J'ai aussi un problème pour me retrouver dans les 
.openstreetmap.org, je n'ai pas trouvé l'endroit où se trouve la liste.


merci de votre aide,
helene


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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !


Steven Le Roux a écrit , Le 23/06/2010 11:44:

Et ajouter chaque import dans le "import catalog" sur le wiki ;)


le lien, s'il te plait ?
helene


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

Re: [OSM-talk-fr] Organisation du wiki


helene a écrit :
C'est plutôt compliqué de naviguer dans le wiki du projet France, il 
me semble que ce n'est pas une arborescence (au sens mathématique du 
terme) ; dites moi si je me trompe.


J'ai aussi un problème pour me retrouver dans les 
.openstreetmap.org, je n'ai pas trouvé l'endroit où se trouve la 
liste.


merci de votre aide,
helene
Tu ne te trompe pas (et j'ai ajouté à la confusion en ne sachant pas 
trop ou rattacher une page et en lui donnant un nom non signifiant).
"Faudrait yaka" reprendre l'ensemble pour lui redonner de la cohérence 
et corriger les obsolètes. J'en suis parfaitement incapable pour ma part.


Benoît R.



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

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !


helene a écrit :

Steven Le Roux a écrit , Le 23/06/2010 11:44:

Et ajouter chaque import dans le "import catalog" sur le wiki ;)


le lien, s'il te plait ?
helene

Ca correspond au bas de la page "Import semi auto du bâti", section 
"Suivi des imports".

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents#Suivi_des_imports

Benoît R.

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

Re: [OSM-talk-fr] Bâtiments jointifs

2010-06-25 Par sujet esperanza

Merci, ajouté à l'instant sur le wiki 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents/Aper%C3%A7u_des_erreurs_rencontr%C3%A9es
E.


Le vendredi 25 juin 2010 à 11:16 +0200, Benoît ROUSSEAU a écrit :
> Pour zoomer sur le problème :
> clic-droit sur l'item dans la liste du validator
> zoom par le curseur de JOSM plutôt qu'à la molette (à la molette, on
> a 
> des chances de zoomer à côté)
> 
> Pour sélectionner deux polygones jointifs :
> clic sur le trait mitoyen (le premier polygone est sélectionné) puis 
> sans déplacer la souris, maj+alt gr + clic (le second polygone est 
> sélectionné aussi)
> 
> Pour fusionner deux polygones jointifs ou se chevauchant :
> sélection des deux polygones puis maj+J
> 
> Je garde l'index de la main gauche au dessus de la touche maj, c'est
> le 
> petit doigt qui navigue de 'alt gr' à 'J'. C'est assez rapide. 


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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti

2010-06-25 Par sujet Ab_fab

Je me réponds à moi-même ^^

Pour éviter d'avoir des zones abandonnées de tous, l'idée du bot reste
séduisante, en complément de l'utilisation "en manuel" par les utilisateurs
pressés de voir les batiments apparaitre dans leur secteur.

Cela peut être un bon point de départ pour des utilisateurs pas trop
"techniques" (je me mets dans le lot).
Je m'explique
Si le bot avance commune par commune, on peut lui imposer des priorités ("tu
seras gentil de me traiter mon village avant ceux de ta liste")
Pour l'utilisateur, c'est au moins la garantie que tout le processus
automatisé de l'import se fera le plus sérieusement possible, avec les
scripts les plus sûrs

En mettant quelques garde-fous, qui peuvent être :
Les imports demandés par X sont réalisés par changesets "sous le nom de X",
un peu comme les modifications raw sous Osmose.
Pas plus de n communes (20 ?) par utilisateur dans la file d'attente
Pas plus de n' communes demandées par utilisateur et par jour
Pas forcément du "premier arrivé premier servi". (Ne attendre que les 400
demandes précédente en attente soient traitées pour voir sa première commune
intégrée)
-> mais les demandes d'utilisateurs priment sur "l'automatique exhaustif"

Bon, le Bot-à-Bâti, on y est pas encore ... quoique ;-)

Le 25 juin 2010 10:37, Ab_fab  a écrit :

> J'ai un peu le même feeling
>
> L'utilisation du script est une aide précieuse pour lancer le mapping des
> bâtiments, mais il y a un "service après-vente" à assurer ensuite (affiner
> la nature des batiments).
> Le fonctionnement commune par commune, sur le même mode que pour les
> limites administratives me plait mieux, parce que la personne qui aura
> initié l'import fera très probablement dans la foulée l'insertion des
> informations complémentaires.
>
> Il est nécessaire de bétonner l'outil pour éliminer au plus tôt dans le
> processus d'import les erreurs / artefacts qui auront été identifiés comme
> récurrents et pour lesquels une correction automatique est nécessaire. Sans
> compter les nouvelles fonctions.
>
> D'ailleurs, s'il est possible de lancer une traçabilité de son évolution,
> je vote pour (indice de révision, date). N'étant pas développeur, je suis
> mal placé pour donner la voie à suivre.
> Mais en tant que "end user" potentiel, j'ai envie d'utiliser l'outil le
> plus robuste, qui m'évitera le "Hall of shame" des dupe nodes, et surtout
> d'avoir à passer beaucoup de temps à tout mettre d'équerre.
>
> Idem pour les dépots de fichiers OSM.
> Comment savoir par quelle évolution du script ils ont été générés ?
>
> Honnêtement, même en ayant du temps pour suivre les discussions, je ne sais
> pas où on en est.
> Lever le pied pour intégrer ce genre de choses me parait raisonnable.
>
> La frénésie des jours passés est simplement à la hauteur de l'attente.
> Il semble que tout le monde était dans les starting-blocks.
> Cumulé à l'indisponibilité du site et à la crainte de voir la génération de
> PDF "généreux en infos" disparaitre du site du cadastre, c'est amusant à
> voir :-)
>
>
>
> Le 25 juin 2010 09:57, Balooval  a écrit :
>
> Je tiens juste à apporter mon témoignage:
>>
>> Toute la journée d'hier j'ai importé le bâti d'une quinzaine de village de
>> mon coin ( http://wiki.openstreetmap.org/wiki/France:Gard ). Tout en
>> lisant les message inquiets sur cette liste, inquiets au point
>> qu'aujourd'hui certains suggèrent même de ne plus rendre accessible les
>> fichiers tirés des pdf.
>> Je pense avoir correctement importé les données, je n'ai pas pris trop de
>> risques, m'étant limité aux toutes petites communes (moins de risque de
>> plantage à l'upload, relativement léger à traiter dans josm, et sans
>> batiments préalablement présents).
>>
>> Bref, ce que je voulais dire c'est que pour une fois l'import de données
>> "en masse" est accessible au plus grand nombre. Pas besoin de savoir faire
>> des requêtes PostGre (?), scripts pythons ou autres. Ce n'est pas réservé à
>> "l'élite" (sans animosité aucune!). Voilà pourquoi je pense continuer. Bien
>> sûr je reste attentif a vos messages, comprend qu'une réflexion pourrait
>> améliorer les choses, mais que voulez-vous, je pars du principe qu'il vaut
>> mieux une donnée incomplète que pas de donnée du tout.
>>
>> Et puis ça m'amuse tellement de contribuer que s'il faut repasser sur mes
>> imports ce sera avec plaisir :)
>> A+
>>
>> Le 25 juin 2010 09:19, Pieren  a écrit :
>>
>>> 2010/6/25 Yann SLADEK 
>>>
>>>  Je suis d'accord avec ce qui a été dit, vu le boulot pré import, il doit
 y avoir un moyen de faire ca proprement (facon CLC) et plus rapidement (si
 on veut faire correctement une commune, c'est au moins 1h00)
 Par contre, je pense qu'il serait judicieux de ne plus rendre les
 données accessibles (notamment sur cquest.com)

 Yann


>>> Chercher à améliorer l'outil est, bien entendu, une bonne chose. Mais de
>>> là à demander d'arrêter les contributions actuelles, non. OSM a toujours
>>> fonctionné comme ça, par erreur/corr

Re: [OSM-talk-fr] Bâtiments jointifs

2010-06-25 Par sujet OSM Léon

Je ne suis pas sûr de comprendre ce qui justifie qu'on fusionne deux
bâtiments jointifs. A Paris, de nombreux immeubles sont accolés à leurs
voisins. Mais il s'agit bien de bâtiments différents, ne serait-ce que par
leur hauteur. Pourquoi fusionner deux immeubles voisins ?

Je me suis posé la question puis me suis dit que je ne fusionnerai pas des
bâtiments accolés, pour au moins deux raisons :
- si on arrive un jour par miracle à avoir des tags ele remplis, il faut que
les bâtiments soient distincts. Ou alors la représentation en 3D ne
ressemblera à rien.
- à terme, ça sera plus facile de corriger les bâtiments qui bougent
(travaux)

OK la charge pour la base est plus importante mais je trouve qu'on perd trop
de justesse à fusionner des bâtiments accolés. Après, y a effectivement des
trucs délirants pour les bâtiments un peu "tordus" : je vous invite à aller
voir l'hôpital Robert Debré à Paris :D

Thomas

Le 25 juin 2010 11:36, esperanza  a écrit :

> Merci, ajouté à l'instant sur le wiki
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents/Aper%C3%A7u_des_erreurs_rencontr%C3%A9es
> E.
>
>
> Le vendredi 25 juin 2010 à 11:16 +0200, Benoît ROUSSEAU a écrit :
> > Pour zoomer sur le problème :
> > clic-droit sur l'item dans la liste du validator
> > zoom par le curseur de JOSM plutôt qu'à la molette (à la molette, on
> > a
> > des chances de zoomer à côté)
> >
> > Pour sélectionner deux polygones jointifs :
> > clic sur le trait mitoyen (le premier polygone est sélectionné) puis
> > sans déplacer la souris, maj+alt gr + clic (le second polygone est
> > sélectionné aussi)
> >
> > Pour fusionner deux polygones jointifs ou se chevauchant :
> > sélection des deux polygones puis maj+J
> >
> > Je garde l'index de la main gauche au dessus de la touche maj, c'est
> > le
> > petit doigt qui navigue de 'alt gr' à 'J'. C'est assez rapide.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les adresses...

2010/6/25 Benoît ROUSSEAU 

> Sans garantie aucune, car il tard ou tôt, il est peut être possible
> d'extraire d'autres éléments comme les cimetières... mais je n'ai pas
> vérifié, ne m'en veuillez pas si j'infirme pas la suite.
>
>
Reconnaître le numéro est une chose mais le script ne pourra pas associer
numéro et rue puisqu'il ne connait pas les highway... est-ce que l'idée est
de créer les nodes avec addr:housenumber et de faire une fusion avec les
données osm ou est-ce qu'on le fait dans JOSM automatiquement ou
manuellement ?
L'association automatique peut se résoudre si l'identification de la rue la
plus proche est bien claire (genre la deuxième rue est 10x plus loin que la
première). Mais ça l'est moins près des carrefours. Et encore moins si le
highway est manquant dans OSM...

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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti

2010-06-25 Par sujet sly (sylvain letuffe)

On vendredi 25 juin 2010, helene wrote:
> Benoît ROUSSEAU a écrit , Le 25/06/2010 01:42:
> > Nous gagnerions du temps à en perdre à réfléchir et nous organiser.
> 
> C'est toujours vrai, quoi qu'on fasse.

Je propose la page suivante pour le regroupement des réflexions et des 
motivés :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_automatique_des_bâtiments

(J'espère qu'il y aura plus de succès que pour les réserves naturelles ;-) )


-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

[OSM-talk-fr] ODbL et compatibilité avec sources actuelles

Bonjour,

J'aimerais que l'on résolve assez rapidement la question de la migration
CC-By-SA2.0 vers ODbl et des sources actuelles en France. En particulier, il
faudra mettre à jour le wiki sur les imports:
http://wiki.openstreetmap.org/wiki/Import/Catalogue

pour qu'ensuite la migration ne fasse pas disparaître la moitié des données
sur la France.

Pour l'essentiel, je pense qu'il n'y a pas de problème légal puisque nos
sources ne sont pas publiées sous CC-BY-SA2.0 mais sous des licenses
publiques qui sont compatibles. Comme les termes essentiels ne changent pas,
il ne devrait pas être nécessaire de reformuler des demandes auprès des
administrations concernées (même si je sais que cela rassurerait certains
mais je pense personnellement que la démarche est inutile voir
contre-productive si nous ne recevons aucune réponse).

Pour Corine Land Cover, l'essentiel a été ajouté sous le compte utilisateur
CLCF donc je pourrais accepter la nouvelle license directement.
(license compatible au niveau européen et voir aussi
http://lists.openstreetmap.org/pipermail/talk-fr/2009-May/009070.html)

Pour les points géodésiques, c'est une license PD:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques/Autorisation
il faudra donc juste s'assurer que celui qui a fait l'import accepte la
nouvelle license (Eric ?)

Pour les imports du cadastre au niveau des collectivités (BMO), la question
se pose comme pour le cadastre en général. Là encore, je ne pense pas qu'il
y ait d'obstacle puisque la clause principale est que le produit final est
composite et que l'on mentionne la source et le millésime. Je ne vois pas
d'incompatibilité avec ODbL sur ces points et donc là-aussi, il suffira que
les auteurs des petits (beaucoup de monde) et grands imports (Steven et
François ?) acceptent la migration de license eux-mêmes.

Reste le geolitoral qui est encore sous-exploité et qui ne figure même pas
dans ce tableau... et d'autres sources potentielles à venir mais qui
devraient déjà tenir compte de la transition vers ODbL.

Il manque peut-être comme source un import des sommets montagneux mais je
n'en suis pas sûr. Sly ?

Est-ce que vous voyez un inconvénient à ce que je mette "OK" pour toutes les
sources en France dans ce tableau ?

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

Re: [OSM-talk-fr] Bâtiments jointifs

2010-06-25 Par sujet Nicolas Dandrimont

* OSM Léon  [2010-06-25 12:29:58 +0200]:

> Je ne suis pas sûr de comprendre ce qui justifie qu'on fusionne deux
> bâtiments jointifs. A Paris, de nombreux immeubles sont accolés à leurs
> voisins. Mais il s'agit bien de bâtiments différents, ne serait-ce que par
> leur hauteur. Pourquoi fusionner deux immeubles voisins ?
> 
> Je me suis posé la question puis me suis dit que je ne fusionnerai pas des
> bâtiments accolés, pour au moins deux raisons :
> - si on arrive un jour par miracle à avoir des tags ele remplis, il faut que
> les bâtiments soient distincts. Ou alors la représentation en 3D ne
> ressemblera à rien.
> - à terme, ça sera plus facile de corriger les bâtiments qui bougent
> (travaux)
> 
> OK la charge pour la base est plus importante mais je trouve qu'on perd trop
> de justesse à fusionner des bâtiments accolés. Après, y a effectivement des
> trucs délirants pour les bâtiments un peu "tordus" : je vous invite à aller
> voir l'hôpital Robert Debré à Paris :D

Salut,

Il me semble que la fusion est surtout pertinente dans le cas où il
s'agit d'un seul immeuble coupé en plusieurs bouts par une limite
parcellaire (j'ai eu le cas à Cachan, où le campus de l'ENS a été
rapiécé à partir de différentes parcelles, et où des bâtiments ont été
construit à cheval sur la limite).

Bonne journée,
-- 
Nicolas Dandrimont

"...Deep Hack Mode--that mysterious and frightening state of
consciousness where Mortal Users fear to tread."
(By Matt Welsh)


signature.asc
Description: Digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ODbL et compatibilité avec source s actuelles

2010-06-25 Par sujet sly (sylvain letuffe)

On vendredi 25 juin 2010, Pieren wrote:
> Il manque peut-être comme source un import des sommets montagneux mais je
> n'en suis pas sûr. Sly ?

Je n'ai rien importé de tel, cette question en restée en suspend avec les 
données en provenance de camp2camp car il n'avait pû être confirmé ou infirmé 
qu'elles pouvaient être tintées de saisie faites sur géoportail ou sur google 
maps.

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org

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

Re: [OSM-talk-fr] ODbL et compatibilité avec sources actuelles

2010/6/25 Pieren 

Ah ben voila, le dernier message de Sly nous le rappelle. Il faut aussi
ajouter les réserves naturelles de l'INPN:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles

qui ne figure pas non-plus dans ce tableau (mais peut-être aussi pas dans
OSM non-plus :-(

Sly, ça en est où de cet import ?

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

Re: [OSM-talk-fr] ODbL et compatibilité avec source s actuelles

2010-06-25 Par sujet sly (sylvain letuffe)

On vendredi 25 juin 2010, Pieren wrote:
> 2010/6/25 Pieren 
> 
> Ah ben voila, le dernier message de Sly nous le rappelle. Il faut aussi
> ajouter les réserves naturelles de l'INPN:
> 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles
> 
> qui ne figure pas non-plus dans ce tableau (mais peut-être aussi pas dans
> OSM non-plus :-(
> 
> Sly, ça en est où de cet import ?

De mon coté, moins ma blague à deux balles sur la page discussion, c'est au 
point mort. J'ai appelé des renforts, mais j'ai l'impression d'être un 
palestinien (personne n'a répondu présent).

Il s'avère que les données sont bien moins homogène que j'avais espéré, on est 
bien loin de CLC et ça demande presque de faire du cas par cas, donc du 
débat, donc du temps.

En bref, y'a rien dans osm à part un seul import d'une seule réserve pour 
laquelle j'ai eu l'accord "de mettre dans osm" :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_régionaux,_réserves_naturelles/Imports_localisés

Donc pas de problème pour l'ODBL

-- 
sly
Sylvain Letuffe sylv...@letuffe.org
qui suis-je : http://slyserv.dyndns.org



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

Re: [OSM-talk-fr] Bâtiments jointifs

2010-06-25 Par sujet Christian Quest

Joindre des bouts de bâtiments est aussi un moyen de supprimer des
chevauchements, mais tout cela se fait bâtiment par bâtiment en faisant en
plus attention aux parties avec "wall=no".
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les adresses...





Pieren a écrit :

  2010/6/25 Benoît ROUSSEAU 
  Sans
garantie aucune, car il tard ou tôt, il est peut être possible
d'extraire d'autres éléments comme les cimetières... mais je n'ai pas
vérifié, ne m'en veuillez pas si j'infirme pas la suite.




  
  
  
Reconnaître le numéro est une chose mais le script ne pourra pas
associer numéro et rue puisqu'il ne connait pas les highway... est-ce
que l'idée est de créer les nodes avec addr:housenumber et de faire une
fusion avec les données osm ou est-ce qu'on le fait dans JOSM
automatiquement ou manuellement ? 
L'association automatique peut se résoudre si l'identification de la
rue la plus proche est bien claire (genre la deuxième rue est 10x plus
loin que la première). Mais ça l'est moins près des carrefours. Et
encore moins si le highway est manquant dans OSM...
  
Pieren

Bonjour Pieren,

    C'est bien ce que je disais quand je me suis lancer sur l'affaire.
Peut être un peu trop en raccourci.

 Une connexion via l'api est un mieux, chercher la voie la plus
proche si elle existe et faire l'import de ce qui semble correcte.
Sinon pour moi perso, un bricolage intermédiaire me facilitera la vie.

    Je vous donnerai tout pour ceux qui veulent, transposer sur
d'autres langages, d'autres éléments, allez plus loin, ...

    Pour tous, ce n'est pas fait ! Mais je reconnais quasi tous les
premiers chiffres et leurs emplacements (je suis en cours de
séquencage). Une fois les nombres reconnus et placés on prendra le
temps...

Benoît R.



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

[OSM-talk-fr] Import des données INPN (was: ODbL et compatibilité avec sources actuelles)

2010-06-25 Par sujet Damouns

Bonjour,

Pour faire écho aux messages sur le (non-)avancement de l'import des
données INPN, je me permets de faire un appel à commentaires dans la
page de discussion du projet
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN

Damouns

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

Re: [OSM-talk-fr] Les adresses...

2010-06-25 Par sujet Vincent de Chateau-Thierry



Bonjour,

> De : "Pieren"
> 
> Reconnaître le numéro est une chose mais le script ne pourra pas associer 
> numéro et rue
> puisqu'il ne connait pas les highway... est-ce que l'idée est de créer les 
> nodes avec
> addr:housenumber et de faire une fusion avec les données osm ou est-ce qu'on 
> le fait 
> dans JOSM automatiquement ou manuellement ?
> L'association automatique peut se résoudre si l'identification de la rue la 
> plus proche 
> est bien claire (genre la deuxième rue est 10x plus loin que la première). 
> Mais ça l'est 
> moins près des carrefours. Et encore moins si le highway est manquant dans 
> OSM...

Sans parler de l'association au bon building. Il n'y a aucune logique de 
proximité qui 
tienne la route pour dire qu'un numéro est associé au building le plus proche. 
Un numéro
sur le cadastre sera par endroits plus près du bâtiment qui se trouve de 
l'autre côté de
la rue, ou plus près du garage du voisin, en bord de rue, que de la bonne 
maison, en retrait, voire près du bâtiment en façade de rue alors que la 
bâtiment concerné est 
masqué derrière. Autant de cas très communs en zone pavillonnaire ancienne, où 
de
vieilles parcelles ont été coupées en 2, constituant 2 parcelles l'une derrière 
l'autre 
vues de la rue. Et là, à part l'oeil et le décodage du terrain et/ou du 
cadastre, je ne 
vois pas. 

Donc avant de publier un algo, du test, du test, du test, et que le constat 
dressé en 
cette fin de folle semaine nous serve au moins à ne pas nous ruer à nouveau. 

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net


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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti


Le 25/06/2010 09:57, Balooval a écrit :


 je pars du principe qu'il vaut mieux une donnée incomplète que pas de 
donnée du tout.

Hou là! Je vais relativiser ce propos.
À priori, je suis tout à fait d'accord. Ma phrase "OSM est mieux 
aujourd'hui qu'hier et moins bien que demain" a même été épinglée dans 
les "Fortunes"


Cependant...
Ces jours ci, j'ai fait de l'import CLC à haute dose. Et je peste !

Des forêts ont été cartographiées à partir de Yahoo autrefois, dans le 
temps où on ne pensait pas disposer de Corine Land Cover. Et c'était bien.
C'était bien de cartographier à partir de ce qui est à disposition, 
l'imagerie Yahoo.


Par prudence, lors de l'import Corine, nous n'avons pas importé de 
polygones risquant de recouvrir des polygones existants. Longue 
discussion à ce sujet. Une position a été arrêtée, à partir de tel tau 
de recouvrement, on n'importe pas. Quelques uns (dont moi) ont masqué 
les landuses existant pour permettre l'import CLC.


Aujourd'hui, je peste ! Non pas après tel ou tel qui a bien fait de 
cartographier à partir de Yahoo.
Je peste parce qu'il reste 10 polygones Corine non importé et que je 
fais les remplacements un par un à la main.
Je peste parce que, probablement, nous aurions du prendre un peu plus de 
temps pour faire place nette et permettre à Corine de s'installer un peu 
mieux.


Donc, concernant le bâti. Bien sur, c'est bon d'importer du bâti, c'est 
mieux avec que sans...
Mais, aujourd'hui où nous avons une méthode permettant l'import en 
masse, ne nous précipitions pas pour, ensuite, devoir reprendre 10 
polygones à la main pour y ajouter, à l'un le tag 'townhall', à l'autre 
le tag 'place_of_worship', à celui-ci modifier le tag building en 
'appartment', à celui-là en 'store', alors qu'un outil dans le flux 
permettrait de le mettre à 80% (chiffre suggestif plus qu'autre chose) .


Il reste du boulot pour les fourmis (il y a 3-4 mois, je ne maniais pas 
la requête SQL postgis et je n'avais pas goûté au python) !
* Ce que je crois possible, c'est de mettre une étape de plus dans le 
flux pour enrichir le fichier .osm. Chacun alors pourra bénéficier d'un 
fichier osm par commune à intégrer à la base, comme aujoud'hui. Mais ce 
fichier sera plus riche que le fichier produit actuellement.

* Ce qui me semble alors nécessaire, c'est
** de faire une page wiki pour rassembler les suggestions (comme nous 
avions fait une page 'nomenclature' pour CLC)

** de trouver des codeurs pour faire cet outils à inclure dans le flux
** de produire des outils de suivi : genre beta.letuffe#admin_level=8, 
puisqu'on fonctionne par commune,
** de produire des outils de post-production : genre clc.osmose 
puisqu'on fonctionne sur des polygones


Tim Berner Lee, à propos du Web², affirme que plus il y a de données 
disponibles, plus les nouvelles données prennent du sens. Nous avons 
déjà des données riches (notamment les repères géodésiques, mais j'en 
oublie certainement). Celles que nous importons comportent aussi de 
l'information riche. Nous avons moyens de faire que notre import soit 
encore plus riche que simplement ajouter du bâti, avec en option "wall=no".
Nous avons moyen, à l'occasion de cet import, que chaque village importé 
(à 80 %) se trouve doté d'une mairie, d'une église, d'un cimetière, d'un 
monument au mort, d'un calvaire, d'un château d'eau...
36000 communes, 3 tags par communes. On est bien aux 10 que 
j'évoquais plus haut. Vous voulez ajouter ces tags à la main ?


- Je ne me précipite pas à importer, étant convaincu que nous allons 
produire de tels outils
- Maintenant que je tâte un peu la requête, je suis prêt à prendre un 
peu de temps pour participer à de tels outils
- avec pas loin de 600 communes dans le Doubs, je suis convaincu de la 
nécessité d'avoir un outil qui me fera moins travailler par la suite, et 
qui m'évitera de pousser des jurons au moment d'effacer des villages, de 
reporter des tags d'un calque à l'autre.

--
FrViPofm

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

Re: [OSM-talk-fr] Les adresses...


> L'association automatique peut se résoudre si l'identification de
> la
> rue la plus proche est bien claire (genre la deuxième rue est 10x
> plus
> loin que la première).

Je pense que le monde réel est plein de cas particulier qui font que c'est
dangereux d'avoir un robot-robot pour ca.
Si c'est un robot avec verif humaine pourquoi pas...

-- 
JB


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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti

J'ai pas saisi ta réflexion sur les townhall, églises et tout et tout.
Je pense que la connaissance du terrain est nécessaire, plus que pour
simplement importer ouatmilles polygones.
Mais en même temps je ne doute pas que la présence des bâtiments incite
fortement à la contribution : calage des routes, ajout de POI facilités etc.

Ce qui est sûr c'est que beaucoup d'uploader (comme moi) vont s'arrêter
passé leur "zone de prédilection" qui doit représenter une vingtaine de
communes.
Encore une fois ne soyons pas si alarmiste, la plus part des communes que
j'ai importé avait des bâtiments sans overlap, quelques nœuds/chemins
dupliqués, plus vicieux des bâtiments superposés (plusieurs niveaux ?). Mais
finalement peut de retouches.

2010/6/25 Vincent Pottier 

> Le 25/06/2010 09:57, Balooval a écrit :
>
>
>>  je pars du principe qu'il vaut mieux une donnée incomplète que pas de
>> donnée du tout.
>>
> Hou là! Je vais relativiser ce propos.
> À priori, je suis tout à fait d'accord. Ma phrase "OSM est mieux
> aujourd'hui qu'hier et moins bien que demain" a même été épinglée dans les
> "Fortunes"
>
> Cependant...
> Ces jours ci, j'ai fait de l'import CLC à haute dose. Et je peste !
>
> Des forêts ont été cartographiées à partir de Yahoo autrefois, dans le
> temps où on ne pensait pas disposer de Corine Land Cover. Et c'était bien.
> C'était bien de cartographier à partir de ce qui est à disposition,
> l'imagerie Yahoo.
>
> Par prudence, lors de l'import Corine, nous n'avons pas importé de
> polygones risquant de recouvrir des polygones existants. Longue discussion à
> ce sujet. Une position a été arrêtée, à partir de tel tau de recouvrement,
> on n'importe pas. Quelques uns (dont moi) ont masqué les landuses existant
> pour permettre l'import CLC.
>
> Aujourd'hui, je peste ! Non pas après tel ou tel qui a bien fait de
> cartographier à partir de Yahoo.
> Je peste parce qu'il reste 10 polygones Corine non importé et que je
> fais les remplacements un par un à la main.
> Je peste parce que, probablement, nous aurions du prendre un peu plus de
> temps pour faire place nette et permettre à Corine de s'installer un peu
> mieux.
>
> Donc, concernant le bâti. Bien sur, c'est bon d'importer du bâti, c'est
> mieux avec que sans...
> Mais, aujourd'hui où nous avons une méthode permettant l'import en masse,
> ne nous précipitions pas pour, ensuite, devoir reprendre 10 polygones à
> la main pour y ajouter, à l'un le tag 'townhall', à l'autre le tag
> 'place_of_worship', à celui-ci modifier le tag building en 'appartment', à
> celui-là en 'store', alors qu'un outil dans le flux permettrait de le mettre
> à 80% (chiffre suggestif plus qu'autre chose) .
>
> Il reste du boulot pour les fourmis (il y a 3-4 mois, je ne maniais pas la
> requête SQL postgis et je n'avais pas goûté au python) !
> * Ce que je crois possible, c'est de mettre une étape de plus dans le flux
> pour enrichir le fichier .osm. Chacun alors pourra bénéficier d'un fichier
> osm par commune à intégrer à la base, comme aujoud'hui. Mais ce fichier sera
> plus riche que le fichier produit actuellement.
> * Ce qui me semble alors nécessaire, c'est
> ** de faire une page wiki pour rassembler les suggestions (comme nous
> avions fait une page 'nomenclature' pour CLC)
> ** de trouver des codeurs pour faire cet outils à inclure dans le flux
> ** de produire des outils de suivi : genre beta.letuffe#admin_level=8,
> puisqu'on fonctionne par commune,
> ** de produire des outils de post-production : genre clc.osmose puisqu'on
> fonctionne sur des polygones
>
> Tim Berner Lee, à propos du Web², affirme que plus il y a de données
> disponibles, plus les nouvelles données prennent du sens. Nous avons déjà
> des données riches (notamment les repères géodésiques, mais j'en oublie
> certainement). Celles que nous importons comportent aussi de l'information
> riche. Nous avons moyens de faire que notre import soit encore plus riche
> que simplement ajouter du bâti, avec en option "wall=no".
> Nous avons moyen, à l'occasion de cet import, que chaque village importé (à
> 80 %) se trouve doté d'une mairie, d'une église, d'un cimetière, d'un
> monument au mort, d'un calvaire, d'un château d'eau...
> 36000 communes, 3 tags par communes. On est bien aux 10 que j'évoquais
> plus haut. Vous voulez ajouter ces tags à la main ?
>
> - Je ne me précipite pas à importer, étant convaincu que nous allons
> produire de tels outils
> - Maintenant que je tâte un peu la requête, je suis prêt à prendre un peu
> de temps pour participer à de tels outils
> - avec pas loin de 600 communes dans le Doubs, je suis convaincu de la
> nécessité d'avoir un outil qui me fera moins travailler par la suite, et qui
> m'évitera de pousser des jurons au moment d'effacer des villages, de
> reporter des tags d'un calque à l'autre.
> --
> FrViPofm
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-

Re: [OSM-talk-fr] Import Bâti ! AAAAARg ! Doucement ! STOOP !


Benoît ROUSSEAU a écrit , Le 25/06/2010 11:33:

http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents#Suivi_des_imports


Merci !

Dans cette page, je vois que l'import du département 31 est réalisé par 
osm42 (quel joli nom !) en lambert 4 zones ;
pour ma part, quand j'utilise le plugin cadasdre, je le mets en zone 2 
du lambert 9 zones.
c'est aussi avec ce paramètrage que j'ai fait le prélèvement de ma 
commune, qui se révèle correct.


Hélène


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

[OSM-talk-fr] ligne de cote

en utilisant le WMS du geolitorral (merci pieren)
j'ai commencer à modifier la ligne de cote a belle ile
http://osm.org/go/eqeeElkKv-?layers=B000FFF
mais il semble que j'ai oublié kkchose car si la ligne de cote et les
relations associé (limite administrative) ont bien bougé,
autant le "sol" ne semble pas avoir suivi.

Les polygones CLC, je comprends.
Si j'avais flingué une relation qui decrit la surface comme une ile
(exclave), j'aurais compris.
Mais le fait que le sol ne suive pas la "coastline", je suis surpris.

Est ce qu'il faut re-importer la ligne de cote dans un outil externe qui
fait kkchose de spécial au niveau du rendu ?


-- 
JB


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

Re: [OSM-talk-fr] Import semi-automatique du bâti

2010-06-25 Par sujet Tanguy JACQ

Bonjour,

J'ai un souci avec le script qui me renvoi l'erreur "Pas de code commune"

~/Documents/Bati$ sh import-bati.sh [035] [POILLEY] [Bati] [3948]
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed
100 137210 137210 0  34741  0 --:--:-- --:--:-- --:--:--
77519
  % Total% Received % Xferd  Average Speed   TimeTime Time
Current
 Dload  Upload   Total   SpentLeft
Speed
101 132260 132260   128  33082320 --:--:-- --:--:-- --:--:--
70800
CODE=
Pas de code de commune

J'ai tout essayé, avec les crochets, sans les crochets, avec les guillemets
pour la commune etc  mais rien à faire ça ne veut pas marcher chez moi


La commune est pourtant bien vectorisé

Je ne comprends pas 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les adresses...

Un plugin ou l'on sélectionnerais un bâtiment/node avec tout ce qui faut
renseigné, puis un clic sur le deuxième ou serait copié les attributs
d'adresse avec incrémentions automatique du numéro. J'envoie ma caisse de
bières/limonade au magicien qui le coderait :q

2010/6/25 

>
> > L'association automatique peut se résoudre si l'identification de
> > la
> > rue la plus proche est bien claire (genre la deuxième rue est 10x
> > plus
> > loin que la première).
>
> Je pense que le monde réel est plein de cas particulier qui font que c'est
> dangereux d'avoir un robot-robot pour ca.
> Si c'est un robot avec verif humaine pourquoi pas...
>
> --
> JB
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Mon weblog - http://www.tenshu.fr/
Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tramway de Rouen


Le 25/06/2010 11:07, Julien Angot a écrit :
Oui oui je connais, je m'en sert justement. Mais, la ligne Georges 
braque-boulingrin n'est constitué que d'un way et 
technopôle-boulingrin sur 2 way. C'est pour ça que je souhaiterai 
harmoniser un peu tout cela.
   
Puisque les deux peuvent se faire, je suis sur qu'à terme, avec le 
micromapping, il y aura dans osm deux voies là où elles existent sur le 
terrain, autant entrer deux voies dès maintenant lorsque c'est possible. 
Ça permettra de cartographier les quais liés à chacune des voies.


La phrase du jour :
Plus un objet est entré avec précision, plus il permet d'avoir de la 
précision pour entrer l'environnement.

La précision, c'est l'exhaustivité, les tags, la géométrie...
--
FrViPofm


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

Re: [OSM-talk-fr] Import semi-automatique du bâti

$sh import-bati.sh 035 "POILLEY" Bati 3948

2010/6/25 Tanguy JACQ 

>
>
> Bonjour,
>
> J'ai un souci avec le script qui me renvoi l'erreur "Pas de code commune"
>
> ~/Documents/Bati$ sh import-bati.sh [035] [POILLEY] [Bati] [3948]
>
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 100 137210 137210 0  34741  0 --:--:-- --:--:-- --:--:--
> 77519
>
>   % Total% Received % Xferd  Average Speed   TimeTime Time
> Current
>  Dload  Upload   Total   SpentLeft
> Speed
> 101 132260 132260   128  33082320 --:--:-- --:--:-- --:--:--
> 70800
> CODE=
>
> Pas de code de commune
>
> J'ai tout essayé, avec les crochets, sans les crochets, avec les guillemets
> pour la commune etc  mais rien à faire ça ne veut pas marcher chez moi
> 
>
> La commune est pourtant bien vectorisé
>
> Je ne comprends pas 
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Mon weblog - http://www.tenshu.fr/
Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet Emilie Laffray

2010/6/25 Vincent Pottier 

> Le 25/06/2010 11:07, Julien Angot a écrit :
>
>> Oui oui je connais, je m'en sert justement. Mais, la ligne Georges
>> braque-boulingrin n'est constitué que d'un way et technopôle-boulingrin sur
>> 2 way. C'est pour ça que je souhaiterai harmoniser un peu tout cela.
>>
>>
> Puisque les deux peuvent se faire, je suis sur qu'à terme, avec le
> micromapping, il y aura dans osm deux voies là où elles existent sur le
> terrain, autant entrer deux voies dès maintenant lorsque c'est possible. Ça
> permettra de cartographier les quais liés à chacune des voies.
>
> La phrase du jour :
> Plus un objet est entré avec précision, plus il permet d'avoir de la
> précision pour entrer l'environnement.
> La précision, c'est l'exhaustivité, les tags, la géométrie...
>

Tu cherches a figurer une nouvelle fois dans Fortunes? :)

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tramway de Rouen

2010-06-25 Par sujet Emilie Laffray

2010/6/25 Vincent Pottier 

> Le 25/06/2010 11:07, Julien Angot a écrit :
>
>> Oui oui je connais, je m'en sert justement. Mais, la ligne Georges
>> braque-boulingrin n'est constitué que d'un way et technopôle-boulingrin sur
>> 2 way. C'est pour ça que je souhaiterai harmoniser un peu tout cela.
>>
>>
> Puisque les deux peuvent se faire, je suis sur qu'à terme, avec le
> micromapping, il y aura dans osm deux voies là où elles existent sur le
> terrain, autant entrer deux voies dès maintenant lorsque c'est possible. Ça
> permettra de cartographier les quais liés à chacune des voies.
>
> La phrase du jour :
> Plus un objet est entré avec précision, plus il permet d'avoir de la
> précision pour entrer l'environnement.
> La précision, c'est l'exhaustivité, les tags, la géométrie...
>

Ou de manière moins subtile, Garbage In Garbage Out :)

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import semi-automatique du bâti

2010-06-25 Par sujet Tanguy JACQ

Merci .


Le 25 juin 2010 15:13, Tenshu  a écrit :

> $sh import-bati.sh 035 "POILLEY" Bati 3948
>
> 2010/6/25 Tanguy JACQ 
>
>>
>>
>> Bonjour,
>>
>> J'ai un souci avec le script qui me renvoi l'erreur "Pas de code commune"
>>
>> ~/Documents/Bati$ sh import-bati.sh [035] [POILLEY] [Bati] [3948]
>>
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>> Current
>>  Dload  Upload   Total   SpentLeft
>> Speed
>> 100 137210 137210 0  34741  0 --:--:-- --:--:-- --:--:--
>> 77519
>>
>>   % Total% Received % Xferd  Average Speed   TimeTime Time
>> Current
>>  Dload  Upload   Total   SpentLeft
>> Speed
>> 101 132260 132260   128  33082320 --:--:-- --:--:-- --:--:--
>> 70800
>> CODE=
>>
>> Pas de code de commune
>>
>> J'ai tout essayé, avec les crochets, sans les crochets, avec les
>> guillemets pour la commune etc  mais rien à faire ça ne veut pas marcher
>> chez moi 
>>
>> La commune est pourtant bien vectorisé
>>
>> Je ne comprends pas 
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Mon weblog - http://www.tenshu.fr/
> Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import des données INPN (was: ODbL et compatibilité avec sources actuelles)


Damouns a écrit :

Bonjour,

Pour faire écho aux messages sur le (non-)avancement de l'import des
données INPN, je me permets de faire un appel à commentaires dans la
page de discussion du projet
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN

Damouns

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

Juste un commentaire général. J'avais regardé, rapidement, il y a peu si 
je pouvais aider...


J'ai tout de suite douté car je n'arrive pas à déterminer facilement ce 
que je pourrai faire :
- les fichiers sont dans plusieurs formats dont certains que je ne 
connais pas ou dont je n'ai pas les outils pour. Je ne sais pas 
exactement de quel fichier partir,
- je n'ai aucune idée du nécessaire pour faire (OS, ram, outils 
[nulk_uplod/JOSM]) ni du temps que cela pourrait prendre pour faire une 
petite chose,
- je ne connais rien au parcs naturels donc je ne vais pas m'insérer 
dans les décisions discutées.


Donc au final j'ai lâché l'affaire :(.

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

Re: [OSM-talk-fr] Les adresses...


Le 25/06/2010 14:39, jul...@krilin.org a écrit :

L'association automatique peut se résoudre si l'identification de
la
rue la plus proche est bien claire (genre la deuxième rue est 10x
plus
loin que la première).
 

Je pense que le monde réel est plein de cas particulier qui font que c'est
dangereux d'avoir un robot-robot pour ca.
Si c'est un robot avec verif humaine pourquoi pas...

   
Est-il possible de renseigner un tag metadata sur la fiabilité de 
l'euristique ? genre note:import_addr_street=[0-1]
Ça permet de faire du "robot-robot" au delà de 0.8, avec correction a 
posteriori (tau d'erreur faible), "robot-humain" (validation) de 0.3 à 
0.7, et de l'humain-humain en dessous de 0.2 (cas du carrefour). Bon on 
peut se mettre une lettre plutôt qu'une valeur. A=OK, B=moyen, C=pas 
trouvé. C'est plus facile à sélectionner en masse dans JOSM pour changer 
de calque.

--
FrViPofm

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

Re: [OSM-talk-fr] Les adresses...


Le 25/06/2010 15:12, Tenshu a écrit :
Un plugin ou l'on sélectionnerais un bâtiment/node avec tout ce qui 
faut renseigné, puis un clic sur le deuxième ou serait copié les 
attributs d'adresse avec incrémentions automatique du numéro. J'envoie 
ma caisse de bières/limonade au magicien qui le coderait :q

+1
Si nombre d'infos a été introduit avant dans le fichier, ça aidera le 
plugin et son opérateur.

--
FrViPofm

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

Re: [OSM-talk-fr] ligne de cote


Le 25/06/2010 15:08, jul...@krilin.org a écrit :

en utilisant le WMS du geolitorral (merci pieren)
j'ai commencer à modifier la ligne de cote a belle ile
http://osm.org/go/eqeeElkKv-?layers=B000FFF
mais il semble que j'ai oublié kkchose car si la ligne de cote et les
relations associé (limite administrative) ont bien bougé,
autant le "sol" ne semble pas avoir suivi.

Les polygones CLC, je comprends.
Si j'avais flingué une relation qui decrit la surface comme une ile
(exclave), j'aurais compris.
Mais le fait que le sol ne suive pas la "coastline", je suis surpris.

Est ce qu'il faut re-importer la ligne de cote dans un outil externe qui
fait kkchose de spécial au niveau du rendu

Il s'agit du rendu mapnik ?
Celui-ci se base sur un fichier "coastline" externe à la base de donnée 
et contrôlé semi-automatiquement de temps en temps (rythme hebdomadaire, 
je crois). Donc pas de prise en compte immédiate.

--
FrViPofm

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

Re: [OSM-talk-fr] ligne de cote

2010/6/25 Vincent Pottier 

> Il s'agit du rendu mapnik ?
> Celui-ci se base sur un fichier "coastline" externe à la base de donnée et
> contrôlé semi-automatiquement de temps en temps (rythme hebdomadaire, je
> crois). Donc pas de prise en compte immédiate.
> --
> FrViPofm
>
>
Voir aussi:
http://wiki.openstreetmap.org/wiki/Coastline#Main_Mapnik_Layer

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

Re: [OSM-talk-fr] ligne de cote

>>
>> Est ce qu'il faut re-importer la ligne de cote dans un outil externe qui
>> fait kkchose de spécial au niveau du rendu
> Il s'agit du rendu mapnik ?

anéfé, si je switch vers le rendo osmaRender, c'est impec

> Celui-ci se base sur un fichier "coastline" externe à la base de donnée
> et contrôlé semi-automatiquement de temps en temps (rythme hebdomadaire,
> je crois). Donc pas de prise en compte immédiate.

ok, si il suffit d'attendre
J'avais peut d'avoir fait une c*nnerie.

Merci
-- 
JB


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

Re: [OSM-talk-fr] Les adresses...

2010-06-25 Par sujet Eric Sibert


Et encore moins si le
highway est manquant dans OSM...


Oui mais justement l'avantage des imports massifs du bâti, c'est qu'on  
voit beaucoup plus facilement les rues qui manquent ;-)


De là dire qu'on met la charrue avant les boeufs...



Eric


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

Re: [OSM-talk-fr] Organisation du wiki


Le 25/06/2010 11:18, helene a écrit :
C'est plutôt compliqué de naviguer dans le wiki du projet France, il 
me semble que ce n'est pas une arborescence (au sens mathématique du 
terme) ; dites moi si je me trompe.

Ah, l'organisation du wiki. Tout un poème...


J'ai aussi un problème pour me retrouver dans les 
.openstreetmap.org, je n'ai pas trouvé l'endroit où se trouve la 
liste.

Je ne suis pas sur qu'une liste existe.
J'ai démaré :
http://wiki.openstreetmap.org/wiki/Domain_names#Sub-domains
À compléter avec tes découvertes


merci de votre aide,

De rien
--
FrViPofm

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

Re: [OSM-talk-fr] ODbL et compatibilité avec sources a ctuelles

2010-06-25 Par sujet Eric Sibert


Pour les points géodésiques, c'est une license PD:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques/Autorisation
il faudra donc juste s'assurer que celui qui a fait l'import accepte la
nouvelle license (Eric ?)


Oui, je suis le maillon terminal de l'import. En ce qui me concerne,  
la question de la nouvelle licence ne se pose même pas. Donc, c'est  
OK. Je mets à jour le wiki de migration.




Eric


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

Re: [OSM-talk-fr] Les adresses...


Vincent Pottier a écrit :

Le 25/06/2010 14:39, jul...@krilin.org a écrit :

L'association automatique peut se résoudre si l'identification de
la
rue la plus proche est bien claire (genre la deuxième rue est 10x
plus
loin que la première).
 
Je pense que le monde réel est plein de cas particulier qui font que 
c'est

dangereux d'avoir un robot-robot pour ca.
Si c'est un robot avec verif humaine pourquoi pas...

   
Est-il possible de renseigner un tag metadata sur la fiabilité de 
l'euristique ? genre note:import_addr_street=[0-1]
Ça permet de faire du "robot-robot" au delà de 0.8, avec correction a 
posteriori (tau d'erreur faible), "robot-humain" (validation) de 0.3 à 
0.7, et de l'humain-humain en dessous de 0.2 (cas du carrefour). Bon 
on peut se mettre une lettre plutôt qu'une valeur. A=OK, B=moyen, 
C=pas trouvé. C'est plus facile à sélectionner en masse dans JOSM pour 
changer de calque.

--
FrViPofm

Oui c'est possible mais pas infaillible. Je pensais mettre un fixme + 
note. mais on n'en est pas là :p. On va déjà voir ce que ça donne.


Beno^^it R.


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

Re: [OSM-talk-fr] ODbL et compatibilité avec sources actuelles

Ça va pas être très constructif ce que je vais dire.
Mais je suis très en colère contre ce projet d'effacer des données.
Je suis très en colère que le sondage qui avait été mis en place sans
mentionner ce point serve d'appui au changement.

Ça va (surement) être une catastrophe si jamais cela se faisait, combien de
data est il raisonnable de perdre 5%10% 20% ?
Parfois je me dit que moins de personne accepteront une telle migration aux
forceps, moins ce cauchemar à de chance de se réaliser.

2010/6/25 Eric Sibert 

> Pour les points géodésiques, c'est une license PD:
>>
>> http://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques/Autorisation
>> il faudra donc juste s'assurer que celui qui a fait l'import accepte la
>> nouvelle license (Eric ?)
>>
>
> Oui, je suis le maillon terminal de l'import. En ce qui me concerne, la
> question de la nouvelle licence ne se pose même pas. Donc, c'est OK. Je mets
> à jour le wiki de migration.
>
>
>
> Eric
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Mon weblog - http://www.tenshu.fr/
Je soutiens le Logiciel Libre, j'adhère à l'APRIL !
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les adresses...

2010-06-25 Par sujet Clement Menier


Tenshu wrote:
Un plugin ou l'on sélectionnerais un bâtiment/node avec tout ce qui 
faut renseigné, puis un clic sur le deuxième ou serait copié les 
attributs d'adresse avec incrémentions automatique du numéro. J'envoie 
ma caisse de bières/limonade au magicien qui le coderait :q 



Bonjour,

   En lisant les discussions je me disais justement qu'un tel petit 
plugin pourrait se trouver utile. Je proposerai bien des trucs/idées en 
complément de ce qu'à proposer je crois Pieren:
a) un outil où on dessine un point début/un point fin et il demande le 
nombre de points à placer avec l'incrément pour placer rapidement les 
points dans une rue dense (idée précédente)
  * une amélioration pourrait être d'indiquer un way existant et de lui 
dire de faire la numérotation de part et d'autre (utile pour les rues 
tournantes).
b) un outil où on sélectionne des points/batis et un way et 
automatiquement il crée les adresses avec ces propriétés:

 - récupération du nom de la rue grâce au way de la rue
 - Numérotation automatique des objets sélectionnés autre que le way 
avec cet algorithme:
   -> On prend les noeuds ayant un numéro comme des références (on n'y 
touche pas)

   -> On trouve la coordonée curviligne sur l'axe du way pour chaque objet
   -> On incrémente de +2 (ou -2 si la rue "descend") par rapport au 
point d'avant étant du même côté de la route.
c) un outil qui en cliquant sur un objet ça ouvre un dialogue proposant 
de lui appliquer des paramètres par défaut (nom de rue et numéro 
incrémenté par rapport à la dernière fois).


Pour l'outil a, cela parait assez simple.
Pour l'outil b, cela ne me parait pas infaisable (et pas non plus super 
compliqué).
Pour l'outil c, je me demande si je n'ai pas déjà vu quelque chose du 
genre. En revanche je ne vois pas comment coder cela avec mes 
connaissances actuelles (surtout pour que cela déclenche le dialog menu 
dès que l'on clique sur un objet).


Ce ne sont que des idées peut-être un peu fantaisistes.
Aux experts des adresses (je n'ai pour l'instant fait que 10 bâtis 
manuellement) d'indiquer quel serait le plugin "idéal".


Pour ce qui est du code je peux un peu aider.

Clément.

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

Re: [OSM-talk-fr] Import des données INPN (was: ODbL et compatibilité avec sources actuelles)

2010-06-25 Par sujet Damien Boilley

> Donc au final j'ai lâché l'affaire :(.

En fait pour l'instant on est au stade de dire si on est d'accord sur
ce qu'on importe et comment on le taggue (balise). Après, les upload
en masse c'est une autre histoire.

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

Re: [OSM-talk-fr] ODbL et compatibilité avec sources actuelles

2010-06-25 Par sujet Emilie Laffray

2010/6/25 Tenshu 

> Ça va pas être très constructif ce que je vais dire.
> Mais je suis très en colère contre ce projet d'effacer des données.
> Je suis très en colère que le sondage qui avait été mis en place sans
> mentionner ce point serve d'appui au changement.
>
> Ça va (surement) être une catastrophe si jamais cela se faisait, combien de
> data est il raisonnable de perdre 5%10% 20% ?
> Parfois je me dit que moins de personne accepteront une telle migration aux
> forceps, moins ce cauchemar à de chance de se réaliser.
>

Le point a été clairement débattu et était présent sur les pages ou
justement les gens invitaient a voter non.

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ligne de cote

2010-06-25 Par sujet Christian Quest

Le 25 juin 2010 15:33,  a écrit :

> J'avais peut d'avoir fait une c*nnerie.
>
>
J'ai moi aussi utilisé GeoLittoral pour remettre un peu plus au propre la
ligne de côte et bien d'autres choses autour vu la relative précision des
orthos.
Donc j'ai fait le même (non) c*nnerie que toi ;-)

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

Re: [OSM-talk-fr] Les adresses... -- devient m olo molo sur l'anarchie du bâti

Le 25/06/2010 15:06, Tenshu a écrit :

J'ai pas saisi ta réflexion sur les townhall, églises et tout et tout.
Je pense que la connaissance du terrain est nécessaire, plus que pour
simplement importer ouatmilles polygones.
Mais en même temps je ne doute pas que la présence des bâtiments
incite fortement à la contribution : calage des routes, ajout de POI
facilités etc.

Ce qui est sûr c'est que beaucoup d'uploader (comme moi) vont
s'arrêter passé leur "zone de prédilection" qui doit représenter une
vingtaine de communes.
Encore une fois ne soyons pas si alarmiste, la plus part des communes
que j'ai importé avait des bâtiments sans overlap, quelques
nœuds/chemins dupliqués, plus vicieux des bâtiments superposés
(plusieurs niveaux ?). Mais finalement peut de retouches.
La qualité de la base ne vient pas seulement de la précision du
positionnement (le mapping), mais aussi de la précision du descriptif
(le tagging).

Il est certainement possible, dans le flux d'extraction du pdf vers le
fichier osm, de croiser les données avec celles existant dans osm (ou
dans la base sur osm.fr)

J'ai écrit une requête permettant de mettre en évidence des repères
géodésiques sensés se trouver sur un bâtiment à partir des informations
contenues dans le tag "description" du repère [1], mais n'ayant pas ce
bâti cartographié dans OSM. Le résultat apparaît sur Osmose [2].
L'idée était, du temps où il était fastidieux de tracer les bâtiments,
d'aider les mappeurs à trouver du bâti "utile" puisque sous un tel
repère géodésique devait se trouver un bâtiment, et même un bâtiment
significatif dans le paysage. Facile d'ouvrir JOSM sur le lieu, de
charger le cadastre et de tracer un beau bâtiment sur lequel on peut
mettre les tags qui vont bien puisque le repère géodésique nous donne
des infos.

La même requête, dans le flux peut permettre de mettre les mêmes tags
sur le polygone avant l'import.

Par ailleurs le cadastre comporte parfois/souvent :
du texte indiquant que tel bâtiment est une école/une mairie,
un signe indiquant que le bâtiment est une église,
et certainement d'autres signes que je ne connais pas.

Il est donc possible, avec un tout petit algorithme, de trouver le
bâtiment sous le signe et d'ajouter les tags qui vont bien.
Autant le faire avant ( et, si nécessaire, d'ajouter un métatag
note:import=warning, pour faire une contrôle des bâtiments ainsi
enrichis) plutôt qu'après où il faudra aller chercher l'information.
L'ordre de grandeur est de 10 bâtiments qui pourront être enrichis (
[mairie|église|école|château d'eau]*36000 communes ~= 10 bâtiments
enrichis. dont ~45000 par les repères géodésiques, chiffre sur ma base
de donnée).

En croisant l'information, on crée de l'information.
Pas besoin d'une grande connaissance de terrain, le risque d'erreur est
très faible :
Un bâtiment + un repère géodésique disant qu'il y a un château d'eau
dessous, le risque est faible que le bâtiment soit un pigeonnier.

[1] par exemple :
http://www.openstreetmap.org/browse/node/670153201 un château d'eau
http://www.openstreetmap.org/browse/node/670147308 un clocher
http://www.openstreetmap.org/browse/node/670632147 une mairie

[2]
http://osmose.openstreetmap.fr/map/cgi-bin/index.py?zoom=11&lat=48.362&lon=2.421&layers=B00T&item=7010
Les stats ont disparu, mais selon mes souvenirs, c'est environ 48000
repères qui apparaissaient ainsi.

--
FrViPofm

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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti


> Il est certainement possible, dans le flux d'extraction du pdf vers le
> fichier osm, de croiser les données avec celles existant dans osm (ou
> dans la base sur osm.fr)

C'est une super idée, et c'est aussi faisable après coup.
On peut faire dans le futur une moulinette qui (re)extrait les infos du
PDF/SVG et qui les associe au bâtiment déjà existant sur OSM.
La proba qu'un bâtiment bouge est plutôt faible.

-- 
JB


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

[OSM-talk-fr] Fwd: osm sur france inter

2010-06-25 Par sujet Frédéric Rodrigo

Je vous fait suivre une information que l'on m'a transmise.
Fred

- Mail transféré -
c'est [...] que que je
repense à la présentation qui a été faite par un auditeur de france
inter d'osm, avec exemple d'haiti à l'appui.
13'30 émission de Allo la planète
http://sites.radiofrance.fr/franceinter/em/allolaplanete/index.php?id=92975
-- 

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

Re: [OSM-talk-fr] Les adresses... -- devient mol o molo sur l'anarchie du bâti


Le 25/06/2010 16:46, jul...@krilin.org a écrit :

Il est certainement possible, dans le flux d'extraction du pdf vers le
fichier osm, de croiser les données avec celles existant dans osm (ou
dans la base sur osm.fr)
 

C'est une super idée, et c'est aussi faisable après coup.
On peut faire dans le futur une moulinette qui (re)extrait les infos du
PDF/SVG et qui les associe au bâtiment déjà existant sur OSM.
La proba qu'un bâtiment bouge est plutôt faible.
   

Je n'y crois pas.
Plus exactement, c'est faisable théoriquement, mais on ne le fera pas.

Il reste 100 000 polygones Corine à importer.
Personne ne s'est trouvé le courage de faire un outil permettant de 
faciliter cet import en masse, de faire le nettoyage de polygones yahoo 
et d'importer des polygones Corine. Il n'y a que quelques tordus de mon 
espèce, quelques masochistes qui se coltinent un méga-polygone par-ci, 
quelques fêlés qui font un import de polygones par là.


Qui même est au courant aujourd'hui que cette base des rebuts existe et 
qu'elle est riche ?


Il en sera de même pour le bâti. On fera bien un outil mettant en 
évidence que des tags existent et sont disponibles. Qui utilisera 
l'outil polygone par polygone, à concurrence de 100 000 ?
Une fois qu'on aura fait une jolie carte pour mapnik, on se foutra de 
savoir la richesse de ses tags !


Le fait que ça fasse joli est une très forte motivation pour 
cartographier. Le fait que la base soit sémantiquement riche est faible 
comme motivation.


Alors que si on l'inclut dans le flux, à partir d'un outil commun sur 
osm.fr, beaucoup exploiteront la richesse présente parce que la forte 
motivation incitera à importer le bâti et la faible motivation fera 
accepter le petit effort en plus pour le contrôle.


One shot, ou (presque) rien.
--
FrViPofm

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

[OSM-talk-fr] Boîtes aux lettres près de chez soi et autres données

2010-06-25 Par sujet Emmanuel


Bonjour à tous

L'emplacement de 149 000 boîtes aux lettres de La Poste est disponible 
sur le net à l'adresse 
http://courrierenfrance.laposte.fr/bal00selection.aspx
Il pourrait être donc intéressant d'étudier les conditions actuelles et 
de faire une demande.
De plus, 
http://www.laposte.fr/Particulier/Utilisez-nos-outils-pratiques/Services-de-localisation/Un-bureau-de-poste 
permet de "localiser" un bureau de poste, un DAB (distributeur) (et autres).


Je viens de découvrir aussi http://fc1.1bis.com/creditnord/ pour 
rechercher une agence ou un distributeur (du groupe Crédit Du Nord) 
ainsi que https://fc1.1bis.com/societegenerale2/ Ces 2 adresses montrent 
que des données sur Internet "existent", je n'ai pas tout testé.


J'ai assisté à la Rencontre avec Sourcemap & OpenStreetMap du 23 juin à 
La Cantine. J'ai pu découvrir le projet Sourcemap.


A quand une massive-party (virtuelle ou réelle) pour "former les uns les 
autres aux techniques

d'import massifs" ?

Emmanuel, alias Manu1400


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

Re: [OSM-talk-fr] Boîtes aux lettres près de chez soi et autres données

2010-06-25 Par sujet V

Le 25 juin 2010 18:27, Emmanuel  a écrit :
> L'emplacement de 149 000 boîtes aux lettres de La Poste est disponible sur
> le net à l'adresse http://courrierenfrance.laposte.fr/bal00selection.aspx
> Il pourrait être donc intéressant d'étudier les conditions actuelles et de
> faire une demande.
> De plus,
> http://www.laposte.fr/Particulier/Utilisez-nos-outils-pratiques/Services-de-localisation/Un-bureau-de-poste
> permet de "localiser" un bureau de poste, un DAB (distributeur) (et autres).

Malheureusement si on lit leurs Conditions Générales d'Utilisation, on
peut voir :
8<-
15. DROITS DE PROPRIETE INTELLECTUELLE

Les contenus tels que notamment, et sans que cette énumération ne soit
limitative, [..], données, bases de données, [...], et plus
généralement tout élément apparaissant sur le Site et/ou disponibles
sur les Services, sont protégés par le droit de la propriété
intellectuelle, sans autorisation expresse de La Poste et/ou de ses
partenaires.
8<-

Mais si une autorisation est obtenue il semblerait assez intéressant
d'importer les BALs.
Par contre, je m'interroge sur la précision des données. J'ai regardé
vers chez moi, cela m'étonnerait qu'il y ait des BALs au milieu d'une
départementale où il n'y a pas de place pour se garer. J'ai
l'impression que les coordonnées ont été déduites de l'adresse d'où
une forte imprécision sur les rues non numérotées. Certaines adresses
sont parfois simplement LE VILLAGE.

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

Re: [OSM-talk-fr] Boîtes aux lettres près de chez soi et autres données

2010-06-25 Par sujet Marc Sibert

Le 25/06/2010 19:26, V a écrit :

Le 25 juin 2010 18:27, Emmanuel a écrit :

L'emplacement de 149 000 boîtes aux lettres de La Poste est disponible sur
le net à l'adresse http://courrierenfrance.laposte.fr/bal00selection.aspx
Il pourrait être donc intéressant d'étudier les conditions actuelles et de
faire une demande.
De plus,
http://www.laposte.fr/Particulier/Utilisez-nos-outils-pratiques/Services-de-localisation/Un-bureau-de-poste
permet de "localiser" un bureau de poste, un DAB (distributeur) (et autres).

Malheureusement si on lit leurs Conditions Générales d'Utilisation, on
peut voir :
8<-
15. DROITS DE PROPRIETE INTELLECTUELLE

Les contenus tels que notamment, et sans que cette énumération ne soit
limitative, [..], données, bases de données, [...], et plus
généralement tout élément apparaissant sur le Site et/ou disponibles
sur les Services, sont protégés par le droit de la propriété
intellectuelle, sans autorisation expresse de La Poste et/ou de ses
partenaires.
8<-

Mais si une autorisation est obtenue il semblerait assez intéressant
d'importer les BALs.
Par contre, je m'interroge sur la précision des données. J'ai regardé
vers chez moi, cela m'étonnerait qu'il y ait des BALs au milieu d'une
départementale où il n'y a pas de place pour se garer. J'ai
l'impression que les coordonnées ont été déduites de l'adresse d'où
une forte imprécision sur les rues non numérotées. Certaines adresses
sont parfois simplement LE VILLAGE.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-frBonsoir,

Bonsoir,

Je me suis déjà permis de leur écrire et même de relancer une fois, mais
sans succès.
Si vous le souhaitez (j'aurais déjà du le faire), je mettrais mes 2
courriers en ligne ce WE.

A+

--
Marc Sibert
m...@sibert.fr

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

Re: [OSM-talk-fr] Boîtes aux lettres près de chez soi et autres données

2010-06-25 Par sujet Vincent de Chateau-Thierry


V a écrit :

Mais si une autorisation est obtenue il semblerait assez intéressant
d'importer les BALs.
Par contre, je m'interroge sur la précision des données. J'ai regardé
vers chez moi, cela m'étonnerait qu'il y ait des BALs au milieu d'une
départementale où il n'y a pas de place pour se garer. J'ai
l'impression que les coordonnées ont été déduites de l'adresse d'où
une forte imprécision sur les rues non numérotées. Certaines adresses
sont parfois simplement LE VILLAGE.
  
Si l'accès à cette source se concrétisait, je verrais plutôt une mise à 
disposition des listings, sans forcément le X,Y de chaque BAL, plutôt 
qu'un import, du fait justement de la précision constatée, à charge pour 
chacun de placer les points en connaissance du terrain, ou au moins à 
l'aide du cadastre (...et de ses bâtiments, tiens). Quand on parle de 
BALs, ou de cabines téléphoniques, d'arbres, de bancs, de bouches 
d'incendies, on est dans le micro-mapping, où le niveau de précision est 
par nature élevé. "Village", comme localisation, ça ne correspond qu'à 
du "macro" mapping, alors autant s'abstenir sur des cas comme celui-là.
Les commentaires qu'on peut lire dans les bulles d'info sur l'interface 
GMaps sont souvent plus riches qu'une adresse conventionnelle, au moins 
sur la commune (urbaine, 25.000hab) que je viens de regarder. On a des 
mentions comme "angle de la rue x et du boulevard y", "devant la gare", 
etc. Un moteur de géocodage (nominatim ou autre) ne s'en sortira pas 
forcément aussi bien qu'un mappeur, sachant qu'à l'échelle d'une commune 
le nombre de points à placer est faible.


...mais on n'en est pas encore là. L'autorisation est en effet le 
pré-requis. Et en argumentaire, une maquette OpenLayers sur des villes 
déjà bien fournies en boîtes aux lettres, pour montrer à La Poste 
l'intérêt d'une page OSM plutôt que GMaps ? Les BALs sont dans le rendu 
Mapnik, il ya une carte (postale) à jouer...


vincent

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

Re: [OSM-talk-fr] [BeCiklo] On en est où ?

2010-06-25 Par sujet Gérard

Je viens de copier coller le texte dans un fichier test.xml, et de l'ouvrir
avec firefox sans rien changer, et boum, ça me jette d'entrée en disant:
Erreur d'analyse XML : données incompréhensibles après l'élément de document
Emplacement : file:///home/gb4/test.xml
Numéro de ligne 8, Colonne 1 :

Re: [OSM-talk-fr] [BeCiklo] On en est où ?


Sur le wiki, je n'ai pas mis les deux premieres lignes du XML :




Ca vient peut être de la

Le 25/06/2010 22:46, Gérard a écrit :
Je viens de copier coller le texte dans un fichier test.xml, et de 
l'ouvrir avec firefox sans rien changer, et boum, ça me jette d'entrée 
en disant:
Erreur d'analyse XML : données incompréhensibles après l'élément de 
document

Emplacement : file:///home/gb4/test.xml
Numéro de ligne 8, Colonne 1 :

Re: [OSM-talk-fr] Boîtes aux lettres près de chez soi et autres données


Le 25/06/2010 21:38, Vincent de Chateau-Thierry a écrit :

V a écrit :

Mais si une autorisation est obtenue il semblerait assez intéressant
d'importer les BALs.
Par contre, je m'interroge sur la précision des données. J'ai regardé
vers chez moi, cela m'étonnerait qu'il y ait des BALs au milieu d'une
départementale où il n'y a pas de place pour se garer. J'ai
l'impression que les coordonnées ont été déduites de l'adresse d'où
une forte imprécision sur les rues non numérotées. Certaines adresses
sont parfois simplement LE VILLAGE.
Si l'accès à cette source se concrétisait, je verrais plutôt une mise 
à disposition des listings, sans forcément le X,Y de chaque BAL, 
plutôt qu'un import, du fait justement de la précision constatée, à 
charge pour chacun de placer les points en connaissance du terrain, ou 
au moins à l'aide du cadastre (...et de ses bâtiments, tiens). Quand 
on parle de BALs, ou de cabines téléphoniques, d'arbres, de bancs, de 
bouches d'incendies, on est dans le micro-mapping, où le niveau de 
précision est par nature élevé. "Village", comme localisation, ça ne 
correspond qu'à du "macro" mapping, alors autant s'abstenir sur des 
cas comme celui-là.
Les commentaires qu'on peut lire dans les bulles d'info sur 
l'interface GMaps sont souvent plus riches qu'une adresse 
conventionnelle, au moins sur la commune (urbaine, 25.000hab) que je 
viens de regarder. On a des mentions comme "angle de la rue x et du 
boulevard y", "devant la gare", etc. Un moteur de géocodage (nominatim 
ou autre) ne s'en sortira pas forcément aussi bien qu'un mappeur, 
sachant qu'à l'échelle d'une commune le nombre de points à placer est 
faible.


...mais on n'en est pas encore là. L'autorisation est en effet le 
pré-requis. Et en argumentaire, une maquette OpenLayers sur des villes 
déjà bien fournies en boîtes aux lettres, pour montrer à La Poste 
l'intérêt d'une page OSM plutôt que GMaps ? Les BALs sont dans le 
rendu Mapnik, il ya une carte (postale) à jouer...


vincent
L'intérêt d'une telle liste est de pouvoir vérifier l'exhaustivité de ce 
qui est dans OSM.

L'exhaustivité, c'est aussi un critère de qualité.
--
FrViPofm

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

Re: [OSM-talk-fr] Boîtes aux lettres près de chez soi et autres données

2010-06-25 Par sujet Jean-Francois Nifenecker



Le 25/06/2010 19:26, V a écrit :


Par contre, je m'interroge sur la précision des données. J'ai regardé
vers chez moi, cela m'étonnerait qu'il y ait des BALs au milieu d'une
départementale où il n'y a pas de place pour se garer. J'ai
l'impression que les coordonnées ont été déduites de l'adresse d'où
une forte imprécision sur les rues non numérotées. Certaines adresses
sont parfois simplement LE VILLAGE.


J'ai remarqué également cette imprécision, y compris en ville. Une boîte 
aux lettres est supposée se trouver à côté de chez moi dans une rue où, 
depuis 12 ans que j'y habite, jamais aucune boîta aux lettre n'y a été 
installée.


Même si l'autorisation d'exploiter leur base était reçue, je suis très 
réservé sur la qualité de cette base.


A+
--
Jean-Francois Nifenecker, Bordeaux


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

Re: [OSM-talk-fr] [BeCiklo] On en est où ?


Le 25/06/2010 10:25, Gérard a écrit :

Superbe bon début, bravo!

Je ne suis pas sur de faire des bêtises si j'édite le Xml, alors je 
préfère commenter ici. Où alors est ce qu'il y a le moyen de tester 
les lignes Xml qu'on rajouterait pour voir si au moins on introduit 
pas une grossière erreur de syntaxe? Peut être quelques conseils 
basiques sur l'édition Xml seraient bien utile aux apprentis sorciers 
en puissance.


Je ne suis pas le plus approprié pour parler du XML, je suis apprenti 
sorcier aussi sur mapnik:D. Je vais essayer de regrouper ce que je sais 
sur le wiki, d'autres enrichiront



Et à supposer que l'ajout soit OK, on fait quoi pour maintenir une 
légende humainement lisible (par opposition au code Xml) quelque par? 
On utilise la page de discussion 
http://wiki.openstreetmap.org/wiki/FR_talk:BeCikloXmlPistes ?


Ca me parait le plus simple pour le moment. J'ai commencé sur cette page



En tentant de comprendre xml, sur les path, j'ai noté qu'un éventuel 
bicycle=no se traduit par quelque chose de différent que s'il n'y a 
pas ce no (bravo d'y avoir pensé), mais je n'ai pas réussi à 
comprendre comment le no sera rendu?


En fait le bicycle = no sert a différencier un path uniquement piéton 
(donc un footway) d'un vrai path. Donc ca sera vert sur la carte (en 
pointillés ou non suivant la surface)


Pour les highway residential, considérer aussi un éventuel tag 
bicycle=designated pour indiquer les rues calmes et conseillées même 
si dépourvues d'aménagement spécifiquement cycliste. On pourrait 
utiliser un pointillé bleu?


Il faudrait faire une TODO list sur la page du projet 
http://wiki.openstreetmap.org/wiki/FR_talk:BeCikle, ca va nous éviter 
tout plein de mail non ?



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

Re: [OSM-talk-fr] [BeCiklo] On en est où ?

Le 25/06/2010 10:50, Ab_fab a écrit :

Un bac à sable de styles serait tip-top

Pouvoir mettre côte à côte des tuiles d'une même zone (quelques km 
carrés) mais avec deux styles différents, aux divers niveaux de zoom

-> Piocher le fichier XML d'un style existant déjà enregistré
-> Faire ses modifs dans le fichier
-> Renvoyer vers le serveur, si possible avec une trace du style 
originel et une description humaine de la teneur des modifs
-> Le serveur génère les tuiles pour la même zone pour permettre la 
comparaison entre deux rendus

(un peu comme là : [1] (grosse imagination requise !)
-> Le serveur laisse le fichier XML à disposition pour les autres 
utilisateurs ou des améliorations

Toujours plus facile à dire qu'à faire :-)

En effet.
Si j'ai le temps, je pourrais tenter de faire une historisation des 
tuiles et diviser la page en deux pour pouvoir comparer. Mais un serveur 
a la demande je doute de pouvoir.

[1] http://teczno.com/cascadenik-openstreetmap-II/

Le 25 juin 2010 10:25, Gérard > a écrit :

Superbe bon début, bravo!

Je ne suis pas sur de faire des bêtises si j'édite le Xml, alors
je préfère commenter ici. Où alors est ce qu'il y a le moyen de
tester les lignes Xml qu'on rajouterait pour voir si au moins on
introduit pas une grossière erreur de syntaxe? Peut être quelques
conseils basiques sur l'édition Xml seraient bien utile aux
apprentis sorciers en puissance. Et à supposer que l'ajout soit
OK, on fait quoi pour maintenir une légende humainement lisible
(par opposition au code Xml) quelque par? On utilise la page de
discussion
http://wiki.openstreetmap.org/wiki/FR_talk:BeCikloXmlPistes ?

En tentant de comprendre xml, sur les path, j'ai noté qu'un
éventuel bicycle=no se traduit par quelque chose de différent que
s'il n'y a pas ce no (bravo d'y avoir pensé), mais je n'ai pas
réussi à comprendre comment le no sera rendu?
Pour les highway residential, considérer aussi un éventuel tag
bicycle=designated pour indiquer les rues calmes et conseillées
même si dépourvues d'aménagement spécifiquement cycliste. On
pourrait utiliser un pointillé bleu?

Le 24 juin 2010 15:41, Lord Awikatchikaen
mailto:lord.awikatchik...@gmail.com>> a écrit :

ok j'ai mixé les deux :

1/ path + surface (paved,asphalt, concrete ou vide) ou
smoothness (excellent good ou vide) -> vert
2/ path  + smoothness (intermediate, bad, very_bad ou vide) et
surface différent de (paved asphalt et concrete)  -> vert
pointillé

2010/6/24 sly (sylvain letuffe) mailto:sylv...@letuffe.org>>

On jeudi 24 juin 2010, Lord Awikatchikaen wrote:
> pour les trajets vert la promenade de l'orge est plutot
bien pour le VTT, je
> la fais quelque fois. Certes pour le vélo de ville c'est
plus dur il n'y a
> pas trop moyen de faire la distinction. ou alors faire
évoluer les tags pour
> avoir du "pathtype"... mais on est plutôt sur le rendu.
La ou on pourrait
> jouer c'est sur le tag "surface". Si path + paved ou
asphalt c'est ok pour
> vélo et VTT. sinon que pour VTT

Ou alors, (au risque de devenir lourd à force d'en faire
la pub) :
http://wiki.openstreetmap.org/wiki/Key:smoothness

smoothness -> good (c'est praticable en Vélo de
course/vélo de ville)
smoothness -> bad (c'est praticable en VTC)
smoothness -> very_horrible (c'est praticable en VTT )

--
sly
Sylvain Letuffe sylv...@letuffe.org

qui suis-je : http://slyserv.dyndns.org

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

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

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

--
--
ab_fab

"Il n'y a pas de pas perdus"

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

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

Re: [OSM-talk-fr] Re : Un aperçu des erreurs à c orrigées lié à l'import semi auto

2010-06-25 Par sujet christophe triquet

Le 25 juin 2010 03:04, Marc Sibert  a écrit :

>  Le 25/06/2010 00:58, Benoît ROUSSEAU a écrit :
>
> THEVENON Julien a écrit :
>
>  *De :* Benoît ROUSSEAU 
>  **
>  Bonsoir,
>
>    J'ai initié une page incomplète et non exhaustive des "erreurs" que
> je cherche à résoudre avant un import bâti semi auto.
>    Elle n'est pour l'instant liée à aucune autre page. Si vous avez
> des éléments pour la compléter, n'hésitez pas et remaniez comme vous le
> souhaitez.
>
> Tu peux donner le lien stp ?
>
> Zut ! Un grand classique. :p
>
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents/Aper%C3%A7u_des_erreurs_rencontr%C3%A9es
>
>
> Julien
>
>
>
>  Celui là est joli. J'ai commencé des suppressions à la main, mais je me
> demande si un revert ne serait pas plus simple (si c'est encore possible
> après mon action... désolé dans ce cas)
>
>
>
> http://matt.dev.openstreetmap.org/dupe_nodes/?zoom=15&lat=43.82415&lon=1.72403&layers=BT
>
> --
> Marc sibertm...@sibert.fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
Je connais le contributeur qui a réalisé cet import. Il est en train de
corriger, donc ne touchez à rien, il a presque fini.

christophe alias orhygine
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les adresses...

2010-06-25 Par sujet hamster


Eric Sibert a écrit :

Et encore moins si le
highway est manquant dans OSM...


Oui mais justement l'avantage des imports massifs du bâti, c'est qu'on 
voit beaucoup plus facilement les rues qui manquent ;-)


De là dire qu'on met la charrue avant les boeufs...


ben non, c'est le bon ordre : la rue c'est bien l'espace entre les 
immeubles non ?


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

Re: [OSM-talk-fr] Les adresses...

2010-06-25 Par sujet hamster


Pieren a écrit :
Reconnaître le numéro est une chose mais le script ne pourra pas 
associer numéro et rue puisqu'il ne connait pas les highway...


ce qui est le plus penible c'est clairement de taper les n° un a un
un truc qui genere des points deja numerotes et qu'on a plus qu'a les 
placer au bon endroit et faire la relation associatedStreet serait deja 
un net progres (meme si c'est pas parfait)


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

Re: [OSM-talk-fr] Organisation du wiki

2010-06-25 Par sujet Nicolas Dumoulin

Le vendredi 25 juin 2010 15:50:54 Vincent Pottier, vous avez écrit :
> J'ai démaré :
> http://wiki.openstreetmap.org/wiki/Domain_names#Sub-domains
> À compléter avec tes découvertes

Merci.

Il y a aussi ceux du domaine en .fr (osmose et ses amis), on pourrait les 
lister sur la même page, ou faire une page annexe ?

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

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

Re: [OSM-talk-fr] Les adresses...

2010-06-25 Par sujet Nicolas Dumoulin

Le vendredi 25 juin 2010 23:27:31 hamster, vous avez écrit :
> Eric Sibert a écrit :
> >> Et encore moins si le
> >> highway est manquant dans OSM...
> > 
> > Oui mais justement l'avantage des imports massifs du bâti, c'est qu'on
> > voit beaucoup plus facilement les rues qui manquent ;-)
> > 
> > De là dire qu'on met la charrue avant les boeufs...
> 
> ben non, c'est le bon ordre : la rue c'est bien l'espace entre les
> immeubles non ?

« Quand deux caravanes ne se touchent pas, ça fait une allée »
(citation de l'œuvre cinématographique « Camping » )

… désolé.

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

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

[OSM-talk-fr] Cadastre vectorisé: qui a fait d es imports de cours d'eau et plans d'eau ?

2010-06-25 Par sujet Christian Quest

Faisant une pause sur la bati, j'ai regardé ce que donnai la récupération
des cours et plans d'eau.

J'ai commencé à mettre à jour les rivages du Rhone à la frontière suisse, ce
qui fait aussi que j'ai aussi de quoi mettre à jour la frontière
France/Suisse.

Qui a déjà exploité ces données ?

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

Re: [OSM-talk-fr] Boîtes aux lettres près de chez soi et autres données

2010-06-25 Par sujet Frédéric Rodrigo


Le 25/06/2010 23:01, Jean-Francois Nifenecker a écrit :


Le 25/06/2010 19:26, V a écrit :


Par contre, je m'interroge sur la précision des données. J'ai regardé
vers chez moi, cela m'étonnerait qu'il y ait des BALs au milieu d'une
départementale où il n'y a pas de place pour se garer. J'ai
l'impression que les coordonnées ont été déduites de l'adresse d'où
une forte imprécision sur les rues non numérotées. Certaines adresses
sont parfois simplement LE VILLAGE.


Même si l'autorisation d'exploiter leur base était reçue, je suis très
réservé sur la qualité de cette base.


Je suis aussi arrivé au même constat. La localisation doit être faite 
par adresse. J'avais déjà expérimenté les données des BAL

http://f.rodrigo.free.fr/tmp/osm-map/LaPoste.html
(il y a des erreurs sur la page mais c'est pas grave) En zoomant, sur le 
centre ville par ex, on peut comparer les données de La Poste et celle 
d'OSM.
Le données sont intéressante pour approcher l'exhaustivité, mais pas 
pour la localisation exacte.
Dans une demande à la Poste on pourrait leur "vendre" le faite que l'on 
a la possibilité d'améliorer leur jeu de données, c'est du gagnant-gagnant.


Pas grand chose à voir, mais sur les BAL il y a une sorte de ref, j'en 
ai déjà relevé, mais je ne sais pas si ça correspond à quelque chose, 
j'ai pas cherché non plus ;)


Fred

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

Re: [OSM-talk-fr] [OSM-talk] Upcoming OSM Server Maintenance

2010-06-25 Par sujet Nakor

 Les 2 et 3 juillet 2010, l'équipe des administrateurs mettra à  jour 
la base de données. L'édition ne sera pas possible durant cette période.


Planning initial, sujet à révisions :

1er juillet à 23:00 (21:00 GMT) : l'API et le site internet sont en 
lecture seule (pas d'édition)
2 juillet à 14:00 (12:00 GMT) : l'API est indisponible. Seuls 
l'affichage et l'export de la carte seront disponibles.
3 juillets dans l'après-midi : l'API et le site web sont de retour 
(l'édition est de nouveau disponible)


Le wiki sera disponible pendant toute cette période.

Pour plus d'information, voir 
http://wiki.openstreetmap.org/wiki/July_2010_DB_Upgrade



On 6/25/2010 7:16 PM, Grant Slater wrote:

OpenStreetMap,

Please translate and copy to local lists.

On the 2nd (Friday) and 3rd (Saturday) of July 2010 the sysadmin team
will be upgrading the database server's storage.

Editing will not be available during this period.

Initial plan, subject to revision:
  1st July 21:00 (GMT) - API and website read-only. (no edits)
  2nd July 12:00 (GMT) - API unavailable. Only Map browsing and map
export available on www.openstreetmap.org
  3rd July Afternoon (GMT) - API and website return. (edit resumes)

The wiki will remain available for the duration.

Futher information and progress status will be posted here:
http://wiki.openstreetmap.org/wiki/July_2010_DB_Upgrade

Regards
  Grant
  OpenStreetMap Sysadmin Team

___
talk mailing list
t...@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk




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

Re: [OSM-talk-fr] Reconnaissance des n° dans les SVG

2010-06-25 Par sujet hamster


Benoît ROUSSEAU a écrit :

Bonjour,

Donc cela semble fonctionner (sur mon jeu d'essai).


ah oui mais non
si t'es pas capable de faire le tri entre les n° de rue et les n° de 
parcelles ca va juste faire du bruit mais pas tellement etre exploitable


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

Re: [OSM-talk-fr] Reconnaissance des n° dans les SVG


hamster a écrit :

Benoît ROUSSEAU a écrit :

Bonjour,

Donc cela semble fonctionner (sur mon jeu d'essai).


ah oui mais non
si t'es pas capable de faire le tri entre les n° de rue et les n° de 
parcelles ca va juste faire du bruit mais pas tellement etre exploitable



Bonjour Hamster,
  
   Lire ma dernière phrase "Reste à déterminer la taille du premier 
caractère pour distinguer les n° de parcelles des numéros de rues." et 
l'objet.
   Cette dernière phrase est la seule où je parle de "n° de rues". Je 
ne mentionne pas "adresse".

   J'ai bien fait gaffe justement :p :p.

   Je partage pour donner des pistes à qquns qui pourraient y voir un 
autre intérêt, donner des idées, et préparer le terrain si jamais ça 
fonctionnait. Aujourd'hui, c'est expérimental.


   Au passage, merci de bien vouloir m'excuser pour le "c'est" en place 
de "ces" et pour les autres.


Benoît R.


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

Re: [OSM-talk-fr] Cadastre vectorisé: qui a fait d es imports de cours d'eau et plans d'eau ?