[OSM-talk-fr] Limites administratives ?
Jaimerais marquer les limites de ma ville, mais je ne suis pas sur de la méthode. Les features ne parlent que dun area, sans détailler. Jai entendu parler ça et la de relations pour cet usage, mais les documents que jai trouvés ne semblent pas trop finalisés. Y a-t-il un usage recommandé actuellement ? Des exemples réalisés qui fonctionnent ? Ou vaut-il mieux attendre que la question se stabilise ? Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives
Bonjour, Sur le site : http://cadastre.cleo-carto.org/ http://cadastre.cleo-carto.org/ Il me semble qu'il manque des communes dans la liste pour le Maine et Loire Armaillé, Carbay, etc... Est-ce une erreur ou faut-il attendre une mise à jour ? Merci, -- View this message in context: http://gis.638310.n2.nabble.com/Limites-administratives-tp6732564p6732564.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives
Bonjour, Si j'ai bien compris pour les limites administratives - Un lien peut être tagé (admin_level=x, et boundary=administrative) - Une relation qui contient ce lien pareil (admin_level=x, et boundary=administrative) Il y a 2 fois le tag admin_level (Une fois de trop pour le lien?) Pour être correct il faut que l' admin_level du lien soit la plus petite valeur de toutes ses relations. Existe-il un outil pour controler cette erreur possible. -- View this message in context: http://n2.nabble.com/Limites-administratives-tp4007087p4007087.html Sent from the French OSM list mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives
Bonjour, Depuis aujourd'hui, la page de suivi des limites de communes [1] affiche 100% d'avancement pour les communes au format vecteur. Bravo à toutes les fourmis qui ont participé et qui participeront à l'ajout des communes restantes ! [1] http://beta.letuffe.org/cron/etat-communes/communes.csv.txt -- ab_fab ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ?
C'est "boundary" : http://wiki.openstreetmap.org/index.php/Fr:Key:boundary Je l'ai créé sur Tours récemment : http://www.openstreetmap.org/?lat=47.3989&lon=0.6939&zoom=13&layers=B00FTF Pour les relations ce n'est utile qu'à partir du moment où une limite est partagée avec une autre. 2008/8/21 leblatt <[EMAIL PROTECTED]>: > J'aimerais marquer les limites de ma ville, mais je ne suis pas sur de la > méthode. Les features ne parlent que d'un area, sans détailler. > > J'ai entendu parler ça et la de relations pour cet usage, mais les documents > que j'ai trouvés ne semblent pas trop finalisés. > > Y a-t-il un usage recommandé actuellement ? Des exemples réalisés qui > fonctionnent ? > > Ou vaut-il mieux attendre que la question se stabilise ? > > Merci. > > ___ > 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] Limites administratives ?
Pardon, j'oubliais de préciser : la ville est côtière (La Seyne), donc du coup limite nationale. Pas d'incidence ? > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:talk-fr- > [EMAIL PROTECTED] De la part de murphy2712.nospam Envoyé : > jeudi 21 août 2008 17:58 À : Discussions sur OSM en français Objet : > Re: [OSM-talk-fr] Limites administratives ? > > (...) > Pour les relations ce n'est utile qu'à partir du moment où une limite > est partagée avec une autre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ?
Créez un way admin_level=2 boundary=administrative pour la limite nationale, admin_level 8 pour la limite de la commune. Et ajoutez cette ways a une nouveau relation boundary=administrative name=La Seyne admin_level=8. Ajoutez le limite nationale a la relation France id:11980 http://www.openstreetmap.org/browse/relation/11980. Exemples ici: http://www.openstreetmap.org/?lat=42.43646&lon=3.17498&zoom=16&layers=B00FTF 2008/8/21 leblatt <[EMAIL PROTECTED]> > Pardon, j'oubliais de préciser : la ville est côtière (La Seyne), donc du > coup limite nationale. Pas d'incidence ? > > > -Message d'origine- > > De : [EMAIL PROTECTED] [mailto:talk-fr- > > [EMAIL PROTECTED] De la part de murphy2712.nospam Envoyé : > > jeudi 21 août 2008 17:58 À : Discussions sur OSM en français Objet : > > Re: [OSM-talk-fr] Limites administratives ? > > > > (...) > > Pour les relations ce n'est utile qu'à partir du moment où une limite > > est partagée avec une autre. > > > > ___ > 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] Limites administratives ?
Merci, je regarde tout ça. Pour linstant je trace les ways nécessaires (coastline à affiner, et 4 villes limitrophes). De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Skywave Envoyé : jeudi 21 août 2008 18:24 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Limites administratives ? Créez un way admin_level=2 boundary=administrative pour la limite nationale, admin_level 8 pour la limite de la commune. Et ajoutez cette ways a une nouveau relation boundary=administrative name=La Seyne admin_level=8. Ajoutez le limite nationale a la relation France id:11980 http://www.openstreetmap.org/browse/relation/11980. Exemples ici: http://www.openstreetmap.org/?lat=42.43646 <http://www.openstreetmap.org/?lat=42.43646&lon=3.17498&zoom=16&layers=B00FT F> &lon=3.17498&zoom=16&layers=B00FTF 2008/8/21 leblatt <[EMAIL PROTECTED]> Pardon, j'oubliais de préciser : la ville est côtière (La Seyne), donc du coup limite nationale. Pas d'incidence ? > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:talk-fr- > [EMAIL PROTECTED] De la part de murphy2712.nospam Envoyé : > jeudi 21 août 2008 17:58 À : Discussions sur OSM en français Objet : > Re: [OSM-talk-fr] Limites administratives ? > > (...) > Pour les relations ce n'est utile qu'à partir du moment où une limite > est partagée avec une autre. ___ 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] Limites administratives ?
Je reprends ce sujet pour soulever un point précis : quelles sont les limites d'une agglomération ? En général, d'après ce que j'ai noté, dans une commune (boundary level = 8), il y a un village principal (du nom de la commune ; c'est une agglomération), des lieux-dits (hameaux, ...), et parfois d'autres petits villages. Par village / agglomération, j'entends que : - il y a un panneau à l'entrée encadré en rouge - la limite de vitesse est de 50 km/h. - parfois (souvent ?), les routes sont refaites jusqu'à l'entrée du village (panneau). La limite est très claire sur le terrain. Mais je n'ai trouvé nulle part de définition de l'agglomération. Je n'ai pas précisément regardé les limites cadastrales, il y a peut-être un truc de ce côté. C'est important, à mon avis, de marquer les agglomérations, et ça mérite un "boundary level = 9 ou 10". Sur les cartes, l'agglomération apparaît dans une couleur différente. A propos des noms de rues : imaginons que je cherche la "Rue de la Mairie" dans un village : les agglomérations ont des noms de rues uniques ; les lieux-dits sont uniques pour la commune ; mais je pense que deux villages d'une même commune peuvent avoir les mêmes noms de rues. A fortiori, les "Rues de la Mairie" se comptent par millier en France. Il faut donc que la rue soit identifiée de façon unique. Deux possibilités : - soit définir les noms de villages en même temps que les rues (Name=Rue de la Mairie ; City=Brie-Comte-Robert), soit précisément les limites des communes et des agglomérations. - soit tracer la limite de la commune, et celle de l'agglomération ; puis il faudra qu'un logiciel prenne les rues les unes après les autres et cherche dans quelle zone elles sont, pour différentier les milliers de "rues de la mairie" en France. Encore un mot : on pourrait songer à tracer les Agglomérations comme des Zones (Area) avec un landuse = village. Mais dans ce cas, il faudrait superposer les landuse pour que le cimetière apparaisse "au-dessus" du tracé du village, etc. Bref, il faut : - définir une boudary_level pour les agglomérations - définir un moyen de préciser les rues / villes. - Mail Original - De: "leblatt" <[EMAIL PROTECTED]> À: "Discussions sur OSM en français" Envoyé: Jeudi 21 Août 2008 18:45:23 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Limites administratives ? Merci, je regarde tout ça. Pour l’instant je trace les ways nécessaires (coastline à affiner, et 4 villes limitrophes). De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Skywave Envoyé : jeudi 21 août 2008 18:24 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Limites administratives ? Créez un way admin_level=2 boundary=administrative pour la limite nationale, admin_level 8 pour la limite de la commune. Et ajoutez cette ways a une nouveau relation boundary=administrative name=La Seyne admin_level=8. Ajoutez le limite nationale a la relation France id:11980 http://www.openstreetmap.org/browse/relation/11980 . Exemples ici: http://www.openstreetmap.org/?lat=42.43646&lon=3.17498&zoom=16&layers=B00FTF 2008/8/21 leblatt < [EMAIL PROTECTED] > Pardon, j'oubliais de préciser : la ville est côtière (La Seyne), donc du coup limite nationale. Pas d'incidence ? > -Message d'origine- > De : [EMAIL PROTECTED] [mailto: talk-fr- > [EMAIL PROTECTED] ] De la part de murphy2712.nospam Envoyé : > jeudi 21 août 2008 17:58 À : Discussions sur OSM en français Objet : > Re: [OSM-talk-fr] Limites administratives ? > > (...) > Pour les relations ce n'est utile qu'à partir du moment où une limite > est partagée avec une autre. ___ 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ?
Charlie Echo a écrit : > Je reprends ce sujet pour soulever un point précis : quelles sont les limites > d'une agglomération ? Une agglomération n'est pas une entité administrative, difficile d'en tracer des limites incontestables. > > En général, d'après ce que j'ai noté, dans une commune (boundary level = 8), > il y a un village principal (du nom de la commune ; c'est une agglomération), > des lieux-dits (hameaux, ...), et parfois d'autres petits villages. > Par village / agglomération, j'entends que : > - il y a un panneau à l'entrée encadré en rouge > - la limite de vitesse est de 50 km/h. > - parfois (souvent ?), les routes sont refaites jusqu'à l'entrée du village > (panneau). La limite est très claire sur le terrain. Une commune est une entité administrative gérée par un élu (le maire). Son périmètre, le plus généralement, est établi par consensus avec les données cadastrales (en clair : la commune est constituée d'un ensemble de parcelles cadastrales). Il y a possibilité de constestation à la limite, car ces données n'ont pas de valeur juridique. Et donc, il arrive que des commmunes s'échangent des hectares entiers de domaine communal (quand bien même aucune des communes ne serait propriétaire du territoire contesté) > > Mais je n'ai trouvé nulle part de définition de l'agglomération. Je n'ai pas > précisément regardé les limites cadastrales, il y a peut-être un truc de ce > côté. > C'est important, à mon avis, de marquer les agglomérations, et ça mérite un > "boundary level = 9 ou 10". > Sur les cartes, l'agglomération apparaît dans une couleur différente. La seule notion d'agglomération que je connaisse est celle qu'en donne l'INSEE pour définir les unités urbaines (entités potentiellement supra-communales). C'est ici : http://www.insee.fr/fr/methodes/default.asp?page=definitions/unite-urbaine.htm > > A propos des noms de rues : imaginons que je cherche la "Rue de la Mairie" > dans un village : les agglomérations ont des noms de rues uniques ; les > lieux-dits sont uniques pour la commune ; mais je pense que deux villages > d'une même commune peuvent avoir les mêmes noms de rues. A fortiori, les > "Rues de la Mairie" se comptent par millier en France. > > Il faut donc que la rue soit identifiée de façon unique. > Deux possibilités : > - soit définir les noms de villages en même temps que les rues (Name=Rue de > la Mairie ; City=Brie-Comte-Robert), soit précisément les limites des > communes et des agglomérations. > - soit tracer la limite de la commune, et celle de l'agglomération ; puis il > faudra qu'un logiciel prenne les rues les unes après les autres et cherche > dans quelle zone elles sont, pour différentier les milliers de "rues de la > mairie" en France. > > Encore un mot : on pourrait songer à tracer les Agglomérations comme des > Zones (Area) avec un landuse = village. Mais dans ce cas, il faudrait > superposer les landuse pour que le cimetière apparaisse "au-dessus" du tracé > du village, etc. > > Bref, il faut : > - définir une boudary_level pour les agglomérations > - définir un moyen de préciser les rues / villes. Non, il faut définir une limite communale (à l'aide de données cadastrales quand c'est possible -> je pense, entre autres, au plug-in JOSM de Pieren). La toponymie de la voirie est du ressort du maire (on parle des voies communales, mais aussi des voies départementales ou nationales qui traversent le ban communal). Le tracage de l'agglomération de zones bâties est une autre chose, utile aussi (tag landuse=residential). Pour distinguer 2 rues de la Mairie (ou de la république), seule la limite communale fera foi. Dans le même temps, voici un exemple réel pour présenter la complexité du problème de toponymie des voies (ce n'est pas l'exmple le + complexe, mais, c'est juste à côté de chez moi ;-) : - sur le ban communal de Strasbourg, la Route Départementale "D 31" (attention à l'espace ;-) se nomme "Route de Mittelhausbergen" sur toute sa longueur ; - sur le ban communal d'Oberhausbergen (dont le continuum bâti échappe aux règles d'agglomération de l'INSEE au niveau de cette voie), cette même voie se nomme "Route de Strasbourg" (toujours D 31, par contre) ; - sur le ban communal de Mittelhausbergen (commune mitoyenne de la précédente), cette RD 31 se nomme "Route de Strasbourg" sur une partie et "Rue de la Côte" sur une autre. En résumé, aucun salut hors de la visite terrain (éventuellement et préalablement anticipée par la lecture de documents officiels -> plans de la commune, plans cadastraux, etc.) Les lieux sont tout sauf communs. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ?
2008/8/23 Charlie Echo <[EMAIL PROTECTED]>: > mais je pense que deux villages d'une même commune peuvent avoir les mêmes > noms de rues. Je ne crois pas. C'était le cas par le passé mais je connais un exemple concret où le nom d'une rue en double sur une "agglomération" comme tu dis, a été changé il y a 20 ans, parce qu'il y avait trop de problèmes d'erreurs d'adresses (routage poste, impôts, etc). > > Il faut donc que la rue soit identifiée de façon unique. > Deux possibilités : > - soit définir les noms de villages en même temps que les rues (Name=Rue de > la Mairie ; City=Brie-Comte-Robert), aïe aïe, il y a le tag "is_in" qui a été créé dans cette idée là > soit précisément les limites des communes et des agglomérations. > - soit tracer la limite de la commune, et celle de l'agglomération ; puis il > faudra qu'un logiciel prenne les rues les unes après les autres et cherche > dans quelle zone elles sont, pour différentier les milliers de "rues de la > mairie" en France. > Je crois que c'est la meilleure solution. Moi je distingue l'administratif (le tag boudary=administrative) avec comme unique source possible pour nous (pour l'instant, et encore, peut-être plus pour longtemps), le cadastre qui fixe les limites de la commune sur la planche "vue d'ensemble" par exemple. Et la limite physique avec un polygone fermé tagué landuse=residential et name=nom_de_la_ville quand c'est effectivement la zone résidentielle. Sinon landuse=industrial, commercial, etc... pour les autres types de zones. Il sera alors possible qu'à l'intérieur d'un polygone "boudary=administrative", il y ait plusieurs zones marquées en residential, une pour le village principal, et d'autres pour chaque lieu-dit important ou "sous-commune" rattachée (pour ceux-là, il m'arrive d'utiliser le tag place=suburb). Pour le cimetière, c'est un cas particulier. En fait, il y a eu des plaintes de gens qui trouvaient qu'utiliser landuse pour un cimetière était inapproprié. Heureusement, les renderers tiennent compte de ce cas particulier et le cimetière apparait normalement à l'intérieur d'un autre landuse même s'il n'y a pas de tag layer. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ?
Ok, bonnes réponses ; je les adopte. Pour les communes, je faisais ça jusqu'ici. Il reste à clarifier une chose : j'avais commencé à faire des communes avec des "left / right", et je suis passé aux "relations", qui, au fond, sont plus intelligentes. Or il y a eu un mail récemment sur ce sujet, qui préconnisait les "left/right". Donc il faudrait clarifier cette situation, à mon avis. (en fait, c'est plutôt une question : tolère-t-on deux systèmes ou bien faut-il uniformiser ?) Reste la question "mathématique" de l'art et de la manière de savoir si un point est DANS une zone. Il faudrait que je creuse ça... Merci pour vos éléments ! - Mail Original - De: "Pieren" <[EMAIL PROTECTED]> À: "Discussions sur OSM en français" Envoyé: Samedi 23 Août 2008 23:13:26 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Limites administratives ? 2008/8/23 Charlie Echo <[EMAIL PROTECTED]>: > mais je pense que deux villages d'une même commune peuvent avoir les mêmes > noms de rues. Je ne crois pas. C'était le cas par le passé mais je connais un exemple concret où le nom d'une rue en double sur une "agglomération" comme tu dis, a été changé il y a 20 ans, parce qu'il y avait trop de problèmes d'erreurs d'adresses (routage poste, impôts, etc). > > Il faut donc que la rue soit identifiée de façon unique. > Deux possibilités : > - soit définir les noms de villages en même temps que les rues (Name=Rue de > la Mairie ; City=Brie-Comte-Robert), aïe aïe, il y a le tag "is_in" qui a été créé dans cette idée là > soit précisément les limites des communes et des agglomérations. > - soit tracer la limite de la commune, et celle de l'agglomération ; puis il > faudra qu'un logiciel prenne les rues les unes après les autres et cherche > dans quelle zone elles sont, pour différentier les milliers de "rues de la > mairie" en France. > Je crois que c'est la meilleure solution. Moi je distingue l'administratif (le tag boudary=administrative) avec comme unique source possible pour nous (pour l'instant, et encore, peut-être plus pour longtemps), le cadastre qui fixe les limites de la commune sur la planche "vue d'ensemble" par exemple. Et la limite physique avec un polygone fermé tagué landuse=residential et name=nom_de_la_ville quand c'est effectivement la zone résidentielle. Sinon landuse=industrial, commercial, etc... pour les autres types de zones. Il sera alors possible qu'à l'intérieur d'un polygone "boudary=administrative", il y ait plusieurs zones marquées en residential, une pour le village principal, et d'autres pour chaque lieu-dit important ou "sous-commune" rattachée (pour ceux-là, il m'arrive d'utiliser le tag place=suburb). Pour le cimetière, c'est un cas particulier. En fait, il y a eu des plaintes de gens qui trouvaient qu'utiliser landuse pour un cimetière était inapproprié. Heureusement, les renderers tiennent compte de ce cas particulier et le cimetière apparait normalement à l'intérieur d'un autre landuse même s'il n'y a pas de tag layer. 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] Limites administratives ?
En fait, je ne suis pas géomaticien et d'autres pourraient mieux répondre que moi mais il existe des modules pour bases de données qui fournissent des librairies de fonctions géographiques telles que "voir si un point est à l'intérieur d'une zone". Mapnik utilise postGIS, le module géospatial pour postgresql. Il est donc très facile d'obtenir ce genre d'info pour un logiciel, à condition d'avoir ce type de bdd. Or les données brutes d'OSM sont dans une base simple (mysql). Il faut donc migrer les données géospatiales dans une nouvelle base organisée différemment. C'est ce que fait le script osm2pqsql, dévellopé pour mapnik mais qui peut servir à d'autres usages. Pieren 2008/8/24 Charlie Echo <[EMAIL PROTECTED]>: > Ok, bonnes réponses ; je les adopte. > Pour les communes, je faisais ça jusqu'ici. > > Il reste à clarifier une chose : j'avais commencé à faire des communes avec > des "left / right", et je suis passé aux "relations", qui, au fond, sont plus > intelligentes. Or il y a eu un mail récemment sur ce sujet, qui préconnisait > les "left/right". Donc il faudrait clarifier cette situation, à mon avis. (en > fait, c'est plutôt une question : tolère-t-on deux systèmes ou bien faut-il > uniformiser ?) > > Reste la question "mathématique" de l'art et de la manière de savoir si un > point est DANS une zone. Il faudrait que je creuse ça... > > Merci pour vos éléments ! > > > - Mail Original - > De: "Pieren" <[EMAIL PROTECTED]> > À: "Discussions sur OSM en français" > Envoyé: Samedi 23 Août 2008 23:13:26 GMT +01:00 Amsterdam / Berlin / Berne / > Rome / Stockholm / Vienne > Objet: Re: [OSM-talk-fr] Limites administratives ? > > 2008/8/23 Charlie Echo <[EMAIL PROTECTED]>: >> mais je pense que deux villages d'une même commune peuvent avoir les mêmes >> noms de rues. > > Je ne crois pas. C'était le cas par le passé mais je connais un > exemple concret où le nom d'une rue en double sur une "agglomération" > comme tu dis, a été changé il y a 20 ans, parce qu'il y avait trop de > problèmes d'erreurs d'adresses (routage poste, impôts, etc). > >> >> Il faut donc que la rue soit identifiée de façon unique. >> Deux possibilités : >> - soit définir les noms de villages en même temps que les rues (Name=Rue de >> la Mairie ; City=Brie-Comte-Robert), > aïe aïe, il y a le tag "is_in" qui a été créé dans cette idée là > >> soit précisément les limites des communes et des agglomérations. >> - soit tracer la limite de la commune, et celle de l'agglomération ; puis il >> faudra qu'un logiciel prenne les rues les unes après les autres et cherche >> dans quelle zone elles sont, pour différentier les milliers de "rues de la >> mairie" en France. >> > > Je crois que c'est la meilleure solution. > Moi je distingue l'administratif (le tag boudary=administrative) avec > comme unique source possible pour nous (pour l'instant, et encore, > peut-être plus pour longtemps), le cadastre qui fixe les limites de la > commune sur la planche "vue d'ensemble" par exemple. > Et la limite physique avec un polygone fermé tagué landuse=residential > et name=nom_de_la_ville quand c'est effectivement la zone > résidentielle. Sinon landuse=industrial, commercial, etc... pour les > autres types de zones. > Il sera alors possible qu'à l'intérieur d'un polygone > "boudary=administrative", il y ait plusieurs zones marquées en > residential, une pour le village principal, et d'autres pour chaque > lieu-dit important ou "sous-commune" rattachée (pour ceux-là, il > m'arrive d'utiliser le tag place=suburb). > Pour le cimetière, c'est un cas particulier. En fait, il y a eu des > plaintes de gens qui trouvaient qu'utiliser landuse pour un cimetière > était inapproprié. Heureusement, les renderers tiennent compte de ce > cas particulier et le cimetière apparait normalement à l'intérieur > d'un autre landuse même s'il n'y a pas de tag layer. > 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 > ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ?
Charlie Echo a écrit : > Ok, bonnes réponses ; je les adopte. > Pour les communes, je faisais ça jusqu'ici. Une discussion intéressante sur des limites communales libres ici : http://georezo.net/forum/viewtopic.php?id=56371&action=new suite à une autre discussion là : http://georezo.net/forum/viewtopic.php?id=56111&action=new Je vais replonger dans les archives de la liste sur l'utilisation des données cadastrales et tenter de faire une nouvelle proposition de questionnement à la DGI qui pourrait être portée par OSM, GeoRezo et le chapitre francophone de l'OS-Geo. Il faut juste trouver du temps. Visiblement les attentes et les besoins sont partagées Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ?
Pieren a écrit : > En fait, je ne suis pas géomaticien et d'autres pourraient mieux > répondre que moi mais il existe des modules pour bases de données qui > fournissent des librairies de fonctions géographiques telles que "voir > si un point est à l'intérieur d'une zone". Mapnik utilise postGIS, le > module géospatial pour postgresql. Il est donc très facile d'obtenir > ce genre d'info pour un logiciel, à condition d'avoir ce type de bdd. > Or les données brutes d'OSM sont dans une base simple (mysql). Il faut > donc migrer les données géospatiales dans une nouvelle base organisée > différemment. C'est ce que fait le script osm2pqsql, dévellopé pour > mapnik mais qui peut servir à d'autres usages. > Pieren Oui, je confirme : PostGIS dispose de toutes les fonctions utiles pour répondre à ce genre de questions. Au passage, osm2pgsql ne me plait pas trop. Je travaille à une manière d'alimenter une base OSM sous PostGIS à partir de scripts osmosis, de feuilles de style xslt, etc. C'est assez intéressant quoique pas abouti encore maintenant (j'essaie de prendre en charge l'historique des données). Des nouvelles bientôt j'espère Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 27/08/2011 19:11, Jero a écrit : Bonjour, Sur le site : http://cadastre.cleo-carto.org/ http://cadastre.cleo-carto.org/ Il me semble qu'il manque des communes dans la liste pour le Maine et Loire Armaillé, Carbay, etc... Est-ce une erreur ou faut-il attendre une mise à jour ? Le Cadastre n'a pas encore numérisé toutes les communes de France. Actuellement on doit être à +/- 50 % de communes, ce pourcentage étant très variable d'un département à l'autre (certains sont à 100 %, d'autres très peu numérisés). Yapluka attendre... -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
il manque bien des communes vectorielles, certes c'est très récent... -- View this message in context: http://gis.638310.n2.nabble.com/Limites-administratives-tp6732564p6733041.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
2009/11/15 Jero : > Existe-il un outil pour controler cette erreur possible. > -- Pas à ma connaissance, Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Pieren a écrit : > 2009/11/15 Jero : >> Existe-il un outil pour controler cette erreur possible. > > Pas à ma connaissance, Idem. Mais si quelqu'un écrit un script qui lit un .osm et l'analyse, on peut le rajouter à moindres frais à osmose. Je regarde si c'est long à faire. -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 15 novembre 2009 10:14, Jero a écrit : > > Bonjour, > > Si j'ai bien compris pour les limites administratives > - Un lien peut être tagé (admin_level=x, et boundary=administrative) > - Une relation qui contient ce lien pareil (admin_level=x, et > boundary=administrative) > Il y a 2 fois le tag admin_level (Une fois de trop pour le lien?) > Pour être correct il faut que l' admin_level du lien soit la plus petite > valeur de toutes ses relations. La plus petite, ou la plus grande ? Est-ce qu'on considère que c'est la limite de commune qui porte aussi la limite de département (, région, pays, ...) , ou que la (pôvre petite) commune est bien obligé de s'arrêter à la limite de département (région, pays) ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Art Penteur a écrit : > Le 15 novembre 2009 10:14, Jero a écrit : >> Bonjour, >> >> Si j'ai bien compris pour les limites administratives >>- Un lien peut être tagé (admin_level=x, et boundary=administrative) >>- Une relation qui contient ce lien pareil (admin_level=x, et >> boundary=administrative) >> Il y a 2 fois le tag admin_level (Une fois de trop pour le lien?) >> Pour être correct il faut que l' admin_level du lien soit la plus petite >> valeur de toutes ses relations. > > La plus petite, ou la plus grande ? Est-ce qu'on considère que c'est > la limite de commune qui porte aussi la limite de département (, > région, pays, ...) , ou que la (pôvre petite) commune est bien obligé > de s'arrêter à la limite de département (région, pays) ? La plus petite : une limite de pays doit être taguée 2, même si elle est limite de région, commuune, département, canton, arrondissement... -- Etienne ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 23 novembre 2009 10:22, Etienne Chové a écrit : > > La plus petite : une limite de pays doit être taguée 2, même si elle est > limite de région, commuune, département, canton, arrondissement... Bon. C'est une convention comme une autre. Vais aller réparer qqunes de mes "erreurs", moi... Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Non, ce n'est pas qu'une convention. Et, pour le coup, je suis étonné que tu aies fait des erreurs. Une limite de Pays est aussi une limite de Région, de Département, etc. Une limite de Département n'est pas forcément une limite de Région, etc. Donc admin_level = 2 ==> admin_level =3, 4, 5, ... alors que admin_level = 5 n'implique rien quant aux levels 2, 3, 4. Charlie Echo - Mail Original - De: "Art Penteur" À: "Discussions sur OSM en français" Envoyé: Lundi 23 Novembre 2009 12:29:01 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] Limites administratives Le 23 novembre 2009 10:22, Etienne Chové a écrit : > > La plus petite : une limite de pays doit être taguée 2, même si elle est > limite de région, commuune, département, canton, arrondissement... Bon. C'est une convention comme une autre. Vais aller réparer qqunes de mes "erreurs", moi... Art. ___ 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] Limites administratives
Le 23 novembre 2009 14:23, Charlie Echo a écrit : > Non, ce n'est pas qu'une convention. Et, pour le coup, je suis étonné que tu > aies fait des erreurs. > > Une limite de Pays est aussi une limite de Région, de Département, etc. > Une limite de Département n'est pas forcément une limite de Région, etc. > > Donc admin_level = 2 ==> admin_level =3, 4, 5, ... > alors que admin_level = 5 n'implique rien quant aux levels 2, 3, 4. J'étais plus dans la logique : Le petit way local est inclus dans diverses relations. Chaque relation a un admin_level. Mais la seule chose vraiment spécifique au petit way local est d'être de type "boundary_administrative". Le admin_level est un peu arbitraire, et pourrait même être omis. J'avais perdu de vue l'implication logique admin_level = n ==> admin_level = n+m, pour tout m entier positif. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
On 04/02/2011 17:18, Ab_fab wrote: Bonjour, Depuis aujourd'hui, la page de suivi des limites de communes [1] affiche 100% d'avancement pour les communes au format vecteur. Bravo à toutes les fourmis qui ont participé et qui participeront à l'ajout des communes restantes ! [1] http://beta.letuffe.org/cron/etat-communes/communes.csv.txt -- ab_fab Donc si je comprends bien cela confirme que le Pas de Calais est un peu en vrac, et explique l'absence de limites administratives dans la vallée de la course, région d'Hesdin? en fait en travaillant ce coin avec JOSM j'avais l'impression que des limites n'étaient pas continues, faudrait les retracer avec le cadastre? David -- David White User #297763 on http://counter.li.org Jabber: dwh...@im.linux62.org OpenStreetMap Contributor DavidKW ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le vendredi 04 février 2011 à 17:41 +0100, David White a écrit : > On 04/02/2011 17:18, Ab_fab wrote: > > Bonjour, > > Depuis aujourd'hui, la page de suivi des limites de communes [1] affiche > > 100% d'avancement pour les communes au format vecteur. > > Bravo à toutes les fourmis qui ont participé et qui participeront à > > l'ajout des communes restantes ! > > [1] http://beta.letuffe.org/cron/etat-communes/communes.csv.txt > > -- > > ab_fab > > > > Donc si je comprends bien cela confirme que le Pas de > Calais est un peu en vrac, et explique l'absence de limites > administratives dans la vallée de la course, région d'Hesdin? Mais Hesdin et Marconne, quel travail ! Quel talentueux contributeur ! Hein ? :-) > en fait en travaillant ce coin avec JOSM j'avais l'impression que des > limites n'étaient pas continues, faudrait les retracer avec le cadastre? S'il n'y a pas les limites, c'est souvent qu'il n'y a simplement pas le cadastre. Le Pas-de-Calais, c'est un peu le Far West pour les mappeurs du Nord … Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le vendredi 4 février 2011 17:18:54, Ab_fab a écrit : > Bonjour, > > Depuis aujourd'hui, la page de suivi des limites de communes [1] affiche > 100% d'avancement pour les communes au format vecteur. > Bravo à toutes les fourmis qui ont participé et qui participeront à l'ajout > des communes restantes ! > > [1] http://beta.letuffe.org/cron/etat-communes/communes.csv.txt Carrément, félicitations à tous ! Nous rentrons maintenant dans la phase plus délicate qui consiste à : - attendre que le cadastre en vectorise de nouvelles (mon outil réactualise la liste tous les 10 jours et j'en lance un autre manuellement qui transforme en gpx les nouvelles disponibles) - Passer par les plans vecteurs, mais ça c'est long et pénible ! Ceux qui veulent filer un coup de main, on ne rappellera jamais assez cette bonne documentation : http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives PS: On peut souvent se poser la question de l'utilité de disposer des contours de communes, qui ne sont pas tant intéressants en eux-même que ce qu'ils permettent pour segmenter le territoire. maposmatic pour tracer le plan d'une commune, nominatim qui cherche les rues présentes à l'intérieur d'une commune ou des outils de statistiques qui permettent de faire des calculs par commue... comme celui en préparation dont je laisse tout l'honneur à Frédéric de le présenter prochainement... -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Bonsoir, Le 04/02/2011 18:02, Philippe Pary a écrit : > Le vendredi 04 février 2011 à 17:41 +0100, David White a écrit : >> en fait en travaillant ce coin avec JOSM j'avais l'impression que des >> limites n'étaient pas continues, faudrait les retracer avec le >> cadastre? En voilà une bonne idée ! > > S'il n'y a pas les limites, c'est souvent qu'il n'y a simplement pas > le cadastre. Pas le cadastre *vectoriel*, mais les planches raster existent, heureusement. On en parle par ici : http://wiki.openstreetmap.org/wiki/FR:JOSM/Fr:Plugin/Cadastre-fr#Utilisation_pour_les_communes_au_format_image Le 04/02/2011 19:23, sylvain letuffe a écrit : Nous rentrons maintenant dans la phase plus délicate qui consiste à : - attendre que le cadastre en vectorise de nouvelles (mon outil réactualise la liste tous les 10 jours et j'en lance un autre manuellement qui transforme en gpx les nouvelles disponibles) - Passer par les plans vecteurs, mais ça c'est long et pénible ! Les plans *raster* (y'a des jours ou ça veut pas :-) ) Au rythme de la vectorisation [1], je continue de penser que ça vaut le coup de s'intéresser au format raster. C'est long, oui, mais on voit du pays. Ca a beau être en noir et blanc, avec parfois des pixels un peu grossiers et des mentions farfelues, c'est, je trouve, loin d'être pénible. Et quand on se creuse pour caler un plan, qui au final tombe 'pile', on a même le droit d'être content :-) vincent [1] : http://osm2.crans.org/munin/stats.db/departement/osm_commune_tous.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le vendredi 4 février 2011 19:23:14 sylvain letuffe, vous avez écrit : > Nous rentrons maintenant dans la phase plus délicate qui consiste à : > - attendre que le cadastre en vectorise de nouvelles (mon outil réactualise > la liste tous les 10 jours et j'en lance un autre manuellement qui > transforme en gpx les nouvelles disponibles) > - Passer par les plans vecteurs, mais ça c'est long et pénible ! Il reste aussi, il me semble de ce que j'ai compris dans d'anciennes discussions, à corriger/reprendre les limites de « Cartographes et associés ». -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Les plans *raster* (y'a des jours ou ça veut pas :-) ) Au rythme de la vectorisation [1], je continue de penser que ça vaut le coup de s'intéresser au format raster. C'est long, oui, mais on voit du pays. J'ai fini l'Isère qui possédait du raster déjà géoréférencé. J'ai vu qu'il manquait les limites de quelques communes dans un coin alors je me suis lancé. Mais de proche en proche, j'en ai découvert beaucoup plus. Les taches jaunes au sud de Grenoble et en direction de Lyon: http://beta.letuffe.org/?zoom=9&lat=45.23203&lon=5.886&layers=BFFFTF Déjà plusieurs dizaines d'heures de boulot pour ça. Ensuite, plein d'enthousiasme, je me suis dit que j'allais compléter la Drôme: http://beta.letuffe.org/?zoom=11&lat=44.5285&lon=5.13412&layers=BFFFTF Sauf que là, il n'y a presque rien de géoréférencé et très peu de données dans OSM permettant de caler les planches en bordure de commune. Quant à aller sur le terrain avec son GPS pour prendre des points de repère, c'est possible en théorie mais en pratique, c'est un boulot monstre. Franchement, là où le cadastre raster n'est pas au moins géoréférencé, ça ne me paraît réaliste de tracer les limites de commune à la main. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 04/02/2011 21:34, Eric SIBERT a écrit : Sauf que là, il n'y a presque rien de géoréférencé et très peu de données dans OSM permettant de caler les planches en bordure de commune. Quant à aller sur le terrain avec son GPS pour prendre des points de repère, c'est possible en théorie mais en pratique, c'est un boulot monstre. Franchement, là où le cadastre raster n'est pas au moins géoréférencé, ça ne me paraît réaliste de tracer les limites de commune à la main. D'accord là dessus. Il reste cependant l'option "de la dernière chance", qui consiste à tracer non sur les planches, mais sur les tableaux d'assemblage. A utiliser avec parcimonie, mais pour un premier niveau de maillage, qui sera à affiner par connaissance locale et/ou dispo future du cadastre vectoriel, c'est déjà ça. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
PS: On peut souvent se poser la question de l'utilité de disposer des contours de communes, qui ne sont pas tant intéressants en eux-même que ce qu'ils permettent pour segmenter le territoire. On n'imagine jamais les applications possibles de données géographiques... surtout quand c'est une base de données libre. Par exemple, je rêve d'une application qui à partir des coordonnées d'un point donne la commune d'appartenance. C'est pour la spéléo quand on réalise des inventaires de toutes les grottes/gouffres connus dans une région. En fait, techniquement, c'est déjà faisable pour les zones couvertes. Une petite appli pour aller chercher les extraits départementaux que fait Sly sur son serveur. Après, j'ai quelques doutes sur la qualité des limites communales fournies par le cadastre, surtout en montagne. Et certains lors des imports n'ont pas dû être perturbés lorsque les limites par chaque commune de part et d'autre ne collent pas. Sans parler des repères géodésique sur la crête sensée faire la limite mais en pratique bien loin dans OSM. J'ai peur que pour les grottes en pied de barre rocheuse avec la crête en sommet de barre comme limite communale, il y ait beaucoup de résultats erronés. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 04/02/2011 21:55, Eric SIBERT a écrit : On n'imagine jamais les applications possibles de données géographiques... surtout quand c'est une base de données libre. Par exemple, je rêve d'une application qui à partir des coordonnées d'un point donne la commune d'appartenance. C'est pour la spéléo quand on réalise des inventaires de toutes les grottes/gouffres connus dans une région. Après, j'ai quelques doutes sur la qualité des limites communales fournies par le cadastre, surtout en montagne. Et certains lors des imports n'ont pas dû être perturbés lorsque les limites par chaque commune de part et d'autre ne collent pas. Sans parler des repères géodésique sur la crête sensée faire la limite mais en pratique bien loin dans OSM. J'ai peur que pour les grottes en pied de barre rocheuse avec la crête en sommet de barre comme limite communale, il y ait beaucoup de résultats erronés. Et quand ils sortirent de l'autre côté de la grotte qu'ils entendirent 'Tiam riep shure", il sortit son GPS avec la carte OSM qui va bien et s'exlama fièrement : "Chérie, nous sommes à Saïgon". Sauf que le cadastre, là bas étant encore au format raster et pas très précis : ils étaient à Phnom Penh. (contexte de rédaction : retour de restaurant...) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Vincent de Chateau-Thierry a écrit , Le 04/02/2011 21:52: D'accord là dessus. Il reste cependant l'option "de la dernière chance", qui consiste à tracer non sur les planches, mais sur les tableaux d'assemblage. A utiliser avec parcimonie, mais pour un premier niveau de maillage, qui sera à affiner par connaissance locale et/ou dispo future du cadastre vectoriel, c'est déjà ça. C'est le raisonnement que j'avais fait il y a une quinzaine de jours; J'ai constaté de grands trous dans le maillage communal de la Haute garonne ; ça fait quand même désordre quand je m'adresse à des élus ; Je me suis aperçue que des communes étaient vectorisées (et importées dans osm, merci pinpin), et qu'elles formaient un sorte de cheminement de petit-poucet ; je pense que l'IGN a fait exprès pour faciliter le repèrage des autres communes ; bingo : j'ai donc utilisé . les tableaux d'assemblage (coche dans les préférences du plugin) . le bouton "j'utilise la souris" pour pointer des intersections de routes déjà cartographiées dans osm depuis bin, ou bien des points caractéristiques de limites de communes vectorielles déjà importées. J'ai pu ainsi compléter tout le nord de la haute-garonne en quelques jours. C'est amusant de voir la carte se reboucher, en temps quasi réel sur http://beta.letuffe.org/?layers=BFFFTF&zoom=10&lat=43.16754&lon=0.99812 Il n'y a pas beaucoup d'écarts entre les contours des différentes communes depuis les différentes feuilles ; à part quelques erreurs manifestes (portions de terrain en limite de commune mais n'appartenant ni à l'une, ni à l'autre !!! - Vu au moins deux fois). Le principal problème que je vois est le nombre très important de chemins ruraux figurant sue les feuilles cadastrales et, au vu de bing, complètement remis en culture par les agriculteurs : j'ai donc cessé de cartographier les chemins depuis le cadastre raster. Autre problème : les ruisseaux qui servent de repères à de nombreuses limites de communes, et dont les cours sinueux ont visiblement été massivement redressés par les agriculteurs riverains : nous avions déjà abordé cette question ici (cherchez le mot "marcaissone" dans votre filtre), mais je pensais qu'il s'agissait d'une anecdote très locale ; que nenni, la situation est très, très répandue ; on avait vu que ce sont les communes concernées qui décident des petites modifications de ce genre par des délibérations ; ok ; mais, pour la marcaissone, je n'ai trouvé aucune délib. Les deux parcelles impactées appartiennent au même propriétaire, et il semble bien que tout le monde s'en fiche. Bref, le cartographe doit maintenir deux "tracés" différents, un boundary=administrative et un waterway=stream. Bon we à tous, Hélène User:HelenePETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 5 février 2011 09:26, hpmt a écrit : > J'ai pu ainsi compléter tout le nord de la haute-garonne en quelques jours. > C'est amusant de voir la carte se reboucher, en temps quasi réel sur > http://beta.letuffe.org/?layers=BFFFTF&zoom=10&lat=43.16754&lon=0.99812 > A ce propos : J'ai vu : http://beta.letuffe.org/?layers=BFFFTF&zoom=12&lat=43.26437&lon=1.58383 et j'ai trouvé que la limite sud de Calmon semble vraiment tracé "à la hache" comparé aux autres limites de communes (la limite sud de Cintegabellle aussi, dans une moindre mesure). C'est vraiment comme ça sur le cadastre, ou c'est un reste d'anciens tracés (CA ou autres ) ? Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Complément à mon compte-rendu extensif du message précédent : L'autre GROS intérêt de l'import des limites des communes Est de la Haute-Garonne a été de donner un aspect bien plus présentable de cette limite Est du département : la version précédente provenait d'une base de données des US, et avait localement, ici et là, un aspect tout à fait rebutant en faisant changer de département des sections entières de communes ; des élus m'avaient fait la remarque en rigolant, et je m'était sentie en petite culotte. Là, ça va mieux, hein Bientôt la limite Ouest ? C'est l'hiver, vous n'avez pas envie de promener le Gps dans le boue et le verglas ? vous avez raison : une ou deux séances d'import de tableaux d'assemblage dans les coins où il y a déjà une ou deux communes vectorisées, et hop, . (pour l'instant je ne connais pas d'élus à l'ouest de la Haute-Garonne, mais bon ) Hélène User:HelenePETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Art Penteur a écrit , Le 05/02/2011 09:52: C'est vraiment comme ça sur le cadastre, ou c'est un reste d'anciens tracés (CA ou autres ) ? Pourquoi ne pas vérifier toi-même en chargeant le tableau d'assemblage ? Comme ça tu auras l'occasion de peaufiner si ça te semble nécessaire ? Hélène User:HelenePETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 5 février 2011 10:19, hpmt a écrit :
> Pourquoi ne pas vérifier toi-même en chargeant le tableau d'assemblage ?
> Comme ça tu auras l'occasion de peaufiner si ça te semble nécessaire ?
Parce que je suis incompétent en maniement des diverses forme
d'images tramées ("raster") et que je suis sur d'autres endroits en ce
moment.
J'ai encore des choses à faire en vectoriel avant d'apprendre tout ça.
Mon os du moment (choix du niveau de finesse entre plusieurs tracés
et sources) :
http://www.openstreetmap.org/?lat=43.43649&lon=2.61106&zoom=16&layers=M
Art.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
J'ajoute que c'était une demande en passant, au cours d'une discussion
informelle au comptoir du bar d'OSM-fr.
Si personne ne veut/peut/a le temps de/ répondre, ce n'est absolument pas grave.
Art.
Le 5 février 2011 12:11, Art Penteur a écrit :
> Le 5 février 2011 10:19, hpmt a écrit :
>
>> Pourquoi ne pas vérifier toi-même en chargeant le tableau d'assemblage ?
>> Comme ça tu auras l'occasion de peaufiner si ça te semble nécessaire ?
>
> Parce que je suis incompétent en maniement des diverses forme
> d'images tramées ("raster") et que je suis sur d'autres endroits en ce
> moment.
>
> J'ai encore des choses à faire en vectoriel avant d'apprendre tout ça.
>
> Mon os du moment (choix du niveau de finesse entre plusieurs tracés
> et sources) :
> http://www.openstreetmap.org/?lat=43.43649&lon=2.61106&zoom=16&layers=M
>
> Art.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Art Penteur a écrit , Le 05/02/2011 12:11: Mon os du moment (choix du niveau de finesse entre plusieurs tracés et sources) : http://www.openstreetmap.org/?lat=43.43649&lon=2.61106&zoom=16&layers=M En effet, ça interpelle ; J'ai chargé le cadastre du coin dans josm, et en effet si le ruisseau provient de l'import "qadastre" , qui lui-même prend ses infos dans le cadastre, pourquoi est-il si loin du dessin du ruisseau dans le cadastre ? Hélène User:HelenePETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Art Penteur a écrit , Le 05/02/2011 14:38: J'ajoute que c'était une demande en passant, au cours d'une discussion informelle au comptoir du bar d'OSM-fr. Si personne ne veut/peut/a le temps de/ répondre, ce n'est absolument pas grave. D'autant que ce bar est souvent assez silencieux ; on ne peut pas savoir combien on est à savourer un(e) petite-mousse/grand-crème au même moment ; parfois c'est le bocson, parfois le désert glacé ; bon, cartographions en lousdé si il faut . Hélène User:HelenePETIT ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Bonjour, Le 05/02/2011 14:53, hpmt a écrit : Art Penteur a écrit , Le 05/02/2011 12:11: Mon os du moment (choix du niveau de finesse entre plusieurs tracés et sources) : http://www.openstreetmap.org/?lat=43.43649&lon=2.61106&zoom=16&layers=M En effet, ça interpelle ; J'ai chargé le cadastre du coin dans josm, et en effet si le ruisseau provient de l'import "qadastre" , qui lui-même prend ses infos dans le cadastre, pourquoi est-il si loin du dessin du ruisseau dans le cadastre ? La limite des départements provient d'un vieil import, dit "Cartographes Associés", qui a un mérite, celui d'exister, mais aussi des inconvénients : peu précis, et avec une licence pas claire. Comme le rappelait Nicolas hier soir, ces limites sont vouées à disparaître, au fur et à mesure que nous savons comment les remplacer, grâce aux limites prises dans le cadastre. Ici, on a donc une limite communale détaillée et récente (ajoutée en janvier 20011), contre cette vieille limite. Pas trop donc de questions à se poser pour décider laquelle doit être gardée : c'est celle qui fait la limite de Lacabarede (way 94584678). Elle doit passer en admin_level=4, avec rattachement des relations des départements et régions. On coupe, on coud, on raccommode, bref, atelier couture :-) . S'il se trouve que cette limite est aussi le tracé d'un ruisseau, personnellement je le tracerais à part : un autre way, qui s'appuie sur les mêmes nodes, avec les tags du ruisseau et rien qu'eux. C'est la "proposition 2" sur cette page : http://wiki.openstreetmap.org/wiki/WikiProject_France/Limites_administratives/Tracer_les_limites_administratives#Limites_administratives_utilisant_des_.C3.A9l.C3.A9ments_physiques vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 05/02/2011 15:22, Vincent de Chateau-Thierry a écrit : Ici, on a donc une limite communale détaillée et récente (ajoutée en janvier 20011), Pardon, pas récente : future ;-) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 5 février 2011 15:22, Vincent de Chateau-Thierry a écrit : > > La limite des départements provient d'un vieil import, dit "Cartographes > Associés", qui[...] > > Ici, on a donc une limite communale détaillée et récente (ajoutée en janvier > 20011), contre cette vieille limite. Pas trop donc de questions à se poser > pour décider laquelle doit être gardée : c'est celle qui fait la limite de > Lacabarede (way 94584678). Elle doit passer en admin_level=4, avec > rattachement des relations des départements et régions. On coupe, on coud, > on raccommode, bref, atelier couture :-) . Pas si simple : Le way qui porte toutes les limites sauf lacabarede, et qui est moins détaillé, porte quand même un "source=cadastre". Et puis il est trop proche de la réalité pour être un tracé "CA". Je voudrais qd même le comparer avec le tracé cadastre de Ferrals-les-montagnes, pour trancher. Mais : dans les extraits vectoriels de cleo-carto.org, y'a pas de FC098-FERRALS-LES-MONTAGNES-city-limit.osm. Donc, faut le faire avec JOSM et le plugin cadastre, et ça va moins vite. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 05/02/2011 16:16, Vincent Pottier a écrit : Le 05/02/2011 15:22, Vincent de Chateau-Thierry a écrit : Ici, on a donc une limite communale détaillée et récente (ajoutée en janvier 20011), Pardon, pas récente : future ;-) -- FrViPofm Et pourtant, je ne sortais pas du resto :-) ... on doit servir de drôles de trucs au "comptoir du bar d'OSM-fr" ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 05/02/2011 16:22, Art Penteur a écrit : Le 5 février 2011 15:22, Vincent de Chateau-Thierry a écrit : La limite des départements provient d'un vieil import, dit "Cartographes Associés", qui[...] Ici, on a donc une limite communale détaillée et récente (ajoutée en janvier 20011), contre cette vieille limite. Pas trop donc de questions à se poser pour décider laquelle doit être gardée : c'est celle qui fait la limite de Lacabarede (way 94584678). Elle doit passer en admin_level=4, avec rattachement des relations des départements et régions. On coupe, on coud, on raccommode, bref, atelier couture :-) . Pas si simple : Le way qui porte toutes les limites sauf lacabarede, et qui est moins détaillé, porte quand même un "source=cadastre". Et puis il est trop proche de la réalité pour être un tracé "CA". Oui il est bien taggué source=cadastre, mais en l'occurence c'est franchement abusif, du moins en comparant avec les cadastres vectoriels de Lacabarede ou Ferral. Sur chaque commune, le tracé de la limite admin comme celui du cours d'eau sont très sinueux. Le "vieux" tracé d'OSM est quand même très simplifié / schématique par rapport. Pour la limite admin, le dilemme vient plutôt de la divergence de tracé d'une commune à l'autre, pour parler de la même frontière. Savoir qui a raison ? Aucune idée. Je voudrais qd même le comparer avec le tracé cadastre de Ferrals-les-montagnes, pour trancher. Mais : dans les extraits vectoriels de cleo-carto.org, y'a pas de FC098-FERRALS-LES-MONTAGNES-city-limit.osm. Donc, faut le faire avec JOSM et le plugin cadastre, et ça va moins vite. En zoomant bien sur la zone, c'est rapide à voir. La mauvaise blague, c'est qu'on change de zone Lambert entre les deux communes, donc impossible de superposer les 2 cadastres dans la même vue JOSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Bonjour, Depuis le temps que je vous vois écrire sur cette liste que les limites administratives sont importante, je me suis dit que j'allais essayer de donner un coup de main, surtout qu'en Meurthe-et-Moselle et en Moselle, il y a beaucoup de commune sans limite. En revanche, si le site "http://beta.letuffe.org/"; est très pratique pour voir l'avancement des limites administrative, je n'ai pas trouver la signification des couleurs orange et rouge. Je me doute qu'il signale que qqc ne vas pas, mais quoi ? Cela me semble d'autant plus important que la première commune dont j'ai essayé d'importer les limites appairait maintenant en rouge (http://beta.letuffe.org/?zoom=14&lat=49.0456&lon=6.06394&layers=BFFFTF) Si quelqu'un peut me dire ce que j'ai mal fait afin que je puisse corriger et continuer correctement à aider sur ce vaste chantier. Allez, une deuxième question tant que je suis la. Pour les limites administrative qui suive un autre élément de la carte (la Moselle dans mon cas) est-ce qu'il faut faire un deuxième 'way' (comme ca a été fait pour le bled d'à coté) ou est-ce qu'on coupe way en morceau pour ajouter l'attribut admin_level=8 sur la section qui nous intéresse ? Merci d'avance BlackMyst ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
En revanche, si le site "http://beta.letuffe.org/"; est très pratique pour voir l'avancement des limites administrative, je n'ai pas trouver la signification des couleurs orange et rouge. Je me doute qu'il signale que qqc ne vas pas, mais quoi ? La durée depuis laquelle les limites de la commune ont été complétées. Rouge : ça vient d'être fait. Orange : ça a déjà quelques jours Jaune : quelques semaines Vert : il y a bien longtemps (dans une galaxie lointaine...) Si une couleur apparaît, fusse-t-elle rouge, c'est que tu as réussi ;-) Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Le 5 février 2011 17:56, Eric SIBERT a écrit : > La durée depuis laquelle les limites de la commune ont été complétées. > Rouge : ça vient d'être fait. > Orange : ça a déjà quelques jours > Jaune : quelques semaines > Vert : il y a bien longtemps (dans une galaxie lointaine...) Effectivement, cela apparaît moins grave comme çà. Donc j'en ai profité pour ajouter 6 autres communes ;-) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives
Par contre si c'est gris, ce que tu as mal fait :p Il te faut dans ce cas la utiliser l'analyseur de relations sur le site d'osmose en indiquant le numéro de la relation ;-) Le 5 février 2011 20:53, Black Myst a écrit : > Le 5 février 2011 17:56, Eric SIBERT a écrit : > > La durée depuis laquelle les limites de la commune ont été complétées. > > Rouge : ça vient d'être fait. > > Orange : ça a déjà quelques jours > > Jaune : quelques semaines > > Vert : il y a bien longtemps (dans une galaxie lointaine...) > > Effectivement, cela apparaît moins grave comme çà. > Donc j'en ai profité pour ajouter 6 autres communes ;-) > > ___ > 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] Limites administratives
Le 5 février 2011 09:52, Art Penteur a écrit : > J'ai vu : > http://beta.letuffe.org/?layers=BFFFTF&zoom=12&lat=43.26437&lon=1.58383 > et j'ai trouvé que la limite sud de Calmon semble vraiment tracé "à la > hache" comparé aux autres limites de communes (la limite sud de > Cintegabellle aussi, dans une moindre mesure). C'est marqué dans la source : c'est du "Cartographe Associés". A reprendre donc à l'occasion avec les planches du cadastre. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives invisibles
Bonsoir, À ce niveau de zoom : http://www.openstreetmap.org/?lat=49.465&lon=4.7025&zoom=12&layers=M Il n'y a pas de limites administratives apparentes. Par contre, si on zoom une fois : http://www.openstreetmap.org/?lat=49.465&lon=4.7025&zoom=12&layers=M Elles apparaissent bien ! Au début, je croyais que c'était un problème de rafraîchissement des tuiles, mais ça fait bientôt 2 mois que c'est comme ça, et je vois que l'Aisne est déjà visible au niveau de zoom 12 alors que le département vient d'être fait. Ai-je fait une erreur quelque part ? (commune de Voncq 08 par exemple) Xavier ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ? [Skywave]
Skywave : Bonsoir, jai vu que tu avais créé une relation pour la limite de La Seyne. Par contre, javais créé une way circulaire de 871 nodes, et il y a maintenant, en plus, une autre way de 358 nodes qui se superpose. Je me demandais à quoi elle servait. As-tu divisé ma way entre la ligne côtière et la limite terrestre ? Jai peut-être causé ce problème, car, pensant être le seul à travailler sur cette ville, jai réutilisé un fichier .osm stocké chez moi au lieu de reprendre des données neuves du serveur. Jai dû recréer la way dorigine sans le vouloir. Gilles De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Skywave Envoyé : jeudi 21 août 2008 18:24 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Limites administratives ? Créez un way admin_level=2 boundary=administrative pour la limite nationale, admin_level 8 pour la limite de la commune. Et ajoutez cette ways a une nouveau relation boundary=administrative name=La Seyne admin_level=8. Ajoutez le limite nationale a la relation France id:11980 http://www.openstreetmap.org/browse/relation/11980. Exemples ici: http://www.openstreetmap.org/?lat=42.43646 <http://www.openstreetmap.org/?lat=42.43646&lon=3.17498&zoom=16&layers=B00FT F> &lon=3.17498&zoom=16&layers=B00FTF 2008/8/21 leblatt <[EMAIL PROTECTED]> Pardon, j'oubliais de préciser : la ville est côtière (La Seyne), donc du coup limite nationale. Pas d'incidence ? > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:talk-fr- > [EMAIL PROTECTED] De la part de murphy2712.nospam Envoyé : > jeudi 21 août 2008 17:58 À : Discussions sur OSM en français Objet : > Re: [OSM-talk-fr] Limites administratives ? > > (...) > Pour les relations ce n'est utile qu'à partir du moment où une limite > est partagée avec une autre. ___ Talk-fr mailing list <http://lists.openstreetmap.org/listinfo/talk-fr> 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] Limites administratives ? [Skywave]
J'ai divise la way entre une way de la limite de France et une way de la limite de La Seyne. J'ai supprime la way superposee. 2008/8/25 leblatt <[EMAIL PROTECTED]> > Skywave : Bonsoir, j'ai vu que tu avais créé une relation pour la limite > de La Seyne. > > Par contre, j'avais créé une way circulaire de 871 nodes, et il y a > maintenant, en plus, une autre way de 358 nodes qui se superpose. Je me > demandais à quoi elle servait. > > As-tu divisé ma way entre la ligne côtière et la limite terrestre ? > > J'ai peut-être causé ce problème, car, pensant être le seul à travailler > sur cette ville, j'ai réutilisé un fichier .osm stocké chez moi au lieu de > reprendre des données neuves du serveur. J'ai dû recréer la way d'origine > sans le vouloir. > > > > Gilles > > > > > > *De :* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *De la part de* Skywave > *Envoyé :* jeudi 21 août 2008 18:24 > *À :* Discussions sur OSM en français > *Objet :* Re: [OSM-talk-fr] Limites administratives ? > > > > Créez un way admin_level=2 boundary=administrative pour la limite > nationale, admin_level 8 pour la limite de la commune. > Et ajoutez cette ways a une nouveau relation boundary=administrative > name=La Seyne admin_level=8. Ajoutez le limite nationale a la relation > France id:11980 http://www.openstreetmap.org/browse/relation/11980. > Exemples ici: > http://www.openstreetmap.org/?lat=42.43646&lon=3.17498&zoom=16&layers=B00FTF > > 2008/8/21 leblatt <[EMAIL PROTECTED]> > > Pardon, j'oubliais de préciser : la ville est côtière (La Seyne), donc du > coup limite nationale. Pas d'incidence ? > > > -Message d'origine----- > > De : [EMAIL PROTECTED] [mailto:talk-fr- > > [EMAIL PROTECTED] De la part de murphy2712.nospam Envoyé : > > jeudi 21 août 2008 17:58 À : Discussions sur OSM en français Objet : > > Re: [OSM-talk-fr] Limites administratives ? > > > > (...) > > > Pour les relations ce n'est utile qu'à partir du moment où une limite > > est partagée avec une autre. > > > ___ > Talk-fr mailing list > > http://lists.openstreetmap.org/listinfo/talk-fr > > > > ___ > 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] Limites administratives ? [Skywave]
OK je vois. Je diviserai la limite terrestre en autan de sections quil y a de communes limitrophes (4), en mettant les tags left/ Right. Par contre, sur la côte, le coastline se superpose à la way de limite de commune. Ne peut-on pas léviter, en incluant ce tronçon de coastline à la relation boundary de la commune ? De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Skywave Envoyé : lundi 25 août 2008 23:30 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Limites administratives ? [Skywave] J'ai divise la way entre une way de la limite de France et une way de la limite de La Seyne. J'ai supprime la way superposee. 2008/8/25 leblatt <[EMAIL PROTECTED]> Skywave : Bonsoir, j'ai vu que tu avais créé une relation pour la limite de La Seyne. Par contre, j'avais créé une way circulaire de 871 nodes, et il y a maintenant, en plus, une autre way de 358 nodes qui se superpose. Je me demandais à quoi elle servait. As-tu divisé ma way entre la ligne côtière et la limite terrestre ? J'ai peut-être causé ce problème, car, pensant être le seul à travailler sur cette ville, j'ai réutilisé un fichier .osm stocké chez moi au lieu de reprendre des données neuves du serveur. J'ai dû recréer la way d'origine sans le vouloir. Gilles De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Skywave Envoyé : jeudi 21 août 2008 18:24 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] Limites administratives ? Créez un way admin_level=2 boundary=administrative pour la limite nationale, admin_level 8 pour la limite de la commune. Et ajoutez cette ways a une nouveau relation boundary=administrative name=La Seyne admin_level=8. Ajoutez le limite nationale a la relation France id:11980 http://www.openstreetmap.org/browse/relation/11980. Exemples ici: http://www.openstreetmap.org/?lat=42.43646 <http://www.openstreetmap.org/?lat=42.43646&lon=3.17498&zoom=16&layers=B00FT F> &lon=3.17498&zoom=16&layers=B00FTF 2008/8/21 leblatt <[EMAIL PROTECTED]> Pardon, j'oubliais de préciser : la ville est côtière (La Seyne), donc du coup limite nationale. Pas d'incidence ? > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:talk-fr- > [EMAIL PROTECTED] De la part de murphy2712.nospam Envoyé : > jeudi 21 août 2008 17:58 À : Discussions sur OSM en français Objet : > Re: [OSM-talk-fr] Limites administratives ? > > (...) > Pour les relations ce n'est utile qu'à partir du moment où une limite > est partagée avec une autre. ___ Talk-fr mailing list <http://lists.openstreetmap.org/listinfo/talk-fr> http://lists.openstreetmap.org/listinfo/talk-fr ___ 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] Limites administratives ? [Skywave]
C'est le cadastre qui fait foi. Une coastline est variable dans le temps (érosion, positionnement par rapport aux marées, hausse du niveau de la mer) mais la limite administrative devrait être plus stable. S'il n'y a pas de boundary supérieur (pays, région, département) déjà présent, je ne vois pas de problème à en créer une spécialement pour ça. Pieren 2008/8/25 leblatt <[EMAIL PROTECTED]>: > Par contre, sur la côte, le coastline se superpose à la way de limite de > commune. Ne peut-on pas l'éviter, en incluant ce tronçon de coastline à la > relation boundary de la commune ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ? [Skywave]
Pieren a écrit : > C'est le cadastre qui fait foi. Une coastline est variable dans le > temps (érosion, positionnement par rapport aux marées, hausse du > niveau de la mer) mais la limite administrative devrait être plus > stable. S'il n'y a pas de boundary supérieur (pays, région, > département) déjà présent, je ne vois pas de problème à en créer une > spécialement pour ça. > Pieren Bonsoir, Sur les cotes, de même que sur les autres plans d'eaux frontaliers il existe des règles internationales. Dans l'absolu la limite d'une telle commune est à situer à la limite territoriale du pays en question. Objectivement est-ce réellement utile dans OSM? Je ne le pense pas! Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/~actes/ Cercle Généalogique (Entraide Généalogique en Entreprises): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://www.payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ? [Skywave]
2008/8/26 Yannick <[EMAIL PROTECTED]>: >> Sur les cotes, de même que sur les autres plans d'eaux frontaliers il > existe des règles internationales. > > Dans l'absolu la limite d'une telle commune est à situer à la limite > territoriale du pays en question. Oui mais "la limite territoriale", c'est parfois un peu vague. > > Objectivement est-ce réellement utile dans OSM? Je ne le pense pas! > Tu parles des limites adminstratives ? En voyant certains forums (merci Denis pour les liens), on voit qu'il n'existe pas en France de données libres pour les limites administratives sauf pour le pays et les régions qu'on retrouve dans certaines bases internationales mais avec une faible qualité. Je peux te dire que si l'usage du cadastre est officiellement autorisé dans OSM et que tout le monde contribue à taguer les limites communales grâce à cette source (et qui peuvent servir ensuite aux limites départementales et régionales avec précision), ça va intéresser beaucoup de monde. Le problème que j'ai aussi avec coastline, c'est dans les embouchures ou delta. Le coastline peut s'aventurer assez loin en terre, au gré de l'humeur de celui qui tague la rivière ou le fleuve. C'est aussi en pensant à ça que je précisait que c'est le cadastre qui doit montrer grosso modo pour où passe la limite communale et que ça ne recoupe pas forcément le coastline. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives ? [Skywave]
Pieren a écrit : > 2008/8/26 Yannick <[EMAIL PROTECTED]>: >>> Sur les cotes, de même que sur les autres plans d'eaux frontaliers il >> existe des règles internationales. >> >> Dans l'absolu la limite d'une telle commune est à situer à la limite >> territoriale du pays en question. > > Oui mais "la limite territoriale", c'est parfois un peu vague. Non c'est la frontière du pays donc pas de litiges possibles. > >> Objectivement est-ce réellement utile dans OSM? Je ne le pense pas! >> > > Tu parles des limites adminstratives ? Oui et non! Je pensais au problème des limites sur mer avec les eaux territoriales. Donc je pose toujours la question; est-ce vraiment utile? Et d'autre part sommes vraiment aptes à faire le relevé de cette limite? ;) C'est aussi en > pensant à ça que je précisait que c'est le cadastre qui doit montrer > grosso modo pour où passe la limite communale et que ça ne recoupe pas > forcément le coastline. > Là je suis 100% d'accord que le cadastre doit faire foi et là il n'y a pas de discussion possible puisque c'est le seul support légal en France. En principe l'IGN se calque dessus pour faire ses limites administratives sur ses cartes. Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/~actes/ Cercle Généalogique (Entraide Généalogique en Entreprises): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://www.payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives : Hélène & Cie ?
On m'a conseillé de lire ce message : http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/041356.html Et comme la post est tout récent, je me faufile dans la brèche :) Si vous êtes toujours partant pour me filer un coup de main à délimiter la communauté de communes de la Région de Suippes ; Pieren a fait Suippes et je l'en remercie :) , je m'essaie à Somme-Suippe (n'hésitez pas à vérifier !) , et les autres sont à prendre. Afin de gagner du temps en organisation, Je fait une tableau directement sur la liste de diffusion. Si vous êtes preneur, mettez votre pseudo à côté du village. Bussy-le-Château Cuperly Jonchery-sur-Suippe La Cheppe La-Croix-en-Champagne Laval-sur-Tourbe Saint-Hilaire-le-Grand Saint-Jean-sur-Tourbe Saint-Rémy-sur-Bussy Sainte-Marie-à-Py Sommepy-Tahure Somme-Suippe : *Xavier* Somme-Tourbe Souain-Perthes-lès-Hurlus Suippes : *Pieren* Tilloy-et-Bellay Cousrtisols Somme-Vesle Poix Merci d'avance ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, Le problème a p-e déjà été évoqué mais je ne trouve pas en recherchant dans les messages. J'ai fait un rendu personnalisé avec mapnik pour pouvoir disposer d'une carte mettant en avant les communes sur une zone donnée. Alors que les limites semblent avoir été bien faites j'ai quelques communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). En base la requête faite pour disposer des noms me renvoie bien les communes manquantes. Avez-vous une idée du pourquoi ? Par avance merci de vos réponses. Le rendu : http://www.peacefrogs.net/~etienne/AFAC/rendu.jpg Les sections pertinentes du xml pour mapnik :area-text osm false -20037508,-19929239,20037508,19929239 localhost motdepasse (select way,way_area,name from planet_osm_polygon where name is not null and (waterway is null or waterway <> 'riverbank') and admin_level='8' order by z_order,way_area desc ) as text postgis osm - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9kV4ACgkQtXI+41wn9OQeyQCeJmIejZ69qf32OOhEag2/ob1X xeEAn0r1Amsj/S0FQz/ZkfOo5h9O/qEJ =rOpr -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives invisibles
C'est bien un retard dans le rafraichissement des "tuidalles" sur sur le moteur de rendu. Problème réglé à coup de "/dirty" pour ce rafraîchissement oublié (sans doûte parce que personne n'avait demandé à visualiser les dalles après la mise à jour des données, et depuis il y a eu bien d'autres tuiles à rafraichir ailleurs et qui ont été, elles, demandées). Note que sur ce serveur quand tu demandes à afficher une dalle, même si elle est obsolète, elle te sera retournée immédiatement et sans délai avant qu'elle soit raffraichie plus tard (si ça se produit, cette tuile est inscrite dans une liste de tâches à faire, mais de temps en temps cette liste déborde, ou si e moteur de rendu est obligé de redémarrer, la liste est purgée et ne se souvient plus qu'elle a des tuiles anciennes à rafraichir alors que le serveur redémarre et a aussi des tas d'autres dalles demandées ailleurs). Tu verras donc immédiatement l'ancienne version, et peut-être que plus tard, si tu les redemandes (après avoir purgé ton cache local de ton navigateur), tu verras les nouvelles dalles à jour. Le seul moyen de s'assurer qu'une dalle sera à jour est de la demander et de revisiter quelques minutes plus tard (en forçant le rafraîchissement de la page dans ton navigateur : cliquer sur "lien permanent" pour fixer la vue, puis appuies sur CTRL+SHIFT+R pour recharger non seulement la page mais aussi les images liées) pour voir si c'est fait (le temps nécessaire dépend du niveau de zoom : c'est beaucoup plus long au faible niveau de zoom où cela peut nécessiter d'attendre quelques heures, alors qu'aux niveaux 10 et plus cela ne prend guère plus de 2-3 minutes au maximum, parfois quelques secondes au niveau 12+ où il y a peu de données à prendre en compte). Si le rafraîchissement simple par le navigateur (CTRL+SHIFT+R) ne semble rien changer, c'est là qu'on a besoin du "/dirty" pour forcer la demande au serveur (cela force en fait le rafraîchissement de la dalle mais aussi en même temps de ses voisines dans une méta-dalle plus grande de 8x8 dalles : on le sait par le numéro X ou Y des dalles modulo 8). Si une dalle est rafraîchie dans une métadalle, les autres doivent être aussi rafraîchie alors dans ton navigateur (purge de ton cache ou CTRL+SHIFT+R) pour les voir. Note que CTRL+R ne rafraîchit que la page principale dans ton navigateur, pas les objets liés (dont les images) s'ils sont encore dans ton cache local. Le 11 juin 2013 23:05, Xavier a écrit : > Bonsoir, > À ce niveau de zoom : > http://www.openstreetmap.org/?lat=49.465&lon=4.7025&zoom=12&layers=M > Il n'y a pas de limites administratives apparentes. > Par contre, si on zoom une fois : > http://www.openstreetmap.org/?lat=49.465&lon=4.7025&zoom=12&layers=M > Elles apparaissent bien ! > > Au début, je croyais que c'était un problème de rafraîchissement des > tuiles, mais ça fait bientôt 2 mois que c'est comme ça, et je vois que > l'Aisne est déjà visible au niveau de zoom 12 alors que le département > vient d'être fait. > > Ai-je fait une erreur quelque part ? (commune de Voncq 08 par exemple) > > Xavier > > ___ > 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] Limites administratives invisibles
Note aussi que nulle part les limites de communes (admin_level 8) ne sont visibles au niveau de zoom 10 sur ce rendu Mapnik d'OSM.org (on n'y voit au mieux que les limites d'arrondissements (admin_level 7). Bref il faut zoomer de toute façon pour les voir et ce n'est pas une question technique de mise à jour (compare ailleurs en France dans les autres régions complètes c'est pareil). On ne peut rien y changer par rafraîchissement, sauf demander si OSM.org veut bien modifier les feuilles de style de son rendu (là on peut attendre...). Si ça ne te plait pas, consulte un autre rendu, il y en a ! Regarde par exemple sur le site Osmose (tu peux l'utiliser aussi pour juste afficher le rendu sans afficher les couches affichant les corrections à faire). ou encore sur http://layers.openstreetmap.fr/ ou http://tile.openstreetmap.fr/ (qui donne accès aux deux rendus OSM.fr et 2u) Le 11 juin 2013 23:05, Xavier a écrit : > Bonsoir, > À ce niveau de zoom : > http://www.openstreetmap.org/?lat=49.465&lon=4.7025&zoom=12&layers=M > Il n'y a pas de limites administratives apparentes. > Par contre, si on zoom une fois : > http://www.openstreetmap.org/?lat=49.465&lon=4.7025&zoom=12&layers=M > Elles apparaissent bien ! > > Au début, je croyais que c'était un problème de rafraîchissement des > tuiles, mais ça fait bientôt 2 mois que c'est comme ça, et je vois que > l'Aisne est déjà visible au niveau de zoom 12 alors que le département > vient d'être fait. > > Ai-je fait une erreur quelque part ? (commune de Voncq 08 par exemple) > > Xavier > > ___ > 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
[OSM-talk-fr] Limites administratives bizarrement placées
Bonsoir, Voila la 2nde fois que je m'aperçoit d'une telle chose : des limites administratives décalées de plusieurs kilomètres par rapport à leur emplacement effectif. Voyez-ici : http://www.openstreetmap.org/#map=16/45.8884/6.1287 On voit clairement les limites du nord d'Annecy se dessiner bien au sud. http://www.openstreetmap.org/way/259844169 L'objet original est pourtant bien placé. http://www.openstreetmap.org/way/257001112 Est-ce le résultat d'un import automatique ? Je l'ai déjà supprimé, mais il a réapparu. Peut-être que ceci se produit ailleurs. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives : Hélène & Cie ?
Correction il y en a déjà de faite : Bussy-le-Château Cuperly : *Fait* Jonchery-sur-Suippe La Cheppe La-Croix-en-Champagne Laval-sur-Tourbe Saint-Hilaire-le-Grand Saint-Jean-sur-Tourbe Saint-Rémy-sur-Bussy Sainte-Marie-à-Py : *Fait* Sommepy-Tahure : *Fait* Somme-Suippe : *Xavier* Somme-Tourbe Souain-Perthes-lès-Hurlus Suippes : *Pieren* Tilloy-et-Bellay Cousrtisols :*Fait* Somme-Vesle : *Fait* Poix ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives : Hélène & Cie ?
> De : "Xavier" > > Correction il y en a déjà de faite : > > J'ai dressé un tableau sur le wiki afin qu'on s'y retrouve, et qu'on vise le moindre effort :-) : http://wiki.openstreetmap.org/wiki/France:Marne/Limites_communales_autour_de_Suippes Il faut viser en premier les communes marquées "à privilégier, croisillons sur toutes les planches" histoire de minimiser les aléas de calage. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives : Hélène & Cie ?
Le 19/03/2012 15:52, Vincent de Chateau-Thierry a écrit : http://wiki.openstreetmap.org/wiki/France:Marne/Limites_communales_autour_de_Suippes Il faut viser en premier les communes marquées "à privilégier, croisillons sur toutes les planches" histoire de minimiser les aléas de calage. Je ferais - Bussy-le-Château - Saint-Rémy-sur-Bussy qui sont connexes (d'après géofla et le plugin OpenData (merci Vincent Privat)) d'ici jeudi soir ; et après je verrai où on en est. Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
Étienne Loks wrote: > Bonjour, > > Le problème a p-e déjà été évoqué mais je ne trouve pas en recherchant > dans les messages. > > J'ai fait un rendu personnalisé avec mapnik pour pouvoir disposer d'une > carte mettant en avant les communes sur une zone donnée. > Alors que les limites semblent avoir été bien faites j'ai quelques > communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). > > En base la requête faite pour disposer des noms me renvoie bien les > communes manquantes. > > Avez-vous une idée du pourquoi ? Le placement des étiquettes est fait automatiquement par mapnik. L'algorithme qui s'en charge évite de surcharger la carte en éliminant les étiquettes qui se chevauchent. Si mes souvenirs sont bons, les étiquettes sont placées dans l'ordre elles sont lues dans les résultats de la requête, c'est à dire qu'on peut prioriser en ajoutant une clause ORDER BY à la requête source. On peut aussi commander à mapnik de ne pas éviter le chevauchement avec l'attribut allow_overlap. Par exemple : Mais généralement, ça fait plus de mal que de bien. Mieux vaut prioriser et laisser faire mapnik afficher tout ce qu'il peut sans forcer. Ce qui n'est pas visible à un niveau de zoom le sera probablement au suivant. Plus d'infos sur : http://trac.mapnik.org/wiki/TextSymbolizer. Pour info, le projet mapnik dispose d'une liste mapnik-us...@lists.berlios.de qui me semble plus indiquée pour des questions aussi pointues. Bien cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Re-bonjour, Le 19/10/2010 14:56, Gilles Bassière a écrit : > Étienne Loks wrote: >> J'ai fait un rendu personnalisé avec mapnik pour pouvoir disposer d'une >> carte mettant en avant les communes sur une zone donnée. >> Alors que les limites semblent avoir été bien faites j'ai quelques >> communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). >> >> En base la requête faite pour disposer des noms me renvoie bien les >> communes manquantes. >> >> Avez-vous une idée du pourquoi ? > > Le placement des étiquettes est fait automatiquement par mapnik. > L'algorithme qui s'en charge évite de surcharger la carte en éliminant > les étiquettes qui se chevauchent. > > Si mes souvenirs sont bons, les étiquettes sont placées dans l'ordre > elles sont lues dans les résultats de la requête, c'est à dire qu'on > peut prioriser en ajoutant une clause ORDER BY à la requête source. > > On peut aussi commander à mapnik de ne pas éviter le chevauchement avec > l'attribut allow_overlap. Par exemple : > Merci ! Avec le allow_overlap="true", j'ai un rendu correct. Je n'avais bêtement pas testé car le problème survenait sur des communes assez étendues qui ne me semblaient pas sujettes à un recouvrement. > Mais généralement, ça fait plus de mal que de bien. Mieux vaut > prioriser et laisser faire mapnik afficher tout ce qu'il peut sans > forcer. Ce qui n'est pas visible à un niveau de zoom le sera > probablement au suivant. En l'occurrence, je fais du rendu pour juste une image, il était important que tout apparaisse. > Plus d'infos sur : http://trac.mapnik.org/wiki/TextSymbolizer. > > Pour info, le projet mapnik dispose d'une liste > mapnik-us...@lists.berlios.de qui me semble plus indiquée pour des > questions aussi pointues. Oui en effet. J'ai cédé à la facilité d'une liste en français. Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9ocUACgkQtXI+41wn9ORnGQCfSbsJ81LbQUk68yGwIx/Yqhs0 qvgAmQGNIf1oxNkUEZ8V18wNE+f5b0By =KdqP -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bonjour, Le 19/10/2010 15:49, sly (sylvain letuffe) a écrit : > On mardi 19 octobre 2010, Étienne Loks wrote: >> communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). > > L'hypothèse de Gilles me semble insuffisante pour expliquer les deux que tu > viens de citer, puisque la surface des deux communes est grande, et il y > aurait largement la place. > > La vérité est ailleurs, et il faudrait faire plus de test pour savoir si ça > vient d'un bug de mapnik, un problème de mémoire quelque part ou autre. Probablement un bug de mapnik du coup. Car en forçant le chevauchement ça passe. Il sera p-e utile que je reporte ce cas de figure sur la liste mapnik. > - ta requête "and (waterway is null or waterway <> 'riverbank')" est > étrange, elle sert à quoi ? (bien que je ne pense pas que cela influence) Avec le admin_level='8' à rien effectivement. Je suis parti du osm.xml de base et l'ai modifié. C'est du mauvais ménage de ma part (juste une condition inutile). Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9pEUACgkQtXI+41wn9OQBqQCcDLQ6fmHue45gwdai/ngETrSl TkwAni9ygUjR3wvs84sjgW0nXGdezR5m =EpZF -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
Étienne Loks wrote: > Bonjour, > > Le 19/10/2010 15:49, sly (sylvain letuffe) a écrit : >> On mardi 19 octobre 2010, Étienne Loks wrote: >>> communes dont le nom n'apparaît pas (comme Rennes, Paimpont, etc.). >> L'hypothèse de Gilles me semble insuffisante pour expliquer les deux que tu >> viens de citer, puisque la surface des deux communes est grande, et il y >> aurait largement la place. > La surface des géométrie n'entre pas en considération dans le placement des étiquettes. Si mes souvenirs sont bons, ce placement est fait après tout le reste pour que les étiquettes apparaissent toujours au-dessus des autres couches. L'algorithme utilise alors seulement les centroïdes des géométries et positionnent les étiquettes les unes après les autres en s'assurant qu'elles ne chevauchent pas d'autres étiquettes (en tenant compte d'une marge). Si mes souvenirs sont bons, cette détection de chevauchement considère les étiquettes de *toutes* les couches, pas seulement celles de la couche concernée, ce qui rendrait le résultat d'autant plus difficilement prévisible. J'ai bien dit plusieurs fois "si mes souvenirs sont bons". Mieux vaut reposer la question sur mapnik-users. Les développeurs du projet ont la mémoire plus fraîche et sont habituellement très réactifs. >> La vérité est ailleurs, et il faudrait faire plus de test pour savoir si ça >> vient d'un bug de mapnik, un problème de mémoire quelque part ou autre. > > Probablement un bug de mapnik du coup. Car en forçant le chevauchement > ça passe. Il sera p-e utile que je reporte ce cas de figure sur la liste > mapnik. > Possible que ce soit un bug mais possible aussi que ce soit une configuration inappropriée. Le placement des étiquettes est un mécanisme compliqué et très certainement capricieux. Il faut savoir que ce mécanisme était un des points forts du projet dès ses débuts, j'imagine que ça a été testé en long en large et en travers. Bref, si tu contactes mapnik-users, mieux vaut avancer prudemment avant de parler de bug. Il me semble qu'il y a un paramètre pour jouer sur l'écartement entre les étiquettes, min_distance peut-être (à vérifier dans la doc). Je ne sais plus quelle est la valeur par défaut. La clause order by reste aussi une piste à ne pas négliger, quand tu fais la requête à la main, est-ce que rennes et paimpont (pour reprendre l'exemple) arrivent avant les communes qui leur sont limitrophes ? Cordialement -- Gilles Bassière - Web/GIS software engineer http://gbassiere.free.fr/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/10/2010 16:37, Gilles Bassière a écrit : > La surface des géométrie n'entre pas en considération dans le placement > des étiquettes. Si mes souvenirs sont bons, ce placement est fait après > tout le reste pour que les étiquettes apparaissent toujours au-dessus > des autres couches. L'algorithme utilise alors seulement les centroïdes > des géométries et positionnent les étiquettes les unes après les autres > en s'assurant qu'elles ne chevauchent pas d'autres étiquettes (en tenant > compte d'une marge). > > Si mes souvenirs sont bons, cette détection de chevauchement considère > les étiquettes de *toutes* les couches, pas seulement celles de la > couche concernée, ce qui rendrait le résultat d'autant plus > difficilement prévisible. Ok. L'algorithme semble sensiblement plus complexe que ce que j'avais supposé. >>> La vérité est ailleurs, et il faudrait faire plus de test pour savoir si ça >>> vient d'un bug de mapnik, un problème de mémoire quelque part ou autre. >> >> Probablement un bug de mapnik du coup. Car en forçant le chevauchement >> ça passe. Il sera p-e utile que je reporte ce cas de figure sur la liste >> mapnik. > > Possible que ce soit un bug mais possible aussi que ce soit une > configuration inappropriée. Le placement des étiquettes est un mécanisme > compliqué et très certainement capricieux. Il faut savoir que ce > mécanisme était un des points forts du projet dès ses débuts, j'imagine > que ça a été testé en long en large et en travers. Bref, si tu contactes > mapnik-users, mieux vaut avancer prudemment avant de parler de bug. Oui. Je commence juste à m'intéresser à Mapnik, je ne vais pas crier de suite au bug sans avoir compris le quart de son mode de fonctionnement. > La clause order by reste aussi une piste à ne pas négliger, quand tu > fais la requête à la main, est-ce que rennes et paimpont (pour reprendre > l'exemple) arrivent avant les communes qui leur sont limitrophes ? Elles sont ordonnées de manière descendante par way_area et donc Paimpont et Rennes apparaissent avant leur voisins. Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEUEARECAAYFAky9tc4ACgkQtXI+41wn9OQulgCYynnR6mI8IbV11/y0564EQPiF +wCfSk7DgD98nCeI88/JIWAZqh26Q4k= =VT3y -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives - rendu mapnik
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 19/10/2010 17:02, sly (sylvain letuffe) a écrit : > Si bug il y a, il pourrait être lié au calcul de la place prise par la police > choisie. Je dis peut-être une connerie, mais son style indique une taille de > police de 40 points, hors à y regarder de plus prêt, à l'affichage, la police > semble plutôt être entre 12 et 15 points. J'ai sensiblement réduit l'image avant de vous la soumettre. J'ai environ divisé la taille par 4. > J'ai essayé sur mon rendu d'utiliser la police fontset_name="book-fonts" mais > mon système ne semble pas l'avoir. > > Étienne, si tu remplaces juste fontset_name="book-fonts" par > face_name="DejaVu Sans Bold" est-ce que ça règle ton problème ? > (sans utiliser allow_overlap="true" évidement) En entête j'ai : Donc on travaille avec la même police ;) Bien cordialement, - -- Étienne Loks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAky9t8YACgkQtXI+41wn9OTvAgCdHFnmPQZO7hmRoitecZ/9zXVp 56YAnj+X42EaPlpVacDa/pBMgHL0QHo7 =fpob -END PGP SIGNATURE- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives françaises issues d'OpenStreetMap
Je viens d'essayer de récupérer ces fichiers sur data.gouv.fr mais il n'y a plus beaucoup de liens fonctionnels sur la page https://www.data.gouv.fr/en/datasets/limites-administratives-francaises-issues-d-openstreetmap/ La page https://www.data.gouv.fr/fr/datasets/decoupage-administratif-communal-francais-issu-d-openstreetmap/ permet d'obtenir le fichier. Marc -- Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Pour ceux que ça intéresse, il existe une carte en ligne depuis une semaine environ qui visualise les limites administratives dans OSM. http://tools.geofabrik.de/osmi/ (choisir "boundaries" dans "view") Cette carte permet surtout de voir en un coup d'oeil les polygones non fermés et la présence ou non de la relation de type boundary. On peut ainsi voir que certains polygones de régions ou départements sont actuellement cassés alors qu'ils étaient correct lors de leur création. On y voit aussi des chemins (ways) comportant des anomalies (traits rouges) comme des superpositions ou croisements. Inutile de préciser que ces données sont extrêmement importantes pour le projet OSM car elles permettront à terme de localiser tous les objets jusqu'à un niveau communal, ce qui ouvre de belles perspectives pour de nombreuses applications à venir. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Bonjour, En examinant le "b...l", pardon, le chaos actuel dans les limites administratives, je me suis demandé s'il était encore pertinent de conserver 2 relations pour les limites de la France, une avec l'ancien modèle, et une avec les segments/multilinestring. L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours aucun logiciel qui s'en sert. Il faut parfois admettre que même les bonnnes idées peuvent ne pas être suivies d'effets. Comme cela alourdie inutilement les éditions (et nous distingue encore une fois de tous nos voisins du monde), je propose de ne conserver que l'ancien modèle, en le remettant dans la relation d'origine pour les frontières terrestres (la 11980) et supprimer la relation 1403916 qui ferrait alors doublon ainsi que toutes les relations multilinestring afférantes. Des opinions ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
>> Inutile de préciser que ces données sont extrêmement importantes pour le >> projet OSM car elles permettront à terme de localiser tous les objets >> jusqu'à un niveau communal, ce qui ouvre de belles perspectives pour de >> nombreuses applications à venir. Je suis surpris de constater que certaines limites communales semblent déjà exister, notamment en région parisienne, comme celle ci : layer:boundary_relations_5 id:989 rel_id:34076 name:Marcoussis admlvltxt:8 admlvl:8 label:Marcoussis (8) lastchange:2008-09-26 13:28:23 Je serais intéressé de connaître la source, mais comment remonter cette information ? Robin, curieux. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
2008/11/18 Robin Prest <[EMAIL PROTECTED]>: > Je serais intéressé de connaître la source, mais comment remonter cette > information ? Il suffit d'aller sur la carte principale d'OSM et de sélectionner le layer "data" et cliquer sur l'objet : http://www.openstreetmap.org/browse/way/27285683 Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Pieren a écrit : > Pour ceux que ça intéresse, il existe une carte en ligne depuis une > semaine environ qui visualise les limites administratives dans OSM. > > http://tools.geofabrik.de/osmi/ > (choisir "boundaries" dans "view") merci pour le lien. Bookmarké !!! Il y a du boulot (et, probablement, une méthodologie à mettre en place) Demain, j'ai une formation sur Openlayers. Youpi !!! Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Bonsoir, Bon alors, la plupart des erreurs de boundaries en Île-de-France, c'est de moi :o) http://tools.geofabrik.de/osmi/?view=boundaries&baselayer=Mapnik&opacity=0.30&lon=2.16638&lat=48.75431&zoom=11&overlays=coastline,boundary_relations_1,boundary_relations_2,boundary_relations_3,boundary_relations_4,boundary_relations_5,boundary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ways_5,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways Le truc, c'est que je note les admin_level au niveau des relations, et pas au niveau des ways directement, car un way peut-être utilisé par plusieurs relations avec des admin_level différents. C'est le cas par exemple lorsqu'un way correspond à la limite d'une commune, mais aussi d'un département (voire d'une région). Les ways sont donc juste tagués boundary=administrative, le reste étant mis dans les relations. En gros, j'utilise ce qui est décrit dans cette page : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries Si ça vous va pas, vous savez maintenant sur qui taper ! a+ Jérôme Denis a écrit : > Pieren a écrit : > >> Pour ceux que ça intéresse, il existe une carte en ligne depuis une >> semaine environ qui visualise les limites administratives dans OSM. >> >> http://tools.geofabrik.de/osmi/ >> (choisir "boundaries" dans "view") >> > > merci pour le lien. Bookmarké !!! > Il y a du boulot (et, probablement, une méthodologie à mettre en place) > Demain, j'ai une formation sur Openlayers. Youpi !!! > Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Jérôme BLUM a écrit : > Bonsoir, > > Bon alors, la plupart des erreurs de boundaries en Île-de-France, c'est > de moi :o) > http://tools.geofabrik.de/osmi/?view=boundaries&baselayer=Mapnik&opacity=0.30&lon=2.16638&lat=48.75431&zoom=11&overlays=coastline,boundary_relations_1,boundary_relations_2,boundary_relations_3,boundary_relations_4,boundary_relations_5,boundary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ways_5,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways > > Le truc, c'est que je note les admin_level au niveau des relations, et > pas au niveau des ways directement, car un way peut-être utilisé par > plusieurs relations avec des admin_level différents. C'est le cas par > exemple lorsqu'un way correspond à la limite d'une commune, mais aussi > d'un département (voire d'une région). Les ways sont donc juste tagués > boundary=administrative, le reste étant mis dans les relations. > > En gros, j'utilise ce qui est décrit dans cette page : > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries > > Si ça vous va pas, vous savez maintenant sur qui taper ! > > a+ > Jérôme Merci Jérôme de te dénoncer (nan je déconne, on aurait finit par te retrouver ;-). En fait, CQFD : les objets immatériels ont besoin d'une méthodologie pérenne : ton raisonnement tient la route. Un autre est de dire : on tague l'objet le plus précis le plus complètement (normalement la commune) et les autres objets "supra-communaux" surchargent (à la manière java) les infos : admin_level=x, name=y, etc. Dans un raisonnement tautologique, cela s'applique aussi au niveau communal, mais il reste un way qui n'a plus de sens en soi à part le fait de dire (ce que tu as fait) qu'il soit une limite administrative. Je ne souhaite pas lancer le débat ici et maintenant, mais une des questions est de déterminer s'il faut privilégier uniquement les relations pour décrire les classes d'objets immatériels ou s'il n'est pas nécessaire que la brique de base soit porteuse de suffisamment d'informations pour elle-même. Personnellement, je voyais la relation "commune" comme étant l'ordonnancement des ways (dans le sens trigonométrique ?) constituant la ban communal à partir des limites commune X/commune Y. A l'assaut du wiki !! Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> Merci Jérôme de te dénoncer (nan je déconne, on aurait finit par te > retrouver ;-). En fait, CQFD : les objets immatériels ont besoin d'une > méthodologie pérenne : ton raisonnement tient la route. Un autre est de > dire : on tague l'objet le plus précis le plus complètement (normalement > la commune) et les autres objets "supra-communaux" surchargent (à la > manière java) les infos : admin_level=x, name=y, etc. > Tu veux dire qu'un way appartenant à une commune et à un département serait uniquement tagué "admin_level=6" par surchargement ?! Comment peux-tu retrouver le contour complet de ta commune dans ce cas là ? > Dans un raisonnement tautologique, cela s'applique aussi au niveau > communal, mais il reste un way qui n'a plus de sens en soi à part le > fait de dire (ce que tu as fait) qu'il soit une limite administrative. > > Je ne souhaite pas lancer le débat ici et maintenant, mais une des > questions est de déterminer s'il faut privilégier uniquement les > relations pour décrire les classes d'objets immatériels ou s'il n'est > pas nécessaire que la brique de base soit porteuse de suffisamment > d'informations pour elle-même. > Les relations sont en train de prendre de l'importance dans le monde OSM : voir par exemple la nouvelle façon de taguer les routes internationales (finies les int_ref)... Les relations ont été créées en partie pour palier à l'impossibilité technique d'appliquer plusieurs une même key à un objet, à cause du format des attributs XML. La solution proposée pour tagguer toutes les limites administratives avec des relations me semble justement la plus pérenne, car elle est la plus logique et évolutive dans le temps. J'ai donc arrêté de taguer avec des right: et des left: à tout-va. > Personnellement, je voyais la relation "commune" comme étant > l'ordonnancement des ways (dans le sens trigonométrique ?) constituant > la ban communal à partir des limites commune X/commune Y. > Tu connais le coup des 3 engrenages concomitants ? Aucun ne peut tourner ! Cela serait pareil pour trois communes partageant un coin commun : tu serais obligé d'avoir au moins une commune avec des ways à contre-sens de ses autre ways... Donc l'ordonnancement dont tu parles ne peut pas toujours fonctionner. > A l'assaut du wiki !! > Je t'en prie, après toi... :o) > Denis > Jérôme ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
2008/11/19 Jérôme BLUM <[EMAIL PROTECTED]>: Comme souvent avec OSM, il y a plusieurs solutions: - créer des ways qui se superposent pour chaque admin_level; mais comme ça reste du boudary à chaque fois, ça n'aurais pas trop de sens. Donc mauvaise idée. - faire comme les hollandais qui ont un tag "admin_level:6=yes" et "admin_level:8=yes". Je trouve ça pas terrible. En plus, ils gardent aussi un "admin_level" avec une seule valeur, peut-être pour valider leur boundary dans l'outil de geofabrik. Encore pire. - il reste que OSM propose depuis longtemps la possibilité d'avoir une clé avec plusieurs valeurs, séparées par un point-virgule. Ca donne "admin_level=4;6;8". C'est simple et c'est valable pour toutes sortes de clés. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Ta troisième solution me semble la meilleure, bien qu'elle ne résolve pas le problème des noms de différentes limites assignés à un même way. On pourrait alors proposer pour un même way un "admin_level_6:name = Pyrénées-Orientales" et un "admin_level_8:name = Rivesaltes" par exemple, mais je trouve ça moche. De plus, j'essaie de me mettre à place d'un GPS (c'est assez étroit !) ou d'un logiciel : pour trouver la limite d'un département, lui sera-t-il plus facile, plus rapide et plus économique en mémoire de chercher tous les ways possédant le tag "admin_level = 6" et le tag "admin_level_6:name = Pyrénées-Orientales", ou bien de regarder tous les id des ways contenus dans une relation "type = boundary", "boundary = administrative", "admin_level = 6" et "name = Pyrénées-Orientales" ?. Et puis, au final, il faut regarder vers l'avenir : de nouveaux types de relations sortent régulièrement. Le fait de découpler certaines informations des ways dans des relations a deux avantages qui vont devenir de plus en plus importants : 1) Cela évitera de placer de plus en plus de tags au niveau des nodes et des ways ayant une représentation physique (routes, waterways...) 2) Par conséquent, cela permettra aux concepteurs de cartes pour GPS de "choisir" le niveau de détail de l'information à embarquer dans l'appareil : s'ils ne veulent pas inclure les limites administratives, il suffira de supprimer toutes les relations "boundary = administrative", sans avoir à modifier les tags des nodes et des ways participant à ces limites-. Jérôme Pieren a écrit : > 2008/11/19 Jérôme BLUM <[EMAIL PROTECTED]>: > > Comme souvent avec OSM, il y a plusieurs solutions: > - créer des ways qui se superposent pour chaque admin_level; mais > comme ça reste du boudary à chaque fois, ça n'aurais pas trop de sens. > Donc mauvaise idée. > - faire comme les hollandais qui ont un tag "admin_level:6=yes" et > "admin_level:8=yes". Je trouve ça pas terrible. En plus, ils gardent > aussi un "admin_level" avec une seule valeur, peut-être pour valider > leur boundary dans l'outil de geofabrik. Encore pire. > - il reste que OSM propose depuis longtemps la possibilité d'avoir une > clé avec plusieurs valeurs, séparées par un point-virgule. Ca donne > "admin_level=4;6;8". C'est simple et c'est valable pour toutes sortes > de clés. > > 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] Limites administratives sur la carte OSM Inspector
Jérôme BLUM a écrit : > Tu veux dire qu'un way appartenant à une commune et à un département > serait uniquement tagué "admin_level=6" par surchargement ?! non, le way "appartenant" à la commune serait tagué admin_level=8, left:city=machin, rigth_city=bidule, comme d'hab. Le département et autres limites supérieures itou, ne serait que des relations se concentrant sur l'ensemble des membres de la relation et les attributs surchargés : admin_level, name, code, etc. > Comment peux-tu retrouver le contour complet de ta commune dans ce cas là ? Une relation pardi ! Celle qui associe l'ensemble des ways commune A/commune B en disant que c'est le ban communal de la commune A (ou B). > Les relations sont en train de prendre de l'importance dans le monde OSM > : voir par exemple la nouvelle façon de taguer les routes > internationales (finies les int_ref)... économies d'énergie -> développement durable ? Pourquoi mettre le même tag sur TOUS les constituants d'un objet ? > Les relations ont été créées en partie pour palier à l'impossibilité > technique d'appliquer plusieurs une même key à un objet, à cause du > format des attributs XML. La solution proposée pour tagguer toutes les > limites administratives avec des relations me semble justement la plus > pérenne, car elle est la plus logique et évolutive dans le temps. J'ai > donc arrêté de taguer avec des right: et des left: à tout-va. Sauf à posséder une base de données spatiale (PostGIS, dans mon cas) qui permet de traiter la question "qu'est ce qu'on a à droite|gauche de l'objet X), je ne crois pas que l'information soit traitable avec les outils classiques (analyse de fichier xml, API, etc.). Est-ce une information importante, je ne sais pas et ce n'est pas à moi d'en décider. Toutefois, si cette connaissance était liée à l'utilisation d'outils particuliers, je militerais pour son maintien comme tag, du moins tant que tout le monde ne bénéficie pas, par ailleurs, du même niveau de connaissance. Mieux vaux des infos redondantes (en espérant une rationalisation à bon escient, qu'une absence d'informations). C'est clair, c'est plus coûteux pour le contributeur et rien ne peut l'y obliger. > Tu connais le coup des 3 engrenages concomitants ? Aucun ne peut tourner > ! Cela serait pareil pour trois communes partageant un coin commun : tu > serais obligé d'avoir au moins une commune avec des ways à contre-sens > de ses autre ways... Donc l'ordonnancement dont tu parles ne peut pas > toujours fonctionner. Une bordure (edge|limite|frontière) ne peut avoir qu'un et un seul côté droit et un et un seul côté gauche. Quant aux relations caractérisant les 2 communes, rien n'empêche que leurs bordures membres soient exprimées dans des sens contraires. A moins que : 1. je me sois mal exprimé dans ma proposition initiale 2. que je n'ai rien compris à la topologie des faces, des edges et des nodes Aucune des 2 hypothèses n'est pas exclure d'emblée vu l'état de fatigue dans lequel je suis actuellement. >> A l'assaut du wiki !! >> > Je t'en prie, après toi... :o) 1:0 ;-) > Jérôme Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
2008/11/19 Jérôme BLUM <[EMAIL PROTECTED]>: > Ta troisième solution me semble la meilleure, bien qu'elle ne résolve > pas le problème des noms de différentes limites assignés à un même way. > On pourrait alors proposer pour un même way un "admin_level_6:name = En principe, ce problème est résolu si on respecte la convention actuelle "left:city=", "left:departement=", "left:region=". Je ne me souviens pas ce qu'il y a à ce sujet dans le wiki qui est en rade pour l'instant mais c'est vrai que la relation a été créée justement pour résoudre ces problèmes de nom. En effet, rien ne lie le tag "left:commune" avec "admin_level=8" et le tag "left:departement" avec "admin_level=6" dans la bdd mais uniquement une hypothétique documentation sur le wiki. > ../..j'essaie de me mettre à place > d'un GPS (c'est assez étroit !) ou d'un logiciel : pour trouver la > limite d'un département, lui sera-t-il plus facile, plus rapide ../.. > de chercher tous les ways possédant le tag > "admin_level = 6" et le tag "admin_level_6:name = Pyrénées-Orientales", > ou bien de regarder tous les id des ways contenus dans une relation > "type = boundary", "boundary = administrative", "admin_level = 6" et > "name = Pyrénées-Orientales" ?. Les logiciels disposent rarement des données bruts mais convertissent souvent ces données dans un format qui filtre et organise ces données pour leur besoin propre. Si l'application a besoin de localiser les objets à l'intérieur de polygones comme les régions ou les communes, les développeurs choisiront la solution qui conviendra le mieux à leur besoin et aux capacités de la machine qui accueille le logiciel. Tout ça, c'est assez simple mais ça reste le problème des programmeurs qui ont l'habitude d'en baver. Le modèle des données OSM est volontairement simple et flexible pour les contributeurs. On laisse les trucs compliqués aux machines et aux programmeurs. > > Et puis, au final, il faut regarder vers l'avenir : de nouveaux types de > relations sortent régulièrement. Le fait de découpler certaines > informations des ways dans des relations a deux avantages qui vont > devenir de plus en plus importants : Je suis d'accord. A terme, les tags admin_level et les noms devraient sortir des ways et rester uniquement dans les relations. Mais il y a une certaine réticence à abandonner les attributs des ways parce que les gens sont assez réfractaires aux relations qui sont en général assez difficile à éditer avec les outils actuels. 2008/11/19 Denis <[EMAIL PROTECTED]>: > ... Mieux vaux des infos redondantes (en espérant > une rationalisation à bon escient, qu'une absence d'informations). Pour une fois, je ne suis pas d'accord avec Denis. Si on stocke une information dans deux endroits différents, on est sûr que tôt ou tard, il y a aura des différences. A éviter à tout prix. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Il me semble, qu'avec cette nouvelle approche par 'relations', on rentrerait dans une nouvelle ère à taguer les propriétés d'un objet, fondamentalement différente de ce qu'on fait jusque-là... Par extension, ce système de 'relations' devrait s'appliquer à toute propriété non-physique de tous éléments... (?) Si on voulait être conséquents, les "tags traditionnels" resteraient réservés aux propriétés physiques (classification, largeur, état de la voie, nombre de voies...), là où les autres attributs plutôt virtuels, non-physiques, (name, ref, int_ref d'une voie, ou la voie à laquelle appartient l'adresse/n° d'une maison, ou la ligne de métro à laquelle appartient une station, devraient faire objet d'une 'relation' ? (Voire une buvette ferait partie d'une relation débits de boisson lic III, un bar ferait partie d'une relation débits de boisson lic IV, où tous deux feraient partie de la relation restauration ? Et ne "reste" dans le node que ce qui n'est pas pris en compte par une relation, ici le tag "name : "Chez Bidule" ?) --- Le principe me va, de regrouper plusieurs ways en une "unité supérieure", comme plusieurs morcaux de limites communales en une limite de département, puis en frontière nationale (la logique de Jérôme me paraît correcte), ou de regrouper plusieurs tronçons de ways en une "route européenne E machin", "RCEA", ou "route des châteaux" ou "route Jacques Cœur", qui eux-mêmes pourraient être dans une relation parcours touristique. ok, même si ça fera du travail en sus, et obligera à huiler des aiguillages rouillées du cerveau... mais alors OU est la notion de regroupement en unités supérieures dans la "Relation:restriction", pourtant dans les "established uses" ? Ça revient à artificiellement introduire une unité qui n'a pas d'existence, pour ensuite dire, qu'elle n'existe pas, ça me paraît absurde... Je suis réfractaire à des fonctionnements qui nécessitent un élément virtuel extérieur. Oui, je me sers de tels artifices en mathématiques, mais je regarde l'usage de ces "parachutes" comme une déclaration d'échec, comme quoi je n'ai pas réussi à faire face avec mes outils 'propres'. --- Je n'ai rien contre les 'relations', mais que cela soit a) conséquent et partout, b) simple et compréhensible, c) expliqué sur le wiki, en mots simples. (et si possible d), des "presets" en cascade pour ça, dans josm... :-) Dans l'attente d'éclaircissement où s'arrête le tag sur node et way, et où au juste commence la 'relation', je continue à l'ancienne. Gerhard --- Le 18 nov. 08 à 20:55, Denis a écrit : > > Jérôme BLUM a écrit : >> Bonsoir, >> >> Bon alors, la plupart des erreurs de boundaries en Île-de-France, >> c'est >> de moi :o) >> http://tools.geofabrik.de/osmi/? >> view=boundaries&baselayer=Mapnik&opacity=0.30&lon=2.16638&lat=48.7543 >> 1&zoom=11&overlays=coastline,boundary_relations_1,boundary_relations_ >> 2,boundary_relations_3,boundary_relations_4,boundary_relations_5,boun >> dary_ways_1,boundary_ways_2,boundary_ways_3,boundary_ways_4,boundary_ >> ways_5,boundary_ways_with_unknown_admlvl,non_simple_boundary_ways >> >> Le truc, c'est que je note les admin_level au niveau des >> relations, et >> pas au niveau des ways directement, car un way peut-être utilisé par >> plusieurs relations avec des admin_level différents. C'est le cas par >> exemple lorsqu'un way correspond à la limite d'une commune, mais >> aussi >> d'un département (voire d'une région). Les ways sont donc juste >> tagués >> boundary=administrative, le reste étant mis dans les relations. >> >> En gros, j'utilise ce qui est décrit dans cette page : >> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Boundaries >> >> Si ça vous va pas, vous savez maintenant sur qui taper ! >> >> a+ >> Jérôme > > Merci Jérôme de te dénoncer (nan je déconne, on aurait finit par te > retrouver ;-). En fait, CQFD : les objets immatériels ont besoin d'une > méthodologie pérenne : ton raisonnement tient la route. Un autre > est de > dire : on tague l'objet le plus précis le plus complètement > (normalement > la commune) et les autres objets "supra-communaux" surchargent (à la > manière java) les infos : admin_level=x, name=y, etc. > Dans un raisonnement tautologique, cela s'applique aussi au niveau > communal, mais il reste un way qui n'a plus de sens en soi à part le > fait de dire (ce que tu as fait) qu'il soit une limite administrative. > Je ne souhaite pas lancer le débat ici et maintenant, mais une des > questions est de déterminer s'il faut privilégier uniquement les > relations pour décrire les classes d'objets immatériels ou s'il n'est > pas nécessaire que la brique de base soit porteuse de suffisamment > d'informations pour elle-même. > Personnellement, je voyais la relation "commune" comme étant > l'ordonnancement des ways (dans le sens trigonométrique ?) constituant > la ban communal à partir des limites commune X/commune Y. > A l'assaut du wiki !! > > Denis > > > __
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
g.d a écrit : > Il me semble, > qu'avec cette nouvelle approche par 'relations', > > on rentrerait dans une nouvelle ère à taguer les propriétés d'un objet, > fondamentalement différente de ce qu'on fait jusque-là... Disons que les relations commencent à prendre leur place et je crois que c'est une bonne pratique et un challenge pour les moteurs de rendu et autres applications connexes. > > Par extension, > ce système de 'relations' devrait s'appliquer > à toute propriété non-physique de tous éléments... (?) Ce serait logique. > > Si on voulait être conséquents, > les "tags traditionnels" resteraient réservés aux propriétés physiques > (classification, largeur, état de la voie, nombre de voies...), > > là où les autres attributs plutôt virtuels, non-physiques, > (name, ref, int_ref d'une voie, > la voie à laquelle appartient l'adresse/n° d'une maison, > ou la ligne de métro à laquelle appartient une station, > devraient faire objet d'une 'relation' ? > > (Voire > une buvette ferait partie d'une relation débits de boisson lic III, > un bar ferait partie d'une relation débits de boisson lic IV, > où tous deux feraient partie de la relation restauration ? > Et ne "reste" dans le node que ce qui n'est pas pris en compte par > une relation, > ici le tag "name : "Chez Bidule" ?) > --- > > Le principe me va, > de regrouper plusieurs ways en une "unité supérieure", > comme plusieurs morcaux de limites communales > en une limite de département, > puis en frontière nationale > (la logique de Jérôme me paraît correcte), Oui. Plus précisément et concernant le cas particulier des limites communales, on peut voir cohabiter des tags, au niveau way, comme left:city=a, right:city:b, right:department=c, etc. et, dans le même temps, avoir des relations "commune" avec les tags name=x ou des relations departements avec name=y. L'information peut paraître redondante, mais pas tant que cela, sauf à disposer d'outils qui permettent de retrouver la topologie de l'objet. > > ou de regrouper plusieurs tronçons de ways en une "route européenne E > machin", > "RCEA", > ou "route des châteaux" ou "route Jacques Cœur", > qui eux-mêmes pourraient être dans une relation parcours touristique. > > ok, même si ça fera du travail en sus, > et obligera à huiler des aiguillages rouillées du cerveau... C'est aussi par ces relations que se créera de la plus value par rapport à un simple dessin de ce que chacun a vu dans son coin. A terme, cela devrait engendrer moins de travail : taguer un itinéraire européen un seule fois (en listant l'ensemble de ses composantes) est moins coûteux que de taguer l'ensemble des ways, et moins source d'erreurs (hors to graphe). > > > mais alors OU est la notion de regroupement en unités supérieures > dans la "Relation:restriction", pourtant dans les "established uses" ? > Ça revient à artificiellement introduire une unité qui n'a pas > d'existence, > pour ensuite dire, qu'elle n'existe pas, > ça me paraît absurde... pas sûr d'avoir compris ta pensée. Pour moi, l'avenir de la relation est aussi dans la factorisation des descriptions. C'est plus simple d'écrire : 4x2 plutôt que 2+2+2+2. Aujourd'hui on n'est pas assuré que les outils d'exploitation de la base en donnent comme seul résultat possible 8. C'est un chantier en cours. Pour les restrictions, les relations sont utiles aussi (no-left-turn) car on met aussi de la logique de circulation et donc forcément des liens entre les objets de base. > > Je suis réfractaire à des fonctionnements > qui nécessitent un élément virtuel extérieur. > Oui, je me sers de tels artifices en mathématiques, > mais je regarde l'usage de ces "parachutes" comme une déclaration > d'échec, > comme quoi je n'ai pas réussi à faire face avec mes outils 'propres'. > --- > > Je n'ai rien contre les 'relations', > mais que cela soit > a) conséquent et partout, > b) simple et compréhensible, > c) expliqué sur le wiki, en mots simples. > (et si possible d), des "presets" en cascade pour ça, dans josm... :-) d'accord pour [a-d]. OSM n'est pas gravé dans le marbre (ou le grès des Vosges), laissons-le poursuivre sa maturation. > > Dans l'attente d'éclaircissement > où s'arrête le tag sur node et way, > et où au juste commence la 'relation', > je continue à l'ancienne. > > Gerhard Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> temps, avoir des relations "commune" avec les tags name=x ou des > relations departements avec name=y. L'information peut paraître > redondante, mais pas tant que cela, sauf à disposer d'outils qui > permettent de retrouver la topologie de l'objet. Je prends un peu en cours et je voudrais juste commenter ça. Je pense qu'il faut bannir, comme dans toute base de donnée, la redondance. Et si des relations "commune" voient le jour, il me semble qu'il serait mauvais de s'en servir pour y inclure tous les éléments contenus dans la commune. La logique géographique à cet avantage qu'il existe déjà une relation entre des objets physique (une route) et logique (une commune) : leurs coordonnées. quand je vois les tags : is_in=france ou des trucs comme ça, ça me fout un peu les boules, car cette info découle d'une appartenance à un polygone, et me semble être du temps perdu. Jamais personne ne me verra ajouter des codes postaux à une rue, car ceux-ci sont déductibles de la commune dans laquelle ils sont . . . ou alors j'ai tout faux -- Sylvain Letuffe [EMAIL PROTECTED] qui suis-je : http://slyserv.dyndns.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
sylvain letuffe a écrit : > > Je prends un peu en cours et je voudrais juste commenter ça. Je pense qu'il > faut bannir, comme dans toute base de donnée, la redondance. Et si des > relations "commune" voient le jour, il me semble qu'il serait mauvais de s'en > servir pour y inclure tous les éléments contenus dans la commune. exemples de requête sur la base : - quelles sont les communes adjacentes à la commune X ? - combien de communes composent le département Y, la comcom Z (je sais l'INSEE ou d'autress fournissent déjà la réponse, mais l'idée est de vérifier qu'on est aligné) - il y a-t-il une différence significative entre la morphologie des communes du Kochersberg et celles du pays d'Auge ? > > La logique géographique à cet avantage qu'il existe déjà une relation entre > des objets physique (une route) et logique (une commune) : leurs coordonnées. Je suis foncièrement d'accord, j'utilise PostGIS aussi bien au boulot qu'à la maison, je ne suis pas à convaincre. Je dis simplement que dans l'état actuel de la base (je ne parle pas de celle que l'un ou l'autre a pu monter de son côté) ou de l'API, ces informations apportent une véritable information, pour le moment. > > quand je vois les tags : > is_in=france ou des trucs comme ça, ça me fout un peu les boules, car cette > info découle d'une appartenance à un polygone, et me semble être du temps > perdu. C'est un autre problème qui peut être règlé avec des relations (potentiellement avec une requête spatiale aussi). > > Jamais personne ne me verra ajouter des codes postaux à une rue, car ceux-ci > sont déductibles de la commune dans laquelle ils sont > . > . > . > ou alors j'ai tout faux Non, ta position est largement défendable. Je milite juste pour que des personnes, des applications qui ne peuvent pas (ou ne veulent pas ?) s'appuyer sur les bases de données spatiales, puissent quand même avoir des informations sur les relations entre les objets. Dans le même temps, si OSM décidait de basculer l'entrepôt de données dans PostGIS (ou n'importe quel autre soft équivalent), si OSM décidait de s'aligner sur les standards Open GIS Consortium (notamment les web services géographiques), on ferait un grand pas, mais avec des si on mettrait OSM en bouteilles. Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> Je dis simplement que dans > l'état actuel de la base (je ne parle pas de celle que l'un ou l'autre a > pu monter de son côté) ou de l'API, ces informations apportent une > véritable information, pour le moment. Aussi bien l'état peu changer et nous résoudre le problème, aussi bien quelqu'un va nous écrire une logiciel d'exportation qui rajoutera pour "M. Mysql avec machine au rabais" un logiciel de précalcul qui fasse le boulot. Il nous suffira alors de post-traiter la base. "Don't ask a human what a machine can do" > > quand je vois les tags : > > is_in=france ou des trucs comme ça, ça me fout un peu les boules, car > > cette info découle d'une appartenance à un polygone, et me semble être du > > temps perdu. > > C'est un autre problème qui peut être règlé avec des relations > (potentiellement avec une requête spatiale aussi). Tout a fait ! donc autant ne pas perdre du temps à les remplir. Il ne me faudrait pas plus de 10 jours pour remplir tout les is_in de la terre et sortir un fichier osm les contenant > Non, ta position est largement défendable. Je milite juste pour que des > personnes, des applications qui ne peuvent pas (ou ne veulent pas ?) > s'appuyer sur les bases de données spatiales, puissent quand même avoir > des informations sur les relations entre les objets. Alors post-traitons, pour eux, la donnée, mais ne demandons pas à des humains de le faire. J'utilise beaucoup mysql, je veux savoir dans quel département se trouve quel POI, je tiens à disposition de qui veut la fonction php qui pré-calcul tout ça. (et d'après mes bench sur requêtes postGIS, notre vie n'a pas changée, il faut de toute façon le précalculer ) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
sylvain letuffe a écrit : > Jamais personne ne me verra ajouter des codes postaux à une rue, car ceux-ci > sont déductibles de la commune dans laquelle ils sont > . > . > . > ou alors j'ai tout faux > Bonsoir, Le problème des codes postaux multiples dans une commune correspond à la délimitation d'une zone susceptible d'évoluer dans le temps. Dans les communes de Paris Lyon et Marseille les codes postaux sont accolés de fait à une entité administrative d'où peu de risque de modifications, quoique. Ailleurs c'est rarement le cas. Le simple fait de déménager physiquement l'établissement postal de tri des facteurs le matin va ipso-facto modifier les codes postaux. La ville de Rennes a 3/4 CP non consécutifs de surcroît. Il se trouve que ma grand-mère a vu changer par au moins 2/3 fois son code postal. Il y a donc un non pérennité de l'information sauf à avoir une personne qui surveille en permanence ce que fait La Poste. Je serais donc assez OK avec toi pour dire non à un codage de la rue mais par contre oui à un codage de zone qui sera plus "simple", pas pour moi, de modifier ensuite Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/actes/ Cercle Généalogique (EGE-PTT): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
> Bonsoir, Bonne nuit ;-) > Le problème des codes postaux multiples dans une commune correspond à la > délimitation d'une zone susceptible d'évoluer dans le temps. Argh, merde, ha oui dans ce cas là, ça devient vachement plus chaud alors. > Je serais donc assez OK avec toi pour dire non à un codage de la rue > mais par contre oui à un codage de zone qui sera plus "simple", pas pour > moi, de modifier ensuite Aïe, ce qui reporte le problème à "comment déterminer la zone à codifier" et si cette zone est décidée "au petit bonheur la chance des registres de la poste" on est pas sortie de l'auberge. Tant pis, bien tenté sly ! -- sly ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
sylvain letuffe a écrit : >> Bonsoir, > Bonne nuit ;-) Bonsoir > >> Le problème des codes postaux multiples dans une commune correspond à la >> délimitation d'une zone susceptible d'évoluer dans le temps. > Argh, merde, ha oui dans ce cas là, ça devient vachement plus chaud alors. Comme quoi on ne pense pas à tout. C'est peut-ere cela l'un des pluis gros avantage de la communauté du libre car il y a toujours une personne qui peut signaler une erreur de raisonnement pouvant obérer ensuite le travail de tous. Il peut même arriver qu'une commune change de bureau distributeur donc changement de code postal. J'ai même un cas de commune desservie par 2 bureaux distributeurs différents donc 2 CP différents et ce en fonction de critères exclusivement postaux. Je suis quasiment certains que d'autres cas à la noix existent > >> Je serais donc assez OK avec toi pour dire non à un codage de la rue >> mais par contre oui à un codage de zone qui sera plus "simple", pas pour >> moi, de modifier ensuite > > Aïe, ce qui reporte le problème à "comment déterminer la zone à codifier" et > si cette zone est décidée "au petit bonheur la chance des registres de la > poste" on est pas sortie de l'auberge. Hé oui on est tributaire d'éléments 'non contrôlés' puisque indépendant de notre volonté. D'un autre coté ce n'est pas tous les jours. Sur le sujet CP bizarroïdes je peux donner l'exemple de La Grave (dpt 05) qui est desservie par un bureau distributeur de l'Isère donc cette commune peut, potentiellement, avoir deux codes postaux 05xxx et 38xxx. Ceci a pu être vrai aux origines du système mais je ne pense pas qu'il soit toujours en vigueur car maintenant la mécanisation permet de diriger directement les liasses vers le bon bureau distributeur mais sait-on jamais. Amitiés -- Yannick VOYEAUD http://www.voyeaud.org Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/ Actes En Vrac: http://www.francegenweb/actes/ Cercle Généalogique (EGE-PTT): http://www.cercle-genealogique.fr Inconnu de Saulcy: http://www.lced.org Antoine Payet de la Réunion: http://payet.voyeaud.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Le 25 nov. 08 à 19:46, Yannick a écrit : > J'ai même un cas de commune desservie par 2 bureaux distributeurs > différents donc 2 CP différents et ce en fonction de critères > exclusivement postaux. > Je suis quasiment certains que d'autres cas à la noix existent ... > l'exemple de La Grave (dpt > 05) qui est desservie par un bureau distributeur de l'Isère donc cette > commune peut, potentiellement, avoir deux codes postaux 05xxx et > 38xxx. > Ceci a pu être vrai aux origines du système mais je ne pense pas qu'il > soit toujours en vigueur car maintenant la mécanisation permet de > diriger directement les liasses vers le bon bureau distributeur mais > sait-on jamais. J'ai connu le cas de 20170 San Gavino di Carbini en Corse du Sud (San Gavinu di Càrbini, en langue locale) commune qui a un hameau, nommé Araghju par les gens (et par Michelin), nommé Araggio, Arragio, Arraggio ou encore Arraggiu par l'IGN et par différents Cadastres, au choix, mais introuvable sur aucune liste ! :-( Si on écrit une lettre à quelqu'un à 20170 San Gavino di Carbini Hameau d'Arraggio, ça n'arrive pas, Arraggio étant inconnu au régiment chez les postiers du 20170 :-( Car le bureau distributeur pour Araghu est... 20137 ! Mais si on écrit 20137 San Gavino di Carbini Hameau d'Arraggio (ce qui devrait être correct, car même le Cadastre le dit !) la lettre revient quand même, parce que au bureau 20137, ils ne connaissent pas de "San Gavino" ! Pour qu'une lettre arrive, 'faut écrire 20137 Porto-Vecchio Arraggio ! Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... Mais ça, on l'apprend seulement, si on demande à la secrétaire de la Maire annexe d'Araghju, ou au café/resto... Ça ne figure sur aucun renseignement ou liste que j'ai pu trouver jusqu'ici. Bref, ça cafouille un max, justement because of the informateschenikke. Gerhard ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
g.d wrote: > > Pour qu'une lettre arrive, > 'faut écrire > 20137 Porto-Vecchio > Arraggio > ! > Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... En y réfléchissant, ce n'est pas complètement aberrant que sur une lettre distribuée par la Poste il faille mettre les coordonnées du bureau qui s'occupe d'un hameau plutôt que celles de la commune à laquelle il appartient. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector
Dans les SIG, c'est le code INSEE des communes (vous avez, si vous êtes nés en France, celui de votre commune de naissance dans votre numéro de sécurité sociale) qui est utilisé comme jointure entre les tables, dès lors que l'on traite le niveau administratif. Les communautés de communes ont un numéro analogue à celui des entreprises. Ne serait-il pas logique d'adopter ces numéros normés dans OSM, mais sans que l'OSMeur de base ait à s'en préoccuper? Christian Le 26 nov. 08 à 00:48, Thomas Walraet a écrit : > g.d wrote: >> >> Pour qu'une lettre arrive, >> 'faut écrire >> 20137 Porto-Vecchio >> Arraggio >> ! >> Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... > > En y réfléchissant, ce n'est pas complètement aberrant que sur une > lettre distribuée par la Poste il faille mettre les coordonnées du > bureau qui s'occupe d'un hameau plutôt que celles de la commune à > laquelle il appartient. > > ___ > 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] Limites administratives sur la carte OSM Inspector
Bonjour à tous, Pour compléter ta remarque Christian, au niveau international on utilise le codage NUTS ,(Nomenclature of Territorial Units for Statistics) En effet dès que tu dois comparer des régions ou simuler des itinéraires européens les codes INSEE sont insuffisants. D'où ce référentiel NUTS plus global, c'est un complément au code INSEE . Exemple: Lambesc NIVEAU NUTS 0 | 1 | 2 | 3 | 4 | 5 | FR | 8 | 2 | 4 || 050 |où 050 correspond aux 3 derniers caractères du code INSEE. NUTS0 FR FRANCE NUTS1 FR8 ZONE MEDITERRANEE NUTS2 FR82 REGION PACA NUTS3 FR824DEPARTEMENT BOUCHES-DU-RHÔNE NUTS4 -- NUTS5 FR824050 LAMBESC cf: NUTS Internationaux http://web.archive.org/web/2007070457/http://simap.europa.eu/nomen_nuts/7148f4fa-ad24-9e4d-03e427e0aca09bad_en.html cf: Normes ISO des subdivisions administratives http://fr.wikipedia.org/wiki/ISO_3166-2 > From: [EMAIL PROTECTED] > Date: Wed, 26 Nov 2008 01:53:41 +0100 > To: talk-fr@openstreetmap.org > Subject: Re: [OSM-talk-fr] Limites administratives sur la carte OSM Inspector > > Dans les SIG, c'est le code INSEE des communes (vous avez, si vous > êtes nés en France, celui > de votre commune de naissance dans votre numéro de sécurité > sociale) qui est utilisé comme > jointure entre les tables, dès lors que l'on traite le niveau > administratif. > Les communautés de communes ont un numéro analogue à celui des > entreprises. > Ne serait-il pas logique d'adopter ces numéros normés dans OSM, mais > sans que l'OSMeur de base ait > à s'en préoccuper? > > Christian > > > > > Le 26 nov. 08 à 00:48, Thomas Walraet a écrit : > >> g.d wrote: >>> >>> Pour qu'une lettre arrive, >>> 'faut écrire >>> 20137 Porto-Vecchio >>> Arraggio >>> ! >>> Pourtant, Araghju ne fait pas partie de Porto-Vecchio, rien à voir... >> >> En y réfléchissant, ce n'est pas complètement aberrant que sur une >> lettre distribuée par la Poste il faille mettre les coordonnées du >> bureau qui s'occupe d'un hameau plutôt que celles de la commune à >> laquelle il appartient. >> >> ___ >> 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 _ Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now. hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Bonjour, > De : "Pieren" > > En examinant le "b...l", pardon, le chaos actuel dans les limites > administratives, je me suis demandé s'il était encore pertinent de > conserver 2 relations pour les limites de la France, une avec l'ancien > modèle, et une avec les segments/multilinestring. > L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours > aucun logiciel qui s'en sert. Il faut parfois admettre que même les > bonnnes idées peuvent ne pas être suivies d'effets. > Comme cela alourdie inutilement les éditions (et nous distingue encore > une fois de tous nos voisins du monde), je propose de ne conserver que > l'ancien modèle, en le remettant dans la relation d'origine pour les > frontières terrestres (la 11980) et supprimer la relation 1403916 qui > ferrait alors doublon ainsi que toutes les relations multilinestring > afférantes. > Des opinions ? Sur le principe, j'ai toujours un souci avec une justification comme : "personne ne s'en sert, alors on peut supprimer l'objet xxx". Il est facile de tester osm2pgsql ou imposm pour constater comment ils digèrent (ou pas) ces relations. Mais même si eux ne savent pas s'en dépatouiller, pour moi ça ne permet pas de dire "personne ne s'en sert". C'était une remarque générale car ce type d'argument revient parfois. Quant à la lourdeur d'édition, j'ai aussi du mal avec cet argument concernant les limites admins. Comme d'autres, je répare régulièrement ce contenu (sur la France) et je n'ai jamais eu à récupérer entièrement des entités de type région ou pays pour les remettre d'aplomb. Un site comme http://layers.openstreetmap.fr/ permet de grosses économies de chargement, en permettant de cerner où sont les cassures. Pour revenir au cas présent, ça ne me dérange pas qu'on supprime cette relation si, plutôt que de dire "il n'y a toujours aucun logiciel qui s'en sert", on constate qu'elle est cassée depuis une éternité, et donc non maintenue. Ça me semble un meilleur signe de non-utilisation que l'état des techniques de nous connues qui permettraient de l'exploiter. (Reste à définir l'éternité... ) vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?
Le 20 septembre 2013 15:55, Pieren a écrit : > Bonjour, > > En examinant le "b...l", pardon, le chaos actuel dans les limites > administratives, je me suis demandé s'il était encore pertinent de > conserver 2 relations pour les limites de la France, une avec l'ancien > modèle, et une avec les segments/multilinestring. > L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours > aucun logiciel qui s'en sert. En es-tu réellement sûr? Dans ce cas ces loficiels ne seraient pas du tout capable de traiter les multilinestring et la France n'existerait pas du tout. Il faut peut-être rappeler la raison des multilinestrings : au delà d'une certaine limite, il devient très compliqué de modifier une liste énorme de chemins dans une relation, et les éditeurs ne parviennent me^me plus à charger l'objet (particulièrement les éditeurs en ligne, avec du Javascript et dans un navigateur 32 bits où la mémoire d'un onglet de navigation sature autour de 256Mo avant de commencer à "swapper" énormément ou de tout bonnement se bloquer et refuser de grossir; Et avec les éditeurs écrits en Flash c'est encore plus flagrant). Pour ça on avait donné une estimation de ce qu'une relation raisonnable ne devrait pas dépasser, de l'ordre de 200 membres, même si certaines relations en ont plus (par exemple les relations de régions littorales avec une grande quantité d'îles et îlots ; on sait le problème que ça pose en Bretagne et d'autre régions comparables ailleurs qu'en France comme la Galice, ou plus loin de nous au Canada, en Indonésie, et dans toute la zone pacifique de Polynésie et Mélanésie, où le problème est un peu simplifié en ne créant pas les frontières de base, mais celles des frontières territoriales à 12 nm en s'affranchissant de la complexité des lignes de côtes utilisées plus ou moins comme lignes de base). Oui certains peuvent utiliser un plus gros PC avec plus de 4Go de RAM, un CPU multicoeur rapide, un OS 64 bits et un navigateur ou un éditeur 64 bits mais la tendance est plutôt vers les solutions mobiles plus légères (et moins gourmandes en énergie). En revacnehe du côté des serveurs (y compris les serveurs de rendu) on n'a pas de telles limitations et ils peuvent tout charger et n'ont pas grand peine à charger récursivement des multilinestrings ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
