Aller "sur place" et vérifier les données va plus vite que taper un long message
Il y a deux îles en question, et chacune n'est constituée que d'un seul way (pas de multi-polygone) http://www.openstreetmap.org/browse/way/30689180 http://www.openstreetmap.org/browse/way/55015115 Cela tue déjà bcp d'hypothèses. Comme l'a dit Christophe, cela peut être une histoire de données de côtes longues au rafraîchissement. Et il y a l'histoire du sens du tracé (aiguilles d'une montre ou pas). C'est bon : la terre est côté gauche et la mer côté droit, si l'on chemine dans le sens du way Je dirais donc comme Christophe, dans ce cas Le 13 juillet 2012 17:07, Philippe Verdy <verd...@wanadoo.fr> a écrit : > On a eu le cas un peu différent sur les îles intérieures (au milieu > d'un fleuve) à Nantes sur la Loire. Malgré les corrections, elles sont > encore "inondées" (certaines mais pas toutes). Il semble y avoir des > confusions entre les tags, mais il y a un problème commun qui apparaît > parfois, lié à des conflits de versions et des superpositions de > lignes côtières multiples. > On doit vérifier qu'il n'y a bien qu'une seule ligne de côte, pas deux > (pas forcément identiques)... Cela arrrive quand certains ont anticipé > des suppressions de licences et modifié un ancien contour qui est > ensuite restauré par quelqu'un d'autre qui n'a pas vu le nouveau > tracé. > > Le chargement des objets par ID ne permet pas de voir les éléments en > doublon, il faut parfois charger une zone rectangulaire autour d'un > morceau de la côte et englobant une distance suffisante pour trouver > les traits en doublon. Et vérifier ensuite aussi les relations > administratives qui soit utilisent ces lignes de côtes (ce devrait > être le cas, mais ces lignes de côtes ne devraient pas avoir besoin > d'aucun d'attribut boundary=administrative, car en plus ces lignes ne > sont pas réellement les frontières administratives qui sont plus > éloignées). > > Attention aussi au sens du tracé des lignes de côtes : vériifer que > les segments forment bien un contour fermé en les triant pour les > interconnecter, et leur direction (contour dans le sens inverse des > aiguilles d'une montre, avec la terre à gauche et la mer à droite dans > la direction du tracé des segments). > > D'ailleurs le sens du tracé devrait être utilisé préférablement pour > tous les contours fermés. Ce n'est pas possible avec les frontières > administratives qui partagent les mêmes segments de frontières car on > a une surface intérieure aussi bien à droite qu'à gauche du tracé. > > Note: la droite et la gauche mentionnés dans les attributs ne sont pas > celles qu'on voit en regardant la carte orientée avec le Nord vers le > haut. Ce n'est pas par rapport à vous mais par rapport à quelqu'un qui > regarderait dans la direction du tracé: si le tracé "descend" vers le > Sud, le côté droit est à votre gauche en regardant la carte ! si le > tracé va vers l'est, vous voyez le côté droit du segment en dessous de > ce segment... Retenir le sens inverse des aiguilles d'une montre et > pour éviter de se tromper à l'avenir, il vaut mieux systématiquement > tracer dans cette orientation, même si pour certains objets ce n'est > pas nécessaire (cela allège aussi le travail des moteurs de rendu qui > tracent les surfaces ou les requêtes géométriques de recherche qui > passent moins de temps à trier les relations). C'est même valable pour > les tracés de rôle "inner" (qui délimitent un "trou" dans une surface > fermée en utilisant le contour fermé d'un AUTRE objet qui possède ses > PROPRES attributs distincts de celui de la relation qui utilise ce > rôle "inner"/"enclave"). > > Vérifier aussi qu'il n'y a pas de segments en double, et que les nœuds > supposés lier les chemins entre eux sont bien identiques et pas > seulement superposés à la même position. > > Le 13 juillet 2012 16:38, Christophe Merlet <red...@redfoxcenter.org> a > écrit : > > Le vendredi 13 juillet 2012 à 15:24 +0200, Jean-Claude Repetto a écrit : > >> Bonjour, > >> > >> A partir du niveau de zoom 13, cette île semble être inondée : > >> http://www.openstreetmap.org/?lat=-38.7398&lon=77.5645&zoom=12&layers=M > >> > >> Quelqu'un aurait-il une explication ? > > > > Si je ne me trompe pas, les lignes de côtes générées par Mapnik le sont > > depuis un fichier externe, lui même généré de temps en temps depuis > > OpenStreetMap. > > > > http://tile.openstreetmap.org/processed_p.tar.bz2 > > http://tile.openstreetmap.org/shoreline_300.tar.bz2 > > > > Il semble que ni la version du 31 mars, ni la dernière du 17 juin n'ai > > pris en compte ces îles. > > > > Un examen de l'historique des lignes de côtes montre que la balise > > natural = coastline n'a été mise que le 1er juillet. Idem pour l'île > > Amsterdam. Il faut donc attendre la prochaine mise à jour de ces > > fichiers puis la mise à jour des serveurs de tuiles pour que ces îles ne > > soit plus submergées... > > > > > > Librement, > > -- > > Christophe Merlet (RedFox) > > > > > > _______________________________________________ > > 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 > -- ab_fab <http://wiki.openstreetmap.org/wiki/User:Ab_fab> "Il n'y a pas de pas perdus"
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
