[OSM-talk-fr] Route en déblai

[hpmt]

Bonjour à tous, et bon dimanche !

Je n'ai pas trouvé sur le wiki la manière de taguer une "route en 
déblai" ; le terme "déblai" semble ne pas exister ; ni "remblai" ? ni 
"talus" ?


Vous faites comment our signaler les zones très accidentées ?

Merci !


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

Re: [OSM-talk-fr] Route en déblai

[hpmt]

Talus, remblai : embankment=yes

je cherche toujours la "route en déblai", ou "route en tranchée" ; 
ditch=yes ?


hpmt a écrit , Le 01/08/2010 11:10:

Bonjour à tous, et bon dimanche !

Je n'ai pas trouvé sur le wiki la manière de taguer une "route en
déblai" ; le terme "déblai" semble ne pas exister ; ni "remblai" ? ni
"talus" ?

Vous faites comment our signaler les zones très accidentées ?

Merci !


___
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] Soucis OGR dans "svg-parser.pl"

[Eric]

Bonjour,

Je voulais essayer l'import de bâti pour voir le principe au moins (et
éventuellement  compléter mon secteur) mais je me heurte à un problème
lors  de  l'exécution  du  script  récupéré sur le wiki. J'ai l'erreur
suivante:

"RunTime Error OGR Error: Corrupted Data"
et ca intervient lors de l'appel au script PERL
perl svg-parser.pl $IGNF "$dir/pdf/$baseName.svg" $bb > "$dir/osm/$baseName.osm"

J'exécute  sous Ubuntu 10.04 avec PERL 5.10.1. J'ai crée le "ln" comme
demandé,   j'ai  installé  les paquets nécessaires...  je  ne vois pas
d'où  vient  cette erreur et je ne suis pas assez costaud en PERL pour
investiguer  plus.  Le   site  du  Cadastre  est  peut  etre encore en
maintenance.  Ou alors, je fais une bêtise ? Je suis preneur d'indices
car  j'ai  cherché dans les archives de la liste sans trouver trace de
ce genre de problèmes ! :))

-
Blueberry



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

[OSM-talk-fr] Centre de loisirs ?

[Pierre-Alain Dorange]

Bonjour,

Je tag les services municipaux de ma ville et je tombe sur quelques os  
au niveau des tags aussi bien que de l'organisation des lieux.


Par exemple, un Centre de loisirs municipal (ce n'est pas une crèche  
ni un e halte-garderie) qui acceptent les enfants de 3 à 6 ans).
Le lieu est représenté par 1 ou plusieurs bâtiments et un terrain  
autour.
Pour l'instant j'ai taggé le terrain en "leiseure=playground" mais ça  
me satisfait pas, l'endroit n'étant pas réellement accessible au  
public (il faut inscrire son enfant et c'est fermé). Dessus il y a  
plusieurs bâtiments que j'ai simplement taggé en "building=yes et  
"amenity=public_building" (mais il ne faut plus l'utiliser d'après le  
wiki)

Ensuite j'ai crée une relation "type=site" avec name (le nom du centre).
Les bâtiments ont le role "building" et le terrain "area", mais je  
crois que je fais fausse route...


Vous faites comment ?

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


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

Re: [OSM-talk-fr] Route en déblai

[Pierre-Alain Dorange]

Le 1 août 10 à 13:43, hpmt a écrit :


Talus, remblai : embankment=yes

je cherche toujours la "route en déblai", ou "route en tranchée" ;  
ditch=yes ?



cutting=yes ?



--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


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

Re: [OSM-talk-fr] Route en déblai

[hpmt]

les mots "Talus", "Remblai" figurent bel et bien dans la page 
http://wiki.openstreetmap.org/wiki/FR:Map_Features

mais l'outil de recherche ne les trouve pas ; strange.


hpmt a écrit , Le 01/08/2010 13:43:

Talus, remblai : embankment=yes

je cherche toujours la "route en déblai", ou "route en tranchée" ;
ditch=yes ?

hpmt a écrit , Le 01/08/2010 11:10:

Bonjour à tous, et bon dimanche !

Je n'ai pas trouvé sur le wiki la manière de taguer une "route en
déblai" ; le terme "déblai" semble ne pas exister ; ni "remblai" ? ni
"talus" ?

Vous faites comment our signaler les zones très accidentées ?

Merci !


___
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] Centre de loisirs ?

[Pieren]

2010/8/1 Pierre-Alain Dorange 

> Le lieu est représenté par 1 ou plusieurs bâtiments et un terrain autour.
> Pour l'instant j'ai taggé le terrain en "leiseure=playground" mais ça me
> satisfait pas, l'endroit n'étant pas réellement accessible au public (il
> faut inscrire son enfant et c'est fermé). Dessus il y a plusieurs bâtiments
> que j'ai simplement taggé en "building=yes et "amenity=public_building"
> (mais il ne faut plus l'utiliser d'après le wiki)
>

Je ne vois pas mettre une relation pour ça. Je mettrais amenity=kelkechose
sur toute la surface (quitte à réutiliser certains noeuds des bâtiments par
exemple), 'playground' sur la zone de jeu à l'extérieur et rien sur les
bâtiments (ou un description de ce qu'ils sont: "salle commune",
"toilettes", "bureaux", etc).
Pour amenity, le plus proche que je vois pour l'instant est:
http://wiki.openstreetmap.org/wiki/Community_centre
http://en.wikipedia.org/wiki/Community_centre

Comme ça n'est pas une salle commune pour toutes les générations, je
pencherais pour créer une sous-clé, genre community=children (ou
community_centre=children) comme il peut y avoir community=christians ou
elder, etc... Mais si tu pars dans cette direction, il faudrait l'ajouter
dans le wiki.
Pour le côté "non accessible au public sans inscription", je ne pense pas
qu'il faille aller jusqu'à mettre access=private sinon on devrait le mettre
sur 99.9% des buildings. Si tu veux, tu pourrais ajouter un tag 'note' pour
donner ce genre de détails.

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

[OSM-talk-fr] Re : Re : Mise à disposition des orthophotos sur l'Allier et le Puy de Dôme pour Op enStreetMap

[THEVENON Julien]

De : Christian Quest 



 On a déjà les orthos en haute def de Yahoo, celles de GéoLittoral, celle 
 du 
CRAIG et bientôt celles du 06... donc l'idée c'est de faire une grosse 
relation 
pour pouvoir facilement afficher sur une carte de France toutes les zones 
couvertes par des orthos en haute-résolution et aussi toutes les communes 
avec 
le cadastre en vectoriel.
Ok, merci pour l info.

Julien



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

Re: [OSM-talk-fr] Centre de loisirs ?

[Pierre-Alain Dorange]

Le 1 août 10 à 16:15, Pieren a écrit :

Le lieu est représenté par 1 ou plusieurs bâtiments et un terrain  
autour.
Pour l'instant j'ai taggé le terrain en "leiseure=playground" mais  
ça me satisfait pas, l'endroit n'étant pas réellement accessible au  
public (il faut inscrire son enfant et c'est fermé). Dessus il y a  
plusieurs bâtiments que j'ai simplement taggé en "building=yes et  
"amenity=public_building" (mais il ne faut plus l'utiliser d'après  
le wiki)


Je ne vois pas mettre une relation pour ça. Je mettrais  
amenity=kelkechose sur toute la surface (quitte à réutiliser  
certains noeuds des bâtiments par exemple), 'playground' sur la zone  
de jeu à l'extérieur et rien sur les bâtiments (ou un description de  
ce qu'ils sont: "salle commune", "toilettes", "bureaux", etc).


OK je comprend la position surtout que ici le lieu est "petit".

J'ai des "problèmes" similaires pour des sites industriels importants.  
par exemple à Cognac, il y l'usine Saint-Gobain qui est composé d'une  
cinquantaine de bâtiments sur 2 zones (séparé par une route publique).
J'ai là aussi opté pour une relation "type=site" peut être un peu vite  
et j'ai tendance a l'utiliser pour regrouper des batiments (d'une  
usage commun) sur une zone.




Pour amenity, le plus proche que je vois pour l'instant est:
http://wiki.openstreetmap.org/wiki/Community_centre
http://en.wikipedia.org/wiki/Community_centre


Ca parait en effet le pus adéquat de ce que j'ai vu, merci.

Comme ça n'est pas une salle commune pour toutes les générations, je  
pencherais pour créer une sous-clé, genre community=children (ou  
community_centre=children) comme il peut y avoir  
community=christians ou elder, etc... Mais si tu pars dans cette  
direction, il faudrait l'ajouter dans le wiki.


C'est une idée.

Pour le côté "non accessible au public sans inscription", je ne  
pense pas qu'il faille aller jusqu'à mettre access=private sinon on  
devrait le mettre sur 99.9% des buildings. Si tu veux, tu pourrais  
ajouter un tag 'note' pour donner ce genre de détails.



Non j'ai indiqué cet info pour permettre la compréhension je n'ai pas  
l'intention de taggé ce genre de chose, ça parait "implicite".


--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


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

Re: [OSM-talk-fr] Centre de loisirs ?

[Vincent Pottier]

On 01/08/2010 14:26, Pierre-Alain Dorange wrote:

Bonjour,

Bonjour


Je tag les services municipaux de ma ville et je tombe sur quelques os 
au niveau des tags aussi bien que de l'organisation des lieux.


Par exemple, un Centre de loisirs municipal

Plusieurs infos dans Centre de loisirs municipal 3 à 6 ans :
CLSH : pas de tag satisfaisant à ce jour, amenity=quelque_chose
municipal :operator=quelque_chose
3-6 ans : bon là il y a quelque chose à créer (je n'avais jamais vu un 
centre de loisirs spécifique 3-6 ans)

Le lieu est représenté par 1 ou plusieurs bâtiments et un terrain autour.
Pour l'instant j'ai taggé le terrain en "leiseure=playground" mais ça 
me satisfait pas, l'endroit n'étant pas réellement accessible au public
On taggue les cinémas qui ne sont accessibles qu'aux clients... Mais 
certes leisure=playground sans délimitation par un amenity=* c'est ambigu

(il faut inscrire son enfant et c'est fermé).
C'est municipal, donc ouvert à tous les enfants de la commune sur 
inscription, ce n'est pas le centre de vacances des PTT qui est réservé.



On n'est pas très fort en tag pour les équipements sociaux, 
socio-culturels, socio-éducatifs...


@Pieren qui a suivi sur l'autre liste les discussions sur le tag emergency :
Le samu social peut-il être taggué avec un emergency ?
--
FrViPofm

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

Re: [OSM-talk-fr] Bâti OSM de Versailles

[Christian Quest]

Le 31 juillet 2010 16:04, Jérôme BLUM  a écrit :

>
> Bonjour à tous,
>
> Quelqu'un aurait-il à disposition le fichier du bâti de Versailles dans un
> format valide ? Je n'arrive pas à le trouver (j'ai même trouvé un fichier
> de
> 44 octets !)
> Tant qu'à y être, ça serait sympa que ceux qui s'occupent du 78 se
> signalent
> sur la page http://wiki.openstreetmap.org/wiki/France:Yvelines
>
> OSMement,
> Jérôme
>
>

J'ai relancé un traitement sur le 78, le résultat sera bientôt dispo sur
http://osm.cquest.org/bati/78/

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

Re: [OSM-talk-fr] Centre de loisirs ?

[Pieren]

2010/8/1 Vincent Pottier 

> municipal :operator=quelque_chose
>

Plutôt operator=municipality


>
> @Pieren qui a suivi sur l'autre liste les discussions sur le tag emergency
> :
> Le samu social peut-il être taggué avec un emergency ?
>
>
Euh, la discussion est ouverte à tous. Pour ceux qui ne suivent pas les
autres listes, il y a eu ces derniers jours une grosse discussion sur la
liste internationale concernant une nouvelle clé 'emergency', à l'origine
créée pour fire_hydrant au lieu de amenity=fire_hydrant. Puis quelqu'un a
jugé qu'on pouvait déplacer d'autres tags de la catégorie amenity (un peu
foure-tout il est vrai) dans cette nouvelle catégorie (ambulance,
fire_station, police, hospital). Autant la création d'une nouvelle clé ne
pose pas de problème pour la plupart des gens, autant le changement
d'anciens tags a soulevé une vague de protestations, surtout pour
amenity=ambulance car cela s'est fait rapidement dans la bdd par cette
personne suite à l'approbation de deux autres abonnés à la liste
osm-tagging. Cela fait un peu court, sachant ce que la modification de tags
existants implique pour les nombreuses applications gravitant autour d'OSM.

Bref, pour revenir à la question, c'est encore plus délicat car on devrait
définir le degré de l'urgence. Le samu social n'est pas - amha - un service
d'urgence. Si quelqu'un est vraiment malade dans la rue, on appelle le samu
tout court, pas le samu social. Mais j'ai bien conscience que le degré
d'urgence peut s'apprécier de manière très personnelle. Pour certains, un
bar devrait aussi se tagguer emergency=bar après une dure journée de labeur.

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

Re: [OSM-talk-fr] Soucis OGR dans "svg-parser.pl"

[didier2020]

j'ai eu le meme deboire avec debian ;-) ...
 - j'ai créé une machine virtuelle (virtualbox)
 - j'ai installé un debian testing

-> tout fonctionne correctement ...

pour moi, l'erreur est ... dans les versions ... 
et personnellement ça me dépasse allégrement !

bonne continuation !

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

Re: [OSM-talk-fr] Soucis OGR dans "svg-parser.pl"

[didier2020]

j'ai eu le meme deboire avec debian ;-) ...
 - j'ai créé une machine virtuelle (virtualbox)
 - j'ai installé un debian testing

-> tout fonctionne correctement ...

pour moi, l'erreur est ... dans les versions ... 
et personnellement ça me dépasse allégrement !

bonne continuation !

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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Frédéric Rodrigo]

Le 16/07/2010 23:49, Vincent de Chateau-Thierry a écrit :

J'ai ouvert ici :
http://papillon.peacefrogs.net/poll/NVNtQS1279316043/
une page de sondage pour essayer de synthétiser les souhaits autour de
nouvelles listes de discussion. Il ne s'agit pas d'un vote autour des
intitulés des listes (on n'en est pas là) mais juste sur le principe de
leur création.

Rdv dans quelques jours/semaines pour faire un bilan.


Je relance. Peut être le temps de tirer un bilan, peut être le temps 
d'attendre encore un peut.

Toutes fois un résultat se profile déjà.

My 1,5cent
Fred

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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Pieren]

2010/8/1 Frédéric Rodrigo 

> Je relance. Peut être le temps de tirer un bilan, peut être le temps
> d'attendre encore un peut.
> Toutes fois un résultat se profile déjà.
>
>
C'est très curieux comme résultat. Combien parmi ceux qui ont voté pour une
liste dev sont des développeurs ? Ca ressemble plus à un vote d'exclusion
qu'autre chose. D'autre part, les messages purement développeurs, il y en a
combien par mois sur les 800 à 1000 messages de cette liste ? 10, 20 ?

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

[OSM-talk-fr] Soucis OGR dans "svg-parser.pl"

[Eric]

Merci  pour  ta  piste je vais essayer. Ca serait donc une question de
version des différents packages fournis avec les distribs ...
On fonctionne pareil, moi aussi je travaille avec une VM de VirtualBox
pour  faire  mes tests. Je vais donc peut etre essayer une Debian même
si  je  crois  qu'elle  est  plus  pointue  et  donc  moins facilement
utilisable pour un non-spécialiste Linux :(

Ps HS:  Bizarrement,  aucun  de mes messages n'est diffusé par mail on
dirait, je ne  les  vois que par l'interface web de la liste. Bizarre,
je ne suis pourtant pas blacklisté ...

> j'ai eu le meme deboire avec debian ;-) ...
>  - j'ai créé une machine virtuelle (virtualbox)
>  - j'ai installé un debian testing
>
->> tout fonctionne correctement ...
>
> pour moi, l'erreur est ... dans les versions ... 
> et personnellement ça me dépasse allégrement !
>
> bonne continuation !

>> Bonjour,
>>
>> Je voulais essayer l'import de bâti pour voir le principe au moins (et
>> éventuellement  compléter mon secteur) mais je me heurte à un problème
>> lors  de  l'exécution  du  script  récupéré sur le wiki. J'ai l'erreur
>> suivante:
>>
>> "RunTime Error OGR Error: Corrupted Data"
>> et ca intervient lors de l'appel au script PERL
>> perl svg-parser.pl $IGNF "$dir/pdf/$baseName.svg" $bb > 
>> "$dir/osm/$baseName.osm"
>>
>> J'exécute  sous Ubuntu 10.04 avec PERL 5.10.1. J'ai crée le "ln" comme
>> demandé,   j'ai  installé  les paquets nécessaires...  je  ne vois pas
>> d'où  vient  cette erreur et je ne suis pas assez costaud en PERL pour
>> investiguer  plus.  Le   site  du  Cadastre  est  peut  etre encore en
>> maintenance.  Ou alors, je fais une bêtise ? Je suis preneur d'indices
>> car  j'ai  cherché dans les archives de la liste sans trouver trace de
>> ce genre de problèmes ! :))
>>
>> -
>> Blueberry







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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Pierre-Alain Dorange]

Le 1 août 10 à 18:48, Pieren a écrit :

Je relance. Peut être le temps de tirer un bilan, peut être le temps  
d'attendre encore un peut.

Toutes fois un résultat se profile déjà.


C'est très curieux comme résultat. Combien parmi ceux qui ont voté  
pour une liste dev sont des développeurs ? Ca ressemble plus à un  
vote d'exclusion qu'autre chose. D'autre part, les messages purement  
développeurs, il y en a combien par mois sur les 800 à 1000 messages  
de cette liste ? 10, 20 ?



J'ai par exemple voté "liste développeur" :
- je suis développeur (même si j'ai pas vraiment touché à OSM ou je  
suis plus utilisateur actuellement)

- certes il n'y a pas beaucoup de messages dev sur la liste
- par contre à mon sens il "perturbe" beaucoup les pur utilisateur qui  
n'y entendent rien


Concernant la liste, je suis assez peu satisfait d'une liste de  
discussion auquelle je préfère largement un forum usenet (bien plus  
pratique à tout niveau AMHA).
Par contre tant qu'a discuter sur ce medium (liste de discussion par  
email) autant n'en conserver qu'une ou 2 mais pas plus ça ne marchera  
pas sinon.
Pour pouvoir éclater en plusieurs thèmes il convient (AMHA) d'utiliser  
soit des forums web (que j'aime encore moins) soit usenet.


Mais ce n'est qu'un avis...

--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Christophe Merlet]

Le dimanche 01 août 2010 à 18:48 +0200, Pieren a écrit :
> 2010/8/1 Frédéric Rodrigo 
> Je relance. Peut être le temps de tirer un bilan, peut être le
> temps d'attendre encore un peut.
> Toutes fois un résultat se profile déjà.
> 
> 
> C'est très curieux comme résultat. Combien parmi ceux qui ont voté
> pour une liste dev sont des développeurs ? Ca ressemble plus à un vote
> d'exclusion qu'autre chose. D'autre part, les messages purement
> développeurs, il y en a combien par mois sur les 800 à 1000 messages
> de cette liste ? 10, 20 ?

Les messages orienté dev *excluent* de fait les contributeurs qui ne
comprennent rien à la technique.

Il n'y a rien de honteux à parler sql, postgis, perl, python, shell dans
une liste dédiée a ce genre de problématique et rendre la liste talk-fr
plus accessible aux cartographe amateur non ingénieur/doctorant
informaticien.


Librement,
-- 
Christophe Merlet (RedFox)


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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Maurice]

Pieren  écrivit :

> 2010/8/1 Frédéric Rodrigo 
>
> Je relance. Peut être le temps de tirer un bilan, peut être le temps 
> d'attendre encore un peut.
> Toutes fois un résultat se profile déjà.
>
> C'est très curieux comme résultat. Combien parmi ceux qui ont voté pour une 
> liste dev sont des développeurs ? Ca
> ressemble plus à un vote d'exclusion qu'autre chose. D'autre part, les 
> messages purement développeurs, il y en a
> combien par mois sur les 800 à 1000 messages de cette liste ? 10, 20 ?
>
> Pieren

D'où l'on peut conclure que les « développeurs » sont les plus maladroits
pour configurer leur logiciel de courriels. Cherchez le paradoxe... On
pourrait aussi gloser sur la notion d'élitisme.

Maurice qui va se faire engueuler.

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

[OSM-talk-fr] [ OpenStreetMap et l'immobilier (Nestoria)

[RatZilla$]

Bonjour à Tou[te]s

Petit article sur les usages d'OSM:

Article de Techcrunch sur Nestoria (Moteur de recherche immobilier)
http://fr.techcrunch.com/?p=11217


Et le lien vers le site expérimental de Nestoria basée sur OSM:
http://openstreetmap.nestoria.fr/

Gaël

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

Re: [OSM-talk-fr] [dev] Caméras de surveillance

[Pierre-Alain Dorange]

Le 30 juil. 10 à 14:22, christophe a écrit :


pas de changement sur osm.vdska.de : 
http://osm.vdska.de/?lat=45.696856&lon=-0.332271&zoom=18&layers=B000FTFT&node=793023289

le site n'est peut être plus mis à jour ?



Apparemment non... Mes premières caméras ont été taggés il y a un  
mois... et toujours rien.


J'ai jeté un oeil rapide sur le source et on voit que ça utilise  
simplement OpenLayers et un text layer pour afficher les caméras.  
C'est-à-dire (1) que les POI (caméras ici) proviennent d'un fichier  
texte hébergé sur le site et donc que ce fichier texte n'a pas été mis  
à jour.


Du coup je teste de faire la même chose ici :


C'est une démo, j'y travaille un peu.
Le fichier texte est généré par un script python sur ma machine qui  
puise dans OSM (via XAPI).

Donc les données sont à jour à l'instant ou j'écris ces lignes.

Je n'ai qu'un hébergement réduit et pas la possibilité de faire  
tourner un script python sur le serveur donc je dois faire la mise à  
jour manuellement (exactement comme vdska.de donc).


Il y a actuellement que les caméras d'un bbox correspondant à la  
France (ça déborde sur nos voisins bien sur). Dans cette zone on  
compte 648 caméras en ce moment. Pour le monde c'est plus de 6000...  
Les textlayers de OpenLayers ne sont à priori pas fait pour gérer  
autant de POI il faut passer par un système plus sophistiqués...


J'ai repris les logos de la proposition (2), soit :

Vert : indoor (dans les boutiques, banques...)
Bleu : outdoor (extérieur sur des lieux privés)
Rouge : public (sur les lieux publics)
Noir : sans précision ou traffic

Coté utilisation/tag je saisi pas bien la nuance entre outdoor et  
public notamment pour des caméras multiangles qui sont sur un terrain  
privé mais on une zone de vision sur la voie publique.


Dès que j'aurai un peu plus avancé je mettrai le script python à  
disposition (le code javascript du site est directement accessible et  
très basique)


(1) 
(2) 


--
Pierre-Alain Dorange,
Blog Citoyen de Cognac : 
Twitter :  - Facebook : 


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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Vincent Pottier]

On 01/08/2010 18:48, Pieren wrote:
2010/8/1 Frédéric Rodrigo >


Je relance. Peut être le temps de tirer un bilan, peut être le
temps d'attendre encore un peut.
Toutes fois un résultat se profile déjà.


C'est très curieux comme résultat. Combien parmi ceux qui ont voté 
pour une liste dev sont des développeurs ? Ca ressemble plus à un vote 
d'exclusion qu'autre chose. D'autre part, les messages purement 
développeurs, il y en a combien par mois sur les 800 à 1000 messages 
de cette liste ? 10, 20 ?


Pieren


Il s'agit plus de développement OSM que développement logiciel.

Moi, j'ai voté "orienté dev" c'est à dire, dans ma tête:
- plugin cadastre
- imports
- projets spécifiques (geovelo, OSMTransport...)
- tagging
et pas seulement SQL, java, python, C++...

Donc dans ce cas, on est un peu plus nombreux qu'une vingtaine...
--
FrViPofm
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: Données ONEMA ?

[RatZilla$]

Bonjour à Tou[te]s,

La réunion à l'Onema est prévue Jeudi à 10h00.
Pour ceux qui ne s'en souviennent pas , l'Onema pourrait nous
permettre de disposer des données relatives aux cours d'eau. Si
certains d'entre vous veulent m'accompagner c'est OUI avec plaisir.

Gaël

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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Eric Marsden]

> "pd" == Pierre-Alain Dorange  writes:

  pd> Concernant la liste, je suis assez peu satisfait d'une liste de
  pd> discussion auquelle je préfère largement un forum usenet (bien
  pd> plus pratique à tout niveau AMHA).

  Il est possible de suivre (lire & poster) cette liste, comme bien
  d'autres concernant OSM, par NNTP via l'excellent Gmane

http://dir.gmane.org/gmane.comp.gis.openstreetmap.region.fr
  
-- 
Eric Marsden


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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[Pierre-Alain Dorange]

Eric Marsden  wrote:

>   Il est possible de suivre (lire & poster) cette liste, comme bien
>   d'autres concernant OSM, par NNTP via l'excellent Gmane
> 
> http://dir.gmane.org/gmane.comp.gis.openstreetmap.region.fr

(essai) réponse depuis gmane via NNTP.

-- 
Pierre-Alain Dorange



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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[sylvain letuffe]

Le samedi 31 juillet 2010 10:04:57, Ab_fab a écrit :
> Bonjour,
> 
> La relation de la Dordogne n'était pas reconnue car il y manquait
> l'attribut
> waterway:river
> 
> Corrigé hier soir. Depuis c'est ok.
> Le problème ne venait donc pas de la présence conjointe du tracé du cours
> principal et des berges.

Je dirais ne venait pas "que", en effet, sans le tag waterway=river, ce n'était 
pas pris en compte.

Mais cela ne règle pas forcément une autre "problème" qui était le calcul de 
longueur. Si les riverbanks sont dans la relation, leur longueur va être 
additionnée à celle du waterway, donc fausser la longueur total.

(Même raison, le rendu 
http://beta.letuffe.org/ressources/cartes/hydrographie-france.png
prend une salle gueule pour les rivières avec riberbanks puisque le trait 
devient plus épais et bourssouflé car le rendu dessine aussi bien le way 
central que les berges en bleu)

J'ai mis problème entre guillemets, car le problème peut très bien être 
considéré comme venant de mon truc.

--
sly


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[sylvain letuffe]

Le samedi 31 juillet 2010 09:46:57, Pierre-Alain Dorange a écrit :
> Le 31 juil. 10 à 00:03, sylvain letuffe a écrit :

> > relations are not catégories ?
> 
> Je suis pas sur de bien comprendre... 

Clairement, je n'ai pas été clair, car ce n'est pas clair non plus pour moi, 
ma question "ouverte" était, est-ce qu'en faisant ça on fleurte pas avec la 
création de catégories, en oubliant que la base spatiale peut (peut-être ?) 
nous déterminer tout ça ?

> Géographiquement c'est 
> On peut donc soir le définir par une frontière dessinée sur les
> limites de crêtes qui entourent un exutoire des eaux communs

Cette solution me semble bien meilleure/plus simple que de créer des relations 
qui s'appellent les unes les autres. 

> ; soit en
> regroupant l'ensemble du fleuve et de ses affluents.
> 
> Mais je me fait (probablement) des nœuds pour pas grand chose.

Je vois une autre idée (celle suggérée par christophe) qui consiste à 
déterminer les affluents et confluents par calcul des intersections, et de 
constuire les bassins versants par l'ensemble du réseau de cours d'eau (hors 
canaux) qui sont interconnectés.

Je ne suis pas certains que cela puisse gérer tous les cas, mais cette 
histoire de "tributary of", "affluents de", "se jette dans", me semble 
fortement 
ressembler au "is_in"


--
sly


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[Pierre-Alain Dorange]

sylvain letuffe  wrote:

> > Je me demandais: est-ce que ca serait possible d'autoriser les
> > relations qui contiendraient à la fois la way principale et les
> > riverbank, sous un rôle riverbank par exemple ?
> 
> osm2pgsql que j'utilise ne permet pas l'enregistrement du rôle, et donc ne me
> permet pas de distinguer les deux (le chemin central et les berges)
> 
> En outre, comme je l'indiquais dans ma plaidoirie "contre" cette méthode, le
> role me semble préférablement à utiliser pour définir la forme de la relation,
> et non sa nature, pour définir qu'il s'agit d'une route, d'une rivière, d'une
> berge, il me semble plus cohérent d'utiliser les tags, comme pour le reste.


Comme de nombreuses relations intègrent les riverbank (du moins du
partie de ceux-ci) ne pourrais tu pas dans tes scripts mouliner les way
de la relation pour ne considérer que les waterway=river dans le calcul
de longueur voir même le rendu. Cela ne se passe pas au niveau du role
dans la relation mais bien des tags de chaque way composant la relation.

Ca permettrait de ne plus avoir de taux >100% (ou du moins que pour les
rivières qui passent dans d'autres pays).

PS ; je ne sais pas quels outils tu utilises, donc je raconte peut être
une bétise.

-- 
Pierre-Alain Dorange



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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[Pierre-Alain Dorange]

sylvain letuffe  wrote:

> > Géographiquement c'est  On
> > peut donc soir le définir par une frontière dessinée sur les limites de
> > crêtes qui entourent un exutoire des eaux communs
> 
> Cette solution me semble bien meilleure/plus simple que de créer des
> relations qui s'appellent les unes les autres.

Plus simple... je suis pas sur, cela nécessite de dessiner ces
frontières sur la ligne de crêtes... Je sais pas faire ;-)

> 
> > ; soit en regroupant l'ensemble du fleuve et de ses affluents.
> > 
> > Mais je me fait (probablement) des nœuds pour pas grand chose.
> 
> Je vois une autre idée (celle suggérée par christophe) qui consiste à
> déterminer les affluents et confluents par calcul des intersections, et de
> constuire les bassins versants par l'ensemble du réseau de cours d'eau
> (hors canaux) qui sont interconnectés.

C'est une solution par un logiciel qui fait les calculs, ce n'est plus
une données "élémentaire" disponible dans la base.
C'est un peu comme si on laissé un logiciel calcul les frontières de la
France en cumulant toutes les frontières des communes par exemple mais
pourquoi pas.

> Je ne suis pas certains que cela puisse gérer tous les cas, mais cette
> histoire de "tributary of", "affluents de", "se jette dans", me semble
> fortement ressembler au "is_in"

Tout à fait, c'est dur à maintenir et le lien est fait par le nom (ce
qui peut apporter des ambiguités).
Et comment gérer les fleuves (tributary_of="océan atlantique") mais
l'océan n'est pas (si je ne m'abuse) un élément de OSM.

-- 
Pierre-Alain Dorange



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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[sylvain letuffe]

Le dimanche 1 août 2010 21:43:23, Pierre-Alain Dorange a écrit :
> > Cette solution me semble bien meilleure/plus simple que de créer des
> > relations qui s'appellent les unes les autres.
> 
> Plus simple... je suis pas sur, cela nécessite de dessiner ces
> frontières sur la ligne de crêtes... Je sais pas faire ;-)

Je te l'accorde, je réfléchissais en terme de plus facile une fois fait ;-) 
que de l'ensemble des relations qui s'appellent et dont le risque d'erreur me 
semble important.
Après sur le comment faire, déjà, à la main ça va pas être simple, mais peut 
être que sur une analyse d'un modèle de terrain type SRTM, ça doit être 
possible.

> C'est une solution par un logiciel qui fait les calculs, ce n'est plus
> une données "élémentaire" disponible dans la base.

En effet, peut-être alors une calcul "de temps en temps" et qui créer la 
surface du bassin versant et l'insère ensuite dans osm comme objet

> C'est un peu comme si on laissé un logiciel calcul les frontières de la
> France en cumulant toutes les frontières des communes par exemple mais
> pourquoi pas.

C'était la voie proposée par Marc S., mais ça implique d'avoir une relation 
qui contienne toutes les communes de france pour savoir ce qui est ou n'est 
pas une commune de france. Or, aujourd'hui, on (je) le détermine justement par 
calcul basé sur les frontières de la france... ça se mord la queue ;-)

--
sly


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[Frédéric Rodrigo]

Bonsoir,

Concernant ce sujet j'ai ajouté un proposition sur le wiki.
À la place d'utiliser "tributary_of", pour dire dans quoi se jette un 
cours d'eau, utiliser plutôt "tributary" comme rôle dans la relation 
pour ajouter tous les affluents d'un cours d'eau. L'affluent "compose" 
un cours d'eau, alors que l'inverse n'est pas vrais.

http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Waterway

De plus ça a l'avantage de permettre de reconstruire tout le bassin 
versant de manière récursive, quelque soit le cours d'eau et pas 
uniquement pour les fleuves. Vouloir reconstruire un basin versant 
uniquement par la topologie est pour moi illusoire. Il va toujours 
manquer quelque chose, ou on va tomber sur des cas compliqué non pris en 
charge... La relation apporte là de la sémantique.


Je me doute bien que des relations récursives font en faire bondir 
certains ;).


En se qui concerne l'utilisation du référentiel Sandre. Il faut faire 
attention.
Pour le calcul de la longuer d'une ref Sandre il faut ajouter la 
longueur de toutes les relations portant cette référence (cf ex sur le 
wiki du Midou et de la Midouze). Le Sandre "normalisant" les noms de 
cours d'eau, mais cela ne correspond pas forcement au terrain.
Ensuite il y a un autre élément à prendre ne compte. C'est la notion de 
cartographie d'éléments sinueux en fonction de l'echelle. Suivant la 
précision du tracé la longuer va varier, même si cour d'eau est 
complètement cartographié.
(Une explication plus compréhensible que la mienne 
http://www.cgenial.org/?n=-Quelle-est-la-longueur-des-cotes-anglaises-?_166_169 
)



Fred

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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[sylvain letuffe]

Le dimanche 1 août 2010 21:38:39, Pierre-Alain Dorange a écrit :

> Comme de nombreuses relations intègrent les riverbank (du moins du
> partie de ceux-ci) ne pourrais tu pas dans tes scripts mouliner les way
> de la relation pour ne considérer que les waterway=river dans le calcul
> de longueur voir même le rendu. 

Cette approche est possible techniquement en effet. Il est presque tout le 
temps possible de trouver l'algorithme qui va s'en sortir, sauf que est-ce le 
bonne voie ?
J'y vois un risque d'erreur :
- si un way n'est pas taggué en waterway=river mais appartient quand même à la 
relation, qu'en penser ? (ça peut se produire avec des frontières de communes 
qui sont tagguées boundary=administrative et qui ont comme support physique la 
rivière)

On pourrait se dire : c'est une erreur de mapping, il faut donc corriger, mais 
finalement ce n'est une erreur que parce qu'on le dit, structurellement ça peut 
très bien marcher (on peut quand même déduire qu'il s'agit d'une rivière car 
faisant partie de la relation)

D'ailleurs ça pourrait marcher par négation, si le way dans la relation est un 
riverbank, on peut imaginer le retirer, ça marcherait aussi. Ce qui tendrait à 
monter qu'ajouter le role "riverbank" est inutile puisque contenu dans les 
tags du way.

La question que je me pose, c'est que si je dois ruser pour m'en sortir, si 
l'outil de base osm2pgsql doit être modifié pour y arriver, est-ce que ça ne 
veut pas dire qu'a chaque fois que quelqu'un voudra reconstruire la rivière, 
il devra lui aussi faire un algorithme spécial. Et donc est-ce que ça 
n'indique pas que ce modèle n'est pas le plus adapté ?

La page :
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Waterway
indique : Members : any kind of waterway ways. They usually have a 
waterway=[river, canal, stream, drain, ditch] tag
no riverbank areas

Je pense que d'autres sont arrivés à la même conclusion que moi, même si je 
n'ai pas le "killer argument", je préfère ne pas inciter à faire autrement. 

--
sly


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[Pierre-Alain Dorange]

sylvain letuffe  wrote:

> > Comme de nombreuses relations intègrent les riverbank (du moins du
> > partie de ceux-ci) ne pourrais tu pas dans tes scripts mouliner les way
> > de la relation pour ne considérer que les waterway=river dans le calcul
> > de longueur voir même le rendu. 
> 
> Cette approche est possible techniquement en effet. Il est presque tout le
> temps possible de trouver l'algorithme qui va s'en sortir, sauf que est-ce
> le bonne voie ? J'y vois un risque d'erreur : - si un way n'est pas taggué
> en waterway=river mais appartient quand même à la relation, qu'en penser ?
> (ça peut se produire avec des frontières de communes qui sont tagguées
> boundary=administrative et qui ont comme support physique la rivière)
> 
> On pourrait se dire : c'est une erreur de mapping, il faut donc corriger,
> mais finalement ce n'est une erreur que parce qu'on le dit,
> structurellement ça peut très bien marcher (on peut quand même déduire
> qu'il s'agit d'une rivière car faisant partie de la relation)

Pour moi c'est clairement une erreur de mapping. Un tronçon sera
manquant sur la carte (je sais c'est le rendu) mais aussi à l'analyse
(mais que vient faire un boundary dans une relation waterway ?)...

> D'ailleurs ça pourrait marcher par négation, si le way dans la relation
> est un riverbank, on peut imaginer le retirer, ça marcherait aussi. Ce qui
> tendrait à monter qu'ajouter le role "riverbank" est inutile puisque
> contenu dans les tags du way.

Le "retirer" de l'analyse de la longueur de ton outils, je ne parle que
de ça.

> La question que je me pose, c'est que si je dois ruser pour m'en sortir,
> si l'outil de base osm2pgsql doit être modifié pour y arriver, est-ce que
> ça ne veut pas dire qu'a chaque fois que quelqu'un voudra reconstruire la
> rivière, il devra lui aussi faire un algorithme spécial. Et donc est-ce
> que ça n'indique pas que ce modèle n'est pas le plus adapté ?

En effet.
Je ne connais pas osm2pgsql (j'ai essayé de l'installer sur mon mac mais
j'ai abandonné plusieurs fois) et si tu dois envisager de la modifier
pour faire ça pas la peine... J'imaginais plutot que tu avais des
scripts (python ou autre) de traitement et que là a ce niveau c'est
"relativement" facile de filtrer pour calculer la longueur totale.
L'objectif n'est pas de pallier les défauts de tags, mais plutot de
fournir un vrai outil d'analyse pour améliorer l'existant. En calculant
correctement (seulement le cours principal) la longueur des cours d'eau
et avec ton % on a un réel état de l'avancement et cela peut motiver les
gens a continuer le travail.
Car aujourd'hui quand on voit un fleuve à 180% on se dis qu'il n'y a
rien a faire alors que peut être le waterway n'est que de 50% le reste
étant une parti des riverbank.

Mais tu as raison, le modèle avec riverbank n'est pas adapté. La
première étape de construction d'un cours d'eau c'est son cours
principal par autre chose.
 
> Je pense que d'autres sont arrivés à la même conclusion que moi, même si je
> n'ai pas le "killer argument", je préfère ne pas inciter à faire autrement.

OK
-- 
Pierre-Alain Dorange


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[Pierre-Alain Dorange]

Frédéric Rodrigo 
wrote:

> [...]
> En se qui concerne l'utilisation du référentiel Sandre. Il faut faire
> attention.
> Pour le calcul de la longuer d'une ref Sandre il faut ajouter la 
> longueur de toutes les relations portant cette référence (cf ex sur le
> wiki du Midou et de la Midouze). Le Sandre "normalisant" les noms de 
> cours d'eau, mais cela ne correspond pas forcement au terrain.
> Ensuite il y a un autre élément à prendre ne compte. C'est la notion de
> cartographie d'éléments sinueux en fonction de l'echelle. Suivant la 
> précision du tracé la longuer va varier, même si cour d'eau est 
> complètement cartographié.

Je te suis.
Et je me pose une autre question concernant notre cartographie des cours
d'eau et des bons usages.
J'ai cartographier plusieurs cours d'eau et j'ai bien sur rencontré des
iles, des bras et des zones presque maraicageuses.

Sandre semble définir le fleuve ou la rivière par son cours principal et
le cours d'eau y est représenté par un seul tracé.
Toutefois dans le réalité il y a de nombreux bras et parfois de très
nombreux... Comment les dessinez vous, comment créer la relation, etc...

Ainsi lorsque je tag un cours d'eau, je commence par son lit principal
(les riverbank c'est pour après) donc le waterway=river.
Du coup lorsque je rencontre des îles ou des bras je tag des waterway
secondaire en stream et pas en river (afin de marquer la différences
entre le lit principal et les bras) mais j'ai l'impression qu'il s'agit
d'une erreur... ou pas ?
Bien sur si on dessine le rivebank tout de suite ça permet d'outrepasser
ces problèmes (il faut toutefois faire le waterway principal quand même)
; mais c'est un gros boulot.
Peut être ne devrais-je pas dessiner les bras secondaires et passer au
riverbank ?

Un exemple pour mieux me faire comprendre :

Ici par exemple le fleuve charente a un wayerway=river qui appartient à
la relation "La Charente" et les autres petits bras son en
waterway=stream bien que certains soient dans la réalité aussi large que
le lit principal.
Devrais-je taggé tout en "river" et n'inclure que le principal dans la
relation ?


-- 
Pierre-Alain Dorange


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[sylvain letuffe]

Le dimanche 1 août 2010 22:45:27, Pierre-Alain Dorange a écrit :

> Ici par exemple le fleuve charente a un wayerway=river qui appartient à
> la relation "La Charente" et les autres petits bras son en
> waterway=stream bien que certains soient dans la réalité aussi large que
> le lit principal.
> Devrais-je taggé tout en "river" et n'inclure que le principal dans la
> relation ?

C'est ce que je fais moi. Je ne choisi stream que sur la base du wiki:

C'est un stream si :
"An active, able-bodied person should be able to jump over it if trees along 
it aren't too thick."

Bien que la remarque sur les arbres autour me fait un peu rire ;-)

Et je ne place qu'un seul des bras dans la relation (le principal/le plus 
gros, pour peu qu'il existe, sinon j'en prend un au pif)

Pour aller plus loin, il y a le tracé des berges ensuite.

--
sly


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[sylvain letuffe]

Le samedi 31 juillet 2010 11:53:36, Vincent Pottier a écrit :
> Il est fait allusion à mes suggestions... qui ne sont que des suggestions.

C'est bien comme ça que je les avais comprises, là je/on/nous blablate pour 
savoir ce qui semble le mieux (ou le moins pire ? ;-) ) avant qu'un courageux 
porte ça au niveau internationnal du wiki pour aller se faire couper en 
rondelles.

Je résume mon avis en disant, le but est bon, la méthode me plait moins.
 
> Pour résumer succinctement :
> la relation type=waterway organiserait les chemins waterway=river
> la relation type=river rassemblerait les éléments de la rivière
> dont la relation ci-dessus avec le rôle waterway

C'est comme ça que ça me semblerait bien, mais je n'ai pas pensé à tout et le 
discours est là pour trouver failles et améliorations.

PS: il faudra bien trouver un tag pour indiquer le nombre de canards au km² et 
la bonne relation pour le mettre !

--
sly


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

Re: [OSM-talk-fr] [Vote] Nouvelles listes de discussion

[hamster]

Pieren a écrit :
2010/8/1 Frédéric Rodrigo >


Je relance. Peut être le temps de tirer un bilan, peut être le temps
d'attendre encore un peut.
Toutes fois un résultat se profile déjà.


C'est très curieux comme résultat. Combien parmi ceux qui ont voté pour 
une liste dev sont des développeurs ? Ca ressemble plus à un vote 
d'exclusion qu'autre chose. D'autre part, les messages purement 
développeurs, il y en a combien par mois sur les 800 à 1000 messages de 
cette liste ? 10, 20 ?


on peut remarquer que les debutants et contributeurs "modestes", qui ne 
sont pas inscrits sur cette liste mais qu'on pourrait esperer attrapper 
avec un outil mieux adapte pour eux, n'ont pas vote


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[sylvain letuffe]

Le dimanche 1 août 2010 22:17:41, Frédéric Rodrigo a écrit :
> C'est la notion de
> cartographie d'éléments sinueux en fonction de l'echelle. Suivant la
> précision du tracé la longuer va varier, même si cour d'eau est
> complètement cartographié.

Ayant fini de regrouper tous les morceaux du rhône, jusqu'au galcier où il 
prend sa source, j'ai pû constater le problème de calcul :

780 dans osm contre 812 annoncé par wikipedia

Bien que j'exclus pas en plus un problème au niveau de la source (8km en plus 
peut-être), cela ne suffit pas à expliquer la différence restante de ~24 km

Je me suis creusé la tête pour finalement n'avoir d'explication que cette 
histoire d'échelle de tracé, et l'approximation dans osm qui consiste à 
décrire le cours d'eau par une ligne brisée alors qu'il devrait sans doute 
s'agir d'une courbe de la famille des courbes de bézier.

Sauf que je n'ai pas trouvé de solution pour approximer, ou mieux, calculer la 
distance de la courbe interpolée issue de la ligne brisée.

PS: d'ailleurs je ne pense pas que le problème soit le même que pour 
l'histoire de la côte fractale, bien que semblable, en tout cas, ça dépend de 
la définition par le sandre du "lit" de la rivière, qui, je le pense, doit être 
défini pour ne pas avoir une distance infinie

--
sly


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

Re: [OSM-talk-fr] Suivi des cours d'eau français

[Christophe Merlet]

Le dimanche 01 août 2010 à 23:39 +0200, sylvain letuffe a écrit :
> Le dimanche 1 août 2010 22:17:41, Frédéric Rodrigo a écrit :
> > C'est la notion de
> > cartographie d'éléments sinueux en fonction de l'echelle. Suivant la
> > précision du tracé la longuer va varier, même si cour d'eau est
> > complètement cartographié.
> 
> Ayant fini de regrouper tous les morceaux du rhône, jusqu'au galcier où il 
> prend sa source, j'ai pû constater le problème de calcul :
> 
> 780 dans osm contre 812 annoncé par wikipedia
> 
> Bien que j'exclus pas en plus un problème au niveau de la source (8km en plus 
> peut-être), cela ne suffit pas à expliquer la différence restante de ~24 km
> 
> Je me suis creusé la tête pour finalement n'avoir d'explication que cette 
> histoire d'échelle de tracé, et l'approximation dans osm qui consiste à 
> décrire le cours d'eau par une ligne brisée alors qu'il devrait sans doute 
> s'agir d'une courbe de la famille des courbes de bézier.
> 
> Sauf que je n'ai pas trouvé de solution pour approximer, ou mieux, calculer 
> la 
> distance de la courbe interpolée issue de la ligne brisée.
> 
> PS: d'ailleurs je ne pense pas que le problème soit le même que pour 
> l'histoire de la côte fractale, bien que semblable, en tout cas, ça dépend de 
> la définition par le sandre du "lit" de la rivière, qui, je le pense, doit 
> être 
> défini pour ne pas avoir une distance infinie

Je ne crois pas trop au "problème fractal" car j'ai pu constater sur de
grands trajets routiers de grandes que les distances annoncés par OSM
correspondait assez fidèlement à la distance mesuré au compteur
kilométrique de mon véhicule et ce même en empruntant des ronds points
ou des courbes dessinés avec des pelletées de nœuds !

Et il est normal que ce "problème fractale" ne se pose pas vraiment dans
OSM, car quelques soit le nombre de nœuds utilisés, on représente un
trajet médian dont la longueur est censé être invariable.


Librement,
-- 
Christophe Merlet (RedFox)


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