En fait osmose fait déjà aussi la détection de géométries non valide
http://osmose.openstreetmap.fr/map/?item=1040level=1,2,3
en plus de la détection de polygones non fermées. Avec une méthode qui
doit être très similaire avec ce Sly a du faire.
Frédéric.
Le 15 janvier 2013 20:25, sly (sylvain
- Mail original -
De: sly (sylvain letuffe) li...@letuffe.org
À: Discussions sur OSM en français talk-fr@openstreetmap.org
Envoyé: Mercredi 16 Janvier 2013 00:06:55
Objet: Re: [OSM-talk-fr] Suivi des limites communales ( était Nouvel outil
pour repérer les contributeurs ...)
Le mardi 15
Bonjour,
Concernant cette liste de
communeshttp://openstreetmap.fr/outils/limites-communales-a-importer,
je viens de voir que les 2 premières (Melay et Nuelles) sont en fait des
communes qui se sont récemment regroupées en commune nouvelle avec leur
voisine, et la nouvelle relation apparait bien
C'est corrigé dans le script qui les masque désormais, mais sly devrait
aussi le corriger de son côté.
Le 15 janvier 2013 09:39, Francescu GAROBY windu...@gmail.com a écrit :
Bonjour,
Concernant cette liste de
communeshttp://openstreetmap.fr/outils/limites-communales-a-importer,
je viens
Merci.
Autre remarque, toujours sur cette liste : il est indiqué que le code INSEE
de Saint-Martin est 97127. Hors
Wikipediahttp://fr.wikipedia.org/wiki/Saint-Martin_%28Antilles_fran%C3%A7aises%29et
Merci pour tous ces efforts, à la fois pour la modif de l'outil, et
l'intégration des nouvelles limites !
Le 15 janvier 2013 09:57, Christian Quest cqu...@openstreetmap.fr a écrit
:
C'est corrigé dans le script qui les masque désormais, mais sly devrait
aussi le corriger de son côté.
Le 15
Effectivement 97127 est le code quand Saint-Martin était une commune de la
Guadeloupe (971).
En devenant une COM à part, la COM est codée 978 et comme c'est la seule
commune elle prend le code 01 (en fait c'est la même collectivité qui a les
compétences de la COM, qui inclut celles de du
En fait, même remarque pour Saint-Barthélemy : mauvais code INSEE indiqué
(97701 et non 97123)
Francescu
Le 15 janvier 2013 10:10, Francescu GAROBY windu...@gmail.com a écrit :
Merci.
Autre remarque, toujours sur cette liste : il est indiqué que le code
INSEE de Saint-Martin est 97127. Hors
Non cette fois le code actuel est bien 97701, 97123 c'est l'ancien dans la
Guadeloupe.
On a encore des deux pour retrouver bon nombre de statistiques (il ne me
semble pas y a voir eu de nouveau recensement depuis la sortie du DOM de
Guadeloupe et le passage en COM et la disparition de la commune).
C'est ce que je dis : le code INSEE est 97701 et non 97123.
Francescu
Le 15 janvier 2013 10:29, Philippe Verdy verd...@wanadoo.fr a écrit :
Non cette fois le code actuel est bien 97701, 97123 c'est l'ancien dans la
Guadeloupe.
On a encore des deux pour retrouver bon nombre de statistiques
J'ai récemment fini les communes du Var (83) en raster mais une commune :
GAREOULT (ref:INSEE 83064) est toujours listée dans
http://suivi.openstreetmap.fr/communes/communes.csv.txt alors qu'elle semble ok
dans JOSM et par
Bonjour,
De : Vladimir Vyskocil
J'ai récemment fini les communes du Var (83) en raster
\o/
On devrait pouvoir définir tous les arrondissements du 83 alors :-)
http://layers.openstreetmap.fr/?zoom=9lat=43.56019lon=6.22958layers=0B000FFTTF
mais une commune : GAREOULT (ref:INSEE
On 15 janv. 2013, at 12:26, Vincent de Chateau-Thierry v...@laposte.net wrote:
Bonjour,
De : Vladimir Vyskocil
J'ai récemment fini les communes du Var (83) en raster
\o/
Content que cela fasse plaisir :)
Mais il y a encore du boulot car j'ai vu qu'une partie des communes provient de
Le 15 janvier 2013 14:19, Vladimir Vyskocil vladimir.vysko...@gmail.com a
écrit :
Content que cela fasse plaisir :)
Mais il y a encore du boulot car j'ai vu qu'une partie des communes
provient de GeoFLA dont la précision est vraiment faible. J'ai mis à jour
certaines des limites provenant de
Le 15 janvier 2013 14:19, Vladimir Vyskocil vladimir.vysko...@gmail.com a
écrit :
On devrait pouvoir définir tous les arrondissements du 83 alors :-)
http://layers.openstreetmap.fr/?zoom=9lat=43.56019lon=6.22958layers=0B000FFTTF
Je passe mon tour !
Il ne faut pas oublier comcom
2013/1/15 Christian Quest cqu...@openstreetmap.fr:
Vu la piètre précision de GEOFLA, on avait décidé ici même de ne pas faire
d'import en dehors des nœuds place manquants.
+1
On a déjà eu assez de mal à se débarrasser des limites Cartographes
et associés.
Pieren
Le 15 janvier 2013 14:48, Pieren pier...@gmail.com a écrit :
2013/1/15 Christian Quest cqu...@openstreetmap.fr:
Vu la piètre précision de GEOFLA, on avait décidé ici même de ne pas
faire
d'import en dehors des nœuds place manquants.
+1
On a déjà eu assez de mal à se débarrasser des
Le mardi 15 janvier 2013 14:59:12, Christian Quest a écrit :
Je pense par contre qu'il faudrait généraliser l'outil d'analyse des
limites administrative de sly, pour vérifier la validité des toutes les
relations boundary=* car on en a de plus en plus (administratives,
électorales,
De : Vladimir Vyskocil
Mais il y a encore du boulot car j'ai vu qu'une partie des communes provient
de GeoFLA
dont la précision est vraiment faible. J'ai mis à jour certaines des limites
provenant de
GeoFLA quand elles étaient communes (!) avec les dernières que j'ai entré
depuis le
On 15 janv. 2013, at 14:27, Christian Quest cqu...@openstreetmap.fr wrote:
Le 15 janvier 2013 14:19, Vladimir Vyskocil vladimir.vysko...@gmail.com a
écrit :
Content que cela fasse plaisir :)
Mais il y a encore du boulot car j'ai vu qu'une partie des communes provient
de GeoFLA dont la
Le besoin d'une liste externe c'est pour l'exhaustivité.
Je pensais déjà à juste signaler les boundary=* dont le multipolygone ne
ferme pas...
Le 15 janvier 2013 15:19, sly (sylvain letuffe) li...@letuffe.org a écrit
:
J'ai bien ça en tête, comme on en avait discuté sur IRC, idéalement, avec
2013/1/15 Vladimir Vyskocil vladimir.vysko...@gmail.com:
http://www.openstreetmap.org/browse/relation/2162212 par exemple et d'autres
dans les alentours
Ce way:
http://www.openstreetmap.org/browse/way/161413830
est marqué source=GeoFLA alors que sa résolution semble provenir du cadastre...
On 15 janv. 2013, at 15:46, Pieren pier...@gmail.com wrote:
2013/1/15 Vladimir Vyskocil vladimir.vysko...@gmail.com:
http://www.openstreetmap.org/browse/relation/2162212 par exemple et d'autres
dans les alentours
Ce way:
http://www.openstreetmap.org/browse/way/161413830
est marqué
Il ne le fait que pour les nouveaux objets sans tag source.
C'est clair... GEOFLA: 3 nœuds, vlad+cadastre raster... je compterai pas ;)
Vainqueur: vlad !
Le 15 janvier 2013 15:54, Vladimir Vyskocil vladimir.vysko...@gmail.com a
écrit :
On 15 janv. 2013, at 15:46, Pieren pier...@gmail.com
On Tue, Jan 15, 2013 at 03:37:59PM +0100, Christian Quest wrote:
Le besoin d'une liste externe c'est pour l'exhaustivité.
Je pensais déjà à juste signaler les boundary=* dont le multipolygone ne
ferme pas...
On a déjà une analyse osmose pour vérifier les relation de type boundary et
Tant que j'y pense a propos de ce fil, j'ai ajouté une fonctionnalité à mon
truc de suivi des communes :
http://suivi.openstreetmap.fr/communes/commune_stat.log
C'est pas terrible, difficilement utilisable, mais comme il m'a suffit d'une
commande, je le fourni au cas où.
En gros, ça donne,
Le 15/01/2013 20:25, sly (sylvain letuffe) a écrit :
Tant que j'y pense a propos de ce fil, j'ai ajouté une fonctionnalité à mon
truc de suivi des communes :
http://suivi.openstreetmap.fr/communes/commune_stat.log
C'est pas terrible, difficilement utilisable, mais comme il m'a suffit d'une
Le 15 janvier 2013 20:25, sly (sylvain letuffe) li...@letuffe.org a écrit
:
Tant que j'y pense a propos de ce fil, j'ai ajouté une fonctionnalité à mon
truc de suivi des communes :
http://suivi.openstreetmap.fr/communes/commune_stat.log
C'est pas terrible, difficilement utilisable, mais
Le 15/01/2013 23:35, Philippe Verdy a écrit :
Petite idée : ce serait nettement plus pratique de donner les ids des
deux ways qui se coupent à ces coordonnées (les as-tu encore dans ton
outil ou bien c'est perdu par la transformation OSM vers OpenGIS ?).
Un seul way suffit pour produire le
Le mardi 15 janvier 2013 22:46:28, Vincent de Chateau-Thierry a écrit :
Mais pour Postgis, le coin, parfois, ça dépasse les bornes.
Elle me plaît celle là ;-)
Vous êtes bien avancé hein ?
Finalement oui, en fait :-)
Je viens d'essayer et c'est en effet inutilisable, je n'ai rien réussi
Le 15 janvier 2013 23:53, Vincent de Chateau-Thierry v...@laposte.net a
écrit :
Le 15/01/2013 23:35, Philippe Verdy a écrit :
Petite idée : ce serait nettement plus pratique de donner les ids des
deux ways qui se coupent à ces coordonnées (les as-tu encore dans ton
outil ou bien c'est perdu
On va encore me répondre YAKA, mais tout de même ceux qui s'occupent
des différents scripts français devraient s'entendre entre eux pour
que chacun fasse les références croisées entre les divers outils, afin
d'offrir plus d'intégration entre eux, et aboutir à une convergence
des points de vue ou
http://openstreetmap.fr/outils (disponible via le slideshow à droite)
http://wiki.openstreetmap.org/wiki/FR:Servers#Liste_des_adresses_sur_le_domaine_openstreetmap.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
2013/1/12 Christian Quest cqu...@openstreetmap.fr:
http://openstreetmap.fr/outils (disponible via le slideshow à droite)
Sur le slideshow, donc pas toujours affiché. C'est au petit bonheur la
chance, alors qu'il devrait y avoir une section entière du site sur
les outils qui sont maintenus
Une question en passant : qu'est ce qui explique les écarts entre ces pages
de suivi ?
http://suivi.openstreetmap.fr/communes/communes.csv.txt
http://openstreetmap.fr/outils/limites-communales-a-importer
La seconde a l'avantage de permettre de cibler les relations existantes
mais défaillantes
Le
De : Ab_fab
Une question en passant : qu'est ce qui explique les écarts entre ces pages
de suivi ?
http://suivi.openstreetmap.fr/communes/communes.csv.txt
http://openstreetmap.fr/outils/limites-communales-a-importer
La seconde a l'avantage de permettre de cibler les relations existantes
Ca, c'était avant !
http://lists.openstreetmap.org/pipermail/talk-fr/2012-October/049197.html
Le 8 janvier 2013 16:18, Vincent de Chateau-Thierry v...@laposte.net a
écrit :
De : Ab_fab
Une question en passant : qu'est ce qui explique les écarts entre ces
pages
de suivi ?
De : Ab_fab
Ca, c'était avant !
http://lists.openstreetmap.org/pipermail/talk-fr/2012-October/049197.html
Merci Ab_fab, j'avais loupé ça !
vincent (qui est resté sur l'ancien listing)
PS. Doncta question sur les différences entre les 2 reste entière.
Une messagerie gratuite,
Quelques explications alors...
Le script sur le site web part du fichier CSV généré par le script de sly.
Ensuite il vérifie pour chaque commune son état dans une base France
qui je crois est en mise à jour à la minute (du coup la liste sur le
site est plutôt bien à jour).
Deux tableaux sont
On mardi 8 janvier 2013, Ab_fab wrote:
Une question en passant : qu'est ce qui explique les écarts entre ces pages
de suivi ?
http://suivi.openstreetmap.fr/communes/communes.csv.txt
http://openstreetmap.fr/outils/limites-communales-a-importer
Y'a deux type de développeur dans ce monde :
-
On mardi 8 janvier 2013, Christian Quest wrote:
Quelques explications alors...
Le script sur le site web part du fichier CSV généré par le script de sly.
Ah ! J'ignorais cela. D'ailleurs j'ignorais que ça existait.
Ensuite il vérifie pour chaque commune son état dans une base France
qui je
Et oui, y'a un truc pas clair, que je viens de corriger...
Je pense que c'était une modif malheureuse liées au DOM.
On repasse à 115 communes à importer... je démarre en bas de la liste ;)
Le 8 janvier 2013 17:00, sly (sylvain letuffe) li...@letuffe.org a écrit :
Oui mais là, y'a quand même
On mardi 8 janvier 2013, Christian Quest wrote:
On repasse à 115 communes à importer... je démarre en bas de la liste ;)
Voilà qui paraît déjà plus crédible, mais il n'y a pas 2 tableaux, je ne vois
pas celui dont tu parlais qui devrait indiquer les communes avec bug
Puis-je humblement
43 matches
Mail list logo
