Re: [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)

2012-10-17 Par sujet Jo
(Désolé d'envoyer ce mail en anglais sur la liste talk-fr, mais c'est
plutôt dirigé vers talk en général)

I have been following talk-fr myself and my opinion on the 'efforts' of
pnorman is that he is trying very hard to chase away well meaning
contributors in France. The French cadastre is just one of many sources of
data (I wish we'd have access to ours in Belgium, as the contributors in
Holland and France do).

The French are integrating the data of the cadastre, their surveys, their
local knowledge and Bing aerial images to improve Openstreetmap.org as a
whole. They are not doing a bulk import that needs to be sorted out later
on.

If it were 1 person doing such an import department by department, then it
would make a lot of sense for this person to create that separate account,
but that's not how they chose to proceed. So the requirement for using a
separate account doesn't hold water.

The local community's opinion should be more important in this matter, than
the opinion of one person in the UK and the DWG should wield its power to
block actual acts of vandalism, instead of annoying good contributors.

The French community is trying for quite a while already to talk to the
DWG, which has some results, but rather too slowly. As long as no
resolution has been reached they seem to expect the French contributors to
change their behaviour (and create a separate account when making use of
the cadastre), where it would be more logical that they stop their actions
of scaring away contributors with mails in a language those contributors
can't be expected to understand.

So pnorman: For starters, write your emails in French when adressing people
in France, if you feel you have to write them. As it is now, they get an
email out of the blue making them wonder what they did wrong, whereas they
did everything as the local community expects them to do it.

You are creating a lot of ill will, which is kind of odd in a project where
we depend on the contributions of all people who want to spend their time
on it.

Polyglot

2012/10/18 Eric Marsden 

> Hello,
>
> It is clear from discussions on the talk-fr mailing list that DWG
> members (in particular, Paul Norman) are continuing to hassle French
> contributors who are integrating cadastre data in a manner which is
> perfectly compatible with the local community guidelines for this source
> of data. These messages are being sent in English (perhaps DWG members
> need to be reminded -- again -- that some people are not able to
> understand English) and are aggressive in nature. This is despite
> sustained efforts over several months by members of the French
> community, who have volunteered to act as local intermediaries in this
> important and sensitive process of communicating with and helping
> contributors in a constructive manner.
>
> I am having trouble understanding how a group of people who presumably
> wish to make a positive contribution to this fantastic community-based
> project can be so blind to such basic principles of communication,
> community building, and simple respect for fellow human beings. My
> impression is that the majority of the anti-social behaviour is coming
> from a single person, and that other group members are unwilling to take
> a stand on this issue.
>
> Please take this opportunity to reflect on a proposed policy which you
> could decide upon as a group, propose for comment from OSM contributors
> (for example via the talk@ mailing list), document on the OSMF web site,
> and ensure that all DWG members follow the policy (no loose canons on
> deck -- the current situation is killing contributors).
>
> --
> Eric Marsden
>
> ___
> 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] [RECH] Un contributeur pédagogue sur Belfort ?

2012-10-17 Par sujet jean-francois.nifenecker
(réponse très rapide car connectivité réduite aujourd'hui)

Bonjour Mathieu,
je serai sur Belfort à Noël (du 24 au 30/12).
Si je peux être utile, ce sera avec plaisir.

Amicalement,
--
Jean-Francois Nifenecker, Bordeaux
(né à Héricourt et grandi à BF)

> Message du 18/10/12 08:16
> De : o...@ffmc90.org
> A : talk-fr@openstreetmap.org
> Copie à :
> Objet : [OSM-talk-fr] [RECH] Un contributeur pédagogue sur Belfort ?
>
> Salut,
>
> Nous sommes une fédération de motards dans le Territoire de Belfort.
>
> Nous avons été particulièrement bien accueillis par M. Sibert sur une
> problématique de signalement de radar fixe/radar de feux.
>
> (Précisons que nous ne prônons pas la possibilité de s'affranchir des
> règles du code de la route, de griller les feux rouges, notre
> opposition à ce système est plus fondée.
> http://www.ffmc.asso.fr/spip.php?rubrique26 )
>
> Nous avons des besoins propres de carto, pour l'instant bêtement
> réalisés avec Gmap.
>
> Baignés par l'économie sociale, le logiciel libre, OSM nous
> interpelle, mais nous nous trouvons devant un mur, sûrement fait
> d'interrogations toutes simples pour un amateur.
>
> Est-ce qu'un contributeur qui réside dans notre secteur (Territoire de
> Belfort) serait capable de nous faire un fast track/atelier sur OSM.
>
> Nous sommes de purs novices en la matière, mais avons pas mal de
> possibilités de contribution :
>
> - Contrôles automatiques
>
> - Points problématiques d'infrastructure routière
>
> - Recensement de la vidéo-surveillance urbaine
>
> - Itinéraires sympathiques pour des balades
>
> - Stations essences sans agro-carburants
>
> - ...
>
> Une petite heure vaudrait bien mieux que tous les tutoriels, non ?
>
> Vieux Motard que Jamais :)
>
> En vous remerciant,
>
> Ciao'
> --
> Mathieu
>
>
>
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
> 

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


[OSM-talk-fr] [RECH] Un contributeur pédagogue sur Belfort ?

2012-10-17 Par sujet osm
Salut,

Nous sommes une fédération de motards dans le Territoire de Belfort.

Nous avons été particulièrement bien accueillis par M. Sibert sur une
problématique de signalement de radar fixe/radar de feux.

(Précisons que nous ne prônons pas la possibilité de s'affranchir des
règles du code de la route, de griller les feux rouges, notre
opposition à ce système est plus fondée.
http://www.ffmc.asso.fr/spip.php?rubrique26 )

Nous avons des besoins propres de carto, pour l'instant bêtement
réalisés avec Gmap.

Baignés par l'économie sociale, le logiciel libre, OSM nous
interpelle, mais nous nous trouvons devant un mur, sûrement fait
d'interrogations toutes simples pour un amateur.

Est-ce qu'un contributeur qui réside dans notre secteur (Territoire de
Belfort) serait capable de nous faire un fast track/atelier sur OSM.

Nous sommes de purs novices en la matière, mais avons pas mal de
possibilités de contribution :

- Contrôles automatiques

- Points problématiques d'infrastructure routière

- Recensement de la vidéo-surveillance urbaine

- Itinéraires sympathiques pour des balades

- Stations essences sans agro-carburants

- ...

Une petite heure vaudrait bien mieux que tous les tutoriels, non ?

Vieux Motard que Jamais :)

En vous remerciant,

Ciao'
-- 
Mathieu







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


Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Philippe Verdy
Note que dans les demandes effectuées dans ce mail, je n'en retiens
qu'une partie :

* recenser dans le catalogue des imports les sources de ces données.
Là seulement le DWG est dans son rôle.
* consulter la communauté sur les opérations à réaliser (surtout pour
se concerter, quand l'intégration nécessitera une fusion qui demande
des suppressions partielles d'autres données, ou pour éviter de
réaliser le même travail plusieurs fois, ce qui gâcherait trop de
temps de travail pour certains qui devront ensuite passer un temps
considérable à gérer des "conflits d'édition").
* discuter avec elle des détails techniques (quand il pourrait y avoir
des ambiguïtés ou erreurs nées de ces intégrations de données, pour
différents outils d'édition, d'analyse ou de rendu)
* documenter les pratiques, particulièrement s'il s'agit de nouveaux
types de données, pour faciliter leur réutilisation.
* prévoir un plan de réparation en cas d'import et d'intégration qui a
partiellement échoué en cours de route.

Rien de tout cela ne nécessite un autre compte. Bien au contraire cela
complique même la coopération avec la communauté qui ne sait plus à
qui s'adresser et qui ne sait plus quel compte utiliser dans de trop
nombreux cas (sans compter que cela complique aussi l'dentification
des sources de données utilisées par les uns et les autres).

P.Norman a bien tord de menacer de bloquer ceux qui travaillent
correctement et en plein accord avec les communautés les mieux
concernées, en effectuant patiemment aussi de longues heures de
travail (d'intégration plus que d'import qui ne se fait réellement que
vers des outils d'édition et d'analyse hors d'OSM et bien avant
l'envoi des données intégrées).

Son obsession répétée pour les comptes dédiés (particulièrement contre
ceux qui ont le plus travaillé) ne rime à rien, cela n'a jamais été
dans sa mission, cela n'a jamais été décidé par la communauté, c'est
un abus d'autorité qui va faire détester le projet par ceux qui ont le
plus travaillé pour le faire progresser dans le bon sens. A force, il
ne va plus rester que des utilsiateurs qui viendront une fois de temps
en temps mettre quelques données bourrées d'erreurs et qu'on ne
reverra pas ensuite (à charge alors pour la communauté restante,
privée de ceux qui maîtrisent le mieux les sujets, de nettoyer).

L'obsession de P.Norman ne peut aboutir alors qu'à une dégradation
rapide de la qualité des données (alors qu'elles ne font que
s'améliorer jusqu'à présent) car il n'y aura plus personne à les
réviser et les modifications iront dans tous les sens. Elle rendra le
projet encore plus exposé au vandalisme (puisque les bons
contributeurs vraiment actifs ne seront plus là pour les détecter, et
puisque les vandales ne tiendront de toute façon jamais compte des
messages de P.Norman et feront ce que bon leur semble d'autant plus
facilement qu'ils pourront utiliser pléthore de comptes pour leurs
opérations de saccage : parmi les vandales on retrouvera les
omniprésents émetteurs de spams et autres abuseurs du web, qui ont
avec eux des moyens techniques et financiers énormes, la plupart du
temps détournés de façon illégale : ils ne sont plus à ça prêt et sans
arrêt de toute façon dissimulent leurs identités réelles et ne
cherchent jamais à collaborer avec qui que ce soit)

Le 18 octobre 2012 02:33, Cavok  a écrit :
>> pnorman vous a envoyé un message depuis OpenStreetMap avec le sujet
>> Dedicated import account :
>> These imports were not done from a dedicated account.
>>
>> I would suggest that the dedicated account
>>
>> have a link to your main account for contact purposes
>>
>> and
>>
>> have a listing of any imports you have done on it with links to the
>> entries in the import catalogue
>>
>> As a general reminder, the other import guidelines can be found on the
>> wiki. These include
>>
>> appropriate documentation
>>
>> consultation with the local community and the imports@ mailing list
>>
>> having a plan to fix an mistakes in case of a broken upload
>>
>> other technical requirements
>>
>> Ignoring this and continuing to import from your main account may lead to
>> a block.
>>
>> To contact me you can send a message or email the data working group
>>
>> Paul Norman
>> for the Data Working Group

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


Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Cavok
C'est la soirée, moi aussi je viens de recevoir ce petit message fort
agréable, mais à voir seulement, c'est dommage, je ne lis pas l'anglais ;-)
Il y en a qui n'ont vraiment que ça à faire.
Et quand je pense qu'il doit y avoir des contributeurs recevant ce petit
mot doux, sans savoir ce qui leur arrive. Ils doivent ne plus trop
comprendre, le but d'OSM, on trace des cartes, alors on nous dit que si on
continu, on va être bloqué. Alors, c'est quoi le but. Ah, oui, j'avais pas
trop compris, il faut juste regarder et pas toucher.

Toutes les personnes qui importent les bâtiments du cadastre, il doit y en
avoir un bon nombre quand même, ne viennent pas forcément ici et sur le 2
Forums Français, je n'ai même pas trouvé quelqu'un venir s'en interroger
d'une lettre "pnorman".

Au fait cette alerte de porman, c'est vrai qu'on la toujours associé aux
bati du cadastre (les eaux aussi avant quelles ne soient plus disponibles),
mais si on va dans sont sens, peut être aussi pour les noms de rue relevés
sur le cadastre, les numéro des habitations, le traçage des voies, il
faudra tout faire avec ce compte dédiée et sans oublier de documenter tout
ce que l'on fait sur la page wiki de ce compte. Je pense même que lorsqu'on
utilise Bing, il faudrait aussi utiliser ce compte dédié.
Mais alors une question, à quoi sert le compte principal ... j'ai trouvé, à
faire les corrections biensur, sans oublier l'utilisation des données GPS.

Données GPS, tiens j'ai dit donnée, mais si pendant toutes mes grandes
vacances, j’emmagasine dans ce beau jouet, plein de petits points et qu'en
rentrant à la maison je déverse ces innombrables tracés vers OSM, quel
compte utilisé, la, c'est un dilemme. Ça serait pas quand même bien un
import en masse aussi.

En fait tout cela à cause des Import en Masse. Il faut faire comme au
boulot alors. Il ne faut surtout pas trop en faire d'un coup sinon on est
mal vu.

Pour tenir, en faire le minimum, ça sera la nouvelle règle d'OSM.

Bonne nuit.

Voici copie du "pnorman":


2012/10/17 pnorman 

> Bonjour cavokld,
>
> pnorman  vous a envoyé un
> message depuis OpenStreetMap avec le sujet Dedicated import account :
> ==
>
> Hello
>
> I noticed you conducting an import with
>
>- http://www.openstreetmap.org/browse/changeset/13531828
>
> The import 
> guidelinesrequire that 
> imports be done from a dedicated account, after consultation
> with the local community and be documented on the wiki.
>
> These imports were not done from a dedicated account.
>
> I would suggest that the dedicated account
>
>- have a link to your main account for contact purposes
>
> and
>
>- have a listing of any imports you have done on it with links to the
>entries in the import 
> catalogue
>
> As a general reminder, the other import guidelines can be found on the
> wiki . These include
>
>-
>
>appropriate documentation
>-
>
>consultation with the local community and the 
> imports@mailing list
>-
>
>having a plan to fix an mistakes in case of a broken upload
>-
>
>other technical requirements
>
> Ignoring this and continuing to import from your main account may lead to
> a block.
>
> To contact me you can send a 
> messageor email the data
> working group 
>
> Paul Norman 
> for the Data Working 
> Group
> ==
>
> Vous pouvez également lire le message sur
> http://www.openstreetmap.org/message/read/308096 et vous pouvez répondre
> sur http://www.openstreetmap.org/message/reply/308096
>

___
> 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] ou est la licence?

2012-10-17 Par sujet Philippe Verdy
C'est d'autant plus gênant sur ce site dont le lien "Mentions légales"
visible en bas de toutes ses pages, se permet de s'attribuer la
paternité complète de son contenu et de le protéger de façon exclusive
contre la "contrefaçon" dans sa totalité comme dans chacune de ses
parties. Et ne mentionne même pas qu'une partie des données est
détenue par des ayant-droits tiers (cette page n'en cite aucun).

Cependant même s'il invoque la loi française, il ne peut se prévaloir
malgré tout des droits des tiers que la loi protège malgré tout (et
toute stipulation contraire dans ses "mentions légales" est clairement
invalide et illégale).

Et ce n'est pas parce que le site a produit des images dérivées (par
exemple pour dimensionner et réencoder ces images afin qu'elles
rentrent dans la maquette de mise en page du site, ou pour les
habiller avec des coins arrondis) que cela lui permet de s'en
attribuer la paternité. La licence CC-BY-SA s'applique quand même quoi
qu'en dise ses "mentions légales" !

Bref n'importe qui doit être autorisé à utiliser n'importe quelle
méthode (même semi-automatique) pour copier ces images publiées, y
compris dans leur forme modifiée par le site, et de les republier
ailleurs (même en y apportant d'autres modifications) en n'oubliant
pas cette fois de mentionner la licence CC-BY-SA et l'attribution de
copyright de la licence d'origine, même si le site prétend l'interdire
sous le prétexte de "contrefaçon" en droit français (cette
interdiction dans les "mentions légales" est clairement invalide, et
le site ne devrait tromper personne à ce sujet).

D'ailleurs cette page "Mentions légales" me parait très abusive étant
donné qu'elle ne stipule aucun droit pour les tiers dont il utilise
les données (il ne leur concède *que* le droit des marques dans sa
section "exclusion de responsabilité", mais rien du tout dans la
section "Copyright").

Le 18 octobre 2012 01:52, Philippe Verdy  a écrit :
> Renvoyer (en cliquant la carte) sur Google Maps n'est *pas* invalide
> en terme de licence.
>
> La seule chose à reprocher c'est plutôt celle concernant l'image
> statique qui se contente d'afficher le petit logo intégré dans le mot
> "OpenStreetMap" affiché dans le coin inférieur droit, ce qui est
> insuffisant (mais pas dramatique, car "OpenStreetMap" commence à être
> bien connu en tant que tel).
>
> Le problème est ici que l'image (en licence CC-BY-SA) nécessite une
> mention explicite de la licence (par exemple avec un lien vers
> celle-ci), et un copyright explicite pour l'attribution correcte des
> droits d'auteurs et droits dérivés, puisque cette image publiée
> devrait être réutilisable telle quelle (ou modifiée, par exemple
> tronquée ou habillée) par d'autres que le site lui-même et dans des
> conditions accessibles aux réutilisateurs.
>
> Le 17 octobre 2012 22:44, Claude  a écrit :
>> Bonjour
>>
>> je suis tombé la-dessus
>>
>> http://www.gralon.net/plan-ville/plan-briare-17516.htm
>>
>> une carte openstreetmap qui renvoie sur une carte Google

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


Re: [OSM-talk-fr] ou est la licence?

2012-10-17 Par sujet Christian Quest
J'ai laissé un message sur la page contact du site à ce sujet.


Le 18 octobre 2012 01:52, Philippe Verdy  a écrit :
> Renvoyer (en cliquant la carte) sur Google Maps n'est *pas* invalide
> en terme de licence.
>
> La seule chose à reprocher c'est plutôt celle concernant l'image
> statique qui se contente d'afficher le petit logo intégré dans le mot
> "OpenStreetMap" affiché dans le coin inférieur droit, ce qui est
> insuffisant (mais pas dramatique, car "OpenStreetMap" commence à être
> bien connu en tant que tel).
>
> Le problème est ici que l'image (en licence CC-BY-SA) nécessite une
> mention explicite de la licence (par exemple avec un lien vers
> celle-ci), et un copyright explicite pour l'attribution correcte des
> droits d'auteurs et droits dérivés, puisque cette image publiée
> devrait être réutilisable telle quelle (ou modifiée, par exemple
> tronquée ou habillée) par d'autres que le site lui-même et dans des
> conditions accessibles aux réutilisateurs.
>
> Le 17 octobre 2012 22:44, Claude  a écrit :
>> Bonjour
>>
>> je suis tombé la-dessus
>>
>> http://www.gralon.net/plan-ville/plan-briare-17516.htm
>>
>> une carte openstreetmap qui renvoie sur une carte Google
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
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] Continued aggression against French contributors (cadastre integration)

2012-10-17 Par sujet Eric Marsden
Hello,

It is clear from discussions on the talk-fr mailing list that DWG
members (in particular, Paul Norman) are continuing to hassle French
contributors who are integrating cadastre data in a manner which is
perfectly compatible with the local community guidelines for this source
of data. These messages are being sent in English (perhaps DWG members
need to be reminded -- again -- that some people are not able to
understand English) and are aggressive in nature. This is despite
sustained efforts over several months by members of the French
community, who have volunteered to act as local intermediaries in this
important and sensitive process of communicating with and helping
contributors in a constructive manner.

I am having trouble understanding how a group of people who presumably
wish to make a positive contribution to this fantastic community-based
project can be so blind to such basic principles of communication,
community building, and simple respect for fellow human beings. My
impression is that the majority of the anti-social behaviour is coming
from a single person, and that other group members are unwilling to take
a stand on this issue.

Please take this opportunity to reflect on a proposed policy which you
could decide upon as a group, propose for comment from OSM contributors
(for example via the talk@ mailing list), document on the OSMF web site,
and ensure that all DWG members follow the policy (no loose canons on
deck -- the current situation is killing contributors).

-- 
Eric Marsden

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


Re: [OSM-talk-fr] ou est la licence?

2012-10-17 Par sujet Philippe Verdy
Renvoyer (en cliquant la carte) sur Google Maps n'est *pas* invalide
en terme de licence.

La seule chose à reprocher c'est plutôt celle concernant l'image
statique qui se contente d'afficher le petit logo intégré dans le mot
"OpenStreetMap" affiché dans le coin inférieur droit, ce qui est
insuffisant (mais pas dramatique, car "OpenStreetMap" commence à être
bien connu en tant que tel).

Le problème est ici que l'image (en licence CC-BY-SA) nécessite une
mention explicite de la licence (par exemple avec un lien vers
celle-ci), et un copyright explicite pour l'attribution correcte des
droits d'auteurs et droits dérivés, puisque cette image publiée
devrait être réutilisable telle quelle (ou modifiée, par exemple
tronquée ou habillée) par d'autres que le site lui-même et dans des
conditions accessibles aux réutilisateurs.

Le 17 octobre 2012 22:44, Claude  a écrit :
> Bonjour
>
> je suis tombé la-dessus
>
> http://www.gralon.net/plan-ville/plan-briare-17516.htm
>
> une carte openstreetmap qui renvoie sur une carte Google

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


Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN

2012-10-17 Par sujet Philippe Verdy
Encore un autre (trop) mauvais algo d'orthorectification par
triangulation place simple (en fait sur un "rectangle" mais qui n'est
en fait que la juxtaposition de deux facettes triangulaires planes),
qui ignore les questions relatives à l'altitude (puisqu'elle n'est
même pas renseignée dans les données qu'il utilise pour le
géoréférencement).

De quoi expliquer pourtant largement les erreurs de positionnement
qu'il indique (jusqu'à 10 mètres...) qu'il ne s'explique pas, mais qui
pourtant s'expliquent très facilement.

Même en n'utilisant que 4 points de référence, on peut faire bien
mieux qu'avec la triangulation plane (avec moins d'aberrations sur les
distances et les angles), mais on doit travailler sur **plus de
dimensions**.

Le 17 octobre 2012 22:53, Jean-Claude Repetto  a écrit :
> There is a good article about ortho in Russian
> (http://gis-lab.info/qa/orbview3-ortho-gdal.html). You can google
> translate it. Also there is a translation
> (http://wiki.gis-lab.info/w/OrbView-3_Orthorectification) but not finished.

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


Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Eric Marsden
> "pv" == Philippe Verdy  writes:

  pv> On en revient donc au problème d'origine : faire respecter, par le DWG
  pv> et ses membres, les limites de sa mission concédée par la communauté,
  pv> pour qu'il n'abuse pas des privilèges accordés nécessaires à cette
  pv> mission.

  Absolument d'accord avec Philippe Verdy !

  Le DWG a eu largement le temps de se concerter avec la communauté
  française concernant les questions d'intégration du cadastre (ces gens
  semblent avoir beaucoup de temps disponible pour surveiller tous les
  changesets dans OSM, mais peu pour progresser sur des questions de
  gouvernance ...). Les personnes qui continuent à envoyer des messages
  d'harcelement, en anglais, aux membres de la communauté française,
  alors que les contributions en question sont clairement positives pour
  le projet et en accord avec les recommandations de notre communauté,
  nécessitent visiblement une aide supplémentaire pour comprendre ce que
  signifique le mot «communautaire». Je vais écrire un nouveau message
  au DWG.

-- 
Eric Marsden


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


Re: [OSM-talk-fr] Orthorectification (était: Rendez vous avec la Direction de l'IGN)

2012-10-17 Par sujet Philippe Verdy
Faites attention en calant les images sur les points de référence
géodésiques ! le choix de ces points n'est pas sans conséquence,
surtout quand ceux-ci sont placés très en hauteur (regardez l'attribut
"ele=*) par exemple au sommet des clochers ou des chateaux d'eau,
certes très visibles sur l'imagerie, mais inadéquats pour
l'orthorectification des images, si elle ne sait pas tenir compte de
l'effet de perspective (un effet *non* linéaire sur le plan de la
prise de vue tout seul, surtout quand ce sont des photos haute
résolution prises d'avion qui en fin de compte ne volent pas très
haut, et où l'angle de prise de vue varie considérablement sur la
surface de l'image, tout en ne mentionnant pas dans les métadonnées de
l'image l'altitude de la prise de vue).

Quand les images haute résolution sont prises d'avion (ou d'hélico),
un traitement linéaire simple (par triangulation plane) ne suffit pas,
ce qu'il faut c'est repasser en 3 dimensions plus une tenant compte de
l'angle de prise de vue et des effets produits par l'optique des
appareils (particulièrement pour les prises de vue en grand angle, qui
produisent un effet "œil de poisson" qui se surajoute à l'effet de
perspective). Pour des résultats plus uniformes, il faut :

- au moins 4 points de référence (plus de triangulation) car il y a un
degré de liberté supplémentaire du fait de la perspective toute seule.

- tenir compte l'élévation des points géodésiques choisis par rapport
au seul (ele=*)

- disposer de données altimétriques au niveau du sol afin de convertir
les élévations en altitude (sur le géoïde WGS84)

- faire attention à bien désigner le bon point correspondant sur
l'image à la description de l'élévation du point géodésique identifié.

- faire toutes les orthorectifications d'image alors en travaillant
sur 4 dimensions (coordonnées homogènes, dont le traitement peut alors
être linéaire) et non pas en 2 dimensions (pour lesquelles les
aberrations géométriques s'accentuent très rapidement dès qu'on
s'éloigne du point géodésique, d'autant plus que l'altitude au sol
n'est *jamais* constante.

Malheureusement aucun des systèmes d'orthorectification que j'ai vu ne
tiennent compte réellement de toutes ces contraintes, les images
"orthorectifiées" ne le sont en fait pas tellement (les aberrations
géométriques sont nombreuses, particulièrement pour les prises de vue
en grand angle) !

Et les mêmes images orthorectifiées ne mentionnent pas dans leurs
métadonnées les paramètres utilisés (liste des points de référence
choisis, paramètres de conversion des élévations et de l'altitude,
nombre de dimensions utilisées pour la conversion, et liste des
facettes de découpage polygonales sur lesquels l'orthorectification a
eu lieu dans l'image générée. Ce qui ne facilite pas non plus leur
"ré-orthorectification" en ajoutant des points de référence
supplémentaires, si les images sources des prises de vue utilisées
avant orthorectification ne sont pas disponibles ou pas facilement
associables (ce qui est le cas justement des images Bing, même si leur
résolution brute semble excellente).

Je me demande d'ailleurs où trouver un bon algo d'orthorectification
qui travaille justement en au moins 4 dimensions (3 dimensions plus 1
homogène tenant compte de la hauteur de prise de vue entre le point au
visible centre de l'image et le centre optique de focalisation) et non
par simple triangulation plane, voire plus pour tenir compte de
l'effet « œil de poisson » des prises de vue en grand angle (les
appareils de prise de vue utilisent alors une optique spéciale avec
des foyers optiques multiples, comportant des lentilles ou miroirs qui
ne sont pas seulement plans ou sphériques comme pour les prises de vue
classiques en angle étroit).

En effet, la méthode simple par triangulation plane ne peut réduire
les aberrations géométriques qu'avec un nombre important de triangles,
donc aussi un nombre élevé de points géodésiques de référence. Ce qui
me parait impossible à trouver, les systèmes géodésiques n'en
comportant pas assez, en terme de densité, pour orthorectifier
correctement les images en haute résolution et pour lesquelles on a
déjà bien du mal à trouver seulement 2 ou 3 triangles complets ; mais
jamais sur les bords de l'image qu'on "extrapole" par continuité avec
les paramètres de rectification des triangles centraux, ce qui pose
encore des problèmes pour superposer les images adjascentes  (on le
voit facilement dans l'imagerie Bing, où les prises de vue adjascentes
sont seulement "fondues" ensembles, mais où on voit très nettement des
ruptures de continuité des routes ou bâtiments, le résultat étant que
la précision réelle des positions n'est souvent pas meilleure que 2 ou
3 mètres, alors qu'on voit des détails géométriques de quelques
centimètres !).

Bing ne me parait donc pas utiliser un bon algo (Google non plus
d'ailleurs, dans de nombreux endroits !). Visiblement il travaille par
simple triangulation plane, ce qui n'est pas du tout « à la hauteur »
pour l'intenti

Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Philippe Verdy
Pendant ce temps là je me demande bien pourquoi P.Norman n'a pas déjà
reçu un vrai avertissement de la part des autres membres du DWG. La
cooptation a ses limites, et je pense même que les cooptateurs
pourraient déjà intervenir pour faire cesser le trouble sérieux qu'il
cause à la communauté, un trouble nuisible au projet et à la confiance
de ses contributeurs qui n'ont *jamais* explicitement accepté les
règles qu'invoquent P.Norman en l'assortissant de ses menaces.

Qui y a-t-il d'autre dans le DWG que P.Norman ? On n'a pas moyen de
négocier autre part qu'avec lui seul ? Qu'en pense la Fondation
OpenStreetMap et les responsables légaux du site et propriétaires de
ses installations ?

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


Re: [OSM-talk-fr] DWG, nous et P. Norman

2012-10-17 Par sujet sly (sylvain letuffe)
(flûte désolé, je navigue tellement français anglais que j'ai collé un sujet 
en anglais)

-- 
sly (sylvain letuffe)

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


[OSM-talk-fr] DWG, us and pnorman

2012-10-17 Par sujet sly (sylvain letuffe)
Salut,

Je vous tiens informé que j'ai recontacté P. Norman et qu'il est en train de 
rédiger un email à propos de notre candidature au DWG.
Indiquant que si ça a un peu trainé : "c'est à cause du SOTM US"

Juste pour dire que ça avance (on dirait)
Mais si ça traîne encore, je propose de devenir plus insistant pour obtenir 
soit une date buttoir au "ça bouge" soit obtenir les choses suivantes :


a) d'obtenir plus de confiance et d'autonomie
b) de nous laisser prendre en charge la communication vers les contributeurs 
en france et en français lorsque préférable.
c) Définir, en partie au moins, nos règles pour les imports en masse 
(contenant au moins la non obligation d'utiliser un 2ème compte)
d) Qu'ils cessent de bloquer les contributeurs sur le territoire français en 
nous laissant cette tâche pour les cas qui nous semble nécessaires (dernier 
recours quand la discussion a échoué)
e) Que l'équipe du DWG cesse, au moins le temps de la négociation de bloquer 
des contributeurs

Est-ce que ça vous semble bon ?

A suppposer que la négociation ne puisse arriver à ça (je pense bien sûr à c) 
et d) mais encore plus e) ) , quels sont les points sur lesquels nous 
acceptons de reculer (et sous quelles conditions) et sur lesquels nous devons 
continuer à maintenir nos positions ?

Autre question, dans l'hypothèse ou je ne recevrais pas de réponse d'ici fin 
de semaine (politique de l'autruche) que pensez vous lundi que je demande une 
réponse sur les points a) à e) évoqués. Avec un truc du style "date butoir" 
(j'ose pas utiliser le mot ulti...tum). Tout en sachant qu'un ultitruc, n'a, 
hélas, de sens que si nous adoptons un comportement différent après la date 
demandée.

-- 
sly (sylvain letuffe)

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


Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Philippe Verdy
Je note déjà une évolution dans le message envoyé par P.Norman, qui
prend en compte maintenant l'avis des communautés locales. Déjà un bon
point.

Dommage encore une fois que son message soit encore *seulement* en
anglais, et qu'il n'ait toujours pas trouvé le moyen de préparer une
réponse appropriée en français, justement en concertation avec la
communauté française concernée, alors qu'il voit parfaitement que les
changesets concernés sont pour la France (comme s'il feignait de ne
pas le savoir).

P.Norman doit donc encore faire des progrès dans sa communication, car
il veut encore travailler tout seul et ne parviendra jamais les vrais
moyens de le faire correctement. D'une façon ou d'une autre il faut
qu'il se fasse qu'il n'est pas tout seul et doit agir avec le soutien
de la communauté (et même accepter qu'une partie de son travail puisse
être partagée, surtout dans un domaine ici qui ne concerne pas du tout
les attributions du DWG dont il fait partie).

On en revient donc au problème d'origine : faire respecter, par le DWG
et ses membres, les limites de sa mission concédée par la communauté,
pour qu'il n'abuse pas des privilèges accordés nécessaires à cette
mission.

L'intimidation de bloquage unilatérale envoyée par PNorman est très
malvenue car elle se base sur des éléments qui sortent complètement de
sa mission. C'est un abus manifeste de pouvoir, qui mérite donc qu'on
conteste publiquement et collectivement le mécontentement de la
communauté en cas de bloquage effectué pour les raisons qu'il invoque.
Cet abus d'autorité est particulièrement nuisible au projet OSM et
remet encore une fois en cause sévèrement la confiance qu'ont les
contributeurs dans le projet, au point de les faire abandonner le
projet quand ils faisaient du bon travail utile pour tous. Le jour où
le DQG ne sera plus formé par cooptation mais par des élections
communautaires, je n'hésiterai pas à voter contre lui et le **très**
mauvais service qu'il a rendu à la communauté et au projet : pour moi
P.Norman ne mérite plus du tout sa place et ses privilèges ,du fait
même de son très sérieux manque  de volonté de collaborer avec la
communauté et de son obstination.

2012/10/17 Romain MEHUT :
> Bonsoir,
>
> Un ami Vosgien vient de me transférer le message qu'il a reçu de pnorman.
>
> Il fait des intégrations de bâti dans les Vosges mais il ajoute aussi tout
> ce qui va avec c'est à dire les rues, les POI... Il est garde-forestier et a
> pour but d'utiliser OSM dans le cadre de son travail. Bref, il fait du bon
> "boulot" en tant que contributeur. Il n'est pas au courant des histoires
> dont on a longuement parlé sur la liste.

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


Re: [OSM-talk-fr] OSMTransport France

2012-10-17 Par sujet Guilhem Bonnefille
Le 17 octobre 2012 17:58, rldhont  a écrit :
> Le 17/10/2012 14:05, Guilhem Bonnefille a écrit :
>
>> Le 16 octobre 2012 17:42, Otourly Wiki  a écrit :
>>>
>>> Je sais pas où remonter les erreurs d'OSM transport mais le funiculaire
>>> de
>>> Lyon qui va à Saint-Just s'arrête à l'arrêt Saint-Just. La base et le
>>> rendu
>>> OSM est juste...
>>
>> Interrogation similaire : j'ai remarqué une incomplétude. J'ai voulu
>> corriger dans OSM mais... je trouve moins d'information dans OSM que
>> dans OSM transport. A quoi est-ce dû ? Vous utilisez quelles données ?
>
>
> Les données n'étaient peut-être pas très fraîche...
>
>
>>
>>
>> PS : ce "bug" est en région Toulousaine
>
>
> J'ai mis à jour Toulouse
>

Merci. Les données sont maintenant cohérentes entre elles. Néanmoins,
c'est surprennant car c'est allé dans le sens d'une suppression
d'information. Je vais mener mon enquête pour essayer de comprendre ce
qui a pu se passer.

A ce sujet, si certains ont des suggestions sur comment retrouver la
relation qui était utilisée à l'époque...
A ma connaissance, il n'y a pas de serveur faisant des snapshots
(genre la version de OSM le mois dernier, l'an dernier...)

-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

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


Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Romain MEHUT
Merci de viens de lui répondre en lui expliquant le contexte...

Romain

Le 17 octobre 2012 23:09, Christian Quest  a écrit
:

> La cellule "GA" s'est déjà activée ;)
>
> 2012/10/17 Romain MEHUT :
> > Bonsoir,
> >
> > Un ami Vosgien vient de me transférer le message qu'il a reçu de pnorman.
> >
> > Il fait des intégrations de bâti dans les Vosges mais il ajoute aussi
> tout
> > ce qui va avec c'est à dire les rues, les POI... Il est garde-forestier
> et a
> > pour but d'utiliser OSM dans le cadre de son travail. Bref, il fait du
> bon
> > "boulot" en tant que contributeur. Il n'est pas au courant des histoires
> > dont on a longuement parlé sur la liste.
> >
> > Je lui conseille de mettre les intégrations de bâti en stand-by?
> >
>
> Une petite pause sur le bâti en attendant d'avoir un retour du DWG...
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> 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] Orthorectification (était: Rendez vous avec la Direction de l'IGN)

2012-10-17 Par sujet Eric SIBERT

Les photos sont calées individuellement par les images bing, et une
bonne précision nécessite un grand nombre de points.


Surtout que Bing peut être décalé... Il faudrait un recalage en 
utilisant les nombreuses traces GPS disponibles dans OSM.



Les essais de reconnaissance automatique que j'ai fait (huggin) n'ont
pas été concluants, il n'y a rien qui ressemble plus a un toit qu'un
autre toit, et les problèmes de perspective sont très important (en
limite de photo, la prise de vue est effectuée avec un angle de 45°)


Tu as essayé de pré-découper les images et de ne faire la reconnaissance 
de points communs qu'entre parties sensées être communes?


C'est vraiment mauvais la reconnaissance de points communs? Style moins 
de 50% de réussite?


Il y a des algorithmes justement issus du traitement automatiques 
d'images qui permettent de gérer un grand nombre de points aberrants. Je 
peux essayer de rechercher dans mes archives.


Éric

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


Re: [OSM-talk-fr] Initiation OSM

2012-10-17 Par sujet Marc

Le 16/10/2012 19:04, Dominique Lachgar a écrit :


J'ai trouvé un tutoriel assez bien fait mais j'ai tout de même peur de 
faire des erreurs.
Ca se corrige les erreurs, jette toi à l'eau. osmose t'aidera à les 
repérer sur une carte http://osmose.openstreetmap.fr/map/ ou juste les 
tiennes http://osmose.openstreetmap.fr/text/ (délai de quelques heures 
quand même).

Enfin si tu as un doute, ben tu écris ici et une bonne âme vérfiera.

A+

--

Marc http://www.openstreetmap.org/user/plonk/


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


Re: [OSM-talk-fr] Motorroad en France?

2012-10-17 Par sujet Christian Rogel

Le 17 oct. 2012 à 09:44, Arnaud CORBET a écrit :

> Cette ancienne convention ne me semble pas devoir être modifiée mais amendée, 
> le trunk décrivant la réalité d'une voie physiquement à chaussées séparées, 

Quand je lis ce genre de phrase, mon incompréhension augmente, comme l'idée, a 
priori inacceptable, que la convention "motorroad=yes" serait applicable chez
tous nos voisins et pas en France (page "Motorroad" du wiki anglophone).

Comme je l'ai déjà montré, sur la page "Trunk" en anglais, il n'est nullement 
indiqué que "trunk" est destiné aux 4 voies sans connexions à niveau.
Il est clairement indiqué que motorroad=yes ou no est une combinaison possible, 
mais, non automatique, avec "trunk".

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk

Cela veut bien dire que "trunk" est une hiérarchisation du réseau et non une 
description, celle-ci étant éventuellement prise en charge par "motorroad". 

Ce dernier tag, dans le réseau espagnol, est clairement affecté aux sections à 
quatre voies qui se trouveraient sur une voie interrégionale ("carretera 
nacional" 
(rouge) ou  "carrtera autonomica de 1er nivel"  (orange)


Les "autopistas" (nos autoroutes) et les "autovías" (voies express) sont 
concernées uniquement par le tag "highway=motorway".

Au moins, les Ibéres ont compris l'essence du wiki anglophone.

La description des "autopistas" (autoroutes) montre que l'on trouve les mêmes 
différences d'avec nos voies express (courbes plus allongées, 
bretelle d'accélération ou de décélération plus longues et plus larges, BAU 
obligatoires). SVP, ne me parlez plus de la vitesse max. Pitié !

Por ello, técnicamente, la diferencia entre una autopista y una autovía depende 
básicamente del diseño: Las autopistas están diseñadas para circular
a una velocidad máxima constante, con curvas de radios amplios que, por norma 
general, no obliguen a reducir la velocidad (salvo excepciones
inevitables por el terreno donde se ubican), y disposición de carriles de 
aceleración y deceleración lo suficientemente largos, condiciones que 
pueden tener también algunas autovías sin ser obligatorio.

Devant le peu de réactions sur mes précédentes remarques, je crée aujourd'hui 
le FLMT (Front de libération des motorroads et des trunks).

il me semble que le fait de ne pas inclure dans le même tag autoroute et voie 
express est un cas typique de taggage pour le rendu, dont la source  
est le rendu différentiel des cartes de l'IGN.
Voilà une bonne raison de ne pas se précipiter sur le RGE. ;-)
Cela a semblé plus confortable de se raccrocher à ce qu'on connaissait.

A bas l'exception française mal placée !


Christian Rogel




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


Re: [OSM-talk-fr] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Christian Quest
La cellule "GA" s'est déjà activée ;)


2012/10/17 Romain MEHUT :
> Bonsoir,
>
> Un ami Vosgien vient de me transférer le message qu'il a reçu de pnorman.
>
> Il fait des intégrations de bâti dans les Vosges mais il ajoute aussi tout
> ce qui va avec c'est à dire les rues, les POI... Il est garde-forestier et a
> pour but d'utiliser OSM dans le cadre de son travail. Bref, il fait du bon
> "boulot" en tant que contributeur. Il n'est pas au courant des histoires
> dont on a longuement parlé sur la liste.
>
> Je lui conseille de mettre les intégrations de bâti en stand-by?
>

Une petite pause sur le bâti en attendant d'avoir un retour du DWG...

-- 
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] Fwd: [OpenStreetMap] Message en anglais de pnorman

2012-10-17 Par sujet Romain MEHUT
Bonsoir,

Un ami Vosgien vient de me transférer le message qu'il a reçu de pnorman.

Il fait des intégrations de bâti dans les Vosges mais il ajoute aussi tout
ce qui va avec c'est à dire les rues, les POI... Il est garde-forestier et
a pour but d'utiliser OSM dans le cadre de son travail. Bref, il fait du
bon "boulot" en tant que contributeur. Il n'est pas au courant des
histoires dont on a longuement parlé sur la liste.

Je lui conseille de mettre les intégrations de bâti en stand-by?

Romain

-- Forwarded message --
From: Kalaallit Nunaat 
Date: 2012/10/17
Subject: [OpenStreetMap] Message en anglais de pnorman
To: romain.me...@gmail.com

Bonjour Rom1,

Kalaallit Nunaat
vous a envoyé un
message depuis OpenStreetMap avec le sujet Message en
anglais de pnorman :
==

Salut Romain, Pourrais-tu me dire ce que raconte ce message, je n'est pas
tout compris, aurais-je fait une "boulette" ! Merci par avance Denis

Hello

I noticed you conducting an import with

http://www.openstreetmap.org/browse/changeset/13523584

The import guidelines require that imports be done from a dedicated
account, after consultation with the local community and be documented on
the wiki.

These imports were not done from a dedicated account.

I would suggest that the dedicated account

have a link to your main account for contact purposes

and

have a listing of any imports you have done on it with links to the
entries in the import catalogue

As a general reminder, the other import guidelines can be found on the
wiki. These include

appropriate documentation

consultation with the local community and the imports@ mailing list

having a plan to fix an mistakes in case of a broken upload

other technical requirements

Ignoring this and continuing to import from your main account may lead to a
block.

To contact me you can send a message or email the data working group

Paul Norman for the Data Working Group
==

Vous pouvez également lire le message sur
http://www.openstreetmap.org/message/read/308131 et vous pouvez répondre
sur http://www.openstreetmap.org/message/reply/308131
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN

2012-10-17 Par sujet Jean-Claude Repetto
On 17/10/2012 09:44, Sylvain Maillard wrote:
> Le 17 octobre 2012 00:04, Balaitous  > a écrit :
> 
> Les essais de reconnaissance automatique que j'ai fait (huggin) n'ont
> pas été concluants, il n'y a rien qui ressemble plus a un toit qu'un
> autre toit, et les problèmes de perspective sont très important (en
> limite de photo, la prise de vue est effectuée avec un angle de 45°)
> 
> C'est surtout au niveau GUI qu'on peut rendre ce travail moins
> fastidieux.
> 
> Pour l'instant le programme est un peu en sommeil, mais je compte m'y
> remettre cet hivers. Je suis preneur de toute bonne idée.
> 
> 
>  Salut,
> 
> pour ce qui est du calage des image, c'est quelque chose de très
> fréquent en télé-détection et il y a un certain nombre d'outils libres
> qui font ça. Tu peux aller regarder du côté de GRASS, il y a 2
> extensions qui font des choses très intéressantes:
> - i.point.auto
> (http://grass.osgeo.org/wiki/AddOns_/_GRASS_6#i.points.auto) qui
> recherche automatiquement des points de correspondance entre 2 images
> - i.linespoints et i.homography
> (http://grass.osgeo.org/wiki/AddOns_/_GRASS_6#i.homography) qui
> permettent d'utiliser également des lignes pour recaler l'image
> 
> il faudra que je fouille un peu, je suis sur d'avoir vu passer également
> une extension pour plaquer une photo oblique sur un mnt, mais je
> n'arrive plus à me souvenir du nom ...
> 
> la prise en main peut sembler compliquée, mais une fois qu'on a compris
> les principes de base tout devient beaucoup plus simple, et on peut même
> tout scripter en python ;)
> 
> Sylvain

Bonjour,

On a parlé d'orthorectification aujourd'hui sur la liste GDAL :

There is a good article about ortho in Russian
(http://gis-lab.info/qa/orbview3-ortho-gdal.html). You can google
translate it. Also there is a translation
(http://wiki.gis-lab.info/w/OrbView-3_Orthorectification) but not finished.

Jean-Claude

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


[OSM-talk-fr] ou est la licence?

2012-10-17 Par sujet Claude

Bonjour

je suis tombé la-dessus

http://www.gralon.net/plan-ville/plan-briare-17516.htm

une carte openstreetmap qui renvoie sur une carte Google

cordialement
Claude

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


Re: [OSM-talk-fr] OSM sur Géofoncier ?

2012-10-17 Par sujet Pierre Touzard
Bonsoir à tous,

Pour info depuis septembre, les rendus "Mapnik" et "Mapquest" sont
disponibles sur GéoFoncier !

http://public.geofoncier.fr/index.php?context=metropole&layers=metropole:aurige_gp,RFU_FXX_LIMITES,RFU_FXX_SOMMETS,metropole:osm_standard,GEOGRAPHICALGRIDSYSTEMS.MAPS,CADASTRALPARCELS.PARCELS,ORTHOIMAGERY.ORTHOPHOTOS

Pratique pour une co-visualisation données OSM / données IGN...

L'API Géoportail ayant changé de projection les problèmes de projection
évoqués /supra / se sont envolés.

Pierre T.




--
View this message in context: 
http://gis.19327.n5.nabble.com/OSM-sur-Geofoncier-tp5388276p5731304.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] Avez-vous utilisé des données de la ville de Toulouse ?

2012-10-17 Par sujet Sébastien Dinot
Bonsoir Claire,

Claire Libertic a écrit :
> Désolée je n'ai pas regardé les autres retours mais sur ce que j'ai
> taggué "Toulouse" sur le delicious opendata ouvert de
> libertic, j ai identifié les
> projets suivants:
> [...]

Je m'aperçois que le goujat que je suis a oublié de te remercier pour
ces liens précieux. Merci donc et à demain !

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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


Re: [OSM-talk-fr] Avez-vous utilisé des données de la ville de Toulouse ?

2012-10-17 Par sujet Sébastien Dinot
Bonsoir Vincent,

Vincent Privat a écrit :
> - serveur WMS: on a la confirmation qu'on a l'autorisation de s'en
>   servir tel quel ? C'est avant tout leur WMS de travail qui peut
>   contenir des données qui ne sont pas (encore) ouvertes via le
>   portail open data (qui ne référence que les fichiers jpeg) ?

Il est indéniable que la fourniture se limite aux dalles référencées sur
le portail Open Data. La découverte et l'utilisation des serveurs WMS
n'a pas été anticipée par Toulouse Métropole et ses prestataires (qui
auraient du utiliser pour l'interface de navigation en ligne un serveur
WMS dédié) et nous n'avons obtenu aucun droit de les utiliser, d'autant
plus que ces serveurs donnent accès à des flux qui sortent clairement du
périmètre des données libérées.

Trop grisé par ma petite découverte hier soir, je n'y ai pensé que trop
tard ce matin et deux collègues m'ont justement fait la remarque
aujourd'hui après avoir découvert les flux auxquels nous avions accès.
J'aurais du réfléchir un peu avant de m'emballer. À défaut de pouvoir
revenir en arrière, je viens de supprimer la référence aux serveurs WMS
sur le Wiki.

Ceci étant, il est tout aussi certain qu'une fois toutes les dalles
récupérées, nous n'aurons aucun mal à monter un serveur WMS de notre
côté pour accéder aux données libérées. J'estime l'espace disque
nécessaire au stockage des images JPEG à 9 Go et celui nécessaire au
stockage de la pyramide tuilée à 12 Go.

Sébastien

-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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


Re: [OSM-talk-fr] Avez-vous utilisé des données de la ville de Toulouse ?

2012-10-17 Par sujet Vincent Privat
Hello, je passe en coup de vent (désolé de pas avoir pu intervenir plus tôt)
- page wiki: je pensais que tu parlais de réutilisation concrètes, pas
juste l'intégration des données dans OSM ^^
- serveur WMS: on a la confirmation qu'on a l'autorisation de s'en servir
tel quel ? C'est avant tout leur WMS de travail qui peut contenir des
données qui ne sont pas (encore) ouvertes via le portail open data (qui ne
référence que les fichiers jpeg) ?
- pour la page wiki JOSM Maps: si des volontaires veulent s'y pencher, j'ai
créé un plugin pour faciliter le travail de tracé des limites:
http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery-XML-Bounds Sinon
j’essaierai de faire ça au minimum pour dimanche (cartopartie à Toulouse)
- page wiki orthos: Merci Seb !

A+ (à demain ;) )
Vincent

Le 17 octobre 2012 09:15, Romain MEHUT  a écrit :

> Le 16 octobre 2012 22:53, Sébastien Dinot  a
> écrit :
>
>
>> Merci Romain pour ce lien fort intéressant que j'avais complètement zappé
>> alors que je connais son auteur principal !
>>
>
> De rien ;)
> A noter qu'il reste un grand nombre d'écoles à intégrer. Les données
> peuvent être confrontées avec celles de data.gouv.fr cf.
> http://nomino.comptoir.net/etablissements/
>
> Romain
>
> ___
> 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] OSMTransport France

2012-10-17 Par sujet Francescu GAROBY
Je viens de tester quelques stations de Velo'v : il y a bien des noms avec
le / dedans ! Ex : Saint-Luc / Saint-Joseph, Augagneur / Fosse aux Ours,
Universités Lyon III / Lyon II. Donc le problème ne semble pas venir de
là...

Francescu


Le 17 octobre 2012 18:26, Eric  a écrit :

>
>  C'est un bel outil.
>>>
>>> Remarque sur les parking à vélo (amenity=bicycle_parking) il faut
>>> qu'ils aient un nom (name=*) pour qu'ils apparaissent. Mais c'est
>>> difficile de trouver un nom pour un parking à vélo ...
>>> Par exemple, à Tours, sur l'outil, il n'y a que 2 parking car au lieu
>>> du tag "capacity" c'est "name" qui a été utilisé par erreur.
>>>
>>
>> Nous n'utilisons pas le tag amenity=bicycle_parking mais
>> amenity=bicycle_rental sans tenir compte du tag name
>>
>> Les données ne sont peut-être pas encore à jour.
>>
>> René-Luc
>>
>>
> Bonjour ! C'est un très bel outil effectivement ! Mais sur les Velo'v de
> Lyon, vu le nombre de "Undefined" qu'il y a en titre des boites, je me
> demande si l'outil accepte les slash ("/") dans les noms ? Les stations de
> Lyon en ont presque toutes un dans le nom et j'ai l'impression que ca
> correspond à la louche aux "undefined". Et inversement, je n'en ai pas vu
> qui s'affichent correctement avec un slash dans le nom. Il y a peut etre un
> soucis de traitement de ce caractère.
> Ou sinon, c'est à cause de données trop vieilles mais la mise à jour
> Velo'v date de début aout donc je ne pense pas...
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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


Re: [OSM-talk-fr] OSMTransport France

2012-10-17 Par sujet Eric
> C'est un bel outil.
>>
>> Remarque sur les parking à vélo (amenity=bicycle_parking) il faut
>> qu'ils aient un nom (name=*) pour qu'ils apparaissent. Mais c'est
>> difficile de trouver un nom pour un parking à vélo ...
>> Par exemple, à Tours, sur l'outil, il n'y a que 2 parking car au lieu
>> du tag "capacity" c'est "name" qui a été utilisé par erreur.
>>
>
> Nous n'utilisons pas le tag amenity=bicycle_parking mais
> amenity=bicycle_rental sans tenir compte du tag name
>
> Les données ne sont peut-être pas encore à jour.
>
> René-Luc
>
>
Bonjour ! C'est un très bel outil effectivement ! Mais sur les Velo'v de
Lyon, vu le nombre de "Undefined" qu'il y a en titre des boites, je me
demande si l'outil accepte les slash ("/") dans les noms ? Les stations de
Lyon en ont presque toutes un dans le nom et j'ai l'impression que ca
correspond à la louche aux "undefined". Et inversement, je n'en ai pas vu
qui s'affichent correctement avec un slash dans le nom. Il y a peut etre un
soucis de traitement de ce caractère.
Ou sinon, c'est à cause de données trop vieilles mais la mise à jour Velo'v
date de début aout donc je ne pense pas...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] mapping en éthiopie

2012-10-17 Par sujet Jean-François Gaffard
bonjour 
après avoir vu le documentaire "Planète à vendre" hier soir
il m'a pris l'envie d'aller voir du cote de Gambela en Ethiopie. j'ai un
peu mappé au nord-est de cette ville d'après les images Bing mais :

je constate des routes avec une source DEPHA et un id qui ne semble
correspondre à rien sur les images satellite. est ce que quelqu'un
connait cette source ?

des zones de forêts taillées à la hache c'est le cas de le dire

d'autre part il ne semble pas avoir ni de repères géodésiques ou de
traces GPS pour essayer de recaler. Avec Map compare il semble y avoir
un peu de décalage avec Google mais je ne sais qui a raison de Bing ou
de Google

des conseils ou une astuce ?

jeff


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


[OSM-talk-fr] mapping en éthiopie

2012-10-17 Par sujet Jean-François Gaffard
bonjour 
après avoir vu le documentaire "Planète à vendre" hier soir
il m'a pris l'envie d'aller voir du cote de Gambela en Ethiopie. j'ai un
peu mappé au nord-est de cette ville d'après les images Bing mais :

je constate des routes avec une source DEPHA et un id qui ne semble
correspondre à rien sur les images satellite. est ce que quelqu'un
connait cette source ?

des zones de forêts taillées à la hache c'est le cas de le dire

d'autre part il ne semble pas avoir ni de repères géodésiques ou de
traces GPS pour essayer de recaler. Avec Map compare il semble y avoir
un peu de décalage avec Google mais je ne sais qui a raison de Bing ou
de Google

des conseils ou une astuce ?

jeff


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


Re: [OSM-talk-fr] OSMTransport France

2012-10-17 Par sujet rldhont

Le 17/10/2012 14:05, Guilhem Bonnefille a écrit :

Le 16 octobre 2012 17:42, Otourly Wiki  a écrit :

Je sais pas où remonter les erreurs d'OSM transport mais le funiculaire de
Lyon qui va à Saint-Just s'arrête à l'arrêt Saint-Just. La base et le rendu
OSM est juste...

Interrogation similaire : j'ai remarqué une incomplétude. J'ai voulu
corriger dans OSM mais... je trouve moins d'information dans OSM que
dans OSM transport. A quoi est-ce dû ? Vous utilisez quelles données ?


Les données n'étaient peut-être pas très fraîche...




PS : ce "bug" est en région Toulousaine


J'ai mis à jour Toulouse

René-Luc

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


Re: [OSM-talk-fr] OSMTransport France

2012-10-17 Par sujet rldhont

Le 17/10/2012 13:45, Guilhem Bonnefille a écrit :

Bonjour,

Le 16 octobre 2012 17:29, rldhont  a écrit :

Je vous l'avais annoncé pendant l'été, OSMTransport à changer de peau.
Ce changement me permet aujourd'hui de proposer une version pour la France
avec les fonds Géoportail de l'IGN.
http://demo.3liz.com/osmtransport/france.php

Par contre il est intéressant de remarquer que les fonds Bing semblent de
meilleur qualité et plus récent.

Joli travail.

Une remarque si je puis me permettre : je n'ai pas su trouver un lien
pour ouvrir le site OpenStreetMap sur la zone en cours de
visualisation. C'est pourtant bien pratique lorsqu'on est contributeur
et qu'on aperçoit un bug grossier. Est-il envisageable de rajouter ce
type de chose ?



C'est envisageable, je n'avais pas pensé à faire cela.

René-Luc


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


Re: [OSM-talk-fr] OSMTransport France

2012-10-17 Par sujet rldhont

Le 16/10/2012 23:49, Cyrille Giquello a écrit :

Le 16 octobre 2012 17:29, rldhont  a écrit :

Bonjour,

Je vous l'avais annoncé pendant l'été, OSMTransport à changer de peau.
Ce changement me permet aujourd'hui de proposer une version pour la France
avec les fonds Géoportail de l'IGN.
http://demo.3liz.com/osmtransport/france.php

Par contre il est intéressant de remarquer que les fonds Bing semblent de
meilleur qualité et plus récent.

René-Luc

C'est un bel outil.

Remarque sur les parking à vélo (amenity=bicycle_parking) il faut
qu'ils aient un nom (name=*) pour qu'ils apparaissent. Mais c'est
difficile de trouver un nom pour un parking à vélo ...
Par exemple, à Tours, sur l'outil, il n'y a que 2 parking car au lieu
du tag "capacity" c'est "name" qui a été utilisé par erreur.


Nous n'utilisons pas le tag amenity=bicycle_parking mais 
amenity=bicycle_rental sans tenir compte du tag name


Les données ne sont peut-être pas encore à jour.

René-Luc



Peut-être ne pas tenir compte du "name" pour ces éléments.




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


Re: [OSM-talk-fr] OSMTransport France

2012-10-17 Par sujet rldhont

Le 16/10/2012 19:34, Bruno Cortial a écrit :



Le 16 octobre 2012 17:29, rldhont > a écrit :


Bonjour,

Je vous l'avais annoncé pendant l'été, OSMTransport à changer de peau.
Ce changement me permet aujourd'hui de proposer une version pour
la France avec les fonds Géoportail de l'IGN.
http://demo.3liz.com/osmtransport/france.php

Par contre il est intéressant de remarquer que les fonds Bing
semblent de meilleur qualité et plus récent.

René-Luc


Bonjour
Merci pour cette mise à jour.

Les rendus "transport" posent problème actuellement quand les 
itinéraires se chevauchent (ce qui est presque toujours le cas) :on ne 
voit qu'une ligne.


Oui mais il est possible de ne visualiser qu'une ligne à la fois.
Nous n'avons pas chercher à créer une carte des réseaux de transport 
mais une application permettant de visualiser les données de Transport 
en Commun présentent dans OpenStreetMap


J'ai investigué un peu, et il existe un algorithme dit "du 
serpent" qui permet de modifier leur géométrie (hors OSM ;-) ) afin de 
les dé-doublonner.
Cela permettrait d'avoir des itinéraires parallèles là où ils se 
chevauchent, et chacun serait visible avec sa couleur.


Je ne connaissais pas cet algo, je regarderais si j'ai le temps



GRASS implémente çà (v.generalize method=displacement)
http://grass.osgeo.org/grass64/manuals/html64_user/v.generalize.html

N'ayant toujours pas compris comment faire marcher GRASS, j'ai 
zappé... temporairement.


Tu peux tester GRASS via QGIS installé via OSGEO4W



Quelqu'un a-t-il déjà tenté ?


J'utilise régulièrement GRASS avec QGIS sous Ubuntu sinon pour Windows 
tu peux les installer via OSGEO4W.


René-Luc


Bruno


___
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] OSMTransport France

2012-10-17 Par sujet rldhont

Le 16/10/2012 18:05, Francescu GAROBY a écrit :

Sympa d'avoir le fond de carte IGN. :-)
Par contre, je remarque 2 bugs :
* lorsqu'on clique sur un arrêt de bus (plusieurs cas rencontrés à  
Caen, sur la ligne 7 par ex.), il apparait plusieurs fois le même 
numéro de ligne de bus passant par cet arrêt.


Ce n'est pas un bug, je liste l'ensemble des relation de type route dont 
fait partie un arrêt. Lorsque j'ai développé OSMTransport, le modèle de 
données ne définissait qu'une relation de type route par ligne de bus.



* les numéros des lignes passant par un arrêt ne sont pas toujours triés.


Ce n'est pas un bug, mais quelque chose que je n'ai pas fait



Et enfin, une question : quelle est la fraîcheur des données ? Car je 
travaille très fréquemment (quasi quotidiennement) à 
enregistrer/améliorer les tracés des transports en commun sur Caen et 
son agglo, et je remarque des différences avec ce que j'ai déjà saisi 
(certaines données vieilles de quelques semaines n'apparaissent pas).


Pas forcément très fraîche, le système de cron que j'avais mis en place 
n'est plus valable. Mais j'ai fait des mises à jour sur certaine ville 
ses dernières 48h.


Merci pour ces retours.

René-Luc


Francescu

Le 16 octobre 2012 17:29, rldhont > a écrit :


Bonjour,

Je vous l'avais annoncé pendant l'été, OSMTransport à changer de peau.
Ce changement me permet aujourd'hui de proposer une version pour
la France avec les fonds Géoportail de l'IGN.
http://demo.3liz.com/osmtransport/france.php

Par contre il est intéressant de remarquer que les fonds Bing
semblent de meilleur qualité et plus récent.

René-Luc

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




--
Cordialement,
Francescu GAROBY



___
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] lieux-dits

2012-10-17 Par sujet Mikaël Cordon
Il est vrai que je n’avais pas percuté sur « vallée » ou « plaine »… Il me
semble qu’effectivement ça ne s’appliquerai pas, ou alors il faut une
liaison hiérarchique pour les inclusions.

Moi, je parlais des lieux-dits « La Pièce de Machin », « Le Clos de Bidule
» et autres « Le Chatrain » ou « Le Chiron Poulet » (un des plus amusant).

Je tiens à faire remarquer que certains de ces lieux-dits se nomment «
Vallée… » ou « Plaine… » et sont bien des lieux-dits notés place=locality ;
comme « La Vallée de la Digue » qui est bien une petite vallée mais trop
petite pour contenir un autre lieu-dit.

Ce dernier paragraphe étant, évidemment, pour souligner la
non-systématisation de l’association « toponymie-tag ».

Cordialement,
--
Mikaël Cordon (mickey86)

Le 17 octobre 2012 14:10, Pieren  a écrit :

> 2012/10/17 Mikaël Cordon :
> > Moi aussi, j’en ai placé un bon paquet dans la région poitevine,
> d’ailleurs.
> > Ils viennent en grande majorité du cadastre.
>
> locality, c'est pour les lieux-dits inhabités mais tout ce qui
> inhabité n'est pas forcément un locality. Beaucoup d'îles sont
> inhabitées et ça n'en fait pas automatiquement des "locality". Une
> vallée ou une plaine ou une forêt n'est pas un lieu-dit. C'est un
> espace trop vaste et qui peut contenir lui-même une multitudes de
> lieux-dits. Alors comment vous allez hiérarchiser le "locality" de  la
> vallée et les "locality" / lieux-dits qui en font partie ? Un lieu-dit
> ne peut pas en contenir d'autres et se limite à un espace
> intra-communal, ce qui est rarement le cas pour une plaine ou une
> vallée.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Philippe Verdy
Autres avantages du biseau ("bevel" en anglais) complet pour les
angles pas trop aigus (par rapport à la jonction circulaire) :

- les buffers tracés autour de champs ou bâtiments rectangulaires
resteront rectangulaires (sans coins arrondis), et sans aucun point
supplémentaire

- les limites administratives définies par les axes centraux de rues
qui se coupent quasi-orthogonalement seront placées aussi dans un
buffer contenant la totalité de leur carrefour (avec les passages
piétons et feux ajoutés près de cette intersection, pour peu que la
largeur de tampon soit aussi large que la largeur de rue: avec le
rayon du tampon supérieur à 15 mètres et probablement voisin de
l'ordre de 50 mètres, ce devrait toujours être le cas).

- même chose quand la limite administrative suit une ligne de crête en
montagne, et quand le tampon devrait donc inclure le sommet d'un mont,
pour qu'il figure dans une sélection d'objets dont le placement sur la
frontière est à vérifier (ce n'est pas garanti avec un arc de cercle).

L'arc de cercle en revanche contiendra une surface de tampon
supérieure dans le cas des pointes les plus aiguës dépassant le seuil
de troncature des biseaux, mais là encore cela dépend du nombre de
segments générés par quart de cercle (si ce nombre de segments par
quart de cercle est réduit près de son minimum de 0,5, ce qui est très
acceptable pour des tampons de moins de 50 mètres de rayon, le biseau
sera préférable étant donné les limites décamétriques de résolution
des données dans OSM, et dans les sources de référence géographique
dont on dispose aujourd'hui et qu'on utilise, même si OSM peut déjà
stocker une résolution de moins de 10 centimètres partout en France
métropolitaine, une résolution inutilisée pour les zooms de rendus
habituels sauf à partir de sources d'imagerie en très haute
résolution, mais avec des décalages orthophotographiques encore très
incertains et pas mesurables avec nos GPS grand public).

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


Re: [OSM-talk-fr] lieux-dits

2012-10-17 Par sujet Pieren
2012/10/17 Mikaël Cordon :
> Moi aussi, j’en ai placé un bon paquet dans la région poitevine, d’ailleurs.
> Ils viennent en grande majorité du cadastre.

locality, c'est pour les lieux-dits inhabités mais tout ce qui
inhabité n'est pas forcément un locality. Beaucoup d'îles sont
inhabitées et ça n'en fait pas automatiquement des "locality". Une
vallée ou une plaine ou une forêt n'est pas un lieu-dit. C'est un
espace trop vaste et qui peut contenir lui-même une multitudes de
lieux-dits. Alors comment vous allez hiérarchiser le "locality" de  la
vallée et les "locality" / lieux-dits qui en font partie ? Un lieu-dit
ne peut pas en contenir d'autres et se limite à un espace
intra-communal, ce qui est rarement le cas pour une plaine ou une
vallée.

Pieren

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


Re: [OSM-talk-fr] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Philippe Verdy
Le 17 octobre 2012 11:57, Ab_fab  a écrit :
>> Ce qu'il faut plus généralement c'est un outil qui implémente une fonction
>> de type
>> "buffer", "zone tampon" en français. Avec Postgis, c'est ici :
>> http://www.postgis.org/documentation/manual-2.0/ST_Buffer.html
>> Ça permet de dilater une surface. Le travers à éviter, c'est de générer
>> trop de points,
>> la fonction de Postgis permet de jouer là-dessus avec le paramètre
>> num_seg_quarter_circle.

Ce problème du nombre de points qui augmente beaucoup vient du fat
qu'au lieu de joindre les tampons rectangulaires par des biseaux
complets (en losange) ou des biseaux tronqués (trinagulaires), tu
utilises des arcs de cercle.

C'est une autre solution, mais est-ce vraiment souhaitable pour la
demande de polygones simples ?

Un biseau complet ne change pas le nombre de points autour du sommet
déplacé par le buffer, et un biseau tronqué (uniquement sur les
pointes les plus aiguës dont le biseau dépasserait le paramètre de
seuil) de fait que doubler ce point.

Pour la demande de "simple polygone englobant", un biseau complet est
préférable, mais avec un rapport seuil de biseau raisonnable
(légèrement supérieur à 1 et souhaitablement inférieur à 4) suffit  :
je pencherais pour un seuil voisin de 1,73, ce qui limite les biseaux
complets aux angles de plus de arctg(1,73) = 60 degrés, les pointes
d'angle inférieur étant joints non pas par un biseau complet mais
tronqués par un simple triangle (un seule sommet ajouté), et non un
arc de cercle qui augmente beaucoup le nombre de points.

Maintenant si tu as un paramètre qui limite le nombre de segment
générés par sommet à joindre pour parcourir un seul quart de cercle, 1
seul segment par quart de cercle suffit (ce qui génère tout de même 2
segments et 3 sommets par angle aigu déplacé par le buffer au lieu
d'un unique segment et 2 points par un biseau tronqué, et aucun
segment ni point en plus pour le biseau complet).

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


Re: [OSM-talk-fr] OSMTransport France

2012-10-17 Par sujet Guilhem Bonnefille
Le 16 octobre 2012 17:42, Otourly Wiki  a écrit :
> Je sais pas où remonter les erreurs d'OSM transport mais le funiculaire de
> Lyon qui va à Saint-Just s'arrête à l'arrêt Saint-Just. La base et le rendu
> OSM est juste...

Interrogation similaire : j'ai remarqué une incomplétude. J'ai voulu
corriger dans OSM mais... je trouve moins d'information dans OSM que
dans OSM transport. A quoi est-ce dû ? Vous utilisez quelles données ?


PS : ce "bug" est en région Toulousaine
-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

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


Re: [OSM-talk-fr] QueChoisir ? OSM, bien sûr !

2012-10-17 Par sujet Ab_fab
Si j'ai un conseil à leur donner, maintenant qu'ils ont fait le plus dur,
ce serait de changer la feuille de style pour la rendre un peu plus épuré,
pour ne pas dire glamour :-)
Partir de ça, par exemple : https://github.com/mapbox/osm-bright

Le 17 octobre 2012 13:39, Vincent de Chateau-Thierry  a
écrit :

>
>
> Pour le fond, QueChoisir utilise ses propres tuiles, comme par ex. :
> http://static2.maps.quechoisir.org/10/519/351.png
> Il y a à la fois l'indépendance technique (si les serveurs de tuile d'
> osm.org sont
> down, c'est transparent pour le site quechoisir.org), aussi
> l'indépendance éditoriale :
> la charte des tuiles sur quechoisir.org est celle du rendu Mapnik
> aujourd'hui, mais
> rien ne les empêche d'en changer à leur guise. Enfin, il faut noterqu'ils
> respectent
> ce point :
> http://wiki.openstreetmap.org/wiki/FR:Tile_usage_policy
>
> ___
> 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] QueChoisir ? OSM, bien sûr !

2012-10-17 Par sujet Christian Quest
Le 17 octobre 2012 13:11, Nicolas Bouthors  a écrit :
> Question(s) sur le sujet :
>
> Pour ce genre de site "tout venant" qui souhaite mettre en place des cartes 
> basées sur
> OSM, quel est leur intéret à monter leur propre chaine 
> postgis/rendering/import ?
> L'indépendance bien sûr mais encore ?
>
> OpenStreetMap france (ou .org) aurait-il une légitimité à proposer à ces 
> sites d'utiliser
> les services en place (layers.osm.fr par exemple ici) ?
>
> Cela serait-il réaliste ? Intéressant ?
>


Nos ressources techniques sont utilisées en priorité pour favoriser la
contribution.
Pour la ré-utilisation, ce n'est pas la priorité, mais c'est aussi
quelque chose d'utile à proposer dans la limite de nos moyens pour des
services basiques.

Ce qu'il manque ce sont des services très faciles d'emploi, pour
simplifier la ré-utilisation.

-- 
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] OSMTransport France

2012-10-17 Par sujet Guilhem Bonnefille
Bonjour,

Le 16 octobre 2012 17:29, rldhont  a écrit :
> Je vous l'avais annoncé pendant l'été, OSMTransport à changer de peau.
> Ce changement me permet aujourd'hui de proposer une version pour la France
> avec les fonds Géoportail de l'IGN.
> http://demo.3liz.com/osmtransport/france.php
>
> Par contre il est intéressant de remarquer que les fonds Bing semblent de
> meilleur qualité et plus récent.

Joli travail.

Une remarque si je puis me permettre : je n'ai pas su trouver un lien
pour ouvrir le site OpenStreetMap sur la zone en cours de
visualisation. C'est pourtant bien pratique lorsqu'on est contributeur
et qu'on aperçoit un bug grossier. Est-il envisageable de rajouter ce
type de chose ?

-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/

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


Re: [OSM-talk-fr] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Ab_fab
Que demande le peuple ...
\o/

J'ai pu tester avec les paramètres par défaut pour le contour de Nantes
Métropole
http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py?id=420326

L'image générée est bien pratique pour voir le travail de l'outil
http://osm102.openstreetmap.fr/~jocelyn/polygons/images/420326/0.004000-0.001000-0.001000.png
2012 points pour le contour initial, 265 pour le polygone simplifié qui
l'entoure.

Merci pour le tuyau !

Le 17 octobre 2012 13:26, Jocelyn Jaubert  a
écrit :

> Bonjour,
>
> On Wed, Oct 17, 2012 at 10:19:18AM +0200, Ab_fab wrote:
> > Cela pourrait être utile pour faire des extractions de données plus fines
> > qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
> > l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a fait
> > Jocelyn avec la France métropolitaine, mais pour des zones plus
> restreintes
> >
> > Est-ce qu'une base PostGIS est nécessaire  ? Est-ce que JOSM propose ce
> > genre de fonction ?
>
> C'est bien plus facile avec PostGIS quand même.
>
> J'ai fait une interface web pour faire ce genre de chose à partir d'une
> relation, accessible sur:
> http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py
>
> À noter que:
>   - ce n'est pas instantané :)   (compter 5-20s pour une grosse commune)
>   - il est possible d'utiliser des hiérarchies de relations, comme la
> relation France
>   - ça peut générer une "image" pour vérification, un WKT, ou un .poly
>   - on peut aussi générer un polygone "englobant", avec des paramètres
> variés.
> Les paramètres par défaut devrait être approprié pour la plupart des
> cas.
>   - PostGIS est bien plus strict que OSM sur les polygones. Il arrive
> souvent
> que la création du polygone échoue, pour une raison peu claire, mais en
> général autour de la lat/lon indiquée. Un tour vers
> http://osm8.openstreetmap.fr/~osmbin/analyse-relation-open.py? id>
> devrait donner des indices dans ce cas
>
>
> Ce n'est pas actuellement complétement automatisé, mais j'envisage une API
> pour
> générer directement le WKT/.poly engloblant à partir d'un id de relation.
>
>
> --
> Jocelyn
>
> ___
> 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] QueChoisir ? OSM, bien sûr !

2012-10-17 Par sujet Vincent de Chateau-Thierry

> De : "Nicolas Bouthors" 
>
> Question(s) sur le sujet : 
> 
> Pour ce genre de site "tout venant" qui souhaite mettre en place des cartes 
> basées sur
> OSM, quel est leur intéret à monter leur propre chaine 
> postgis/rendering/import ?
> L'indépendance bien sûr mais encore ?
> 

Pour le fond, QueChoisir utilise ses propres tuiles, comme par ex. :
http://static2.maps.quechoisir.org/10/519/351.png
Il y a à la fois l'indépendance technique (si les serveurs de tuile d'osm.org 
sont
down, c'est transparent pour le site quechoisir.org), aussi l'indépendance 
éditoriale :
la charte des tuiles sur quechoisir.org est celle du rendu Mapnik aujourd'hui, 
mais
rien ne les empêche d'en changer à leur guise. Enfin, il faut noterqu'ils 
respectent
ce point :
http://wiki.openstreetmap.org/wiki/FR:Tile_usage_policy

Je ne connais pas les stats de fréquentation du site quechoisir.org mais c'est 
un site
grand public, du coup leur accès en direct aux tuiles d'osm.org dépasserait 
sûrement
la consommation que chacun peut faire de ces tuiles.

> OpenStreetMap france (ou .org) aurait-il une légitimité à proposer à ces 
> sites 
d'utiliser
> les services en place (layers.osm.fr par exemple ici) ? 
> 
> Cela serait-il réaliste ? Intéressant ?
> 
Dans le cas présent le GeoFLA arrive directement en vectoriel (en json) sur le 
poste
client, il n'y a pas de tuiles, mais ça se défend sachant qu'il y a une 
intelligence
associée à chaque objet : il doit être coloriable dynamiquement et cliquable.
Voilà le type de réponse (xml) :
http://maps.quechoisir.org/deserts-medicaux/search-zipcode.php?
codePostal=95100&ind=3&spe=ge_ind&dist=30

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] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Jocelyn Jaubert
Bonjour,

On Wed, Oct 17, 2012 at 10:19:18AM +0200, Ab_fab wrote:
> Cela pourrait être utile pour faire des extractions de données plus fines
> qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
> l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a fait
> Jocelyn avec la France métropolitaine, mais pour des zones plus restreintes
> 
> Est-ce qu'une base PostGIS est nécessaire  ? Est-ce que JOSM propose ce
> genre de fonction ?

C'est bien plus facile avec PostGIS quand même.

J'ai fait une interface web pour faire ce genre de chose à partir d'une
relation, accessible sur:
http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py

À noter que:
  - ce n'est pas instantané :)   (compter 5-20s pour une grosse commune)
  - il est possible d'utiliser des hiérarchies de relations, comme la relation 
France
  - ça peut générer une "image" pour vérification, un WKT, ou un .poly
  - on peut aussi générer un polygone "englobant", avec des paramètres variés.
Les paramètres par défaut devrait être approprié pour la plupart des cas.
  - PostGIS est bien plus strict que OSM sur les polygones. Il arrive souvent
que la création du polygone échoue, pour une raison peu claire, mais en
général autour de la lat/lon indiquée. Un tour vers
http://osm8.openstreetmap.fr/~osmbin/analyse-relation-open.py?
devrait donner des indices dans ce cas


Ce n'est pas actuellement complétement automatisé, mais j'envisage une API pour
générer directement le WKT/.poly engloblant à partir d'un id de relation.


-- 
Jocelyn

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


Re: [OSM-talk-fr] QueChoisir ? OSM, bien sûr !

2012-10-17 Par sujet Nicolas Bouthors
Question(s) sur le sujet : 

Pour ce genre de site "tout venant" qui souhaite mettre en place des cartes 
basées sur
OSM, quel est leur intéret à monter leur propre chaine postgis/rendering/import 
?
L'indépendance bien sûr mais encore ?

OpenStreetMap france (ou .org) aurait-il une légitimité à proposer à ces sites 
d'utiliser
les services en place (layers.osm.fr par exemple ici) ? 

Cela serait-il réaliste ? Intéressant ?

Le 16/10/2012 20:15, Romain MEHUT écrivait  :
> Bonsoir,
> 
> Une nouvelle carte interactive sur le site de Que Choisir:
> http://www.quechoisir.org/sante-bien-etre/systeme-de-sante/professionnel-de-sante/test-de-services-acces-aux-soins-la-carte-de-la-fracture-sanitaire
> 
> Romain
> 
> Le 10 juillet 2012 17:43, Pieren  a écrit :
> 
> > Tombé sur un article du Figaro qui parle d'une nouvelle carte
> > interactive sur le site quechoisir.org:
> >
> > http://www.lefigaro.fr/conso/2012/07/10/05007-20120710ARTFIG00481-les-supermarches-moins-chers-se-situent-sur-la-cote-bretonne.php
> >
> > Evidemment, nos yeux avertis remarquent immédiatement le style
> > "mapnik". Et hop, un ptit tour sur le site:
> >
> > http://www.quechoisir.org/commerce/test-de-services-panier-de-l-ete-trouvez-le-magasin-le-moins-cher-sur-le-littoral
> >
> > et on voit ainsi que QueChoisir adopte notre projet (et avec la bonne
> > attribution en plus). Les tuiles sont abritées sur leur site et les
> > données relativement récentes (mais pas toutes fraiches) avec un
> > niveau de zoom plus restreint.
> >
> > Pieren
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >

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


-- 
Nicolas BOUTHORS

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


Re: [OSM-talk-fr] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Philippe Verdy
On peut noter aussi que le critère de concavité des angles serait très
utile pour déterminer de façon plus exacte ce qu'on appelle en France
la "ligne de base" et qui se rapproche au mieux de la ligne de côte en
éliminant les petits creux, en traçant une frontière administrative
traversant la mer (en s'éloignant donc de la ligne de côte).

Tout ceci pourrait être idéalement calculé de façon purement
mathématique avec les mêmes critères simples que je décris avant :

- la largeur de buffer (si la ligne de base doit partout être tracée
en mer et ne jamais suivre la ligne naturelle des côtes directement)

- le rapport seuil d'extension maximale des biseaux, équivalent aussi
à une cotangente et donc aussi à un angle aigu minimum (sauf que sous
la forme d'un rapport de longueur il ne nécessite aucune utilisation
des fonctions trigonométriques, mais juste des opérations
arithmétiques que sont l'addition et la multiplication pour calculer
les carrés des longueurs et la division pour en calculer le rapport
des longueurs au carré). Pour ce genre d'appplication de calcul des
lignes de base, ce rapport seuil devrait être de 1 et non 4, même si
cela double certains sommets sur les pointes les plus acérées (avec un
rapport de 1, les angles droits et obtus sont tous conservés et tous
les angles aigus sont tronqués par une jonction en trianglet et non
joints par un biseau en losange).

Mais la difficulté de la détermination de la ligne de base est de
savoir ce qu'on retient comme ligne de côte au départ de ce calcul
(dépendante des coefficients et hauteurs de marées, des débits des
fleuves à leurs embouchures et du relief des fonds marins et
fluviaux).

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


Re: [OSM-talk-fr] QueChoisir ? OSM, bien sûr !

2012-10-17 Par sujet Philippe Verdy
Donc l'idée serait de développer notre propre version du GEOFLA pour
les communes, mais avec une meilleure résolution, pour les communes
qu'on a déjà vectorisées. Voire plusieurs versions selon la résolution
demandée, et adaptée à certaines échelles de rendu.

Ce genre de traitement de simplification (san extension par un buffer)
a été fait pour les pays et pour les lignes de côtes (avec le
paramètre de distance minimale entre les noeuds sucessifs à 300 mètres
il me semble, et sans non plus tenir compte de la concavité des angles
simplifiables).

Le critère de concavité est pourtant assez simple à calculer: dès
qu'on a fermé tous les anneaux et qu'on les a orienté de sorte que le
côté interne est toujours à gauche (dans la direction du parcours du
polygone), un sommet formant un angle qui tourne à gauche n'est pas
éliminable (sauf en augmentant  encore la longueur de buffer pour le
déplacer encore plus loin), alors qu'un sommet qui forme un angle qui
tourne à droite est candidat à l'élimination directe.

Un autre paramètre concerne l'extension maximale des zones de buffers
: celui des longueurs de biseaux. Ce paramètre existe dans tous les
rendus vectoriels classiques (SVG ou Postscript par exemple), et est
déterminé par le rapport maximum devant subsister entre la longueur du
biseau (distance entre le sommet réel du polygone d'origine et le
sommet déplacé par le buffer sur la pointe), et sa largeur (distance
entre les points externes des rectangles formés orthogonalement de
part et d'autre de chaque segment su polygone d'origine).
Classiquement ce paramètre de seuil vaut 4 par défaut.

Quand le rapport calculé pour former une jonction par un biseau
dépasse ce paramètre de seuil, au lieu d'inclure ce biseau en entier
(dont la forme est constituée de deux triangles isocèles formant un
losange isocèle, et dont l'arête commune est le segment joignant les
angles droits des rectangles de buffer de part et d'autre de chacun
des segments successifs du polygone d'origine), on élimine du losange
le triangle isocèle le plus pointu pour ne garder que le triangle
isocèle le plus plat (qui joint les angles droits des deux rectangles
de buffer, et le sommet du polygone d'origine) : cela génère alors 2
sommets (aux angles droits des rectangles à joindre) au lieu d'un seul
sur le polygone d'origine.

Ce traitement des biseaux doit se faire lors de l'étape de formation
des buffers, avant celle de simplification des polygones pour réduire
leur résolution (cette seconde étape continuera alors à utiliser le
critère de concavité, c'est à dire le "tourne à gauche" ou "tourne à
droite" quand le polygone est orienté avec un côté interne à gauche et
un côté externe à droite, pour savoir quels sommets sont à garder
absolument pour ne pas trop tronquer les pointes, même quand elles ont
été jointes par un triangle et non un losange de biseau).

Tout cela est un traitement purement mathématique avec des critères simples :

- une distance (largeur d'extension externe des buffers)

- le rapport de seuil d'extension par biseau (typiquement 4), utilisé
lors de la première étape de création des buffers.

- une autre distance (celle de la résolution demandée en fonction de
l'échelle pour la simplification, mais qui peut être égale à la
première)

- éventuellement un dernier paramètre limitant le nombre maximum de
sommets par polygone fermé (ce dernier traitement d'élimination de
sommets sur les segments les plus courts, ne peut avoir lieu qu'après
les deux premiers, il risque de tronquer des pointes qui auraient du
être gardées et de créer des artéfacts comme ceux qu'on observe sur
Layers où deux faces théoriquement parfaitement limitrophes dans leur
définition et dans la base OSM ne le sont plus et laissent des
superpositions et interstices entre ces faces)

Le 17 octobre 2012 11:32, Christian Quest  a écrit :
> Sauf si on en fait une version simplifiée, mais quand même moins que
> le GEOFLA, un peu comme ce que j'avais fait en SVG pour les
> départements et régions:
> http://openstreetmap.fr/contours-departements-et-regions
>
> Le 17 octobre 2012 09:55, Nicolas Dumoulin
>  a écrit :
>>
>> Et aussi, parce que les contours gratuits de l'IGN sont directement
>> téléchargeable en .shp et que finalement la précision est suffisante et 
>> évite de
>> coûter trop cher à traiter.
>> Si demain, je devais afficher des contours de plusieurs communes en 
>> vectoriel,
>> je ne prendrais surtout pas les contours bruts d'OSM, même si on les avait
>> tous.
>>
>
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
> ___
> 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] lieux-dits

2012-10-17 Par sujet Mikaël Cordon
Moi aussi, j’en ai placé un bon paquet dans la région poitevine,
d’ailleurs. Ils viennent en grande majorité du cadastre.

Cordialement,
--
Mikaël Cordon (mickey86)

Le 16 octobre 2012 22:02, Cyrille Giquello  a écrit :

> Le 16 octobre 2012 21:18, Eric SIBERT  a écrit :
> >> 4) Concernant le tag place=locality, je l'utilise pour mapper les
> >> lieux-dits par exemple "Vallée de machin-chose", "Plaine des bidules".
> >> Des lieux inhabités mais disposant tout de même de leur propre nom.
> >> Est-ce que ce tag convient ?
>
> Je fait de même.
>
> > Moi, ça me convient.
> >
> > Éric
>
>
> --
> 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] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Ab_fab
Le script 
polybuffer.pydisponible
sur le dépôt svn proposé par Sylvain utilise Postgis et ses
fonctions ST_BUFFER / ST_SIMPLIFY.

Je vais déjà regarder si j'arrive à quelque chose en utilisant les outils
proposés "out of the box"

Le "petit service en ligne" serait une belle finalité, avec en entrée une
référence INSEE, ou déjà le N° de la relation et deux trois paramètres pour
définir la marge autour de la limite osm et un ordre de grandeur pour le
nombre de points du polygone simplifié.

[1] http://svn.openstreetmap.org/applications/utils/osm-extract/polygons/

Le 17 octobre 2012 10:47, Vincent de Chateau-Thierry  a
écrit :

> Bonjour,
>
> Postgis n'est pas nécessaire, mais si Postgis tu as, alors ça peut aider
> :-)
> Ce qu'il faut plus généralement c'est un outil qui implémente une fonction
> de type
> "buffer", "zone tampon" en français. Avec Postgis, c'est ici :
> http://www.postgis.org/documentation/manual-2.0/ST_Buffer.html
> Ça permet de dilater une surface. Le travers à éviter, c'est de générer
> trop de points,
> la fonction de Postgis permet de jouer là-dessus avec le paramètre
> num_seg_quarter_circle.
> Deuxième étape, ils'agit de sortie la géométrie créée au format poly
> d'Osmosis. Au pire
> pour un (seul) poly ça se bidouille à la main, au mieux une fonction écrit
> ça proprement.
> Je ne connais pas d'outil générant ce format directement mais rien de
> sorcier si besoin,
> ça reste une liste de coordonnées à écrire selon un formalisme convenu.
> Bref, pour recoller à ta question, on pourrait imaginer un petit service
> en ligne où on
> soumet l'identifiant INSEE d'une localité et où en retour on récupère un
> fichier .poly.
>
> 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
>



-- 
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] [forum-osm-fr] JOSM : bâtiment à plusieurs "fonctions"

2012-10-17 Par sujet forum
Le message suivant de :
##
Bonjour,



Juste une petite question bête : j'essai de compléter la carte de ma commune 
avec JOSM, et je me demande comment faire lorsqu'un batiment a plusieurs 
"fonctions".



Par exemple, la bibliothèque est située sous la mairie.



Je met par exemple la valeur[i] library[/i] à la clef [i]amenity[/i] du 
bâtiment, mais ensuite je ne peux pas rajouter un [i]amenity=townhall[/i].



Comment procéder proprement ?



Merci d'avance...

a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleurs réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum->liste
peuvent être posées à sylvainaletuffe.org

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


Re: [OSM-talk-fr] Quelqu'un de dispo pour l'Ubuntu Party 17-18 novembre à Paris...

2012-10-17 Par sujet didier2020
Le mercredi 17 octobre 2012 à 10:45 +0200, Christian Quest a écrit : 
> Je peux te préparer des cartes de visite, pas de souci de ce côté.
> Il doit bien rester des prospectus, mais imprimer quelques osmecum
> peut aussi être utile.
> Une mini cartopartie autour de la cité des sciences pourrait aussi
> être proposée si  vous vous sentez d'attaque ?
ca me va, si tu me pretes ton parapluie :) 
> 
> Le 16 octobre 2012 15:36, Marc SIBERT  a écrit :
> > Candidat !
> > pour l'un ou exclusif l'autre des deux jours. A préciser suivant dispo
> > familiale. Accepte évidemment le soutient d'autres contributeurs / habitués
> > du projet.
> >
> > Faudrait aussi préparer des docs à emporter : cartes de visite, cartes de
> > présentation du projet : ni y a-t-il pas un groupe de travail pour ça à
> > l'asso-fr ?
> >
> > A+
> >
> > Marc
> >
> > Le 16 octobre 2012 01:18, Christian Quest  a écrit
> > :
> >
> >> Il faudrait animer un exposé de 30-35 minutes pour
> >> présenter le projet, suivi (après une pause) d'un atelier pratique de 2h
> >> sur comment contribuer...
> >>
> >> C'est à la Cité des Sciences comme d'habitude.
> >>
> >> --
> >> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
> >>
> >
> >
> > ___
> > 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] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Philippe Verdy
Je pense qu'il cherche une méthode mathématique automatisée calculant
un polygone dérivé du polygone des frontières, qui est étendu en
utilisant une largeur de "buffer" à l'extérieur de cette frontière
(par exemple 100 mètres pour éviter les complications des lignes de
côtes et pour inclure dedans les petits estuaires et les entrées de
ports "fermées" par des digues ainsi qu'une toute petite partie de la
zone maritime le long de la ligne de côtes pour y attacher les rochers
et îlots côtiers sans générer trop d'exclaves).

Avec ensuite une étape de simplification utilisant le même paramètre
de longueur pour étendre encore un peu la zone de buffer dans les
parties concaves du polygone (pas les partie convexes sinon on risque
d'éliminer des "pointes" qui font partie de la zone à inclure),
partout où deux segments consécutifs du multipolygone obtenu peuvent
n'en former qu'un seul d'une longueur restant inférieure au paramètre
de largeur de buffer (il restera toutefois des exclaves possibles si
elles sont plus éloignées entre elles que la taille de buffer).

Ce genre de calcul sera plus précis à faire par traitement
mathématique automatisé qu'à la main en traçant sur un fond de carte
Mapnik dérivé des polygones de la base OSM...

Il se trouve que ces deux traitements (extension de zone buffer, et
simplification des tracés) existent déjà justement pour réaliser des
rendus et font partie des algorithmes de base des systèmes de
traitement GIS (par exemple pour étendre le tracé filaire d'une
rivière ou d'une route en une surface remplissable).

En revanche je ne sais pas trop si le critère de concavité des angles,
tenant compte du côté interne ou externe de la frontière pour
l'inclusion dans la surface des petits "creux" sur la frontière, tout
en ne tronquant pas les "pointes") est implémenté quelque part pour
l'instant (cela ne semble pas être le cas quand on regarde par exemple
ce que produit Layers dans ses "simplifications" de tracés (car les
frontières "simplifiées" de surfaces adjascentes ne se superposent pas
correctement et laissent apparaître des interstices et des
superpositions entre les faces qui sont parfaitement limitrophes dans
la base OSM, car décrites par des ways communs).

Le 17 octobre 2012 10:47, Vincent de Chateau-Thierry
 a écrit :
> Bonjour,
>
>> De : "Ab_fab"
>>
>> Je suis curieux de savoir s'il serait possible et pas trop compliqué
>> d'obtenir un contour **enveloppant** une limite administrative ou
>> politique.
>> Par exemple en le générant sous forme de fichier .poly, en partant des
>> données osm de la limite en question.
>>
>> Cela pourrait être utile pour faire des extractions de données plus fines
>> qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
>> l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a fait
>> Jocelyn avec la France métropolitaine, mais pour des zones plus restreintes
>>
>> Est-ce qu'une base PostGIS est nécessaire ? Est-ce que JOSM propose ce
>> genre de fonction ?

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


Re: [OSM-talk-fr] QueChoisir ? OSM, bien sûr !

2012-10-17 Par sujet Christian Quest
Sauf si on en fait une version simplifiée, mais quand même moins que
le GEOFLA, un peu comme ce que j'avais fait en SVG pour les
départements et régions:
http://openstreetmap.fr/contours-departements-et-regions

Le 17 octobre 2012 09:55, Nicolas Dumoulin
 a écrit :
>
> Et aussi, parce que les contours gratuits de l'IGN sont directement
> téléchargeable en .shp et que finalement la précision est suffisante et évite 
> de
> coûter trop cher à traiter.
> Si demain, je devais afficher des contours de plusieurs communes en vectoriel,
> je ne prendrais surtout pas les contours bruts d'OSM, même si on les avait
> tous.
>


-- 
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] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Ab_fab
Merci à tous pour vos réponses, je vais regarder ça !

Pour répondre à Francescu, un cas pratique.
Si je veux me limiter au département du Nord (59) et que j'utilise une
bounding box, je vais devoir définir une zone comme celle-ci :
http://openstreetmap.org/?minlon=1.88&minlat=49.96&maxlon=4.25&maxlat=51.11&box=yes
On arrive presque jusqu'à Bruxelles, on englobe Gand et une partie non
négligeable du Pas de Calais. Le même genre de chose peut arriver si l'on
travaille sur des communes, des intercommunalités, d'où ma question

On dispose de contours très fins des entités administratives et autres,
donc cela peut servir à optimiser la taille des extraits de données que
l'on va utiliser.

Le 17 octobre 2012 10:23, Francescu GAROBY  a écrit :

> Sans avoir de réponses précises à te donner, pourquoi dis-tu "des
> extractions de données plus fines qu'avec une bbox" ? Quel est le problème
> avec une bbox ?
> À la limite, je te dirais qu'il suffirait de générer les coordonnées de la
> bbox, à partir des coordonnées de la limite administrative concernée (le
> point le plus au nord pour le bord haut de la bbox, celui le plus à l'est
> pour le bord droit, ...), non ? Quitte, éventuellement, à rajouter une
> petite marge, pour avoir une vue des "alentours".
>
> Francescu
>
> Le 17 octobre 2012 10:19, Ab_fab  a écrit :
>
>> Bonjour,
>>
>> Je suis curieux de savoir s'il serait possible et pas trop compliqué
>> d'obtenir un contour **enveloppant** une limite administrative ou
>> politique.
>> Par exemple en le générant sous forme de fichier .poly, en partant des
>> données osm de la limite en question.
>>
>> Cela pourrait être utile pour faire des extractions de données plus fines
>> qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
>> l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a fait
>> Jocelyn avec la France métropolitaine, mais pour des zones plus restreintes
>>
>> Est-ce qu'une base PostGIS est nécessaire  ? Est-ce que JOSM propose ce
>> genre de fonction ?
>>
>>
>> --
>> 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
>>
>>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
>
> ___
> 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] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Sylvain Maillard
Bonjour,

je ne peux que recommander d'aller faire un tour sur le serveur svn dans le
dossier osm-extract dédié aux polygones:
http://svn.openstreetmap.org/applications/utils/osm-extract/polygons/
il y a quelques outils en perl ou python qui font ça très bien ;)

- conversion format osm vers poly,
- buffer sur le poly
- simplification de poly
- extraction des données du planet depuis ce polygone

tout est là en fait, il resterait juste à automatiser un peu si le travail
doit être fait sur plusieurs polygones ;)


Sylvain


Le 17 octobre 2012 10:59, didier2020  a écrit :

> Le mercredi 17 octobre 2012 à 10:19 +0200, Ab_fab a écrit :
> > Bonjour,
> >
> >
> > Je suis curieux de savoir s'il serait possible et pas trop compliqué
> > d'obtenir un contour **enveloppant** une limite administrative ou
> > politique.
> > Par exemple en le générant sous forme de fichier .poly, en partant des
> > données osm de la limite en question.
>
> c'est ici:
> option -m, --osmosispolygon: outfile for osmosis boundary polygon
>
> https://github.com/werner2101/python-osm/blob/master/doc/index.html
>
> > Cela pourrait être utile pour faire des extractions de données plus
> > fines qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
> > l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a
> > fait Jocelyn avec la France métropolitaine, mais pour des zones plus
> > restreintes
> >
> >
> > Est-ce qu'une base PostGIS est nécessaire  ? Est-ce que JOSM propose
> > ce genre de fonction ?
> >
> >
> >
> >
> > --
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet didier2020
Le mercredi 17 octobre 2012 à 10:19 +0200, Ab_fab a écrit :
> Bonjour,
> 
> 
> Je suis curieux de savoir s'il serait possible et pas trop compliqué
> d'obtenir un contour **enveloppant** une limite administrative ou
> politique. 
> Par exemple en le générant sous forme de fichier .poly, en partant des
> données osm de la limite en question.

c'est ici: 
option -m, --osmosispolygon: outfile for osmosis boundary polygon

https://github.com/werner2101/python-osm/blob/master/doc/index.html

> Cela pourrait être utile pour faire des extractions de données plus
> fines qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
> l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a
> fait Jocelyn avec la France métropolitaine, mais pour des zones plus
> restreintes
> 
> 
> Est-ce qu'une base PostGIS est nécessaire  ? Est-ce que JOSM propose
> ce genre de fonction ?
> 
> 
> 
> 
> -- 
> 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]  Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Vincent de Chateau-Thierry
Bonjour,

> De : "Ab_fab" 
> 
> Je suis curieux de savoir s'il serait possible et pas trop compliqué
> d'obtenir un contour **enveloppant** une limite administrative ou
> politique.
> Par exemple en le générant sous forme de fichier .poly, en partant des
> données osm de la limite en question.
> 
> Cela pourrait être utile pour faire des extractions de données plus fines
> qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
> l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a fait
> Jocelyn avec la France métropolitaine, mais pour des zones plus restreintes
> 
> Est-ce qu'une base PostGIS est nécessaire ? Est-ce que JOSM propose ce
> genre de fonction ?
> 

Postgis n'est pas nécessaire, mais si Postgis tu as, alors ça peut aider :-)
Ce qu'il faut plus généralement c'est un outil qui implémente une fonction de 
type
"buffer", "zone tampon" en français. Avec Postgis, c'est ici :
http://www.postgis.org/documentation/manual-2.0/ST_Buffer.html
Ça permet de dilater une surface. Le travers à éviter, c'est de générer trop de 
points,
la fonction de Postgis permet de jouer là-dessus avec le paramètre
num_seg_quarter_circle.
Deuxième étape, ils'agit de sortie la géométrie créée au format poly d'Osmosis. 
Au pire
pour un (seul) poly ça se bidouille à la main, au mieux une fonction écrit ça 
proprement.
Je ne connais pas d'outil générant ce format directement mais rien de sorcier 
si besoin,
ça reste une liste de coordonnées à écrire selon un formalisme convenu.
Bref, pour recoller à ta question, on pourrait imaginer un petit service en 
ligne où on
soumet l'identifiant INSEE d'une localité et où en retour on récupère un 
fichier .poly.

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] Quelqu'un de dispo pour l'Ubuntu Party 17-18 novembre à Paris...

2012-10-17 Par sujet Christian Quest
Je peux te préparer des cartes de visite, pas de souci de ce côté.
Il doit bien rester des prospectus, mais imprimer quelques osmecum
peut aussi être utile.
Une mini cartopartie autour de la cité des sciences pourrait aussi
être proposée si  vous vous sentez d'attaque ?

Le 16 octobre 2012 15:36, Marc SIBERT  a écrit :
> Candidat !
> pour l'un ou exclusif l'autre des deux jours. A préciser suivant dispo
> familiale. Accepte évidemment le soutient d'autres contributeurs / habitués
> du projet.
>
> Faudrait aussi préparer des docs à emporter : cartes de visite, cartes de
> présentation du projet : ni y a-t-il pas un groupe de travail pour ça à
> l'asso-fr ?
>
> A+
>
> Marc
>
> Le 16 octobre 2012 01:18, Christian Quest  a écrit
> :
>
>> Il faudrait animer un exposé de 30-35 minutes pour
>> présenter le projet, suivi (après une pause) d'un atelier pratique de 2h
>> sur comment contribuer...
>>
>> C'est à la Cité des Sciences comme d'habitude.
>>
>> --
>> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
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] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Francescu GAROBY
Sans avoir de réponses précises à te donner, pourquoi dis-tu "des
extractions de données plus fines qu'avec une bbox" ? Quel est le problème
avec une bbox ?
À la limite, je te dirais qu'il suffirait de générer les coordonnées de la
bbox, à partir des coordonnées de la limite administrative concernée (le
point le plus au nord pour le bord haut de la bbox, celui le plus à l'est
pour le bord droit, ...), non ? Quitte, éventuellement, à rajouter une
petite marge, pour avoir une vue des "alentours".

Francescu

Le 17 octobre 2012 10:19, Ab_fab  a écrit :

> Bonjour,
>
> Je suis curieux de savoir s'il serait possible et pas trop compliqué
> d'obtenir un contour **enveloppant** une limite administrative ou
> politique.
> Par exemple en le générant sous forme de fichier .poly, en partant des
> données osm de la limite en question.
>
> Cela pourrait être utile pour faire des extractions de données plus fines
> qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
> l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a fait
> Jocelyn avec la France métropolitaine, mais pour des zones plus restreintes
>
> Est-ce qu'une base PostGIS est nécessaire  ? Est-ce que JOSM propose ce
> genre de fonction ?
>
>
> --
> 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
>
>


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


[OSM-talk-fr] Contours simplifiés englobant une limite administrative / politique

2012-10-17 Par sujet Ab_fab
Bonjour,

Je suis curieux de savoir s'il serait possible et pas trop compliqué
d'obtenir un contour **enveloppant** une limite administrative ou
politique.
Par exemple en le générant sous forme de fichier .poly, en partant des
données osm de la limite en question.

Cela pourrait être utile pour faire des extractions de données plus fines
qu'avec une bbox, tout en étant sûr d'avoir toutes les données à
l'intérieur de la zone qui nous intéresse. L'équivalent de ce qu'a fait
Jocelyn avec la France métropolitaine, mais pour des zones plus restreintes

Est-ce qu'une base PostGIS est nécessaire  ? Est-ce que JOSM propose ce
genre de fonction ?


-- 
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] QueChoisir ? OSM, bien sûr !

2012-10-17 Par sujet Nicolas Dumoulin
Le mardi 16 octobre 2012 21:24:26 Philippe Verdy a écrit :
> Je note que leur carte s'appuie non pas sur les frontières de communes
> OSM mais sur celles à basse résolution de l'INSEE (qu'on a choisi de
> ne pas "importer" ne serait-ce que pour avoir des tracés approchants
> en attendant de les renumériser et les intégrer une à une plus
> précisément avec le cadastre ou d'autres sources, de façon
> incrémentale comme dans la plupart des autres pays).
> 
> Certainement parce qu'il manque encore près de 6000 communes dans OSM
> (une sur 6) et que leurs frontières sont encore instables dans OSM.

Et aussi, parce que les contours gratuits de l'IGN sont directement 
téléchargeable en .shp et que finalement la précision est suffisante et évite 
de 
coûter trop cher à traiter.
Si demain, je devais afficher des contours de plusieurs communes en vectoriel, 
je ne prendrais surtout pas les contours bruts d'OSM, même si on les avait 
tous.

Cordialement,

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

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


Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN

2012-10-17 Par sujet Sylvain Maillard
Le 17 octobre 2012 00:04, Balaitous  a écrit :

> Les essais de reconnaissance automatique que j'ai fait (huggin) n'ont
> pas été concluants, il n'y a rien qui ressemble plus a un toit qu'un
> autre toit, et les problèmes de perspective sont très important (en
> limite de photo, la prise de vue est effectuée avec un angle de 45°)
>
> C'est surtout au niveau GUI qu'on peut rendre ce travail moins
> fastidieux.
>
> Pour l'instant le programme est un peu en sommeil, mais je compte m'y
> remettre cet hivers. Je suis preneur de toute bonne idée.
>

 Salut,

pour ce qui est du calage des image, c'est quelque chose de très fréquent
en télé-détection et il y a un certain nombre d'outils libres qui font ça.
Tu peux aller regarder du côté de GRASS, il y a 2 extensions qui font des
choses très intéressantes:
- i.point.auto (http://grass.osgeo.org/wiki/AddOns_/_GRASS_6#i.points.auto)
qui recherche automatiquement des points de correspondance entre 2 images
- i.linespoints et i.homography (
http://grass.osgeo.org/wiki/AddOns_/_GRASS_6#i.homography) qui permettent
d'utiliser également des lignes pour recaler l'image

il faudra que je fouille un peu, je suis sur d'avoir vu passer également
une extension pour plaquer une photo oblique sur un mnt, mais je n'arrive
plus à me souvenir du nom ...

la prise en main peut sembler compliquée, mais une fois qu'on a compris les
principes de base tout devient beaucoup plus simple, et on peut même tout
scripter en python ;)

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


Re: [OSM-talk-fr] Motorroad en France?

2012-10-17 Par sujet Arnaud CORBET
Cette ancienne convention ne me semble pas devoir être modifiée mais amendée, 
le trunk décrivant la réalité d'une voie physiquement à chaussées séparées, et 
le tag "highway=motorroad" décrivant l'espace administratif situé entre le 
panneau C107 et le C108 que j'ai déjà vu apposé sur des section de routes à 2 
voies (de mémoire la déviation de St Dizier, stricte 2 voies limitée à 90, a un 
C107 à l'entrée), espace dans lequel quelque soit la nature physique de la 
chaussée des restrictions de circulation s'appliquent.






 De : Christian Rogel 
À : Discussions sur OSM en français  
Envoyé le : Mercredi 17 octobre 2012 0h53
Objet : [OSM-talk-fr] Motorroad en France?
 



Le 16 oct. 2012 à 21:42, Pierre-Alain Dorange a écrit :

>Trunk indique une voie avec terre-plein séparant les 2 sens de
>circulation (utilisation de oneway=yes), c'est plus descriptif. De plus
>trunk est souvent avec des restrictions de circulation (vitesse mini,
>interdiction aux vélos...).
>
>Voir les conseils du wiki:FR 
>
>

C'est un choix ancien fait par la communauté française avant que ne soit 
introduit 
le tag "highway=motorroad" qui dans beaucoup de pays désigne un concept analogue
à nos voies express, au moins sur un type de critère assez courant, la 
réservation 
aux véhicules à 4 roues et aux motocycles.

http://wiki.openstreetmap.org/wiki/Key:motorroad

Bizarrement, la page du wiki anglophone sur les "motorroad" ne parle de rendu 
que pour
le défunt Osmarender, et pas pour Mapnik.

Le tag a été introduit en 2008 et en avril 2009, Pieren a indiqué, sur la page 
dédiée,  qu'il 
ne s'appliquait pas à la France.
Celle-ci n'a pourtant pas des classifications de routes fondamentalement 
différentes de 
celles de ses voisins.

Dans beaucoup de pays, "trunk" est affecté aux itinéraires interrégionaux sans 
préjuger de leur aspect physique ou des restrictions à certains véhicules.

J'ai lancé le débat sur la définition des "trunks" en demandant que les voies 
express soient 
assimilées aux autoroutes ("highway=motorway", d'autant que certaines sont en 
cours de 
requalification avec des aménagements de type autoroute.


Il me semble, maintenant,  que nos voies express devraient être finalement des 
"motorroad",
exactement comme les Espagnols mettent "motorway" pour autopista et 
"mottorroad" pour autovia.


Une proposition non suivie de vote 
(http://wiki.openstreetmap.org/wiki/Proposed_features/Expressway_indication)
tendait à introduire un tage "expressway=yes"" pour toutes les voies qui sont 
similaires aux
autoroutes au moins  en ce qui concerne la non-connexion directe avec le réseau 
standard 
("conventional") sans que l'on préjuge du tag "highway" qui pourrait donc être 
"motorroad", "trunk"
ou "primary".

Ici, "expressway" (terme plutôt américain) semble synonyme de voie rapide et 
non de voie express.


Christian Rogel
___
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] Initiation OSM

2012-10-17 Par sujet Romain MEHUT
Bonjour,

Le 16 octobre 2012 19:04, Dominique Lachgar
a écrit :

>
> Je fais partie de Vélocité Angoulême et notre objectif est de pouvoir à
> terme se servir d'OSM pour y reporter les voies cyclables, les itinéraires
> futés, les aménagements...
>

Tu trouveras ici
http://wiki.openstreetmap.org/wiki/WikiProject_France/Villes/Itin%C3%A9raires_cyclablesune
liste de sites utilisant OSM pour un usage à vélo. J'ajoute également
http://www.apicy.fr/carte/contribuer-a-la-carte &
http://www.apicy.fr/carte/realiser-une-carte-similaire qui décrivent les
éléments à cartographier pour le vélo et comment réaliser soi-même une
carte des aménagements cyclables.

Tiens nous au courant des avancées de Vélocité Angoulème...

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


Re: [OSM-talk-fr] Avez-vous utilisé des données de la ville de Toulouse ?

2012-10-17 Par sujet Romain MEHUT
Le 16 octobre 2012 22:53, Sébastien Dinot  a écrit
:

>
> Merci Romain pour ce lien fort intéressant que j'avais complètement zappé
> alors que je connais son auteur principal !
>

De rien ;)
A noter qu'il reste un grand nombre d'écoles à intégrer. Les données
peuvent être confrontées avec celles de data.gouv.fr cf.
http://nomino.comptoir.net/etablissements/

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