Re: [OSM-talk-fr] Point adresse à Montpellier

[Philippe Verdy]

Le 10 février 2012 08:38, rldhont  a écrit :
> Mais en fait il faut réussir à remonter au niveau des services qui
> fournissent les données mais ne s'intéressent pas forcément à l'OpenData

Bien des communes n'ont pas les moyens de supporter un SIG. Mais avec
le développement accéléré des intercommunalités, et même leur fusion
dans certains cas (des communautés de communes fusionnent pour devenir
une communauté d'agglomération, disposant d'autres moyens plus
importants), bon nombre se mettent à bouloir gérer leur propre SIG au
lieu de dépendre de services divers qui fournissent des infos pas
synchronisées entre elles voire contradictoires ou insuffisamment
précises pour leurs besoins.

Par exemple dans les appels d'offre pour l'équipement, le ramassage
scolaire, les eaux usées, les nouveaux réseaux de télécommunication
comme la fibre ou les antennes de téléphonie, ou pour respecter des
cahiers des charges environnementaux et de nouvelles règles de
contrôle de conformité des installations, d'origine française ou
européenne, ou aussi pour mesurer les disparités d'offres de services
entre les territoires, avec des statistiques détaillées de population
issues du recensement, ou encore pour justifier des demandes de
subvention ou dotation par le département, la région, l'Etat ou
l'Union européenne, ou encore pour vérifier des clauses de respect de
la concurrence dans les demandes d'installations ce certaines
activités réglementées.

Un SIG efficace et bien renseigné permet une planification plus
précise et des décisions mieux motivées qui ne seront pas contestées
ensuite devant les tribunaux, et cela permet aussi de sérieuses
économies budgétaires en évitant des travaux inutiles ou dont la
priorité n'est pas essentielle par rapport à d'autres projets. Ça
permet aussi de mieux expliquer à la population les décisions prises,
et de faciliter aussi les négociations avec les riverains concernés ou
lorsqu'il est envisagé des compensations financières (surtout en cas
d'expropriations ou d'arrêtés de fermeture de certaines activités trop
polluantes ou dangereuses que la communauté ne peut prendre en charge,
ou de levée de taxes supplémentaires sur ces activités, ou encore
quand des conflits de voisinage surviennent entre administrés, car les
collectivités sont de plus en plus souvent concernées ou prises à
partie et appelées à témoigner pour renseigner les tribunaux...).

Sinon comment expliquer à la population des fermetures de classes afin
de pouvoir mieux financer d'autres classes dans des zones
sous-équipées ? Comment autoriser un commerce à ouvrir tandis qu'on le
refuse à un autre ? Comment expliquer une changement de fréquence ou
une réduction du nombre d'arrêts ou leur déplacement dans un ramassage
scolaire subventionné par la collectivité ? Comment éviter des
accusations de "clientélisme" par une opposition minicipale qui accuse
de privilégier certains quartier plutôt que d'autres ? C'est d'autant
plus nécessaire que toutes les collectivités font en principe la
chasse au gaspillage et cherchent des économies, dans un contexte où
l'appel aux prêts des banques est de plus en plus cher et compliqué,
et où les banques demandent aussi des justifications de rentabilité
fiscale, et quand l'Etat, les départements et régions ou l'Union
européenne réduisent leurs dotations de fonctionnement ou même
d'investissement...

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

[OSM-talk-fr] Périphérique nord-ouest de Tours

[Vincent de Chateau-Thierry]

Bonjour,
Ce mail est potentiellement pour local-to...@listes.openstreetmap.fr  :-)

En regardant ce document sur le site du CG37 :
http://www.cg37.fr/periph/pdf/plan-general-presentation-2006.pdf 
la sortie du "diffuseur de Fondettes" en direction de Fondettes (la D 367) est 
tracé
comme passant sous le périphérique, puis sous la voie ferrée.

Dans OSM :
http://www.openstreetmap.org/?lat=47.41766&lon=0.63591&zoom=17&layers=M 
on a une modélisation opposée : la D 367 passe au dessus du périphérique puis 
au dessus
de la voie ferrée. Par ailleurs en venant du nord, les bretelles de sortie puis 
d'entrée
ne peuvent accéder à la D367, en pont de part et d'autre du croisement :
http://www.openstreetmap.org/browse/node/1445519838 

N'étant pas dans le coin pour constater, est-ce que les régionaux de l'étape 
ont moyen de
valider une des versions, et le cas échéant de mettre à jour la base ?

merci
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] Traduction des toponymes et lieux assistée par Wikipedia

[Mikaël Cordon]

salut,

Juste une idée qui m’a traversé l’esprit quand j’ai vu passer les mots «
traduction en plusieurs langues »…
Il existe un projet/site de traduction communautaire basé sur une solution
libre : Tatoeba (http://tatoeba.org/)

Actuellement, les traductions ne concernent par les toponymies, mais
peut-être qu’il y a un sujet à développer autour de ça ?

Qu’en pensez-vous ?

Le 9 février 2012 11:18, Vincent de Chateau-Thierry  a
écrit :

>
> > De : "Pieren"
>
> > 2012/2/9 Ab_fab
> >
> > >
> > > (et qui plus est inutile puisque dans la même langue)
> > >
> > >
> > >
> > Cet outil ne devrait pas ajouter de "name:fr" en France. C'est
> > contre-productif et dangereux (doublon, risque de dichotomie, à
> l'encontre
> > des pratiques actuelles et des éditeurs).
> > Moi, je serais partisan de les supprimer systématiquement dans
> l'hexagone.
> >
>
> Dans l'hexagone d'accord, mais peut-être pas au bord :-)
>
> Taginfo France compte un millier de name:fr :
> http://taginfo.openstreetmap.fr/keys/name:fr#values
>
> et les 3 valeurs les plus récurrentes sont sur des objets frontaliers :
> "Frontière franco-suisse", "Le Rhin" et "La Moselle".
>
> == début de HS ==
> Cela dit, on peut de demander si sur une limite administrative, le tag
> "name" tout court
> est pertinent. Pour moi non, il devrait être déduit des noms des emprises
> administratives auxquelles il participe, et pas stocké en dur. Libre à
> chaque utilisateur
> de construire le nom qu'il veut, dans la langue qu'il veut, et avec le
> niveau
> administratif qu'il souhaite.
> == fin de HS ==
>
> 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
>


Cordialement,
-- 
Mikaël Cordon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Point adresse à Montpellier

[rldhont]

Le 10/02/2012 09:30, Philippe Verdy a écrit :

Le 10 février 2012 08:38, rldhont  a écrit :

Mais en fait il faut réussir à remonter au niveau des services qui
fournissent les données mais ne s'intéressent pas forcément à l'OpenData



Ma remarque portait plus sur le fait que les services qui fournissent 
des données SIG ou autres, ne s'intéressent pas toujours à l'OpenData, 
et que le service OpenData n'a pas toujours les compétences et le temps 
pour vérifier ces données.


Maintenant nous sommes là, pour exploiter ces données et faire un retour 
pour démontrer l'intérêt d'un partage des données.


René-Luc


Bien des communes n'ont pas les moyens de supporter un SIG. Mais avec
le développement accéléré des intercommunalités, et même leur fusion
dans certains cas (des communautés de communes fusionnent pour devenir
une communauté d'agglomération, disposant d'autres moyens plus
importants), bon nombre se mettent à bouloir gérer leur propre SIG au
lieu de dépendre de services divers qui fournissent des infos pas
synchronisées entre elles voire contradictoires ou insuffisamment
précises pour leurs besoins.

Par exemple dans les appels d'offre pour l'équipement, le ramassage
scolaire, les eaux usées, les nouveaux réseaux de télécommunication
comme la fibre ou les antennes de téléphonie, ou pour respecter des
cahiers des charges environnementaux et de nouvelles règles de
contrôle de conformité des installations, d'origine française ou
européenne, ou aussi pour mesurer les disparités d'offres de services
entre les territoires, avec des statistiques détaillées de population
issues du recensement, ou encore pour justifier des demandes de
subvention ou dotation par le département, la région, l'Etat ou
l'Union européenne, ou encore pour vérifier des clauses de respect de
la concurrence dans les demandes d'installations ce certaines
activités réglementées.

Un SIG efficace et bien renseigné permet une planification plus
précise et des décisions mieux motivées qui ne seront pas contestées
ensuite devant les tribunaux, et cela permet aussi de sérieuses
économies budgétaires en évitant des travaux inutiles ou dont la
priorité n'est pas essentielle par rapport à d'autres projets. Ça
permet aussi de mieux expliquer à la population les décisions prises,
et de faciliter aussi les négociations avec les riverains concernés ou
lorsqu'il est envisagé des compensations financières (surtout en cas
d'expropriations ou d'arrêtés de fermeture de certaines activités trop
polluantes ou dangereuses que la communauté ne peut prendre en charge,
ou de levée de taxes supplémentaires sur ces activités, ou encore
quand des conflits de voisinage surviennent entre administrés, car les
collectivités sont de plus en plus souvent concernées ou prises à
partie et appelées à témoigner pour renseigner les tribunaux...).

Sinon comment expliquer à la population des fermetures de classes afin
de pouvoir mieux financer d'autres classes dans des zones
sous-équipées ? Comment autoriser un commerce à ouvrir tandis qu'on le
refuse à un autre ? Comment expliquer une changement de fréquence ou
une réduction du nombre d'arrêts ou leur déplacement dans un ramassage
scolaire subventionné par la collectivité ? Comment éviter des
accusations de "clientélisme" par une opposition minicipale qui accuse
de privilégier certains quartier plutôt que d'autres ? C'est d'autant
plus nécessaire que toutes les collectivités font en principe la
chasse au gaspillage et cherchent des économies, dans un contexte où
l'appel aux prêts des banques est de plus en plus cher et compliqué,
et où les banques demandent aussi des justifications de rentabilité
fiscale, et quand l'Etat, les départements et régions ou l'Union
européenne réduisent leurs dotations de fonctionnement ou même
d'investissement...

___
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] Traduction des toponymes et lieux assistée par Wikipedia

[Pierre-Amiel Giraud]

Salut,
pour les toponymes, il y a un projet déjà très avancé mené par l'Université
de Tours. Ça s'appelle Prolex, c'est très complet, et la base de données
est sous LGPL for Linguistic Resources (LGPL-LR). Que demande le peuple? Ah
oui, même problème que dans Wikipédia, pas d'article devant les noms de
cours d'eau...

a+

PA

Le 10 février 2012 10:01, Mikaël Cordon  a écrit :

> salut,
>
> Juste une idée qui m’a traversé l’esprit quand j’ai vu passer les mots «
> traduction en plusieurs langues »…
> Il existe un projet/site de traduction communautaire basé sur une solution
> libre : Tatoeba (http://tatoeba.org/)
>
> Actuellement, les traductions ne concernent par les toponymies, mais
> peut-être qu’il y a un sujet à développer autour de ça ?
>
> Qu’en pensez-vous ?
>
> Le 9 février 2012 11:18, Vincent de Chateau-Thierry  a
> écrit :
>
>
>> > De : "Pieren"
>>
>> > 2012/2/9 Ab_fab
>> >
>> > >
>> > > (et qui plus est inutile puisque dans la même langue)
>> > >
>> > >
>> > >
>> > Cet outil ne devrait pas ajouter de "name:fr" en France. C'est
>> > contre-productif et dangereux (doublon, risque de dichotomie, à
>> l'encontre
>> > des pratiques actuelles et des éditeurs).
>> > Moi, je serais partisan de les supprimer systématiquement dans
>> l'hexagone.
>> >
>>
>> Dans l'hexagone d'accord, mais peut-être pas au bord :-)
>>
>> Taginfo France compte un millier de name:fr :
>> http://taginfo.openstreetmap.fr/keys/name:fr#values
>>
>> et les 3 valeurs les plus récurrentes sont sur des objets frontaliers :
>> "Frontière franco-suisse", "Le Rhin" et "La Moselle".
>>
>> == début de HS ==
>> Cela dit, on peut de demander si sur une limite administrative, le tag
>> "name" tout court
>> est pertinent. Pour moi non, il devrait être déduit des noms des emprises
>> administratives auxquelles il participe, et pas stocké en dur. Libre à
>> chaque utilisateur
>> de construire le nom qu'il veut, dans la langue qu'il veut, et avec le
>> niveau
>> administratif qu'il souhaite.
>> == fin de HS ==
>>
>> 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
>>
>
>
> Cordialement,
> --
> Mikaël Cordon
>
> ___
> 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] Traduction des toponymes et lieux assistée par Wikipedia

[Ab_fab]

Il y a une réflexion en cours sur ce sujet qui est assez avancée sur la
liste bretonne OSM-talk-fr-bzh.
http://lists.openstreetmap.org/pipermail/talk-fr-bzh/2012-January/000562.html

C'est le genre d'outil qu'il peut être intéressant d'avoir sous le coude,
pour arriver à quelque chose de rapide, précis ... et contrôlé par un oeil
humain.

(idem pour Prolex)

Le 10 février 2012 10:01, Mikaël Cordon  a écrit :

> salut,
>
> Juste une idée qui m’a traversé l’esprit quand j’ai vu passer les mots «
> traduction en plusieurs langues »…
> Il existe un projet/site de traduction communautaire basé sur une solution
> libre : Tatoeba (http://tatoeba.org/)
>
> Actuellement, les traductions ne concernent par les toponymies, mais
> peut-être qu’il y a un sujet à développer autour de ça ?
>
> Qu’en pensez-vous ?
>
> Le 9 février 2012 11:18, Vincent de Chateau-Thierry  a
> écrit :
>
>
>> > De : "Pieren"
>>
>> > 2012/2/9 Ab_fab
>> >
>> > >
>> > > (et qui plus est inutile puisque dans la même langue)
>> > >
>> > >
>> > >
>> > Cet outil ne devrait pas ajouter de "name:fr" en France. C'est
>> > contre-productif et dangereux (doublon, risque de dichotomie, à
>> l'encontre
>> > des pratiques actuelles et des éditeurs).
>> > Moi, je serais partisan de les supprimer systématiquement dans
>> l'hexagone.
>> >
>>
>> Dans l'hexagone d'accord, mais peut-être pas au bord :-)
>>
>> Taginfo France compte un millier de name:fr :
>> http://taginfo.openstreetmap.fr/keys/name:fr#values
>>
>> et les 3 valeurs les plus récurrentes sont sur des objets frontaliers :
>> "Frontière franco-suisse", "Le Rhin" et "La Moselle".
>>
>> == début de HS ==
>> Cela dit, on peut de demander si sur une limite administrative, le tag
>> "name" tout court
>> est pertinent. Pour moi non, il devrait être déduit des noms des emprises
>> administratives auxquelles il participe, et pas stocké en dur. Libre à
>> chaque utilisateur
>> de construire le nom qu'il veut, dans la langue qu'il veut, et avec le
>> niveau
>> administratif qu'il souhaite.
>> == fin de HS ==
>>
>> 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
>>
>
>
> Cordialement,
> --
> Mikaël Cordon
>
> ___
> 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] Périphérique nord-ouest de Tours

[Cyrille Giquello]

Merci Vincent, on va faire les corrections nécessaires (les collègues
car je n'ai pas de voiture)

Dis moi, par curiosité, comment es-tu arrivé à trouver ces erreurs ?

Cyrille.

Le 10 février 2012 10:01, Vincent de Chateau-Thierry
 a écrit :
> Bonjour,
> Ce mail est potentiellement pour local-to...@listes.openstreetmap.fr  :-)
>
> En regardant ce document sur le site du CG37 :
> http://www.cg37.fr/periph/pdf/plan-general-presentation-2006.pdf
> la sortie du "diffuseur de Fondettes" en direction de Fondettes (la D 367) 
> est tracé
> comme passant sous le périphérique, puis sous la voie ferrée.
>
> Dans OSM :
> http://www.openstreetmap.org/?lat=47.41766&lon=0.63591&zoom=17&layers=M
> on a une modélisation opposée : la D 367 passe au dessus du périphérique puis 
> au dessus
> de la voie ferrée. Par ailleurs en venant du nord, les bretelles de sortie 
> puis d'entrée
> ne peuvent accéder à la D367, en pont de part et d'autre du croisement :
> http://www.openstreetmap.org/browse/node/1445519838
>
> N'étant pas dans le coin pour constater, est-ce que les régionaux de l'étape 
> ont moyen de
> valider une des versions, et le cas échéant de mettre à jour la base ?
>
> merci
> 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



-- 
Cyrille.

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

Re: [OSM-talk-fr] Point adresse à Montpellier

[Ab_fab]

Personne n'avait pris PostGIS LV2 au lycée, mais c'était une solution de
repli identifiée en cas de blocage.

Les essais d'Isnogoud ont ** rapidement ** donné de bons résultats, donc la
mise en place d'une BDD spatiale n'a pas été nécessaire pour aboutir à des
fichiers exploitables.

Le 10 février 2012 08:38, rldhont  a écrit :

>
>>
>> Pour associer une adresse à une rue d'OSM, je procède comme suit :
>> - calculer le barycentre des adresses de chaque rue de l'opendata.
>> - calculer le barycentre de chaque rue d'OSM (highway avec un name
>> renseigné sur le secteur de Montpellier)
>> - calculer la distance de l'adresse la plus éloignée du barycentre des
>> adresses de la rue
>>
>
> Pourquoi utiliser un barycentre ? Dans PostGIS tu peux utiliser :
> * ST_Line_Locate_Point qui renvoit un float entre 0 et 1 indiquant la
> position de la porjeté d'un point sur une ligne
> * ST_Line_Interpolate_Point qui renvoit un point à partir d'une ligne et
> d'un float entre 0 et 1, peut servir avec ST_Line_Locate_Point pour créer
> le point de la projection sur la ligne
> * ST_Length et St_MakeLine en réutilisant ST_Line_Interpolate_Point et
> ST_Line_Locate_Point pour calculer la distance
> Tu obtiendrais ainsi quelque chose de précis
>
>
-- 
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] Périphérique nord-ouest de Tours

[Vincent de Chateau-Thierry]

> De : "Cyrille Giquello" 
>
> Merci Vincent, on va faire les corrections nécessaires (les collègues
> car je n'ai pas de voiture)
> 
> Dis moi, par curiosité, comment es-tu arrivé à trouver ces erreurs ?
> 

Merci Cyrille.
Pour ta curiosité :-) : j'ai eu l'info par un collègue au courant de 
l'ouverture de cette
portion, et à qui je présentais OSM.

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] Périphérique nord-ouest de Tours

[Cyrille Giquello]

Le 10 février 2012 10:55, Vincent de Chateau-Thierry
 a écrit :
>> De : "Cyrille Giquello"
>>
>> Merci Vincent, on va faire les corrections nécessaires (les collègues
>> car je n'ai pas de voiture)
>>
>> Dis moi, par curiosité, comment es-tu arrivé à trouver ces erreurs ?
>>
>
> Merci Cyrille.
> Pour ta curiosité :-) : j'ai eu l'info par un collègue au courant de 
> l'ouverture de cette
> portion, et à qui je présentais OSM.

Dommage pour la présentation ... Pas terrible pour la réputation ;-)

Cyrille.

>
> 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



-- 
Cyrille.

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

Re: [OSM-talk-fr] Import Ballades Vertes du 71 dans le cadre de Night of the live mapping, le 7 Février

[didier2020]

Le mercredi 08 février 2012 à 00:57 -0800, partir-en-vtt a écrit :
> Alors les chemins ont été intégré ?
j'en ai fait 1...
c'est plutot hardu d'autant plus que je ne connait pas le coin

http://osmose.openstreetmap.fr/map/?zoom=16&lat=46.914076&lon=4.470295&item=5010


> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/ANNONCE-Night-of-the-live-mapping-le-7-Fevrier-a-Paris-et-ailleurs-tp5441144p5465964.html
> Sent from the France mailing list archive at Nabble.com.
> 
> ___
> 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] Périphérique nord-ouest de Tours

[Ab_fab]

La rapidité de "l'action corrective" fait partie de ce qui peut donner
bonne réputation quand un défaut est identifié.

Sans compter qu'en plus sur OSM, on n'est jamais mieux servi que par
soi-même pour corriger un défaut que l'on a repéré.

et toc ! ;-)

Le 10 février 2012 11:04, Cyrille Giquello  a écrit :

> Le 10 février 2012 10:55, Vincent de Chateau-Thierry
>  a écrit :
> >> De : "Cyrille Giquello"
> >>
> >> Merci Vincent, on va faire les corrections nécessaires (les collègues
> >> car je n'ai pas de voiture)
> >>
> >> Dis moi, par curiosité, comment es-tu arrivé à trouver ces erreurs ?
> >>
> >
> > Merci Cyrille.
> > Pour ta curiosité :-) : j'ai eu l'info par un collègue au courant de
> l'ouverture de cette
> > portion, et à qui je présentais OSM.
>
> Dommage pour la présentation ... Pas terrible pour la réputation ;-)
>
> Cyrille.
>
> >
> > 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
>
>
>
> --
> Cyrille.
>
> ___
> 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

[OSM-talk-fr] Re : Périphérique nord-ouest de Tours

[THEVENON Julien]

 De : Cyrille Giquello 


 Dommage pour la présentation ... Pas terrible pour la réputation ;-)


Sauf si tu lui montres qu en 2 minutes il peut corriger contrairement aux 
autres "cartes" ou il peut aussi y avoir des erreurs


Julien



>
> De : Cyrille Giquello 
>À : Vincent de Chateau-Thierry ; Discussions sur OSM en 
>français  
>Envoyé le : Vendredi 10 février 2012 11h04
>Objet : Re: [OSM-talk-fr] Périphérique nord-ouest de Tours
> 
>Le 10 février 2012 10:55, Vincent de Chateau-Thierry
> a écrit :
>>> De : "Cyrille Giquello"
>>>
>>> Merci Vincent, on va faire les corrections nécessaires (les collègues
>>> car je n'ai pas de voiture)
>>>
>>> Dis moi, par curiosité, comment es-tu arrivé à trouver ces erreurs ?
>>>
>>
>> Merci Cyrille.
>> Pour ta curiosité :-) : j'ai eu l'info par un collègue au courant de 
>> l'ouverture de cette
>> portion, et à qui je présentais OSM.
>
>Dommage pour la présentation ... Pas terrible pour la réputation ;-)
>
>Cyrille.
>
>>
>> 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
>
>
>
>-- 
>Cyrille.
>
>___
>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] Périphérique nord-ouest de Tours

[Vincent de Chateau-Thierry]

> De : "Ab_fab" 
>
> La rapidité de "l'action corrective" fait partie de ce qui peut donner
> bonne réputation quand un défaut est identifié.
> 

Exactement. De plus, les cas ne manquent pas d'ouverture au jour J dans OSM 
d'une voie,
d'un magasin, etc. Et la réactivité pour des corrections reste inégalable. 

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] Point adresse à Montpellier

[rldhont]

Désolé, mais c'est naturel chez moi... ça va tellement plus vite... 
c'est comme la ligne de commande, ssh, etc.


Le 10/02/2012 10:54, Ab_fab a écrit :
Personne n'avait pris PostGIS LV2 au lycée, mais c'était une solution 
de repli identifiée en cas de blocage.


Les essais d'Isnogoud ont ** rapidement ** donné de bons résultats, 
donc la mise en place d'une BDD spatiale n'a pas été nécessaire pour 
aboutir à des fichiers exploitables.


Le 10 février 2012 08:38, rldhont > a écrit :




Pour associer une adresse à une rue d'OSM, je procède comme suit :
- calculer le barycentre des adresses de chaque rue de l'opendata.
- calculer le barycentre de chaque rue d'OSM (highway avec un
name renseigné sur le secteur de Montpellier)
- calculer la distance de l'adresse la plus éloignée du
barycentre des adresses de la rue


Pourquoi utiliser un barycentre ? Dans PostGIS tu peux utiliser :
* ST_Line_Locate_Point qui renvoit un float entre 0 et 1 indiquant
la position de la porjeté d'un point sur une ligne
* ST_Line_Interpolate_Point qui renvoit un point à partir d'une
ligne et d'un float entre 0 et 1, peut servir avec
ST_Line_Locate_Point pour créer le point de la projection sur la ligne
* ST_Length et St_MakeLine en réutilisant
ST_Line_Interpolate_Point et ST_Line_Locate_Point pour calculer la
distance
Tu obtiendrais ainsi quelque chose de précis


--
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

[OSM-talk-fr] Rapidité de "l'action corrective"

[Erik Amzallag]

Bonjour,

Pour rebondir sur cette phrase :

"La rapidité de "l'action corrective" fait partie de ce qui peut donner
bonne réputation quand un défaut est identifié."


Je prends pour exemple l'échangeur A 15 / N 184, qui a été en travaux
depuis quelques années.
L'été dernier, les travaux se sont terminés, avec la configuration
définitive de l'échangeur.
J'ai donc mis OSM à jour (le 6 juillet,
http://www.openstreetmap.org/browse/changeset/8650536  ).

Depuis je surveille les "grands". A ce jour, ni Bing, ni ViaMichelin, ni
Mappy n'intègrent la nouvelle configuration.
Quant à Google, depuis peu il propose une configuration intermédiaire
datant des travaux.

8 mois, et ils ne sont toujours pas à jour...

Erik
PS : par contre, je viens de voir que Bing avait des photos à jour ! Je
vais pouvoir affiner le tracé...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Je viens de trouver un bogue dans Osmose, sur son serveur Backend.

 Premier problème (le plus sérieux) ===

Cela se situe ici:

https://gitorious.org/~frodrigo/osmose/frodrigo-osmose-backend/blobs/master/modules/OsmSax.py

Aux deux lignes suivantes du module SaxWriter lorsqu'il génère le code
des valeurs d'attributs des élements XML :

369 self._write(' %s=%s' % (name, quoteattr(value)))
378 self._write(' %s=%s' % (name, quoteattr(value)))

En effet, la fonction Python quoteattr() ne représente pas
correctement le caractère "&" qu'il laisse sous cette forme, alors
qu'il FAUT le réencoder sous la forme "&"

La fonction quoteattr() est importée depuis le module Python
"sax.saxutils", absent dans les sources GIT d'Osmose. C'est elle qui
est ici en cause.

Cela affecte la modification des éléments contenant un caractère "&"
dans leur valeur (par exemple les relations contenant un tag "url", ou
certains tags "name" parfaitement valides).

L'effet de ce bogue est que le XML reçu par le client et éditable par
"rawedit" est invalide, et ne peut pas être revalidé tel quel !
Sinon on reçoit un message affiché en rouge en haut de l'écran
rawedit: "XML parser can't parse this data", et les données ne sont
pas enregistrées.

Pour contourner le problème, il faut soit même corriger le code XML
qui a été reçu en remplaçant les "&" affichés dans l'éditeur dans les
valeurs de tags par "&" avant de valider, même si on n'a pas
réellement touché à la valeur.

Le risque subsiste que même sans y toucher, l'absence de modification
manuelle pour faire la correction risque parfois d'être acceptés comme
du XML valide (par exemple quand un "&" littéral est suivi de
quelquechose qui ressemble à une référence numérique de caractère ou
une référene d'entité XML définie dans le schéma XML utilisé), ce qui
corrompra les données qui n'avaient pas lieu d'être modifiées.

Je ne sais pas si c'est la fonction quoteattr() du module sax.saxutils
qui devrait être corrigée, ou si une autre fonction devrait plutôt
être définie ou utilisée ici, ou si un paramètre supplémentaire
optionnel de quoteattr() permet de préciser la conformité avec XML
(car quoteattr() n'est pas obligé de remplacer ces "&" si la fonction
est utilisée pour générer du HTML ou du SGML): dans ce cas il faut
passer ce paramètre oublié.

A ce sujet, quoteattr() recode toutes les apostrophes ASCII (') sous
la forme ' alors que c'est inutile (et peu lisible) ici, étant
donné que la chaine retournée sera encadrée de guillemets doubles
ASCII ("). En revanche les quatre caractères suivants doivent être mis
sous forme de référence à une des quatre seules entité de caractères
XML prédéfinie :

- les guillemets doubles ASCII (") sous la forme "
- le signe inférieur (<) sous la forme <
- le signe supérieur (>) sous la forme >
- le signe et commercial (&) sous la forme &

Et c'est tout ! Tout le reste peut (et devrait) rester sous leur forme
littérale (même l'apostrophe ici, bien que XML prédéfinisse aussi une
cinquième entité "'" puisque la syntaxe XML permet aussi aux
valeurs d'attributs d'être encadrées par des apostrophes ASCII au lieu
de guillemets ASCII).


 Deuxième problème (lié au premier) ===

Enfin je note que le code Javascript envoyé au client utilise le
constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
caractères qui sera utilisé pour dialoguer avec le serveur :

 function ApiDo(action)
  {
var myReq = new XMLHttpRequest();
if (myReq) {
  myReq.onreadystatechange = function (evnt) { if(myReq.readyState == 4) {
res = myReq.responseText.split('\n');
document.getElementById('osm_msg').innerHTML = res[0];
tmp = res.shift();
document.getElementById('osm_data').value= res.join('\n');
} }
  myReq.open('POST', '/' + action + '/' + osm_type + '/' + osm_id, true);
  myReq.setRequestHeader("Content-type",
"application/x-www-form-urlencoded");
  poststr = "osm_data=" +
encodeURIComponent(document.getElementById("osm_data").value );
  myReq.send(poststr);
}
  }

Rien n'oblige actuellement le navigateur à supposer que cette requête
se fera en codage UTF-8, même si la page web et le code javascript
sont eux-même codés en UTF-8. Dans les faits, cette requête telle
qu'elle est envoyée au serveur ne précise rien du tout, ce qui demande
alors que les données incluses dans la valeur "osm_data=" ne soient
que de l'ASCII pur.

Ici le problème est que pour s'assurer que ce sera uniquement de
l'ASCII, ce javascript utilise encodeURIComponent(), dont le
comportement dépend du navigateur : la source est bien de l'UTF-16,
son résultat sera bien de l'ASCII compatible avec une syntaxe de
composant URI, mais asolument rien n'indique dans quel jeu de
caractères se fera la conversion de la chaine source UTF-16 vers un
jeu restreint à 8 bits (avant ensuite de convertir les espaces ASCII
sous la forme "+", et les octets non ASCII et non imprimables ou
réservés par la syntaxe des U

Re: [OSM-talk-fr] "Accueil" des nouveaux contributeurs

[djo_man]

  
  
bonjour, 

J'ai commencé véritablement à contribuer à OSM qu'il y 1 an. Mon
caractère me guide toujours à assembler les infos dispos avant de
faire quoi que ce soit mais pourtant j'ai fait pas mal d'erreurs
qu'aujourd'hui encore, je corrige. 

J'ai de moi même contacté des contributeurs de la zone ou je
souhaitais travailler et j'ai aussi été contacté par certains quand
mes erreurs étaient trop visibles. Grâce à cela (et à la liste) j'ai
"découvert" les outils d'autocorrection ( la semaine dernière
encore: osmose par nom de contributeur, bravo pour cet outil ! ).
J'imagine que tous les contributeurs ne sont pas comme moi.

Personnellement, j'aurais vraiment aimé qu'un mail automatique
resumant les évidences me soit envoyé par l'asso. Je trouverais ça
efficace et non-intrusif car clairement automatique.

Et dans ce mail si il y a un lien vers une page super débutant,
débutant, etc, très bien.

Et dans ce mail si il y avait un lien vers une page pour choisir un
parrain, pourquoi pas.

Si jamais un contributeur chevronné d'une zone veut, en plus,
prendre contact directement et nominativement, cela resterait
compatible.

Après, il y a sans doute la manière de ce "premier contact direct" 
pour éviter l'effet "l'intrusif" . ça doit être d'abord une question
de ressenti perso. De mon coté, je trouve qu'un contact direct dés
mes premières contributions m'aurait un peu décontenancé.
Qu'aurais-je pensé ? Puisqu'ils voient tout ce que je fais, j'ai les
boules car je me sens jugé ? Puisqu'ils sont si jaloux de
l'intégrité de leur base je ne ferais plus rien avant d’être sur ? 

quoi qu'il en soit
ce que vous ferez sera bien pour moi
djo_man



Le 06/02/2012 10:53, Ab_fab a écrit :
Bonjour,
  
  
  Pensez-vous qu'un outil identifiant les nouveaux
contributeurs sur un territoire donné (une région, la France
Métropolitaine) serait une bonne chose ?
  
  
  L'idée étant de pouvoir facilement les identifier pour 
  _ regarder la teneur des premières contributions, 
  _ proposer par la messagerie interne de les épauler pour les
premiers pas, guider vers des tutos, d'autres outils ...



  En tant que "ex-nouveaux contributeur" (on l'est tous), est-ce
  que vous auriez apprécié ce genre de prise de contact (j'y ai
  eu droit, et j'ai trouvé ça très intéressant), ou alors vous
  considérez que c'est trop "intrusif" ?


Une idée sur une manière efficace de procéder ?


-- 
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] Rapidité de "l'action corrective"

[Vincent de Chateau-Thierry]

> De : "Erik Amzallag" 
> 
> Pour rebondir sur cette phrase :
> 
> "La rapidité de "l'action corrective" fait partie de ce qui peut donner
> bonne réputation quand un défaut est identifié."
> 
> 
> Je prends pour exemple l'échangeur A 15 / N 184, qui a été en travaux
> depuis quelques années.
> L'été dernier, les travaux se sont terminés, avec la configuration
> définitive de l'échangeur.
> J'ai donc mis OSM à jour (le 6 juillet,
> http://www.openstreetmap.org/browse/changeset/8650536 ).
> 
> Depuis je surveille les "grands". A ce jour, ni Bing, ni ViaMichelin, ni
> Mappy n'intègrent la nouvelle configuration.
> Quant à Google, depuis peu il propose une configuration intermédiaire
> datant des travaux.
> 
> 8 mois, et ils ne sont toujours pas à jour...

:-( 
(note : je travaille chez ViaMichelin)

> Erik
> PS : par contre, je viens de voir que Bing avait des photos à jour ! Je
> vais pouvoir affiner le tracé...

À noter, quelques traces GPS présentes sur cet nouvel échangeur, mais pour 
l'instant
minoritaires en comparaison des traces prenant l'ancienne configuration (avec 
des feux).
Je devrais pouvoir rajouter quelques traces ce week-end, mais en effet, Bing 
est déjà 
excellent sur cette zone.

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] Le Mans Métropole & Open Data

[Cyrille Giquello]

Salut

Je ne sais pas si l'info a été relayé sur osm.fr :

Lug Réunion de concertation sur la libération de données relative à la
ville du Mans (opendata)
Le Mans Métropole va libérer un lot de données opendata. Ces données
concernent surtout la circulation et l'environnement : lignes de bus,
pistes cyclables, parking handicapés, points de collectes des déchets,
etc. L'étendue de ces données est la communauté urbaine du Mans.
À cette date ce lot de données pourrait venir compléter, corriger OSM
ou permettre à Le Mans Métropole de corriger ses données à partir de
OSM.

Détail du rendez-vous :
http://linuxfr.org/news/reunion-de-concertation-sur-la-liberation-de-donnees-relative-a-la-ville-du-mans-opendata

Le 9 février 2012 16:44, Romain MEHUT  a écrit :
> Délibération aujourd'hui de la communauté urbaine...
> http://www.lemainelibre.fr/actualite/le-virage-numerique-du-mans-08-02-2012-28761
>
> Romain
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cyrille.

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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Frédéric Rodrigo]

Bonjour,
Sincèrement je n'ai pas tout lu (vraiment beaucoup trop long, tu
pourrais proposer un résumé de tes mails en introduction ;) ).
Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
version de développement.

Frédéric

Le 10 février 2012 11:51, Philippe Verdy  a écrit :
> Je viens de trouver un bogue dans Osmose, sur son serveur Backend.
>
>  Premier problème (le plus sérieux) ===
>
> Cela se situe ici:
>
> https://gitorious.org/~frodrigo/osmose/frodrigo-osmose-backend/blobs/master/modules/OsmSax.py
>
> Aux deux lignes suivantes du module SaxWriter lorsqu'il génère le code
> des valeurs d'attributs des élements XML :
>
> 369                 self._write(' %s=%s' % (name, quoteattr(value)))
> 378                 self._write(' %s=%s' % (name, quoteattr(value)))
>
> En effet, la fonction Python quoteattr() ne représente pas
> correctement le caractère "&" qu'il laisse sous cette forme, alors
> qu'il FAUT le réencoder sous la forme "&"
>
> La fonction quoteattr() est importée depuis le module Python
> "sax.saxutils", absent dans les sources GIT d'Osmose. C'est elle qui
> est ici en cause.
>
> Cela affecte la modification des éléments contenant un caractère "&"
> dans leur valeur (par exemple les relations contenant un tag "url", ou
> certains tags "name" parfaitement valides).
>
> L'effet de ce bogue est que le XML reçu par le client et éditable par
> "rawedit" est invalide, et ne peut pas être revalidé tel quel !
> Sinon on reçoit un message affiché en rouge en haut de l'écran
> rawedit: "XML parser can't parse this data", et les données ne sont
> pas enregistrées.
>
> Pour contourner le problème, il faut soit même corriger le code XML
> qui a été reçu en remplaçant les "&" affichés dans l'éditeur dans les
> valeurs de tags par "&" avant de valider, même si on n'a pas
> réellement touché à la valeur.
>
> Le risque subsiste que même sans y toucher, l'absence de modification
> manuelle pour faire la correction risque parfois d'être acceptés comme
> du XML valide (par exemple quand un "&" littéral est suivi de
> quelquechose qui ressemble à une référence numérique de caractère ou
> une référene d'entité XML définie dans le schéma XML utilisé), ce qui
> corrompra les données qui n'avaient pas lieu d'être modifiées.
>
> Je ne sais pas si c'est la fonction quoteattr() du module sax.saxutils
> qui devrait être corrigée, ou si une autre fonction devrait plutôt
> être définie ou utilisée ici, ou si un paramètre supplémentaire
> optionnel de quoteattr() permet de préciser la conformité avec XML
> (car quoteattr() n'est pas obligé de remplacer ces "&" si la fonction
> est utilisée pour générer du HTML ou du SGML): dans ce cas il faut
> passer ce paramètre oublié.
>
> A ce sujet, quoteattr() recode toutes les apostrophes ASCII (') sous
> la forme ' alors que c'est inutile (et peu lisible) ici, étant
> donné que la chaine retournée sera encadrée de guillemets doubles
> ASCII ("). En revanche les quatre caractères suivants doivent être mis
> sous forme de référence à une des quatre seules entité de caractères
> XML prédéfinie :
>
> - les guillemets doubles ASCII (") sous la forme "
> - le signe inférieur (<) sous la forme <
> - le signe supérieur (>) sous la forme >
> - le signe et commercial (&) sous la forme &
>
> Et c'est tout ! Tout le reste peut (et devrait) rester sous leur forme
> littérale (même l'apostrophe ici, bien que XML prédéfinisse aussi une
> cinquième entité "'" puisque la syntaxe XML permet aussi aux
> valeurs d'attributs d'être encadrées par des apostrophes ASCII au lieu
> de guillemets ASCII).
>
>
>  Deuxième problème (lié au premier) ===
>
> Enfin je note que le code Javascript envoyé au client utilise le
> constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
> caractères qui sera utilisé pour dialoguer avec le serveur :
>
>  function ApiDo(action)
>  {
>    var myReq = new XMLHttpRequest();
>    if (myReq) {
>      myReq.onreadystatechange = function (evnt) { if(myReq.readyState == 4) {
>        res = myReq.responseText.split('\n');
>        document.getElementById('osm_msg').innerHTML = res[0];
>        tmp = res.shift();
>        document.getElementById('osm_data').value    = res.join('\n');
>        } }
>      myReq.open('POST', '/' + action + '/' + osm_type + '/' + osm_id, true);
>      myReq.setRequestHeader("Content-type",
> "application/x-www-form-urlencoded");
>      poststr = "osm_data=" +
> encodeURIComponent(document.getElementById("osm_data").value );
>      myReq.send(poststr);
>    }
>  }
>
> Rien n'oblige actuellement le navigateur à supposer que cette requête
> se fera en codage UTF-8, même si la page web et le code javascript
> sont eux-même codés en UTF-8. Dans les faits, cette requête telle
> qu'elle est envoyée au serveur ne précise rien du tout, ce qui demande
> alors que les données incluses dans la valeur "osm_data=" ne soient
> que de l'ASCII pur.
>
> Ici le problème est

Re: [OSM-talk-fr] Périphérique nord-ouest de Tours

[Philippe Verdy]

Le 10 février 2012 11:23, Vincent de Chateau-Thierry
 a écrit :
>
>> De : "Ab_fab"
>>
>> La rapidité de "l'action corrective" fait partie de ce qui peut donner
>> bonne réputation quand un défaut est identifié.
>>
>
> Exactement. De plus, les cas ne manquent pas d'ouverture au jour J dans OSM 
> d'une voie,
> d'un magasin, etc. Et la réactivité pour des corrections reste inégalable.

Les autres services aussi ont leurs erreurs:

- Google Maps en est bourré et attend qu'on les lui signale, mais mais
ensuite des semaines ou des mois avant que cela apparaisse sur les
cartes affichées en ligne, même s'il répond assez rapidement aux
signalements d'erreur (moins de 48 heures, leurs modérateurs
travaillent bien pour vérifier ces remontées d'erreurs qui doivent
être nombreuses).

- Les SIG "officiels" des collectivités aussi (parce que la plupart
sont encore assez récents, et formés au départ de collections de
données prises telles quelles de sources diverses et parfois
contradictoires entre elles) : les géomètres "officiels" (ou parfois
les huissiers de justice) chargés des vérifications en cas de conflit
de sources ne chôment pas.

Ça fait longtemps d'ailleurs que les tribunaux reçoivent des plaintes
au sujet d'un voisin qui a parait-il déplacé des bornes cadastrales
pour grignoter la propriété du voisin, ou seulement parce que ça
gênait le passage des engins agricoles ou la pose d'un abri de jardin,
ou parce qu'un voisin a abattu un arbre supposé lui appartenir, ou
parce qu'une erreur de métrage d'un géomètre a conduit à la
construction de 10 cm pris chez un voisin, ou parce qu'un mur mitoyen
de cloture a été construit prenant tout son emprise chez un seul
voisin Il y a même des morts à ce sujet (et j'ai un exemple très
précis et très récent que je ne peux pas citer plus explicitement car
un procès va avoir lieu suite à de graves menaces, des violences
physiques puis le décès d'un ouvrier qui n'y était pour rien et
faisait le travail qu'on lui a commandé).

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

Re: [OSM-talk-fr] Le Mans Métropole & Open Data

[Cyrille Giquello]

Publié sur http://www.openstreetmap.fr/ section "événements"

Il y en a des choses ce WE: AG de l'April, Manif anti-ACTA...

Cyrille.

Le 10 février 2012 12:09, Cyrille Giquello  a écrit :
> Salut
>
> Je ne sais pas si l'info a été relayé sur osm.fr :
>
> Lug Réunion de concertation sur la libération de données relative à la
> ville du Mans (opendata)
> Le Mans Métropole va libérer un lot de données opendata. Ces données
> concernent surtout la circulation et l'environnement : lignes de bus,
> pistes cyclables, parking handicapés, points de collectes des déchets,
> etc. L'étendue de ces données est la communauté urbaine du Mans.
> À cette date ce lot de données pourrait venir compléter, corriger OSM
> ou permettre à Le Mans Métropole de corriger ses données à partir de
> OSM.
>
> Détail du rendez-vous :
> http://linuxfr.org/news/reunion-de-concertation-sur-la-liberation-de-donnees-relative-a-la-ville-du-mans-opendata
>
> Le 9 février 2012 16:44, Romain MEHUT  a écrit :
>> Délibération aujourd'hui de la communauté urbaine...
>> http://www.lemainelibre.fr/actualite/le-virage-numerique-du-mans-08-02-2012-28761
>>
>> Romain
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cyrille.



-- 
Cyrille.

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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Le 10 février 2012 12:11, Frédéric Rodrigo  a écrit :
> Bonjour,
> Sincèrement je n'ai pas tout lu (vraiment beaucoup trop long, tu
> pourrais proposer un résumé de tes mails en introduction ;) ).

Justement chaque point a une présentation dès les premières lignes. La
suite de chaque point, c'est pour expliquer pourquoi l'erreur
survient.

> Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
> version de développement.

J'ai regardé justement, mais je n'ai trouvé aucun contact, ou section
en place sur le site pour signaler et suivre l'anomalie (par exemple
Bugzilla).

On trouve juste un endroit pour soumettre une branche, qui sera
difficilement acceptée si on n'explique rien. Ce qui suppose qu'en
fait ce repository n'a qu'un seul mainteneur qui travaille seul mais
qui omet de fournir un point de contact.

Le bogue est facile à voir et reproduire : essaye de charger un point
géodésique contenant une erreur dans Osmose (par exemple dans un
toponyme) : le lien url fourni est mal encodé quand il est envoyé en
format XML par le backend, alors même qu'on n'a aucune intention d'y
toucher dans "rawedit", et la validation du XML édité échoue sur le
serveur.

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

[OSM-talk-fr] Mises à jour sur www.openstreetmap.fr

[Christian Quest]

Je viens de faire des mises à jour concernant Drupal et ses modules sur le
site http://www.openstreetmap.fr/

N'hésitez pas à me signaler tout problème... ça arrive (malheureusement).

-- 
Christian Quest - OpenStreetMap France -
http://openstreetmap.fr/u/cquest
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Re : Rapidité de "l'action corrective"

[THEVENON Julien]

 De : Erik Amzallag 
 Je prends pour exemple l'échangeur A 15 / N 184, qui a été en travaux 
 depuis quelques années.
  L'été dernier, les travaux se sont terminés, avec la configuration 
 définitive de l'échangeur.
 J'ai donc mis OSM à jour (le 6 juillet, 
 http://www.openstreetmap.org/browse/changeset/8650536  ).

 Depuis je surveille les "grands". A ce jour, ni Bing, ni ViaMichelin, ni 
 Mappy n'intègrent la nouvelle configuration.
 Quant à Google, depuis peu il propose une configuration intermédiaire 
 datant des travaux.

 8 mois, et ils ne sont toujours pas à jour...


De meme du cote de Grenoble avec l ouverture de la route passant sur le barrage 
de Saint Egreve il y a quelques mois, le tag en construction a retire d 
Openstreetmap le jour de l inauguration alors que Geoportail et via michelin ne 
sont toujours pas a jour. Si vous faites un essaie de routage Noyarey - Saint 
Egreve en utilisant Via Michelin ou open.mapquest.fr on voit bien la difference.
Seul mappy est a jour

Julien




>
> De : Erik Amzallag 
>À : Discussions sur OSM en français  
>Envoyé le : Vendredi 10 février 2012 11h42
>Objet : [OSM-talk-fr] Rapidité de "l'action corrective"
> 
>
>Bonjour,
>
>Pour rebondir sur cette phrase :
>
>"La rapidité de "l'action corrective" fait partie de ce qui peut donner bonne 
>réputation quand un défaut est identifié."
>
>
>Je prends pour exemple l'échangeur A 15 / N 184, qui a été en travaux depuis 
>quelques années.
>L'été dernier, les travaux se sont terminés, avec la configuration définitive 
>de l'échangeur.
>J'ai donc mis OSM à jour (le 6 juillet, 
>http://www.openstreetmap.org/browse/changeset/8650536  ).
>
>Depuis je surveille les "grands". A ce jour, ni Bing, ni ViaMichelin, ni Mappy 
>n'intègrent la nouvelle configuration.
>Quant à Google, depuis peu il propose une configuration intermédiaire datant 
>des travaux.
>
>8 mois, et ils ne sont toujours pas à jour...
>
>Erik
>PS : par contre, je viens de voir que Bing avait des photos à jour ! Je vais 
>pouvoir affiner le tracé...
>
>
>___
>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] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

A mon avis le bogue est surtout à corriger dans la fonction
quoteattr() du module Python "sax.saxutils".

Car ***même*** en HTML ou SGML (au lieu de XML ou XHTML) il faudrait
systématiquement recoder un "&" présent dans une valeur qu'on veut
encapsuler dans un attribut d'élément HTML (ou XML). Tout parseur HTML
ou SGML reconnait "&" automatiquement (sans avoir besoin de
définir l'entité), mais ***tolère*** (par compatibilité ascendante
avec les très vieux navigateurs HTML, d'avant même HTML4) des valeurs
contenant des entités mal codées (dans ce cas un parseur HTML a un
"fallback" lui permettant de réinterpréter la valeur donnée sans faire
le décodage des entités, mais PAS un parseur XML qui s'y refuse, car
c'est un trou de sécurité).

Le code d'Osmose visiblement l'oublie quand il génère aussi d'autres
URLs "en dur" à d'autres endroits de la page HTML du frontend (mais ce
frontend est codé pour générer du HTML, pas du XHTML, ce qui autorise
le "fallback" pourtant pas recommandé du tout et dangereux).

>> Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
>> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
>> version de développement.

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

Re: [OSM-talk-fr] Mises à jour sur www.openstreetmap.fr

[Cyrille Giquello]

Le 10 février 2012 12:29, Christian Quest  a écrit :
> Je viens de faire des mises à jour concernant Drupal et ses modules sur le
> site http://www.openstreetmap.fr/

Ah, c'est pour ça. J'ai publié un article, et quand j'ai voulu
vérifier sa publication, le site ne répondait plus. J'ai eu peut
d'avoir tout cassé avec mes fautes d'orthographes. Ensuite tout est
revenu dans l'ordre (sauf les fautes).

Peut-être qu'un petit mail avant de lancer la mise à jour serait le
bienvenue étant donné qu'il y a potentiellement plusieurs utilisateurs
sur le site.

Et merci pour l'entretien du moteur, c'est super !!

Cyrille.

>
> N'hésitez pas à me signaler tout problème... ça arrive (malheureusement).
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cyrille.

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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Jocelyn Jaubert]

Bonjour,

(je redirige sur dev-fr où ça a plus sa place)

Le 10 février 2012, Philippe Verdy a écrit :

> 369   self._write(' %s=%s' % (name, quoteattr(value)))
> 378   self._write(' %s=%s' % (name, quoteattr(value)))
> 
> En effet, la fonction Python quoteattr() ne représente pas
> correctement le caractère "&" qu'il laisse sous cette forme, alors
> qu'il FAUT le réencoder sous la forme "&"
> 
> La fonction quoteattr() est importée depuis le module Python
> "sax.saxutils", absent dans les sources GIT d'Osmose. C'est elle qui
> est ici en cause.

Cette fonction fait parti de la librairie python standard, et sa
documentation se trouve là:

http://docs.python.org/library/xml.sax.utils.html

D'après la doc, quoteattr() échappe bien les & < et >, donc je ne
comprends pas le problème.

Est-ce que tu pourrais donner un lien sur osmose.openstreetmap.fr qui
montrerait le problème ?  (avec le permalink en bas à droite)


>  Deuxième problème (lié au premier) ===
> 
> Enfin je note que le code Javascript envoyé au client utilise le
> constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
> caractères qui sera utilisé pour dialoguer avec le serveur :

Le fait que la page html et le fichier .js soient encodées en UTF-8 via
les headers HTTP ne suffit pas à informer le navigateur ?


Et est-ce que tu peux donner un exemple d'objet "corrompu" sur OSM ?



Merci,
Jocelyn

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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Note, la doc Python du module SAX est là:

http://docs.python.org/library/xml.sax.utils.html

Elle précise bien que quoteattr() doit normalement encoder les mêmes
caractères que:

xml.sax.saxutils.escape(data[, entities])

sans même avoir à passer un tableau entities (les caractères "&", "<"
et ">" sont inclus par défaut), mais quoteattr() ajoute les guillemets
(") et apostrophes ('), sans retirer pour autant le caractère "&" des
entités de substitution définies par défaut.

Visiblement c'est un problème de version du module "xml.sax.saxutils"
que tu utilises (il faut une version 2.2 ou supérieure de Python pour
avoir cette fonction). Note bien que quoteattr() a été conçu pour HTML
ou SGML, pas pour la conformité XML ou XHTML (la conformité XML vient
avec la version 2.3 il me semble, sinon il te faut passer un paramètre
entities ; Python est actuellement en version 2.7)


Le 10 février 2012 12:45, Philippe Verdy  a écrit :
> A mon avis le bogue est surtout à corriger dans la fonction
> quoteattr() du module Python "sax.saxutils".
>
> Car ***même*** en HTML ou SGML (au lieu de XML ou XHTML) il faudrait
> systématiquement recoder un "&" présent dans une valeur qu'on veut
> encapsuler dans un attribut d'élément HTML (ou XML). Tout parseur HTML
> ou SGML reconnait "&" automatiquement (sans avoir besoin de
> définir l'entité), mais ***tolère*** (par compatibilité ascendante
> avec les très vieux navigateurs HTML, d'avant même HTML4) des valeurs
> contenant des entités mal codées (dans ce cas un parseur HTML a un
> "fallback" lui permettant de réinterpréter la valeur donnée sans faire
> le décodage des entités, mais PAS un parseur XML qui s'y refuse, car
> c'est un trou de sécurité).
>
> Le code d'Osmose visiblement l'oublie quand il génère aussi d'autres
> URLs "en dur" à d'autres endroits de la page HTML du frontend (mais ce
> frontend est codé pour générer du HTML, pas du XHTML, ce qui autorise
> le "fallback" pourtant pas recommandé du tout et dangereux).
>
>>> Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
>>> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
>>> version de développement.

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

Re: [OSM-talk-fr] Import Ballades Vertes du 71 dans le cadre de Night of the live mapping, le 7 Février

[partir-en-vtt]

En gros c'est le PDIPR qui à été numérise sur le scan 25 par le CDT

--
View this message in context: 
http://gis.19327.n5.nabble.com/ANNONCE-Night-of-the-live-mapping-le-7-Fevrier-a-Paris-et-ailleurs-tp5441144p5472277.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Pour le code source à jour de ce module:

http://svn.cs.brynmawr.edu/viewvc/Pyjama/trunk/IronPython/Lib/xml/sax/saxutils.py?view=markup&pathrev=9
ou (version 3)
http://www.opensource.apple.com/source/python/python-3/python/Lib/xml/sax/saxutils.py
ou
https://vmi.lmt.ei.tum.de/projects/ros/browser/trunk/vmi_cognitive_environment/ce_skype/src/sky2ros/Student/client/xml/sax/saxutils.py

Ce codage de quoteattr() est correct et n'oublie pas "&", puisqu'il
utilise escape() en interne, qui remplace systématiquement ce
caractère.

Le 10 février 2012 12:58, Philippe Verdy  a écrit :
> Note, la doc Python du module SAX est là:
>
> http://docs.python.org/library/xml.sax.utils.html
>
> Elle précise bien que quoteattr() doit normalement encoder les mêmes
> caractères que:
>
> xml.sax.saxutils.escape(data[, entities])
>
> sans même avoir à passer un tableau entities (les caractères "&", "<"
> et ">" sont inclus par défaut), mais quoteattr() ajoute les guillemets
> (") et apostrophes ('), sans retirer pour autant le caractère "&" des
> entités de substitution définies par défaut.
>
> Visiblement c'est un problème de version du module "xml.sax.saxutils"
> que tu utilises (il faut une version 2.2 ou supérieure de Python pour
> avoir cette fonction). Note bien que quoteattr() a été conçu pour HTML
> ou SGML, pas pour la conformité XML ou XHTML (la conformité XML vient
> avec la version 2.3 il me semble, sinon il te faut passer un paramètre
> entities ; Python est actuellement en version 2.7)
>
>
> Le 10 février 2012 12:45, Philippe Verdy  a écrit :
>> A mon avis le bogue est surtout à corriger dans la fonction
>> quoteattr() du module Python "sax.saxutils".
>>
>> Car ***même*** en HTML ou SGML (au lieu de XML ou XHTML) il faudrait
>> systématiquement recoder un "&" présent dans une valeur qu'on veut
>> encapsuler dans un attribut d'élément HTML (ou XML). Tout parseur HTML
>> ou SGML reconnait "&" automatiquement (sans avoir besoin de
>> définir l'entité), mais ***tolère*** (par compatibilité ascendante
>> avec les très vieux navigateurs HTML, d'avant même HTML4) des valeurs
>> contenant des entités mal codées (dans ce cas un parseur HTML a un
>> "fallback" lui permettant de réinterpréter la valeur donnée sans faire
>> le décodage des entités, mais PAS un parseur XML qui s'y refuse, car
>> c'est un trou de sécurité).
>>
>> Le code d'Osmose visiblement l'oublie quand il génère aussi d'autres
>> URLs "en dur" à d'autres endroits de la page HTML du frontend (mais ce
>> frontend est codé pour générer du HTML, pas du XHTML, ce qui autorise
>> le "fallback" pourtant pas recommandé du tout et dangereux).
>>
 Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
 Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
 version de développement.

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

Re: [OSM-talk-fr] bonjour + utilisation de data.gouv.fr

[Christian Quest]

Le 8 février 2012 16:03,  a écrit :
>
> Bonjour,
> j'arrive fraichement sur le talk-fr bien que contribuant déjà depuis quelques 
> temps à OSM (notamment dans les forêts sarthoises, grâce à mon précieux GPS, 
> Garmin Oregon de son petit nom). J'ai un peu fouillé dans data.gouv.fr, et ai 
> déniché des données qui me semblent intéressantes : les périmètres des forêts 
> publiques, produites par l'ONF. Je me suis permis de mettre à jour le wiki en 
> ce sens. Par ailleurs, j'ai intégré le périmètre de la forêt domaniale de 
> Sillé-le-Guillaume à OSM avec landuse=forest et name="forêt domaniale de 
> Sillé-le-Guillaume". Je suis en train de faire les vérifications mais le 
> tracé me semble très précis (sans commune mesure avec Corine Landcover). Il 
> faudra simplement retirer du polygone les maisons forestières, les étangs et 
> les quelques prairies permanentes, et retirer la couche issue de Corine 
> Landcover, ou plutôt n'y laisser que les forêts privées attenantes à la forêt 
> domaniale. Qu'en pensez-vous ?
>  Par ailleurs, j'ai importé quelques cours d'eau issus de data.gouv.fr 
> (agence de l'eau Loire-Bretagne), toujours dans les forêts publiques 
> sarthoises. Leur précision semble relativement bonne (de l'ordre de 10m a 
> priori), après vérification de terrain. Votre avis sur la faisabilité à plus 
> grande échelle ?
> Bien cordialement,
> Sylvain H.
>

Je viens de regarder ce jeu de fichier SHP issus de l'ONF.

Voir: http://bit.ly/yaKcYS

Ca a effectivement l'air relativement précis au niveau du tracé.
Mais... la description indique "Contours des forêts publiques relevant
du régime forestier : terrains domaniaux et communaux, y compris les
terrains qui ne sont pas en nature de forêt."

- on a donc un mélange entre du landuse=forest et parfois autre chose.
- seules les forêts publiques y figurent

Un apport me semble être la récupération des noms des forêts
publiques, et leur caractère publique ce qui peut être utile
(access=yes ? ou un leisure=forest ?).

--
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Le 10 février 2012 12:56, Jocelyn Jaubert  a écrit :
> Bonjour,
>
> (je redirige sur dev-fr où ça a plus sa place)
>
> Le 10 février 2012, Philippe Verdy a écrit :
>
>> 369               self._write(' %s=%s' % (name, quoteattr(value)))
>> 378               self._write(' %s=%s' % (name, quoteattr(value)))
>>
>> En effet, la fonction Python quoteattr() ne représente pas
>> correctement le caractère "&" qu'il laisse sous cette forme, alors
>> qu'il FAUT le réencoder sous la forme "&"
>>
>> La fonction quoteattr() est importée depuis le module Python
>> "sax.saxutils", absent dans les sources GIT d'Osmose. C'est elle qui
>> est ici en cause.
>
> Cette fonction fait parti de la librairie python standard, et sa
> documentation se trouve là:
>
> http://docs.python.org/library/xml.sax.utils.html
>
> D'après la doc, quoteattr() échappe bien les & < et >, donc je ne
> comprends pas le problème.

Tu as une doc à jour, mais pas le module Python à jour qui correspond,
sans doute un module de Python v1. Il y a eu de nombreuses corrections
de sécurité dedans (y compris une correction dans l'ordre de
substitution de "&", uniquement dans Python 2.1.1, puis ensuite des
tentatives  "simplifications" du code sans utiliser escape() en
interne... suivi aussitôt d'une anomalie avec une attaque de sécurité
XSS sur un certain nombre de sites.

C'est pour ça que je t'ai fourni des liens vers des versions
correctes. Car je ne sais pas du tout quelle version tu as chargée et
utilisée (depuis quel repository Python ??? Il y en a plein, pas
toujours conformes à l'original ou ne prenant pas en compte les
corrections pourtant approuvées).

> Est-ce que tu pourrais donner un lien sur osmose.openstreetmap.fr qui
> montrerait le problème ?  (avec le permalink en bas à droite)

Oui, mais j'ai corrigé un problème, il n'apparait plus dans Osmose là
où je l'ai vu la première fois.

J'en ai vu ailleurs dans les noms relations de sites géodésiques (dont
les membres sont des noeuds groupés sur une même collection dont la
relation donne une référence commune avec une URL vers le site de
géosésie de l'IGN, ces URL contenant des "&" puisqu'elles contiennent
des paramètres.

Et j'ai vu ces mêmes URL corrompues par endroit (j'aurais du regarder
l'historique, pour voir que cela venait bien de rawedit).

Si tu n'en voit pas, crée un point avec une erreur de tonomymie dans
JOSM qu'Osmose signalera (par exemple donne un nom comme "BOUTIQUE
C&A", Osmose ralera sur les majuscules, ouvre le noeud signalé. Tu
verras que même sans rien toucher, il refusera la modification. Mets
une URL en valeur contenant des paramètres de requêtes: dans JOSM il
n'est pas nécessaire et on ne doit rien substituer à l'écran, JOSM
fait correctement les encodages et décodage URL quand il utilise l'API
d'OSM (mais pas Osmose aussi bien dans ses URLs insérées dans le
Frontend HTML/CSS/JS que dans le code Javascript qui communique en XML
avec le Backend d'Osmose, qui vérifie la requête puis renvoie vers
l'API d'OSM).

>>  Deuxième problème (lié au premier) ===
>>
>> Enfin je note que le code Javascript envoyé au client utilise le
>> constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
>> caractères qui sera utilisé pour dialoguer avec le serveur :
>
> Le fait que la page html et le fichier .js soient encodées en UTF-8 via
> les headers HTTP ne suffit pas à informer le navigateur ?
>
>
> Et est-ce que tu peux donner un exemple d'objet "corrompu" sur OSM ?

Si tu charges une zones assez grande dans JOSM, il suffit de regarder
les valeurs chargées énumérées dans la liste de valeurs existantes
d'un attribut comme "source". Tu y verras des tas de caractères ""
noirs là où auraient du rester des caractères accentués, visiblement
édités sur un navigateur Macintosh; sélectionne cette valeur dans la
liste, uniquement pour la copier dans le presse-papier. Puis recherche
les objets contenant cette valeur incorrecte.

Tu vas en trouver beaucoup.

Ensuite regarde les historiques: tu verras qu'ils proviennent de "rawedit".

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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Le 10 février 2012 13:42, Philippe Verdy  a écrit :
> Ensuite regarde les historiques: tu verras qu'ils proviennent de "rawedit".

D'ailleurs je suggère que les historiques de modifications indique
dans le champ mentionnant le logiciel utilisé, non seulement la
version de ce logiciel, mais aussi pour tous les éditeurs en ligne
(Potlatch et rawedit inclus) l'indication du type de navigateur
utilisé et sa version (le "user-agent") qui précise aussi la
plateforme hôte du client (Windows, Mac, Linux...).

Afin de repérer aussi les incompatiblités de certains navigateurs avec
le code Javascript utilisé. Et de motiver aussi l'utilisation de
jQuery au lieu d'un code "maison" oubliant de prendre en compte des
problèmes de compatibilité.

A mon avis, les utilisateurs de vieilles versions d'Internet Explorer
avec ces éditeurs en ligne peuvent causer de sérieux problème de
corruption de données, et la base OSM n'est pas suffisamment à l'abri
d'attaques de type XSS (contre lesquelles jQuery du coté javascript
client, et les frameworks associés côté serveur fournissent une
meilleure protection, à condition que vous les gardiez à jour !)

Méfiance avec les modules de frameworks Python dont les sources ne
proviennent pas de repositories officiels, correctement maintenus et
versionnés, ou le code "maison" sensé simplifier le code, surtout si
vous ne pouvez pas tester vous même tous les problèmes connus de
compatibilité avec ces navigateurs exotiques ou anciens et bogués mais
encore utilisés (pour lesquels les frameworks maintenus fournissent
une parade efficace, et tant pis si les vieux navigateurs sont à la
peine question performance).

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

[OSM-talk-fr] Changement de ref pour des routes dans l'Oise

[Damouns]

Une décision publiée sur le site du bulletin officiel du ministère du
Développement Durable :
http://www.bulletin-officiel.developpement-durable.gouv.fr/fiches/BO20121/met_20120001_0100_0011.pdf

En gros, près de Compiègne, une partie de la N 31 devient la N 2031,
et une partie de la N 1031 devient la nouvelle N 31.

N'étant pas du coin j'ai du mal à visualiser les routes en question...

Si quelqu'un veut bien faire les modifs.

Emplacement : http://www.openstreetmap.org/?lat=49.4243&lon=2.8253&zoom=14

Damouns

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

Re: [OSM-talk-fr] Changement de ref pour des routes dans l'Oise

[didier2020]

- Mail d'origine -
De: Damouns 
À: Discussions sur OSM en français 
Envoyé: Fri, 10 Feb 2012 14:18:42 +0100 (CET)
Objet: [OSM-talk-fr] Changement de ref pour des routes dans l'Oise

Une décision publiée sur le site du bulletin officiel du ministère du
Développement Durable :
http://www.bulletin-officiel.developpement-durable.gouv.fr/fiches/BO20121/met_20120001_0100_0011.pdf

En gros, près de Compiègne, une partie de la N 31 devient la N 2031,
et une partie de la N 1031 devient la nouvelle N 31.

N'étant pas du coin j'ai du mal à visualiser les routes en question...

N1031 ->  N31
http://www.openstreetmap.org/?lat=49.41843&lon=2.79171&zoom=15&layers=M
la voie est en trunk
Le Pr 0 est au sud ouest, le pr 7 au nord est , jonction d932

N31 -> N2031
C'est la N31 qui passe dans le centre de compiègne. Le Pr 80 etant a l'ouest 
(echangeur avec voie N1031), le 87 a l'est (d130/rocade)

Il faudra ajouter un tag indiquant le changement,
les panneaux sont souvent changés bien plus tardivement après les décisions 
préfectorales.

didier

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

Re: [OSM-talk-fr] Changement de ref pour des routes dans l'Oise

[Damouns]

Le 10 février 2012 14:46,   a écrit :
> N1031 ->  N31
> http://www.openstreetmap.org/?lat=49.41843&lon=2.79171&zoom=15&layers=M
> la voie est en trunk
> Le Pr 0 est au sud ouest, le pr 7 au nord est , jonction d932
>
> N31 -> N2031
> C'est la N31 qui passe dans le centre de compiègne. Le Pr 80 etant a l'ouest 
> (echangeur avec voie N1031), le 87 a l'est (d130/rocade)
>
> Il faudra ajouter un tag indiquant le changement,
> les panneaux sont souvent changés bien plus tardivement après les décisions 
> préfectorales.

Tu veux bien faire les modifs ? Et pour le tag indiquant le
changement, une note=* suffirait ? Avec old_ref bien sûr ?

Damouns

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

Re: [OSM-talk-fr] Changement de ref pour des routes dans l'Oise

[Fabien]

Bonjour,

Je ne suis pas réellement concerné dans ce cas mais ne faudrait-il pas
conserver en l'état actuellement ?
On dit toujours que le visuel fait foi mais si on change directement après
une "loi" ça paraît étrange non ?
Surtout qu'on sait que la mise enplace de panneaux ne sera effectif que
d'ici quelques mois. Un utilisateur pourrait effacer les changements parce
que lui en relevé GPS voit bien autre chose.

Fabien
Le 10 févr. 2012 14:55, "Damouns"  a écrit :

> Le 10 février 2012 14:46,   a écrit :
> > N1031 ->  N31
> > http://www.openstreetmap.org/?lat=49.41843&lon=2.79171&zoom=15&layers=M
> > la voie est en trunk
> > Le Pr 0 est au sud ouest, le pr 7 au nord est , jonction d932
> >
> > N31 -> N2031
> > C'est la N31 qui passe dans le centre de compiègne. Le Pr 80 etant a
> l'ouest (echangeur avec voie N1031), le 87 a l'est (d130/rocade)
> >
> > Il faudra ajouter un tag indiquant le changement,
> > les panneaux sont souvent changés bien plus tardivement après les
> décisions préfectorales.
>
> Tu veux bien faire les modifs ? Et pour le tag indiquant le
> changement, une note=* suffirait ? Avec old_ref bien sûr ?
>
> Damouns
>
> ___
> 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] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Frédéric Rodrigo]

>> Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
>> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
>> version de développement.
>
> J'ai regardé justement, mais je n'ai trouvé aucun contact, ou section
> en place sur le site pour signaler et suivre l'anomalie (par exemple
> Bugzilla).
>
> On trouve juste un endroit pour soumettre une branche, qui sera
> difficilement acceptée si on n'explique rien. Ce qui suppose qu'en
> fait ce repository n'a qu'un seul mainteneur qui travaille seul mais
> qui omet de fournir un point de contact.

Actuellement seul Jocelyn commites sur le dépôt principal. Mais il y a
plusieurs clones, dont le mien. Sur le quel je fais beaucoup de
modifications et qui sont intégrées (et validé) par Jocelyn.

Tu peux aussi te créer une clone et commiter dessus avec des
commentaires pour expliquer le pourquoi et proposer des modifications
à l'intégration d'osmose (c'est le principe fonctionnement de
gitorious).
Bien sur il est possible d'en discuter sur la ML-dev ou sur IRC.

Frédéric.

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

Re: [OSM-talk-fr] Changement de ref pour des routes dans l'Oise

[Damouns]

Le 10 février 2012 15:01, Fabien  a écrit :
> Je ne suis pas réellement concerné dans ce cas mais ne faudrait-il pas
> conserver en l'état actuellement ?

Ça se discute... en tout cas il n'y a effectivement pas d'urgence si
les panneaux sur le site ne sont pas encore à jour.

D'où l'intérêt de demander aux contributeurs locaux.

Ça peut attendre donc.

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

Re: [OSM-talk-fr] Changement de ref pour des routes dans l'Oise

[didier2020]

- Mail d'origine -
De: Fabien 
À: Discussions sur OSM en français 
Envoyé: Fri, 10 Feb 2012 15:01:25 +0100 (CET)
Objet: Re: [OSM-talk-fr] Changement de ref pour des routes dans l'Oise

Bonjour,

Je ne suis pas réellement concerné dans ce cas mais ne faudrait-il pas
conserver en l'état actuellement ?
On dit toujours que le visuel fait foi mais si on change directement après
une "loi" ça paraît étrange non ?
Surtout qu'on sait que la mise enplace de panneaux ne sera effectif que
d'ici quelques mois. Un utilisateur pourrait effacer les changements parce
que lui en relevé GPS voit bien autre chose.

=> Tu as raison, si on change le ref trop tot il pourra etre remodifié de toute 
bonne fois.

=> Ici c'est la préfecture donc "reg_ref= N xx" peut etre utilisé.
Le wiki ne donne pas de reponse exacte d'ou l'utilité de noter la référence du 
changement dans le changeset et meme sur les way.

didier


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

Re: [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Le 10 février 2012 15:02, Frédéric Rodrigo  a écrit :
>>> Mon dépôt osmose sur gitorious n'est pas vraiment une référence.
>>> Regardes plutôt la branche dev de http://gitorious.org/osmose pour la
>>> version de développement.
>>
>> J'ai regardé justement, mais je n'ai trouvé aucun contact, ou section
>> en place sur le site pour signaler et suivre l'anomalie (par exemple
>> Bugzilla).
>>
>> On trouve juste un endroit pour soumettre une branche, qui sera
>> difficilement acceptée si on n'explique rien. Ce qui suppose qu'en
>> fait ce repository n'a qu'un seul mainteneur qui travaille seul mais
>> qui omet de fournir un point de contact.
>
> Actuellement seul Jocelyn commites sur le dépôt principal. Mais il y a
> plusieurs clones, dont le mien. Sur le quel je fais beaucoup de
> modifications et qui sont intégrées (et validé) par Jocelyn.
>
> Tu peux aussi te créer une clone et commiter dessus avec des
> commentaires pour expliquer le pourquoi et proposer des modifications
> à l'intégration d'osmose (c'est le principe fonctionnement de
> gitorious).
> Bien sur il est possible d'en discuter sur la ML-dev ou sur IRC.

Multiplier les dépôts sans mettre en place un suivi centralisé des
anomalies pour savoir qui fait quoi, c'est pas très utile. Tous les
projets opensource ont un système comme Bugzilla pour remonter les
anomalies, les reclasser, en gérer la planification et les tests
d'intégration, et ne pas compter que sur les discussions.

Je persiste ici à dire que c'est du au manque de versionnement central
qu'une version incorrecte de Python a été installée sur le serveur
Osmose.openstreetmap. Je me demande si vous savez quelles versions des
bibliothèques Python sont installées et d'où elles viennent, puisque
cela ne figure même pas dans vos repositories, qui ne documentent pas
non plus les versions testées nécessaires.

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

Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Etienne Trimaille]

Bon, j'ai enfin pris le temps de retester cet outil ;-)

Est-ce possible de prendre en compte les building=* en compte ?
Je ne comprends pas toujours le résultats :
Avec building=apartements / train_station dans la base OSM, ton outils met
le bati dans ok.osm.
Avec building=supermarket dans OSM, ton outils met le bati dans
nofusion.osm.

Je précise que pour les 2 types apartements et supermarket, les bâtiments
sont exactements au même endroits entre les 2 fichiers OSM (courant.osm et
cadastre.osm).Je ne pense pas que cela soit le bon résultat, non ? Ils
devraient se trouver dans nofusion.osm ?

Et en théorie, si j'ai bien compris les différents fichiers :
ok.osm, à importer car aucune intersection
nofusion.osm, à importer après verif des petites intersections
fusion.osm, à ne pas importer, car bati déjà présent dans la base
conflit.osm, à vérifier manuellement
C'est bien çà ?

Pour obtenir les batiments qui ont été supprimés du cadastre, mais présent
dans OSM ?

Merci pour l'outil ;-)
Etienne

Le 8 janvier 2012 23:17, Jérôme Cornet  a écrit :

> De rien de rien :-)
>
> Ce qui me fait le plus plaisir, c'est de savoir que ça t'as été utile.
> N'hésites pas si tu veux que je change/améliore des choses. :-)
>
> Jérôme, tout content
>
>
> Le 8 janv. 2012 à 22:36, Etienne Trimaille a écrit :
>
> > Parce qu'il n'est pas trop tard pour dire merci, alors je te le dis
> cette fois-ci : merci :)
> >
> > Il me semble, d'après me souvenirs, que j'ai eu quelques soucis avec les
> différents fichiers au début. Mais j'ai finalement réussi à faire la mise à
> jour de ma commune.
> > Je vais avoir plus de temps dans 2 semaines pour retester ton outil ;-)
>
> ___
> 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] Point adresse à Montpellier - Qui ?

[isnogoud]

Le 10/02/2012 11:40, rldhont a écrit :
Désolé, mais c'est naturel chez moi... ça va tellement plus vite... 
c'est comme la ligne de commande, ssh, etc.


Le 10/02/2012 10:54, Ab_fab a écrit :
Personne n'avait pris PostGIS LV2 au lycée, mais c'était une solution 
de repli identifiée en cas de blocage.


Les essais d'Isnogoud ont ** rapidement ** donné de bons résultats, 
donc la mise en place d'une BDD spatiale n'a pas été nécessaire pour 
aboutir à des fichiers exploitables.


Le 10 février 2012 08:38, rldhont > a écrit :






Tu es tout excusé : pour traiter les données opendata, je suis plus à 
l'aise avec une base de données relationnelle classique qu'avec les 
outils géomatiques.
Mais ta réflexion m'incite à aller approfondir le sujet PostGIS à l'aide 
du wiki d'OSM.


Par ailleurs, je confirme qu'il reste des rues non mappées par OSM à 
Montpellier et des noms de rue qui diffèrent de ceux de l'opendata.

L'import semi-automatique est probablement la démarche la mieux adaptée.

Bruno est disposé à communiquer les éléments techniques de son site web.
Les fichiers xml associés peuvent être fournis rapidement.

Il nous faut simplement un ou plusieurs interlocuteurs pour organiser et 
animer l'import sur Montpellier.


Qui est partant ?

Librement

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

[OSM-talk-fr] mooring=yes plante JOSM

[Claude]

bonjour

je vient de constater une chose étrange

lorque j'attribue la balise "mooring=yes" sur une ligne, JOSM se bloque 
et ne répond plus: la  fenêtre devient toute blanche et le curseur a la 
forme d'une croix.
Je l'ai constaté sur 2 machine différente toutes les 2 sous linux Debian 
6 avec la version 4878

quelqu'un peut-il confirmer?

merci
cordialement
claude

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

Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Jérôme Cornet]

Le 10 févr. 2012 à 17:44, Etienne Trimaille a écrit :

> Bon, j'ai enfin pris le temps de retester cet outil ;-)
> 
> Est-ce possible de prendre en compte les building=* en compte ?

Ahem… je dois avouer piteusement en public que je n'avais pas connaissance de 
ces variations sur tag building. Et donc…
les bâtiments qui sont en building=XX ou XX n'est pas yes sont complètement 
ignorés de la comparaison! (arg)

> Je ne comprends pas toujours le résultats : 
> Avec building=apartements / train_station dans la base OSM, ton outils met le 
> bati dans ok.osm.
> Avec building=supermarket dans OSM, ton outils met le bati dans nofusion.osm.

En fait cela ne dépend pas du type de building… (vu que je ne reconnais que 
building=yes). La différence
que tu as observé est liée probablement à une intersection avec un autre 
polygone qui lui était taggé building=yes.

> Je précise que pour les 2 types apartements et supermarket, les bâtiments 
> sont exactements au même endroits entre les 2 fichiers OSM (courant.osm et 
> cadastre.osm).Je ne pense pas que cela soit le bon résultat, non ? Ils 
> devraient se trouver dans nofusion.osm ?

Euh je ne comprend pas bien cette partie. Dans le cadastre on a uniquement du 
building=yes non?

> Et en théorie, si j'ai bien compris les différents fichiers : 
> ok.osm, à importer car aucune intersection

Oui, même si l'outil pouvant avoir des failles (comme nous venons juste de le 
voir), il est bon de vérifier.

> nofusion.osm, à importer après verif des petites intersections

Exact

> fusion.osm, à ne pas importer, car bati déjà présent dans la base

Ben là ça dépend des opinions. Préfères-tu un bâtiment dessiné exactement comme 
dans le cadastre, ou garder
quelque chose d'approximatif fait à la main, pas forcément au bon niveau de 
détail? (je sais j'en ai fait nombre à la main
à la grande époque). Si tu souhaites avoir la précision du cadastre, et les 
tags intéressants rentrés sur la version faite
 à la main, le calque "Fusion" est censé réimporter les tags utilisateur sur le 
bâti cadastre (et sur les points, notamment
pour les adresses). Après c'est une question d'opinion/de temps et aussi que le 
processus de fusion se passe bien. 

> conflit.osm, à vérifier manuellement
> C'est bien çà ?

Oui.

> Pour obtenir les batiments qui ont été supprimés du cadastre, mais présent 
> dans OSM ?

Peut-être en inversant les deux fichiers en arguments (cadastre et calque osm) 
et en regardant la sortie .ok.
Je peux faire une option spéciale sinon si tu m'expliques à quoi ça te sert, 
quel comportement tu veux, etc.

> Merci pour l'outil ;-)

Merci pour le feedback, il n'y a que comme ça qu'on le fera progresser.

La morale de l'histoire, c'est que comme toujours, il n'y a pas d'outils 
automatiques, et bati-fusion est clairement un outil semi-automatique,
qui requiert un contrôle manuel. Ne pas faire confiance aveuglément, et ne 
jamais importer un calque de sortie dans avoir préalablement
vérifié que tout allait bien (y compris sur le .ok).

Sur le site github, il y a un "tracker" de bugs 
(https://github.com/jecor/bati-fusion/issues). Il y a un autre problème qui a 
été trouvé par un utilisateur
 à notlm-grenoble: l'outil suppose qu'on a téléchargé toute la commune pour le 
calque osm. Dans certaines zones denses, ça n'est pas toujours 
possible…. dans ce cas il faut donc faire très gaffe avec les bâtiments 
"hors-zone" qui sont tous marqués ok.

Je m'en vais fixer les bugs au plus vite,

Jérôme

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

Re: [OSM-talk-fr] mooring=yes plante JOSM

[Brice Hardy]

Ça ne le fait pas sur Mac si jamais ça peut aider...
Le 10 févr. 2012 à 20:13, Claude a écrit :

> bonjour
> 
> je vient de constater une chose étrange
> 
> lorque j'attribue la balise "mooring=yes" sur une ligne, JOSM se bloque et ne 
> répond plus: la  fenêtre devient toute blanche et le curseur a la forme d'une 
> croix.
> Je l'ai constaté sur 2 machine différente toutes les 2 sous linux Debian 6 
> avec la version 4878
> quelqu'un peut-il confirmer?
> 
> merci
> cordialement
> claude
> 
> ___
> 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] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Philippe Verdy]

Juste une idée, comme ça:

Il n'y a pas moyen avec votre outil de marquer les bâtiments importés
avec un numéro de parcelle (par exemple le plus petit numéro de
parcelle où il est construit), ou le numéro de rue dans une
agglomération, et insérer cette référence dans un tag de suivi, afin
de savoir qu'il a été rapproché avec le cadastre, et ensuite permettra
de savoir ceux qui ont été modifiés ?

Cela soulagerait ensuite bien des comparaisons géomatiques hasardeuses
et faciliterait aussi les synchronisations lors d'imports de nouveaux
bâtis, tout comme de permettre aussi d'avoir un état statistique du
bâti manquant ou à corriger/fusionner.

On insère bien des références Insee et NUTS pour les relations de
communes, départements, arrondissements, régions, ou des codes SIREN
pour les relations des intercommunalités...

Ce qui permet justement des rapprochements de fichiers plus faciles et
moins d'erreurs (par exemple sur les graphies ou toponymes alternatifs
ou ambigus) dès lors que les géolocalisations ne correspondent pas
exactement (surtout quand une source utilise une précision différente
dans les géométries de contours ou les centroïdes renseignés, ou parce
que cette géométrie a évolué au cours du temps et que les données
prennent en compte des dates de mise à jour différentes de cette
géométrie).

Le 10 février 2012 20:24, Jérôme Cornet  a écrit :
> Le 10 févr. 2012 à 17:44, Etienne Trimaille a écrit :
>
>> Bon, j'ai enfin pris le temps de retester cet outil ;-)
>>
>> Est-ce possible de prendre en compte les building=* en compte ?
>
> Ahem… je dois avouer piteusement en public que je n'avais pas connaissance de 
> ces variations sur tag building. Et donc…
> les bâtiments qui sont en building=XX ou XX n'est pas yes sont complètement 
> ignorés de la comparaison! (arg)
>
>> Je ne comprends pas toujours le résultats :
>> Avec building=apartements / train_station dans la base OSM, ton outils met 
>> le bati dans ok.osm.
>> Avec building=supermarket dans OSM, ton outils met le bati dans nofusion.osm.
>
> En fait cela ne dépend pas du type de building… (vu que je ne reconnais que 
> building=yes). La différence
> que tu as observé est liée probablement à une intersection avec un autre 
> polygone qui lui était taggé building=yes.
>
>> Je précise que pour les 2 types apartements et supermarket, les bâtiments 
>> sont exactements au même endroits entre les 2 fichiers OSM (courant.osm et 
>> cadastre.osm).Je ne pense pas que cela soit le bon résultat, non ? Ils 
>> devraient se trouver dans nofusion.osm ?
>
> Euh je ne comprend pas bien cette partie. Dans le cadastre on a uniquement du 
> building=yes non?
>
>> Et en théorie, si j'ai bien compris les différents fichiers :
>> ok.osm, à importer car aucune intersection
>
> Oui, même si l'outil pouvant avoir des failles (comme nous venons juste de le 
> voir), il est bon de vérifier.
>
>> nofusion.osm, à importer après verif des petites intersections
>
> Exact
>
>> fusion.osm, à ne pas importer, car bati déjà présent dans la base
>
> Ben là ça dépend des opinions. Préfères-tu un bâtiment dessiné exactement 
> comme dans le cadastre, ou garder
> quelque chose d'approximatif fait à la main, pas forcément au bon niveau de 
> détail? (je sais j'en ai fait nombre à la main
> à la grande époque). Si tu souhaites avoir la précision du cadastre, et les 
> tags intéressants rentrés sur la version faite
>  à la main, le calque "Fusion" est censé réimporter les tags utilisateur sur 
> le bâti cadastre (et sur les points, notamment
> pour les adresses). Après c'est une question d'opinion/de temps et aussi que 
> le processus de fusion se passe bien.
>
>> conflit.osm, à vérifier manuellement
>> C'est bien çà ?
>
> Oui.
>
>> Pour obtenir les batiments qui ont été supprimés du cadastre, mais présent 
>> dans OSM ?
>
> Peut-être en inversant les deux fichiers en arguments (cadastre et calque 
> osm) et en regardant la sortie .ok.
> Je peux faire une option spéciale sinon si tu m'expliques à quoi ça te sert, 
> quel comportement tu veux, etc.
>
>> Merci pour l'outil ;-)
>
> Merci pour le feedback, il n'y a que comme ça qu'on le fera progresser.
>
> La morale de l'histoire, c'est que comme toujours, il n'y a pas d'outils 
> automatiques, et bati-fusion est clairement un outil semi-automatique,
> qui requiert un contrôle manuel. Ne pas faire confiance aveuglément, et ne 
> jamais importer un calque de sortie dans avoir préalablement
> vérifié que tout allait bien (y compris sur le .ok).
>
> Sur le site github, il y a un "tracker" de bugs 
> (https://github.com/jecor/bati-fusion/issues). Il y a un autre problème qui a 
> été trouvé par un utilisateur
>  à notlm-grenoble: l'outil suppose qu'on a téléchargé toute la commune pour 
> le calque osm. Dans certaines zones denses, ça n'est pas toujours
> possible…. dans ce cas il faut donc faire très gaffe avec les bâtiments 
> "hors-zone" qui sont tous marqués ok.
>
> Je m'en vais fixer les bugs au plus vite,
>
> Jérôme
>
> 

[OSM-talk-fr] forum: extraction a parir de BD

[forum]

Le message suivant :
##
salut , bon mon problème est comment extraire les données a partir des tables 
des bases des données déjà prête sous qgis pour exporter sous c++ pour après 
commencer a qu'on appelle routing c a dire aller de A vers B a laide de plus 
court chemin aussi comment peut avoir les coordonnées dune point quelconque le 
hauteur le longitudinale ... sous Qgis merc


a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=3
Une réponse sur la liste directement n'est hélas pas transmise sur le forum, 
ce qui n'empeche pas une concertation avant réponse par email.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour repondre.
--
Tout commentaire sur ce message peut être demandé à sylvainaletuffe.org

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

Re: [OSM-talk-fr] mooring=yes plante JOSM

[didier2020]

Le vendredi 10 février 2012 à 20:13 +0100, Claude a écrit :
> bonjour
> 
> je vient de constater une chose étrange
> 
> lorque j'attribue la balise "mooring=yes" sur une ligne, JOSM se bloque 
> et ne répond plus: la  fenêtre devient toute blanche et le curseur a la 
> forme d'une croix.
> Je l'ai constaté sur 2 machine différente toutes les 2 sous linux Debian 
> 6 avec la version 4878
> quelqu'un peut-il confirmer?
> 
negatif pour moi - debian 6 & 4878 

didier

> merci
> cordialement
> claude
> 
> ___
> 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] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Philippe Verdy]

Encore une note: le cadastre n'est pas nécessairement complet sur le
bati, même pour des batiments construits il y a plusieurs dizaines
d'années (et ayant en plus fait l'objet de permis de construire en
bonne et due forme).

Le cadastre est sensé aussi donner la position des puits, mais il en
manque énormément, surtout dans les campagnes quand ces puits ont été
creusés alors que les communes n'avaient pas construit les réseaux
d'eau potable et autorisaient donc le creusement de puits par une
simple déclaration sans forcément donner une position exacte.

Depuis les collectivités obligent les propriétaires à faire faire des
analyses de l'eau et des relevés de niveaux afin de protéger les
ressources en eau du voisinage et détecter les pollutions d'origine
agricole. Elles obligent aussi à faire contrôler les rejets des eaux
traitées par les fosses septiques (ce qui me semble un peu excessif,
car un propriétaire n'a pas intérêt du tout à empoisonner ou étouffer
sa fosse septique en mettant n'importe quels produits dans les
toilettes ou éviers, surtout s'il n'y a pas de raccordement à un
réseau public d'eaux usées (même si les communes ou intercommunalités,
ainsi que les agences de bassin font payer quand même
l'assainissement...)

Les mêmes communes obligent aussi les propriétaires à prendre un
raccordement au réseaux d'eaux potables et usées quand ils sont
construits, même si on ne s'en sert pas (et alors elles obligent aussi
à la séparation complète des réseaux privés et publics, et des
robinets et regards de purge, et pejuvent aussi prendre des arrêtés
interdisant aux propriétaires de pomper dans leurs puits en période de
restrictions en eau (de peut que les pompages privés viennent assécher
les points de pompage du réseau public), et à poser aussi des
compteurs agréés sur les pompes.

Pourtant la plupart n'ont aucune idée où sont précisément ces puits,
qui ne figurent pas dans le cadastre et donc pas dans leurs SIG non
plus hormis de façon uniquement qualitative dans des listes de
propriétés (mais sans mention de la parcelle non plus)...

C'est pareil pour bon nombre d'extensions de bâtiments, oubliées dans
le cadastre parce que ce ne sont pas des surfaces habitables (au sens
du fisc), les terrasses et les vérandas construites en dur, bon nombre
d'étangs et de piscines (même déclarées avec un permis de construire),
bon nombre de murs mitoyens, de chemins empierrrés, de petites
rivières et fossés drainants enterrés dans des canalisations peu
profondes...

Le bati du cadastre est finalement pas si bon que ça (surtout en zone
très rurale, forestière, ou périurbaine quand ces zones sont hors de
réserves naturelles avec un contrôle plus poussé sur ce qui y est
installé)

Et souvent même la position, la taille et l'orientation des bâtiments
reste assez approximative, faite à main levée à une échelle pas
toujours respectée non plus, sur la base de plans qui mentionnaient
des dimensions et orientations non certifiées par un géomètre (du
moment que ça rentrait dans la parcelle et qu'il y avait respect de
certaines distances minimales avec les voisins ou la voirie, et qu'il
n'y a pas eu de plainte du voisinage ou par un acheteur contre un
vendeur, il n'y a que les déclarations de travaux avant l'accord des
permis de construire ou de creuser qui comptent car même un n notaire
ne conteste pas le cadastre et bon nombre de ventes dans l'ancien se
font dans l'état, bâtiments et terrains inclus).

Quant à la certification récente de la surface habitable, obligatoire
pour les vendeurs, elle ne correspond en rien à l'emprise d'un
bâtiment sur un terrain et ne permet pas de rapprochement et
correction dans le cadastre

Enfin les collectivités très peu denses et pauvres en budget n'ont pas
envie de payer des sommes énormes pour payer quelqu'un à traiter des
photos aériennes géolocalisées de façon précise par des géomètres
qualifiés, car ça leur coûterait très cher sur une mission très longue
pour très peu de bénéfice au final (sauf fraude manifeste par un
propriétaire et que quelqu'un viendrait leur signaler), sachant que
ces propriétés privées ne sont pas accessibles à beaucoup de monde,
que peu de monde peut faire de la photo aérienne (ou peut acheter des
clichés satellite vendus encore "en gros" sur des zones trop grandes),
et que pour qu'une collectivité envoie un huissier avec un géomètre
constater une fraude sur une propriété privée, elle doit aussi les
payer et y trouver son compte en terme d'entrée fiscale. Ces contrôles
se font alors au hasard, ou seulement à l'occasion d'aménagements
publics à proximité immédiate, lorsqu'ils font des études d'impact sur
le voisinage du projet.

Par conséquent, les zones rurales ou périurbaines qui sont sorties des
zones constructibles des anciens POS ou des actuels PLU ne sont plus
contrôlées du tout, tant qu'il n'y a pas de vente (saisies
judiciaires, séparation de biens lors de divorces, partage dans une
succession), et entâchent le cadastre d'erreurs et d'omissions parfois
grossiè

Re: [OSM-talk-fr] mooring=yes plante JOSM

[Philippe Verdy]

Sans doute une anomalie dans les données de ton fichier OSM en mémoire
(JOSM signale parfois des bogues internes lors de certaines
modifications). Sauve-le sur disque et relance JOSM pour recharger le
fichier proprement...

Peut-être aussi qu'il te faut monter la quantité de mémoire virtuelle
pour la machine Java (paramètre -Xmx sur la ligne de commande, moi j'y
ai mis 8 Go et je suis tranquille, mais mon PC a 32 Go de RAM physique
et un processeur 8 coeurs, ce qui ne pose aucun problème de swap
excessif ou de performance du garbage collector, même avec d'autres
applications lourdes voire plusieurs instances de JOSM en parallèle,
ou un OS virtuel utilisant 2 coeurs).

Mes fichiers OSM thématiques font facilement plus de 1Go avec plus
d'un million de noeuds ; pourtant ça ne prend que quelques secondes à
sauver, et moins d'une minute à charger ou dans les tests du
validateur (même pour le contrôle de superposition des bâtiments, qui
est le test le plus long en raison du nombre élevé de superposition de
traits dans les zones urbaines). Mais je n'ai aucune erreur de la
sorte dans JOSM (hormi un bogue mineur lors de de la sélection dans la
liste de warnings du validateur d'objets déjà supprimés (la
suppression ou la fusion d'objets n'ôte pas leur référence dans la
liste des avertissements du validateur, on peut encore les ajouter à
la sélection courante, et cliquer dessus en tentant de voir ses
propriétés, et JOSM signale une exception interne qui n'a rien de
critique, et qui permet de continuer sans problème).

Le 10 février 2012 21:46, didier2020  a écrit :
> Le vendredi 10 février 2012 à 20:13 +0100, Claude a écrit :
>> bonjour
>>
>> je vient de constater une chose étrange
>>
>> lorque j'attribue la balise "mooring=yes" sur une ligne, JOSM se bloque
>> et ne répond plus: la  fenêtre devient toute blanche et le curseur a la
>> forme d'une croix.
>> Je l'ai constaté sur 2 machine différente toutes les 2 sous linux Debian
>> 6 avec la version 4878
>> quelqu'un peut-il confirmer?
>>
> negatif pour moi - debian 6 & 4878
>
> didier
>
>> merci
>> cordialement
>> claude
>>
>> ___
>> 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] mooring=yes plante JOSM

[Claude]

Le 10/02/2012 22:25, Philippe Verdy a écrit :

Sans doute une anomalie dans les données de ton fichier OSM en mémoire
(JOSM signale parfois des bogues internes lors de certaines
modifications). Sauve-le sur disque et relance JOSM pour recharger le
fichier proprement...

Peut-être aussi qu'il te faut monter la quantité de mémoire virtuelle
pour la machine Java (paramètre -Xmx sur la ligne de commande, moi j'y
ai mis 8 Go et je suis tranquille, mais mon PC a 32 Go de RAM physique
et un processeur 8 coeurs, ce qui ne pose aucun problème de swap
excessif ou de performance du garbage collector, même avec d'autres
applications lourdes voire plusieurs instances de JOSM en parallèle,
ou un OS virtuel utilisant 2 coeurs).

Mes fichiers OSM thématiques font facilement plus de 1Go avec plus
d'un million de noeuds ; pourtant ça ne prend que quelques secondes à
sauver, et moins d'une minute à charger ou dans les tests du
validateur (même pour le contrôle de superposition des bâtiments, qui
est le test le plus long en raison du nombre élevé de superposition de
traits dans les zones urbaines). Mais je n'ai aucune erreur de la
sorte dans JOSM (hormi un bogue mineur lors de de la sélection dans la
liste de warnings du validateur d'objets déjà supprimés (la
suppression ou la fusion d'objets n'ôte pas leur référence dans la
liste des avertissements du validateur, on peut encore les ajouter à
la sélection courante, et cliquer dessus en tentant de voir ses
propriétés, et JOSM signale une exception interne qui n'a rien de
critique, et qui permet de continuer sans problème).

Le 10 février 2012 21:46, didier2020  a écrit :
   

Le vendredi 10 février 2012 à 20:13 +0100, Claude a écrit :
 

bonjour

je vient de constater une chose étrange

lorque j'attribue la balise "mooring=yes" sur une ligne, JOSM se bloque
et ne répond plus: la  fenêtre devient toute blanche et le curseur a la
forme d'une croix.
Je l'ai constaté sur 2 machine différente toutes les 2 sous linux Debian
6 avec la version 4878
quelqu'un peut-il confirmer?

   

negatif pour moi - debian 6&  4878

didier

 

merci
cordialement
claude

___
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

   

Ca semble marcher à nouveau.

j'ai lancé en ligne de commande juste avec java -jar josm-tested.jar 
plus de plantage mais il est vrai qu'il a aparement écrasé mon fichier 
de config car mes paramètre OAuth ont suaté


j'avais un lanceur qui faisait "java -Xmx1024M -jar 
/home/claude/josm/josm-tested.jar" mon PC est un P4 avec 4Gpo seulement 
de mémoire.
l'autre PC est un Dual Core avec 8 Go j'avais "java -Xmx4096M -jar 
/home/claude/josm/josm-tested.jar".
en fait JOSM se figeait dans d'autres situations. C'est bizarre car j'ai 
fait la mise à jour hier soir et j'ai jamais ce prob avant.

peut-être un hasard

cordialement
Claude





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

Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Etienne Trimaille]

Le 10 février 2012 20:24, Jérôme Cornet  a écrit :

> Le 10 févr. 2012 à 17:44, Etienne Trimaille a écrit :
>
> > Est-ce possible de prendre en compte les building=* en compte ?
>
> Ahem… je dois avouer piteusement en public que je n'avais pas connaissance
> de ces variations sur tag building. Et donc…
> les bâtiments qui sont en building=XX ou XX n'est pas yes sont
> complètement ignorés de la comparaison! (arg)
>


Il n'existe pas que le building=yes ;-)
http://wiki.openstreetmap.org/wiki/Key:building


>
> > Je ne comprends pas toujours le résultats :
> > Avec building=apartements / train_station dans la base OSM, ton outils
> met le bati dans ok.osm.
> > Avec building=supermarket dans OSM, ton outils met le bati dans
> nofusion.osm.
>
> En fait cela ne dépend pas du type de building… (vu que je ne reconnais
> que building=yes). La différence
> que tu as observé est liée probablement à une intersection avec un autre
> polygone qui lui était taggé building=yes.
>
> > Je précise que pour les 2 types apartements et supermarket, les
> bâtiments sont exactements au même endroits entre les 2 fichiers OSM
> (courant.osm et cadastre.osm).Je ne pense pas que cela soit le bon
> résultat, non ? Ils devraient se trouver dans nofusion.osm ?
>
> Euh je ne comprend pas bien cette partie. Dans le cadastre on a uniquement
> du building=yes non?
>

Tout à fait. Il n'y a que des building=yes dans les fichiers issus du
cadastre. Sauf pour les églises qui sont automatiquements building=church !
Tu as déjà répondu à ma question en disant que ton script ne prend que
building=yes.

Je vais revérifier pour la différence que j'ai obtenu entre ok.osm et
fusion.osm.


>
> > Et en théorie, si j'ai bien compris les différents fichiers :
> > fusion.osm, à ne pas importer, car bati déjà présent dans la base
>
> Ben là ça dépend des opinions. Préfères-tu un bâtiment dessiné exactement
> comme dans le cadastre, ou garder
> quelque chose d'approximatif fait à la main, pas forcément au bon niveau
> de détail? (je sais j'en ai fait nombre à la main
> à la grande époque). Si tu souhaites avoir la précision du cadastre, et
> les tags intéressants rentrés sur la version faite
>  à la main, le calque "Fusion" est censé réimporter les tags utilisateur
> sur le bâti cadastre (et sur les points, notamment
> pour les adresses). Après c'est une question d'opinion/de temps et aussi
> que le processus de fusion se passe bien.
>

Dans mon cas, le bati venait déjà d'un import cadastre, donc pas de soucis
de ce cote la.


>
> > conflit.osm, à vérifier manuellement
> > C'est bien çà ?
>
> Oui.
>

Merci pour le rappel des fichiers.
J'avais bien marqué "en théorie" dans ma question ;-) Cela n'empêche pas la
vérif manuelle.


>
> > Pour obtenir les batiments qui ont été supprimés du cadastre, mais
> présent dans OSM ?
>
> Peut-être en inversant les deux fichiers en arguments (cadastre et calque
> osm) et en regardant la sortie .ok.
> Je peux faire une option spéciale sinon si tu m'expliques à quoi ça te
> sert, quel comportement tu veux, etc.
>

J'avais essayé :p
Mais les fichiers OSM ne sont pas compatibles. Ce sont les id qui foirent
la lecture.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] mooring=yes plante JOSM

[Philippe Verdy]

Le 10 février 2012 22:46, Claude  a écrit :
> j'ai lancé en ligne de commande juste avec java -jar josm-tested.jar plus de
> plantage mais il est vrai qu'il a aparement écrasé mon fichier de config car
> mes paramètre OAuth ont suaté

Cela est un signe clair que lors des bloquages, OSM a manqué de
mémoire pour réaliser une opération, et ce manque de mémoire a
provoqué une corruption des données qu'il a voulu enregistrer dans tes
paramètres.

J'ai déjà remarqué que même avec de petits fichiers OSM, 1Go de RAM
allouée pour la machine Java c'est un peu juste pour JOSM: le garbage
collector de Java n'arrive plus à gérer les "générations" d'objets
alloués efficacement, du coup la fragmentation augmente très
sensiblement dans l'ancienne génération, et il finit par manquer de
place pour la nouvelle génération.

Le garbage collector de Java passe alors son temps à recompacter
l'ancienne génération, ce compactage étant beaucoup plus couteux en
ressource CPU et en temps, et opérations de copies en mémoire, que le
compactage de la nouvelle génération (qui n'est qu'une file cyclique).
C'est encore plus vrai sur un système avec un seul processeur car le
compacteur de l'ancienne génération monopolise le seul thread actif et
bloque tout autre thread dans le processus Java (tout en devant aussi
céder tu temps au reste de l'OS et aux autres applis du bureaux et
services en cours).

Le poblème ici avec JOSM c'est la taille assez importante de
"l'ancienne génération", qui contient en particulier le code Java
compilé en cours d'exécution (JOSM est une appli volumineuse en code,
avec tous ses plugins), et ses caches de données et aussi les données
de rendu du calque précalculé à l'écran. La nouvelle génération en
revanche contient tous les objets alloués en permanence pour la
génération des objets XML ou leur décodage et leur affichage, ou leur
activation coloré à l'écran et dans les fenêtres de propriétés, ou
calculés temporairement en très grand nombre par les fonctions de
recherche et de validation. Un fichier OSM chargé sera alloué dans des
objets au début dans la nouvelle génération, mais rapidement
transférés vers l'ancienne génération (d'autant plus vite que la
taille de machine virtuelle -Xmx est petite)

JOSM pour moi n'est plus recommandé avec moins de -Xmx1500 car ses
gestionnaires d'exception en cas de débordement mémoire ne ratrapent
pas toujours bien la situation notamment dans les données qu'il
sauvegarde sur fichier ou envoie au serveur.

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

Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Jérôme Cornet]

Le 10 févr. 2012 à 20:47, Philippe Verdy a écrit :

> Juste une idée, comme ça:
> 
> Il n'y a pas moyen avec votre outil de marquer les bâtiments importés
> avec un numéro de parcelle (par exemple le plus petit numéro de
> parcelle où il est construit), ou le numéro de rue dans une
> agglomération, et insérer cette référence dans un tag de suivi, afin
> de savoir qu'il a été rapproché avec le cadastre, et ensuite permettra
> de savoir ceux qui ont été modifiés ?
> 
> Cela soulagerait ensuite bien des comparaisons géomatiques hasardeuses
> et faciliterait aussi les synchronisations lors d'imports de nouveaux
> bâtis, tout comme de permettre aussi d'avoir un état statistique du
> bâti manquant ou à corriger/fusionner.
> 
> On insère bien des références Insee et NUTS pour les relations de
> communes, départements, arrondissements, régions, ou des codes SIREN
> pour les relations des intercommunalités...
> 
> Ce qui permet justement des rapprochements de fichiers plus faciles et
> moins d'erreurs (par exemple sur les graphies ou toponymes alternatifs
> ou ambigus) dès lors que les géolocalisations ne correspondent pas
> exactement (surtout quand une source utilise une précision différente
> dans les géométries de contours ou les centroïdes renseignés, ou parce
> que cette géométrie a évolué au cours du temps et que les données
> prennent en compte des dates de mise à jour différentes de cette
> géométrie).

Euh… 100% d'accord avec l'idée de référencement, après d'aucuns vont
retorquer que ça risque de bien surcharger la base. Et en terme de réalisation
je ne vois pas bien où je vais récupérer l'information (à ma connaissance
l'import-bati n'arrive pas à extraire cette information). Donc à discuter 
ensemble,
si vous trouvez comment concrétiser :-)

Jérôme


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

Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Jérôme Cornet]

Le 10 févr. 2012 à 21:59, Philippe Verdy a écrit :

> [..]
> 
> Par conséquent, les zones rurales ou périurbaines qui sont sorties des
> zones constructibles des anciens POS ou des actuels PLU ne sont plus
> contrôlées du tout, tant qu'il n'y a pas de vente (saisies
> judiciaires, séparation de biens lors de divorces, partage dans une
> succession), et entâchent le cadastre d'erreurs et d'omissions parfois
> grossières.

Que le cadastre, comme toutes les autres sources, est à prendre avec des 
pincettes
(surtout en campagne), je ne peux qu'être d'accord (surtout que je fais du 
cadastre
raster non-géoréférencé, donc bon… ça me paraît évident). 

Après il ne faut pas tout mélanger: en centre-ville vectorisé c'est plutôt bon, 
et ça restera toujours
meilleur qu'un truc décalqué à la main. Et oui, il y a des bâtiments non 
présents, et vice-versa:
à Grenoble, vers la Bastille nous avons des magnifiques ruines référencées 
cadastre. Il faut
donc mettre son grain de sel et c'est bien normal.

> Alors une bonne question se pose :
> 
> Est-ce que OSM doit jouer un rôle d'auxiliaire de contrôle fiscal en
> corrigeant gratuitement ce qui est ou n'est pas dans leur cadastre (ce
> qui pourrait être un bénéfice inavoué motivant les collectivités à
> ouvrir leur données SIG et à collaborer avec OSM) ?

Euf… théorie du complot? Je pense que "nous" ne sommes pas assez rigoureux 
(d'un point de vue fiscal!) ni
n'avons un but qui puisse convenir à ce genre d'utilisation. Ça va servir à 
quoi à l'administration
fiscale qu'on rajoute des ruines en building=yes? Et puis je les vois bien 
justifier auprès 
des contribuables que si si il faut payer parce qu'on les a vu sur OSM… À 
l'extrême limite j'ai vu
des piscines sur Bing/CRAIG/etc. non signalées sur le cadastre… mais peut-être 
parce qu'elle
étaient hors-sol, etc, etc. 
Cette hypothèse de bénéfice non avoué me paraît peu plausible.

Jérôme

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

Re: [OSM-talk-fr] Nouvel outil "diff" cadastre (was Re: COD : Cadastre Osm Diff)

[Philippe Verdy]

Le 11 février 2012 00:33, Jérôme Cornet  a écrit :
>> Est-ce que OSM doit jouer un rôle d'auxiliaire de contrôle fiscal en
>> corrigeant gratuitement ce qui est ou n'est pas dans leur cadastre (ce
>> qui pourrait être un bénéfice inavoué motivant les collectivités à
>> ouvrir leur données SIG et à collaborer avec OSM) ?
>
> Euf… théorie du complot? Je pense que "nous" ne sommes pas assez rigoureux 
> (d'un point de vue fiscal!) ni
> n'avons un but qui puisse convenir à ce genre d'utilisation. Ça va servir à 
> quoi à l'administration
> fiscale qu'on rajoute des ruines en building=yes? Et puis je les vois bien 
> justifier auprès
> des contribuables que si si il faut payer parce qu'on les a vu sur OSM… À 
> l'extrême limite j'ai vu
> des piscines sur Bing/CRAIG/etc. non signalées sur le cadastre… mais 
> peut-être parce qu'elle
> étaient hors-sol, etc, etc.
> Cette hypothèse de bénéfice non avoué me paraît peu plausible.

Vue le peu de moyens de collectivités pour faire leurs contrôles, et
le rapport coût/bénéfice des quelques contrôles aléatoires qu'elles
peuvent faire, elles peuvent être tentées de chercher des pistes de
comparaison sur autre chose que le seul hasard, surtout dans le
domaine du bâti épars qu'elles maitrisent très mal.

Evidemment elles maîtrisent plutôt bien leur parcellaire, base de la
taxe foncière, mais un domaine qui ne nous intéresse pas. En revanche
concernant le bâti lui-même, c'est tout autre chose: elles savent qui
est propriétaire d'une parcelle, mais finalement très peu ce qui est
implanté dessus.

Et là je ne parle pas des ruines, mais bien de bâtiments pas si vieux
que ça, parfaitement habitables (je peux donner des exemples, ne
serait-ce que dans la maison de mon enfance qui ne figure nulle part
dans le cadastre alors qu'elle a été construite en bonne et due forme
avec permis de construire. Elle est même assez remarquable dans la
commune par sa forme, sa construction toute en granit de taille (comme
aussi le muret de séparation avec la voirie, qui n'est pas non plus
sur le cadastre alors même que la commune s'y est confrontée lors d'un
élargissement de route pour le passage de ligne de bus, et a été
contrainte de racheter moins que prévu et de boucher un fossé en
posant une canalisation enterrée).

Le cadastre ne mentionne pas non plus le puits creusé lui aussi avec
un permis (et déclaré à l'agence de bassin). Si on se fit au cadastre,
il n'y a qu'un petit rectangle standard et mal orienté, aucun mur,
aucun puits, aucune séparation sur une grande parcelle qui a été
pourtant divisée pour n'en paysager qu'une partie et mettre le reste
en fermage. Depuis cette maison a été revendue avec seulement la
division de parcelle (oubliée là encore sur le cadastre alors qu'il y
a maintenant deux propriétaires différents...)

Si je regarde le cadastre chez les voisins immédiats (dans les 500
mètres), c'est pareil, il manque des bâtiments qui sont là depuis
plusieurs décennies, des puits, des installations agricoles, un bois,
deux rivières, et même des chemins ancestraux (dont un chemin
intercommunal : les parcelles existent mais rien n'indique la présence
de ce chemin...)

Mais c'est sur les constructions que c'est le pire : aucun bâtiment
n'est à l'échelle, ce ne sont que des rectangles mal orientés, pas à
l'échelle, posés approximativement sur les parcelles (et parfois même
pas les bonnes quand il s'agit d'une même propriété...

Rien n'a été mis à jour depuis longtemps car c'est dans un secteur
désormais hors zone constructible (une des zones vertes que protègent
la communauté d'agglomération qui ne veut pas un développement urbain
continu et qui tente de densifier le bâti sur des pôles centres
multiples sur chaque bourg des communes existantes, en évitant la
dispersion typique du bâti dans les zones dites "rurbaines" et qui a
eu lieu dans les années 1970 un peu partout en France autour de toutes
les métropoles régionales pour créer de larges banlieue périurbaines
qui ne sont ni de la vraie ville, ni plus de la campagne, et qui
coûtent maintenant trop cher aux collectivités, en terme d'aménagement
de services publics ou dans les plans de déplacements urbains pour la
gestion des voiries, comme en terme environnemental pour la protection
des ressources en eau et la collecte des eaux usées par exemple).

Et pourtant le cadastre a été remis à jour et vectorisé sur le GIS
communautaire, et l'agglomération dispose aussi d'une imagerie
aérienne complète et de très bonne qualité (bien meilleure que celle
fournie par Bing, avec des mises à jour au moins annuelles et une
précision permettant de voir des détails voisins de 5-10 centimètres
par pixel  : on identifie parfaitement les modèles de véhicules garés,
si une personne présente est un adulte ou pas, on voit le moindre
poteau, la plus petite boîte à lettre, les bordures de trottoirs, on
distingue très bien une construction en dur d'une construction légère
comme les cabanes de jardin et mobile-homes, on peut compter les
marches des escaliers,