Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Philippe Verdy]

Le 6 mars 2013 20:18, Christian Quest  a écrit :
> 1) le code d'osm2pgsql c'est pas de la théorie, c'est du concret, qui
> tourne sur les serveurs.
> Ce code redécoupe clairement les way composant une relation boundary
> en n objets dans planet_osm_line et planet_osm_roads
>
> 2) la feuille de style Mapnik utilise planet_osm_line et
> planet_osm_roads pour tracer les limites admin, donc les redécoupages
> des ways membres des relations et c'est bien donc de là que provient
> le admin_level.
>
> Ce sont tes affirmations non étayées qui sont dans la théorie... et l'erreur.
> Vu que le jour où tu reconnaitra t'être trompé n'est sûrement pas pour
> aujourd'hui, je passe à autre chose.

Vu que tu n'as rien prouvé du tout par tes affirmations mais juste
énoncé une théorie et que les bogues sont bel et bien visibles, je te
laisse à ta conclusion contredite par les résultats obtenus. Tu n'as
strictement rien prouvé, je ne juge que sur les résultats obtenus, pas
sur un morceau de commentaire dans un code source.

Mapnik a des bigues de rendus un peu partout, facile à trouver, et ce
ne sera pas le premier.

> Dernier message pour moi car perdre mon temps à corriger tes
> appoximations me lasse... mais je persiste à les corriger pour éviter
> que trop de monde ne reste sur celles-ci.

Quelle impolitesse. Même si la théorie dit que 2 et 2 font 4, et qu'on
obtient 3, tu vas conclure que la théorie est juste mais même pas te
poser la question si les données traitées sont bien 2 et 2 là où le
code est sensé agir parce qu'il calcule une addition. On voit pourtant
3, et on sait que les données sources sont justement 2 et 2.

Quelque chose t'échappe (à moi aussi d'ailleurs et je n'ais
certainement pas envie de regarder et comprendre pourquoi le code rend
ce résultat, tout bonnement parce que ce n'est peut-être même pas ce
code qui est concerné ici dans le résultat obtenu). Tu fais juste
confiance à la théorie et refuse de regarder les résultats tels qu'ils
sont.

Je ne reproche rien aux concepteurs de ce programme, tous les
programmes ont des bogues, des cas particuliers oubliés et non traités
ou des conditions initiales non clairement spécifiées et oubliées. Le
code est assez complexe pour en avoir des tas. Mais toi tu regarde à
un endroit microscopique du code pour conclure que ce code est correct
sans même te demander si c'est à cet endroit qu'est l'erreur.

Des bigues de rendus il y en a pour différentes raisons, y compris
diverses sources de désynchronisations des données entre ce qui est
dans la base et ce qui est dans les tables de cache internes. Le
problème n'est pas là : si on a des données contradictoires dans la
base, la façon dont se débrouille les algos pour lever les ambiguités
reste seulement une heuristique qui va juste régler les cas les plus
courants.

Mais voilà, tu fais partie des personnes qui font une confiance
aveugle dans ce que produit un programme, sans doute parce que tu l'as
écrit toi-même et que tu penses que c'est déshonorant d'admettre que
ton bijou peut avoir des anomalies. Je me fiche totalement de savoir
comment fait le programme en interne, et en fait je ne devrais même
pas avoir à le savoir.

Pour évaluer un programme on regarde ses résultats, rien d'autre. Si
le résultat n'est pas celui attendu, on isole le problème en repérant
les cas qui ne marchent pas se lon quelques règles simples. Et on
commence par d'abord relever les contradictions dans les données
sources pour éviter de les mettre. Et c'est en procédant ainsi qu'on
arrive à isoler des problèmes en fait dans les données sourves, que
l'heuristique du programme ne parbient pas à isoler et corriger
lui-même. Et on voit que ces corrections aussitôt faite non seulement
résolvent le problème du résultat mais aussi clarifient les données
sources (il n'y a pas que Mapnik qui doivent interpréter les données,
les contributeurs aussi.

Je te laisse donc à ta théorie fumeuse, puisque tu lui fais une
confiance aveugle, moi je reste à ma méthode pratique qui est souvent
bien plus fiable et permet d'avancer (et surtout ne dépend pas de la
seule interprétation faite par Mapnik, mais peut aussi servir à
d'autres rendus, sans compter aussi que la version déployée peut aussi
être différente de celles qui est dans le code source).

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

[OSM-talk-fr] [forum-osm-fr] Cartopartie à Ercé-près-Liffré (35)

[forum]

Le message suivant de Gwentux:
##
bonjour



[url=http://gulliver.eu.org]Gulliver[/url], vous invite à participer à sa 
prochaine [b]cartopartie[/b] organisée à [b]Ercé-près-Liffré[/b] (au 
[url=http://www.openstreetmap.org/?mlat=48.2547&mlon=-1.5156&zoom=12&layers=Q]nord-est
 de Rennes[/url]), en collaboration avec le Groupe Multimédia et l’Association 
de randonneurs Les Rotes d’Ercé.



Date : le [b]samedi 23 mars 2013[/b] à partir de 14h

Lieu de rendez-vous : Le Relais des Cultures Place de la Mairie



Plus d'info sur notre site : 
[url]http://gulliver.eu.org/cartopartie_erce-pres-liffre[/url]



à bientôt !

a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=6&t=554
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 meilleures 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] Réunion AFIGEO/OGC à l'IGN

[Christian Quest]

Le 6 mars 2013 23:10, Pieren  a écrit :
> Merci pour les infos. Deux, trois petites remarques:
>
> 2013/3/6 Christian Quest :
>> Un grosse discussion sur les problèmes de mise à disposition de
>> données très volumineuses (par exemple les orthophotos).
>> Comment gérer ça ?
>
> Pour les gros volumes, on peut envisager de payer les frais de mise à
> disposition sur DVD/blueray par exemple (à condition de ne pas payer
> des tarifs prohibitifs comme à la DGFiP). Les ortho ne sont pas
> actualisées aussi fréquemment que ça.
>

Pour certains cas, nous avons toujours la possibilité de fournir un
disque dur pour y poser plus rapidement les fichier qu'en gravant des
DVD ou Bluray... et ça revient souvent moins cher. C'est ce qui est
prévu pour PACA.


>> Une question sur les calculs d'itinéraires piéton et la possibilité de
>> messages vocaux qui prennent en compte le genre des toponymes...
>
> Intéressant. On pourrait imaginer un tag additionnel pour les cas 
> particuliers.
>

name:gender[:lang] ?

>> Autre chose... le GEOFLA non simplifié. Ça peut s'acheter, avec une
>> licence compatible OSM...
>
> Dès que c'est dans OSM, c'est gratuit. Je voudrais bien voir une
> licence payante compatible ODbL...
>

J'en ai parlé pour l'anecdote... ;)


-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Réunion AFIGEO/OGC à l'IGN

[Jean-Claude Repetto]

On 06/03/2013 22:35, Christian Quest wrote:
> Nous étions (Gaël et moi) à l'IGN pour une réunion de l'Afigéo pour le
> groupe de travail opendata.

> Il faut qu'on vérifie par une confirmation écrite la possibilité
> d'utiliser les ortho IGN pour tracer par dessus, car il m'a encore été
> dit qu'on pouvait le faire.
> 

Ce serait une excellente nouvelle !


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

Re: [OSM-talk-fr] Réunion AFIGEO/OGC à l'IGN

[Pieren]

Merci pour les infos. Deux, trois petites remarques:

2013/3/6 Christian Quest :
> Un grosse discussion sur les problèmes de mise à disposition de
> données très volumineuses (par exemple les orthophotos).
> Comment gérer ça ?

Pour les gros volumes, on peut envisager de payer les frais de mise à
disposition sur DVD/blueray par exemple (à condition de ne pas payer
des tarifs prohibitifs comme à la DGFiP). Les ortho ne sont pas
actualisées aussi fréquemment que ça.

> Une question sur les calculs d'itinéraires piéton et la possibilité de
> messages vocaux qui prennent en compte le genre des toponymes...

Intéressant. On pourrait imaginer un tag additionnel pour les cas particuliers.

> Autre chose... le GEOFLA non simplifié. Ça peut s'acheter, avec une
> licence compatible OSM...

Dès que c'est dans OSM, c'est gratuit. Je voudrais bien voir une
licence payante compatible ODbL...

Pieren

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

[OSM-talk-fr] Réunion AFIGEO/OGC à l'IGN

[Christian Quest]

Nous étions (Gaël et moi) à l'IGN pour une réunion de l'Afigéo pour le
groupe de travail opendata.

Difficile de résumer une journée entière mais voici les grandes lignes.

Le matin, réunion avec les CRIGE, où l'on a abordé deux sujets:

a- utilisation d'OSM par les CRIGE, en particulier pour la réalisation
d'un fond de carte "neutre"

On y a donc parlé de mapnik, de tilemill et comparé l'évolution du
style "bright" de mapbox modifiée par Géopicardie et l'évolution du
style "osm" de mon côté.
Les buts sont bien sûr différents, mais nous avons déjà des expérience
à partager de part et d'autre.

On a aussi abordé les aspects techniques de génération et distribution
de tuiles, des volumes en jeu, de la mise à jour, de l'infrastructure
matérielle, etc.

b- les données dont disposent les CRIGE qui pourraient être mise à
disposition pour OSM

Le gros morceau ce sont souvent des orthophotos. Une grosse discussion
sur la façon de les mettre à disposition: via des services (WMS, TMS)
ou en fournissant les données brutes (fichiers .ecw/jpeg2000 voire
tiff) ? Nous avons indiqué que nous pouvons tirer partie de l'un comme
de l'autre.

Il y a assez peu de données vectorielles disponibles actuellement, car
peu ont été mises sous licence libre par les membres des CRIGE.
La principale toutefois est l'occupation des sols, avec une précision
meilleure que CLC (demi Ha).
Il y aurait un gros travail de conflation à faire, en croisant aussi
avec le registre parcellaire graphique pour les zones cultivées.

Cela nécessite une grosse analyse avant de se lancer dans un tel
projet, surtout pour ne pas perdre les améliorations de CLC qui ont
été faites à de très nombreux endroits.


L'après-midi, la réunion Afigéo sur l'opendata.

Premier sujet: définir des recommandations sur les données à
libérer... fixer un peu des priorités en quelque sorte.

Donc toute une discussion sur comment savoir ce qui intéresse "les
utilisateurs"... les compteurs de téléchargement ? un questionnaire à
diffuser ?

J'avoue ne pas être très chaud pour cette approche. L'opendata est
plutôt la "simple" mise à disposition de données existantes, sans
demander un travail particulier sur celles-ci. Faire un tri n'est donc
en principe nécessaire que pour éliminer les données non libérables
(problème de licence, problème de données personnelles, etc).

J'ai rappelé que les compteurs de téléchargement ne pouvaient donner
des infos que par rapport aux données disponibles... pas celle qui ne
sont pas (encore) en opendata.
Un développeur qui télécharge un jeu de données et fait une super
appli utilisée par des milliers de personnes compte pareil qu'un
curieux qui charge un fichier "pour voir" et n'en fera jamais rien.

Un grosse discussion sur les problèmes de mise à disposition de
données très volumineuses (par exemple les orthophotos).
Comment gérer ça ?


Ensuite, une présentation sur le web sémantique... j'en avais
tellement parlé à la précédente réunion ;)


Comme souvent les discussion "off" ont été riches, en particulier avec
2 personnes de l'IGN.
Une question sur les calculs d'itinéraires piéton et la possibilité de
messages vocaux qui prennent en compte le genre des toponymes...
donnée non présente dans OSM, car oui, il s'agit de faire du calcul
d'itinéraire piéton avec des données OSM. Donc on a parlé
d'OpenTripPlanner et aussi d'OSRM.
Pour ce qui est des masculin/féminin/neutre je pense qu'on peut en
gérer beaucoup de façon automatique, mais qu'effectivement pour
certains cas particuliers l'info a besoin d'être explicitée.

L'autre discussion c'est avec un des responsables
commerciaux/marketing qu'on croise assez souvent. On a parlé de
différence entre "gratuit" et "libre"... pour bien être clair: "la
prison j'y dors gratuitement, mais je ne suis pas libre"... ça
commence à rentrer ;)
Il faut qu'on vérifie par une confirmation écrite la possibilité
d'utiliser les ortho IGN pour tracer par dessus, car il m'a encore été
dit qu'on pouvait le faire.

Autre chose... le GEOFLA non simplifié. Ça peut s'acheter, avec une
licence compatible OSM... je demanderai bien un devis par curiosité,
juste pour les communes qui nous manque.

Dernier point, l'accès à la BDTOPO et au RGE dans le cadre d'une
recherche est possible. On pourrait ainsi faire une étude de
comparaison des données OSM/IGN, exhaustivité, précision, richesse des
détails. Il faut que ce soit dans un cadre universitaire... ça doit
pouvoir se trouver, non ?

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] source=inconnue

[DH]

Le 06/03/2013 15:33, Jo. a écrit :
Pour les cours d'eau, ce sont des éléments physique qui sont mouvant 
alors que les frontières sont fixée. On peut avoir la même logique 
avec les routes dont les autorité locale peuvent modifier le tracé 
sans respecter à la lettre les frontière.


Près de chez moi, un cours d'eau change doucement chaque année 
pourtant il est en plaine et le débit en hivers n'est pas très fort. 
J'avais par erreur modifier les frontières en suivant le cours d'eau 
mais le cadastre indiquai autre chose même si les écarts sont de 
quelques mètres, j'ai du tout séparer et réparer pendant une longue 
demie journée de perdue : http://osm.org/go/xVlCOin3O-


Pareil pour les routes et ponts avec un exemple passant au dessus 
d'une autoroute : http://osm.org/go/xVlmmAVBA--


Après *ce n'est qu'un conseil d'édition*, c'est simplement pour éviter 
de créer/propager une erreur. Séparer les éléments physique des 
éléments immatériel me semble conseillé pour éviter de nombreuses 
heures de correction.


Je suis preneur de la définition légale de la limite d'une commune. 
Genre article du Code des Collectivités Locales. Perso, je n'ai rien 
trouvé de convaincant, mais j'ai peut-être pas assez ou mal cherché.
Une indication : le cadastre ne définit pas les limites communales (ils 
seraient bien en peine puisque les limites de 2 cadastres adjacents ne 
sont pas toujours concordantes).
Enfin, OSM n'a pas vocation à être une base d'arbitrage des limites 
communales. Rappelez-vous : sans garanties. Mais on pourrait dire : OSM 
a raison, in fine, la limite entre les communes X et Y c'est bien la 
rivière Z, le chemin d'exploitation AA.
La parcelle 1 de la feuille 2 de la section 3 de la commune 4 est bien 
identifiée comme étant la limite de la commune 4 (selon le cadastre et 
donc, par dérivation des POS-PLU et autres documents réglementaires, 
etc.) et participe du faisceau de preuves des revendications 
territoriales de la commune. Il se pratique régulièrement des échanges 
de territoires entre communes (et cela change légalement la limite 
desdites communes car consignée dans le COG -Code Officiel Géographique- 
publié annuellement au JO). Nos arrangements et règles diverses n'auront 
aucune influence sur le COG.
Je veux dire que le flou légal du juridique ne peut pas être compensé 
par une confiance aveugle dans les données cadastrales quant aux limites 
communales et que, de surcroît, ce n'est pas de notre compétence 
d'interférer dans ce débat. Le jour où OSM sera utilisable (fiable ?), 
sur l'ensemble du territoire national (pas que métropole) aux échelles 
cadastrales, il sera temps de recauser de ce débat, avec l'IGN (qui 
entretemps aura fait la convergence cadastrale -graal des géomaticiens 
de la grande échelle- et libéré les limites communales de la BD 
Parcellaire ->marge suffisante ?).


Denis, ready for the rencontre avec M. DGPiP
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relation 'waterway'

[Francescu GAROBY]

En l'occurrence, il s'agit du Golo (relation fraîchement créée :
2805254),
et du lac de Calacuccia :
28890020,
dans lequel j'ai tracé une way au milieu :
208607756

Francescu


Le 6 mars 2013 20:33, Romain MEHUT  a écrit :

> Comme d'habitude, avec un exemple ce serai plus parlant ;)
>
> Merci.
>
> Romain
>
> Le 6 mars 2013 20:30, David Crochet  a écrit :
>
> Bonjour
>>
>> Le 06/03/2013 20:08, Francescu GAROBY a écrit :
>>
>>  Sauf que ledit fleuve passe par le lac de Calacuccia (retenue
>>> artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer
>>> dans la relation les ways en amont et en aval dudit lac, et donc créer une
>>> "coupure" ? Inclure le lac ? Dessiner un way au milieu du lac, allant du
>>> point d'entrée (amont) au point de sortie (aval) dudit lac ?
>>>
>>
>> Lorsque je rencontre une étendue d'eau sur le parcours d'un cours d'eau,
>> je trace au milieu de cette étendue d'eau un chemin correspondant au même
>> type de chemin que celui d'un cours d'eau. Ainsi cette étendue est un
>> élément tout comme un autre d'un cours d'eau
>>
>> Cordialement
>>
>> --
>> David Crochet
>>
>>
>>
>> __**_
>> 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
>
>


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

Re: [OSM-talk-fr] Relation 'waterway'

[David Crochet]

Bonjour

Le 06/03/2013 20:33, Romain MEHUT a écrit :

Comme d'habitude, avec un exemple ce serai plus parlant ;)



http://www.openstreetmap.org/?lat=48.59035&lon=-0.37134&zoom=17&layers=M

--
David Crochet


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

Re: [OSM-talk-fr] Relation 'waterway'

[Romain MEHUT]

Comme d'habitude, avec un exemple ce serai plus parlant ;)

Merci.

Romain

Le 6 mars 2013 20:30, David Crochet  a écrit :

> Bonjour
>
> Le 06/03/2013 20:08, Francescu GAROBY a écrit :
>
>  Sauf que ledit fleuve passe par le lac de Calacuccia (retenue
>> artificielle, mais cela a-t-il une importance ?). Dois-je donc déclarer
>> dans la relation les ways en amont et en aval dudit lac, et donc créer une
>> "coupure" ? Inclure le lac ? Dessiner un way au milieu du lac, allant du
>> point d'entrée (amont) au point de sortie (aval) dudit lac ?
>>
>
> Lorsque je rencontre une étendue d'eau sur le parcours d'un cours d'eau,
> je trace au milieu de cette étendue d'eau un chemin correspondant au même
> type de chemin que celui d'un cours d'eau. Ainsi cette étendue est un
> élément tout comme un autre d'un cours d'eau
>
> Cordialement
>
> --
> David Crochet
>
>
>
> __**_
> 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] Relation 'waterway'

[David Crochet]

Bonjour

Le 06/03/2013 20:08, Francescu GAROBY a écrit :
Sauf que ledit fleuve passe par le lac de Calacuccia (retenue 
artificielle, mais cela a-t-il une importance ?). Dois-je donc 
déclarer dans la relation les ways en amont et en aval dudit lac, et 
donc créer une "coupure" ? Inclure le lac ? Dessiner un way au milieu 
du lac, allant du point d'entrée (amont) au point de sortie (aval) 
dudit lac ?


Lorsque je rencontre une étendue d'eau sur le parcours d'un cours d'eau, 
je trace au milieu de cette étendue d'eau un chemin correspondant au 
même type de chemin que celui d'un cours d'eau. Ainsi cette étendue est 
un élément tout comme un autre d'un cours d'eau


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Eric SIBERT]

Je viens d'étudier les points de repère que j'ai pris dans la ville. 
J'en ai 19. J'ai calculé le décalage de Bing avec :


En X : 1.91 m (+/-0.57)
En Y : -1.76 m (+/-0.64)

Autant dire que c'est faible et que je recommande de ne pas appliquer de 
correction aux images Bing de Tulear.



Éric


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

Re: [OSM-talk-fr] Relation 'waterway'

[Francescu GAROBY]

Donc ma troisième proposition (qui est celle qui avait ma préférence), OK.

Francescu


Le 6 mars 2013 20:19, Christian Quest  a écrit :

> Dans ces cas, j'ai dessiné un way qui parcoure le lac, un peu comme si
> le lac était le riverbank de la rivière...
>
> Le 6 mars 2013 20:08, Francescu GAROBY  a écrit :
> > Bonsoir,
> > Suite à la discussion parlant (initialement) des bassins versants, j'ai
> > découvert l'outil de Sly, et je vois que la relation pour le Golu n'y est
> > pas !
> > En effet, il n'existe pas de relation mais seulement des ways...
> >
> > Sauf que ledit fleuve passe par le lac de Calacuccia (retenue
> artificielle,
> > mais cela a-t-il une importance ?). Dois-je donc déclarer dans la
> relation
> > les ways en amont et en aval dudit lac, et donc créer une "coupure" ?
> > Inclure le lac ? Dessiner un way au milieu du lac, allant du point
> d'entrée
> > (amont) au point de sortie (aval) dudit lac ?
> >
> > Francescu
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Synthèse du Week-end "SOTM-FR" à Lyon :
> http://openstreetmap.fr/synthese-sotmfr
>
> ___
> 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] Relation 'waterway'

[Christian Quest]

Dans ces cas, j'ai dessiné un way qui parcoure le lac, un peu comme si
le lac était le riverbank de la rivière...

Le 6 mars 2013 20:08, Francescu GAROBY  a écrit :
> Bonsoir,
> Suite à la discussion parlant (initialement) des bassins versants, j'ai
> découvert l'outil de Sly, et je vois que la relation pour le Golu n'y est
> pas !
> En effet, il n'existe pas de relation mais seulement des ways...
>
> Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle,
> mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation
> les ways en amont et en aval dudit lac, et donc créer une "coupure" ?
> Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée
> (amont) au point de sortie (aval) dudit lac ?
>
> Francescu
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Christian Quest]

1) le code d'osm2pgsql c'est pas de la théorie, c'est du concret, qui
tourne sur les serveurs.
Ce code redécoupe clairement les way composant une relation boundary
en n objets dans planet_osm_line et planet_osm_roads

2) la feuille de style Mapnik utilise planet_osm_line et
planet_osm_roads pour tracer les limites admin, donc les redécoupages
des ways membres des relations et c'est bien donc de là que provient
le admin_level.

Ce sont tes affirmations non étayées qui sont dans la théorie... et l'erreur.
Vu que le jour où tu reconnaitra t'être trompé n'est sûrement pas pour
aujourd'hui, je passe à autre chose.

Dernier message pour moi car perdre mon temps à corriger tes
appoximations me lasse... mais je persiste à les corriger pour éviter
que trop de monde ne reste sur celles-ci.

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Christian Quest]

Le rendu mapnik/osm2pgsql utilise bien les relations pour tracer les
limites administratives contrairement à ce qu'indique Philippe.

Tu peux mettre admin_level=2 sur le way de frontière, c'est assez
courant même si pas indispensable.

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] les POI de Mapnik

[Christian Quest]

Il faut regarder et le fichier .mss et le .mml c'est à dire là où sont
les requêtes SQL, car c'est là qu'on sélectionne dans un premier temps
les POI à rendre et ensuite on choisit comment ils sont rendus (dans
le .mss)... avec ou sans icône présente dans le dossier "symbols".


Le 6 mars 2013 18:29, Etienne Trimaille  a écrit :
> Bonjour Émilie,
>
> Est-ce que le répertoire des pictos mapnik convient ?
> http://svn.openstreetmap.org/applications/rendering/mapnik/symbols/
>
>
> Le 6 mars 2013 18:12, Ab_fab  a écrit :
>
>> Pour le rendu Mapnik du site principal openstreetmap.org, tu peux regarder
>> ici :
>> https://github.com/gravitystorm/openstreetmap-carto
>>
>> Et plus particulièrement ici :
>>
>> https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss
>>
>> https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-symbols.mss
>> (...)
>>
>> (sans garantie d'exhaustivité)
>>
>> Le 6 mars 2013 17:48, Emivi  a écrit :
>>
>>> Bonjour
>>> Existe t-il une liste des POI rendus par Mapnik ?
>>>
>>> Emilie (la bretonne)
>>>
>>> ___
>>> 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", Nadja
>>
>> ___
>> 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
>



-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

[OSM-talk-fr] Relation 'waterway'

[Francescu GAROBY]

Bonsoir,
Suite à la discussion parlant (initialement) des bassins versants, j'ai
découvert l'outil de Sly, et je vois que la relation pour le Golu n'y est
pas !
En effet, il n'existe pas de relation mais seulement des ways...

Sauf que ledit fleuve passe par le lac de Calacuccia (retenue artificielle,
mais cela a-t-il une importance ?). Dois-je donc déclarer dans la relation
les ways en amont et en aval dudit lac, et donc créer une "coupure" ?
Inclure le lac ? Dessiner un way au milieu du lac, allant du point d'entrée
(amont) au point de sortie (aval) dudit lac ?

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

Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Philippe Verdy]

C'est la théorie, dans la pratique cela ne marche pas (et cela
provient probablement de la requête initiale de sélection de données à
traiter). Pour un niveau de zoom données, le moteur de rendu ne charge
pas *tous* les objets contenus dans la zone. Il fait une préselection
pour ensuite aller chercher juste ce qui semble nécessaire pour
compléter le reste.

Et le rendu obtenu confirme que cette théorie ne marche pas (ou qu'il
y a un bogue dans le code, ce ne serait pas le premier, on a des tas
de cas où Mapnik ne tient pas compte de tout ce qui est réellement
dans la base, on doit l'aider un peu assez souvent, à commencer par
éviter de lui donner des données incorrectes dans les
dénormalisations, sinon ces données disparaissent du jeu de données
utilisées).

2013/3/6 Christian Quest :
> Un peu de lecture pour confirmer mes dires:
> http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/output-pgsql.c
>
> comme ce commentaire fort pertinent: "Linear features will end up in
> the line and roads tables (useful for admin boundaries)"

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

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Cédric Moro]

Bonjour,

Cette zone est parfaite puisqu'elle tient compte des grosses parties de la 
ville impactées et toujours sous les eaux à savoir Anketa et Mahavatse II. Si 
de plus, les autres zones sinistrées relevées par le SERTIT sont intégrées, ce 
serait mieux pour le terrain. Quant aux images SPOT/Pleiades, c'est super 
d'avoir le contact.
Crowdmap intègre OSM pas de problèmes. Mais il ne peut proposer en même temps 
d'afficher OSM avec GoogleMap Sattelites.
Le problème est que quand il affiche OSM, il ne propose plus la vue images 
statellites qui peut être importante pour se rendre compte de l'utilisationn du 
sol, surtout quand la carto n'est pas détaillée.
Ce que l'on peut faire par contre, c'est mettre une couche KMZ en bas de 
légende avec les infos OSM.
Dès que la carte OSM est très détaillée, on pourra la mettre en fond de carte 
par défaut sur crowdmap.

Nous avons un chat depuis samedi. Donnez moi votre compte et je vous y fais 
entrer. Voici mon compte skype @roomilissimo .

Merci de votre aide,

Cédric


> From: talk-fr-requ...@openstreetmap.org
> Subject: Lot Talk-fr, Vol 80, Parution 43
> To: talk-fr@openstreetmap.org
> Date: Wed, 6 Mar 2013 16:47:18 +
> 
> Envoyez vos messages pour la liste Talk-fr à
>   talk-fr@openstreetmap.org
> 
> Pour vous (dés)abonner par le web, consultez
>   http://lists.openstreetmap.org/listinfo/talk-fr
> 
> ou, par email, envoyez un message avec 'help' dans le corps ou dans le
> sujet à
>   talk-fr-requ...@openstreetmap.org
> 
> Vous pouvez contacter l'administrateur de la liste à l'adresse
>   talk-fr-ow...@openstreetmap.org
> 
> Si vous répondez, n'oubliez pas de changer l'objet du message afin
> qu'il soit plus spécifique que "Re: Contenu du digest de Talk-fr..."
> 
> 
> Thèmes du jour :
> 
>1. Re: Bassins versants (Ab_fab)
>2. Re: Bassins versants (Philippe Verdy)
>3. Re: Demande d'assistance cartographique sur le Cyclone Haruna
>   à Madagascar. (Pierre Béland)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 6 Mar 2013 17:40:06 +0100
> From: Ab_fab 
> To: Discussions sur OSM en français  
> Subject: Re: [OSM-talk-fr] Bassins versants
> Message-ID:
>   
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Il est possible d'attribuer dans la relation "waterway" :
> _ un rôle main_stream sur le(s) way(s) du bras que l'on définit comme
> principal,
> _ un rôle side_stream sur le(s) way(s) du/des bras que l'on détermine comme
> secondaire(s)
> 
> Ces règles sont plutôt récentes, et l'usage s'est répandu après que les
> principaux outils de suivi que l'on connait ont été développés (si ma
> mémoire est bonne).
> J'espère qu'un jour il y aura un "mashup" sympa de tous ces outils
> permettant d'avoir une bonne vision d'ensemble de l'avancement et des zones
> à améliorer.
> 
> Le 6 mars 2013 17:14, Marc SIBERT  a écrit :
> 
> > Ça doit être intéressant, mais c'est vraiment trop long (détaillé).
> > J'aimerais comprendre comment vous tagguez les bras multiples et //
> > tl;dr
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> 
> 
> -- 
> ab_fab <http://wiki.openstreetmap.org/wiki/User:Ab_fab>
> "Il n'y a pas de pas perdus", Nadja
> -- section suivante --
> Une pièce jointe HTML a été nettoyée...
> URL: 
> <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130306/1c096ef7/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Wed, 6 Mar 2013 17:43:41 +0100
> From: Philippe Verdy 
> To: Discussions sur OSM en français  
> Subject: Re: [OSM-talk-fr] Bassins versants
> Message-ID:
>   
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Le 6 mars 2013 17:29, Ab_fab  a écrit :
> > Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent
> > justement pas compte de ces rôles "side_stream" ou "main_stream". Cela
> > fausse et alourdit les résultats.
> 
> En quoi cela fausse les résultats ? Si tu ne fais pas de différence,
> la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler
> par endroits des longueurs 2 ou 3 fois.
> 
> Pourtant l'outil doit être capable de déterminer si parmi l'ensemble
> des chemins "main_stream" cela forme une ligne conti

Re: [OSM-talk-fr] Cartopartie des panneaux publicitaires à Paris - samedi 16 mars 2013

[Christian Quest]

C'est sur le site: https://openstreetmap.fr/2013-03-16-cartopartie-paris

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

Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Philippe Verdy]

Le 6 mars 2013 18:41, Stéphane MARTIN  a écrit :
> Salut,
>
> J'ai changé les ways constituant la frontière maritime en admin_level=2.
> Il semble qu'il y ait consensus !
>
> Par contre, arrivé aux ways constituant la frontière Guyane-Brésil, changer
> l'admin_level de 1 en 2 ne risque-t-il pas de faire doublon avec la relation
> frontière Guyane-Brésil qui inclut déjà admin_level=2 ?

Non aucun risque. c'est comme ça partout. mais cela permet d'attribuer
un rendu aux frontières justement parce qu'elles sont de plein de
types différents selon les relations qui les utilisent (et les moteurs
de rendus de carte ne chargent pas toutes les relations dépendantes
pour savoir comment afficher le trait, ils se contentent de lire les
attributs du chemin pour savoir s'il faut ou non l'afficher selon le
niveau de zoom sélectionné).

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

Re: [OSM-talk-fr] Bassins versants

[Philippe Verdy]

Le 6 mars 2013 18:09, Ab_fab  a écrit :
> Le 6 mars 2013 17:43, Philippe Verdy  a écrit :
>
>> Le 6 mars 2013 17:29, Ab_fab  a écrit :
>> > Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent
>> > justement pas compte de ces rôles "side_stream" ou "main_stream". Cela
>> > fausse et alourdit les résultats.
>>
>> En quoi cela fausse les résultats ? Si tu ne fais pas de différence,
>> la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler
>> par endroits des longueurs 2 ou 3 fois.
>
>
> Cela fausse les résultats en indiquant que le cours d'eau est en plusieurs
> segments (et donc implicitement qu'il y a des coupures), alors qu'en réalité
> tout est ok. Cela ne permet pas de mettre en évidence les cours d'eau pour
> lesquels il y a vraiment une amélioration à apporter.
>
> Voir la Durance, depuis l'outil de Sly : il indique trois tronçons, mais en
> pratique il y a juste un bras secondaire à Chateau-Arnoux - Saint Auban
> quand on consulte l'analyseur de relation
> http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html

Justement ce sont les outils d'analyse qui se trompent.

La Durance est correctement taguée avec un *unique* segment
"main_stream" de bout en bout et son bras parallèle est bien tagué en
side_stream (et listé après tous les autres segments main_stream
interconnectés). La liste des "tributary" est également parfaite.

>>
>> Pourtant l'outil doit être capable de déterminer si parmi l'ensemble
>> des chemins "main_stream" cela forme une ligne continue ou pas.
>> Ensuite s'il reste des segments, l'outil peut signaler que certains
>> devraient passer en "side_stream" pour former un unique chemin
>> "main_stream".
>
>
> Il devrait, oui, mais c'est justement pas le cas avec les outils dans leur
> état actuel.

Preuve s'il en est qu'on ne doit pas toujours prendre leurs prétendus
rapports comme des erreurs. Ce sont des insuffisances de ces outils,
mais pas du tout un problème de modélisation dans la base.

Et justement les rôles sont là pour confirmer qu'il n'y a pas
d'erreurs : pratiquement tous les cours d'eau ont des bras parallèles,
et un outil sensé faire le point sur les cours d'eau mais qui ne sait
pas prendre en compte ce cas très courant a un problème sérieux à
régler.

> Si j'en étais capable, j'aimerais bien améliorer ce genre de choses.
>
>> Cas particulier: un canal peut avoir une direction changeante : il
>> peut monter et redescendre via des jeux d'écluses (exemple le canal
>> d'Ille-et-Rance qui a son point haut au milieu, aux écluses d'Hédé).
>
> C'est un cas particulier, on peut vivre avec

Note : encore : le sens d'écoulement normal dans le canal descend des
écluses d'Hédé vers Rennes en rejoignant la partie canalisée de
l'Ille. Pourtant, justement par le jeu des écluses, ce sens de
circulation peut être inversé temporairement (cela est utilisé en
période de crue de la Vilaine, si l'Ille par ailleurs n'est pas en
crue et peut être fermée en amont. Cela permet d'évacuer une partie
des eaux de la Vilaine vers le canal, pour aller inonder des prairies
inondables (il y en a à Rennes même mais plus en amont aussi sur
l'Ille à Saint-Grégoire et Betton).

Cela permet de limiter les inondations en aval sur la Vilaine,
notamment à Redon où il y a un goulet sans grande possibilité
d'inonder des terres et où les bassins de rétention sont largement
insuffisants. En aval de Rennes il y a aussi des bassins de rétention
pour aussi détourner une partie des eaux de la Vilaine.

Les modifications de sens de circulation proviennent des équipements
construits par l'homme (mais parfois cela se fait avec des erreurs de
manipulation: il y a quelques années une écluse en amont du canal a
été ouverte sur le cours de l'Ille, en croyant que l'écluse du
confluent de l'Ille vers la Vilaine avait été ouverte, mais elle était
restée fermée par un bloquage de porte, et cela a inondé durant la
nuit tout un quartier au Nord de Rennes qui a été réveillé d'urgence
pour évacuer, le temps que les pompiers ne viennent soulever la porte
avec une grue de chantier, détruisant la porte au passage... et avant
qu'elle soit réparée, il y a eu une inondation importante à Redon du
fait que l'eau de l'Ille n'avait pas pu être retenue à Rennes par la
même porte).

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

Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Christian Quest]

Un peu de lecture pour confirmer mes dires:
http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/output-pgsql.c

comme ce commentaire fort pertinent: "Linear features will end up in
the line and roads tables (useful for admin boundaries)"

-- 
Christian Quest - OpenStreetMap France
Synthèse du Week-end "SOTM-FR" à Lyon : http://openstreetmap.fr/synthese-sotmfr

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

Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Philippe Verdy]

Le 6 mars 2013 19:13, Christian Quest  a écrit :
> Le rendu mapnik/osm2pgsql utilise bien les relations pour tracer les
> limites administratives contrairement à ce qu'indique Philippe.

Visiblement non ! Il effectue une requête partielle des données et
cela se confirme justement par la différence de rendus des traits et
leur disparition inattendue si on n'est pas à un niveau de zoom où les
chemins sont bien sélectionnés et retournés de la base.

Et même quand ils sont retournés et visibles si Mapnik sur OSM.org
utilisant toutes les relations dépendantes il ne tiendrait plus compte
de l'attribut pour déterminer la nature du trait dessiné et
utiliserait la value minimum d'admin_level parmi les relations qu'il a
trouvées.

Certainement Mapnik sait le faire, mais pour des raisons de
performance et de charge des serveurs, des raccourcis ont aussi été
faits, justement pour les bas niveaux de zoom où chaque tuile couvre
des zones très étendues contenant de très nombreux objets.

> Tu peux mettre admin_level=2 sur le way de frontière, c'est assez
> courant même si pas indispensable.

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

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Philippe Verdy]

Peut-être qu'une demande à Microsoft/Yahoo/Bing pour obtenir les
droits d'usage des images SPOT (pas nécessairement les plus récentes
si le CNES tient à garder son exploitation commerciale, ou alors
seulement les images après catastrophe) pourrait aider aussi. Mais
combien de temps cela prendra-t-il ?

Le sponsoring peut marcher aussi si le CNES peut vendre ces images à
prix réduit justement du fait de l'urgence humanitaire. La
distribution gratuite des images pourrait aussi être temporaire
(quelques mois), pour ensuite revenir à une exploitation commerciale
des images post-catastrophe montrant l'état des reconstructions et
réaménagements (car après une catastrophe, le terrain va évoluer
énormément, mais on n'est plus dans le cadre de la gestion humanitaire
de la catastrophe elle-même).

Le 6 mars 2013 19:09, Jean-Guilhem Cailton  a écrit :
> Cependant l'imagerie Bing Haute définition n'est pas disponible pour
> Morombe. D'où l'importance d'obtenir l'autorisation d'utiliser l'imagerie
> SPOT ou d'autre.

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

Re: [OSM-talk-fr] Bassins versants

[Philippe Verdy]

On peut très bien (et on devrait) dessiner les deux bras (surtout
d'ailleurs s'ils séparent une île où il y a des constructions et
utilisations diverses du terrain).

Mais dans ce cas il faut désigner un des bras comme "main_stream" et
l'autre comme "side_stream" (classé à part dans la liste des membres).

Assez souvent le choix du bras à désigner comme principal est évident
(il faut regarder chaque bras dans sa totalité et pas seulement la
largeur relative des deux bras à leur séparation), mais pas toujours
(cas des deux bras de la Loire à Nantes), et dans ce cas le choix est
assez arbitraire.

Mais un simple bras canalisé permettant de franchir une écluse reste
un bras secondaire, même si le cours principal franchit un seuil
construit interdisant la navigation. Cela implique que la longueur
navigable d'un cours d'eau est différente de la longueur totale du
cours d'eau naturel (c'est de toute façon déjà le cas en amont de tous
les fleuves et rivières).

Un graphe différent doit donc être calculé pour les bassins versants
(qui doivent aussi exclure les canaux mais pas les cours d'eau
naturels canalisés) et pour les réseaux navigables (qui incluent les
canaux et les bras secondaires créés pour les passages d'écluses).

Comme on l'a noté plus haut les affluents ne se connectent pas
toujours tous au bras principal, mais tant qu'ils se connectent à un
moins un bras déclaré secondaire dans la relation, il n'y a pas
d'erreur :

Si on dessine un graphe en arbre des affluents en ne tenant compte que
des bras principaux, il suffit de prolonger les affluents le long du
bras secondaire auquel il se connecte pour le reconnecter au bras
principal (en ignorant cette longueur ajoutée dans le calcul de la
longueur de l'affluent), l'arbre peut donc continuer à être construit
pour calculer les bassins versants.

Dernière complication, les embouchures multiples : le choix de
l'embouchure principale (main_stream) par rapport aux autres
(side_stream) n'est pas toujours évident pour les fleuves terminés en
delta (cas du Rhône par exemple), et peut être assez arbitraire. S'il
n'est pas évident qu'un bras est beaucoup plus important que les
autres, on peut tenter d'utiliser celui le plus central pour le graphe
des bassins versants. Sinon le bras qui se connecte le mieux à
d'autres canaux (pour le graphe navigable, mais dans ce cas ce graphe
n'est pas un arbre de toute façon et n'est pas orienté comme les cours
naturels, il forme un réseau maillé qui n'a rien à voir avec les
bassins versants mais s'interconnecte d'un bassin à l'autre).

Le 6 mars 2013 18:41, Marc Sibert  a écrit :
> Ok, ça ça va. Je parlais du cas des bras symétriques : faites-vous 2 cours
> // ou un seul arbitraire ?
> Exemple aussi la mangrove de Mada (justement) ou l'estuaire de la Garonne
>
> --
> Marc Sibert
> mailto:m...@sibert.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] Frontière et/ou eaux territoriales Guyane française

[Stéphane MARTIN]

Salut,

J'ai changé les ways constituant la frontière maritime en admin_level=2.
Il semble qu'il y ait consensus !

Par contre, arrivé aux ways constituant la frontière Guyane-Brésil, 
changer l'admin_level de 1 en 2 ne risque-t-il pas de faire doublon avec 
la relation frontière Guyane-Brésil qui inclut déjà admin_level=2 ?


Je supprime carrément l'admin_level sur les ways ?

Merci encore !
@+

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

Re: [OSM-talk-fr] Bassins versants

[Marc Sibert]

Le 06/03/2013 17:31, Philippe Verdy a écrit :

Le 6 mars 2013 17:14, Marc SIBERT  a écrit :

Ça doit être intéressant, mais c'est vraiment trop long (détaillé).
J'aimerais comprendre comment vous tagguez les bras multiples et //

Quelle mauvaise foi tu as ! C'était déjà marqué plus court dans un
message précédent que tu n'as pas lu non plus !

- le cours principal : rôle "main_stream" dans la relation du cours
d'eau (membres de type way uniquement, avec
waterway=river/stream/etc...)
- tous les autres bras secondaires : rôle "side_stream" (membres de
type way uniquement, avec waterway=river/stream/etc...)

Les riverbanks sont à part, dans des polygones successifs ou dans une
relation multipolygone qui les incluent tous sous forme fermée (rôle
outer) ou sous forme de série de chemins ouverts formant une boucle
fermée (rôle outer), avec parfois des boucles fermées de rôle inner
pour les îles créés par les différents bras. En principe si on
commence à créer un multipolygone pour une riverbank, on devrait les
fusionner dans la même relation sauf pour les sections couvertes
taguées en "tunnel=yes".


Ok, ça ça va. Je parlais du cas des bras symétriques : faites-vous 2 
cours // ou un seul arbitraire ?

Exemple aussi la mangrove de Mada (justement) ou l'estuaire de la Garonne

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


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

Re: [OSM-talk-fr] les POI de Mapnik

[Etienne Trimaille]

Bonjour Émilie,

Est-ce que le répertoire des pictos mapnik convient ?
http://svn.openstreetmap.org/applications/rendering/mapnik/symbols/


Le 6 mars 2013 18:12, Ab_fab  a écrit :

> Pour le rendu Mapnik du site principal openstreetmap.org, tu peux
> regarder ici :
> https://github.com/gravitystorm/openstreetmap-carto
>
> Et plus particulièrement ici :
>
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss
>
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-symbols.mss
> (...)
>
> (sans garantie d'exhaustivité)
>
> Le 6 mars 2013 17:48, Emivi  a écrit :
>
> Bonjour
>> Existe t-il une liste des POI rendus par Mapnik ?
>>
>> Emilie (la bretonne)
>>
>> __**_
>> 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", Nadja
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] les POI de Mapnik

[Ab_fab]

Pour le rendu Mapnik du site principal openstreetmap.org, tu peux regarder
ici :
https://github.com/gravitystorm/openstreetmap-carto

Et plus particulièrement ici :
https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-points.mss
https://github.com/gravitystorm/openstreetmap-carto/blob/master/amenity-symbols.mss
(...)

(sans garantie d'exhaustivité)

Le 6 mars 2013 17:48, Emivi  a écrit :

> Bonjour
> Existe t-il une liste des POI rendus par Mapnik ?
>
> Emilie (la bretonne)
>
> __**_
> 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", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] source=inconnue

[Philippe Verdy]

Si les autorités sont incapables de démerder la situation légalement,
je ne vois pas en quoi le fait de créer une conflation nous-même
serait plus fausse que les autres solutions théoriquement
"officielles" mais pas d'accord entre elles ! Dans des cas comme ça,
on consacre l'usage, donc ici dans le cas de cette forêt, la limite
concrète de cette forêt (on reverra ça uniquement le jour où les
autorités administratives se mettront d'accord, mais on peut malgré
tout marquer notre conflation comme ne correspondant à aucune
définition officielle puisque celle-ci tout bonnement... n'existe pas
encore !).
On résoud comme cela le cas pratique par la règle du terrain, et cela
ne sert strictement à rien de multiplier les traits contradictoires
selon les sources.

Le 6 mars 2013 17:36, PhQ  a écrit :
> Bonjour,
> J'ai eu à connaitre à titre professionnel un conflit de ce type à l'ONF ou 3
> départements et deux régions se disputait 15 hectares de forêts suite à des
> arrangement cadastraux ( reports des erreurs en limites de communes). J'en
> ai eu connaissance en 1974. En 1995 une même surface était toujours
> revendiqué par 2 régions différentes ONF  dans les base informatiques. Sur
> le terrain (source photo aérienne) la limite de plantation, valant limite
> "concrète" était éloigné d'une centaine de mètres de la limite légale
> administrative.
> Et pourtant, j'ai entendu dire que 3 préfets s'étaient déplacé sur le
> terrain pour régler ca ... alors, je vous (nous souhaite bien du plaisir
> pour démerder certaines zones.
> (Zone : les 3 limites cantal haute-loire Lozère)
> Bien cordialement
>
>
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/source-inconnue-tp5752013p5752114.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] Bassins versants

[Ab_fab]

Le 6 mars 2013 17:43, Philippe Verdy  a écrit :

> Le 6 mars 2013 17:29, Ab_fab  a écrit :
> > Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent
> > justement pas compte de ces rôles "side_stream" ou "main_stream". Cela
> > fausse et alourdit les résultats.
>
> En quoi cela fausse les résultats ? Si tu ne fais pas de différence,
> la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler
> par endroits des longueurs 2 ou 3 fois.
>

Cela fausse les résultats en indiquant que le cours d'eau est en plusieurs
segments (et donc implicitement qu'il y a des coupures), alors qu'en
réalité tout est ok. Cela ne permet pas de mettre en évidence les cours
d'eau pour lesquels il y a vraiment une amélioration à apporter.

Voir la Durance, depuis l'outil de Sly : il indique trois tronçons, mais en
pratique il y a juste un bras secondaire à Chateau-Arnoux - Saint Auban
quand on consulte l'analyseur de relation
http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html


>
> Pourtant l'outil doit être capable de déterminer si parmi l'ensemble
> des chemins "main_stream" cela forme une ligne continue ou pas.
> Ensuite s'il reste des segments, l'outil peut signaler que certains
> devraient passer en "side_stream" pour former un unique chemin
> "main_stream".
>

Il devrait, oui, mais c'est justement pas le cas avec les outils dans leur
état actuel.
Si j'en étais capable, j'aimerais bien améliorer ce genre de choses.


> Puis si le cours d'eau "main_stream" n'est toujours pas continu de
> bout en bout, il peut chercher parmi les sans rôle défini, ou sinon
> parmi les "side_stream" ceux qui peuvent combler les trous et les
> signaler comme des "main_stream" candidats. Le reste des chemins sans
> rôle peut enfin être signalé comme devant être des "side_stream".
>
> Une fois qu'on a un cours d'eau continu, la direction du cours devrait
> être consistante (on peut signaler alors les sections médianes
> stipulées dans le sens opposé.
>
> Une fois ces ignalement faits, on peut corriger, et finalement obtenir
> un graphe orienté de main_streams pour les cours d'eau et former les
> relations "tributary" des affluents. Là encore l'orientation est
> vérifiable, un tributary devant avoir un noeud commun avec le cours
> vers lequel il se termine.
>

Oui oui

Cas particulier: un canal peut avoir une direction changeante : il
> peut monter et redescendre via des jeux d'écluses (exemple le canal
> d'Ille-et-Rance qui a son point haut au milieu, aux écluses d'Hédé).
>

C'est un cas particulier, on peut vivre avec


>
> ___
> 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", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] les POI de Mapnik

[Emivi]

Bonjour
Existe t-il une liste des POI rendus par Mapnik ?

Emilie (la bretonne)

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

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Pierre Béland]

Marc,

Compte-tenu que nous avons l'autorisation d'utiliser l'imagerie Bing pour ces 
zones, j'ai ajouté une tâche pour  Sakaraha http://tasks.hotosm.org/job/207.

Cependant l'imagerie Bing Haute définition n'est pas disponible pour Morombe. 
D'où l'importance d'obtenir l'autorisation d'utiliser l'imagerie SPOT ou 
d'autre.

Jean-Guilhem, aurions-nous une chance avec d'autres sources?


 
Pierre 



>
> De : Marc SIBERT 
>À : Pierre Béland ; Discussions sur OSM en français 
> 
>Envoyé le : Mercredi 6 mars 2013 11h10
>Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone 
>Haruna à Madagascar.
> 
>
>Concernant les images provenant du Sertit, c'est clairement : non ! Les 
>conditions de réutilisation des images se limitent à l'usage non commercial. 
>Évidemment, il ne s'agit pas ici de réutiliser les images elles-même, mais le 
>produit du travail de vectorisation. Mais AMHA ça ne change rien. D'où ma 
>demande à SpotImage, à la source des images.
>
>A+
>
>
>
>
>Le 6 mars 2013 17:06, Pierre Béland  a écrit :
>
>
>>Une tâches est maintenant définie pour la zone de Toliara dans le 
>>Gestionnaire de HOT  (http://tasks.hotosm.org/job/206).
>>
>>Les images du Disaster Chapter concernent aussi le zones de Sakaraha 
et Morombe.
>>
>>Nous devrons décider du type de travail carto à effectuer et à partir de 
>>quelles images (Bing ou SPOT).  En ce qui a trait à l'import de données dans 
>>OSM, nous n'avons aucun problème de licence avec Bing, et si nécessaire vous 
>>pouver demander à ajouter des tâches pour d'autres zones que Toliara. 
>>
>>Par contre,  il est nécessaire d'éclaircir la question des licences des  
>>images SPOT.  Permet-on ou non l'import dans OSM (Licence ODbl incluant à des 
>>fins commerciales) dans le contexte de cette urgence humanitaire?
>>
>>Aussi, pour le traitement des infos post-sinistre, immeubles touchés etc., il 
>>faudrait décider de ce qui doit être fait.
>>
>>Je fais aussi faire rapport sur la liste de discussion de HOT  
>>http://lists.openstreetmap.org/listinfo/hot.
>>
>> 
>>Pierre 
>>
>>
>>
>>>
>>> De : Marc SIBERT 
>>>À : Discussions sur OSM en français  
>>>Envoyé le : Mercredi 6 mars 2013 9h36
>>>Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone 
>>>Haruna à Madagascar.
>>> 
>>>
>>>
>>>Bonjour,
>>>
>>>Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp 
>>>2010) pour lui demander les images originales libérées des contraintes de 
>>>réutilisation.
>>>
>>>A+
>>>
>>>
>>>
>>>
>>>Le 6 mars 2013 14:56, Cédric Moro  a écrit :
>>>
>>>Merci de vos réponses.

1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci

2/ Images SPOT/Pléiades :

Elles sont dispo à ces adresses :
http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html
http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434

Nous
 avons eu un contact téléphonique et fait une demande écrite au SERTIT 
qui a effectué le traitement des images en télédétection. Nous avions 
une difficulté à importer leurs images KML dans crowdmap ou même 
googlemap et nous avons pu les ouvrir seulement dans Googleearth pour 
les avoir sous une forme géolocalisée. 

Le problème était que les traitements et 
légendes étaient incrustés dans le raster de l'image (qui n'est qu'une 
JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus 
facilement exportables. Pour la région de Tuléar, nous avons donc mis 
des dizaines d'heures à refaire les polygones et points. On a perdu 
beaucoup de temps et de la précision, et sur cette zone seulement. Nous 
avons eu un contact avec le SERTIT hier soir et nous leur avons donc 
demander de bénéficier des couches de traitement en télédétection au 
format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour 
d'autres régions touchées sur lesquelles nous n'avons pas encore déployé
 de données spatiales. La demande est en cours d'approbation au siège.

Concernant l'utilisation des images satellites en dehors de la 
catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous 
rapporte (sans jugement personnel) :
Les droits d'auteurs à de fins 
commerciales et la non réutilisation en dehors de la situation de la 
catastrophe naturelle et de sa réponse d'urgence.

Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des 
formats d'échange de données en période de catastrophe pour qu'à l'avenir, 
on ne perde plus autant de temps.

4/ Ceux qui gèrent
 la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les 
acteurs sur place par téléphone et email , surtout avec les Pompiers de 
l'urgence internationale,
 et par Réseaux sociaux pour certains habitants sur place.

5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite.

6/

Re: [OSM-talk-fr] Bassins versants

[Philippe Verdy]

Le 6 mars 2013 17:29, Ab_fab  a écrit :
> Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent
> justement pas compte de ces rôles "side_stream" ou "main_stream". Cela
> fausse et alourdit les résultats.

En quoi cela fausse les résultats ? Si tu ne fais pas de différence,
la longueur du cours d'eau s'en ressent sensiblement, tu vas cumuler
par endroits des longueurs 2 ou 3 fois.

Pourtant l'outil doit être capable de déterminer si parmi l'ensemble
des chemins "main_stream" cela forme une ligne continue ou pas.
Ensuite s'il reste des segments, l'outil peut signaler que certains
devraient passer en "side_stream" pour former un unique chemin
"main_stream".

Puis si le cours d'eau "main_stream" n'est toujours pas continu de
bout en bout, il peut chercher parmi les sans rôle défini, ou sinon
parmi les "side_stream" ceux qui peuvent combler les trous et les
signaler comme des "main_stream" candidats. Le reste des chemins sans
rôle peut enfin être signalé comme devant être des "side_stream".

Une fois qu'on a un cours d'eau continu, la direction du cours devrait
être consistante (on peut signaler alors les sections médianes
stipulées dans le sens opposé.

Une fois ces ignalement faits, on peut corriger, et finalement obtenir
un graphe orienté de main_streams pour les cours d'eau et former les
relations "tributary" des affluents. Là encore l'orientation est
vérifiable, un tributary devant avoir un noeud commun avec le cours
vers lequel il se termine.

Cas particulier: un canal peut avoir une direction changeante : il
peut monter et redescendre via des jeux d'écluses (exemple le canal
d'Ille-et-Rance qui a son point haut au milieu, aux écluses d'Hédé).

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

Re: [OSM-talk-fr] Bassins versants

[Ab_fab]

Il est possible d'attribuer dans la relation "waterway" :
_ un rôle main_stream sur le(s) way(s) du bras que l'on définit comme
principal,
_ un rôle side_stream sur le(s) way(s) du/des bras que l'on détermine comme
secondaire(s)

Ces règles sont plutôt récentes, et l'usage s'est répandu après que les
principaux outils de suivi que l'on connait ont été développés (si ma
mémoire est bonne).
J'espère qu'un jour il y aura un "mashup" sympa de tous ces outils
permettant d'avoir une bonne vision d'ensemble de l'avancement et des zones
à améliorer.

Le 6 mars 2013 17:14, Marc SIBERT  a écrit :

> Ça doit être intéressant, mais c'est vraiment trop long (détaillé).
> J'aimerais comprendre comment vous tagguez les bras multiples et //
> tl;dr
>
>
>
> ___
> 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", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] source=inconnue

[PhQ]

Bonjour,
J'ai eu à connaitre à titre professionnel un conflit de ce type à l'ONF ou 3
départements et deux régions se disputait 15 hectares de forêts suite à des
arrangement cadastraux ( reports des erreurs en limites de communes). J'en
ai eu connaissance en 1974. En 1995 une même surface était toujours
revendiqué par 2 régions différentes ONF  dans les base informatiques. Sur
le terrain (source photo aérienne) la limite de plantation, valant limite
"concrète" était éloigné d'une centaine de mètres de la limite légale
administrative.
Et pourtant, j'ai entendu dire que 3 préfets s'étaient déplacé sur le
terrain pour régler ca ... alors, je vous (nous souhaite bien du plaisir
pour démerder certaines zones.
(Zone : les 3 limites cantal haute-loire Lozère)
Bien cordialement



--
View this message in context: 
http://gis.19327.n5.nabble.com/source-inconnue-tp5752013p5752114.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] Bassins versants

[Philippe Verdy]

Le 6 mars 2013 17:14, Marc SIBERT  a écrit :
> Ça doit être intéressant, mais c'est vraiment trop long (détaillé).
> J'aimerais comprendre comment vous tagguez les bras multiples et //

Quelle mauvaise foi tu as ! C'était déjà marqué plus court dans un
message précédent que tu n'as pas lu non plus !

- le cours principal : rôle "main_stream" dans la relation du cours
d'eau (membres de type way uniquement, avec
waterway=river/stream/etc...)
- tous les autres bras secondaires : rôle "side_stream" (membres de
type way uniquement, avec waterway=river/stream/etc...)

Les riverbanks sont à part, dans des polygones successifs ou dans une
relation multipolygone qui les incluent tous sous forme fermée (rôle
outer) ou sous forme de série de chemins ouverts formant une boucle
fermée (rôle outer), avec parfois des boucles fermées de rôle inner
pour les îles créés par les différents bras. En principe si on
commence à créer un multipolygone pour une riverbank, on devrait les
fusionner dans la même relation sauf pour les sections couvertes
taguées en "tunnel=yes".

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

Re: [OSM-talk-fr] Bassins versants

[Ab_fab]

"Dans des cas comme celui de la Loire à Nantes, il n'est pas possible de
décider lequel des deux bras principaux est LE bras principal. Au milieu il
y a une île, assez grande d'ailleurs et habitée, les deux bras sont
navigables, aucun n'est fermé par un seuil. C'est difficile de dire lequel
est le cours principal et d'ailleurs chaque bras a son propre nom, distinct
du nom du fleuve entier."

J'ai grandi à moins de 500 mètres du bras de pirmil, donc je connais bien
(et ce n'est pas la première fois que l'on en parle sur cette liste).
C'est d'autant plus délicat que la Sèvre Nantaise se jette dans le bras de
Pirmil (au sud), et l'Erdre dans le bras de la Madeleine (au nord). C'est
un cas particulier, on peut vivre avec, par exemple en y allant de manière
arbitraire pour définir le bras principal et le bras secondaire.

Mais pour le reste, les outils d'analyse que j'ai cités ne tiennent
justement pas compte de ces rôles "side_stream" ou "main_stream". Cela
fausse et alourdit les résultats.

Ce serait chouette que les résultats de ces analyses puissent être rendus
plus clairs sur ces aspects.
Cela faciliterait la recherche des zones où il est possible d'améliorer le
filaire des cours d'eau et leur continuité


Le 6 mars 2013 17:05, Philippe Verdy  a écrit :

> Le 6 mars 2013 16:01, Ab_fab  a écrit :
> > Les outils non graphiques que tu cites sont puissants mais mériteraient
> un
> > peu d'affinage visuel, ainsi que quelques règles complémentaires
> d'analyse,
> > par exemple pour évacuer des résultats les bras secondaires.
>
> Les bras secondaires sont normalement tagués avec un rôle
> "side_stream", au lieu du rôle par défaut "main_stream", quand les
> deux types sont présents. Pour les cours d'eau qui forment une seule
> ligne continue, souvent il n'y a aucun rôle défini, mais c'est à
> interpréter comme "main_stream".
>
> Dans certains cas, il n'y a aucun rôle défini mais on déduit le
> side-stream au fait que ses deux extrémités ne sont les extrémités
> d'aucun autre chemin, mais seulement des points communs à un même
> chemin.
>
> Des ambiguïtés existent dans des cas comme celui-ci:
>
>
>  A--->B--->C
>  \\
>   D--->-E>F
>
> où les deux chemins créés sont ABCE et BDEF : lequel des deux bras BCE
> ou BDE est le bras principal, l'autre un bras secondaire ? Sans un
> rôle pour l'indiquer sur chaque chemin dans une même relation, ou sans
> relation pour les regrouper avec ces rôles ce n'est pas possible de le
> déterminer géométriquement.
>
> Si les chemins ont été créés sous la forme ABCEF et BDE, on pourrait
> en "déduire" par défaut que BDE est un bras secondaire ; mais si les
> chemins sont AB, BCE, BDE et EF, on ne sait pas faire cette déduction;
> pourtant géométriquement parlant, ces différentes solutions produisent
> la même chose, et sans indication des débits sur chaque bras, ou sans
> indication d'un rôle dans une relation-maître, ou sans déduction par
> observation des largeurs de lits ou des "riverbanks" quand ils ont été
> tracés aussi, ou de la dynamique de volumes d'eau en déplacement qui
> ne peuvent pas changer facilement de direction et privilégieront le
> chemin le plus  en ligne droite et capable d'évacuer en aval la plus
> grande hauteur d'eau, on ne peut pas toujours réellement décider (cela
> demande une analyse plus fine que la seule largeur car les hauteurs de
> fonds en aval jouent aussi un rôle sur les débits que chaque bras
> peuvent évacuer, sinon ce bras déjà rempli devient un "mur" d'eau
> s'opposant au passage et forçant plus d'eau à passer par l'autre bras,
> même si la lame d'eau doit faire un virage).
>
> Cela ne fait en général pas de grosses différences sur le calcul de la
> longueur totale du cours d'eau (il y a déjà des différences accumulées
> tout le long du cours par la seule estimation du cours central).
>
> Parfois ce choix du bras principal reste arbitraire, sujet à
> l'interprétation. Par exemple le cours principal d'une rivière reste
> la partie la plus large supposée écouler le débit d'eau le plus
> important, même si elle est partiellement "fermée" par un seuil (pour
> maintenir un niveau d'eau suffisant en amont) et non franchissable
> pour la navigation, alors que l'autre est plus étroit, canalisé et
> fermé par une écluse, mais alors navigable (mais pas adapté pour
> écouler les volumes d'eau, l'écluse étant destinée à rester toujours
> fermée au moins sur une des deux portes).
>
> Mais il existe aussi des cas où les bras secondaires sont aussi créés
> uniquement par un seuil à débordement (le bras restant quasiment à sec
> ou avec une circulation d'eau infime juste destinée à éviter que l'eau
> n'y croupisse, sauf en cas de crue où le niveau d'eau dépasse la
> hauteur du seuil), ce seuil pouvant aussi être réglé par la présence
> de vannes, quitte même à ce que le bras secondaire vienne lui-même
> inonder certaines terres non construites pour que le bras principal ne
> provoque pas d'inondations causant des dommages 

Re: [OSM-talk-fr] source=inconnue

[Philippe Verdy]

Le 6 mars 2013 15:33, Jo.  a écrit :
> Après ce n'est qu'un conseil d'édition, c'est simplement pour éviter de
> créer/propager une erreur. Séparer les éléments physique des éléments
> immatériel me semble conseillé pour éviter de nombreuses heures de
> correction.

Tout peut bouger sur une carte au cours du temps, que ce soit les
éléments matériels ou les éléments immatériels. Bref on aura toujours
des corrections à faire pour tenir compte de ça. Une carte se révise
donc dans tous les cas. Mais si dans un état actuel on ne sait pas
faire de différence entre deux éléments, la conflation s'impose tant
que les différences ne sont pas assez significatives.

Car même les frontières administratives ne sont pas encore elles-mêmes
en conflation d'une commune à l'autre, ce qui laisse assez d'écart
pour que la confusion des deux tracés se confonde aussi avec le tracé
de l'élément matériel.

Le cadastre est justement un bon exemple puisqu'il est maintenu
commune par commune mais quand une commune se limite sur la tracé d'un
cours d'eau, il n'y a que le tracé jusqu'aux rives existantes qui soit
significatif, le tracé au milieu du cours d'eau est très indicatif et
se superpose en fait rarement avec le tracé tout aussi indicatif de la
planche cadastrale de la commune voisine. Pour les deux communes
pourtant cela ne fait aucune différence, elles sont appelées à gérer
en commun le cours d'eau et ses aménagements, et ne peuvent pas
intervenir sur le tracé de leurs rives sans impacter l'autre rive.

Il me semble même que tous les travaux sur un cours d'eau ou sur ses
rives ne peuvent se faire qu'en concertation avec l'agence de bassin
car cela peut impacter d'autres communes beaucoup plus loin pour la
gestion des crues. Bref la compétence administrative exclusive d'une
commune s'arrêtera à sa propre rive, le lit lui-même reste une
compétence partagée par toutes les communes traversées ou longeant un
cours d'eau.

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

Re: [OSM-talk-fr] Bassins versants

[Marc SIBERT]

Ça doit être intéressant, mais c'est vraiment trop long (détaillé).
J'aimerais comprendre comment vous tagguez les bras multiples et //
tl;dr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Marc SIBERT]

Concernant les images provenant du Sertit, c'est clairement : non ! Les
conditions de réutilisation des images se limitent à l'usage non
commercial. Évidemment, il ne s'agit pas ici de réutiliser les images
elles-même, mais le produit du travail de vectorisation. Mais AMHA ça ne
change rien. D'où ma demande à SpotImage, à la source des images.

A+


Le 6 mars 2013 17:06, Pierre Béland  a écrit :

>
> Une tâches est maintenant définie pour la zone de Toliara dans le
> Gestionnaire de HOT  (http://tasks.hotosm.org/job/206).
>
> Les images du Disaster Chapter concernent aussi le zones de Sakaraha  et
> Morombe.
>
> Nous devrons décider du type de travail carto à effectuer et à partir de
> quelles images (Bing ou SPOT).  En ce qui a trait à l'import de données
> dans OSM, nous n'avons aucun problème de licence avec Bing, et si
> nécessaire vous pouver demander à ajouter des tâches pour d'autres zones
> que Toliara.
>
> Par contre,  il est nécessaire d'éclaircir la question des licences des
> images SPOT.  Permet-on ou non l'import dans OSM (Licence ODbl incluant à
> des fins commerciales) dans le contexte de cette urgence humanitaire?
>
> Aussi, pour le traitement des infos post-sinistre, immeubles touchés etc.,
> il faudrait décider de ce qui doit être fait.
>
> Je fais aussi faire rapport sur la liste de discussion de HOT
> http://lists.openstreetmap.org/listinfo/hot.
>
> Pierre
>
>   --
> *De :* Marc SIBERT 
> *À :* Discussions sur OSM en français 
> *Envoyé le :* Mercredi 6 mars 2013 9h36
> *Objet :* Re: [OSM-talk-fr] Demande d'assistance cartographique sur le
> Cyclone Haruna à Madagascar.
>
> Bonjour,
>
> Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp
> 2010) pour lui demander les images originales libérées des contraintes de
> réutilisation.
>
> A+
>
>
> Le 6 mars 2013 14:56, Cédric Moro  a écrit :
>
>  Merci de vos réponses.
>
> 1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci
>
> 2/ Images SPOT/Pléiades :
>
> Elles sont dispo à ces adresses :
>
> http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html
>
> http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434
>
> Nous avons eu un contact téléphonique et fait une demande écrite au SERTIT
> qui a effectué le traitement des images en télédétection. Nous avions une
> difficulté à importer leurs images KML dans crowdmap ou même googlemap et
> nous avons pu les ouvrir seulement dans Googleearth pour les avoir sous une
> forme géolocalisée.
>
> Le problème était que les traitements et légendes étaient incrustés dans
> le raster de l'image (qui n'est qu'une JPG) et pas sous forme d'objets
> vecteurs géoloc qui auraient été plus facilement exportables. Pour la
> région de Tuléar, nous avons donc mis des dizaines d'heures à refaire les
> polygones et points. On a perdu beaucoup de temps et de la précision, et
> sur cette zone seulement. Nous avons eu un contact avec le SERTIT hier soir
> et nous leur avons donc demander de bénéficier des couches de traitement en
> télédétection au format KML/KMZ pour pouvoir les intégrer à notre crowdmap,
> surtout pour d'autres régions touchées sur lesquelles nous n'avons pas
> encore déployé de données spatiales. La demande est en cours d'approbation
> au siège.
>
> Concernant l'utilisation des images satellites en dehors de la
> catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous
> rapporte (sans jugement personnel) :
> Les droits d'auteurs à de fins commerciales et la non réutilisation en
> dehors de la situation de la catastrophe naturelle et de sa réponse
> d'urgence.
>
> Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique
> des formats d'échange de données en période de catastrophe pour qu'à
> l'avenir, on ne perde plus autant de temps.
>
> 4/ Ceux qui gèrent la carte, dont moi, ne sommes pas sur le terrain mais
> en contact avec les acteurs sur place par téléphone et email , surtout avec
> les Pompiers de l'urgence internationale, et par Réseaux sociaux pour
> certains habitants sur place.
>
> 5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite.
>
> 6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais
> sur place, certains s'intéressent en détail dans la carto libre, je leur
> montrerai le chemin d'OSM et d'Ushahidi :-)
>
> Merci encore à tous et à bientôt,
>
>
> +33 5 35 54 19 27
> Skype : roomilissimo
> Twitter : @Moro_Cedric
> Coordinateur du VOST Francophone
> Membre de la communauté MSGU (Médias sociaux en gestion d'urgence)
> Webmaster des Pompiers de l'urgence internationale
> www.pompiers-urgence.org
> www.i-resilience.fr
>
> > Date: Wed, 6 Mar 2013 14:43:25 +0100
> > From: j...@arkemie.com
> > To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com
> > Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le
> Cyclone Haruna à Madagascar.
>
> >
> > Bonjour,
> >
> > Le mieux es

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Pierre Béland]

Une tâches est maintenant définie pour la zone de Toliara dans le Gestionnaire 
de HOT  (http://tasks.hotosm.org/job/206).

Les images du Disaster Chapter concernent aussi le zones de Sakaraha 
et Morombe.

Nous devrons décider du type de travail carto à effectuer et à partir de 
quelles images (Bing ou SPOT).  En ce qui a trait à l'import de données dans 
OSM, nous n'avons aucun problème de licence avec Bing, et si nécessaire vous 
pouver demander à ajouter des tâches pour d'autres zones que Toliara. 

Par contre,  il est nécessaire d'éclaircir la question des licences des  images 
SPOT.  Permet-on ou non l'import dans OSM (Licence ODbl incluant à des fins 
commerciales) dans le contexte de cette urgence humanitaire?

Aussi, pour le traitement des infos post-sinistre, immeubles touchés etc., il 
faudrait décider de ce qui doit être fait.

Je fais aussi faire rapport sur la liste de discussion de HOT  
http://lists.openstreetmap.org/listinfo/hot.

 
Pierre 



>
> De : Marc SIBERT 
>À : Discussions sur OSM en français  
>Envoyé le : Mercredi 6 mars 2013 9h36
>Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone 
>Haruna à Madagascar.
> 
>
>Bonjour,
>
>Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp 
>2010) pour lui demander les images originales libérées des contraintes de 
>réutilisation.
>
>A+
>
>
>
>
>Le 6 mars 2013 14:56, Cédric Moro  a écrit :
>
>Merci de vos réponses.
>>
>>1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci
>>
>>2/ Images SPOT/Pléiades :
>>
>>Elles sont dispo à ces adresses :
>>http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html
>>http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434
>>
>>Nous
 avons eu un contact téléphonique et fait une demande écrite au SERTIT 
qui a effectué le traitement des images en télédétection. Nous avions 
une difficulté à importer leurs images KML dans crowdmap ou même 
googlemap et nous avons pu les ouvrir seulement dans Googleearth pour 
les avoir sous une forme géolocalisée. 
>>
>>Le problème était que les traitements et 
légendes étaient incrustés dans le raster de l'image (qui n'est qu'une 
JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus 
facilement exportables. Pour la région de Tuléar, nous avons donc mis 
des dizaines d'heures à refaire les polygones et points. On a perdu 
beaucoup de temps et de la précision, et sur cette zone seulement. Nous 
avons eu un contact avec le SERTIT hier soir et nous leur avons donc 
demander de bénéficier des couches de traitement en télédétection au 
format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour 
d'autres régions touchées sur lesquelles nous n'avons pas encore déployé
 de données spatiales. La demande est en cours d'approbation au siège.
>>
>>Concernant l'utilisation des images satellites en dehors de la 
catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous 
rapporte (sans jugement personnel) :
>>Les droits d'auteurs à de fins 
commerciales et la non réutilisation en dehors de la situation de la 
catastrophe naturelle et de sa réponse d'urgence.
>>
>>Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des 
>>formats d'échange de données en période de catastrophe pour qu'à l'avenir, on 
>>ne perde plus autant de temps.
>>
>>4/ Ceux qui gèrent
 la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les 
acteurs sur place par téléphone et email , surtout avec les Pompiers de 
l'urgence internationale,
 et par Réseaux sociaux pour certains habitants sur place.
>>
>>5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite.
>>
>>6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais sur 
>>place, certains s'intéressent en détail dans la carto libre, je leur 
>>montrerai le chemin d'OSM et d'Ushahidi :-)
>>
>>Merci encore à tous et à bientôt,
>>
>>
>>+33 5 35 54 19 27
>>Skype : roomilissimo
>>Twitter : @Moro_Cedric
>>Coordinateur du VOST Francophone
>>Membre de la communauté MSGU (Médias sociaux en gestion d'urgence)
>>Webmaster des Pompiers de l'urgence internationale
>>www.pompiers-urgence.org
>>www.i-resilience.fr
>>
>>
>>> Date: Wed, 6 Mar 2013 14:43:25 +0100
>>> From: j...@arkemie.com
>>> To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com
>>> Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le 
>>> Cyclone Haruna à Madagascar.
>>
>>> 
>>> Bonjour,
>>> 
>>> Le mieux est effectivement de récupérer les données directement chez
>>> Geofabrik, où elles sont mises à jour quotidiennement.
>>> 
>>> Au cas où cela pourrait être utile, j'ai fait une conversion rapide de
>>> leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est
>>> dans :
>>> http://osm.arkemie.org/madagascar/madagascar.kml.zip
>>> et les fichiers individuels sont dans le répertoire :
>>> http://osm.arkemie.org/madaga

Re: [OSM-talk-fr] Bassins versants

[Philippe Verdy]

Le 6 mars 2013 16:01, Ab_fab  a écrit :
> Les outils non graphiques que tu cites sont puissants mais mériteraient un
> peu d'affinage visuel, ainsi que quelques règles complémentaires d'analyse,
> par exemple pour évacuer des résultats les bras secondaires.

Les bras secondaires sont normalement tagués avec un rôle
"side_stream", au lieu du rôle par défaut "main_stream", quand les
deux types sont présents. Pour les cours d'eau qui forment une seule
ligne continue, souvent il n'y a aucun rôle défini, mais c'est à
interpréter comme "main_stream".

Dans certains cas, il n'y a aucun rôle défini mais on déduit le
side-stream au fait que ses deux extrémités ne sont les extrémités
d'aucun autre chemin, mais seulement des points communs à un même
chemin.

Des ambiguïtés existent dans des cas comme celui-ci:


 A--->B--->C
 \\
  D--->-E>F

où les deux chemins créés sont ABCE et BDEF : lequel des deux bras BCE
ou BDE est le bras principal, l'autre un bras secondaire ? Sans un
rôle pour l'indiquer sur chaque chemin dans une même relation, ou sans
relation pour les regrouper avec ces rôles ce n'est pas possible de le
déterminer géométriquement.

Si les chemins ont été créés sous la forme ABCEF et BDE, on pourrait
en "déduire" par défaut que BDE est un bras secondaire ; mais si les
chemins sont AB, BCE, BDE et EF, on ne sait pas faire cette déduction;
pourtant géométriquement parlant, ces différentes solutions produisent
la même chose, et sans indication des débits sur chaque bras, ou sans
indication d'un rôle dans une relation-maître, ou sans déduction par
observation des largeurs de lits ou des "riverbanks" quand ils ont été
tracés aussi, ou de la dynamique de volumes d'eau en déplacement qui
ne peuvent pas changer facilement de direction et privilégieront le
chemin le plus  en ligne droite et capable d'évacuer en aval la plus
grande hauteur d'eau, on ne peut pas toujours réellement décider (cela
demande une analyse plus fine que la seule largeur car les hauteurs de
fonds en aval jouent aussi un rôle sur les débits que chaque bras
peuvent évacuer, sinon ce bras déjà rempli devient un "mur" d'eau
s'opposant au passage et forçant plus d'eau à passer par l'autre bras,
même si la lame d'eau doit faire un virage).

Cela ne fait en général pas de grosses différences sur le calcul de la
longueur totale du cours d'eau (il y a déjà des différences accumulées
tout le long du cours par la seule estimation du cours central).

Parfois ce choix du bras principal reste arbitraire, sujet à
l'interprétation. Par exemple le cours principal d'une rivière reste
la partie la plus large supposée écouler le débit d'eau le plus
important, même si elle est partiellement "fermée" par un seuil (pour
maintenir un niveau d'eau suffisant en amont) et non franchissable
pour la navigation, alors que l'autre est plus étroit, canalisé et
fermé par une écluse, mais alors navigable (mais pas adapté pour
écouler les volumes d'eau, l'écluse étant destinée à rester toujours
fermée au moins sur une des deux portes).

Mais il existe aussi des cas où les bras secondaires sont aussi créés
uniquement par un seuil à débordement (le bras restant quasiment à sec
ou avec une circulation d'eau infime juste destinée à éviter que l'eau
n'y croupisse, sauf en cas de crue où le niveau d'eau dépasse la
hauteur du seuil), ce seuil pouvant aussi être réglé par la présence
de vannes, quitte même à ce que le bras secondaire vienne lui-même
inonder certaines terres non construites pour que le bras principal ne
provoque pas d'inondations causant des dommages importants. Cela crée
donc des "bras morts" qui sont malgré tout conservés pour cet usage de
gestion des crues.

Dans des cas comme celui de la Loire à Nantes, il n'est pas possible
de décider lequel des deux bras principaux est LE bras principal. Au
milieu il y a une île, assez grande d'ailleurs et habitée, les deux
bras sont navigables, aucun n'est fermé par un seuil. C'est difficile
de dire lequel est le cours principal et d'ailleurs chaque bras a son
propre nom, distinct du nom du fleuve entier.

Dans des cas comme ça, le choix du bras principal résulte alors d'une
simple tradition locale sans tenir compte des débits (un bras
considéré comme principal en terme de débit écoulé pendant des
périodes normales, pourrait devenir secondaire en période de crue, et
suite à une crue la part respective de chaque bras pourrait changer à
cause de l'effet de vidange des fonds causés par la crue, ou de
comblement au contraire d'un des bras par des charriages
alluvionnaires conséquents ayant réhaussé les fonds d'un des bras en
aval). Et les travaux humains de curage (ou désensablage) d'un chenal
d'écoulement, peuvent aussi changer cette répartition des eaux, sans
pourtant rien changer au dessin des rives et de la surface de la nappe
d'eau en surface visible en période normale.

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

[OSM-talk-fr] [forum-osm-fr] Maperitive + relation

[forum]

Le message suivant de :
##
Bonjour



je cherche a faire mon premier rendu avec maperitive mais j'ai quelques soucis 
et je fais donc appel a vous 

je n'arrive pas a extraire d'une relation certains éléments contenus dedans



ex : la relation "Transilien N" mais seulement les gares , il me dessine le 
long de toutes les voies



extrait du fichier de règles utilisé



[code]

lines

railway station N : relation[name="Transilien N" and type=route 
and route=train]

.../...

rules

target : railway station N

define

icon-image : 
icons/SJJB/png/16px-Logo_Paris_Transilien_ligneN.svg.png

min-zoom : 10

icon-width : 32

draw : icon

[/code]



si vous avez des conseils ...

a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=3&t=553
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 meilleures 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] Bassins versants

[Ab_fab]

Les outils non graphiques que tu cites sont puissants mais mériteraient un
peu d'affinage visuel, ainsi que quelques règles complémentaires d'analyse,
par exemple pour évacuer des résultats les bras secondaires.

Il y a également l'outil d'Arno Renevier, qui reste bloqué en 2012.
http://renevier.net/maps/rivers/
J'ai essayé de le faire tourner chez moi sur la base des sources
disponibles, et j'ai l'impression qu'il a du mal à digérer les noeuds les
plus récents (ceux avec l'id > à la limite 32 bit ?). Pas eu le temps de
vérifier ça.

Le 18 février 2013 17:49, Frédéric Rodrigo  a écrit
:

> Le 18 février 2013 17:33, Ab_fab  a écrit :
>
> Ou comment
>> _ extraire les données (filaires) relatives aux cours d'eau d'un extrait
>> Geofabrik,
>> _ les analyser  pour constituer les
>> grands bassins versants,
>> _ et finalement en faire le rendu
>>
> Il y deux approches :
> - topologique
> - relationnelle
>
>
>> Les cours d'eau que l'algo n'arrive pas à rattacher à un bassin versant
>> sont affichés en gris. C
>> ela permet de mettre en évidence les défauts de connexion dans le filaire
>> des cours d'eau
>>
>> Ca a l'air sympa, à première vue.
>> Je ne sais pas si ce serait facilement transposable à la France
>>
> On à déjà deux outil, non graphique pour faire ça, suivant deux approches
> différentes :
> - http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html (à la
> sly)
> - http://suivi.openstreetmap.fr/cours-eau/suivi-affluents.html (à la fred
> (moi))
>
> Frédéric
>
>
> ___
> 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", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] source=inconnue

[Philippe Verdy]

JOSM ne va "râler" dns son validateur QUE si les segments qui se
superposent utilisent les mêmes noeuds (gros carrés au lieux de petits
carrés). Comme il est impossible de faire la différence, le fait
d'avoir deux traits au lieu d'un seul, alors que ce sont les mêmes
noeuds, n'empêchera jamais la modification du lit d'une riière ou
d'une route de bouger aussi la limite administrative puisque ce seront
de toute façon les mêmes noeuds qui seront déplacés.

Bref si les noeuds sont déjà superposés, fusionner les segments
communs a du sens et ne change rien au fait qu'ils peuvent bouger si
la route ou la rivière a physiquement bougé.

De plus si les plans cadastraux d'une commune et d'une autre ne sont
pas d'accord sur la position des frontières, on est bien obligé de
faire une conflation sur des éléments communs. Les défauts
d'alignement sont nombreux, et si on n'est pas capable même de
différencier les deux traits d'origine de la route ou de la rivière
qui passe entre les deux, je ne vois strictement aucun intérêt à
vouloir multiplier les tracés pour rien. Même si le cours d'eau bouge
un peu ou est réaligné pour rester entre les tracé des rives, cela ne
changera strictement rien à la précision du tracé des frontières
administratives.

Note: je ne parlais évidemment pas du cas où un cours d'eau change de
lit pour passer par un autre bras en asséchant l'ancien. le bras mort
reste là où il est, même si c'est une frontière administrative. Et
s'il est alors utilisé pour faire quelquechose, les communes iront
faire du repérage voire un bornage sur les parcelles afin de se
partager récupérées les terrains équitablement, ou négocieront avec
les propriétaires qui ne souhaiteraient pas garder des microparcelles
séparées sur deux communes

Les échanges de parcelles entre communes c'est assez courant, surtout
lors de la construction de voiries, et quand cela se produit le
cadastre est mis à jour dans l'année ; par exemple si pour aménager un
carrefour au départ entièrement sur une commune, pour en faire un
rond-point dont une infime partie va empiéter sur la commune voisine,
qui ne veut pas prendre en charge les travaux et l'entretien de ce
rond-point, une opération de cession de parcelles, va avoir lieu, ou
d'échange équitable, et la limite entre les communes restera malgré
tout au bord de ce même carrefour réaménagé

C'est assez facile si les parcelles sont déjà dans le domaine public
d'une des deux communes concernées, plus compliqué s'il faut pour ça
des expropriations partielles de propriétés privées ou si
l'aménagement coupe une propriété privée de telle façon qu'il reste
alors une petite bande privée inutilisable par l'ancien propriétaire
car devenu impossible à clotûrer par exemple pour n'en faire qu'un
carré de pelouse; la commune devra acheter la bande résiduelle aussi.
C'est plus compliqué aussi si un échange de parcelles n'est pas
possible dans le même secteur pour conserver la surface des terres
d'une des communes (et il n'est pas question pour des raisons fiscales
de déplacer des propriétés privées d'une commune à l'autre, du moins
pas sans l'accord des propriétaires qui pourraient cependant y être
incités par d'autres mesures de compensation, y compris le fait de
rendre une parcelle constructible ou lotissable, car viabilisée sans
frais pour lui en même temps que l'arrivée de la nouvelle voirie et
des réseaux qui vont avec)

Le 6 mars 2013 14:58, Tetsuo Shima  a écrit :
> Quand physiquement ce n'est pas la meme chose il est souvent judicieux de ne
> pas le faire supporter par le meme objet effectivement ca evite des éditions
> sauvages lorsque qu'un cours d'eau est modifié a priori la limite
> administrative n'a pas a l’être trivialement. On a le meme souci avec les
> landuse supporté par des highway ou meme des building!
>
> Pour ce qui est d'avoir deux objet superposé et de même géométrie ca génere
> une alerte certes mais ce n'est pas forcément un doublon.
>
> Le 6 mars 2013 14:07, Jo.  a écrit :
>>
>> Je ne me rappel plus si c'était un conseil d'édition (sans obligation)
>> mais si possible on ne doit pas fusionner sur le même segment une route ou
>> un cours d'eau avec un frontière.
>>
>> Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et
>> fausser les limites administrative.
>>
>> Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre
>> et je ne pense pas qu'on met à jour le cadastre après chaque hivers.
>>
>>
>>
>>
>> Le 6 mars 2013 13:38, Philippe Verdy  a écrit :
>>
>>> Justement, des rivières, routes, voies ferrées sont parfois aussi des
>>> limites administratives. Et c'est là qu'on trouve le plus des
>>> source=inconnue ! Et ça commence à se propager ailleurs sur d'autres
>>> objets.
>>>
>>> Le 6 mars 2013 10:51, Pieren  a écrit :
>>> > 2013/3/6 Philippe Verdy :
>>> >
>>> >> On dirait que cela a été ajouté uniquement pour faire disparaître le
>>> >> marquage dans Osmose, sans rien corriger du tout.
>>> >
>>> > De quelle analyse Osmose parle-t-on ? La 

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Marc SIBERT]

Bonjour,

Je viens de contacter M. JF Faudi de Spot Image (rencontré lors du barcamp
2010) pour lui demander les images originales libérées des contraintes de
réutilisation.

A+


Le 6 mars 2013 14:56, Cédric Moro  a écrit :

>  Merci de vos réponses.
>
> 1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci
>
> 2/ Images SPOT/Pléiades :
>
> Elles sont dispo à ces adresses :
>
> http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html
>
> http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434
>
> Nous avons eu un contact téléphonique et fait une demande écrite au SERTIT
> qui a effectué le traitement des images en télédétection. Nous avions une
> difficulté à importer leurs images KML dans crowdmap ou même googlemap et
> nous avons pu les ouvrir seulement dans Googleearth pour les avoir sous une
> forme géolocalisée.
>
> Le problème était que les traitements et légendes étaient incrustés dans
> le raster de l'image (qui n'est qu'une JPG) et pas sous forme d'objets
> vecteurs géoloc qui auraient été plus facilement exportables. Pour la
> région de Tuléar, nous avons donc mis des dizaines d'heures à refaire les
> polygones et points. On a perdu beaucoup de temps et de la précision, et
> sur cette zone seulement. Nous avons eu un contact avec le SERTIT hier soir
> et nous leur avons donc demander de bénéficier des couches de traitement en
> télédétection au format KML/KMZ pour pouvoir les intégrer à notre crowdmap,
> surtout pour d'autres régions touchées sur lesquelles nous n'avons pas
> encore déployé de données spatiales. La demande est en cours d'approbation
> au siège.
>
> Concernant l'utilisation des images satellites en dehors de la
> catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous
> rapporte (sans jugement personnel) :
> Les droits d'auteurs à de fins commerciales et la non réutilisation en
> dehors de la situation de la catastrophe naturelle et de sa réponse
> d'urgence.
>
> Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique
> des formats d'échange de données en période de catastrophe pour qu'à
> l'avenir, on ne perde plus autant de temps.
>
> 4/ Ceux qui gèrent la carte, dont moi, ne sommes pas sur le terrain mais
> en contact avec les acteurs sur place par téléphone et email , surtout avec
> les Pompiers de l'urgence internationale, et par Réseaux sociaux pour
> certains habitants sur place.
>
> 5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite.
>
> 6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais
> sur place, certains s'intéressent en détail dans la carto libre, je leur
> montrerai le chemin d'OSM et d'Ushahidi :-)
>
> Merci encore à tous et à bientôt,
>
>
> +33 5 35 54 19 27
> Skype : roomilissimo
> Twitter : @Moro_Cedric
> Coordinateur du VOST Francophone
> Membre de la communauté MSGU (Médias sociaux en gestion d'urgence)
> Webmaster des Pompiers de l'urgence internationale
> www.pompiers-urgence.org
> www.i-resilience.fr
>
> > Date: Wed, 6 Mar 2013 14:43:25 +0100
> > From: j...@arkemie.com
> > To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com
> > Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le
> Cyclone Haruna à Madagascar.
>
> >
> > Bonjour,
> >
> > Le mieux est effectivement de récupérer les données directement chez
> > Geofabrik, où elles sont mises à jour quotidiennement.
> >
> > Au cas où cela pourrait être utile, j'ai fait une conversion rapide de
> > leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est
> > dans :
> > http://osm.arkemie.org/madagascar/madagascar.kml.zip
> > et les fichiers individuels sont dans le répertoire :
> > http://osm.arkemie.org/madagascar/
> > (Le fichier LISEZMOI liste les commandes - toutes simples - que j'ai
> > utilisées).
> >
> > Lundi dernier, j'avais entré dans OSM les villages que je voyais dans
> > Bing le long de la côte entre Toliara et Morombe, et qui n'y étaient pas
> > déjà (emprises indiquées comme landuse=residential). Pour trouver les
> > noms, j'ai eu l'impression que GNS
> > (https://wiki.openstreetmap.org/wiki/GNS -
> > http://geonames.nga.mil/ggmagaz/) est une source relativement précise et
> > complète à Madagascar (par rapport à son état dans d'autres pays). Au
> > point qu'il semble qu'on puisse même utiliser leur couche WMS pour
> > trouver les lieux habités. (Et bien sûr leur moteur de recherche pour
> > géolocaliser des lieux qui ne sont pas (encore) dans OSM).
> >
> > Je ne savais pas si ça avait une chance de servir. Content de voir que
> > oui, et qu'il y a des gens sur le terrain.
> >
> > Bien cordialement,
> >
> > Jean-Guilhem
> >
> >
> > Le 06/03/2013 13:15, Eric Sibert a écrit :
> > > Bonjour,
> > >
> > > Je connais pas mal Madagascar et un peu Tuléar. On peut trouver
> > > quelques généralités sur la cartographie du pays dans le wiki:
> > > http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar
> > >
> > 

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Pierre Béland]

J'ai interprété la zone à partir de l'application Crowdmap. Je suggère que 
cette application-ci soit révisée pour y mettre la carte OSM comme carte de 
base.

La tâche suivante peut être utilisée pour  cartographier la zone de Toliera 
(Tulear) à partir de l'imagerie Bing.
http://tasks.hotosm.org/job/206
J'ai aussi publié un message twitter pour annoncer cette tâche. Vous pouvez 
faire un Retweet.
https://twitter.com/pierzen

Si la zone est mal définie, prière de m'aviser.


 
Pierre 



>
> De : Pierre Béland 
>À : Discussions sur OSM en français  
>Envoyé le : Mercredi 6 mars 2013 8h50
>Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone 
>Haruna à Madagascar.
> 
>
>Voir le lien suivant où on peut observer l'imagerie Bing disponible.
>http://www.harrywood.co.uk/maps/bingosm.html?lat=-23.362526698877858&lon=43.67677691268953&zoom=18&bingopacity=50
>
>Nous pouvons définir une zone à cartographier et ajouter une tâche sur le 
>Gestionnaire de tâches de HOT si vous le jugez à propos. Nous pourrons ainsi 
>faire la carte OSM de base Avant.  A partir de openstreetmap.org vous pouvez 
>simplement zoomer pour definir la zone a couvrir. Le bouton exporter vous 
>permettra d'obtenir les le bbox définissant cette zone,
>
>
>
>Je pourrai aussi alerter la communauté Humanitarian OpenStreetMap (HOT).
>
> 
>Pierre Béland
>Humanitarian OpenStreetMap
>
>
>
>>
>> De : Marc SIBERT 
>>À : Discussions sur OSM en français  
>>Envoyé le : Mercredi 6 mars 2013 7h49
>>Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone 
>>Haruna à Madagascar.
>> 
>>
>>Bonjour,
>>
>>Concernant le dernier point "toute autre action...", je me posais la question 
>>de la disponibilité des images SPOT sous une licence compatible avec OSM afin 
>>que des contributeurs non-locaux (contributions dans le fauteuil :-) puissent 
>>participer.
>>En particulier, suivant la date des images (avant/après) il sera possible 
>>d'affiner le bati sur la zone concernée par l'inondation et/ou d'indiquer 
>>dans OSM les détails visibles de l’infrastructure routière ; ces éléments 
>>pouvant servir de repère géographique pour des remontées d'informations 
>>locales.
>>
>>
>>En cas de réponse positive, je pense (et je m'avance sur ce point) que l'asso 
>>OSM-FR pourra fournir les moyens techniques pour exploiter les images 
>>(tuilage, hébergement, etc.)
>>
>>
>>
Cordialement,
>>
>>A+
>>
>>
>>
>>
>>Le 6 mars 2013 11:23, Cédric Moro  a écrit :
>>
>>Bonjour,
>>>
>>>Nous sommes une équipes de bénévoles qui intervenons actuellement sur le 
>>>cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et 
>>>Morombé. 
>>>
>>>Le bilan provisoire d'hier est de :  
>>> * 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 
>>> 1 Sakaraha, 4 Toliara II, 1 Betroka) ;
>>> * 16 disparus (Toliara I) ;
>>> * 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 
>>> Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano);
>>> * 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II, 
>>> 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 
265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 
Vangaindrano, 1 562 Ankazoabo) ;
>>> * 13 882 sans abris (892 Toliara I,2 000 Sakaraha, 2 271 Toliara II, 1 
>>> 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459 
>>> Antakataka Sud, 332 Vangaindrano, 1 562 Ankazoabo) ;
>>> * 7 402 cases totalement détruites (100 Sakahara, 120 
Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 
920 Toliara II) ;
>>> * 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 
>>> Sakaraha, 372 Ampanihy, 32 Betroka) 
>>>
>>>Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence 
>>>internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes 
>>>pour des soins en urgence. Nos membres sont celui du VOST Francophone 
>>>(nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue 
>>>de la communauté des #MSGU, Médias sociaux en gestion d'urgence : 
>>>http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity 
>>>Road s'est également jointe à notre action. Grâce au travail d'impacts sur 
>>>les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées 
>>>d'infos des médias sociaux et sites internet, nous avons pu mieux orienter 
>>>l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara.
>>>
>>>
>>>
>>>Nous utilisons une carte collaborative pour recenser les besoins 
>>>humanitaires et améliorer la réponse de crise : https://haruna.crowdmap.com
>>>
>>>
>>>Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et 
>>>de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car 
>>>il nous permet d'avoir une vision en image satellite, importante pour 
>>>comprendre la géographie locale tout comme pour bénéifi

Re: [OSM-talk-fr] source=inconnue

[Jo.]

Pour les cours d'eau, ce sont des éléments physique qui sont mouvant alors
que les frontières sont fixée. On peut avoir la même logique avec les
routes dont les autorité locale peuvent modifier le tracé sans respecter à
la lettre les frontière.

Près de chez moi, un cours d'eau change doucement chaque année pourtant il
est en plaine et le débit en hivers n'est pas très fort. J'avais par erreur
modifier les frontières en suivant le cours d'eau mais le cadastre indiquai
autre chose même si les écarts sont de quelques mètres, j'ai du tout
séparer et réparer pendant une longue demie journée de perdue :
http://osm.org/go/xVlCOin3O-

Pareil pour les routes et ponts avec un exemple passant au dessus d'une
autoroute : http://osm.org/go/xVlmmAVBA--

Après *ce n'est qu'un conseil d'édition*, c'est simplement pour éviter de
créer/propager une erreur. Séparer les éléments physique des éléments
immatériel me semble conseillé pour éviter de nombreuses heures de
correction.


Le 6 mars 2013 15:15, Pieren  a écrit :

> 2013/3/6 Francescu GAROBY :
>
> > commune, créant alors un "vide", qui correspond au lit de la rivière.
> D'où
> > le choix de prendre le tracé central dudit cours d'eau.
>
> J'ai rencontré des cas similaires avec des chemins. Soit une commune
> fixait la limite au milieu et l'autre commune au bord, soit chacune un
> bord avec un vide, soit chacune un bord avec superposition. Ou même un
> choix qui variait à l'intérieur de la commune d'une planche à
> l'autre... Evidemment, dans ces cas-là, on est obligé de faire un
> choix subjectif. A moins de contacter les maires des communes
> concernées pour savoir qui est en charge de l'entretien du dit chemin
> (en espérant qu'ils disent la même chose ;-)
> Certaines régions semblent plus touchées que d'autres par ces
> aberrations. On espère que la future intégration des cadastres DGFiP
> et IGN permettront de remettre à plat ces "erreurs géométriques"
>
> > Et je plaide coupable (et j'assume complètement) le fait que, lorsqu'une
> > frontière de commune et un tracé de cours d'eau/route se superpose,
> c'est ce
> > dernier que je retiens pour les relations. Voyez là une interprétation
> de la
> > règle "le terrain prévaut".
>
> Le terrain n'a aucune valeur en matière de limite administrative
> puisqu'elle est invisible. Sauf si on peut voir sur le sol une jolie
> ligne blanche ou une clôture symbolisant cette limite dans certaines
> contrées. Je connais au moins un exemple de parcelles agricoles qui
> sont passées au fil des ans de l'autre côté d'un ruisseau (disons
> plutôt que c'est le ruisseau qui a bougé et pas les parcelles, hein).
> Et bien ces parcelles font toujours parties de la même commune. La
> règle du "terrain prévaut" est donc fausse dans ce cas.
>
> 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] source=inconnue

[Jo.]

Bonjour Fracescu,


Oui cela peut arriver si on superpose à l'identique les deux segments mais
on peut souvent différencier les segments en les laissant proche.

Ce matin j'ai encore séparer une frontière et une départementale. Il y
avait de petit décalage avec le cadastre (maxi 2 mètres) alors que la route
suivait parfaitement l'imagerie Bing.
Par défaut je crée une parallèle et définie la route (ou cours d'eau) sur
le nouveau segment, j'en profite pour l'ajuster à l'imagerie et effectue
une simplification du segment. Après ce travail, les segments sont toujours
proche mais les nœuds ne peuvent plus être fusionné car ils ont été
retouché.

Le 6 mars 2013 14:12, Francescu GAROBY  a écrit :

> Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de
> lignes superposées, ce que le validateur de Josm n'apprécie que très
> modérément !
> Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le
> temps pour pouvoir être utilisé comme frontière. Les (rares) cas où un
> cours d'eau change de lit tous les ans (en France) sont sans doute
> justement les cas où la frontière n'a plus rien à voir avec le cours d'eau
> depuis longtemps (je pense à la limite Bretagne/Basse-Normandie, où
> l'embouchure du Couesnon n'est plus la frontière entre ces 2 régions
> depuis...)
>
> Francescu
>
>
> Le 6 mars 2013 14:07, Jo.  a écrit :
>
> Je ne me rappel plus si c'était un conseil d'édition (sans obligation)
>> mais si possible on ne doit pas fusionner sur le même segment une route ou
>> un cours d'eau avec un frontière.
>> Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé
>> et fausser les limites administrative.
>>
>> Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre
>> et je ne pense pas qu'on met à jour le cadastre après chaque hivers.
>>
>>
>>
>>
>> Le 6 mars 2013 13:38, Philippe Verdy  a écrit :
>>
>> Justement, des rivières, routes, voies ferrées sont parfois aussi des
>>> limites administratives. Et c'est là qu'on trouve le plus des
>>> source=inconnue ! Et ça commence à se propager ailleurs sur d'autres
>>> objets.
>>>
>>> Le 6 mars 2013 10:51, Pieren  a écrit :
>>> > 2013/3/6 Philippe Verdy :
>>> >
>>> >> On dirait que cela a été ajouté uniquement pour faire disparaître le
>>> >> marquage dans Osmose, sans rien corriger du tout.
>>> >
>>> > De quelle analyse Osmose parle-t-on ? La seule que je vois qui
>>> > pourrait correspondre à un problème de source manquante est l'item
>>> > 2040 mais cela ne concerne que les limites administratives.
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> 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] Cartopartie des panneaux publicitaires à Paris - samedi 16 mars 2013

[Francescu GAROBY]

Bonjour,
Très bonne idée !
Je remarque cependant qu'il manque (selon moi) quelque chose dans la page
du wiki : comment indiquer qu'un panneau publicitaire est aussi (sur
l'autre face, celle qui n'est pas tournée vers la route) un panneau
affichant un plan de la ville/du quartier ?

Francescu


Le 6 mars 2013 15:12, Arthur Lutz  a écrit :

> Bonjour à tous,
>
> Simplement pour vous signaler une cartopartie un peu particulière à Paris
> : http://www.cartographiepublicitaire.org/2013/02/cartopartie/
>
> Cette cartopartie sera spécifique aux panneaux publicitaires. Récolter des
> informations sur les panneaux environnants, leur emplacement géographique,
> le nom de l’afficheur, la taille, le type de panneau, etc.
>
> Pour plus d'informations sur l'initiative voir le site :
> http://www.cartographiepublicitaire.org/
>
> J'avais discuté de cette initiative sur la liste il y a plusieurs mois, la
> cartographie avance ainsi que les visualisations. Nous nous basons sur
> http://wiki.openstreetmap.org/wiki/FR:Key:advertising si certains ont des
> retours constructifs à faire, ils sont les bienvenus.
>
> Vous êtes bien évidemment aussi les bienvenus à la cartopartie. J'éspère
> par ce type de cartographie "spécifique" eveiller la curiosité pour OSM et
> éventuellement initier de nouveaux contributeurs.
>
> Arthur
>
> --
> http://arthur.lutz.im
>
> ___
> 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] source=inconnue

[Pieren]

2013/3/6 Francescu GAROBY :

> commune, créant alors un "vide", qui correspond au lit de la rivière. D'où
> le choix de prendre le tracé central dudit cours d'eau.

J'ai rencontré des cas similaires avec des chemins. Soit une commune
fixait la limite au milieu et l'autre commune au bord, soit chacune un
bord avec un vide, soit chacune un bord avec superposition. Ou même un
choix qui variait à l'intérieur de la commune d'une planche à
l'autre... Evidemment, dans ces cas-là, on est obligé de faire un
choix subjectif. A moins de contacter les maires des communes
concernées pour savoir qui est en charge de l'entretien du dit chemin
(en espérant qu'ils disent la même chose ;-)
Certaines régions semblent plus touchées que d'autres par ces
aberrations. On espère que la future intégration des cadastres DGFiP
et IGN permettront de remettre à plat ces "erreurs géométriques"

> Et je plaide coupable (et j'assume complètement) le fait que, lorsqu'une
> frontière de commune et un tracé de cours d'eau/route se superpose, c'est ce
> dernier que je retiens pour les relations. Voyez là une interprétation de la
> règle "le terrain prévaut".

Le terrain n'a aucune valeur en matière de limite administrative
puisqu'elle est invisible. Sauf si on peut voir sur le sol une jolie
ligne blanche ou une clôture symbolisant cette limite dans certaines
contrées. Je connais au moins un exemple de parcelles agricoles qui
sont passées au fil des ans de l'autre côté d'un ruisseau (disons
plutôt que c'est le ruisseau qui a bougé et pas les parcelles, hein).
Et bien ces parcelles font toujours parties de la même commune. La
règle du "terrain prévaut" est donc fausse dans ce cas.

Pieren

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

[OSM-talk-fr] Cartopartie des panneaux publicitaires à Paris - samedi 16 mars 2013

[Arthur Lutz]

Bonjour à tous,

Simplement pour vous signaler une cartopartie un peu particulière à Paris :
http://www.cartographiepublicitaire.org/2013/02/cartopartie/

Cette cartopartie sera spécifique aux panneaux publicitaires. Récolter des
informations sur les panneaux environnants, leur emplacement géographique,
le nom de l’afficheur, la taille, le type de panneau, etc.

Pour plus d'informations sur l'initiative voir le site :
http://www.cartographiepublicitaire.org/

J'avais discuté de cette initiative sur la liste il y a plusieurs mois, la
cartographie avance ainsi que les visualisations. Nous nous basons sur
http://wiki.openstreetmap.org/wiki/FR:Key:advertising si certains ont des
retours constructifs à faire, ils sont les bienvenus.

Vous êtes bien évidemment aussi les bienvenus à la cartopartie. J'éspère
par ce type de cartographie "spécifique" eveiller la curiosité pour OSM et
éventuellement initier de nouveaux contributeurs.

Arthur

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

Re: [OSM-talk-fr] source=inconnue

[Tetsuo Shima]

Quand physiquement ce n'est pas la meme chose il est souvent judicieux de
ne pas le faire supporter par le meme objet effectivement ca evite des
éditions sauvages lorsque qu'un cours d'eau est modifié a priori la limite
administrative n'a pas a l’être trivialement. On a le meme souci avec les
landuse supporté par des highway ou meme des building!

Pour ce qui est d'avoir deux objet superposé et de même géométrie ca génere
une alerte certes mais ce n'est pas forcément un doublon.

Le 6 mars 2013 14:07, Jo.  a écrit :

> Je ne me rappel plus si c'était un conseil d'édition (sans obligation)
> mais si possible on ne doit pas fusionner sur le même segment une route ou
> un cours d'eau avec un frontière.
> Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et
> fausser les limites administrative.
>
> Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre
> et je ne pense pas qu'on met à jour le cadastre après chaque hivers.
>
>
>
>
> Le 6 mars 2013 13:38, Philippe Verdy  a écrit :
>
> Justement, des rivières, routes, voies ferrées sont parfois aussi des
>> limites administratives. Et c'est là qu'on trouve le plus des
>> source=inconnue ! Et ça commence à se propager ailleurs sur d'autres
>> objets.
>>
>> Le 6 mars 2013 10:51, Pieren  a écrit :
>> > 2013/3/6 Philippe Verdy :
>> >
>> >> On dirait que cela a été ajouté uniquement pour faire disparaître le
>> >> marquage dans Osmose, sans rien corriger du tout.
>> >
>> > De quelle analyse Osmose parle-t-on ? La seule que je vois qui
>> > pourrait correspondre à un problème de source manquante est l'item
>> > 2040 mais cela ne concerne que les limites administratives.
>>
>> ___
>> 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] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Eric Sibert]

De mémoire, j'ai du relever un nombre significatif de points  
caractéristiques au GPS dans Tuléar, ainsi qu'à l'aéroport au sud et  
sans doute à Mangily 15 km au nord. J'ai aussi transféré mes traces  
GPS dans OSM. Ça peut permettre de caler des vues aériennes ou  
satellites (Bing inclus).



Eric


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

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Cédric Moro]

Merci de vos réponses.

1/ HotOSM : Je viens de tweeter un message à ce sujet. Merci

2/ Images SPOT/Pléiades :

Elles sont dispo à ces adresses :
http://sertit.u-strasbg.fr/SITE_RMS/2013/02_rms_Madagascar_2013/02_rms_Madagascar_2013.html
http://www.disasterscharter.org/web/charter/activation_details?p_r_p_1415474252_assetId=ACT-434

Nous
 avons eu un contact téléphonique et fait une demande écrite au SERTIT 
qui a effectué le traitement des images en télédétection. Nous avions 
une difficulté à importer leurs images KML dans crowdmap ou même 
googlemap et nous avons pu les ouvrir seulement dans Googleearth pour 
les avoir sous une forme géolocalisée. 

Le problème était que les traitements et 
légendes étaient incrustés dans le raster de l'image (qui n'est qu'une 
JPG) et pas sous forme d'objets vecteurs géoloc qui auraient été plus 
facilement exportables. Pour la région de Tuléar, nous avons donc mis 
des dizaines d'heures à refaire les polygones et points. On a perdu 
beaucoup de temps et de la précision, et sur cette zone seulement. Nous 
avons eu un contact avec le SERTIT hier soir et nous leur avons donc 
demander de bénéficier des couches de traitement en télédétection au 
format KML/KMZ pour pouvoir les intégrer à notre crowdmap, surtout pour 
d'autres régions touchées sur lesquelles nous n'avons pas encore déployé
 de données spatiales. La demande est en cours d'approbation au siège.

Concernant l'utilisation des images satellites en dehors de la 
catastrophe, on nous a bien dit qu'il y avait 2 problèmes que je vous 
rapporte (sans jugement personnel) :
Les droits d'auteurs à de fins 
commerciales et la non réutilisation en dehors de la situation de la 
catastrophe naturelle et de sa réponse d'urgence.

Tout ce travail avec le SERTIT fera, j'espère, avancer la problématique des 
formats d'échange de données en période de catastrophe pour qu'à l'avenir, on 
ne perde plus autant de temps.

4/ Ceux qui gèrent
 la carte, dont moi, ne sommes pas sur le terrain mais en contact avec les 
acteurs sur place par téléphone et email , surtout avec les Pompiers de 
l'urgence internationale,
 et par Réseaux sociaux pour certains habitants sur place.

5/ Bravo pour la réactivité sur le KML, de Mada je le teste tout de suite.

6/ A priori, personne d'OSM sur place. En tous cas, si parmi nos relais sur 
place, certains s'intéressent en détail dans la carto libre, je leur montrerai 
le chemin d'OSM et d'Ushahidi :-)

Merci encore à tous et à bientôt,

+33 5 35 54 19 27
Skype : roomilissimo
Twitter : @Moro_Cedric
Coordinateur du VOST Francophone
Membre de la communauté MSGU (Médias sociaux en gestion d'urgence)
Webmaster des Pompiers de l'urgence internationale
www.pompiers-urgence.org
www.i-resilience.fr

> Date: Wed, 6 Mar 2013 14:43:25 +0100
> From: j...@arkemie.com
> To: talk-fr@openstreetmap.org; moro_geogra...@hotmail.com
> Subject: Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone 
> Haruna à Madagascar.
> 
> Bonjour,
> 
> Le mieux est effectivement de récupérer les données directement chez
> Geofabrik, où elles sont mises à jour quotidiennement.
> 
> Au cas où cela pourrait être utile, j'ai fait une conversion rapide de
> leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est
> dans :
> http://osm.arkemie.org/madagascar/madagascar.kml.zip
> et les fichiers individuels sont dans le répertoire :
> http://osm.arkemie.org/madagascar/
> (Le fichier LISEZMOI liste les commandes - toutes simples - que j'ai
> utilisées).
> 
> Lundi dernier, j'avais entré dans OSM les villages que je voyais dans
> Bing le long de la côte entre Toliara et Morombe, et qui n'y étaient pas
> déjà (emprises indiquées comme landuse=residential). Pour trouver les
> noms, j'ai eu l'impression que GNS
> (https://wiki.openstreetmap.org/wiki/GNS -
> http://geonames.nga.mil/ggmagaz/) est une source relativement précise et
> complète à Madagascar (par rapport à son état dans d'autres pays). Au
> point qu'il semble qu'on puisse même utiliser leur couche WMS pour
> trouver les lieux habités. (Et bien sûr leur moteur de recherche pour
> géolocaliser des lieux qui ne sont pas (encore) dans OSM).
> 
> Je ne savais pas si ça avait une chance de servir. Content de voir que
> oui, et qu'il y a des gens sur le terrain.
> 
> Bien cordialement,
> 
> Jean-Guilhem
> 
> 
> Le 06/03/2013 13:15, Eric Sibert a écrit :
> > Bonjour,
> >
> > Je connais pas mal Madagascar et un peu Tuléar. On peut trouver
> > quelques généralités sur la cartographie du pays dans le wiki:
> > http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar
> >
> >> Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette
> >> cartographie, notamment sur le centre-ville où les données sont
> >> beaucoup plus détaillées et qui nous ont été précisieuses pour
> >> localiser les écoles (centres d'hébergement, cycbercafés...).
> >
> > Je suis fort aise que mon modeste travail de fourmi ait pu être utile :-p
> >
> > Par contre, je n'ai pas vraiment

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Pierre Béland]

Voir le lien suivant où on peut observer l'imagerie Bing disponible.
http://www.harrywood.co.uk/maps/bingosm.html?lat=-23.362526698877858&lon=43.67677691268953&zoom=18&bingopacity=50

Nous pouvons définir une zone à cartographier et ajouter une tâche sur le 
Gestionnaire de tâches de HOT si vous le jugez à propos. Nous pourrons ainsi 
faire la carte OSM de base Avant.  A partir de openstreetmap.org vous pouvez 
simplement zoomer pour definir la zone a couvrir. Le bouton exporter vous 
permettra d'obtenir les le bbox définissant cette zone,


Je pourrai aussi alerter la communauté Humanitarian OpenStreetMap (HOT).

 
Pierre Béland
Humanitarian OpenStreetMap



>
> De : Marc SIBERT 
>À : Discussions sur OSM en français  
>Envoyé le : Mercredi 6 mars 2013 7h49
>Objet : Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone 
>Haruna à Madagascar.
> 
>
>Bonjour,
>
>Concernant le dernier point "toute autre action...", je me posais la question 
>de la disponibilité des images SPOT sous une licence compatible avec OSM afin 
>que des contributeurs non-locaux (contributions dans le fauteuil :-) puissent 
>participer.
>En particulier, suivant la date des images (avant/après) il sera possible 
>d'affiner le bati sur la zone concernée par l'inondation et/ou d'indiquer dans 
>OSM les détails visibles de l’infrastructure routière ; ces éléments pouvant 
>servir de repère géographique pour des remontées d'informations locales.
>
>
>En cas de réponse positive, je pense (et je m'avance sur ce point) que l'asso 
>OSM-FR pourra fournir les moyens techniques pour exploiter les images 
>(tuilage, hébergement, etc.)
>
>
>
Cordialement,
>
>A+
>
>
>
>
>Le 6 mars 2013 11:23, Cédric Moro  a écrit :
>
>Bonjour,
>>
>>Nous sommes une équipes de bénévoles qui intervenons actuellement sur le 
>>cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et 
>>Morombé. 
>>
>>Le bilan provisoire d'hier est de :  
>>  * 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 
>> 1 Sakaraha, 4 Toliara II, 1 Betroka) ;
>>  * 16 disparus (Toliara I) ;
>>  * 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 
>> Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano);
>>  * 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II, 
>> 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 
265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 
Vangaindrano, 1 562 Ankazoabo) ;
>>  * 13 882 sans abris (892 Toliara I,2 000 Sakaraha, 2 271 Toliara II, 1 
>> 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459 
>> Antakataka Sud, 332 Vangaindrano, 1 562 Ankazoabo) ;
>>  * 7 402 cases totalement détruites (100 Sakahara, 120 
Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 
920 Toliara II) ;
>>  * 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 
>> Sakaraha, 372 Ampanihy, 32 Betroka) 
>>
>>Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence 
>>internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes 
>>pour des soins en urgence. Nos membres sont celui du VOST Francophone 
>>(nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue 
>>de la communauté des #MSGU, Médias sociaux en gestion d'urgence : 
>>http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity 
>>Road s'est également jointe à notre action. Grâce au travail d'impacts sur 
>>les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées 
>>d'infos des médias sociaux et sites internet, nous avons pu mieux orienter 
>>l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara.
>>
>>
>>
>>Nous utilisons une carte collaborative pour recenser les besoins humanitaires 
>>et améliorer la réponse de crise : https://haruna.crowdmap.com
>>
>>
>>Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et 
>>de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car 
>>il nous permet d'avoir une vision en image satellite, importante pour 
>>comprendre la géographie locale tout comme pour bénéificier des infos 
>>toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans 
>>cette cartographie, notamment sur le centre-ville où les données sont 
>>beaucoup plus détaillées et qui nous ont été précisieuses pour localiser les 
>>écoles (centres d'hébergement, cycbercafés...).
>>
>>
>>
>>Nous demandons donc à tout membre de la communauté d'OSM votre participation 
>>bénévole pour :
>>- Extraire le sud-ouest de Madagascar en format KML ou KMZ afin de l'intégrer 
>>comme couche dans Crowdmap. Nous pouvons chercher techniquement comment faire 
>>de notre côté mais nous y gagnerons du temps si quelqu'un de chez vous s'en 
>>occupe.
>>- Participer sur le terrain à de la remontée d'informations humanitaires 
>>géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, voir de 
>>Sakaraha, Betiky,

Re: [OSM-talk-fr] source=inconnue

[Samy Mezani]

le 06/03/2013 14:36, Philippe Verdy a écrit:

Une rivière ne change plus radicalement de lit en France, hormis les
ruisseaux de montagne. Elles sont presque toutes aménagées alors par
l'homme, et tant que la ligne passe dans le lit, mêm esi ce lit change
de largeur selon les nivaux d'eau, la ligne reste dans la rivière et


Bonjour,
Tu es déjà allé voir la Loire ou le Doubs ? Tu constateras que, oui, une 
rivière peut changer radicalement de lit en très peu de temps, par 
seulement en montagne.


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

Re: [OSM-talk-fr] source=inconnue

[Francescu GAROBY]

Sauf qu'il m'est déjà arrivé que l'export généré par le cadastre définisse
la limite d'une commune comme étant la rive (gauche ou droite, selon) d'un
cours d'eau, et la même chose (droite ou gauche, cette fois) pour l'autre
commune, créant alors un "vide", qui correspond au lit de la rivière. D'où
le choix de prendre le tracé central dudit cours d'eau.
Et je plaide coupable (et j'assume complètement) le fait que, lorsqu'une
frontière de commune et un tracé de cours d'eau/route se superpose, c'est
ce dernier que je retiens pour les relations. Voyez là une interprétation
de la règle "le terrain prévaut".

Francescu


Le 6 mars 2013 14:37, Pieren  a écrit :

> 2013/3/6 Francescu GAROBY :
> > Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de
> > lignes superposées, ce que le validateur de Josm n'apprécie que très
> > modérément !
>
> Si c'est le cas, c'est un problème dans le validateur (ça ne serait
> pas la première fois).
>
> > Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le
> > temps pour pouvoir être utilisé comme frontière.
>
> Euh, ça dépend vraiment de la largeur du cour d'eau, de la force des
> courants, de l'intensité d'événements exceptionnels (crues), des
> aménagements. De nombreuses limites sont aussi basées sur des
> ruisseaux avec un relevé déjà approximatif dans les vieux plans
> cadastraux d'origine (qui ne disposaient pas de vues aériennes comme
> aujourd'hui). Non, on ne peut vraiment pas dire que les tracés de
> cours d'eaux soient stables dans le temps. Il y a malheureusement des
> gens qui se contentent d'ajouter un waterway comme limite communale
> par facilité alors que seul le tracé du cadastre compte (au risque de
> mettre des parcelles dans la mauvaise commune). Bien-sûr, on n'est pas
> obligé de mettre le waterway pile poil au milieu de la rivière pour
> être plus conforme avec le tracé du cadastre. Mais il y a ensuite
> toujours quelqu'un qui repassera derrière pour corriger le waterway à
> partir de Bing.
>
> Pieren
>
> ___
> 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] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Jean-Guilhem Cailton]

Bonjour,

Le mieux est effectivement de récupérer les données directement chez
Geofabrik, où elles sont mises à jour quotidiennement.

Au cas où cela pourrait être utile, j'ai fait une conversion rapide de
leurs shapefiles pour Madagascar en KML, avec ogr2ogr. Le résultat est
dans :
http://osm.arkemie.org/madagascar/madagascar.kml.zip
et les fichiers individuels sont dans le répertoire :
http://osm.arkemie.org/madagascar/
(Le fichier LISEZMOI liste les commandes - toutes simples - que j'ai
utilisées).

Lundi dernier, j'avais entré dans OSM les villages que je voyais dans
Bing le long de la côte entre Toliara et Morombe, et qui n'y étaient pas
déjà (emprises indiquées comme landuse=residential). Pour trouver les
noms, j'ai eu l'impression que GNS
(https://wiki.openstreetmap.org/wiki/GNS -
http://geonames.nga.mil/ggmagaz/) est une source relativement précise et
complète à Madagascar (par rapport à son état dans d'autres pays). Au
point qu'il semble qu'on puisse même utiliser leur couche WMS pour
trouver les lieux habités. (Et bien sûr leur moteur de recherche pour
géolocaliser des lieux qui ne sont pas (encore) dans OSM).

Je ne savais pas si ça avait une chance de servir. Content de voir que
oui, et qu'il y a des gens sur le terrain.

Bien cordialement,

Jean-Guilhem


Le 06/03/2013 13:15, Eric Sibert a écrit :
> Bonjour,
>
> Je connais pas mal Madagascar et un peu Tuléar. On peut trouver
> quelques généralités sur la cartographie du pays dans le wiki:
> http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar
>
>> Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette
>> cartographie, notamment sur le centre-ville où les données sont
>> beaucoup plus détaillées et qui nous ont été précisieuses pour
>> localiser les écoles (centres d'hébergement, cycbercafés...).
>
> Je suis fort aise que mon modeste travail de fourmi ait pu être utile :-p
>
> Par contre, je n'ai pas vraiment de contacts sur place actuellement.
>
>
>> Nous demandons donc à tout membre de la communauté d'OSM votre
>> participation bénévole pour :- Extraire le sud-ouest de Madagascar en
>> format KML ou KMZ afin
>
> Ca, je ne sais pas faire et comme je suis au boulot, je ne peux pas
> faire d'essais.
>
> Néanmoins, si certains veulent le faire, on peut récupérer toutes les
> données de Madagascar d'un seul coup chez geofabrik :
>
> http://download.geofabrik.de/openstreetmap/africa/
>
> Ce n'est pas bien gros (20 Mo max).
>
> Pour revenir à Tuléar (http://osm.org/go/k~5RokPm-), donc, avec le
> cyclone, la digue protégeant la ville de la rivière au nord a cédé
> d'où l’inondation du centre-ville (très plat). Ca a aussi coupé la RN9
> au sud du pont franchissant la dite rivière, coupant la circulation
> vers le nord dont Morombe.
>
> Pour se repérer en ville, il reste certes des noms de rues d'époque
> coloniale mais personne ne s'en sert. Les malgaches se repèrent avec
> les noms des quartiers. Il y en a quelques uns dans OSM mais je pense
> qu'il en manque pas mal.
>
> Il y a un découpage administratifs sous les communes, les fokontany.
> Ils possèdent des bureaux. Ils peuvent avoir le même nom que le
> quartier. Ils ne sont pas renseignés dans OSM.
>
> Il y a aussi une identifications des bâtiments et des ilots par lot
> (http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar#Adresses) mais
> si ce n'est pas renseigné avant la catastrophe, c'est trop tard. D'où
> l'intérêt d'avoir des éléments (centre de santé, écoles...)
> directement géo-référencés dans OSM.
>
> S'il y a des questions sur les spécificités malgaches, je peux essayer
> d'y répondre. Je peux peut-être aussi contacter des personnes en
> France qui connaissent mieux la ville.
>
> Et, quand vous serez revenus, je suis aussi intéressé par savoir
> quelles sont les informations que vous avez trouvé dans OSM qui vont
> ont été utiles et celles qui vous ont manquées.
>
> Eric
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
gpg 0x5939EAE2


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

Re: [OSM-talk-fr] source=inconnue

[Pieren]

2013/3/6 Francescu GAROBY :
> Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de
> lignes superposées, ce que le validateur de Josm n'apprécie que très
> modérément !

Si c'est le cas, c'est un problème dans le validateur (ça ne serait
pas la première fois).

> Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le
> temps pour pouvoir être utilisé comme frontière.

Euh, ça dépend vraiment de la largeur du cour d'eau, de la force des
courants, de l'intensité d'événements exceptionnels (crues), des
aménagements. De nombreuses limites sont aussi basées sur des
ruisseaux avec un relevé déjà approximatif dans les vieux plans
cadastraux d'origine (qui ne disposaient pas de vues aériennes comme
aujourd'hui). Non, on ne peut vraiment pas dire que les tracés de
cours d'eaux soient stables dans le temps. Il y a malheureusement des
gens qui se contentent d'ajouter un waterway comme limite communale
par facilité alors que seul le tracé du cadastre compte (au risque de
mettre des parcelles dans la mauvaise commune). Bien-sûr, on n'est pas
obligé de mettre le waterway pile poil au milieu de la rivière pour
être plus conforme avec le tracé du cadastre. Mais il y a ensuite
toujours quelqu'un qui repassera derrière pour corriger le waterway à
partir de Bing.

Pieren

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

Re: [OSM-talk-fr] source=inconnue

[Philippe Verdy]

Le 6 mars 2013 14:12, Francescu GAROBY  a écrit :
> Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de
> lignes superposées, ce que le validateur de Josm n'apprécie que très
> modérément !
> Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le
> temps pour pouvoir être utilisé comme frontière. Les (rares) cas où un cours
> d'eau change de lit tous les ans (en France) sont sans doute justement les
> cas où la frontière n'a plus rien à voir avec le cours d'eau depuis
> longtemps (je pense à la limite Bretagne/Basse-Normandie, où l'embouchure du
> Couesnon n'est plus la frontière entre ces 2 régions depuis...)

Une rivière ne change plus radicalement de lit en France, hormis les
ruisseaux de montagne. Elles sont presque toutes aménagées alors par
l'homme, et tant que la ligne passe dans le lit, mêm esi ce lit change
de largeur selon les nivaux d'eau, la ligne reste dans la rivière et
il n'y a pas de raison d'avori deux tracés différents pour le cours
central (imaginaire) et la ligne administrative (aussi imaginaire) :
même si cette ligne bouge de quelques mètres la limite entre les deux
communes reste tout de même cette rivière indépendamment du fait que
ses rives peuvent bouger (sans jamais toucher la ligne centrale
imaginaire). Le cas où c'est réellement défini de façon précise, avec
des coordonnées exactes et des bornes d'alignement, c'est pour les
frontières internationales (le tracé de la frontière franco-allemande
par exemple au milieu du Rhin : il y a des points précis positionnés
par exemple au milieu des ponts, et parfois des bouées ou balises.

Ce qui bouge réellement alors ce sont les rives, pas la ligne
imaginaire passant entre les rives (il n'y a pas de cas où une rive
change d'une année sur l'autre de territoire, même si le partage des
eaux peut bouger un peu, cela ne fait aucune importance car le cours
d'eau est géré en collaboration sur toute sa surface entre les rives.

L'autre cas plus problématique c'est pour les routes car là il y a
bien des terrains qui entrent en compte et peuvent changer d'usage :
si un rond-point est construit, il faut acheter du terrain pour une
collectivité ou une autre.

La France n'est pas le Bengladesh, les cours d'eau sont presque tous
maîtrisés, hormis les ruisseaux de montagne dont le lit est très
variable mais sur une surface déjà repérée comme inondable et
normalement laissée à son état naturel (le lit est donc plus large que
l'état actuel ou le plus courant du cours d'eau : cela se voit par es
enrochements, les galets déplacés, les zones boueuses). C'est
seulement si on décide de construire une route ou voie ferrée ou un
immeuble le long de ce cours d'eau qu'on prend un risque que l'ouvrage
soit emporté lors d'une crue, et qu'il est alors important de savoir à
quel territoire on attribue l'ouvrage construit (et cela ne peut se
faire sans accord mutuel des collectivités mitoyennes concernées, et
une expropriation légale des éventuels propriétaires. Avant que cela
arrive, il va s'écouler du temps.

Si jamais survient une catastrophe (crue exceptionnelle par exemple,
effondrement d'une falaise, glissement de terrain), il intervient une
autre procédure légale (l'arrêté de catastrophe naturelle qui permet
des indemnisations, ou de ne plus admettre d'autres constructions, et
de désigner une collectivité qui prendra en charge les nouveaux
terrains laissés après la catastrophe et éventuellement de
reconstruire différemment). Ce sera de toute façon assez visible et
l'effet sera durable (et on aura vite fait de modifier nos cartes dans
OSM, la catastrophe ne passera pas inaperçue).

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

Re: [OSM-talk-fr] source=inconnue

[Francescu GAROBY]

Le problème d'un tel conseil d'édition est qu'il crée alors un doublon de
lignes superposées, ce que le validateur de Josm n'apprécie que très
modérément !
Quand aux tracés des routes/cours d'eau, ils sont assez stables dans le
temps pour pouvoir être utilisé comme frontière. Les (rares) cas où un
cours d'eau change de lit tous les ans (en France) sont sans doute
justement les cas où la frontière n'a plus rien à voir avec le cours d'eau
depuis longtemps (je pense à la limite Bretagne/Basse-Normandie, où
l'embouchure du Couesnon n'est plus la frontière entre ces 2 régions
depuis...)

Francescu


Le 6 mars 2013 14:07, Jo.  a écrit :

> Je ne me rappel plus si c'était un conseil d'édition (sans obligation)
> mais si possible on ne doit pas fusionner sur le même segment une route ou
> un cours d'eau avec un frontière.
> Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et
> fausser les limites administrative.
>
> Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre
> et je ne pense pas qu'on met à jour le cadastre après chaque hivers.
>
>
>
>
> Le 6 mars 2013 13:38, Philippe Verdy  a écrit :
>
> Justement, des rivières, routes, voies ferrées sont parfois aussi des
>> limites administratives. Et c'est là qu'on trouve le plus des
>> source=inconnue ! Et ça commence à se propager ailleurs sur d'autres
>> objets.
>>
>> Le 6 mars 2013 10:51, Pieren  a écrit :
>> > 2013/3/6 Philippe Verdy :
>> >
>> >> On dirait que cela a été ajouté uniquement pour faire disparaître le
>> >> marquage dans Osmose, sans rien corriger du tout.
>> >
>> > De quelle analyse Osmose parle-t-on ? La seule que je vois qui
>> > pourrait correspondre à un problème de source manquante est l'item
>> > 2040 mais cela ne concerne que les limites administratives.
>>
>> ___
>> 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
>
>


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

Re: [OSM-talk-fr] source=inconnue

[Jo.]

Je ne me rappel plus si c'était un conseil d'édition (sans obligation) mais
si possible on ne doit pas fusionner sur le même segment une route ou un
cours d'eau avec un frontière.
Ces deux éléments (entre autres) risque d'être facilement déplacé/cassé et
fausser les limites administrative.

Par exemple, une rivière peut voir son lit ce déplacer de quelques mètre et
je ne pense pas qu'on met à jour le cadastre après chaque hivers.




Le 6 mars 2013 13:38, Philippe Verdy  a écrit :

> Justement, des rivières, routes, voies ferrées sont parfois aussi des
> limites administratives. Et c'est là qu'on trouve le plus des
> source=inconnue ! Et ça commence à se propager ailleurs sur d'autres
> objets.
>
> Le 6 mars 2013 10:51, Pieren  a écrit :
> > 2013/3/6 Philippe Verdy :
> >
> >> On dirait que cela a été ajouté uniquement pour faire disparaître le
> >> marquage dans Osmose, sans rien corriger du tout.
> >
> > De quelle analyse Osmose parle-t-on ? La seule que je vois qui
> > pourrait correspondre à un problème de source manquante est l'item
> > 2040 mais cela ne concerne que les limites administratives.
>
> ___
> 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] Frontière et/ou eaux territoriales Guyane française

[Philippe Verdy]

Le 6 mars 2013 10:42, Pieren  a écrit :
> 2013/3/6 Philippe Verdy :
>> admin_level=1 puisse s'appliquer car il n'existe encore aucune entité
>> "administrative" supranationale.
>
> L'union européenne et ses 50.000 fonctionnaires seront contents
> d'apprendre qu'ils ne sont pas une "entité administrative".

C'est une administration mais les pays membres n'en sont pas des
sous-entités. Le modèle hiérarchique ne s'applique pas à l'Union
européenne, ni aux autres organisations européennes même si elles ont
leur propre structure administrative.

> Au niveau des frontières et de leur incidence sur la circulation des
> biens et des personnes, on devrait effectivement définir deux zones,
> les pays dans l'UE et ceux qui font partie de l'espace Schengen. Pas
> sûr cependant que toutes ces nuances entrent dans le schéma classique
> des admin_level.

C'est tellement compliqué et il y a tellement d'exceptions que c'est
impossible à faire rentrer dans le moule. L'Union européenne peut être
cartographiée dans OSM mais à part (et il faudra effectivement une
collection de relations selon ce qu'on veut représenter, selon les
statuts d'adhésion pleine des parties de territoires nationaux inclus
ou pas, ou statuts de collaboration renforcée ou associée, et selon
aussi diverses exceptions incluses dans les traités selon les
domaines...

Pour certaines cartes simplifiées on peut ne pas vouloir faire le
détail, mais si on est précis, les frontières de l'UE sont très
difficiles à définir car il faur retenir certains critères, assez
arbitrairement.

Shengen en est un exemple : ce n'est pas non plus une subdivision de
l'Union européenne car on y trouve aussi des territoires qui ne font
PAS partie de l'Unione européenne, et des parties de l'Union
européenne (parties de certains pays membres, ou pays membres tout
entiers) qui n'en font pas partie.

La zone euro en est un autre exemple similaire (formellement le
Vatican ne fait pas partie de l'UE, n'est pas pleinement membre de la
zone euro et pourtant dispose d'un accord de la explicite de la
Commission pour l'utiliser; le Kosovo l'utilise officiellement chez
lui, mais son gouvernement n'a pas reçu lui-même cet agrément qui n'a
été accordé qu'à la mission intérimaire des Nations unies qui
auparavant utilisait le mark allemand en vertu d'un traité avalisé par
l'ONU Le Monténégro a décidé unilatéralement aussi d'utiliser
l'euro, mais sans aucun accord; pour Andorre, il ne fait pas partie
non plus de l'UE ni de la zone euro, mais les accords monétaires
préexistants avec la France et l'Espagne ont été maintenus : Andorre
ne peut utiliser l'euro que parce que la France et/ou l'Espagne ont
voulu perpétuer leur accord avec l'Andorre : c'est l'adhésion de la
France et de l'Espagne qui a entrainé celle de l'Andorre, et si la
France et l'Espagne quittaient l'euro, Andorre devrait le faire aussi
(sauf si les traités entre Andorre et la France et l'Espagne sont
dénoncés conjointement par les parties).

Pour s'en convaincre il faut regarder l'extrême complexité des annexes
au traité d'union : la liste complète des exceptions pour chaque pays
membre est impressionnante, et chaque modification des traités
européens en a ajouté d'autres. A un point tel qu'il me semble que
formellement il n'y a plus aucun pays membre de l'Union qui ait adopté
la totalité des textes sur la totalité de leur territoire. L'Union
européenne est un véritable patchwork d'exceptions sur presque tous
les sujets (et les mêmes sujets incluent aussi des parties qui ont été
admises à collaborer dans certains domaines sans faire partie
formellement de l'Union). Je te mets au défit alors de tracer les
frontières effectives de l'UE, ne serait-ce que pour ce qu'on appelle
les "acquis européens" (autrement dit les points "non négociables" du
traité, les mêmes points sur lesquels il reste pourtant des pays
membres qui ne les ont pas adoptés lors des amendements successifs,
parce qu'il n'était pas question qu'ils sortent pour autant de la
nouvelle entité...). L'UE reste une entité en construction permanente.

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

Re: [OSM-talk-fr] source=inconnue

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Philippe Verdy" 

> Justement, des rivières, routes, voies ferrées sont parfois aussi des
> limites administratives. Et c'est là qu'on trouve le plus des
> source=inconnue ! Et ça commence à se propager ailleurs sur d'autres
> objets.
> 

Pas de panique. À te lire la base est en train d'être envahie par ce tag.
Concrètement, on trouve d'après taginfo 8 ways avec le tag source=inconnue. 
Oui, 8,
pas 800 ou 8000. 
Il proviennent tous d'un groupe de modification pas tout jeune (2010) :
http://www.openstreetmap.org/browse/changeset/5210200 de sly.
Et donc non "ça [ne] commence [pas] à se propager".

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] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Marc SIBERT]

Bonjour,

Concernant le dernier point "toute autre action...", je me posais la
question de la disponibilité des images SPOT sous une licence compatible
avec OSM afin que des contributeurs non-locaux (contributions dans le
fauteuil :-) puissent participer.
En particulier, suivant la date des images (avant/après) il sera possible
d'affiner le bati sur la zone concernée par l'inondation et/ou d'indiquer
dans OSM les détails visibles de l’infrastructure routière ; ces éléments
pouvant servir de repère géographique pour des remontées d'informations
locales.

En cas de réponse positive, je pense (et je m'avance sur ce point) que
l'asso OSM-FR pourra fournir les moyens techniques pour exploiter les
images (tuilage, hébergement, etc.)

Cordialement,

A+


Le 6 mars 2013 11:23, Cédric Moro  a écrit :

>  Bonjour,
>
> Nous sommes une équipes de bénévoles qui intervenons actuellement sur le
> cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et
> Morombé.
>
> Le bilan provisoire d'hier est de : **
>
>- 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara
>I, 1 Sakaraha, 4 Toliara II, 1 Betroka) ;
>- 16 disparus (Toliara I) ;
>- 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29
>Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano);
>- 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II,
>16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 265 CR Soanala, 115
>CU Betroka, 2 459 Antakataka Sud, 1 315 Vangaindrano, 1 562 Ankazoabo)
>;
>- 13 882 sans abris (892 Toliara I, 2 000 Sakaraha, 2 271 Toliara II, 1
>680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459
>Antakataka Sud, 332 Vangaindrano, *1 *562 Ankazoabo) ;
>- 7 402 cases totalement détruites (100 Sakahara, 120 Morombe, 1 729
>Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 920 Toliara II) ;
>- 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044
>Sakaraha, 372 Ampanihy, 32 Betroka)
>
>
>
> Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence
> internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes
> pour des soins en urgence. Nos membres sont celui du VOST Francophone
> (nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue
> de la communauté des #MSGU, Médias sociaux en gestion d'urgence :
> http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity
> Road s'est également jointe à notre action. Grâce au travail d'impacts sur
> les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées
> d'infos des médias sociaux et sites internet, nous avons pu mieux orienter
> l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara.
>
>
>
> Nous utilisons une carte collaborative pour recenser les besoins
> humanitaires et améliorer la réponse de crise :
> https://haruna.crowdmap.com
>
>
> Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM
> et de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut
> car il nous permet d'avoir une vision en image satellite, importante pour
> comprendre la géographie locale tout comme pour bénéificier des infos
> toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans
> cette cartographie, notamment sur le centre-ville où les données sont
> beaucoup plus détaillées et qui nous ont été précisieuses pour localiser
> les écoles (centres d'hébergement, cycbercafés...).
>
>
>
> Nous demandons donc à tout membre de la communauté d'OSM votre
> participation bénévole pour :
> - Extraire le sud-ouest de Madagascar en format KML ou KMZ afin de
> l'intégrer comme couche dans Crowdmap. Nous pouvons chercher techniquement
> comment faire de notre côté mais nous y gagnerons du temps si quelqu'un de
> chez vous s'en occupe.
> - Participer sur le terrain à de la remontée d'informations humanitaires
> géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, voir de
> Sakaraha, Betiky, Betroka, Vangaindrano, Antakataka, Ampanihy, Soanala.
> - Compléter notre liste de cyber-cafés fonctionnels et y distribuer des
> affiches pour mobiliser les internautes sur place afin qu'ils remontent des
> informations sur les besoins humanitaires et leurs attentes en général face
> à cette catastrophe.
> - Ou toute autre action qui pourrait améliorer la réponse humanitaire.
>
>
>
> Pour les deux derniers point, auriez-vous svp un contact sur place ?
>
>
>
> Nous vous remercions de votre attention.
>
>
> Cédric
>
> +33 5 35 54 19 27
> Skype : roomilissimo
> Twitter : @Moro_Cedric
>
> Coordinateur du VOST Francophone
> Membre de la communauté MSGU (Médias sociaux en gestion d'urgence)
>
> Webmaster des Pompiers de l'urgence internationale
> www.pompiers-urgence.org
>
> www.i-resilience.fr
>
>
>
>
>
>
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] source=inconnue

[Philippe Verdy]

Justement, des rivières, routes, voies ferrées sont parfois aussi des
limites administratives. Et c'est là qu'on trouve le plus des
source=inconnue ! Et ça commence à se propager ailleurs sur d'autres
objets.

Le 6 mars 2013 10:51, Pieren  a écrit :
> 2013/3/6 Philippe Verdy :
>
>> On dirait que cela a été ajouté uniquement pour faire disparaître le
>> marquage dans Osmose, sans rien corriger du tout.
>
> De quelle analyse Osmose parle-t-on ? La seule que je vois qui
> pourrait correspondre à un problème de source manquante est l'item
> 2040 mais cela ne concerne que les limites administratives.

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

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Eric Sibert]

Bonjour,

Je connais pas mal Madagascar et un peu Tuléar. On peut trouver  
quelques généralités sur la cartographie du pays dans le wiki:

http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar

Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette  
cartographie, notamment sur le centre-ville où les données sont  
beaucoup plus détaillées et qui nous ont été précisieuses pour  
localiser les écoles (centres d'hébergement, cycbercafés...).


Je suis fort aise que mon modeste travail de fourmi ait pu être utile :-p

Par contre, je n'ai pas vraiment de contacts sur place actuellement.


Nous demandons donc à tout membre de la communauté d'OSM votre  
participation bénévole pour :- Extraire le sud-ouest de Madagascar  
en format KML ou KMZ afin


Ca, je ne sais pas faire et comme je suis au boulot, je ne peux pas  
faire d'essais.


Néanmoins, si certains veulent le faire, on peut récupérer toutes les  
données de Madagascar d'un seul coup chez geofabrik :


http://download.geofabrik.de/openstreetmap/africa/

Ce n'est pas bien gros (20 Mo max).

Pour revenir à Tuléar (http://osm.org/go/k~5RokPm-), donc, avec le  
cyclone, la digue protégeant la ville de la rivière au nord a cédé  
d'où l’inondation du centre-ville (très plat). Ca a aussi coupé la RN9  
au sud du pont franchissant la dite rivière, coupant la circulation  
vers le nord dont Morombe.


Pour se repérer en ville, il reste certes des noms de rues d'époque  
coloniale mais personne ne s'en sert. Les malgaches se repèrent avec  
les noms des quartiers. Il y en a quelques uns dans OSM mais je pense  
qu'il en manque pas mal.


Il y a un découpage administratifs sous les communes, les fokontany.  
Ils possèdent des bureaux. Ils peuvent avoir le même nom que le  
quartier. Ils ne sont pas renseignés dans OSM.


Il y a aussi une identifications des bâtiments et des ilots par lot  
(http://wiki.openstreetmap.org/wiki/FR:WikiProject_Madagascar#Adresses) mais  
si ce n'est pas renseigné avant la catastrophe, c'est trop tard. D'où  
l'intérêt d'avoir des éléments (centre de santé, écoles...)  
directement géo-référencés dans OSM.


S'il y a des questions sur les spécificités malgaches, je peux essayer  
d'y répondre. Je peux peut-être aussi contacter des personnes en  
France qui connaissent mieux la ville.


Et, quand vous serez revenus, je suis aussi intéressé par savoir  
quelles sont les informations que vous avez trouvé dans OSM qui vont  
ont été utiles et celles qui vous ont manquées.


Eric


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

Re: [OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Sylvain Maillard]

Bonjour,

à priori c'est une tâche pour HOT, l'équipe de cartographie pour
l'humanitaire de OSM : http://hot.openstreetmap.org

ils ont déjà travaillé sur des cas semblables, et ont déjà en place un
système de partage des tâches plutôt efficace !
et d'ailleurs si je ne me trompe pas, certains des membres actifs lisent
cette liste ...



Sylvain


Le 6 mars 2013 11:23, Cédric Moro  a écrit :

>  Bonjour,
>
> Nous sommes une équipes de bénévoles qui intervenons actuellement sur le
> cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et
> Morombé.
>
> Le bilan provisoire d'hier est de : **
>
>- 26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara
>I, 1 Sakaraha, 4 Toliara II, 1 Betroka) ;
>- 16 disparus (Toliara I) ;
>- 127 blessés (32 Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29
>Toliara II, 3 SOANALA, 1 Betroka, 1 Vangaindrano);
>- 40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5 441 Toliara II,
>16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 265 CR Soanala, 115
>CU Betroka, 2 459 Antakataka Sud, 1 315 Vangaindrano, 1 562 Ankazoabo)
>;
>- 13 882 sans abris (892 Toliara I, 2 000 Sakaraha, 2 271 Toliara II, 1
>680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 100 Betroka, 2 459
>Antakataka Sud, 332 Vangaindrano, *1 *562 Ankazoabo) ;
>- 7 402 cases totalement détruites (100 Sakahara, 120 Morombe, 1 729
>Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 920 Toliara II) ;
>- 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044
>Sakaraha, 372 Ampanihy, 32 Betroka)
>
>
>
> Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence
> internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes
> pour des soins en urgence. Nos membres sont celui du VOST Francophone
> (nouvellement créé pour l'occasion), soit un réseau à but humanitaire issue
> de la communauté des #MSGU, Médias sociaux en gestion d'urgence :
> http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity
> Road s'est également jointe à notre action. Grâce au travail d'impacts sur
> les images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées
> d'infos des médias sociaux et sites internet, nous avons pu mieux orienter
> l'ONG sur le terrain qui se situe à Tuléar, Région de Toliara.
>
>
>
> Nous utilisons une carte collaborative pour recenser les besoins
> humanitaires et améliorer la réponse de crise :
> https://haruna.crowdmap.com
>
>
> Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM
> et de Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut
> car il nous permet d'avoir une vision en image satellite, importante pour
> comprendre la géographie locale tout comme pour bénéificier des infos
> toponymiques. Cependant, nous souhaiterions bénéficier des infos d'OSM dans
> cette cartographie, notamment sur le centre-ville où les données sont
> beaucoup plus détaillées et qui nous ont été précisieuses pour localiser
> les écoles (centres d'hébergement, cycbercafés...).
>
>
>
> Nous demandons donc à tout membre de la communauté d'OSM votre
> participation bénévole pour :
> - Extraire le sud-ouest de Madagascar en format KML ou KMZ afin de
> l'intégrer comme couche dans Crowdmap. Nous pouvons chercher techniquement
> comment faire de notre côté mais nous y gagnerons du temps si quelqu'un de
> chez vous s'en occupe.
> - Participer sur le terrain à de la remontée d'informations humanitaires
> géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, voir de
> Sakaraha, Betiky, Betroka, Vangaindrano, Antakataka, Ampanihy, Soanala.
> - Compléter notre liste de cyber-cafés fonctionnels et y distribuer des
> affiches pour mobiliser les internautes sur place afin qu'ils remontent des
> informations sur les besoins humanitaires et leurs attentes en général face
> à cette catastrophe.
> - Ou toute autre action qui pourrait améliorer la réponse humanitaire.
>
>
>
> Pour les deux derniers point, auriez-vous svp un contact sur place ?
>
>
>
> Nous vous remercions de votre attention.
>
>
> Cédric
>
> +33 5 35 54 19 27
> Skype : roomilissimo
> Twitter : @Moro_Cedric
>
> Coordinateur du VOST Francophone
> Membre de la communauté MSGU (Médias sociaux en gestion d'urgence)
>
> Webmaster des Pompiers de l'urgence internationale
> www.pompiers-urgence.org
>
> www.i-resilience.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

[OSM-talk-fr] Demande d'assistance cartographique sur le Cyclone Haruna à Madagascar.

[Cédric Moro]

Bonjour,

Nous sommes une équipes de bénévoles qui intervenons actuellement sur le 
cyclone Haruna qui a frappé le Sud-Ouest de Madagascar autour de Tuléar et 
Morombé. 

Le bilan provisoire d'hier est de : 
26 décédés (6 Vangaindrano, 02 Morombe, 01 Betioky Sud, 11 Toliara I, 1 
Sakaraha, 4 Toliara II, 1 Betroka) ;16 disparus (Toliara I) ;127 blessés (32 
Toliara I, 19 Betioky Sud, 3 Sakaraha, 9 Bekily, 29 Toliara II, 3 SOANALA, 1 
Betroka, 1 Vangaindrano);40 154 sinistrés (2 261 Toliara I, 5 358 Sakaraha, 5
 441 Toliara II, 16 219 Betioky Sud, 2 880 CU Morombe, 3 780 Ampanihy, 
265 CR Soanala, 115 CU Betroka, 2 459 Antakataka Sud, 1 315 
Vangaindrano, 1 562 Ankazoabo) ;13 882 sans abris (892 Toliara I, 2 000 
Sakaraha, 2 271 Toliara II, 1 680 Betioky Sud, 368 CU Morombe, 3 780 Ampanihy, 
100 Betroka, 2 459 Antakataka Sud, 332 Vangaindrano, 1 562 Ankazoabo) ;7 402 
cases totalement détruites (100 Sakahara, 120 
Morombe, 1 729 Toliara I, 1283 Betioky Sud, 250 Soanala/dist Betroka, 3 
920 Toliara II) ; 2 808 cases décoiffées (1 175 Morombe, 185 Betioky Sud, 1 044 
Sakaraha, 372 Ampanihy, 32 Betroka) 
Nous sommes associés sur le terrain avec l'ONG les Pompiers de l'urgence 
internationale http://www.pompiers-urgence.org qui ont envoyé 5 personnes pour 
des soins en urgence. Nos membres sont celui du VOST Francophone (nouvellement 
créé pour l'occasion), soit un réseau à but humanitaire issue de la communauté 
des #MSGU, Médias sociaux en gestion d'urgence : 
http://www.i-resilience.fr/msguchat/archives-du-msguchat/. L'ONG Humanity Road 
s'est également jointe à notre action. Grâce au travail d'impacts sur les 
images sattelites SPOT et à leur mise en ligne ainsi qu'aux remontées d'infos 
des médias sociaux et sites internet, nous avons pu mieux orienter l'ONG sur le 
terrain qui se situe à Tuléar, Région de Toliara.

Nous utilisons une carte collaborative pour recenser les besoins humanitaires 
et améliorer la réponse de crise : https://haruna.crowdmap.com
Crowdmap, issu d'Ushahidi, ne nous permet pas de mettre les couches d'OSM et de 
Gmap en même temps. Or, nous avons choisi Gmap comme layer par défaut car il 
nous permet d'avoir une vision en image satellite, importante pour comprendre 
la géographie locale tout comme pour bénéificier des infos toponymiques. 
Cependant, nous souhaiterions bénéficier des infos d'OSM dans cette 
cartographie, notamment sur le centre-ville où les données sont beaucoup plus 
détaillées et qui nous ont été précisieuses pour localiser les écoles (centres 
d'hébergement, cycbercafés...).

Nous demandons donc à tout membre de la communauté d'OSM votre participation 
bénévole pour :- Extraire le sud-ouest de Madagascar en format KML ou KMZ afin 
de l'intégrer comme couche dans Crowdmap. Nous pouvons chercher techniquement 
comment faire de notre côté mais nous y gagnerons du temps si quelqu'un de chez 
vous s'en occupe.- Participer sur le terrain à de la remontée d'informations 
humanitaires géolocalisées sur les secteurs de Tuléar à Toliari, de Morombé, 
voir de Sakaraha, Betiky, Betroka, Vangaindrano, Antakataka, Ampanihy, 
Soanala.- Compléter notre liste de cyber-cafés fonctionnels et y distribuer des 
affiches pour mobiliser les internautes sur place afin qu'ils remontent des 
informations sur les besoins humanitaires et leurs attentes en général face à 
cette catastrophe.- Ou toute autre action qui pourrait améliorer la réponse 
humanitaire.

Pour les deux derniers point, auriez-vous svp un contact sur place ? 

Nous vous remercions de votre attention.
Cédric 
+33 5 35 54 19 27Skype : roomilissimoTwitter : @Moro_Cedric
Coordinateur du VOST FrancophoneMembre de la communauté MSGU (Médias sociaux en 
gestion d'urgence)
Webmaster des Pompiers de l'urgence internationalewww.pompiers-urgence.org
www.i-resilience.fr




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

Re: [OSM-talk-fr] Rappel pour l'appel à contributions FROG 2013

[Pieren]

2013/3/5 Pieren :

> Bouh, les vilains d'osgeo, sur la carte d'accès au site, ils utilisent
> la version OSM d'Open MapQuest (ben) mais ils créditent la version
> commerciale MapQuest NAVTEQ (pas ben):

Faute non avouée mais corrigée, donc pardonnée :))

{attribution: "Tuiles de fond © MapQuest Données
© les contributeurs
OpenStreetMap"}

Pieren

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

Re: [OSM-talk-fr] source=inconnue

[Pieren]

2013/3/6 Philippe Verdy :

> On dirait que cela a été ajouté uniquement pour faire disparaître le
> marquage dans Osmose, sans rien corriger du tout.

De quelle analyse Osmose parle-t-on ? La seule que je vois qui
pourrait correspondre à un problème de source manquante est l'item
2040 mais cela ne concerne que les limites administratives.

Pieren

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

Re: [OSM-talk-fr] Frontière et/ou eaux territoriales Guyane française

[Pieren]

2013/3/6 Philippe Verdy :
> admin_level=1 puisse s'appliquer car il n'existe encore aucune entité
> "administrative" supranationale.

L'union européenne et ses 50.000 fonctionnaires seront contents
d'apprendre qu'ils ne sont pas une "entité administrative". Et pour
ceux qui auraient raté les infos de ces cinquante dernières années,
une large partie du droit européen est effectivement supranationale.
Au niveau des frontières et de leur incidence sur la circulation des
biens et des personnes, on devrait effectivement définir deux zones,
les pays dans l'UE et ceux qui font partie de l'espace Schengen. Pas
sûr cependant que toutes ces nuances entrent dans le schéma classique
des admin_level.

Pieren

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

Re: [OSM-talk-fr] source=inconnue

[Erik Amzallag]

Bonjour,

De mon côté, il m'arrive parfois de mettre des tags source=unknown.
La raison ?
Le plugin cadastre qui ajoute automatiquement le tag source=cadastre à tous
les noeuds/ways modifiés.
Or parfois, il m'arrive de couper un way déjà présent en base sans notion
de source, pour adapter une partie conformément au cadastre, l'autre partie
du way restant inchangée. Mais pour le plugin, le way a changé (puisque
coupé) et veut mettre son tag source. Ce que je contourne en mettant un tag
source=unknown.

Erik




Le 6 mars 2013 09:44, Philippe Verdy  a écrit :

> Je tombe de temps en temps sur un tag source=inconnue (dans la Drôme
> par exemple, sur certains tracés comme les fleuves et rivières).
>
> On dirait que cela a été ajouté uniquement pour faire disparaître le
> marquage dans Osmose, sans rien corriger du tout.
> Ce genre de tag est plus nuisible qu'autre chose, si la source n'est
> pas connue ou pas précisée, il vaut mieux ne rien mettre du tout. Il
> peut s'agir d'un oubli par son contributeur initial, mais alors il
> peut le voir et corriger lui-même ou bien on peut aller consulter une
> plance cadastrale ou une imagerie Bing pour aller vérifier et
> éventuellement affiner un tracé (s'il s'écarte trop de la réalité de
> sorte que le tracé d'une route, voie ferrée, ou rivière sort de sa
> surface réelle occupée (et peut entrer en conflit avec des éléments
> adjascents comme des polygones landuse=*, natural=*, building=*,
> et...).
>
> Bref le tag "source=inconnue" est à supprimer (et Osmose pourrait
> éventuellement vérifier cette valeur pour la marquer comme inutile et
> à supprimer, et malgré tout signaler un tracé comme étant sans source
> de référence).
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] source=inconnue

[Philippe Verdy]

Je tombe de temps en temps sur un tag source=inconnue (dans la Drôme
par exemple, sur certains tracés comme les fleuves et rivières).

On dirait que cela a été ajouté uniquement pour faire disparaître le
marquage dans Osmose, sans rien corriger du tout.
Ce genre de tag est plus nuisible qu'autre chose, si la source n'est
pas connue ou pas précisée, il vaut mieux ne rien mettre du tout. Il
peut s'agir d'un oubli par son contributeur initial, mais alors il
peut le voir et corriger lui-même ou bien on peut aller consulter une
plance cadastrale ou une imagerie Bing pour aller vérifier et
éventuellement affiner un tracé (s'il s'écarte trop de la réalité de
sorte que le tracé d'une route, voie ferrée, ou rivière sort de sa
surface réelle occupée (et peut entrer en conflit avec des éléments
adjascents comme des polygones landuse=*, natural=*, building=*,
et...).

Bref le tag "source=inconnue" est à supprimer (et Osmose pourrait
éventuellement vérifier cette valeur pour la marquer comme inutile et
à supprimer, et malgré tout signaler un tracé comme étant sans source
de référence).

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