Ok, Je suis pas encore familier avec JOSM. J'ai pas pris le temps de m'y mettre plus que ça. J'ai plus l'habitude des solution web ou d'ArcGIS. Mais bon, tu as raisons de dire qu''iD que c'est pas l'idéal. Mais bon dans ce cas il faut limité les possibililé d'iD ou amélioré son fonctionnement pour éviter des désagréments sans pour autant dire.
Quand tu veux décomposer des intersections, tu et obligé de coupé ton tronçon et c'est aussi le cas dans JOSM. Avec iD il n'y a pas de filtre et c'est dommage. Car c'est histoire de relation ne serait pas aussi chiante. Je viens de réouvrir le cadastre pour ta zone et elle n'a pas de nom dans le cadastre d'où le trou mais David pourra surement en dire plus. Je pense qu'il faut voir avec la mairie pour avoir plus de détail. Et je suis pas sur que le rattachement à une autre commune change de découpage des quartiers ou ensembles parcellaires. Je prendrai plus de temps pour JOSM plus tard pour le moment je suis sur une appli mobil de tracking pour Windows Phone. Le 15 octobre 2014 15:23, Philippe Verdy <verd...@wanadoo.fr> a écrit : > Il y a bien un PLU à la Ferté Macé (publié en annonce légale dans > Ouest-France, 1,60€ sur https://actulegales.fr/annonce-legale/1004035453). > Mais il va sans doute être obsolète car la commune souhaite s'associer avec > les autres communes de la communauté de communes pour passer au PLUi > (intercommunal). > > Je ne comprend pas trop comment tu manipules les choses sous iD mais je > n'ai jamais vu avoir besoin de couper une relation en deux et copier des > morceaux pour ensuite reconsituer la zone initiale en réassemblant après > avoir découpé une route. > > Je n"aime pas du tout iD pour faire des découpages complexes de toute > façon JOSM est tellement plus pratique, plus souple et permet de ne pas > être noyé sous das tas d'autres données. iD c'est fait pour des modifs très > locales (pas pus grande qu'une seule rue, ou ajouter un batiment, une > adresse, un nom; une limite de vitesse, un passage piéton. > > iD est une catastrophe pour ceux qui l'ont utilisé pour ajouter des > rond-points (en cassant des lignes de bus; et autres itinéraires dans > lesquels se forment des trous. iD mélange aussi tous les membres et ne > garde pas leur continuité, il coute cher ensuite pour ceux qui doivent > réparer. Je connais très peu de gens capables de comprendre comment > travailler efficacement avec des relations dans cet éditeur. Et puis > qu'est-ce que c'est lent et lourd en mémoire, le navigateur rame, les accès > constants au réseau sont pénibles, même sur une connexion fibre. A ,on avis > il surcharge même les serveurs de l'API d'OSM. > > La manipulation des relations dans iD passe par des dialogues de sélection > ultra compliqués et très lourds car peu sélectifs, il faut sans cesse > passer en revue les longues listes proposées et ne pas se tromper car il y > a peu d'indice et aucun filtrage. Il est inutilisable pour moi en dessous > du niveau de zoom 15; donc pas moyen de travailler dessus à l'échelle d'une > commune entière comme la Ferté-Macé (c'est illisible en plus; on a baucoup > de mal à sélectionner ce qu'on veut avec). > > iD c'est de l'occasionnel quand j'ai déjà une session OSM en cours et pas > envie de charger une autre calque. Parfois pour des modifs très légères > (par exemple corrections très simples dans OSMose sur un seul objet) > j'utilise directement rawedit (en XML) c'est plus vite fait, mais jamais je > n'utiliserai iD (ni même Potlatch2) pour Osmose, si possible j'utilise JOSM > pour tout (je peux provoirement cacher un calque et ouvrir un calque séparé > pour des modifs ponctuelles qui nécessitent plus de données que ce que je > ne veux pas garder dans le calque actuel si je ne veux pas ensuite purger > des tas d'éléments non modifiés et non utiles à la correction à faire). > > JOSM est mon ami (avec les touches CLTR+ALT+D ou une icone ajoutée sur la > barre d'icônes pour la même commande, plus pratique d'un clic qu'avec 3 > touches). Il permet aussi de créer temporairement des relations de travail > pour garder des sélections d'objets en cours de modif ou à vérifier. Pour > repérer facilement cette relation de travail dans la liste, je lui donne un > tag "type=!TODO" au lieu de multipolygon, avec un point d'exclamation au > début de la valeur pour qu'elle soit en tête de liste des relations (qui > est classée par type puis par nom). > > Modifs terminées, je peux sauvegarder le fichier, purger la relation > temporaire de la mémoire et je peux envoyer les données puis fusionner les > données dans un calque principal pour le mettre à jour avec les données que > je souhaite garder pour la suite. > > Le 15 octobre 2014 14:55, Jérôme Seigneuret <jseigneuret-...@yahoo.fr> a > écrit : > > http://overpass-turbo.eu/s/5tq une requete des way en question. >> http://overpass-turbo.eu/s/5tv une requete des relation en question. >> >> Il y a des trous dans les relations et je pense qu'il manque des tronçon >> pour fermer le tout. >> >> Sinon j'ai regardé le cadastre pour voir et c'est un regroupement de >> parcelle correspondant au lieu-dit (voir sur cadastre.gouv.fr) >> Un centre serait pas mal pour voir les nom des quartiers dans les >> relation. >> >> >> Pour le reste en effet sous iD si tu veux découper un way il faut déjà >> vérifier s'il n'est pas en relation avec un autre tracé au moment de faire >> le découpage sur le noeud souhaité.Une route superposé sur un découpage >> administratif (les noeud sont en relation par exemple) si tu découpes le >> noeud avec des relations, ça coupe tous les objets concernées par ce noeud. >> >> Et ça tu ne le sait pas forcément. Si tu as plusieurs niveaux de contours >> administratif c'est la même merde. Le seul moyen que j'ai trouvé c'est de >> décomposer la relation au préalable puis couper l'entité puis refaire la >> relation si nécessaire. >> >> C'est en coupant une route que j'avais tous cassé la dernière fois. >> >> Je regarde le cadastre pour vérifier ta zone >> >> >> >> >> Le 15 octobre 2014 13:55, Philippe Verdy <verd...@wanadoo.fr> a écrit : >> >> Layers en fait d'ailleurs un rendu de toutes ces relations qui sont bien >>> là >>> >>> >>> http://layers.openstreetmap.fr/?zoom=13&lat=48.58094&lon=-0.35914&layers=B0000FFFFFFFFFFFFFFFTFFFFFF >>> >>> Il n'y a qu'un seul way qui ne correspond encore à aucune relation 10 >>> bien qu'il soit marqué comme boundary de niveau 10 et ce way est connecté >>> correctement par ses extrémités aux autres utilisés par des relations >>> boundary de niveau 10. >>> >>> D'ailleurs je vois que depuis mon premier message il y a eu de nouvelles >>> relations ajoutées pour les lieux-dits. Mais certains leiux-dits sont >>> coupés en deux (La Sourdière par exemple) et pas du tout par l'ajout d'une >>> limite de landuse et je ne vois pas pourquoi iD découperait une relation en >>> deux relations. du fait qu'on découpe un segment, il a plutôt tendance à >>> accumuler les ways découpés dans les relations existantes et y laisser des >>> ways en trop... >>> >>> >>> >>> >>> Le 15 octobre 2014 13:45, Philippe Verdy <verd...@wanadoo.fr> a écrit : >>> >>> Non justement car ce sont bien tout un tas de relations administratives >>>> de niveau 10 qui ont été créées toutes correctement fermées sauf une en >>>> cours de tracé visiblement avec un chemin isolé de toute relations car >>>> visiblement il manque des traits a l'est pour ne pas reprendre les >>>> parcelles d'une voirie de jonction. Et id n'y est pour rien car chacune des >>>> relations administratives des noms représentant selon les cas un lieu dit, >>>> une rue, une place, ou presque tout un quartier... Et ce sont des groupes >>>> de parcelles couvrant des propriétés différentes et des petites voiries de >>>> desserte interne. Bref ca a été fait volontairement et sans aucun rapport >>>> avec les landuse même si pour certaines relations (en minorité) il y a des >>>> wommns avec les landuse. Bref je ne comprend pas sur quoi se base ce >>>> découpage qui n plus est incomplet au nord ouest de la commune. >>>> >>>> Ne regarde pas que le way que j'ai indique mais les ways qui y sont >>>> connecte par les extrémités. Un requête overpass sur les admin level 10 >>>> dans une BBox couvrant la commune et tu comprendras mieux. >>>> >>>> NB: c'est toi qui a créé ces relations? >>>> Le 15 oct. 2014 11:06, "Jérôme Seigneuret" <jseigneuret-...@yahoo.fr> >>>> a écrit : >>>> >>>> Les zones dont tu parles pour moi c'est pas du boundary, c'est du >>>>> découpage cadastre des lieu-dits (voisinage dans un village ou quartier en >>>>> ville ou hameau) En principe moi je fais juste un noeud toponyme mais on >>>>> peu faire des zones toponymes et faire le lien vers le nom du contour >>>>> administratif en question. d'ailleurs c'est bizarre car aucun tracé n'est >>>>> fermé vu que le nom est sur le tracé.... >>>>> >>>>> on peut mettre un is_in=* pour lier avec le boundary de la commune >>>>> certains font des landuse= residential mais je trouve ça pourri pour >>>>> faire des toponymes. Moi je préfère juste faire comme ici : >>>>> http://www.openstreetmap.org/way/277831410 au pire ne pas mettre le >>>>> nom dans le polygone mais sur un noeud et les lier si besoin...(il y a >>>>> peut-être mieux) >>>>> >>>>> Le landuse est un autre objet pour moi. Mais je vais pas revenir sur >>>>> ça c'est pas le sujet. >>>>> >>>>> Pour réparer moi je fais ça dans JOSM en important que le tronçon >>>>> boundary en question par son id et en important uniquement les relations. >>>>> Après en cas de problèmes JOSM demande de corriger les incohérence avant >>>>> de >>>>> faire la sauvegarde. J'avais fait une connerie de ce type sur Montpellier. >>>>> J'ai juste refermé le way et fini. >>>>> >>>>> En même temps iD fou un peu la merde: >>>>> Si tu coupes un polygon pour en faire deux il coupe toute les >>>>> relations et ça ressemble un peu à ce que tu présentes. >>>>> >>>>> >>>>> >>>>> >>>>> Le 15 octobre 2014 10:14, Philippe Verdy <verd...@wanadoo.fr> a écrit >>>>> : >>>>> >>>>>> En tentant de corriger des erreurs de frontières incomplètes dans >>>>>> Osmose, je me suis aperçu que la Ferté-Macé (en Mayenne) est découpé dans >>>>>> ce qui ne ,e semble pas être des quartiers mais des noms de parcelles (ou >>>>>> groupes de parcelles). Y compris des parcelles homonymes et limitrophes >>>>>> l'une de l'autre. >>>>>> Les noms sont parfois des lieux-dits, ou des noms de rues. >>>>>> >>>>>> Exemple autour de ceci: >>>>>> >>>>>> http://www.openstreetmap.org/way/306246629 >>>>>> >>>>>> Le chemin est isolé mais la frontière n'est pas fermée (il n'est >>>>>> encore dans aucune relation mais a déjà un tag admin_level 10), et la >>>>>> commune n'est visiblement pas entièrement découpée, je ne vois pas >>>>>> comment >>>>>> corriger ces relations "administrative" pour les fermer correctement, et >>>>>> comment les retaguer correctement si ce n'est pas administratif. >>>>>> >>>>>> Pour l'instant je n'ai rien supprimé (ce tracé est tout demême >>>>>> complexe pour une seule commune), juste levé quelques anomalies >>>>>> géométriques pour vérifier la cohérence de ce découpage dont la >>>>>> classification reste tout de même à revoir si on doit garder ce découpage >>>>>> pour une certaine utilité (il ne me semble pas qu'il soi approprié pour >>>>>> les >>>>>> lieux-dits). Je me demande d'où ce découpage est issu : est-ce que c'est >>>>>> le >>>>>> découpage des zones cadastrales ? L'auteur comptait-il poursuivre ensuite >>>>>> avec les parcelles individuelles ? >>>>>> >>>>>> Jusqu'à présent on utilisait le niveau 9 pour les arrondissements de >>>>>> Paris Lyon Marseille o pour les communes associées au sein d'une même >>>>>> commune; le niveau 10 pour des quartiers réels, mais pas pour un >>>>>> découpage >>>>>> quasi parcellaire comme ici. >>>>>> >>>>>> Note: je ne m'adresse pas spécifiquement à cet auteur (il peut >>>>>> s'exprimer; je ne lui tape pas dessus et il peut avoir des intentions >>>>>> louables), si sur le fait que ce découpage soit incomplet, mais juste sur >>>>>> la question de la pertinence de ces données (pérennité, adéquation à une >>>>>> utilisation par exemple pour des plans immobiliers) et surtout de leur >>>>>> classification, pour que cela ne nuise pas aux autres utilisations des >>>>>> données (j'ai peur que ça pollue les recherches de Nominatim par exemple, >>>>>> ou que cela nuise à la recherche d'adresses et lieux-dits, liée au projet >>>>>> BANO). >>>>>> >>>>>> Le risque de conserver ce découpage au niveau admin 10 c'est la >>>>>> confusion qui pourrait naitre du fait de l'association de communes >>>>>> voisines, ou d'une réelle division administrative pour les services >>>>>> intercommunaux (comme à Nantes avec ses "pôles de proximité" au sein de >>>>>> la >>>>>> métropole) qui sera nettement plus utile à mon avis. >>>>>> >>>>>> Si cela représente des zones cadastrales, cela pourrait être utile à >>>>>> plus grande échelle mais je pense qu'avant ça on aimerait plutôt avoir >>>>>> d'abord le découpage INSEE des IRIS (les deux projets ne sont pas >>>>>> incompatibles et peuvent coexister), à condition de décider des bons >>>>>> tags à >>>>>> utiliser: >>>>>> >>>>>> En Espagne ils ont des découpages sous-communaux très détaillés pour >>>>>> les "unités de population" (traduction approchante, le terme exact varie >>>>>> selon les communautés autonomes ou villes), et ça sert de brique de base >>>>>> pour les statistiques économiques, les découpages électoraux (par exemple >>>>>> bureaux de vote) ou la fiscalité locale (taux d'imposition foncière ou >>>>>> locative), les plans et règlements d'urbanisme, la gestion des réseaux >>>>>> publics et des ressources... >>>>>> >>>>>> En France on a encore du mal avec >>>>>> - les IRIS dont l'usage est encore mal maitrisé >>>>>> (boundary=statistical)- On aimerait avoir des données exploitables >>>>>> dessus. >>>>>> - le découpage pour les opérations électorales des bureaux de vote >>>>>> (boundary=electoral) >>>>>> - le zonage urbain légal (celui qui définit les limites >>>>>> d'agglomérations selon les distances maximales entre bâtiments et au delà >>>>>> les poles urbains; boundary=urban?), >>>>>> - les bassins d'emploi (pas nécessairement les mêmes découpages que >>>>>> les intercommunalités et syndicats mixtes) >>>>>> la carte scolaire publique, le zonage des services sociaux et >>>>>> médico-hospitalier, le >>>>>> - le découpage judiciaire des tribunaux (boundary=judiciary, comme en >>>>>> Belgique), >>>>>> - le découpage des secteurs de police (révisé avec police et >>>>>> gendarmerie, plus fin que le découpage judiciaire avec des secteurs sur >>>>>> plusieurs secteurs judiciaires) >>>>>> - les régions de défense nationale (boundary=military), >>>>>> - le découpage civil des régions aériennes autour des centres de >>>>>> contrôle aérien (boundary=aerial?), >>>>>> - les limites de compétence des ports autonomes (définis par décret >>>>>> depuis 1961, étendus vers 2003, et indépendant des intercommunalités), >>>>>> - les zones franches (quel tags?) >>>>>> - etc. >>>>>> >>>>>> Et tout ça bien avant le découpage historique des anciennes planches >>>>>> cadastrales (pour ensuite y numéroter les parcelles et le calcul des >>>>>> taxes >>>>>> foncières ou la gestion des domaines publics locaux ou nationaux, ou la >>>>>> gestion des concessions publiques au privé; y compris les mines, forages >>>>>> et >>>>>> conduites de transport d'eau et d'énergie) d'avant leur numérisation (OSM >>>>>> n'ayant pas vocation non plus à remplacer le cadastre pour ses aspects >>>>>> légaux et réglementaires dans des opérations de cession immobilière, les >>>>>> successions, la fiscalité, les plans d'urbanisme légaux et les permis de >>>>>> construire, la délimitation officielle des zones à risque ou secteurs >>>>>> protégés; les plans de pêche ou de chasse, etc.) >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > >
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
