Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Ab_fab
Bonjour,

"Il n'existe donc plus qu'une seule relation type=multipolygone +
waterway=riverbank" (pour toute la Loire)

Pour le rendu cela signifie qu'en voulant faire le rendu d'une tuile à St
Nazaire, tu dois aller charger des données jusqu'au Puy en Velay pour
vérifier que l'étendue d'eau est fermée, n'est-ce pas ?

Et un rendu qui ne se baserait que sur un extrait régional (par ex. les
Pays de Loire) ne pourrait pas s'assurer de la fermeture du polygone.
Je ne nie pas que c'est la réalité du terrain, mais j'imagine que c'est
super contraignant pour les rendus (en particulier de zones restreintes,
comme avec Maperitive).

Bonne journée


Le 7 février 2014 08:00, djo_man  a écrit :

>  Bonjour
>
> *POUR INFO :*
> La Loire a retrouvé ses Iles.
> Il n'existe donc plus qu'une seule relation type=multipolygone +
> waterway=riverbank
> http://www.openstreetmap.org/relation/2794697
>
> *MAIS :*
> il s'agit du schéma de tag ancien.
> Le nouveau : type=multipolygone + natural=water + water=river ne
> fonctionne pas dans le rendu ORG et FR
> http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>
> Pour Christian,
> Ce nouveau schéma n'est pas implémenté dans le rendu ?
>
> merci
> djo_man
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://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
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Christian Quest
natural=water est bien sûr rendu par les deux rendus ORG et FR.

Je ne pense pas avoir traité le water=river comme cas particulier, donc si
ça coince c'est sûrement ailleurs que dans la feuille de style.

+1 avec Ab_fab, ce genre de relation n'aide pas vraiment à la réutilisation.

Il suffit par exemple qu'un seul noeud soit modifié pour que tout le
multipolygone soit impacté et donc toutes les tuiles correspondantes soient
invalidées sur des centaines de km.

Vu que chaque membre est taggué comme un polygone (waterway=riverbank) on
se retrouve de plus avec le double de géométries.

A quoi sert au final de telles mega-relations ?

Ca m'aurait semblé moins gênant d'avoir un ref:sandre=* ou un name=* sur
les membres pour les retrouver, ou alors utiliser une relation
type=collection.



Le 7 février 2014 08:00, djo_man  a écrit :

>  Bonjour
>
> *POUR INFO :*
> La Loire a retrouvé ses Iles.
> Il n'existe donc plus qu'une seule relation type=multipolygone +
> waterway=riverbank
> http://www.openstreetmap.org/relation/2794697
>
> *MAIS :*
> il s'agit du schéma de tag ancien.
> Le nouveau : type=multipolygone + natural=water + water=river ne
> fonctionne pas dans le rendu ORG et FR
> http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
>
> Pour Christian,
> Ce nouveau schéma n'est pas implémenté dans le rendu ?
>
> merci
> djo_man
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Ista Pouss
Le 7 février 2014 09:03, Ab_fab  a écrit :

> Pour le rendu cela signifie qu'en voulant faire le rendu d'une tuile à St
> Nazaire, tu dois aller charger des données jusqu'au Puy en Velay pour
> vérifier que l'étendue d'eau est fermée, n'est-ce pas ?
>
>
Pourquoi donc ? pourquoi est-il nécessaire de savoir que cette étendue
d'eau est fermée dans ce cas ?

(c'est pour ma culture personnelle)

(et puis la Loire ne passe pas au Puy, mais juste à coté) (à environ 20m :
http://osm.org/go/0Aigz6oNl-?relation=120067)


> Et un rendu qui ne se baserait que sur un extrait régional (par ex. les
> Pays de Loire) ne pourrait pas s'assurer de la fermeture du polygone.
> Je ne nie pas que c'est la réalité du terrain, mais j'imagine que c'est
> super contraignant pour les rendus (en particulier de zones restreintes,
> comme avec Maperitive).
>
>
Oui, mais si on résoud le problème pour la Loire, ce sera plus facile
ensuite pour le Nil et l'Amazone.


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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Pieren
2014-02-07 9:32 GMT+01:00 Christian Quest :

> +1 avec Ab_fab, ce genre de relation n'aide pas vraiment à la réutilisation.

Oui, il faut absolument éviter que ça se propage à d'autres fleuves.
Les grosses relations sont, en général, à éviter lorsque c'est
possible : elles sont plus difficiles à maintenir (les relations sont
souvent cassées par des débutants) et elles nécessitent plus de
ressources (surtout si on veut consulter l'historique). Je
conseillerais même de scinder cette relation multipolygon en plus
petits morceaux dès que possible.
Concernant les nouveaux tags, j'ai toujours un peu de réticence à voir
deux schémas coexister simplement pour que le rendu fonctionne
partout. En même temps, si personne n'utilise le nouveau schéma, les
développeurs ne vont pas non plus changer les feuilles de style. Cette
cohabitation est acceptable à condition que ce soit pour un temps
limité. On voit aussi parfois certaines propositions de nouveaux
schémas stagner dans les stats, bien qu'elles aient été formellement
"votées". Parfois un nouveau tag accepté par 16 personnes ne rencontre
pas le succès escompté auprès de la communauté. C'est particulièrement
vrai lorsque le nouveau schéma est plus complexe que l'ancien (plus de
tags, par ex.). Il faut que le changement apporte une vrai plus-value.

Pieren

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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Frédéric Rodrigo
Le lit de rivière est une entité unique. La Loire n'est pas la seule à 
être faite avec une relation. La Dordogne l'est, la Garonne l'était mais 
ça a été détruit et remplacé par une succession de polygone et et 
multipolygone a l'ancienne (pour le deuxième fois). Il n'y a pas de 
problème conceptuel à représenter les choses comme ça, l'inverse l'est 
parcontre. Le problème est au niveau des renvu je veux bien le croire. 
Mais ce n'est pas pour moi une raison suffisante, on ne mappe pas pour 
le rendu n'est ce pas. Pour l'edition on n'a de toute façon pas besoin 
de la totalité de la relation


Frédéric.


Le 07/02/2014 10:17, Pieren a écrit :

2014-02-07 9:32 GMT+01:00 Christian Quest :


+1 avec Ab_fab, ce genre de relation n'aide pas vraiment à la réutilisation.


Oui, il faut absolument éviter que ça se propage à d'autres fleuves.
Les grosses relations sont, en général, à éviter lorsque c'est
possible : elles sont plus difficiles à maintenir (les relations sont
souvent cassées par des débutants) et elles nécessitent plus de
ressources (surtout si on veut consulter l'historique). Je
conseillerais même de scinder cette relation multipolygon en plus
petits morceaux dès que possible.
Concernant les nouveaux tags, j'ai toujours un peu de réticence à voir
deux schémas coexister simplement pour que le rendu fonctionne
partout. En même temps, si personne n'utilise le nouveau schéma, les
développeurs ne vont pas non plus changer les feuilles de style. Cette
cohabitation est acceptable à condition que ce soit pour un temps
limité. On voit aussi parfois certaines propositions de nouveaux
schémas stagner dans les stats, bien qu'elles aient été formellement
"votées". Parfois un nouveau tag accepté par 16 personnes ne rencontre
pas le succès escompté auprès de la communauté. C'est particulièrement
vrai lorsque le nouveau schéma est plus complexe que l'ancien (plus de
tags, par ex.). Il faut que le changement apporte une vrai plus-value.



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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Pieren
2014-02-07 10:32 GMT+01:00 Frédéric Rodrigo :

> Le lit de rivière est une entité unique.

Oui, la forêt amazonienne aussi. Ca n'est pas une raison pour faire un
seul polygone qui couvrirait le cinquième de l'amérique du sud (au
pif). Il faut parfois être pragmatique. Il n'y a aucune nécessité à
faire un seul polygone pour les riverbank. Alors si on peut l'éviter,
autant revenir à quelque chose de plus facile à maintenir pour les
contributeurs (je dis bien "si on a le choix", ce qui n'est pas
toujours possible). Je ne parle pas de rendu ici mais de difficulté à
maintenir les grosses relations en général (c'est vrai aussi pour les
itinéraires "type=route").
J'imagine bien que ça peut poser quelques difficultés supplémentaires
pour les consommateurs de données qui devront faire une requête
spatiale un peu compliquée pour récupérer tous les contours. Mais il y
a aussi la solution proposée par Christian (une superrelation). Et de
manière générale, dans OSM, on privilégie toujours la solution qui
facilite la vie des contributeurs, pas celle qui facilite la vie des
consommateurs de données au détriment des contributeurs. Ce sont ces
derniers qui font vivre le projet et qu'il faut choyer en priorité.

Pieren

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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet djo_man

  
  
bonjour, 

ab_fab:
non pas du tout.
il ne s'agit pas d'une relation par ways ouverts outer mais d'une
relation ajoutant des ways fermé outer

djo_man

Le 07/02/2014 09:03, Ab_fab a écrit :


  
Bonjour,

  
"Il
n'existe donc plus qu'une seule relation type=multipolygone
+ waterway=riverbank" (pour toute la Loire)


  
Pour le rendu cela signifie qu'en voulant faire le rendu d'une
tuile à St Nazaire, tu dois aller charger des données jusqu'au
Puy en Velay pour vérifier que l'étendue d'eau est fermée,
n'est-ce pas ?

  

Et un rendu qui ne se baserait que sur un extrait régional
  (par ex. les Pays de Loire) ne pourrait pas s'assurer de la
  fermeture du polygone. 
Je ne nie pas que c'est la réalité du terrain, mais
  j'imagine que c'est super contraignant pour les rendus (en
  particulier de zones restreintes, comme avec Maperitive). 
  
  
  Bonne journée

  
  

Le 7 février 2014 08:00, djo_man 
  a écrit :
  
 Bonjour
  
  POUR INFO :
  La Loire a retrouvé ses Iles.
  Il n'existe donc plus qu'une seule relation
  type=multipolygone + waterway=riverbank
  http://www.openstreetmap.org/relation/2794697
  
  
  MAIS :
  il s'agit du schéma de tag ancien.
  Le nouveau : type=multipolygone + natural=water +
  water=river ne fonctionne pas dans le rendu ORG et FR
  http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
  
  Pour Christian,
  Ce nouveau schéma n'est pas implémenté dans le rendu ?
  
  merci
  djo_man


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




  


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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet djo_man

  
  
bonjour, 

Vous faites erreur.

la relation est constituée de ways fermé OUTER et non pas de ways
ouvert OUTER. ça change tout.

En plus, et comme le wiki le demande, les ways fermés OUTER ( qui
n'ont pas changés ) sont taggués sur l'objet en waterway=riverbank
Ce sont les iles INNER qui posaient problèmes car non pris en compte
dans le schema nouveau : natural=water + water=river

Je comprend votre confusion vu que sur le wiki il est décrit 2
schémas mais avec plusieurs méthodes. les ways fermés et les ways
ouvert

Cependant, comme Christian, je ne comprend pas pourquoi les iles ne
seraient pas rendus avec le schema natural=water 
C'est pourtant les cas. J'ai laissé durant 1 semaine ce schema en
place, et les iles n'apparaissaient pas.
Mais dés replacement du schema waterway=riverbank dans la relation,
les iles sont réapparues assez rapidement (1 jour pour les tuiles
souvent appellées)

si je me suis planté, je ne vois pas ou...
En tout cas ça remarche !

djo_man


Le 07/02/2014 10:44, Pieren a écrit :


  2014-02-07 10:32 GMT+01:00 Frédéric Rodrigo :


  
Le lit de rivière est une entité unique.

  
  Oui, la forêt amazonienne aussi. Ca n'est pas une raison pour faire un
seul polygone qui couvrirait le cinquième de l'amérique du sud (au
pif). Il faut parfois être pragmatique. Il n'y a aucune nécessité à
faire un seul polygone pour les riverbank. Alors si on peut l'éviter,
autant revenir à quelque chose de plus facile à maintenir pour les
contributeurs (je dis bien "si on a le choix", ce qui n'est pas
toujours possible). Je ne parle pas de rendu ici mais de difficulté à
maintenir les grosses relations en général (c'est vrai aussi pour les
itinéraires "type=route").
J'imagine bien que ça peut poser quelques difficultés supplémentaires
pour les consommateurs de données qui devront faire une requête
spatiale un peu compliquée pour récupérer tous les contours. Mais il y
a aussi la solution proposée par Christian (une superrelation). Et de
manière générale, dans OSM, on privilégie toujours la solution qui
facilite la vie des contributeurs, pas celle qui facilite la vie des
consommateurs de données au détriment des contributeurs. Ce sont ces
derniers qui font vivre le projet et qu'il faut choyer en priorité.

Pieren

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





  


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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Ab_fab
Rebonjour,

En effet, ça change tout. Désolé pour la confusion et le bruit !


Le 7 février 2014 12:14, djo_man  a écrit :

>  bonjour,
>
> Vous faites erreur.
>
> la relation est constituée de ways fermé OUTER et non pas de ways ouvert
> OUTER. ça change tout.
>
> En plus, et comme le wiki le demande, les ways fermés OUTER ( qui n'ont
> pas changés ) sont taggués sur l'objet en waterway=riverbank
> Ce sont les iles INNER qui posaient problèmes car non pris en compte dans
> le schema nouveau : natural=water + water=river
>
> Je comprend votre confusion vu que sur le wiki il est décrit 2 schémas
> mais avec plusieurs méthodes. les ways fermés et les ways ouvert
>
> Cependant, comme Christian, je ne comprend pas pourquoi les iles ne
> seraient pas rendus avec le schema natural=water 
> C'est pourtant les cas. J'ai laissé durant 1 semaine ce schema en place,
> et les iles n'apparaissaient pas.
> Mais dés replacement du schema waterway=riverbank dans la relation, les
> iles sont réapparues assez rapidement (1 jour pour les tuiles souvent
> appellées)
>
> si je me suis planté, je ne vois pas ou...
> En tout cas ça remarche !
>
> djo_man
>
>
> Le 07/02/2014 10:44, Pieren a écrit :
>
> 2014-02-07 10:32 GMT+01:00 Frédéric Rodrigo  
> :
>
>
>  Le lit de rivière est une entité unique.
>
>  Oui, la forêt amazonienne aussi. Ca n'est pas une raison pour faire un
> seul polygone qui couvrirait le cinquième de l'amérique du sud (au
> pif). Il faut parfois être pragmatique. Il n'y a aucune nécessité à
> faire un seul polygone pour les riverbank. Alors si on peut l'éviter,
> autant revenir à quelque chose de plus facile à maintenir pour les
> contributeurs (je dis bien "si on a le choix", ce qui n'est pas
> toujours possible). Je ne parle pas de rendu ici mais de difficulté à
> maintenir les grosses relations en général (c'est vrai aussi pour les
> itinéraires "type=route").
> J'imagine bien que ça peut poser quelques difficultés supplémentaires
> pour les consommateurs de données qui devront faire une requête
> spatiale un peu compliquée pour récupérer tous les contours. Mais il y
> a aussi la solution proposée par Christian (une superrelation). Et de
> manière générale, dans OSM, on privilégie toujours la solution qui
> facilite la vie des contributeurs, pas celle qui facilite la vie des
> consommateurs de données au détriment des contributeurs. Ce sont ces
> derniers qui font vivre le projet et qu'il faut choyer en priorité.
>
> Pieren
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://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
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Pieren
2014-02-07 13:32 GMT+01:00 Ab_fab :

> En effet, ça change tout. Désolé pour la confusion et le bruit !

>> la relation est constituée de ways fermé OUTER et non pas de ways ouvert
>> OUTER. ça change tout.

Au contraire, c'est pire ! Si ce sont des ways fermés qui se touchent.
Suivant les logiciels qui les traitent, le multipolygone pourrait être
considéré comme invalide:

http://postgis.refractions.net/docs/using_postgis_dbmanagement.html#OGC_Validity

Il n'y a pas trop de logique à assembler tous ces polygones en
conservant des ways fermés (si ce n'est, peut-être, à réduire le
nombre de ways et donc de membres de la relation). Si l'idée de départ
est de dire que c'est "une entité unique", ajouter des ways
(artificiels) qui traversent le fleuve à intervalle régulier ne
correspond à rien dans le monde réel. Autant aller jusqu'au bout de
votre logique et ne garder que les berges. Mais personnellement, je
préfère, et de loin, conserver les ways fermés et éventuellement
couplés à une relation multipolygon lorsqu'il y des ilots à
l'intérieur.

Pieren

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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Pieren
2014-02-07 14:50 GMT+01:00 djo_man :
> La méthode pour la relation riverbank
> type=multipolygone + waterways=riverbank sur des ways fermé OUTER qui se
> touchent avec des iles en INNER :
> vient du wiki.

Je connais. D'ailleurs, la méthode avec un seul gros polygone outer
est aussi présentée (et aussi contestée, comme quoi, ça n'arrive pas
qu'en France ;-)
Mais pour revenir au wiki, le paragraphe sur la relation multipolygon
ne concerne que des petites sections qui contiennent des îlots, pas
l'ensemble du fleuve (ou rivière). Alors que la version actuelle de la
relation "Loire" dans OSM avec la somme de ways fermés n'est jamais
présentée comme modèle (il n'y a que celle qui suggère de mettre
uniquement l'ensemble des berges - ways ouverts - dans une relation
unique).


> avant il y  avait 2 voire 3 relations au même endroit.
> (certaines en reprenant juste le OUTER et ajoutant juste quelques iles dont
> les autres relations n'avaient pas)
> personne ne savaient pourquoi.
> laquelle modifier ?
> personne ne prenant le temps de supprimer ce qu'il faut
> plusieurs fois La Loire a inondé ses iles à cause de mauvaises
> manipulation/ajout de relation, etc (3 fois en 2 ans: c'est plus que
> d'hivers...)

J'ai bien compris qu'il y avait auparavant un certain nombre de
problèmes. Mais il existait sans doute une façon plus simple de les
résoudre que de créer une relation unique. J'aurais pu donner un coup
de main à ce moment-là. Je ne pensais pas que ça partirait dans cette
direction.

> je veux bien modifier ce qu'il faut mais pour aboutir à quoi au juste ?
> sans compter qu'il faut que le rendu rende... (sinon La Loire va encore être
> inondé: ça le fait pas...)

Surtout qu'en matière d'inondations (réelles), on a notre compte en ce
moment ;-)
Moi, ce que je propose, c'est de supprimer la grosse relation
multipolygon et de n'en faire que des petites aux endroits nécessaires
(c.a.d. là où il y a des îlots et uniquement là). Je pourrais aussi
m'en charger sauf s'il y a trop de gens qui pensent qu'il vaut mieux
en rester là.

Pieren

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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet djo_man

  
  

Le 07/02/2014 15:12, Pieren a écrit :


  
Moi, ce que je propose, c'est de supprimer la grosse relation
multipolygon et de n'en faire que des petites aux endroits nécessaires
(c.a.d. là où il y a des îlots et uniquement là). 



Je crois que le problème à la base vient de cela.
Des relations basées sur un seul way fermé riverbank avec ses iles.
donc 30/40 relations (je ne sais plus)
avec le temps d'autres ont été ajoutés pour faire apparaitre les
iles oubliées .

c'est aux alentours des grosses villes et alentours des sections
avec beaucoup d'iles qu'il y avaient le plus de problèmes.
les embrouilles ne sont forcement arrivés que petit à petit.

pour info: environ 95% des OUTER de la Loire ont des INNER (iles)

Dans ce cas, cela reviendrait à faire au moins 30/40 relations...

djo_man
  


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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Christian Quest
Il ne faut pas mélanger deux concepts derrière les relations OSM.

Il y a les relations qui servent à créer des géométries complexes: les
multipolygones

Il y a les relations qui servent à définir une logique entre objets,
logique qu'on ne pourrait pas déterminer autrement (facilement ou pas du
tout) : les itinéraires, les lignes de bus, les interdictions de tourner,
etc.


Là on veut faire quoi au juste ?

type=multipolygon rentre actuellement dans le premier cas, mais une seule
et unique relation pour l'ensemble d'un fleuve n'apporte pas grand chose à
part plein de problème tant à l'édition (ça donne quoi dans iD ? j'ose pas
regarder) qu'à la réutilisation vu la taille finale (un noeud qui bouge et
tout à recalculer tout du long comme déjà expliqué).

Avoir quelques multipolygones (même 30 ou 40) me semble nettement plus
facile à gérer tant pour l'édition que la réutilisation.

Si l'on veut par contre récupérer la surface de la Loire :
a- soit on a sur les waterway=riverbank un ref:sandre=* qui permet de les
retrouver sans passer par une requête géométrique
b- soit on s'y prend avec des requêtes géométriques (tout
waterway=riverbank en intersection avec un waterway=river faisant partie de
la relation "La Loire"),
c- soit on a une super-relation "logique", mais pas géométrique qui fait ce
regroupement (donc pas type=multipolygon)... mais elle sera difficile à
maintenir donc souvent cassée et donc un réutilisateur sérieux se ré-écrira
la requête géométrique qui va bien et ne l'utilisera sûrement pas ;)

Mon tiercé: a, b et au pire c.


Le 7 février 2014 15:46, djo_man  a écrit :

>
> Le 07/02/2014 15:12, Pieren a écrit :
>
> Moi, ce que je propose, c'est de supprimer la grosse relation
> multipolygon et de n'en faire que des petites aux endroits nécessaires
> (c.a.d. là où il y a des îlots et uniquement là).
>
>
> Je crois que le problème à la base vient de cela.
> Des relations basées sur un seul way fermé riverbank avec ses iles. donc
> 30/40 relations (je ne sais plus)
> avec le temps d'autres ont été ajoutés pour faire apparaitre les iles
> oubliées .
>
> c'est aux alentours des grosses villes et alentours des sections avec
> beaucoup d'iles qu'il y avaient le plus de problèmes.
> les embrouilles ne sont forcement arrivés que petit à petit.
>
> pour info: environ 95% des OUTER de la Loire ont des INNER (iles)
>
> Dans ce cas, cela reviendrait à faire au moins 30/40 relations...
>
> djo_man
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Pieren
2014-02-07 15:46 GMT+01:00 djo_man :

> c'est aux alentours des grosses villes et alentours des sections avec
> beaucoup d'iles qu'il y avaient le plus de problèmes.
> les embrouilles ne sont forcement arrivés que petit à petit.
>
> pour info: environ 95% des OUTER de la Loire ont des INNER (iles)
>
> Dans ce cas, cela reviendrait à faire au moins 30/40 relations...

C'est pas 40 relations qui vont m'arrêter ^^ Ca peut paraître beaucoup
mais elles seront aussi plus petites et donc plus facile à gérer.

Pieren

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


Re: [OSM-talk-fr] [Talk-ht] NIght of the Living Maps

2014-02-07 Par sujet Christian Quest
Je suis partant sur Paris... mais quelle est la date prévue ?

On se refait ça dans ensemble IRL ou bien IRC ?


Le 7 février 2014 15:58, Severin MENARD  a écrit :

> Je précise que l'initiative NOTLM n'est pas du tout de moi, mais nous y
> avions participé avec l'équipe de Saint-Marc (qui est devenue par la suite
> COSMHA-STM). Une vidéo pour ceux qui n'étaient pas là :
> http://www.youtube.com/watch?v=rBSAN1H1Fhg
>
>
> 2014-02-07 Rodenec Noel :
>
>> Une belle initiative.
>>
>> On Feb 7, 2014 8:31 AM, "similia joseph"  wrote:
>>
>> Quelle Geniale initiative!!! j'y serai!
>>
>>
>> Le 6 février 2014 06:23, Jojo Marseille  a écrit :
>>
>>
>> > He bien! Ouais, je veux faire partie du groupe.
>> >
>> >
>> > Le 5 février 2014 19:39, Severin MENARD > ___
>> Talk-ht mailing list
>> talk...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ht
>> Notez! Vous pouvez utiliser Google Translate (http://translate.google.com)
>> pour traduire les messages.
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [Talk-ht] NIght of the Living Maps

2014-02-07 Par sujet Severin MENARD
Je précise que l'initiative NOTLM n'est pas du tout de moi, mais nous y
avions participé avec l'équipe de Saint-Marc (qui est devenue par la suite
COSMHA-STM). Une vidéo pour ceux qui n'étaient pas là :
http://www.youtube.com/watch?v=rBSAN1H1Fhg


2014-02-07 Rodenec Noel :

> Une belle initiative.
>
> On Feb 7, 2014 8:31 AM, "similia joseph"  wrote:
>
> Quelle Geniale initiative!!! j'y serai!
>
>
> Le 6 février 2014 06:23, Jojo Marseille  a écrit :
>
>
> > He bien! Ouais, je veux faire partie du groupe.
> >
> >
> > Le 5 février 2014 19:39, Severin MENARD  ___
> Talk-ht mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ht
> Notez! Vous pouvez utiliser Google Translate (http://translate.google.com)
> pour traduire les messages.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Ista Pouss
Le 7 février 2014 16:20, Christian Quest  a écrit :

>
> Avoir quelques multipolygones (même 30 ou 40) me semble nettement plus
> facile à gérer tant pour l'édition que la réutilisation.
>
>
Il me semble que le problème de cette approche est que, comme la forme d'un
fleuve a un caractère fractal, elle se rallonge non seulement sur la
distance, mais encore sur le détail.

Pour s'en protéger, Il faudrait non seulement convenir d'une découpe sur la
distance comme tu le fais, mais aussi convenir d'une limite à la précision,
par exemple ne pas mapper les formes inférieures à 10m.

Surtout, pour découvrir les meilleurs compromis, il faudrait savoir comment
va évoluer l'organisation des données dans le schéma OSM. (si ça évolue ? )

Cordialement.



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


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Christian Quest
On a une limite à 2000 noeuds par way. C'est mieux que rien, mais pas
suffisant.

Beaucoup de formes naturelles sont fractales et l'autre limite que l'on
rencontre c'est celle de la résolution des sources.

Côté schéma OSM, la seule évolution dont on parle c'est la création de la
notion d'objets surfaciques, dont on pourrait éditer qu'un partie sans tout
charger. Mais on est loin d'avoir ça implémenté et il y a tout l'écosystème
d'éditeurs à mettre à niveau... pas simple.



Le 7 février 2014 18:18, Ista Pouss  a écrit :

> Le 7 février 2014 16:20, Christian Quest  a
> écrit :
>
>>
>> Avoir quelques multipolygones (même 30 ou 40) me semble nettement plus
>> facile à gérer tant pour l'édition que la réutilisation.
>>
>>
> Il me semble que le problème de cette approche est que, comme la forme
> d'un fleuve a un caractère fractal, elle se rallonge non seulement sur la
> distance, mais encore sur le détail.
>
> Pour s'en protéger, Il faudrait non seulement convenir d'une découpe sur
> la distance comme tu le fais, mais aussi convenir d'une limite à la
> précision, par exemple ne pas mapper les formes inférieures à 10m.
>
> Surtout, pour découvrir les meilleurs compromis, il faudrait savoir
> comment va évoluer l'organisation des données dans le schéma OSM. (si ça
> évolue ? )
>
> Cordialement.
>
>
> 
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet Ista Pouss
Le 7 février 2014 19:01, Christian Quest  a écrit :

>
> Côté schéma OSM, la seule évolution dont on parle c'est la création de la
> notion d'objets surfaciques, dont on pourrait éditer qu'un partie sans tout
> charger. Mais on est loin d'avoir ça implémenté et il y a tout l'écosystème
> d'éditeurs à mettre à niveau... pas simple.
>
>
Je comprends mieux quand tu rouspètes qu'il faut rester pragmatique, ne pas
aller trop dans les détails qui risqueraient de noyer les nouveaux
contributeurs etc ! L'organisation des données est vraiment le talon
d'achile du projet osm, je trouve.

Donc, oui, la seule solution est de découper la Loire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

2014-02-07 Par sujet djo_man

  
  
La méthode pour la relation riverbank
type=multipolygone + waterways=riverbank sur des ways fermé OUTER
qui se touchent avec des iles en INNER : 
vient du wiki.

lorsqu'il y a qu'une relation, elle est visible et modifiable. pas
moyen de se tromper.

avant il y  avait 2 voire 3 relations au même endroit. 
(certaines en reprenant juste le OUTER et ajoutant juste quelques
iles dont les autres relations n'avaient pas)
personne ne savaient pourquoi. 
laquelle modifier ?
personne ne prenant le temps de supprimer ce qu'il faut
plusieurs fois La Loire a inondé ses iles à cause de mauvaises
manipulation/ajout de relation, etc (3 fois en 2 ans: c'est plus que
d'hivers...)

je veux bien modifier ce qu'il faut mais pour aboutir à quoi au
juste ?
sans compter qu'il faut que le rendu rende... (sinon La Loire va
encore être inondé: ça le fait pas...)

djo_man




Le 07/02/2014 13:49, Pieren a écrit :


  2014-02-07 13:32 GMT+01:00 Ab_fab :


  
En effet, ça change tout. Désolé pour la confusion et le bruit !

  
  

  la relation est constituée de ways fermé OUTER et non pas de ways ouvert
OUTER. ça change tout.


  
  Au contraire, c'est pire ! Si ce sont des ways fermés qui se touchent.
Suivant les logiciels qui les traitent, le multipolygone pourrait être
considéré comme invalide:

http://postgis.refractions.net/docs/using_postgis_dbmanagement.html#OGC_Validity

Il n'y a pas trop de logique à assembler tous ces polygones en
conservant des ways fermés (si ce n'est, peut-être, à réduire le
nombre de ways et donc de membres de la relation). Si l'idée de départ
est de dire que c'est "une entité unique", ajouter des ways
(artificiels) qui traversent le fleuve à intervalle régulier ne
correspond à rien dans le monde réel. Autant aller jusqu'au bout de
votre logique et ne garder que les berges. Mais personnellement, je
préfère, et de loin, conserver les ways fermés et éventuellement
couplés à une relation multipolygon lorsqu'il y des ilots à
l'intérieur.

Pieren

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





  


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


[OSM-talk-fr] Service de carte statique

2014-02-07 Par sujet Guilhem Bonnefille
Bonsoir,

Il y a quelques temps déjà, j'avais pris l'habitude de mettre des cartes
statiques dans des pages web en utilisant les services proposés par
MapQuest. Je viens de découvrir, ce soir, que ces services sont maintenant
soumis à une clé.

Connaissez-vous un autre service en ligne de ce type ?
Surtout, un service capable de durer un peu dans le temps.

https://wiki.openstreetmap.org/wiki/Static_map_images
-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr