Le 31 janvier 2012 17:48, Vincent de Chateau-Thierry <v...@laposte.net> a écrit : > >> De : "Philippe Verdy" >> >> Entièrement d'accord. Y compris sur le "name" (et ses traductions) qui >> doit alors remplacer celui de la relation quand les deux sont >> présents. >> (...) >> >> Juste une idée "comme ça" : >> >> (...) >> >> Une règle supplémentaire devrait être que cet objet de "type=label" >> ... >> >> Un label objet de "type=label" ne devrait pas exister seul, sinon >> c'est qu'il doit être d'un autre type plus descriptif (dans ce cas on >> enlève son attribut "type=label" mais il faut indiquer le genre >> d'objet qu'il désigne, avec d'autres attributs géographiques). >> > > Avoir des lignes de placement pour du texte relève à 100 % du domaine de la > cartographie, > autrement dit de la représentation des données, le fameux "rendu". > OSM n'est pas une carte mais une base de données, a fortiori une base dont la > vocation > est bien plus large que la représentation cartographique. Ça serait à mon > sens une dérive > que de stocker ce type d'info dans la base, tout ça pour palier à une absence > de finesse > dans les algos de placement des moteurs de rendu. Sans parler de la > multiplicité des > lignes pour un même texte, tout ça pour anticiper les représentations à > différentes > échelles (on y revient toujours :-) ). > > En revanche, modéliser, peut-être avec le fuzzy souligné par Ab_fab, les > limites floues, > ça me paraît une vraie question pour la base de données. Aux moteurs de rendu > ensuite > de s'en emparer, chacun son boulot.
Dans ce cas, on ne labelle plus rien d'autre que les surfaces (qui par elles-même indiquent les tolérances de placement). Pourtant, les labels ont une direction préférée. Sans aucune indication dans la base, on ne peut que les centrer sur un point et pas les dimensionner du tout. L'idée des limites floues (fuzzy) est bonne: on continue à modéliser une surface, donc une géométrie, même avec un tracé imprécis et une résolution faible. Mentionner ces limites comme floues évite de les dessiner explicitement dans le moteur de rendu, mais suffit à indiquer la zone dans laquelle on suggère de placer le label (qui devrait "recouvrir" proportionellement toute cette zone, quitte à espacer les lettres et agrandir les polices utilisées). Mais comment indiquer sa direction, par exemple pour les massifs montagneux, les caps et pointes de terres, les presqu'îles, les baies maritimes (souvent contenant des "sous-baies" ; l'idéal serait d'indiquer la ligne centrale d'approche dans la baie), ou des désignations locales (culturelles mais non administratives) ? Sans aucune direction, tous nos labels sont horizontaux, rien ne les distingue vraiment, et un moteur ne sait pas du tout comment faire. Si on n'indique que la surface avec une limite floue, le contour fermé n'a plus de direction (le contour n'est pas nécessairement fortement convexe, il peut être même ramifié, comme les rivières, sans pour autant qu'on ait a désigner toutes les petites ramifications, ce qui justifie d'afficher alors plusieurs fois le label sur une carte, sur les ramifications principales) ; alors qu'un trait de placement (le "noyau" squelettique de la surface désignée par ce label) suffit à régler le problème, comme on le fait sur les rivières (en indiquant le cours central, en plus des rives; quand les rives sont représentables, le moteur les dessine et les remplit, mais ne dessine plus le trait du cours central, mais l'utilise pour positionner correctement le nom du cours d'eau, et aussi pour indiquer son sens d'écoulement d'amont en aval, bien qu'il suffirait seulement de mentionner le point source et celui d'embouchure ou de confluent). Il existe des algorithmes pour calculer le noyau squelettique d'une surface connexe définie par son contour polygonal (le noyau est un ensemble de courbes interconnectées, inclues totalement dans la surface ferlée par le contour), mais avec toutes les irrégularités des surfaces complexes (comme les côtes par exemple, mais aussi les rivières, on obtiendrait un squelette contenant de très nombreuses ramifications de longueurs très différentes et pas de réelle utilité à labelliser toutes ces irrégularités quand la ramification principale suffit largement, étant donnée le lettrage employé le long de cette ramification). Noter aussi que la délimitation entre un cours d'eau et son affluent est une limite floue alors que les rives ne le sont pas. En pratique ça veut dire créer un segment "flou" (à masquer, donc marqué comme "fuzzy") et l'inclure comme membre du multipolygone définissant les rives de chaque cours ou affluent. Comme alors chaque cours est entièrement défini par une courbe fermée, il est possible d'en calculer automatiquement un squelette (à condition de savoir éliminer les fausses ramifications créées simplement par des variations de largeur ou de petites criques), ce qui alors rendrait caduque l'indication du cours "central" avec les "main_stream" et "side_stream" (des lignes juste estimées à la main, "à vue de nez", sauf quand il s'agit d'une frontière administrative qui souvent a omis d'être modifiée alors que le cours d'eau s'est déplacé, raison de plus pour ne partager les contours administratifs avec aucun autre objet topographique...) . _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
