Re: [OSM-talk-fr] Cadastre et riverbank
Donc je vais continuer à supprimer les riverbank pour les stream (uniquement quand il s'agit d'un import "brut" du cadastre, lorsqu'un autre contributeur a tracé le filaire central en jugeant pertinent de laisser le riverbank, je ne touche pas) Je les supprime car * Je n'en vois pas l’intérêt quand la largeur est très faible * Les riverbank issu du cadastre sont souvent irréalistes (si je ne me trompe pas, le cadastre ne décrit pas l'hydrographie, mais délimite des parcelle de propriété, ce qui est parfois assez différent) Autre question: est-ce qu'un filaire doit traverser les lacs ? osmose signale systématiquement des erreurs à ce sujet. Et comment utiliser le tag waterway=ditch ? D'après la description : "Utiliser waterway=ditch pour les fossés, simples cours d'eau ( FR:waterways) artificiels et étroits" C'est pourquoi je ne l'utilise qu’exceptionnellement en montagne ou les fossés artificiels sont très rares. J'ai constaté que d'autre contributeurs l'utilise lorsque même un stream est un peu gros. Il me semble effectivement que la seule distinction river/stream est insuffisante, mais en l’absence de tag inférieur au stream pour un cours d'eau naturel, je m'en tient à celui-ci. Balaitous Le mercredi 03 juin 2015 à 15:14 +0200, Jérôme Seigneuret a écrit : > En effet dans mon cas j'ai laissé car c'était du warterway=river. Je > laisse les riverbank quand ils sont permanents et je mets river quand > c'est plus large qu' 1m. > > > Le choix entre steam et river et des fois un peut limite... Mais > j'aimerai bien savoir comment vous déterminez votre choix. > > > Genre quand la rivière ou fleuve fait plus d'un mettre mais n'est pas > permanent... car warterway=river semble ne pas accepté l'intermittence > > > > > > Le 3 juin 2015 10:29, JB a écrit : > Hé non, les riverbank ne sont pas toujours à conserver, > notamment le long des ruisseaux et des fossés, quand ils ont > été malencontreusement importés depuis le cadastre. Là, par > exemple : > http://www.openstreetmap.org/#map=19/44.90275/4.35458 . Pour > nettoyer, il faudrait effectivement supprimer les riverbanks, > tracer le filaire central (en stream, voire en ditch, > parfois). Après, dans certains cas, le riverbank peut être > pertinent, mais je ne me risquerais pas à donner une largeur > limite, on risquerait des discussions sans fin… > JB. > > > Le 03/06/2015 09:04, Jérôme Seigneuret a écrit : > > > Salut, > > Les riverbank sont à conserver pour les cours d'eau! il faut > > ajouter un filaire par dessus en son centre pour y mettre le > > nom du cours d'eau et autre. Je viens de retoucher une > > partie vers argelès sur mer. Reste à refaire la relation > > pour le cours d'eau "La Riberette". J'ai utiliser la BD > > Carthage mais le cours d'au à un nom différent suivant la > > portion parcouru d'apèrs Wikipédia... A voir donc pour les > > locaux. > > > > Le 3 juin 2015 00:44, Balaitous a > > écrit : > > Bonjour, > > > > J'essaye de corriger les imports de riverbank du > > cadastre. > > > > Pour les petits cours d'eau (j'interviens > > essentiellement sur les > > Pyrénées ariégeoises), j'ai tendance à supprimer le > > riverbank du > > cadastre. J'ai constaté que d'autres contributeurs > > laissent le riverbank > > et ajoutent un warterway=stream au milieu. > > > > Y a t-il des recommandations à ce sujet ? > > > > Balaitous > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > > > > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Cadastre et riverbank
Bonjour, J'essaye de corriger les imports de riverbank du cadastre. Pour les petits cours d'eau (j'interviens essentiellement sur les Pyrénées ariégeoises), j'ai tendance à supprimer le riverbank du cadastre. J'ai constaté que d'autres contributeurs laissent le riverbank et ajoutent un warterway=stream au milieu. Y a t-il des recommandations à ce sujet ? Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpage des futures régions...
Effectivement, je suis un peu septique sur cette réaction face à l'actualité. Mais après tout, beaucoup de journaux ont récemment publié les propositions antérieures (Baladur, ...) alors pourquoi pas dans OSM. Mais par contre, cela doit être fait proprement, avec toutes les métadonnées nécessaires pour que dans 10 ans on puisse identifier clairement qu'il s'agit de la proposition de Hollande du 2 juin 2014. Autre proposition admin_level:proposed=4 source=Hollande, 2014-06-02 ou (plus générique) admin_level:proposed=4 date=2014-06-02 author=Hollande puis pour les anciennes régions (en cas de réforme!) admin_level:old=4 date:begin=à vérifier date:end=2015-??? Comment sont aujourd'hui gérées les fusions de communes ? et plus généralement toutes les données historiques (anciennes voies ferrées, ...) ? Il faut un système de datation homogène. Balaitous Le mardi 03 juin 2014 à 22:25 +0200, Christian Quest a écrit : > Si tu veux conserver toutes les versions successives ;) > > > Je pense qu'on peut n'en conserver qu'une, c'est déjà pas mal > > > Le 3 juin 2014 20:19, Balaitous a écrit : > Bonjour, > > Ne vaudrait-il pas mieux un tag > > admin_level:proposed:2014=4 > > voir : > > admin_level:proposed:2014:06=4 > > ou > > admin_level:proposed:2014-06-02=4 (date au format iso 8601) > > Car Il est fort probable que cette carte ne soit que > temporaire ! > > Balaitous > > > Le mardi 03 juin 2014 à 00:46 +0200, Christian Quest a écrit : > > J'ai créé les relations avec les limites. > > J'espère n'avoir rien oublié. > > > > > > Ca simplifie au moins quelques enclaves ;) > > > > > > Pour ne pas mélanger avec les régions actuelles, j'ai opté > pour: > > - type=boundary > > - boundary=administrative > > - admin_level:proposed=4 > > > > > > Si vous voyez mieux n'hésitez pas à proposer ! > > > > > > J'ai aussi fait un petit tableau dans le > > wiki: > > http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives#Futures_r.C3.A9gions_telles_qu.27annonc.C3.A9es_le_2_juin_2014 > > > > > > -- > > Christian Quest - OpenStreetMap France > > > ___ > > Talk-fr mailing list > > Talk-fr@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > > -- > Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpage des futures régions...
Bonjour, Ne vaudrait-il pas mieux un tag admin_level:proposed:2014=4 voir : admin_level:proposed:2014:06=4 ou admin_level:proposed:2014-06-02=4 (date au format iso 8601) Car Il est fort probable que cette carte ne soit que temporaire ! Balaitous Le mardi 03 juin 2014 à 00:46 +0200, Christian Quest a écrit : > J'ai créé les relations avec les limites. > J'espère n'avoir rien oublié. > > > Ca simplifie au moins quelques enclaves ;) > > > Pour ne pas mélanger avec les régions actuelles, j'ai opté pour: > - type=boundary > - boundary=administrative > - admin_level:proposed=4 > > > Si vous voyez mieux n'hésitez pas à proposer ! > > > J'ai aussi fait un petit tableau dans le > wiki: > http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives#Futures_r.C3.A9gions_telles_qu.27annonc.C3.A9es_le_2_juin_2014 > > > -- > Christian Quest - OpenStreetMap France > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartographie d'un sommet double
Le lundi 07 octobre 2013 à 21:40 +0200, orhygine a écrit : > En regardant un peu les données on constate que le point actuellement > tagué Pic de Rulhe est l'intersection entre les limites communales de > Mérens, Savignac et Aston. Le Rulhe doit-être considéré comme la > limite entre ces 3 communes. C'est une modif que j'ai effectuée dimanche (avant le point était séparé) après vérification de la limite communale sur le cadastre. Mais le cadastre prend-il en considération le sommet le plus élevé, ou bien un sommet "moyen" ? > Si on superpose les données cadastrales, on peut voir que les limites > communales actuellement cartographiées dans OSM divergent du cadastre, > notamment la limite qui part en direction du nord depuis le Rulhe > (frontière entre Aston et Savignac). Je ne sais pas quelle peut-être > la précision du cadastre dans ces zones très accidentées et donc s'il > peut-être justifié de recaler les limites communales...? Dans ces zones de montagnes, la géolocalisation du cadastre est souvent approximative (constations personnelle sur d'autre zones frontalières avec l'espagne). Pour ma part j'accorde plus d'importance aux données textuelles telle que la limite passant par tel ou tel pic. > Toujours est-il que, concernant les deux sommets du Rulhe, s'ils sont > distants de 50 m et séparés par un collet, il me semble pertinent de > les cartographier, surtout si l'on dispose de relevés GPS. Ce sera > plus représentatif de la réalité du terrain que actuellement. Il > faudra alors ajouter un tag source=survey sur les points ou le > changeset et supprimer les tags sur le point actuellement tagué Pic de > Rulhe. Finalement, je viens de placer le pic de Rulhe sur le plus élevé, et j'ai mis un sommet non nommé sur l'autre. > Le 6 octobre 2013 16:06, Balaitous a écrit : > Bonjour, > > Le pic de Rulhe est comporte 2 sommets principaux, distants > d'une petite > cinquantaine de mètres. > > Le point actuellement présent dans OSM correspond au col > séparant les 2 > sommets. > > Comment faire pour le cartographier correctement (i.e. > indiquer la > position des deux sommets) ? > > J'ai ajouté les voies d'accès aux deux sommets. L'extrémité > des sentiers > correspond aux deux sommets. > > Voir http://www.openstreetmap.org/#map=18/42.62709/1.73941 > > D'après mon relevé GPS, le sommet ouest a pour altitude 2780m, > le sommet > est à 2782m. > http://ubuntuone.com/4t1GVDs5v8faveLOlK8lEL > > Balaitous > > > > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > > > > -- > Christophe aka orhygine | http://orhyginal.free.fr | ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Cartographie d'un sommet double
Bonjour, Le pic de Rulhe est comporte 2 sommets principaux, distants d'une petite cinquantaine de mètres. Le point actuellement présent dans OSM correspond au col séparant les 2 sommets. Comment faire pour le cartographier correctement (i.e. indiquer la position des deux sommets) ? J'ai ajouté les voies d'accès aux deux sommets. L'extrémité des sentiers correspond aux deux sommets. Voir http://www.openstreetmap.org/#map=18/42.62709/1.73941 D'après mon relevé GPS, le sommet ouest a pour altitude 2780m, le sommet est à 2782m. http://ubuntuone.com/4t1GVDs5v8faveLOlK8lEL Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Bonjour, > > Pour le chemin de Compostelle, j'admets que je n'ai pas suivi la procedure. Pour moi le GR et le Chemin de Compostelle sont deux routes distinctes qui utilisent les memes ways. Ils ont des osmc:symbole differentes. C'est pourquoi je l'ai dédoublé. Dois-je revenir en arriere? > > > méfiez vous quand même du chemin appelé "chemin de Compostelle", c'est au mieux une invention moderne ou plus certainement une invention contemporaine de la FFRP (voir ce site : http://www.saint-jacques.info où la genèse du tracé semble pas trop mal expliquée). > Du chemin médiéval on ne sait qu'une chose, il allait de ville en ville, on comprend mal d'ailleurs pourquoi les pèlerins les auraient évitées. Le chemin "ancien" doit donc plutôt passer par les actuelles nationales ou départementales, là ou il y a des autos ;-). Sauf, peut-être, des portions en montagne, et encore, les cols utilisables ne sont pas si nombreux. Je doute fort que l'on puisse parler du chemin de Saint-Jacques de Compostelle. En fait les chemins devaient être multiples. Au niveau des Pyrénées, de nombreux cols étaient utilisés. Ce site en retrace 3 : http://vppyr.free.fr/pages_transversales/voies_lavedan/voies_lavedan.php?etp=presentation Par contre concernant les Pyrénées, la plupart des routes actuelles n'ont pas détruit les chemins ancestraux, car les tracés anciens présentent biens souvent des pentes incompatibles avec la motorisation. C'est pourquoi les routes actuelles ont été tracé à côté, plutôt que par élargissement des anciens chemins. Sinon je salue l'effort fait pour transférer les références GR vers des relations. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Premier pas
Je ne voie pas de raison à la duplication des deux noeuds http://www.openstreetmap.org/browse/node/31376615 http://www.openstreetmap.org/browse/node/1379311022 Ils sont même contradictoires puisque l'un indique: place = city place = town Selon le tag population = 53373 et le wiki http://wiki.openstreetmap.org/wiki/FR:Key:place C'est place=town qui est correct. Donc je pense qu'il faut les fusionner avec place=town Dans l'historique, l'un date de 2007, l'autre de 2011. Il s'agit donc d'un doublon créé par méconnaissance. En revanche le polygon : http://www.openstreetmap.org/browse/way/5738808 a pour but de délimiter l'aire urbanisée grace au tag landuse=residential http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential Mais il n'y a aucune utilité à mettre le nom de la ville sur cet objet Le mercredi 27 février 2013 à 21:53 +0100, Jean-Christophe Groult a écrit : > Bonjour, > > Suite à une présentation de Francescu (que je salue au passage :) le > week-end dernier, je me suis décidé à faire mes premières > modifications (que je croyais) simples : ajouter des traductions de > noms. Et très vite je suis tombé sur un cas que je ne sais pas > résoudre. > > Il s'agit de la ville grecque de Χανιά en Crète, la Canée en français. > > D’une part il y a 3 objets qui correspondent à cette ville : > http://www.openstreetmap.org/browse/node/31376615 > http://www.openstreetmap.org/browse/node/1379311022 > http://www.openstreetmap.org/browse/way/5738808 > > Est-ce normal ? Si oui, faut-il fournir la traduction dans les 3 > objets (redondance de donnée) ? > Sinon faut-il fusionner ces objets ? Existe-t-il un outil pour ça ou > faut-il simplement copier les attributs et supprimer les 2 autres > objets ? Faut-il prendre des précautions particulières avant de > supprimer un objet ? > Je pensais garder le polygone (plus précis) > > D’autre part, la Canée porte aussi d’autres noms en français : Chaniá > et Haniá > J’ai vu le tag alt_name mais à priori c’est pour les noms locaux. > Est-ce qu’il possible d’ajouter le code langue comme avec name > (alt_name:fr=) ? > De plus il y a 2 noms; dans ce cas quel est le séparateur ? la > virgule, le point-virgule ? > > Cela donne ça : alt_name:fr=Chaniá;Haniá > C’est bon ? > > Merci d’avance pour votre aide, > LeBret > ___ > 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
Re: [OSM-talk-fr] Proposition for a classification of path
Le mardi 26 février 2013 à 11:45 +0100, Philippe Verdy a écrit : > Tu as marqué en fin de page pour la compatibilité ascendante d'anciens tags: > > - as grade4 if trail_visibility=bad/horrible/no > > j'aurais plutôt vu: > > - as grade4 if trail_visibility=bad/horrible > - as grade5 if trail_visibility=no > > qui correspond mieux à la description proposée. Et ce n'ai certainement pas ma meilleure idée. Initialement j'avais pensé à - as grade3 if no pathtype tag exist => en l’absence de classification on prend le "milieu" (contrairement à tracktype, où en l’absence de classification on prend le meilleur!) J'ai ensuite voulu faire une petite différence, mais aller jusqu'à proposer trail_visibility=no <=> grade5, signifiait que les 2 tags sont synonymes. Or le sens de ma proposition est bien d'introduire un jugement global et multicritère de l'importance d'un chemin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition for a classification of path
> Et j'apprécie la zone que tu as pris en exemple ;o) Je ne l'ai pas totalement choisie au hasard, voir ce nœud : http://www.openstreetmap.org/browse/node/494395635 Dont voici une photo: http://ubuntuone.com/2Iw2YrP3ix0kEBJl123NUz Je ne sais pas si tu apprécies la zone parce que tu la connais, mais si ce n'est pas le cas je t'encourage vivement à aller y faire un petit tour, c'est magnifique. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Proposition for a classification of path
Hi, I have wrote a proposition of classification for path. You can see it at : http://wiki.openstreetmap.org/wiki/Proposed_features/pathtype Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
> Il est vrai qu'il ne fait pas que supprimer les GR, et sur ce changeset, > j'ai du mal à comprendre la logique et l'utilité. > http://www.openstreetmap.org/browse/changeset/15162876 Le GR 78 est scindé dans 3 relations. Il en a regroupé 2 dans une nouvelle relation dans laquelle il a transféré la ref GR. Le problème c'est qu'il n'a pas vu l’existence d'une relation (1112208) qui regroupait déjà les différentes partie du GR. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Bonjour, Je viens de regarder un des modification en question, je n'ai nullement l'impression qu'il s'agisse de vandalisme. Par exemple pour la modif : http://www.openstreetmap.org/browse/changeset/15162766 Ce chemin est utilisé par 2 GR, il a supprimé la référence au GR dans le way pour créer 2 relations. J'ai l'impression qu'il en va de même pour ces autres modif, ce qui constitue donc une amélioration, les GR empruntant des routes pourtant d'autres références administratives. Balaitous Le lundi 25 février 2013 à 19:10 +0100, Tetsuo Shima a écrit : > Un contributeur s'est lâché en liquidant toutes les relation GR > http://www.openstreetmap.org/user/cantece > > Problème réglé :lol: ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM, oui, mais il faut autre chose
Je viens d'inscrire cette proposition sur le wiki : http://wiki.openstreetmap.org/wiki/Proposed_features/pathtype n'hésite pas à la modifier. ps. Comment faire pour en assurer la visibilité ? > Je ne comprends pas ? L'échelle peut avoir un caractère mondial, il > n'empêche qu'il est mieux que celle qui est utilisée soit donnée. Et > bien sûr que cette échelle doit faire l'objet de documentation > précise. Ce que je veux dire, c'est que l'échelle doit apparaitre dans la doc (cf le wiki), pas à chaque utilisation du tag. Le but est d'obtenir quelque chose de largement emplyé (cf les 44% du tag tracktype) > Mais point d'intérêt ne signifie pas automatiquement intérêt > touristique. > Dans des régions du monde où le déplacement pédestre reste > important > pour les activités quotidiennes, cela peut s'appliquer encore. > La notion de point d'intérêt est alors davantage liée au point > de > peuplement, au centre d'activité. > > > > Je me doute. (mais il me semble que la notion de "point d'intérêt" > vient du monde touristique, car ils trouvent que c'est mieux que > "node"). Je n'ai jamais regardé la définition officielle de POI, mais il me semble qu'elle s'emploie aussi pour un dentiste, pourtant je n'y vais jamais pour raison touristique. > > Le tout c'est de trouver une formulation qui soit déconnectée > de la > notion de tourisme, mais c'est cela que j'ai voulu faire en > mettant en > avant avec le terme culturel. > > > Le terme "culturel" m'a aussi trompé. Et je n'ai jamais vu des > colporteurs transporter à pied du bois pour des raisons culturelles > que ce soit au Pérou ou ailleurs (mais il est vrai que je ne suis > jamais allé au Pérou). Moi non plus, pour voir ces colporteurs, il aurait fallut naître bien avant la révolution industrielle. Mais ils ont portant bel et bien existé. C'est surtout pour mettre en évidence que les usages changes. > Et l'association "chemin en bon état / grosse fréquentation" est > encore une caractéristique du milieu touristique, sauf évidemment > quelques "aventures" - bien réchauffées de toutes façons. > > Il y a une version occidentale du chemin en mauvais état / grosse > fréquentation avec le RER A, par exemple. Et je ne suis pas sûr que > les passagers y soient pour des raisons culturelles. Mais c'est pas un > chemin, c'est vrai. Pour le RER je m'abstiendrais de commentaire sur ce que je ne connais pas. Pour les chemins, en revanche, il me semble qu'il y a une forte corrélation entre entretient et fréquentation. * la fréquentation, de part le piétinement régulier, constitue à elle seule un entretient * les chemins liées à l'activité quotidienne sont généralement bien entretenus, ne serait-ce que parce que cela facilite cette activité. Dans les Pyrénées, les innombrables chemins ancestraux, vitaux pour l'activité, était parfaitement entretenus (murets, ...), la preuve c'est qu'il existent encore malgré 50 ans de non entretient. Et dans les montagne au Pérou, il m'a semblé voir ce que les Pyrénées pouvait être il y a 50 ans. * Quand les chemins sont entretenus pour le tourisme, cela appelle la fréquentation. > Bref, moi je veux bien rechercher des trucs valides pour le monde > entier et toute forme culturelle, mais je dis que c'est illusoire. > Même si l'on valorise séparément fréquentation, balisage, et état, on > va se heurter à des variabilitées culturelles, particulièrement pour > la notion de balisage : un même chemin, bien balisé pour un > travailleur, ne le sera pas du tout pour un touriste, etc. Je ne cherche pas d'universalité, mais une classification unique qui permette pour chaque zone géographique de hiérarchiser les chemins en fonction de leur importance selon leur utilisation locale. Il me semble que c'est déjà le cas pour les autres type de highway, sans être vraiment écrit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM, oui, mais il faut autre chose
> Moi je trouve ça bien, à condition d'identifier et documenter > l'échelle utilisée, et de la spécifier dans les tags. Il n'existe > aucune espèce de sorte d'échelle universelle internationale > mondialisée pour les chemins. > > > Par exemple : > hikingtype=Grade2,Balatous Scale > Je pense qu'il vaut mieux mettre les deux infos - le type d'échelle et > la valeur, dans le même tag, car les deux infos sont complètement > liées. C'est comme de dire 2 mètres, par exemple. On dit pas 2 quelque > part, puis mètres ailleurs. C'est le meilleur moyen de créer un truc inutilisable et inutilisé. Comme pour les autres tag, il doit faire l’objet d'une définition dans le wiki, à la fois précise, mais suffisamment souple pour s'adapter à des particularité locales. C'est déjà largement la pratique, si le réseaux routier du Pérou était taggué selon les même critères qu'ici, il n'y aurait que 3 routes, puis que des pistes ! > > Ici la seule réserve que je ferais et d'associer la notion de type (de > hikingtype) à des grades. Un type appelle un nom, mais un grade > appelle une valeur. (si vous ne me comprenez pas, je recommencerai > dans un autre mail). Il s'agit simplement d'une analogie avec tracktype= > Si je reprends ton échelle avec l'idée "c'est une graduation", j'ai > l'impression que tu as surtout retenu la facilité touristique comme > type avec 1 = très facile et très sûr, 5 = merdique au possible, tout > ça pour les touristes, avec, à chaque étape, une description précise > de ce qui le caractérise. Dans les pays "développés" les déplacements pédestres à la campagne sont essentiellement liés au tourisme (qui fait encore 5 km à pied pour aller à l'école ? et qui a vu des colporteurs transporter du bois au port de Saleix à 1794 m ?), et l'aspect culturel est très lié au tourisme. Mais point d'intérêt ne signifie pas automatiquement intérêt touristique. Dans des régions du monde où le déplacement pédestre reste important pour les activités quotidiennes, cela peut s'appliquer encore. La notion de point d'intérêt est alors davantage liée au point de peuplement, au centre d'activité. Par exemple un chemin entre deux villages (se qui va généralement de pair avec un bon entretient) sera grade1. Un chemin permettant l’accès à quelques fermes isolées, ou à des zones de pâturage sera plutôt grade2. Les chemins formant un réseau dense d’accès aux différents champs sont plutôt 3 où 4. Le tout c'est de trouver une formulation qui soit déconnectée de la notion de tourisme, mais c'est cela que j'ai voulu faire en mettant en avant avec le terme culturel. La pratique culturelle des déplacement pédestres est variable selon les endroits, et j'ai essayé de tenir compte dans les définitions de deux expériences personnelle, la randonnée dans les pyrénéens, et le Pérou. Là bas un chemin permettant l'accès à un site archéologique isolé sera moins bien classé qu'un chemin entre 2 villages, alors qu'en france les chemins entre villages sont pour beaucoup en voie d'abandon. > Si maintenant j'essaie de typer chaque niveau, du 1 au 5, j'aurais > VeryGoodAndMagnificalTripWithNoEffort, PrettyMarvelousButLittleCommon, > FamilialAventureStuff, ForJunkiesOnly, SportifsHasards. C'est effectivement un résumé possible d'une telle échelle pour la France où la pratique culturelle des déplacements pédestres est essentiellement orienté tourisme. Par contre je supprimerai WithNoEffort. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM, oui, mais il faut autre chose
> N oubliez pas qu il existe deja un tag pour la visibilite : > trail_visibility ( http://wiki.openstreetmap.org/wiki/Hiking ) Ce tag ne prend en compte qu'un aspect pour quantifier l'importance d'un chemin. On peut en effet quantifier l'importance d'un chemin par un ensemble de tag précis sur différents critères, mais dans ce cas on abouti à un système peu utilisé. le tag trail_visibility est utilisé dans 4.61% des cas de highway=path. http://taginfo.openstreetmap.org/tags/highway=path#combinations En comparaison tracktype est utilisé dans 44.43% des cas highway=track. http://taginfo.openstreetmap.org/tags/highway=track#combinations Il n'y a pour moi pas d'incompatibilité entre une classification unique, laissant une part importante à la subjectivité, et la présence d'autres critères mesurables. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM, oui, mais il faut autre chose
> J'ai quelques avis sur la question mais je ne fait pas de rando de > façon convaincante et je serait hors sujet. Par contre si cette > création de Tag est envisageable il ne faudrait pas que ce ne soit pas > un moyen détourné pour tracer les circuits GR mais que cela vienne > d'un réel besoin sur le terrain pas sous de faux prétexte. Même si je fais cette proposition à l'occasion du débat sur les GR, il ne s'agit pas de les réintroduire par une voie détournée. L'idée vient de ma pratique de la randonnée, et le principe de hiérarchisation de l'information est courant en SIG, il existe dans OSM pour les route et les "track", pas pour les sentiers. Quand je pars en rando, assez souvent je me fixe un objectif (lac, pic, ...), puis je prend une carte pour voir comment y aller. Dans OSM, toutes les variantes pour se rendre d'un point A à un point B sont cartographiées de la même manière, et il est difficile de s'y retrouver (sauf si la région est peu cartographiée, auquel cas les rares sentiers sont souvent les principaux !) Voila ce que je propose, un tag hikingtype=* (par analogie avec tracktype=*). hikingtype et non pathtype car ce tag aurait vocation à être utilisé prioritairement sur les path, mais également sur les track et autre way présentant un usage pédestre avéré. Les critères de classification serait culturels, de fréquentation, de visibilité et d’entretien. La difficulté de parcours reste décrite par sac_scale. grade1 : Chemin culturellement important, d'usage courant, présentant un tracé clairement établie et régulièrement entretenu. Ce chemin est suffisamment long pour se déplacer entre 2 points d'intérêts majeurs, ou représente un tronçon d'un tel chemin. Ne représente au maximum que 10 à 15% des chemins d'une zone géographique (en tenant compte des chemins non encore tracés). grade2 : Chemin important, d'usage fréquent, son tracé reste clairement établi, et son entretient satisfaisant. Ce chemin relie (ou fait parti d'un itinéraire) entre deux points d'intérêt proche grade3 : Chemin d'importance moindre, son tracé reste clairement établie, mais n'est pas toujours indiqué par un marquage particulier, son entretien plus irrégulier peu laisser des obstacles ponctuels. Il peut s'agir de variantes pour les grade 1 et 2. grade4 : Chemin d'importance mineure, de faible fréquentation, il relie toujours 2 points d'intérêt, mais se distingue du grade 3 soit par un manque d'entretien pouvant obliger de s'en écarter, soit par une faible visibilité. Il peut s'agir de variantes pour les grade 1 ou 2, ou de chemins ancestraux en voie d'abandon. grade5 : Chemin très peu utilisé, dont le tracé n'est pas toujours clairement identifiable, éventuellement interrompue par endroit. L'entretient est quasi inexistant, et la progression sur ce chemin est ralentie par la présence d'obstacle ou de végétation. Ce chemin peut se terminer en cul de sac Cette classification n'a pas vocation à être automatique pour les GR, mais de par l'importance culturelle des GR dans la pratique de la randonnée les GR serait le plus souvent en 1, mais également 2 voir 3. Les PR serait majoritairement dans la catégorie 2 : cette catégorie vise les itinéraires en cul de sac à destination d'un point d'intérêt particulier (lac, pic, ...) Pour le grade4, je ne peux m’empêcher de penser à certains chemins d'origine pastorale rencontrés en espagne, dont le tracé fait par les vaches est loin d'être clairement identifiable. Par contre un itinéraire sans marque continue au sol, mais repérable par des kerns de loin en loin est un tracé clairement établi. Le rendu associé devrait montrer une visibilité décroissante entre les grade 1 et 5. Le grade 1 pourrait même être affiché à des niveaux de zoom auxquels les chemins ne sont pas visible aujourd'hui. Cette classification est à adapter localement de manière à ce que sur une zone géographique donnée chaque grade s'approche de 20% du total des chemins (en incluant les chemins non encore présents dans OSM). A discuter, mais je suis convaincu qu'il y a actuellement un manque dans OSM Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Je souscris totalement au mail précédent. Depuis que j'ai découvert cette affaire au mois de juillet je me demande si en réalité nous ne sommes pas en train de créer un problème de toute pièce. Je persiste à penser que tant qu'aucune demande de retrait des itinéraires concernés n'aura été formulée par la FFRP, il n'y a aucune raison de les retirer. L'analogie avec la précédente condamnation d'un éditeur, principal argument en faveur de la suppression, ne me parait pas pertinente, étant donné que dans le cas d'OSM les GR sont un élément de cartographie comme un autre, reposant sur des traces visibles dans l'espace publique, pas un but. Pour mieux comprendre cette affaire, quelqu'un pourrait-il faire un récapitulatif des démarches entreprises auprès de la FFRP ? Balaitous Le vendredi 22 février 2013 à 11:27 +0100, Philippe Verdy a écrit : > Le 22 février 2013 08:41, Hélène PETIT a écrit : > > 1) > > D'après mon juriste, consulté hier soir, la : > > LOI n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique > > et sa jurisprudence en cours de consolidation, > > > > imposent que l'éditeur de l'infraction au droit d'auteur retire de son site > > l'oeuvre "à la première sollicitation de l'ayant droit". > > Et ont-ils seulement fait cette sollicitation de retrait ? Pourquoi ce > serait à nous de prendre l'initiative alors qu'il n'y a *strictement* > aucun risque pour nous, car la loi prévoit que l'ayant-droit fasse > *d'abord* sa demande avant même de pouvoir porter son litige en > justice ? > > On a pourtant *déjà* les moyens de répondre à une telle demande. > Pourquoi donc se montrer plus prudent que nécessaire,d'autant qu'on a > les moyens de se défendre en montrant alors que le contenu de notre > base n'est PAS une copie intégrale contenu toute la base des GRn ni > permettant de les isoler spécifiquement ? > > (surtout si on n'a pas mentionné un tag spécifique pour les sentiers > GR par rapport aux autres dont la FRPP n'est même pas la créatrice ni > même la délégataire, étant donné que nos contributeurs viennent du > monde entier et peuvent aveoir utilisé aussi d'autres critères pour > l'insertion, par exemple le classement par une autre association > européenne, ou même un programme spécial de protection ou sauvegarde > de l'Union européenne, de l'Unesco, ou d'une fédération sportive > internationale, ou d'une asso environnementale) > > Je ne vois pas à quel titre la FFRP doit automatiquement devenir > propriétaire de tous les chemins de randonnée possibles, *même* si > elle a reçu une délégation ministérielle concernant les chemins > protégés par l'Etat français (cette délégation ne concerne pas la > propriété des chemins créés par la FRPP, mais bien les chemins > historiques concernant leur entretien et balisage, et pour agir comme > intermédiaire avec les autres assos concernées par ces chemins, la > FRPP devenant rapporteur de ces efforts auprès de l'Etat dans le cadre > de cette mission, sans pour autant se prévaloir d'en être > propriétaire). > > Il me semble même que cette délégation publique lui impose de ne PAS > contrecarrer les efforts citoyens de publicité de ces chemins mais > qu'au contraire elle devrait soutenir ces efforts externes. Ce qu'on > fait dans OSM est pour tout le monde (oui même pour les utilisations > commerciales mais pas seulement, car on le fait aussi pour les > citoyens : ce n'était pas le cas de l'éditeur de guides condamné qui > justement imposait des limites de reproduction par son copyright et > par son prix de vente ; OSM n'a rien de comparable avec cet éditeur de > guides, et ce qu'il fait est également à la disposition de la FRPP qui > peut utiliser OSM lui aussi ; on est dans le cadre d'une licence > ouverte, non exclusive, ce qui n'était pas le cas de l'éditeur de > guides qui a été condamné). > > Bref je pense sincèrement que tout ce débat ne sert à rien : on peut > agir avec un excès de prudence là où même la loi nous protège bien > contre une condamnation puisque les ayant-droits sont obligés de faire > une demande de justification de leur droit et auront alors la charge > d'apporter la preuve d'un abus éventuel (qui pour l'instant n'est pas > prouvé du tout puisque l'existence de ces droits n'est même pas > prouvée). > > Continuez sur ce terrain, et en fin de compte plus personne ne pourra > plus RIEN mettre du tout dans OSM (que ce soit des chemins de > randonnée ou pas) car on trouvera toujours sans peine un domaine où la > question de ce qui est une propriété
[OSM-talk-fr] Suppression GR dans OSM, oui, mais il faut autre chose
Bonjour, La suppression de la mention GR semble inéluctable, alors je prend la question sous un autre angle. Quel est l’intérêt de la mention GR ? Pour moi, leur principal intérêt est de hiérarchiser les différents chemins en indiquant : "celui-ci est le chemin le plus utilisé pour ce rendre du point A au point B, il est balisé, entretenu et ne débouche pas dans un cul de sac". Quand je planifie une rando avec une carte IGN, c'est de cette manière que je voie les GR, je me fixe d'abord un objectif, et je n'utilise jamais un GR au simple motif que c'est un GR. Pour les highway en général, on dispose d'une hiérarchisation (primary, secondary, ...) Pour les highway=track, on dispose également d'une hiérarchisation (tracktype=). Par contre pour les highway=path, il n'y a rien de tout cela, et c'est le bazar pour choisir un itinéraire en se basant sur OSM. Dans le wiki, il y a: access=* surface=* : peu utilisé, et ne préjuge pas de l'état sac_scale=* : bien, mais peu utilisé, et trop orienté alpinisne pour traiter les cas généraux trail_visibility=* : se rapproche de la notion de balisage incline=* width=* On peut utiliser plusieurs tags tels que balisé=oui/non entretenu=oui/non fréquentation=faible/moyenne/forte Mais ce qui est complexe risque de ne pas être utilisé, alors le plus simple serait un tag pathtype= du genre grade1 : pour les 20% de chemins localement les plus utilisés et les mieux entretenus grade2 : ... Voir un tag hikingtype= applicable à tout élément highway=* De cette manière plus besoin de relation GR, et je ne doute pas qu'un rendu des chemins utilisant ces tags permettrait de mettre en évidence les GR (tout en restant dans la légalité), mais aussi de nouveau itinéraires potentiellement plus intéressant. A creuser, mais si la FFRP veut garder ses GR, c'est à nous d'inventer autre chose, et mieux. Cordialement Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)
Bonjour,
Je suis partisans de laisser les relations tant qu'aucune demande n’aura
été formulée pour demander leur suppression.
Pour ce qui est du risque juridique, si j'ai bien compris, OSM a demandé
à la FFRP l'autorisation, mais n'a pas reçu de réponse.
Donc la FFRP est parfaitement au courant et a choisi de laisser faire.
OSM est toujours a temps de retirer les relations en question en cas de
demande explicite de la FFRP.
wikipedia publie les itinéraires de manières suffisamment détaillée pour
pouvoir les recréer sur une carte. Quelqu'un sait-il s'ils ont eu des
débats à ce sujet ? ont-ils une autorisation pour cela ?
Balaitous
Le dimanche 17 février 2013 à 11:03 +0100, Pieren a écrit :
> 2013/2/16 :
> > Le message suivant de :
> > ##
> > j'ai pris le temps de renseigner un wiki sur le sujet, y figure le détail
> > du style mkgmap et du fichier typ requis pour obtenir l'affichage désiré.
>
> Ce message posté sur le forum m'a permis de retrouver un grand
> itinéraire GR encore présent dans OSM:
> http://www.openstreetmap.org/browse/relation/2650826
>
> Bien que la relation ne contienne pas la mention directe "GR", le
> tracé est clairement celui de l'itinéraire GR36 de la FFRP. La
> référence ("36") et le balisage (tag "osmc:symbol") sont aussi de la
> FFRP.
> Rappelons qu'il n'y a pas que la marque "GR" qui soit déposée mais que
> les tribunaux ont construit une jurisprudence qui considère que les
> itinéraires eux-mêmes sont une oeuvre originale protégée par le droit
> d'auteur (donc on sort un peu du cadre restreint du droit des
> marques).
> Pour ceux qui doutent encore, lire ceci :
> http://www.voxpi.info/2008/12/12/la-protection-juridique-des-itinraires-de-randonne/
> Je pense donc qu'il est nécessaire, malheureusement, de supprimer
> cette relation (et les autres du même type). Je dis malheureusement
> parce qu'on voit bien que certains contributeurs y investissent
> beaucoup de temps et que ça ne sera pas de gaité de coeur que cela
> sera supprimé mais par obligation vis à vis du projet OSM qui est doit
> être irréprochable dans la protection du droit d'auteur, bien plus que
> la multitude des sites internets amateurs qui parlent des GR et qui
> sont tolérés parce qu'il sont justement amateurs, faits par des
> amoureux de rando et dans un but non lucratif. Alors qu'OSM est une
> base de données qui peut servir à tout, y compris des applications
> commerciales et doit rester à ce titre irréprochable.
> Comme je ne me sens pas l'âme d'un bourreau et que cette décision doit
> être commune, je souhaiterais que ces suppressions des relations GR,
> parfois imposantes en taille, maintes fois évoquées sur cette liste et
> ailleurs, mais jamais effectuées, soient discutées par ses membres les
> plus impliqués lors du prochain SOTM-Fr et actées une fois pour toute
> (ou plutôt, jusqu'à changement du contexte juridique ou d'un accord
> avec la FFRP).
> Qu'en pensez vous ?
>
> Pieren
>
> ___
> 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
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
> Tes conditions exposées sont encore trop simples, tu oublies de parler > dans les polygones que tu fusionnes le fait qu'ils puissent être > membres de relations différentes (et n'ont pas à être fusionnés même > si tous les attributs sont identiques). Tu n'as pas du lire correctement ce que je propose, car j'ai bien précisé que deux polygones membres de deux relations différentes n'ont pas à être fusionné. > Sinon on peut toujours augmenter le nombre de commandes différentes > pour un certain nombre de cas particulier, mais là encore ça n'est pas > simple non plus de comprendre et distinguer les plus nombreuses > commandes disponibles et de leur donner un nom ou une description > signifiante et assez précise pour les distinguer. J'ai au contraire cherché à proposer quelque chose de simple avec 2 commandes fusion/scission, en précisant clairement le contexte d'utilisation possible, et respectant la logique des raccourcis c et p. > ... intersections à calculer et effectuer J'avais pourtant écrit : > Scission d'un polygone : > > Condition d'utilisation : Sélection d'un polygone (simple) et d'un way > dont les extrémités appartiennent au polygone et n'ayant aucun attribut > (way créé dans le seul but de la scission) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Non, je pense qu'un tel outil est réalisable. La plupart des cas d'utilisations concernent des polygones simples, je pense en particulier au landuse. Plus de détail sur un début de spécification possible : Fusion de polygones : Condition d'utilisation : Sélection de 2 polygones avec au moins 1 point commun (simple pas des multipolygones) => Les polygones n'appartiennent à aucune relation : fusion avec éventuellement boite de dialogue pour gérer les tags en conflits => Les polygones appartiennent tous les deux à une même relation => Les polygones ont le même rôle : fusion, il n'en reste qu'un dans la relation => Les polygones ont des rôles différents : message d'erreur => Les polygones appartiennent à deux relations différentes : message d'erreur Scission d'un polygone : Condition d'utilisation : Sélection d'un polygone (simple) et d'un way dont les extrémités appartiennent au polygone et n'ayant aucun attribut (way créé dans le seul but de la scission) => Le polygone n'appartient à aucune relation : création de deux nouveaux polygones héritant des mêmes tags, et suppression du way => Les polygones font partie d'une relation : idem, et de plus les deux polygones créés font partie de la relation avec le même rôle. Je ne pense pas que cela puisse introduire des incohérences. En l'état actuel, je me refuse à modifier Corinne (même si j'ai fait quelques tentatives), alors qu'il y a beaucoup à faire de ce côté là. Si quelqu'un trouve ma proposition intéressante, ça serait bien qu'il la relais à un endroit adéquat. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Quelles fonctionnalités techniques vous manquent ? Mode d'édition polygone
Bonjour, Ce qui serait bien c'est un mode d'édition adapté aux polygones (JOSM). Actuellement il est assez difficile de faire des choses "simples" comme partager un polygone en deux (surtout si ses frontières sont communes avec un autre polygone) Donc ce qui serait pratique, c'est un mode d'édition où : * Un polygone se sélectionne par un clic à l'intérieur de celui-ci. * Deux polygones ayant au minimum 1 point commun peuvent être fusionnés (gestion des attributs comme pour les fusion de way) * Possibilité de fractionner un polygone (par exemple sélection d'un way et d'un polygone, si le way et sans attributs, il disparaît lors de la création des deux nouveaux polygones) Peut-être que cela existe déjà, mais je ne croix pas. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] soucis avec un contributeur en Vaucluse
Il me semble que toutes les références nominatives devrait être supprimées, y compris de l'historique. Je ne sais pas si cela est possible. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Source des données dans OSM
Bonjour, Suites aux discutions sur le cadastre, j'ouvre ce nouveau fils sur les sources d'une manière plus large. OSM est par définition de la fusion de données, or le système actuel privilégie trop l'aspect binaire des sources : tel élément provient de telle source. Par exemple, j'ai récemment fait de la toponymie sur l'Ariège. Les sources de données sont composées de : * Bing pour le géoréferencement * Le cadastre pour la toponymie * Ma connaissance du terrain (là encore c'est une notion très vague, qui recouvre les cartes que j'ai longuement observé étant petit, donc d'une manière très indirecte des données IGN, les panneaux que j'ai pu voir, les discutions avec des personnes, ...) * Des infos que j'ai récolté expressément dans ce but sur le terrain (même s'il s'agit d'une part minime des informations), le Graal étant un plan publique. * Une recherche google sur un nom suite à une mention dans le cadastre pour voir s'il est encore d'actualité (ce qui renvoie sur des sites d'annonce, des annuaire de profession libérales, ...) J'ai récemment taggué : source=géoréférencement:bing;toponymie:cadastre (car 90% de la toponymie en était extraite) Mais dans quel mesure ce travail de fusion de données ne constitue-t-il pas une nouvelle donnée en tant que telle ? Pour le cadastre plus particulièrement, je le consulte via le géoportail (même si j'en ai fait, je ne fait pratiquement plus de géoréférencement depuis le cadastre), donc il est impossible de dire de quel millésime il s'agit. Ce qui me gène, c'est qu'en l’absence de système générique pour gérer les sources, le cadastre est bien souvent la seule source correctement citée. Mais quelle est la valeur d'un tag source=cadastre millésime xxx lorsque la voie en question a été redessinée depuis ? D'où ma proposition, pourquoi en plus du système actuel ne pas affecter des sources aux groupes de modification ? Et pour les développement de josm, il faudrait pouvoir facilement pratiquer l'ajout de source. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthorectification
Le jeudi 18 octobre 2012 à 22:08 +0200, Philippe Verdy a écrit : > Dans les deux cas, cela évitera alors de voir ce qu'on constate sur > les images dites "orthorectifiées" en haute résolution (décimétrique > ou meilleures) avec des décalages dépassant pourtant encore les 10 > mètres par endroit (trop loin des points de référence), afin de ne > plus avoir que des décalages du même ordre de grandeur que la haute > résolution des images. Reste que même avec un très bon modèle de caméra, la précision d'une image orthorectifiée reste liée à celle du MNT utilisé, et des points de référence utilisés. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Orthorectification
Suite à un point mal placé, ma première image était incorrecte, voici la nouvelle: http://ubuntuone.com/3ZeUWV2khGee6Ie2ZfNvgC Au sujet d'ASTER : It is referenced to the WGS84/EGM96 geoid Or j'ai utilisé l'altitude au dessus de l'ellipsoide, donc il y a une erreur à ce niveau les codes proj4 que j'ai utilisé sont +init=epsg:4326 +proj=geocent +datum=WGS84 +units=m +no_defs Je pense que c'est un EPSG:5773, qu'il faudrait pour convertir les coordonnées (lat, lon, h) en (X, Y, Z) Pour le reste, c'est vrai que passé le modèle de caméra sténopé, je n'y connait pas grand chose. Il faut que je me documente sur ces coordonnées 4D. Par contre, je part bien du l'image orthorectifiée pour ensuite déterminer les coordonnées dans l'image d'origine. Reste que compte tenu des données utilisées pour le géoréférencement (bing+ASTER) utiliser un modèle plus précis est peut-être illusoire. Dans l'immédiat (d'ici la fin de l'année) je vais essayer de mettre les sources à disposition, en retravaillant sur la partie GUI. Le jeudi 18 octobre 2012 à 21:25 +0200, Philippe Verdy a écrit : > Le 18 octobre 2012 19:55, Balaitous a écrit : > > 3. Recentrage en prenant pour origine le barycentre du nuage de point > > (X, Y, Z) > > Là encore un problème à la source des erreurs : les photos > "orthorectifiées" ne le sont pas nécessairement en fonction de l'effet > de perspective (notamment les prises de vue en altitude basse). La > correction de cet effet ne peut pas se contenter d'utiliser un > barycentre unique, mais nécessite une dimension supplémentaire (liée > au degré de liberté supplémentaire introduit par l'altitude de > l'appareil de prise de vue). De la 3D on passe à la 4D (cette > dimension supplémentaire est la distance entre le point au sol visible > dans l'image dont on a les coordonnées 3D, et le centre optique de > l'appareil de pise de vue, mais en projection pour l'image finale en > 2D, cette dimension pourra être ignorée : on travaille en coordonnées > homogènes). > > De l'effet de déformation « œil de poisson » des objectifs en grand > angle, c'est plus difficile à corriger (il faudrait avoir une > description précise des propriétés géométriques de l'optique de > l'appareil). La seule façon d'en tenir compte de façon correcte est de > ne pas traiter l'image en la découpant simplement en facettes > triangulaire planes, mais en utilisant une transformation "lissante" à > base de splines (au moins quadratiques sinon cubiques), et d'augmenter > le nombre de points de référence pour réduire la surface des triangles > retenus quitte à en augmenter le nombre (les splines à calculer > contiendront donc davantage de noeuds). > > Toute la difficulté est là, dans le nombre de paramètres et de degrés > de libertés pris en compte, et dans le choix des transformées pour > tenir compte des effets à corriger. > > Le calcul des paramètres initiaux peut sembler compliqué, mais en fin > de compte un traitement efficace des images 2D peut avoir lieu en > utilisant une matrice de transformation simpel mais efficace et > comportant plus de dimensions que 2 ou 3. > > A mon avis cette matrice carrée doit avoir au minimum 4 dimensions, ce > qui implique que pour chaque point 2D de l'image cible, il faut > d'abord calculer les 2 coordonnées dans l'image source, et calculer > les 2 autres coordonnées par une transformée *non* linéaire tenant > compte des effets à corriger, mais pour simplifier on peut > effectivement faire ce calcul des 2 autres coordonnées manquantes > uniquement sur les points de référence, pour ensuite estimer les > autres points 4D de l'image par triangulation linéaire dans cet espace > 4D augmenté et non dans le seul espace 2D de l'image source. > > Comme ensuite la matrice de transformation 4D est aussi linéaire, on > peut combiner l'interpolation 4D des coordonnées 2D sources et la > matrice en une transformation linéaire unique. > > On obtient alors en résultat des coordonnées 4D aussi, dont il ne > reste plus qu'à ignorer les deux dernières coordonnées (représentant > la hauteur dans la direction de la verticale de chaque point de > l'image obtenue, et la distance de ce point au centre optique > transformé de la prise de vue initiale, dans une direction variable > mais passant par ce centre optique "déplacé"). > > Dans les faits, pour produire une image orthorectifiée, on utilise > plutôt la transformée inverse (on part des corrdonnées 2D de chaque > pixel dans l'image rectifiée, pour en déduire une position dans > l'image source). Cela se fait par l'inversion de la matrice 4x4 (si on > s'est contenté d'une triangulation plane), ou 5x5 (avec une > transformation lissante à base de "spline" quadratique), ou 6x6 > (spline cubique). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Orthorectification
Bonjour, Suite aux réponses précédentes, un peu plus de détail. Pour l'orthorectification, voila comment j'ai procédé : 1. Création de couples de points (lat, lon) <-> (x, y) à l'aide de l'imagerie bing 2. Transformation (lat, lon) -> (X, Y, Z) en utilisant le MNT ASTER 3. Recentrage en prenant pour origine le barycentre du nuage de point (X, Y, Z) 4. Par ACP, détermination de 3 directions (U, V, W), de manière à avoir la plus petite variance sur l'axe W 5. Transformation des coordonnées (X, Y, Z) -> (U, V, W) 6. Par modèle de caméra sténopé : calcul d'un modèle 3D, A tel que t(sx, sy, 1) = A t(U, V, W, 1) calcul d'un modèle 2D, B tel que t(sx, sy, s) = B t(U, V, 1) Et choix du meilleur modèle puis pour calculer l'image finale : Pour chaque pixel de coordonnées (a, b) dans le système de projection choisi (uniquement lambert II pour l'instant), chaîne de transformation (a, b) -> (lat, lon) -> (X, Y, Z) -> (U, V, W) -> (x_img, y_img) L'assemblage final est fait par enblend (ça fait des petits miracles pour cacher les défauts) Les principales difficultés que j'ai sont au niveau de la partie GUI (manque d'expérience en programmation pour la conception) Capture d'écran: géolocalisation http://ubuntuone.com/0FJ7L9DjgCp3pvkmriXFUZ assemblage (avant d'appliquer les masques) http://ubuntuone.com/5YOL3oSa6hQaAZnktZHuN2 résultat (Tarascon sur Ariège 1953, résolution 1 pixel par mètre, 10 points par photos), j'ai volontairement choisi un exemple en montagne http://ubuntuone.com/2DbKSGdRiepuEyGOJKUTTn Les veilles photos permettent de faire apparaître des chemins aujourd'hui dissimulés, par exemple Du côté d'Ornolac, j'ai tenté de cartographier un chemin Image de 1953: http://ubuntuone.com/11XTy3kFuse6Ucn6IEBtDb bing aujourd'hui: http://ubuntuone.com/63lJxUuX4elmcutXcR1q1A Il faut que je revoie encore le code, je le mettrai bientôt à disposition ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN
Le mardi 16 octobre 2012 à 12:50 +0200, Eric Sibert a écrit : > > Mais même les photos anciennes > > ne sont pas toujours disponibles, ce qui est particulièrement > > choquant car elles > > ont été payé par nos grands-parents et devraient à ce titre faire parti du > > patrimoine commun librement accessible. > > Tes grands-parents ont payé pour faire les photos et stocker les > négatifs. Mais ils n'ont pas payé le gars qui va chercher le négatif > et le passer dans le scanner ;-) > > > > J'ai d'ailleurs commencé cet été à écrire une application > > d'orthorectification (MMT ASTER) > > dont on peut voir un exemple ici (mosaïque à partir de plusieurs > > images, projeté en > > Lambert II avec superposition OSM) > > Pleine résolution (77.7Mb) : > > http://ubuntuone.com/2qHmVR2SCWu5vYaQ1qHUNI > > Tu utilises quelles méthodes pour caler les photos? La part manuelle > de travail était-elle importante? > > Eric > Les photos sont calées individuellement par les images bing, et une bonne précision nécessite un grand nombre de points. Les essais de reconnaissance automatique que j'ai fait (huggin) n'ont pas été concluants, il n'y a rien qui ressemble plus a un toit qu'un autre toit, et les problèmes de perspective sont très important (en limite de photo, la prise de vue est effectuée avec un angle de 45°) C'est surtout au niveau GUI qu'on peut rendre ce travail moins fastidieux. Pour l'instant le programme est un peu en sommeil, mais je compte m'y remettre cet hivers. Je suis preneur de toute bonne idée. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN
Le mardi 16 octobre 2012 à 11:18 +0200, Frédéric Rodrigo a écrit : > Le 16/10/2012 08:11, Pierre-Alain Dorange a écrit : > > Balaitous wrote: > > > >> J'ai d'ailleurs commencé cet été à écrire une application > >> d'orthorectification (MMT ASTER) dont on peut voir un exemple ici > >> (mosaïque à partir de plusieurs images, projeté en Lambert II avec > >> superposition OSM) > >> Pleine résolution (77.7Mb) : > >> http://ubuntuone.com/2qHmVR2SCWu5vYaQ1qHUNI > >> Résolution réduite (7.2Mb) : > >> http://ubuntuone.com/7Dw2byZFNfYNziaRz4QfNc > > > > Excellent. > > Le code est disponible ? > > Ce m'intresse pour un usge personnel (en attendant les droits IGN). > > Ces photographies font partie des missions régaliennes de l'IGN. Il n'y > a pas besoin de droit ou autorisation autre que la loi CADA de 78 pour > les utiliser. C'est d'ailleurs rappelé sur le site de l'IGN : > > http://www.geoportail.gouv.fr/actualite/181/telechargez-les-cartes-et-photographies-aeriennes-historiques > > À ne pas confondre avec les photo orthorectifiées qui elles font partie > de la mission commerciale. > > Frédéric. Je compte fournir le code, mais j'ai encore pas mal de problème au niveau GUI. Effectivement, il n'y a pas de droit d'utilisation, et ces photos peuvent être utiles pour OSM, mais seule une petite partie est accessible, c'est cela qui est dommage. Je doute fortement que ces veilles photos aient été orthorectifiées, existe-t-il des moyens d'orthorectification hors informatique ? Car pour ce qui est de l'informatique, je doute fort que cela ait été fait avant le début des années 80 voir 90. Pour rappel, un supercalculateur du début 90 n'était pas plus puissant qu'un laptop d'aujourd'hui, et à cette époque, la france n'en possédait que très peu. Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendez vous avec la Direction de l'IGN
Le jeudi 27 septembre 2012 à 18:45 +0200, Eric SIBERT a écrit : > > Nous sommes à votre écoute pour toute remarque ou doléance à remonter à > > l'IGN ;) > > J'insiste : réellement libérer les données libres. > > Pour le cas des repères géodésiques : possibilité de consulter les > fiches de manière automatisée. Voir de disposer d'un moyen d'être > informé à chaque mise à jour d'une fiche. Comme ça, on ne sera pas > obliger de retélécharger tout le répertoire qu'ils vont mettre à notre > disposition chaque semaine :-) > > Photos aériennes brutes : on veut les photos actuelles, pas celles de 50 > ans. Les photos actuelles ont déjà été numérisées pour l'orthophoto donc > il n'y a aucune raison technique de ne pas les mettre à disposition. Les photos d'il y a 50 ans sont aussi intéressantes (je travaille sur l'Ariège, de nombreuses zones actuellement boisées ne l'était pas à cette époque, et de vielles photos permettent de voir des chemins qui existent encore mais ne sont plus visible sur les photos actuelles). Mais même les photos anciennes ne sont pas toujours disponibles, ce qui est particulièrement choquant car elles ont été payé par nos grands-parents et devraient à ce titre faire parti du patrimoine commun librement accessible. J'ai d'ailleurs commencé cet été à écrire une application d'orthorectification (MMT ASTER) dont on peut voir un exemple ici (mosaïque à partir de plusieurs images, projeté en Lambert II avec superposition OSM) Pleine résolution (77.7Mb) : http://ubuntuone.com/2qHmVR2SCWu5vYaQ1qHUNI Résolution réduite (7.2Mb) : http://ubuntuone.com/7Dw2byZFNfYNziaRz4QfNc > Faire un inventaire des données sous licence libres dont dispose l'IGN. > > La suite pour les prochaines réunions. > > Eric > > ___ > 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
Re: [OSM-talk-fr] Démarrage de la destruction des données (transition ODbL)
Bonjour, Comment faire pour savoir si on utilise la bonne licence ? Merci Balaitous Le mardi 10 juillet 2012 à 09:47 +0200, Eric Marsden a écrit : > [Vu sur la liste de diffusion principale, t...@openstreetmap.org. Ceci > est une information et non une traduction du message d'annonce.] > > Le robot qui supprimera les données incompatibles avec la licence ODbL et > les termes du contributeur (c'est à dire, des données qui, à un moment > dans leur historique, ont été modifiées par un utilisateur n'ayant pas > accepté les termes du contributeur) devrait commencer son travail le mercredi > 11 juillet (demain). > > Le robot tournera par zone géographique, dans l'ordre suivant: > > Ireland > UK > Western Europe > North America > Australia > rest of the world > > Une fois ce travail de suppression des contributions terminé, les > données OSM ne seront plus distribuées que sous la nouvelle licence > expérimentale ODbL. Il est prévu que le processus de destruction des > données dure environ un mois. > > Les serveurs et API continueront à fonctionner pendant cette période, > sans interruption de service. Il est conseillé de sauvegarder plus > souvent son travail lorsque le robot destructeur travaille dans sa > zone, pour éviter les conflits d'édition. > > Ce processus était prévu pour démarrer début avril, mais sa composante > technique avait été insuffisamment planifiée, d'où le retard dans sa > mise en oeuvre. > > > Message d'origine en anglais: > >http://blog.osmfoundation.org/2012/07/09/licence-redaction-ready/ > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Aide sur les tags.
Bonjour, Mon problème ce coup-ci est de tagger un ancien canal couvert (en montagne destiné à la production hydroélectrique), et qui sert aujourd'hui de chemin de randonnée. highway=path sac_scale=A voir T1 car c'est plat waterway=canal waterway:ruins=yes Il ne faudrait pas qu'il apparaisse en bleu, car il n'y a plus d'eau Ou alors comme pour les trains waterway:dismantled=yes Merci ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment tagger une conduite forcée ?
Bonjour, Je viens d'essayer, c'est en plein milieu http://www.openstreetmap.org/?lat=42.74734&lon=1.45122&zoom=17&layers=M Le problème, c'est qu'il n'apparaît plus (attention la mise à jour de la carte n'est pas encore terminée) !! La proposition me semble intéressante, mais pipeline traduit trop à mon avis une idée de transport horizontal, alors que la conduite forcée est plutôt un transport vertical. Autre question : une conduite forcée commence généralement par une chambre de mise sous pression. Quels tags utiliser ? Encore une question, pourquoi dans le rendu une centrale hydroélectrique n’apparaît-elle que par son nom ? Merci Balaitous Le dimanche 01 juillet 2012 à 19:56 +0200, Jean-Claude Repetto a écrit : > On 07/01/2012 02:29 PM, Balaitous wrote: > > Bonjour, > > > > Tout est dans le titre. > > Parmi les tags existant je voie waterway=canal, qui s'en raproche le > > plus, mais cela n'est pas satisfaisant. > > Quel tag utiliser ? > > > > Merci > > Balaitous > > Bonjour, > > Je suggère : > man_made=pipeline > type=water > location=overground > operator=... > > > Voir la page http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline . > > Jean-Claude > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Comment tagger une conduite forcée ?
Bonjour, Tout est dans le titre. Parmi les tags existant je voie waterway=canal, qui s'en raproche le plus, mais cela n'est pas satisfaisant. Quel tag utiliser ? Merci Balaitous ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Merci pour ces réponses qui me permettent d'y voir un peu plus clair. Le vendredi 25 mai 2012 à 14:39 +0200, sly (sylvain letuffe) a écrit : > On jeudi 24 mai 2012, Balaitous wrote: > > Bonjour, > > Bonjour, > > > Pour mon premier message, je voudrais poser une question que je me pose > > depuis un moment. > > Est-ce que les tags d'une relation sont héréditaires ? > > En d'autre terme lorsque je mets un tag dans une relation celui-ci > > est-il transmis aux enfants de la relation (lorsque ceux-ci ne > > redéfinissent pas le tag en question) ? > > Il n'y a pas "une" mais plusieurs réponses à ta question, principalement car > l'éco-système OSM (la base, les utilisations, les éditeurs, le wiki) sont > très souples et disons, un peu anarchique parfois et pas toujours cohérent et > pas imposé par quoi que ce soit. (Je ne commenterais pas les défauts et > avantages) > > Donc la réponse à ta question va dépendre de quelle partie de cet éco-système > elle concerne. > > Dans la base OSM (celle qu'on édite avec JOSM/potlatch/...) il n'y a pas de > notion d'hérédité, une relation a ses tags, un way les siens, un noeud les > sien, et rien n'est recopié nulle part de manière automatique. > Exemple, si tu places le tag landuse=forest sur une relation multipolygon, ce > tag ne se retrouvera pas sur les ways membres de la relation. > > L'hérédité, si elle existe quelque part, sera dans la manière d'utiliser les > données OSM, c'est à dire les logiciels de rendu, l'impression d'une > carte, ... > Et ça, c'est laissé complètement libre à celui qui veut se servir des données > OSM, et donc au logiciel qu'il va utiliser pour s'occuper de la conversion du > format .osm vers un format exploitable pour son besoin. > > Le logiciel osm2pgsql par exemple qui est célèbre car étant utilisé par la > majorité des rendus sous forme de carte des données OSM (dont le rendu > proposé en page d'accueil du site www.osm.org) dispose de quelque traitement > de l'hérédité au niveau de certaines relations seulement (type=route, > type=boundary et type=multipolygon) et pour certains tags seulement défini > dans par liste blanche ou noire > Il n'y a rien de systématique donc, et tout est fait au cas par cas, selon le > besoin et le logiciel utilisé. > Et enfin, il y a le wiki, qui va décrire l'utilisation de relation, et pour > lesquelles il va (ou non) explicitement indiquer que toute utilisation de > cette relation "devrait" considérer l'hérédité. Mais le wiki n'est qu'une > description, la décision finale revenant à l'utilisation qui sera faite des > dites relations et qui dépendra, certes de la description faite du wiki, mais > aussi de la manière réél et majoritaire dont les contributeurs OSM auront > rentré dans la base de donnée Côté wiki il ne me parait pas à jour. Par quel processus une relation passe du stade de proposé à officiel ? Sur la base des statistiques d'utilisation ? Quand j'aurais plus de temps, j'irais faire un tour de ce côté là aussi. > Exemple, si 1% seulement des routes nationales de france disposent d'une > relation avec nom+ref alors que tout le reste c'est de la réplication des > tags sur chacun des composants, alors je suppose que quelqu'un souhaitant > faire un rendu des routes nationales de france va simplement laisser tomber > l'hérédité car ça ne gérera que trop peu de cas. > A l'inverse, si ce chiffre passe à 99% ça va commencer à intéresser du monde, > et les choses évoluerons. Pour le projet qui m'intéresse, je compte pourtant m’appuyer sur les relations quand elles existent, et faire de l'empirique ailleurs (2 ways avec un certain nombres d'attribut communs = 1 route) (2 ways // avec même catégorie de route = probablement 1 route a chaussée séparée) Pour ma part hier j'ai ajouté 2 ou 3 routes, dès qu'elles sont coupées en 2 je les encapsules dans une "street", et je ne met plus le nom dans tous les tronçons. Aux éditeurs de se débrouiller comme cela m'a été dit dans certaines réponses. > Tout ça est donc un salmigondi s'entre-influençant fait de la manière > d'éditer, du nombre d'utilisation qui en est faite, de documentation wiki qui > en parle et du support plus au moins aisé/influencé par les éditeurs OSM. Une > sorte de progression anarchique par essai/erreur qui entraîne sans doute de > la perte de temps, de création d'algorithme plus compliqué mais aussi de plus > de flexibilité. > > Mon pronostic c'est qu'on devrait ré-avancer vers la normalisation > (factorisation des tags par les r
Re: [OSM-talk-fr] Héritage et relation
Le jeudi 24 mai 2012 à 18:59 +0200, Gilles Bassière a écrit : > Le jeudi 24 mai 2012 à 09:36 -0500, Balaitous a écrit : > > Merci pour vos réponse. > > > > Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des > > tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand > > je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de > > marcher). > > Je pense que c'est l'éditeur ou le rendu qui t'induit en erreur. Si tu > prend un bâtiment avec un cour intérieure par exemple, il y aura deux > chemins membres d'une relation de type multipolygon. Le seul objet OSM > qui représente le bâtiment est la relation. Les deux chemin *ne sont > pas* des bâtiments. Ils peuvent éventuellement porter des tags propres > pour représenter un *autre* objet. > > > En fait, le point de départ de ma réflexion, c'est qu'après avoir > > contribué un peu à l'édition, j'aimerais bien avoir une carte papier! > > Et je compte dans les mois qui viennent essayer de faire une telle > > carte, échelle visé 1:25000 et 1:10. > > L'exploitation envisagée de la base de données ne doit en aucun cas > commander la manière dont on l'édite. Autrement dit : on ne taggue pas > pour le rendu (ou pour quoi que ce soit d'autre). Entièrement d'accord. Le point de départ est effectivement l'élaboration d'une carte, mais les questions sont plus générales. La question que je me suis posé est quand deux way highway=* sont parallèles (pas évident à détecter, mais c'est possible algorithmiquement) s'agit-il des deux chaussées d'une même route ou non ? Cette information n'est pas spécifique à un rendu particulier, c'est une question d'échelle de représentation (et pas uniquement graphique) de l'information. Les relations existent, mais il y a un gros travail de standardisation à faire. Sur le wiki, je voie que des propositions de 2008 restent aujourd'hui des propositions! et le nombre de relation officiellement reconnues ne dépasse pas 6! Assez limité pour décrire de l'information de grande échelle. Pour les routes street ? associatedstreet ? collected way ? > > Si par exemple tu veux faire une carte du bâti, tu pourras avoir 2 > tables après import de la base : une table du bâti polygone (way) et une > table du bâti multipolygone (relation). C'est *après l'import* que tu > devras faire un post-traitement pour mettre ça au propre dans une seule > table. Pareil pour fusionner les tronçons de routes qui n'aurait pas été > groupé dans une relation (ST_LineMerge est ton ami). > > > Le système existant est très orienté navigation routière. > > Dans OSM, il y a aussi de l'occupation des sols, des chemins de > randonnées, des POI, des balises de navigation maritime, des ... Il n’empêche que la représentation des routes est très orienté voie de circulation. > > Les outils de modélisation OSM sont simples et souples et c'est pour ça > que la base est aussi riche :) > > > Effectivement les besoins ne sont pas les mêmes en rase campagne, où la > > règle un trait = une route fonctionne assez bien, et tant qu'une route > > n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne > > assez bien. En ville ou sur les grands axes routiers par contre la > > segmentation est beaucoup plus forte, et question simplicité d'édition, > > le système actuel n'est pas satisfaisant, rajouter une modifier une ref > > ou un nom sur une route partagée en 10 ou 2 segments à de quoi > > décourager plus d'un utilisateur! > > Rien ne t'empêche de créer une relation pour cette voie et ainsi > factoriser les tags. Je ne l'ai jamais vu mais ça n'est ni impossible ni > interdit. Le problème est que la factorisation des tags n'est pas reconnue (exception du multipolygon), il me semble que la plupart des moteurs de rendu fonctionnent au niveau trait. > > > Le principe d'un projet tel qu'OSM est de fonctionner par petites > > évolutions avec compatibilité ascendante. Le principe d'héritage des > > tags me parait entrer dans cette catégorie. > > Au niveau de l'édition cela peut se gérer assez facilement si un peu > > comme ce qui est fait pour les relations, lors de la sélection d'un > > élément JOSM affiche les groupes dont il fait partie, et si JOSM propose > > lors du découpage d'un segment de regrouper les tags existant en créant > > un nouveau groupe. > > L’existence de la relation type=route montre qu'il y a un besoin, mais > > son utilité est bien faible sans l'héritage des tags. > > En fait, je
Re: [OSM-talk-fr] Héritage et relation
> Bonjour, > > > > http://wiki.openstreetmap.org/wiki/FR:Relations/Relations_are_not_Categories > > Par extension, je ne comprends pas que l'on regroupe dans une relation > des voies qui possèdent le même nom, le tag name est fait pour ça ! > > > Ça n'était pas vraiment le sens de mon mail, et bien que je ne sois pas particulièrement partisan de regrouper toutes les banques d'un même opérateur dans une grande catégorie, des questions comme ça doivent se poser. Est-ce que OSM doit seulement rester un jouet avancé de décalcomanie pour adultes ? Ça restera certainement l'utilisation pour la majorité des contributeurs (et c'est aussi utile), mais si 5% des contributeurs pouvaient contribuer à donner plus sens ça serait bien également. C'est dans le sens que la valeur ajouté réside. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Héritage et relation
Merci pour vos réponse. Donc si je comprend bien en dehors du myltipolygon, pas d'héritage des tags. (Je ne sais pas si c'est officiel pour le multipolygon, mais quand je l'utilise je ne tag pas les ways correspondantes, et ça a l'air de marcher). En fait, le point de départ de ma réflexion, c'est qu'après avoir contribué un peu à l'édition, j'aimerais bien avoir une carte papier! Et je compte dans les mois qui viennent essayer de faire une telle carte, échelle visé 1:25000 et 1:10. Le système existant est très orienté navigation routière. Effectivement les besoins ne sont pas les mêmes en rase campagne, où la règle un trait = une route fonctionne assez bien, et tant qu'une route n'est pas trop segmenté, la gestion manuelle de la cohérence fonctionne assez bien. En ville ou sur les grands axes routiers par contre la segmentation est beaucoup plus forte, et question simplicité d'édition, le système actuel n'est pas satisfaisant, rajouter une modifier une ref ou un nom sur une route partagée en 10 ou 2 segments à de quoi décourager plus d'un utilisateur! Le principe d'un projet tel qu'OSM est de fonctionner par petites évolutions avec compatibilité ascendante. Le principe d'héritage des tags me parait entrer dans cette catégorie. Au niveau de l'édition cela peut se gérer assez facilement si un peu comme ce qui est fait pour les relations, lors de la sélection d'un élément JOSM affiche les groupes dont il fait partie, et si JOSM propose lors du découpage d'un segment de regrouper les tags existant en créant un nouveau groupe. L’existence de la relation type=route montre qu'il y a un besoin, mais son utilité est bien faible sans l'héritage des tags. ps: Je n'ai pas le niveau en anglais pour pouvoir participer aux discutions en anglais re ps: Quel est le tag pour ajouter un commentaire ? Je veux dire par la un court texte explicatif destiné aux contributeurs futurs. J'utilise comment=* car je n'ai rien trouvé dans la doc. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Héritage et relation
Bonjour, Pour mon premier message, je voudrais poser une question que je me pose depuis un moment. Est-ce que les tags d'une relation sont héréditaires ? En d'autre terme lorsque je mets un tag dans une relation celui-ci est-il transmis aux enfants de la relation (lorsque ceux-ci ne redéfinissent pas le tag en question) ? Plus généralement, depuis quelques temps que je m'intéresse à OSM, je trouve un manque de séparation des aspects géométriques (point, ligne, ...) et sémantiques. Cela risque de poser d'importants problèmes de cohérence pour le nommage des routes, de plus en plus fragmentées. Je ne sais pas où en sont les discutions, mais il me semble qu'il faudrait aller vers un système de tag par regroupements récursifs des éléments, et héritage des tags. (Il me semble avoir vu qq chose dans ce sens pour la prochaine API) En gros, généraliser les relations, faire du multipolygon un élément géométrique à part entière. Pour les routes cela permettrait de clarifier les aspects : * de voirie * d'entité géographiques * d'entité administrative (no de voirie, axe européen, ...) * d'entité logique (axe de transport en commun, ...) Il y a déjà des choses, et c'est d'ailleurs le point de départ de ma question, c'est en voulant regrouper des routes que je me suis dis que c'était totalement inutile s'il n'y avait pas héritage du nom de la référence, ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
