Re: [OSM-talk-fr] pharmacie, dispensing
Elle devrait être ' \b[P|p]harmacie\b http://regexr.com/39r2h’ mais overpass ne supporte pas les \b. Oui, overpass utilise les expressions rationnelles posix, donc pas moyen de chercher les débuts ou fins de mots :-( J’ai écrit un ticket https://github.com/drolbr/Overpass-API/issues/146 proposant d’utiliser la bibliothèque de code PCRE (utilisée par PHP, R…). Les expressions sont compatibles avec celles de Javascript, Perl… D’ailleurs je ne sais pas si et comment on peut lui passer des flags i (ignore case) g (global) et m (multiline). Des pistes ? En étudiant le code source, il est possible d’utiliser l’option « ignorer la casse » mais uniquement en Overpass-XML : has-kv k=name regv=pharmacie case=ignore »/ Cette expression trouvera « Pharmacie », « PHARMACIE », « pharmacie »… — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] highway=trunk en France
Coucou, Jérôme Amagat wrote Si la voie express en agglo est remplacé par une voie non express au même endroit la vitesse passe de 90 (ou 70) à 50 donc la voie express permet bien d'aller plu vite même si a un autre endroit tu peux rouler encore plus vite. Donc en gros l'idée est de désigner le cas des 2x2 voies, sens unique, vitesse inférieure à 110 km/h (90 ou 70) avec ou sans panneau C107 dans les agglomérations en highway=trunk, et highway=primary hors agglomérations ? Cordialement. -- View this message in context: http://gis.19327.n5.nabble.com/highway-trunk-en-France-tp5821793p5822602.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] highway=trunk en France
Bonjour, J'ai l'impression que le débat tourne autour de la vitesse sur ce sujet des trunk. Attention en France, les voies pour automobile C107 (voie expresse) sont réglementé et par définition sont par de nombreuses caractéristiques implicites (sauf panneaux pour caractéristique explicites) - Vitesse 110km/h - Présence de véhicule lent (les connues, agricole,piéton, cyclo,.. mais aussi les fauteuil roulant de vitesse supérieur à 6km, traction animale, .. - Affichage publicitaire en bord de voies 40m - interdiction de faire demi-tour (pour les C107 à double voies) - Voie d'arrêt d'urgence - Réglementation sur le dépannage : http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT29097784dateTexte=categorieLien=id Si on met les C107 en primary pour des raisons de vitesse ou de 2x2 voies alors il faudra de façon exhaustive indiqué toutes les caractéristiques ci-dessus. - Si grâce aux positionnement des panneaux publicitaire (http://www.cartographiepublicitaire.org/) on veut vérifier leurs distances à la voies. - Si une personne avec fauteuil électrique (6km/h) utilise sont GPS pour circuler sur primary (il a le droit) risque de se retrouver sur une voie C107 - Si un garagiste veux dépanner sur une primary il risque de se voir intervenir illégalement sur une voie expresse Si ponctuellement une C107 est autorisée aux véhicules agricoles, limitée à 90Km, à double sens, il existe des tag pour indiquer cela. il est tellement plus simple en France Autoroute : motorway Voie express (C107) : Trunk les autres des fois 110Km/h des fois non Pour les Voie expresse C107, la vitesse maxi n'est-elle pas caractéristique mineures par rapport à toutes les autres ??? -- View this message in context: http://gis.19327.n5.nabble.com/highway-trunk-en-France-tp5821793p5822612.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] highway=trunk en France
Il ne fqudrait pas être aussi catégorique. 2x2 voies hors agglo peut aussi être par endroit li,ité à moins de 110 avec le panneau C107 et ne devrait pas passer en highway=pri,ary mais rester en trunk. Notamment dans les prolongements d'autoroutes ou routes nationales/départementales/départementales en voie de classement autoroutier et dont les accès sont protégés avec de vraies échangeurs. Même la présence d'un grand rond-point ne devrait pas gêner (bien que cela se trouve plutot alors assez prêt des agglomérations. La classification des nationales/départementales/métropolitaines n'est plus un guide depuis que l'Etat et les collectivités se transfèrent des compétences sur le réseau routier (de mêmetoutes les autoroutes ne sont pas concédées à des sociétés privées, et toutes les autoroutes ne sont pas payantes). On doit plus se baser sur la topologie des lieux et notamment les interdictions d'accès, la présence de bretelles; de voies d'accélération, de voies d'arrêt d'urgence, le ryaon d ecourbure des virages... Sinon que dire de la nationale qui autour d'Avranche joint les deux segments de l'A84 (mais se prolonge ensuite en suivant la cote vers Saint-Malo via un imposant échangeur où sont connectées aussi d'autres départementales): plus de trunk, passage en primary ? Si cette section n'a pas été classée officiellement A84, c'est parce que l'Etat l'a encore en charge (pas de transfert aux deux régions basse-normande et bretonne ni de concession à la société d'autoroute qui prend en charge les segments calssés A84; dont la section bretonne sans péage vers Rennes). Toute cette section n'est pas dans l'agglomération d'Avranche. et on ne devrait pas soudaiement passer en trunk juste dans cette agglomération (alors que la vitesse y est plus réduite que sur le reste). Il y a le C107 pourtant partout sur cette section de nationale (dont la classification en autoroute pose problème justement dans l'agglomération où cette section sert aussi de rocade urbaine puisque le projet de contournement autoroutier séparé d'Avranche n'a pas été retenu, a collectivité ayant préféré améliorer la voie existante pour faire la jonction autoroutière)... D'ailleurs cet axe fait partie du tracé de la route européenne dite autoroute des estuaires alors que ce trajet emprunte encore diverses nationales et départementales; pas toutes encore en 2x2 voies mimimum; notammeent au sud de Nantes avant l'A81 via l'ancienne N137 découpée en départementales dont certaines sont progressivement déclassées; et où il manque encore la partie en Sud-Vendée entre La Roche-sur-Yon et la Rochelle; où le projet d'autoroute évitant le long contournement très à l'Est autour de Niort est encore suspendu dans les marais vendéens et charentais et où les départementales déclassées sont aussi urbanisés avec des carrefours, feux et limites abaissées régulièrement à 70, 50 ou même 30 dans les traversées de villages par des carrefours non protégés). A l'heure actuelle la route euopéenne passe encore par cette autoroute Nantes-Niort Est avant de reproendre l'autoroute Paris-Poitiers-Bordeaux et pas de liaison vers la Rochelle (et le secteur de Niort-Est est régulièrement bouchonné par le trafic Poitiers-Bordeaux) D'ailleurs si on regarde les motorways au Royayme-Uni, la plupart ne mériteraient même pas la classification de déartementale en France et certaines n'ont même pas de séparation centrale et ont des carrefours non protégés autrement que par des stops (pas de bretelle; voie d'accélération ou de sortie inexistante ou juste construite par une réducton du nombre de voies transverses (obligation de rabattement/fusion de voies; et même des limites de vitesse très basses à ces endroits. Cependant les Britanniques ont gardé la classification basée sur la numérotation officielle et le fait que ces routes constituent un maillage router de base pour les liaisons interurbaines et périurbaines. En France c'est un peu bordélique à cause du nombre croissant d'acteurs dans les transports et du fait des transferts de plus en plus nombreux entre collectivités, Etat et acteurs privés. Les schémas de transport sont en pleine refonte, les budgets limités et il y a de nombreuses oppositions locales pour certains grands travaux (et en zone périrurbaine il y a une pression immobilière i,portante avec une inflation des prix des terrains, plus de nombreuses nouvelles contraintes de sécurité et environnementales, et certaines lois récentes en France ou aux frontières n'ont rien arrangé pour gérer le trafic longue distance notamment celui des poids-lourds). On ne peut plus facilement fixer de règle absolue, c'est une série d'adaptations locales, les schémas sont en plein bouleversement mais les travaux eux son dispersés et prendront des décennies. Le 1 novembre 2014 11:17, Axelos axe...@broman.fr a écrit : Coucou, Jérôme Amagat wrote Si la voie express en agglo est remplacé par une voie non express au même endroit la vitesse passe de 90 (ou 70) à 50 donc la voie express
Re: [OSM-talk-fr] pharmacie, dispensing
En étudiant le code source, il est possible d’utiliser l’option « ignorer
la casse » mais uniquement en Overpass-XML :
has-kv k=name regv=pharmacie *case=ignore »*/
Nonnonon :-) Le flag ignorecase se met avec une *,i* derrière voir le code
en dessous. il n'y a pas d'échappement car celui-ci et fait dans le code.
Pour le multiligne c'est pas accepté dans les valeurs et pour prendre
généralement tu commeces par ^ et fini par $.
La requête renvoie toute les noms commençant par pharmacie et (sans
contrainte de case) et dispensing=no
[out:json][timeout:250];
// gather results
(
// query part for: “dispensing=no” and name~(^pharmacie)(.*$)*,i*
node[dispensing=no][name~(^pharmacie)(.*$)*,i*]({{bbox}});
node[dispensing=no][name~(^pharmacie)(.*$)*,i*]({{bbox}});
node[dispensing=no][name~(^pharmacie)(.*$)*,i*]({{bbox}});
);
// print results
out body;
;
out skel qt;
Je teste un autre requête ce soir pour compléter les cas invalides
Le 1 novembre 2014 10:16, Yves Pratter yves.prat...@gmail.com a écrit :
Elle devrait être ' \b[P|p]harmacie\b http://regexr.com/39r2h’ mais
overpass ne supporte pas les \b.
Oui, overpass utilise les expressions rationnelles posix, donc pas moyen
de chercher les débuts ou fins de mots :-(
J’ai écrit un ticket https://github.com/drolbr/Overpass-API/issues/146
proposant
d’utiliser la bibliothèque de code PCRE (utilisée par PHP, R…).
Les expressions sont compatibles avec celles de Javascript, Perl…
D’ailleurs je ne sais pas si et comment on peut lui passer des flags i
(ignore case) g (global) et m (multiline).
Des pistes ?
En étudiant le code source, il est possible d’utiliser l’option « ignorer
la casse » mais uniquement en Overpass-XML :
has-kv k=name regv=pharmacie *case=ignore »*/
Cette expression trouvera « Pharmacie », « PHARMACIE », « pharmacie »…
—
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] pharmacie, dispensing
Nonnonon :-) Le flag ignorecase se met avec une ,i derrière voir le code en
dessous. il n'y a pas d'échappement car celui-ci et fait dans le code.
Merci, je n’avais pas repéré cette partie du code :-)
Donc en résumé, pour ignorer la casse dans une expression rationnelle dans
Overpass, on utilise la syntaxe had hoc :
[‘clé’~’expression’,i]
has-kv k=« clé regv=« expression case=ignore »/
La requête renvoie toute les noms commençant par pharmacie et (sans
contrainte de case) et dispensing=« no »
Il y a aussi les noms se terminants par pharmacie : « Grande pharmacie »
Une autre façon de faire, c’est de prendre les objets le nom contenant «
pharmacie » puis d’exclure ceux qui contiennent « parapharmacie » (en attendant
que les expressions Perl soient utilisables)
node[dispensing=no][name~(pharmacie)(.*$),i][« name!~
»(parapharmacie)(.*$),i]({{bbox}});
[out:json][timeout:250];
// gather results
(
// query part for: “dispensing=no” and name~(^pharmacie)(.*$),i
node[dispensing=no][name~(^pharmacie)(.*$),i]({{bbox}});
node[dispensing=no][name~(^pharmacie)(.*$),i]({{bbox}});
node[dispensing=no][name~(^pharmacie)(.*$),i]({{bbox}});
Tu recherches 3 fois la même chose ? ;-)
ça donne ça pour un export vers JOSM : http://overpass-turbo.eu/s/5II
http://overpass-turbo.eu/s/5II
—
Yves___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] highway=trunk en France
Bonjour, J'interviens un peu tardivement sur le sujet, ayant eu de fortes occupations cette semaine. Le 01/11/2014 12:23, osmien a écrit : J'ai l'impression que le débat tourne autour de la vitesse sur ce sujet des trunk. Attention en France, Je crois que le problème, c'est d'attaquer au niveau national. Chacun dans son pays a proposé une détermination souvent sur des critères administratifs. Par exemple, en Angleterre, une classification de route a été retenue. Quand on regarde, on constate qu'une partie des dites routes ont tout juste un caractère régional. Résultat, les primary qui sont sensées assurer des liaisons nationales assurent des dessertes assez locales et semblent en nombre inférieur au trunk, ce qui va à l'encontre d'une hiérarchisation du réseau. Il y a le cas de l'Argentine cité par Pieren où les trunk sont utilisées massivement mais ont cannibalisé les niveaux inférieurs. Certains se sont dit aussi qu'il n'y avait pas de raison de ne pas utiliser de trunk dans les pays d'Afrique où le réseau routier était peu développé. Alors même que le faible développement du réseau rend difficile une hiérarchisation, on se retrouve en Somalie avec des trunk pour des routes qui doivent être à peu près goudronnées et des primary pour des pistes de quelques dizaines de kilomètres desservant un seul bled. Zone typique: http://osm.org/go/wriddA?relation=192799 Je vous laisse regarder sur Bing la tête de la primary suivante: http://osm.org/go/wq9KUXo--?relation=192799 Enfin, avec l'avancement d'OSM, on se rend compte que les données implicites, au niveau d'un pays par exemple, deviennent difficiles à gérer quand on veut globaliser à l'échelle mondiale. Si on part sur trunk = route pour automobile en France (ce que j'ai aussi soutenu à une époque), ça veut dire que pour obtenir les restrictions correspondantes, il faut faire des requêtes si (highway=trunk) et (highway en France) alors maxspeed=110, pas de tracteur, pas de vélo... sauf indications contraires. Et ceci à coder pour les 150 pays de la planètes dans tous les logiciels d'utilisation des données. Donc, je suis pour repartir sur une définition générique et plutôt que le longue distance de la définition initiale, voie express me paraît pas mal. Après, chaque pays peut donner des indication suivant le développement de son réseau routier. Par exemple, en France, on pourrait imaginer les voies à chaussées séparées non autoroutières mais éventuellement aussi les 2x1 non séparées disposant d'échangeurs comme certains contournements de ville. Ensuite, on explicite les aspects réglementaires avec motorroad, maxspeed, access=*... Inversement, un pays qui n'aurait pas de 2x2 non autoroutières mais des nationales bien profilées et contournant les villages pourrait les recommander pour trunk surtout s'il existe d'autres routes structurantes à l'échelle du pays mais moins bonnes et/ou moins rapides. Éric ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Intégration des gares et code uic_ref
Bonjour, La gare (rer, champigny) près de chez moi est signalé en erreur par Osmose: Gare sans uic_ref ou invalide. L'aide n'est pas d'un grand secours, l'item 7100 envoie au 8050 et 8051. Le 8051 renvoie à lui-même :-( http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#7100 http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#8050 http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#8051 Est-ce que les gares RER gérés par la RATP ont un identifiant ? Si oui, comment trouver le code 'uic_ref' d'une gare (Sachant qu'il n'y a pas d'item 8051 dans osmose) ? Cdt Black Myst ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Intégration des gares et code uic_ref
j'ai retrouvé ca : http://permalink.gmane.org/gmane.comp.gis.openstreetmap.region.fr/59263 Le samedi 01 novembre 2014 à 21:56 +0100, Black Myst a écrit : Bonjour, La gare (rer, champigny) près de chez moi est signalé en erreur par Osmose: Gare sans uic_ref ou invalide. L'aide n'est pas d'un grand secours, l'item 7100 envoie au 8050 et 8051. Le 8051 renvoie à lui-même :-( http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#7100 http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#8050 http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#8051 Est-ce que les gares RER gérés par la RATP ont un identifiant ? Si oui, comment trouver le code 'uic_ref' d'une gare (Sachant qu'il n'y a pas d'item 8051 dans osmose) ? Cdt Black Myst ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] intersection entre communes ???
Je ne comprend pas ce que fait là cette détection entre une frontière internationale (qui est aussi une rue à cet endroit, mais c'est secondaire car on a des erreurs de même type sans ça) et un landuse rédidentiel (qui n'a rien d'une commune). On dirait qu'Osmose tente de trouver des villages qui pourraient éventuellement être des subdivisions d'une commune, alors que les agglomérations n'ont rien à voir avec les villages en tant que tels, et encore moins avec les zones résidentielles d'un découpage d'utilisation des sols (où on trouve d'autres usages comme des forêts, zones d'activité commerciale ou industrielle; parcs et jardins...) Je ne suis pas convaincu de la méthode (qui ne fonctionne pas plus en Belgique où les sections communales (niveau 9) sont en fait l'ancien découpage des communes avant leur fusion massive (totalement indépendant des zones résidentielles et villages), et où les sous-sections sont des quartiers administratifs eux aussi indépendant des utilisations de sols. Peut-être que c'est adapté à l'Afrique où le découpage administratif est à l'état d'ébauche, mais pas du tout en Europe (et surtout pas les landuse issus du vieil import CORINE comme ici) Voici l'erreur rapportée par Osmose: *Intersection entre communes* *way 41904064 http://www.openstreetmap.org/browse/way/41904064* rawedit http://osmose.openstreetmap.fr/fr/map/# josm http://localhost:8111/load_object?objects=w41904064 edit http://osmose.openstreetmap.fr/fr/map/# *source* = Union européenne - SOeS, CORINE Land Cover, 2006. *landuse* = residential *CLC:id* = FR-1644 *CLC:code* = 112 *CLC:year* = 2006 *way 293523268 http://www.openstreetmap.org/browse/way/293523268* rawedit http://osmose.openstreetmap.fr/fr/map/# josm http://localhost:8111/load_object?objects=w293523268 edit http://osmose.openstreetmap.fr/fr/map/# *admin_level* = 2 *name* = Rue Dombrie *surface* = asphalt *source* = cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2012 *border_type* = nation *boundary* = administrative *highway* = service Erreur reportée le : 2014-11-01 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] pharmacie, dispensing
Donc en résumé, pour ignorer la casse dans une expression rationnelle dans
Overpass, on utilise la syntaxe had hoc :
- [‘clé’~’expression’,i]
- has-kv k=clé regv=expression case=ignore /
Je teste mes regex avec ce *site http://regex101.com/#python en mode
python. *c'est une tuerie pour tester les chaines. tu peux y ajouter le
modifier i dans la 2eme textbox qui suit la chaine regex
La requête renvoie toute les noms commençant par pharmacie et (sans
contrainte de case) et dispensing=« no »
Il y a aussi les noms se terminants par pharmacie : « Grande pharmacie »
Ah oui en effet
Une autre façon de faire, c’est de prendre les objets le nom contenant
« pharmacie » puis d’exclure ceux qui contiennent « parapharmacie » (en
attendant que les expressions Perl soient utilisables)
node[dispensing=no][name~(pharmacie)(.*$),i]
[name!~(parapharmacie)(.*$),i]({{bbox}});
Oui c'est le seul moyen je pense car overpass n'accepte pas
l'assertion (negative
look-ahead (?!) )
*name~((pharmacie)(?!parapharmacie),i*
ca fonctionne pas cela!
// query part for: “dispensing=no” and name~(^pharmacie)(.*$)*,i*
node[dispensing=no][name~(^pharmacie)(.*$)*,i*]({{bbox}});
node[dispensing=no][name~(^pharmacie)(.*$)*,i*]({{bbox}});
node[dispensing=no][name~(^pharmacie)(.*$)*,i*]({{bbox}});
Tu recherches 3 fois la même chose ? ;-)
Euh je crois que j'ai oublié de changer en *way *et *relation *suite à ma
copie
ça donne ça pour un export vers JOSM : http://overpass-turbo.eu/s/5II
Oui sauf que j'avais en effet fait ça on pensant avoir toujours le mot
pharmacie au début
[dispensing=no][name~pharmacie,i][name!~parapharmacie,i]
C'est suffisant
—
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] pharmacie, dispensing
Je teste mes regex avec ce site http://regex101.com/#python en mode python. c'est une tuerie pour tester les chaines. tu peux y ajouter le modifier i dans la 2eme textbox qui suit la chaine regex Ben moi j’utilise ces 2 là : http://www.regexr.com http://www.regexr.com/ https://www.debuggex.com https://www.debuggex.com/ Le second fait un joli graphique de l’expression ;-) Le tient affiche le détail de \b c’est (^\w|\w$|\W\w|\w\W) aagg c'est une tuerie pour tester les chaines C’est la citation pour halloween ou pour la Toussaint ?? :-D Oui c'est le seul moyen je pense car overpass n'accepte pas l'assertion (negative look-ahead (?!) ) C’est les ERE POSIX qui n’acceptent pas ça ;-) name~((pharmacie)(?!parapharmacie),i ca fonctionne pas cela! Faudrait essayer avec (^\w|\w$|\W\w|\w\W)pharmacie C'est suffisant Oh oui… Bonne nuit, — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] intersection entre communes ???
Bonjour, Selon moi, ca vient du fait que la zone CORINE fait partie de la même relation que les frontières classiques (admin_level 2 dans ton exemple). Osmose n'a aucune raison de les considérer différemment et les voit comme deux frontières au même niveau qui se croisent... D'autre part, la frontière en question ne semble pas complète, il manque la Rue des Fèves. Est ce que ce ne serait pas une erreur de selection qui fait que la zone CORINE a fini dans la relation à la place de cette rue? Cdlt, From: verd...@wanadoo.fr Date: Sat, 1 Nov 2014 23:59:34 +0100 To: talk-fr@openstreetmap.org Subject: [OSM-talk-fr] intersection entre communes ??? Je ne comprend pas ce que fait là cette détection entre une frontière internationale (qui est aussi une rue à cet endroit, mais c'est secondaire car on a des erreurs de même type sans ça) et un landuse rédidentiel (qui n'a rien d'une commune). On dirait qu'Osmose tente de trouver des villages qui pourraient éventuellement être des subdivisions d'une commune, alors que les agglomérations n'ont rien à voir avec les villages en tant que tels, et encore moins avec les zones résidentielles d'un découpage d'utilisation des sols (où on trouve d'autres usages comme des forêts, zones d'activité commerciale ou industrielle; parcs et jardins...) Je ne suis pas convaincu de la méthode (qui ne fonctionne pas plus en Belgique où les sections communales (niveau 9) sont en fait l'ancien découpage des communes avant leur fusion massive (totalement indépendant des zones résidentielles et villages), et où les sous-sections sont des quartiers administratifs eux aussi indépendant des utilisations de sols. Peut-être que c'est adapté à l'Afrique où le découpage administratif est à l'état d'ébauche, mais pas du tout en Europe (et surtout pas les landuse issus du vieil import CORINE comme ici) Voici l'erreur rapportée par Osmose: Intersection entre communes way 41904064 rawedit josm edit source = Union européenne - SOeS, CORINE Land Cover, 2006. landuse = residential CLC:id = FR-1644 CLC:code = 112 CLC:year = 2006 way 293523268 rawedit josm edit admin_level = 2 name = Rue Dombrie surface = asphalt source = cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2012 border_type = nation boundary = administrative highway = service Erreur reportée le : 2014-11-01 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] intersection entre communes ???
Non tu lis mal, il s'agit de deux ways distincts qui ne sont pas dans les mêmes relations. Et ça se produit ailleurs, Osmose se trompe ou alors utilise des données pas à jour Le 2 novembre 2014 01:03, Ronan Morin ronan_mo...@hotmail.com a écrit : Bonjour, Selon moi, ca vient du fait que la zone CORINE fait partie de la même relation que les frontières classiques (admin_level 2 dans ton exemple). Osmose n'a aucune raison de les considérer différemment et les voit comme deux frontières au même niveau qui se croisent... D'autre part, la frontière en question ne semble pas complète, il manque la Rue des Fèves. Est ce que ce ne serait pas une erreur de selection qui fait que la zone CORINE a fini dans la relation à la place de cette rue? Cdlt, -- From: verd...@wanadoo.fr Date: Sat, 1 Nov 2014 23:59:34 +0100 To: talk-fr@openstreetmap.org Subject: [OSM-talk-fr] intersection entre communes ??? Je ne comprend pas ce que fait là cette détection entre une frontière internationale (qui est aussi une rue à cet endroit, mais c'est secondaire car on a des erreurs de même type sans ça) et un landuse rédidentiel (qui n'a rien d'une commune). On dirait qu'Osmose tente de trouver des villages qui pourraient éventuellement être des subdivisions d'une commune, alors que les agglomérations n'ont rien à voir avec les villages en tant que tels, et encore moins avec les zones résidentielles d'un découpage d'utilisation des sols (où on trouve d'autres usages comme des forêts, zones d'activité commerciale ou industrielle; parcs et jardins...) Je ne suis pas convaincu de la méthode (qui ne fonctionne pas plus en Belgique où les sections communales (niveau 9) sont en fait l'ancien découpage des communes avant leur fusion massive (totalement indépendant des zones résidentielles et villages), et où les sous-sections sont des quartiers administratifs eux aussi indépendant des utilisations de sols. Peut-être que c'est adapté à l'Afrique où le découpage administratif est à l'état d'ébauche, mais pas du tout en Europe (et surtout pas les landuse issus du vieil import CORINE comme ici) Voici l'erreur rapportée par Osmose: *Intersection entre communes* *way 41904064 http://www.openstreetmap.org/browse/way/41904064* rawedit http://osmose.openstreetmap.fr/fr/map/# josm http://localhost:8111/load_object?objects=w41904064 edit http://osmose.openstreetmap.fr/fr/map/# *source* = Union européenne - SOeS, CORINE Land Cover, 2006. *landuse* = residential *CLC:id* = FR-1644 *CLC:code* = 112 *CLC:year* = 2006 *way 293523268 http://www.openstreetmap.org/browse/way/293523268* rawedit http://osmose.openstreetmap.fr/fr/map/# josm http://localhost:8111/load_object?objects=w293523268 edit http://osmose.openstreetmap.fr/fr/map/# *admin_level* = 2 *name* = Rue Dombrie *surface* = asphalt *source* = cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2012 *border_type* = nation *boundary* = administrative *highway* = service Erreur reportée le : 2014-11-01 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] intersection entre communes ???
Je n'avais pas regarde le côté Belge, la zone Corine figure effectivement, à tord, dans la relation de frontière postale (pas la commune belge), c'est la zone Corine (un way simple fermé) qui déborde un peu sur la France; il n'y a aucune ano,alie sur les frontières françaises, mais ça sent une mauvaise sélection de chemin pour fermer la zone postale. De toute façon le diagnostic Osmose est faux. Mais il y a plein d'autres cas où les landuse résidentiels ne sont dans aucune relation et sont considérés à tord comme des frontières adminstratives alors qu'il n'y a rien de tel aucune relation frontière dont elles dont partie, aucun tag pour l'indiquer sur le chemin. Il y en a un paquet et c'est en train de se miltiplier. Je ,e demande si ce n'est pas la base Osmose qui n'est plus synchronisée et commence à tout mélanger (peut-être des oublis dans le rattrapage du retour dû à la panne d'il y a quelques jours sur sa base Monde). Le 2 novembre 2014 01:03, Ronan Morin ronan_mo...@hotmail.com a écrit : Bonjour, Selon moi, ca vient du fait que la zone CORINE fait partie de la même relation que les frontières classiques (admin_level 2 dans ton exemple). Osmose n'a aucune raison de les considérer différemment et les voit comme deux frontières au même niveau qui se croisent... D'autre part, la frontière en question ne semble pas complète, il manque la Rue des Fèves. Est ce que ce ne serait pas une erreur de selection qui fait que la zone CORINE a fini dans la relation à la place de cette rue? Cdlt, -- From: verd...@wanadoo.fr Date: Sat, 1 Nov 2014 23:59:34 +0100 To: talk-fr@openstreetmap.org Subject: [OSM-talk-fr] intersection entre communes ??? Je ne comprend pas ce que fait là cette détection entre une frontière internationale (qui est aussi une rue à cet endroit, mais c'est secondaire car on a des erreurs de même type sans ça) et un landuse rédidentiel (qui n'a rien d'une commune). On dirait qu'Osmose tente de trouver des villages qui pourraient éventuellement être des subdivisions d'une commune, alors que les agglomérations n'ont rien à voir avec les villages en tant que tels, et encore moins avec les zones résidentielles d'un découpage d'utilisation des sols (où on trouve d'autres usages comme des forêts, zones d'activité commerciale ou industrielle; parcs et jardins...) Je ne suis pas convaincu de la méthode (qui ne fonctionne pas plus en Belgique où les sections communales (niveau 9) sont en fait l'ancien découpage des communes avant leur fusion massive (totalement indépendant des zones résidentielles et villages), et où les sous-sections sont des quartiers administratifs eux aussi indépendant des utilisations de sols. Peut-être que c'est adapté à l'Afrique où le découpage administratif est à l'état d'ébauche, mais pas du tout en Europe (et surtout pas les landuse issus du vieil import CORINE comme ici) Voici l'erreur rapportée par Osmose: *Intersection entre communes* *way 41904064 http://www.openstreetmap.org/browse/way/41904064* rawedit http://osmose.openstreetmap.fr/fr/map/# josm http://localhost:8111/load_object?objects=w41904064 edit http://osmose.openstreetmap.fr/fr/map/# *source* = Union européenne - SOeS, CORINE Land Cover, 2006. *landuse* = residential *CLC:id* = FR-1644 *CLC:code* = 112 *CLC:year* = 2006 *way 293523268 http://www.openstreetmap.org/browse/way/293523268* rawedit http://osmose.openstreetmap.fr/fr/map/# josm http://localhost:8111/load_object?objects=w293523268 edit http://osmose.openstreetmap.fr/fr/map/# *admin_level* = 2 *name* = Rue Dombrie *surface* = asphalt *source* = cadastre-dgi-fr source : Direction Générale des Impôts - Cadastre. Mise à jour : 2012 *border_type* = nation *boundary* = administrative *highway* = service Erreur reportée le : 2014-11-01 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
