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
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 su
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, e
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)
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
tou
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
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 a
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
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 logiciel
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 dema
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=rive
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,
"
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é à
fa
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 conceptu
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 à ma
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
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 ex
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 fer
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=m
19 matches
Mail list logo
