Le 18 septembre 2012 17:27, Ab_fab gamma@gmail.com a écrit :
Une idée de bonne pratique :
Celle que l'usage de waterway = riverbank est à réserver pour des
surfaces recouvrant des cours d'eaux filaires et nommés (par ex. waterway
= river et name = La Loire).
A ce sujet
A ce sujet waterway=riverbank doit-il être réservé aux rivières ou
convient-il aussi à un canal par exemple? Le wiki ne parle que des fleuves
et rivières larges:
http://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Driverbank.
Je pense que c'est possible, il n'y a pas de raison.
Si c'est
Pour moi, waterway = riverbank (surface) et waterway = canal (filaire)
peuvent se combiner
En pratique, cela se fait déjà :
Le 19 septembre 2012 15:42, Ab_fab gamma@gmail.com a écrit :
Pour moi, waterway = riverbank (surface) et waterway = canal (filaire)
peuvent se combiner
Et la tendance est plutôt en faveur de waterway=riverbank +
waterway=canal ou natural=water + water=canal + waterway=canal?
Le 18 septembre 2012 11:54, sly (sylvain letuffe) li...@letuffe.org a
écrit :
Certes, mais je trouve que le fichier osm auxquels on accèdent pour les
cours
d'eau cumulent de nombreuses tares tant d'existence sur le terrain que de
format des géométries dans le fichier osm, qui le font passer,
On Wed, Sep 19, 2012 at 3:46 PM, Romain MEHUT romain.me...@gmail.com wrote:
Et la tendance est plutôt en faveur de waterway=riverbank + waterway=canal
ou natural=water + water=canal + waterway=canal?
Difficile à dire. Il n'y a pas d'outil qui montre la progression de
l'usage de tel ou tel tag
Le 19 septembre 2012 16:25, Pieren pier...@gmail.com a écrit :
On Wed, Sep 19, 2012 at 3:46 PM, Romain MEHUT romain.me...@gmail.com
wrote:
Et la tendance est plutôt en faveur de waterway=riverbank +
waterway=canal
ou natural=water + water=canal + waterway=canal?
Difficile à dire. Il n'y
On mercredi 19 septembre 2012, Romain MEHUT wrote:
Et la tendance est plutôt en faveur de waterway=riverbank +
waterway=canal ou natural=water + water=canal + waterway=canal?
natural=water + water=canal + waterway=canal n'est préconisée nulle part,
c'est natural=water + water=canal pour
Le 19 septembre 2012 16:38, sly (sylvain letuffe) li...@letuffe.org a
écrit :
On mercredi 19 septembre 2012, Romain MEHUT wrote:
Et la tendance est plutôt en faveur de waterway=riverbank +
waterway=canal ou natural=water + water=canal + waterway=canal?
natural=water + water=canal +
Oui bien entendu, je parlais à la fois de la surface et du way. On est
d'accord.
ok, alors mon reproche à l'utilisation de waterway=riverbank seul pour tagguer
la surface est que l'on ne peut distinguer une rivière, d'un ruisseau, d'un
canal à moins d'analyser le way qui le traverse, mais ce
2012/9/19 sly (sylvain letuffe) li...@letuffe.org:
ok, alors mon reproche à l'utilisation de waterway=riverbank seul pour tagguer
la surface est que l'on ne peut distinguer une rivière, d'un ruisseau, d'un
canal à moins d'analyser le way qui le traverse, mais ce qui me semble
s'avérer plus
Donc préciser que c'est une rivière ou un ruisseau sur le
way central ET sur la berge fait un peu doublon.
J'ai envie d'aller plus loin en disant simplement que tracer le way central
et les berges ça fait doublon
Mais c'est comme ça qu'on fait, et la raison est à mon avis avant tout pour la
Le 19 septembre 2012 17:21, sly (sylvain letuffe) li...@letuffe.org a écrit :
Dans un rêve éveillé d'algorithme miraculeux, on pourrait faire du routage sur
surface, retrouver le sens du courant par le point de connexion à la mer et à
la source (et éventuellement gérer uniquement les très rares
Désolé d'être bref, la ML est du à suivre depuis quelques jours.
Je suis également pour une suppression de la couche water de cadastre.osm.fr
.
Ce sujet revient régulièrement sur la ML, il est temps que l'on se fasse
une réponse.
Les riverbanks sont, dans une grande partie des communes
Bonsoir,
Je plussoie avec décalage, mais oui il faut cacher la possibilité d'import de
la couche eau du cadastre.
Ce qui n'empêche pas, en plus, un outil de surveillance.
Brice
Le 19 sept. 2012 à 21:39, Etienne
Qu'en pensez-vous?
Entièrement d'accord.
Si les données water semblent indispensables à un utilisateur d'ici
là, il est toujours possible de décalquer à partir du plugin cadastre.
Et, comme le fait remarquer Hélène, je vois mal comment intégrer
correctement le cadastre aujourd'hui si
Le 17/09/2012 23:39, sly (sylvain letuffe) a écrit :
Le lundi 17 septembre 2012 23:19:59, Eric Marsden a écrit :
- nous cherchions à développer un algorithme pour déterminer la
représentation filaire à partir de la représentation surfacique (mon
niveau en PostGIS est hélas trop
Je ne sais pas si vous vous rendez compte mais ça n'est pas le rôle de
la fondation, ni du DWG de décider de la pertinence des données à
importer. C'est à nous, en tant que communauté des contributeurs de le
faire. Il y a ici un énorme dévoiement des missions de la fondation.
C'est scandaleux
Bonjour,
Je suis d'accord avec la plupart des points soulevs dans cette
discussion sur les problmes d'importation des surfaces en eaux
depuis le cadastre. Mais je suis contre un point en particulier : ne
plus mettre disposition la couche water sur le site
On mardi 18 septembre 2012, Nicolas Moyroud wrote:
Bonjour,
Je suis d'accord avec la plupart des points soulevés dans cette discussion
sur les problèmes d'importation des surfaces en eaux depuis le cadastre.
Mais je suis contre un point en particulier : ne plus mettre à disposition
la
Le mardi 18 septembre 2012 à 10:53 +0200, Nicolas Moyroud a écrit :
Bonjour,
Dernier point, dans la zone où je cartographie (sud de la France), il
y a énormément de piscines et j'utilise la couche cadastre pour les
ajouter. Je ne veux pas relancer ici le débat sur les piscines. Je
considère
2012/9/18 sly (sylvain letuffe) li...@letuffe.org:
ça peut être envisageable, le fait que l'on retrouve côte à côte, dans le même
panier, sur un pied d'égalité, des données comme le bâti et les frontières
qui sont de bonne qualité et celles des cours d'eau qui varient de bonnes à
On mardi 18 septembre 2012, Pieren wrote:
Euh, il aurait aussi beaucoup à dire sur la qualité du bâti et des
frontières du cadastre.
Certes, mais je trouve que le fichier osm auxquels on accèdent pour les cours
d'eau cumulent de nombreuses tares tant d'existence sur le terrain que de
format
Le 18/09/2012 11:54, sly (sylvain letuffe) a écrit :
On mardi 18 septembre 2012, Pieren wrote:
untel wrote : etc...
Il est question de pas public, il est question de recommandations...
Et si les fichiers cadastre, tous, pas seulement water... étaient
accessibles après login, acceptation de
Une idée de bonne pratique :
Celle que l'usage de waterway = riverbank est à réserver pour des
surfaces recouvrant des cours d'eaux filaires et nommés (par ex. waterway
= river et name = La Loire).
J'ai l'intuition que c'est un minimum, Les exceptions pouvant dès lors être
marquées comme erreurs
Bonsoir,
Comme vous avez pu le suivre ici, l'importation de données depuis le
cadastre numérique est critiqué par différentes personnes du monde
Openstreetmap, dont certaines ont un certain poids politique dans le
projet (par exemple, le nouveau président de l'OSMF, Simon Poole, est un
intégriste
Le lundi 17 septembre 2012 23:19:59, Eric Marsden a écrit :
Je suis embêté pour défendre l'usage qui est fréquemment fait des
données sur les cours d'eau issues du cadastre.
Je le serais aussi.
Ces données accumulent
plusieurs défauts importants
Je suis entièrement d'accord avec tout ce
Bonsoir,
Le 17/09/2012 23:19, Eric Marsden a écrit :
J'ai récemment défendu une utilisation raisonnée des données bâtiments
du cadastre auprès du Data Working Group, qui fait de l'activisme sur le
sujet (allant à mon avis bien au delà de son mandat, et ne respectant
pas le principe basique de
Comme vous avez pu le suivre ici, l'importation de données depuis le
cadastre numérique [...]
On n'importe pas le cadastre, on l'intègre ;-)
Éric
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Entièrement d'accord et ça évitera les piscines en natural=water
Et oui... on n'importe pas, on intègre... après travail manuel non
automatisable.
--
Christian Quest - OpenStreetMap France -
http://openstreetmap.fr/u/cquesthttp://openstreetmap.fr/u/christian-quest
Salut Éric,
Eric Marsden a écrit :
J'ai récemment défendu une utilisation raisonnée des données bâtiments
du cadastre auprès du Data Working Group
Et je t'en remercie. J'ai lu tes messages et d'autres (ceux de Pieren
notamment), ils sont tout à fait pertinents. Je suis agacé que le DWG
n'en
Le 17/09/2012 23:19, Eric Marsden a écrit :
Bonsoir,
Comme vous avez pu le suivre ici, l'importation de données depuis le
cadastre numérique est critiqué par différentes personnes du monde
Openstreetmap, dont certaines ont un certain poids politique dans le
projet (par exemple, le nouveau
2012/9/17 Sébastien Dinot sebastien.di...@free.fr:
Je suis embêté pour défendre l'usage qui est fréquemment fait des
données sur les cours d'eau issues du cadastre. Ces données accumulent
plusieurs défauts importants (et pour ma part, je ne les intègre pas
dans OSM):
Je ne sais pas si vous
rn == Pieren pier...@gmail.com writes:
rn Je ne sais pas si vous vous rendez compte mais ça n'est pas le rôle de
rn la fondation, ni du DWG de décider de la pertinence des données à
rn importer. C'est à nous, en tant que communauté des contributeurs de le
rn faire. Il y a ici un énorme
Juste très rapidement... pour donner un avis complémentaire que j'ai déjà
donné sur d'anciens sujets du même genre: j'habite dans le MARAIS POITEVIN,
deuxième zone humide de la france! et nous avons de nombreux canaux et
divers cours d'eau de différentes tailles et cette couche est bien utile (je
+1 parfaitement d'accord avec tout ce qui précède et sur le point de ne
plus fournir de fichiers tout prêts pour un mauvais import automatique sans
intervention supplémentaires ...
le dernier contact que j'ai eu avec un import de rivière depuis le cadastre
se situe autour de
Am 17.09.2012 23:19, schrieb Eric Marsden:
Qu'en pensez-vous?
Entièrement d'accord avec tout ce que tu écris!
Rainer
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
37 matches
Mail list logo
