[OSM-talk-fr] Chemin à modifier way:43904124

Philippe Verdy verdy_p at wanadoo.fr
Jeu 11 Juil 17:33:49 UTC 2013


Le 11 juillet 2013 18:25, CedricDV <cedricdumezviou at gmail.com> a écrit :

> Je suis l'auteur du script qui a réduit des multi-polygones géants en
> multi-polygones plus "petits".


C'est vrai que c'est un travail utile car ça permet de les manipuler plus
facilement (en particulier avec les éditeurs en ligne qui ne peuvent pas
charger autant de données sur une surface très étendue). quand ils sont
plus petits, c'est plus facile ensuite de les affiner localement sans tout
casser et laisser de gros trous.

> Le 11/07/2013 16:56, Vincent Calame a écrit :
> > Le 10/07/2013 16:58, JB a écrit :
> >>
> >> À quand un projet de mois de réduction des mégamultipolygones du CLC ?
> >>
> >>
> >
> > Est-ce qu'on ne pourrait pas carrément supprimer ceux avec l'attribut
> > landuse=farm. Certains sont gigantesques et n'apportent rien. Autant
> > colorier le fond de carte en rose.
> >
> > Je pense par exemple à celui-ci entre Châteauroux et Bourges :
> >
> >
> http://tile.openstreetmap.fr/?zoom=11&lat=46.89423&lon=1.93633&layers=B00000FFF
> >
> >
> > Cela donne des tronçons comme ceux-ci :
> >
> > http://www.openstreetmap.org/browse/way/62105291
> >
> > http://www.openstreetmap.org/browse/way/198911420
> >
> > Je pense que c'est ingérable.
>

C'est gérable à mon sens. Et cela donne encore une indication que ce n'est
pas occupé par autre chose (de la forêt, de la vigne, un étang ou une
carrière par exemple, ni par une agglomération).

Ne serait-ce que dans les statistiques d'occupation des sols, cela permet
de dresser des bilans de l'occupation et aussi de permettre certaines
comparaisons sur la densité relative des données : il est normal que dans
des zones de sols arables la densité soit faible (y compris le découpage
routier où on ne s'attend pas à beaucoup de routes primaires ni même
secondaires).

Normalement on devrait pouvoir obtenir une densité acceptable partout, tout
en évitant une profusion de polygones qui remplissent la carte de traits
artificiels : le redécoupage des gros polygones a du sens dès que leur
complexité devient trop importante ou que d'autres polygones doivent s'y
insérer (puisqu'il faut alors créer des multipolygones pour les "îles" à
exclure du grand polygone si on veut éviter des ambiguités d'nterprétation
et des anomalies de rendus avec des "îles" qui disparaissent sous une autre
surface. Autant que possible toutefois, ces redécoupages devraient
s'aligner le long de traits réels : rivières, routes, etc. Afin de
faciliter la lecture de la carte et son affinage progressif. Sinon la
moindre modif locale obligera à redécouper deux gros polygones ou plus, au
lieu d'un seul.

On peut automatiser certains découpages sur des zones d'étranglement, mais
si possible on devrait pouvoir le faire sans avoir à scinder les chemins
(sauf s'ils sont trop longs, simplement en utilisant les points triples
existants (ou alors en créant un point voisin pas trop éloigné mais pas à 2
centimètres non plus où on les confond), toujours dans le but de garder les
choses simples géométriquement, et facilement sélectionnables dans un
éditeur sans avoir toujours à basculer entre de trop nombreux niveaux de
zoom.

Idéalement tout polygone devrait être visible et sélectionnable en entier
dans un éditeur en ligne, sans qu'on soit noyé par les autres détails dans
la zone. Sinon il n'y a que sous JOSM qu'on s'en tire plus ou moins bien.

La question n'est donc pas tant le nombre des points dans un tracé que la
multiplicité des traits et des noeuds isolés pour les POIs (quand les POIs
sont des noeuds isolés, il faudrait qu'ils soient aussi séparés des traits
auxquels ils n'ont pas de relation directe.

Par exemple il est OK de poser un noeud d'adresse sur un mur de bâtiment ou
une clôture, mais pas sur la route ou sur le trait délimitant une zone
landuse=* ou natural=*, ou un fossé (qui plus est ce fossé en bordure de
route est normalement dans le domaine public et non dans la propriété
elle-même, le noeud adresse est alors mal posé, trop près de la route dont
on a tracé en fait l'axe central; pour associer un noeud d'adresse avec la
route la plus proche associée, on a les relations d'adresse et ça marche
bien).

Dans tous les cas, on devrait éviter d'avoir à chercher très loin les
éléments associés (c'est facile sous JOSM, mais pas sous iD ou Potlatch).
De plus en plus on va avoir besoin de contributions locales, et la
complexité et la densité des données soit être adaptative, tout en évitant
des superpositions de traits quand les limites entre deux zones contiguës
sont précises. Et il n'y a que pour les touts petits polygones (bâtiments)
qu'on n'est pas obligé de fusionner les traits superposés en créant des
multipolygones (cela ne bougera pas souvent de toute façon; mais pour
certaines modifs complexes on est parfois obligé de le faire si cela
simplifie les choses avec de trop nombreux polygones partageant un trait,
car il ne devrait jamais y en avoir plus de deux à la fois, un pour chaque
zone décrite à droite et à gauche du trait).

Attention aussi à la multiplication des traits quasi-parallèles (le plus
souvent leurs limites sont imprécises de toute façon, et certains de ces
polygones sont trop grands et incluent des choses qui ne devraient en être
exclues). Ces traits quasi parallèles rendent plus ambiguës les opérations
d'affinage ou de pose d'autres éléments, et créent des anomalies ensuite de
géométrie (tels que des routes supposées former un carrefour mais qui ne se
connectent pas en fait).

Cependant concernant les routes tracées par leur axe, je pense qu'il n'y a
pas de sens à créer des polygones landuse ou natural superposés à leur
tracé : ces polygones peuvent traverser la route, mais sinon ils devraient
la longer, pas trop près pour coller mieux à la limite des terrains hors
fossés et bas-côté, où on voudra poser des éléments comme les luminaire,
panneaux, radars, parcmètres, etc sans avoir à les mettre dans les terrains
voisins (cela n'a pas de sens). Noter que les vieux parcmètres
disparaissent de plus en plus aussi, remplacés par des bornes à ticket qui
gênent moins les piétons et moins compliqués à relever, moins chères à
entretenir, plus sécurisées (et permettant aussi le paiement par carte).

A terme les routes pourront avoir aussi une description surfacique, en
ville comme en campagne (même si on gardera un tracé filaire, comme pour
les rivières), afin de mieux cartographier les ilots directionnels, les
trottoirs, voire des groupes de voies (cela ne servira pas tant à la
navigation car les surfaces n'ont pas d'orientation, que pour entrer dans
les détails de structure et d'équipements, ou pour mieux marquer les
parkings latéraux jusqu'à chaque place de stationnement ou chaque arbre,
butoir, bac à fleur, glissière de sécurité, feux et panneaux, poubelles,
plaque et regards d'égouts les anciennes bornes en pierre ou béton ayant
disparu presque partout de nos routes, remplacées par des panonceaux moins
dangereux...). Cette description surfacique donnera aussi des statistiques
d'occupation des sols par la voirie le stationnement ou d'autres
utilisations comme les terrasses commerciales et emplacements de marchés,
ou les marquages en relief pour aveugles.
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20130711/891cbac3/attachment.htm>


Plus d'informations sur la liste de diffusion Talk-fr