Bonsoir,
Est ce que quelqu'un spécialiste des rivières (ou non) peut regarder
pourquoi les iles (correspondant à des écluses) sur le lien suivant ne
sont que de l'eau (il y en a plusieurs).
http://www.informationfreeway.org/?lat=47.845304583546934&lon=-0.19318154982545982&zoom=14&layers=BF000
On Wed, Feb 4, 2009 at 11:22 PM, Etienne Chové wrote:
> Bonsoir,
>
> Est ce que quelqu'un spécialiste des rivières (ou non) peut regarder
> pourquoi les iles (correspondant à des écluses) sur le lien suivant ne
> sont que de l'eau (il y en a plusieurs).
>
Salut Etienne,
amha, ça vient du fait qu
Pieren a écrit :
> On Wed, Feb 4, 2009 at 11:22 PM, Etienne Chové wrote:
>
>> Bonsoir,
>>
>> Est ce que quelqu'un spécialiste des rivières (ou non) peut regarder
>> pourquoi les iles (correspondant à des écluses) sur le lien suivant ne
>> sont que de l'eau (il y en a plusieurs).
>>
>>
>
>
Pieren a écrit :
> On Wed, Feb 4, 2009 at 11:22 PM, Etienne Chové wrote:
>> Bonsoir,
>>
>> Est ce que quelqu'un spécialiste des rivières (ou non) peut regarder
>> pourquoi les iles (correspondant à des écluses) sur le lien suivant ne
>> sont que de l'eau (il y en a plusieurs).
>>
>
> Salut Etienn
Attention aussi aux ways de plus de 2000 nodes. Cela passe encore, mais
ça ne fonctionnera plus dans l'API 0.6.
Voir le très fameux
http://tools.geofabrik.de/osmi/?view=geometry&lon=1.05951&lat=46.64748&zoom=7&overlays=long_ways
qui indique même les Ways de plus de 1000 nodes.
--
Marc
___
En ce qui nous concerne, pour la France, il serait intéressant de mettre en
place un robot qui sélectionne les ways trop longs et qui les découpe en
"sous-ways" de moins de 2000 noeuds.
2009/2/5 Marc SIBERT
> Attention aussi aux ways de plus de 2000 nodes. Cela passe encore, mais
> ça ne fonctio
Arnaud Duval a écrit :
> En ce qui nous concerne, pour la France, il serait intéressant de
> mettre en place un robot qui sélectionne les ways trop longs et qui
> les découpe en "sous-ways" de moins de 2000 noeuds.
> --
> Cordialement,
>
> Arnaud Duval
> Doctorant en mécanique du solide
> ESSTIN
Salut,
> J'ai peur que ça ne soit pas si simple que ça ! Exemple bête : l'Étang
> de Berre (http://www.openstreetmap.org/browse/way/28247877), un beau
> natural=water de 2490 nœuds. Je te laisse imaginer la cata si un bot
> découpe son contour en 4 morceaux. Vu le (faible) nombre de taches bleu
Pierre Mauduit a écrit :
> Salut,
>
>
>> J'ai peur que ça ne soit pas si simple que ça ! Exemple bête : l'Étang
>> de Berre (http://www.openstreetmap.org/browse/way/28247877), un beau
>> natural=water de 2490 nœuds. Je te laisse imaginer la cata si un bot
>> découpe son contour en 4 morceaux.
Salut,
étant auteur de ces - trop - longs ways (Berre en partie, Sainte-Croix,
Serre-Ponçon), je viens de jeter un zoeil sur le problème.
Je pensais de prime abord qu'il serait suffisant de segmenter les rives
plutôt que de reconstituer carrément des polygones individualisés comme
tu l'as fait
Bonjour,
Concernant 'simplify-way.max-error', il faut le rajouter manuellement
dans la config avancée ?
J'utilise utilsplugin, mais n'ai pas ce paramètre dans la liste.
Merci d'avance,
Antoine
krysst a écrit :
Salut,
étant auteur de ces - trop - longs ways (Berre en partie, Sainte-Croix,
S
Salut,
C'est tout à fait cela. Maintenant, j'avais retenu cette valeur de 1.0
après moult essais, il se peut que ce soit celle par défaut. La flemme
de tout re-tester a fait son oeuvre... :-D
Attention cependant à ne pas mettre une valeur trop basse : elle ne
permettra pas de lisser les erreur
Pieren a écrit :
> On Wed, Feb 4, 2009 at 11:22 PM, Etienne Chové wrote:
>> Bonsoir,
>>
>> Est ce que quelqu'un spécialiste des rivières (ou non) peut regarder
>> pourquoi les iles (correspondant à des écluses) sur le lien suivant ne
>> sont que de l'eau (il y en a plusieurs).
>>
>
> Salut Etienn
2009/2/7 Etienne Chové :
> J'en reviens à mon problème. J'ai fusionné les outer et mis plein de
> inner dans ma relation. Cela marche bien pour le moment car mon outer
> n'est pas encore trop long.
>
> Lorsque la rivière est longue, on ne peut pas avoir un unique outer,
> donc on est obligé de mett
Pieren a écrit :
> 2009/2/7 Etienne Chové :
>> J'en reviens à mon problème. J'ai fusionné les outer et mis plein de
>> inner dans ma relation. Cela marche bien pour le moment car mon outer
>> n'est pas encore trop long.
>>
>> Lorsque la rivière est longue, on ne peut pas avoir un unique outer,
>> d
2009/2/7 Etienne Chové :
> Donc rien n'informe que les différents multipolygon sont de la même
> rivière ?
>
> Etienne
>
Ben, ils sont contigüs et portent le même tag riverbank. Tu dois aussi
mettre le tag name= sur les polygones (mais il arrive que Mapnik mette
le label complètement à côté de la
Si quelqu'un comprend celui-là :
http://www.openstreetmap.org/note/125800#map=13/47.2736/-1.9258&layers=N
Le riverbank n'est pas rendu sur ce tronçon, alors que celui de l'ouest
l'est. La seule différence que je vois est que celui de l'ouest est dans
un multipolygone avec les mêmes tags sur le M
Est-ce que la superposition des riverbanks selon les deux modèles ne les
amène pas à s'annuler l'un et l'autre quand le moteur rendu fusionne le
tout ?
Le 2 mars 2014 13:47, JB a écrit :
> Si quelqu'un comprend celui-là :
> http://www.openstreetmap.org/note/125800#map=13/47.2736/-1.9258&layers=
bonjour,
Sans doute que prédemment il était outer dans la grande relation
mais vue que je suis en train de remettre les choses comme il faut
c'est à dire une relation par outer dés qu'il y a des iles
pas de relation quand il n'y pas d'iles
là je me rappelle qu'i
Ben là, je sèche.
Rien a voir avec la problèmatique des relations imbiquées.
(disparition des iles dont l'ile de nantes)
Ni celle sur la problèmatique d'une trop grosse relation. (modèles
et usage de la base)
- Le riverbank est des plus simples avec le bon tag et
Bon,
ça semble réglé (generation en cours des tuiles aux zooms
18-->15)
Mais je ne peux dire ce qui a vraiment marché
- modification de la géometrie ?
- suppression du name (je le remettrais plus tard ) ?
- reconnection des ways des waterway=river avec un noeud s
s.
Christian, est-ce voulu ?
-- George
> Date: Sun, 2 Mar 2014 21:30:12 +0100
> From: djo_...@laposte.net
> To: talk-fr@openstreetmap.org
> Subject: Re: [OSM-talk-fr] Riverbank - de retour
>
> Bon,
> ça semble réglé (generation en cours des tuiles aux zooms 18-->15)
&
le trait a disparu et le fleuve est bien rempli comme il faut. sans doute
un problème de cache image de ton navigateur ou éditeur.
pense à le purger (surtout celui de JOSM qui ne fait que grossir et ne se
purge jamais)
Le 2 mars 2014 19:35, djo_man a écrit :
> bonjour,
>
> Sans doute que préde
2014-03-02 21:30 GMT+01:00 djo_man :
> Bon,
> ça semble réglé (generation en cours des tuiles aux zooms 18-->15)
> Mais je ne peux dire ce qui a vraiment marché
> - modification de la géometrie ?
> - suppression du name (je le remettrais plus tard ) ?
> - reconnection des ways des waterway=river av
Pour l'ile de la Jatte... dans la base générée par osm2pgsql j'ai 2
polygones "waterway=riverbank":
- un pour le way 35475500 qui est "outer" dans la relation, donc plein
- un pour la relation multipolygone 152887 qui a aussi un waterway=riverbank
- le way 10426860 qui représente l'île n'a qu'un ta
2014-03-03 11:51 GMT+01:00 Christian Quest :
> Pour l'ile de la Jatte... dans la base générée par osm2pgsql j'ai 2
> polygones "waterway=riverbank":
> - un pour le way 35475500 qui est "outer" dans la relation, donc plein
> - un pour la relation multipolygone 152887 qui a aussi un waterway=riverban
2014-03-03 11:51 GMT+01:00 Christian Quest :
> En supprimant le layer=-1 tout est rentré dans l'ordre au niveau de la base
> de donnée et donc du rendu.
Ca ressemble à un bug dans osm2pqsql. Les règles de transformation ne
devraient pas changer en fonction du tag "layer". Ou alors, y a une
subtil
osm2pgsql procède en plusieurs étapes:
- il crée la géométrie du multipolygone
- il recopie les tags des membres si il n'y en a aucun de significatif sur
la relation (là il y en avait un: waterway=riverbank)
- il repasse en revue les membres pour décider de générer ou non une
géométrie séparée pour
2014-03-03 12:26 GMT+01:00 Christian Quest :
> La conclusion c'est quand même d'éviter d'avoir des tags identiques sur la
> relation et ses membres et de plutôt les reporter sur la relation, ça évite
> pas mal d'ambiguité pas toujours facile à gérer côté code.
Ou de ne mettre que le strict minimu
29 matches
Mail list logo
