Re: [OSM-talk-fr] expérimentations à Orange
Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.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] expérimentations à Orange
pourquoi le zéro ? Ce n'est pas un code comme l'Insee c'est une valeur numérique propre à OSM, et on ne met jamais ces zéros dans les admin_level Le 14 avril 2013 09:58, Tony Emery tony.em...@yahoo.fr a écrit : Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Civilités et incivilités sur OSM-fr
Le 13 avril 2013 15:48, Philippe Verdy verd...@wanadoo.fr a écrit : Mais voilà on me demande d'accepter ça sans me défendre. On va même inventer un mépris en amont de ma part En amont qui est bien un présupposé total sur ce que je n'ai pas dit. Bref une création de l'esprit d'un autre dont je devrais m'excuser... Au lieu de t'embarquer dans la contemplation des injustices dont tu serais victime, je te suggère : 1) Malgré les tonnes de tonnes de messages que tu envoies, je crois ne t'avoir jamais vu reconnaître que tu t'étais trompé dans une de tes affirmations. Remarquable performance certes, mais complètement contre-productive dans un groupe de discussion... Au départ tente, de temps en temps, l'exercice de la concession. Et puis, quand tu auras vu que c'est sans danger particulier, envisage que tu puisses te tromper complètement dans une circonstance extraordinaire. 2) Prend un jour de vacances par semaine (le dimanche ? )... Ferme ton ordi, ou au moins ne fais rien sur osm, fais une pause ou ce genre de choses. Médite. Respire. Sors. Distrais-toi. Pour terminer sur une note positive, j'ai remarqué que certains de tes messages étaient courts, et même dans le sujet :-) En effet, je continue à lire tes messages, moi :-) Donc c'est bon :-) Cordialement. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Le 14 avril 2013 10:20, Philippe Verdy verd...@wanadoo.fr a écrit : pourquoi le zéro ? Ce n'est pas un code comme l'Insee c'est une valeur numérique propre à OSM, et on ne met jamais ces zéros dans les admin_level Le 14 avril 2013 09:58, Tony Emery tony.em...@yahoo.fr a écrit : Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Bonjour, Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Tout à fait d'accord, ce n'est pas mon idée de n'utiliser que l'admin_level qui n'est pas suffisant (on a des tas de données qui pourraient provenir de jeux sources maintenues par plusieurs communes simultanément sans qu'on puisse savoir laquelle, ou de plusieurs départements ou plusieurs régions j'avais déjà plaidé vers une identification des sources par leur code INSEE quand ce sont des collectivités. Au moins ça évitait les collision dans l'espace ref:FR:* et c'était assez court pour ne pas surcharger la base avec des clés interminables. Sinon une alternative au code INSEE est le code département suivi d'une abréviation du nom de la commune (par exemple ref:FR:35REN=* pour indiquer une source de la ville de Rennes et ref:FR:35CES=* pour Cesson-Sévigné sa voisine. Mais c'est inventer une nouvelle codification pour rien... Le 14 avril 2013 11:14, Christian Quest cqu...@openstreetmap.fr a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Le 14 avril 2013 10:20, Philippe Verdy verd...@wanadoo.fr a écrit : pourquoi le zéro ? Ce n'est pas un code comme l'Insee c'est une valeur numérique propre à OSM, et on ne met jamais ces zéros dans les admin_level Le 14 avril 2013 09:58, Tony Emery tony.em...@yahoo.fr a écrit : Est-on d'accord pour que je modifie ref:orange et ref:FR:08 ou ref:FR:admin_level_08 ? -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757001.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ 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] expérimentations à Orange
Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_**level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] expérimentations à Orange
Je peux prendre une exemple extrême mais réel : la maison de Victor Hugo située à Guernesey (Hauteville House) est entièrement gérée par la Mairie de Paris (avec le drapeau français à l'entrée, un administrateur local payé par la mairie de Paris. Pourtant elle n'est pas sur le territoire de la commune, ni en France. C'est une propriété privée de la Ville qui est un propriétaire comme un autre à Guernesey. Des cas où les communes sont amenées à gérer des choses hors de leur propre territoire sont assez nombreux peme si ce n'est le plus souvent pas si loin (mais même en restant en France, le Conseil général d'Ille-et-Vilaine gère des bâtiments et services à Paris ; la Corrèze aussi). Le 14 avril 2013 12:20, Philippe Verdy verd...@wanadoo.fr a écrit : Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_**level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Imagerie aérienne de Fort Liberté
Bonjour Guillaume,
Je réponds en ligne aux trois autres questions :
Le 14/04/2013 06:17, Christian Quest a écrit :
Le DEM est calculé à partir des images elles même...
Le process est à peu près celui-là:
- prise de vues, avec suffisamment de recouvrement et de différence
d'angle de point de vue
- repérage (automatique) des éléments identiques sur les photos
- calcul des déformations dûes au DEM... puis calcul du DEM (technique
de structure from motion)
- orthorectification des photos à partir du DEM
- assemblage de la mosaïque globale
Le logiciel utilisé n'est malheureusement pas opensource, il s'agit de
Pix4D.
Le 13 avril 2013 23:10, Guillaume Allegre allegre.guilla...@free.fr
mailto:allegre.guilla...@free.fr a écrit :
Le sam. 13 avril 2013 à 21:57 +0200, Jean-Guilhem Cailton a écrit :
(English version follows)
-
Bonjour,
Une équipe de l'OIM Haïti et de deux volontaires de Drone Adventures
(http://droneadventures.org/), lors d'une mission d'une semaine
en Haïti
pour laquelle Frédéric Moine s'est personnellement impliqué, a
utilisé
un drone eBee pour prendre des photos de Fort Liberté, entre autres.
Elles ont ensuite été assemblées avec le logiciel pix4D en une
orthomosaïque, qui couvre 10,9 km2 avec une résolution de 8 cm
par pixel.
Pour voir cette mosaïque dans JOSM (et mapper aussi, bien sûr), vous
pouvez y ajouter la couche TMS :
tms[23]:http://wms.openstreetmap.fr/tms/1.0.0/fortliberte_2013/{zoom}/{x}/{y}
http://wms.openstreetmap.fr/tms/1.0.0/fortliberte_2013/%7Bzoom%7D/%7Bx%7D/%7By%7D
Le niveau de détail est absolument impressionnant, c'est la
première fois que je vois
des humains (à pied et à vélo) sur une imagerie aérienne
exploitable dans JOSM.
Du coup, j'ai quelques questions techniques :
- combien d'images différentes ont été assemblées ?
808
- ça représente combien de temps de prise de vues ?
3 h
- à quelle altitude volait le drone ?
à 240 m à l'ouest de la Baie, et à 276 m à l'est
(On peut choisir de voler bas pour voir de plus petits détails, ou plus
haut pour couvrir plus de surface).
- d'habitude on parle d'orthorectification à base de DEM ; est-ce
que ça a été fait ici ?
ou bien le terrain était suffisamment plat pour se passer de DEM ?
cf. réponse de Christian.
Le DEM (ou MNE en français, pour modèle numérique d'élévation) peut être
généré séparément par le processus. Il y en a certains exemples pour les
sites précédents, et il devrait bientôt en avoir un autre exemple le
long d'une ravine, avec un dénivelé important.
La même équipe d'OIM avait déjà fait des prises de vues similaires l'an
dernier, sur des surfaces moins étendues, avec des résolutions allant
jusqu'à 4 cm, en amont du recensement des zones montagneuses de la
métropole de Port-au-Prince. Il me semblait que j'avais déjà diffusé les
liens, mais ce n'était que sur la liste roborthos :
http://listes.openstreetmap.fr/wws/arc/roborthos/2012-06/msg3.html
et, juste après le cyclone Sandy, sur les abords de la Rivière Grise,
dont les rives avaient été emportées :
http://lists.openstreetmap.org/pipermail/talk-ht/2012-November/000612.html
Si les liens anciens ne marchent plus, parce que des couches ont été
ajoutées, il peut être nécessaire d'ajuster les choix dans le menu des
couches. Les voici d'ailleurs actualisés :
Sur le quartier Haut-Turgeau :
http://osm.arkemie.org/haiti/?zoom=20lat=18.5219lon=-72.31789layers=B0FFF
Visualisation du DEM :
http://osm.arkemie.org/haiti/?zoom=20lat=18.5219lon=-72.31789layers=B0FFTFF
(en dézoomant, on peut voir les 3 sites où les DEM étaient disponibles)
Rivière Grise :
http://osm.arkemie.org/haiti/?zoom=16lat=18.59821lon=-72.27466layers=0BT.
Il devrait bientôt y avoir des sites supplémentaires en ligne.
Bien cordialement,
Jean-Guilhem
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 12:20, Philippe Verdy a écrit : Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin___level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. J'entends ton argument. Ma proposition n'est pas robuste, et donc il en faut une autre. Je n'ai rien sous le coude, mais là où j'insiste, c'est sur le fait de ne pas arriver à un nouveau tag _par commune_. Il faut parvenir à un schéma avec des tags identiques pour toutes les communes. cf. en début de ce fil : http://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056812.html vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Pourquoi FAUT-il- parvernir à ça ? Je ne vois aucune justification au fait d'avoir des tags identiques pour toutes les communes, car ce ne sont pas des éléments consitutifs d'un feature géographique. Le feature c'est plutôt porté par les autres tags. Ici on ne parle que d'un simple identifiant qui n'indique strictement rien d'autre qu'une base externe pouvant contenir des tas d'objets géographiques ou non et même pas dans OSM non plus pour la plupart, et aussi contenant des attributs supplémentaires pour les objets OSM mais des attributs qu'on ne stockera pas. Bref, si ce qui te gène c'est de ne pas pouvoir convertir tous les attributs ref;* dans des colonnes séparées d'un tableau, tu pars mal : aucune application n'a besoin de le faire, i ly a des tas d'attributs qu'on ignore totalement, mais si tu veu pouvoir les retrouver, commence d'abord par séparer les attributs qui t'intéressent dans des colonnes spécifiques de ta base, et stocke les autres dans une colonne générique refs contenant une énumération sous forme clé1=id1;clé2=id2;... là où on avait ref:clé1=id1 et ref:clé2=id2. Si on sépare malgré tout ces clés dans OSM c'est pour permettre de faire des requêtes et filtrer les données du côté du serveur, mais aussi pour limiter le risque d'effacement d'une clé par une autre incompatible. La base OSM n'est pas l'application finale utilisatrice qui prendra seulemetn ce qui l'intéresse, et n'a pas besoin non plus de tout garder puisque pour le reste elle a toujours accès à l'identifiant d'objet OSM ou peut le retrouver en faisant une recherche avec la ref:clé=* qu'elle a gardé (en ignorant les autres ref:clé2=* qu'elle n reconnait pas). Le 14 avril 2013 12:46, Vincent de Chateau-Thierry v...@laposte.net a écrit : Le 14/04/2013 12:20, Philippe Verdy a écrit : Et ce n'est pas suffisant, les objets pouvant être à cheval sur plusieurs communes (une voirie, un parc, etc... ou être administré par une autre commune qui est locataire les lieux sités sur le territoire d'une autre (par exemple une déchetterie) Le 14 avril 2013 12:14, Vincent de Chateau-Thierry v...@laposte.net Le 14/04/2013 11:14, Christian Quest a écrit : ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! Et doncon est revenu au point de départ de la discussion :-) Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8, avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page unique plutôt que x déclinaisons, une par nouveau code INSEE. Quant à l'interprétation de ce tag, ce serait : la valeur du tag est un identifiant unique délivré par l'entité de type boundary=administrative+admin_**__level=8 dans laquelle se situe (géographiquement parlant) l'objet ainsi taggué. J'entends ton argument. Ma proposition n'est pas robuste, et donc il en faut une autre. Je n'ai rien sous le coude, mais là où j'insiste, c'est sur le fait de ne pas arriver à un nouveau tag _par commune_. Il faut parvenir à un schéma avec des tags identiques pour toutes les communes. cf. en début de ce fil : http://lists.openstreetmap.**org/pipermail/talk-fr/2013-** March/056812.htmlhttp://lists.openstreetmap.org/pipermail/talk-fr/2013-March/056812.html vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] expérimentations à Orange
Le dim. 14 avril 2013 à 12:14 +0200, Vincent de Chateau-Thierry a écrit : Et doncon est revenu au point de départ de la discussion :-) Oui, et tant mieux, les digressions sur la meilleure réforme possible des administrations, ce n'est pas tellement ce qui va faire avancer la cause. Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le dim. 14 avril 2013 à 11:14 +0200, Christian Quest a écrit : ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! +1 -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imagerie aérienne de Fort Liberté
Le dim. 14 avril 2013 à 06:17 +0200, Christian Quest a écrit : Le DEM est calculé à partir des images elles même... !!! Mais alors, ça veut dire qu'on ne récupère pas seulement l'orthophoto, mais aussi une nouvelle source de données d'élévation, et ça c'est aussi super intéressant, non ? Je découvre sans doute l'eau tiède, là, mais jusqu'à présent je pensais qu'on n'aurait jamais de données d'altitude contributives fiables. En dehors du fait qu'OSM ne semble pas pour l'instant conçu pour stocker efficacement ces données, est-ce qu'il y a un obstacle à récupérer ces données de post-traitement des images de drones ? (notamment pour améliorer la résolution des données Aster/SRTM). -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 12:58, Philippe Verdy a écrit : Pourquoi FAUT-il- parvernir à ça ? Je ne vois aucune justification au fait d'avoir des tags identiques pour toutes les communes, car ce ne sont pas des éléments consitutifs d'un feature géographique. Le il faut n'est pas à prendre comme un ordre. En revanche ça me semble la cible à atteindre. Et ça n'est pas parce que ces IDs externes sont en effet, plutôt une meta-donnée qu'une donnée, qu'il faut les modéliser n'importe comment. Le feature c'est plutôt porté par les autres tags. Ici on ne parle que d'un simple identifiant qui n'indique strictement rien d'autre qu'une base externe pouvant contenir des tas d'objets géographiques ou non et même pas dans OSM non plus pour la plupart, et aussi contenant des attributs supplémentaires pour les objets OSM mais des attributs qu'on ne stockera pas. Bref, si ce qui te gène c'est de ne pas pouvoir convertir tous les attributs ref;* dans des colonnes séparées d'un tableau, tu pars mal : aucune application n'a besoin de le faire, J'adore ce genre de vérité définitive : aucune application n'a besoin de le faire. Pour affirmer ça, il faudrait connaître toutes les utilisations de la base, et le détail de chacune. C'est bien prétentieux ! Philippe, dis-toi bien que tu ne connais (et moi non plus et personne d'autre ici) pas le 1/4 du 1/3 du périmètre des applications qui s'appuient sur la base OSM. Et c'est tant mieux, au passage. Mais donc ce genre d'argument n'en est pas un. Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:identifiant de la maison selon la Ville de Paris vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un LizPoi pour les vélos
Bonjour Le 13 avril 2013 22:55, Dominique Lachgar dominique.lach...@laposte.net a écrit : Bonjour, Comme les équipements cyclables sont assez pauvres chez nous mais que nous avons quelques voies vertes, te serait-il possible de les rajouter ? En attendant que nous publions une carte, cela peut être un lien intéressant. J'ai regardé, et ce serait possible sans souci. Le seul problème, c'est qu'il faut que je réimporte toutes les données, car j'utilise les options par défaut de l'outil osm2pgsql pour importer les données dans ma base, et les réseaux cyclables ne sont pas importés. Dès que je trouve du temps pour remettre cela à plat, je vous tiens au courant. Pour l'instant, les seules choses que je peux afficher, ce sont les chemins avec accès interdit aux véhicules à moteur. Soit la combinaison de tags : higway=path et motor_vehicle=no Michael ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un LizPoi pour les vélos
Héhé, si ils savaient comment on est productifs pendant leurs siestes … Et comme on ne l'est pas lorsqu'ils ne veulent pas :D Bon dimanche estival ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14 avril 2013 14:32, Vincent de Chateau-Thierry v...@laposte.net a écrit : Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:**identifiant de la maison selon la Ville de Paris vincent J'aime assez cette dernière proposition. En effet, on reste sur l'effet une seule colonne dans les bases de données à plat tout en permettant de filtrer pour la ou les communes qui nous intéresse. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 14:21, Guillaume Allegre a écrit : Le dim. 14 avril 2013 à 12:14 +0200, Vincent de Chateau-Thierry a écrit : Et doncon est revenu au point de départ de la discussion :-) Oui, et tant mieux, les digressions sur la meilleure réforme possible des administrations, ce n'est pas tellement ce qui va faire avancer la cause. Je continue de penser que ref:FR:code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Tout le monde à terme : contributeurs (c'est indocummentable, anti intuitif au possible) et consommateurs. Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. Dans le cas d'une voie communale en frontière, on suffixe ref:FR:admin_level8 avec :left et :right. Cette convention est assez répandue dans les tags. avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. On n'en sait _rien_ , cf. ce que je viens de répondre à Philippe. Mais justement, ne sachant pas, notre responsabilité c'est de ne pas fabriquer une usine à gaz. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Décalage bing et trace gps
Ca depend aussi de la qualite de ton GPS et des conditions de mesure. Si tu avais le GPS a la main dans une plaine et en dehors d'une foret, tu peux lui faire confiance plus qu'a l'imagerie satellite. Si ton GPS etait au fond de ton sac ou dans l'habitacle d'une voiture dans une foret et au pied d'une falaise, tu aura toute sortes de sources d'erreurs qui vont faire que ta trace GPS va serieusement deriver. Tu peux peut-etre recaler l'imagerie satellite si par chance tu a une route bien couverte par au moins une dizine de traces GPS a proximite de ton chemin. Plus d'infos ici : http://wiki.openstreetmap.org/wiki/FR:Using_Imagery 2013/4/13 Dominique Lachgar dominique.lach...@laposte.net Prés d'Angoulême sur la commune de Soyaux Le 13/04/2013 23:03, Philippe Verdy a écrit : Sans indiquer le lieu où ça se produit, impossible de répondre. ing est correct presque partout en France métropolitaine continentale, mais pas encore partout car certaines images ne sont pas de l'orthophotographie dans certaines zones où elles ne sont pas disponibles. Par exemple si ta trace GPX est en Corse ou au sud du Léman (autour d'Evian) ou un peu au nord de Monaco dans les Alpes de Haute-Provence, ou dans une partie du Cotentin; les images Bing ne sont pas orthorectifiées (ça peut changer dans les mises à jour annoncées par Bing dont la couverture orthorectifiée est annoncée régulièrement). De même si c'est dans les DOM, et presque partout hors d'Europe continentale et d'Amérique du Nord continentale (en Afrique par exemple, cette couverture orthorectifiée est un vrai patchwork et on passe sans transition de zones correctement alignées à d'autres qui ne le sont pas; il y a aussi des cas nombreux en Espagne), Aucun pays d'Europe (ni même les USA) ne sont encore couverts à 100% par Bing en orthophoto. Le reste c'est une imagerie satellite avec un positionnement estimatif plus ou moins bien raccordé à l'orthophoto (et on voit assez nettement les transitions sur les tuiles servies, au delà des seuls changement de résolution ou de la colorimétrie et des contrastes, qui sont accessoires mais pas nuisibles en terme de précision de positionnement si on ne tente pas d'atteindre la précision du pixel affiché). Le 13 avril 2013 22:39, Dominique Lachgar dominique.lach...@laposte.neta écrit : Bonjour, Je viens d'ajouter un chemin via josm à partir d'une trace gps. J'observe un décalage entre cette trace et avec l'image bing. Qui a raison, la trace que j'ai réalisée ou l'imagerie bing ? Merci de vos lumières? Dominique ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2013.0.3272 / Base de données virale: 3162/6242 - Date: 13/04/2013 ___ 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] expérimentations à Orange
Le 14 avril 2013 14:32, Vincent de Chateau-Thierry v...@laposte.net a écrit : Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:**identifiant de la maison selon la Ville de Paris Et ça ne marchera pas si 2 communes veulent identifier le même objet... comme tout les objets en limite de commune et plein de cas particuliers comme celui de la Maison de Victor Hugo. 2 jeux de données différents = 2 ref:xxx différents, je ne vois pas d'autre solution qui puisse tenir, désolé. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Liens de et vers OSM...
Pour prendre un peu de recul... si on réfléchissait au problème de façon plus globale ? Pour utiliser des ref:xx ? - pour lier des données OSM avec des jeux de données externes Peut-on/doit-on le faire pour n'importe quel jeu de données ? Je ne pense pas. Si ce sont des données librement accessibles et qui apportent plus d'information sur un objet OSM, oui, ça me semble avoir sa place dans OSM. Ca permet de ne pas inclure inutilement tout un ensemble de données dans OSM, données qu'il faudrait maintenir à jour pour qu'elles gardent de leur utilité. Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien. Comment faire l'inverse... avoir un lien dans des données externes vers des objets OSM ? Là ça se complique gravement pour plusieurs raisons: - les id OSM ne sont pas pérennes: ils peuvent changer suite à un effacement/recréation ou parce qu'on fait évoluer un objet (par exemple un POI initial sur un nœud peut disparaitre en étant reporté sur un polygone) - un objet dans le jeu de données externe peut correspondre à plusieurs objets dans OSM. C'est le cas par exemple pour les codes FANTOIR/RIVOLI (rayer la mention inutile) qui identifient une rue, laquelle rue peut être segmentée dans OSM... et là il faut avoir un objet englobant sous la forme d'une relation. Il y en a sûrement d'autres... Il va falloir se pencher sérieusement un de ces jours sur des identifiants pérennes que je pense devoir mixer les 2 dimensions d'OSM à savoir la dimension spatiale et la dimension sémantique en gardant un niveau de flou sur les deux pour retrouver des objets qui ont légèrement bougé ou légèrement changé de description. Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. C'est assez facile à mettre en œuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). L'utilisation pourrait se faire via une API interrogeant par exemple l'overpass en convertissant ce hash à la volée. Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 15:25, Christian Quest a écrit : Le 14 avril 2013 14:32, Vincent de Chateau-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8=code INSEE de la commune source:identifiant de l'objet tel que géré par cette commune Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:__identifiant de la maison selon la Ville de Paris Et ça ne marchera pas si 2 communes veulent identifier le même objet... comme tout les objets en limite de commune et plein de cas particuliers comme celui de la Maison de Victor Hugo. 2 jeux de données différents = 2 ref:xxx différents, je ne vois pas d'autre solution qui puisse tenir, désolé. Donc mettons nous dans le cas où n communes gèrent, chacune dans son coin, un seul et même objet (ex. : la déchetterie citée par Philippe). Toutes ces communes libèrent leurs données. Mince ! Nous sommes donc confrontés à une bataille (dantesque !) de sources :-) Qu'est-ce qui, dans ce type de cas, nous empêche d'utiliser, là encore, une convention de tagguage (au même titre que :left et :right), à savoir le ';' comme séparateur de valeurs ? Je n'en suis pas fan, mais ça me semble une fois de plus largement plus gérable que le mode où chaque source provoquerait l'ajout d'un tag distinct. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
cquest wrote ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! si on suit cette logique, alors il faut faire ref:FR:Communes car INSEE est une institution, pas un code de classification. Si on compare avec la même chose, c'est comme si on mettait ref:84087 pour ajouter le code INSEE derrière en valeur de clé. REF:FR:admin_level_08=* voudrait dire c'est la référence en France pour les niveaux administratif 8 (les communes. Pour quoi le 08 et non le 8, parce qu'il y a 10 niveaux administratifs recensés en France. C'est pour garder le même nombre de caractères pour ce type de tags. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757051.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] expérimentations à Orange
Guillaume Allegre wrote Je continue de penser que ref:FR: code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Ceux qui utilisent les données dans des SIG classiques (il y en a encore). Il ne faut pas seulement penser informatique et web... Guillaume Allegre wrote Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. C'est déjà le cas pour le nom de ces voies name:left et name:right. Ou alors les séparer par des ;. De toute façon, l'identifiant unique devrait contenir le n° INSEE de la commune (comme pour les parcelles). Guillaume Allegre wrote avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. Des communautés de communes, d'agglo ou tout autre EPCI qui gèrent plusieurs communes, par exemple. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757054.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] Liens de et vers OSM...
Salut C'est un vieux débat sur lequel déjà pas mal d'efforts a déjà investi. Un geohash ne résouds qu'une partie du problème même en y associant le type de tag. On peut citer les cas de déménagement d'une société dans un autre endroit de la ville. De même un coiffeur ou toute autre société peut être fermée et reouvert sous un autre nom. Il faut donc produire un identifiant unique qui soit suffisamment sensible à cela pour que ça soit des identifiants uniques différents. Bref un super sujet qui m'intéresse beaucoup mais qui n'a pas de solution simple aussi bien dans l'industrie que dans le milieu académique. Émilie laffray On 14 Apr 2013 16:01, Christian Quest cqu...@openstreetmap.fr wrote: Pour prendre un peu de recul... si on réfléchissait au problème de façon plus globale ? Pour utiliser des ref:xx ? - pour lier des données OSM avec des jeux de données externes Peut-on/doit-on le faire pour n'importe quel jeu de données ? Je ne pense pas. Si ce sont des données librement accessibles et qui apportent plus d'information sur un objet OSM, oui, ça me semble avoir sa place dans OSM. Ca permet de ne pas inclure inutilement tout un ensemble de données dans OSM, données qu'il faudrait maintenir à jour pour qu'elles gardent de leur utilité. Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien. Comment faire l'inverse... avoir un lien dans des données externes vers des objets OSM ? Là ça se complique gravement pour plusieurs raisons: - les id OSM ne sont pas pérennes: ils peuvent changer suite à un effacement/recréation ou parce qu'on fait évoluer un objet (par exemple un POI initial sur un nœud peut disparaitre en étant reporté sur un polygone) - un objet dans le jeu de données externe peut correspondre à plusieurs objets dans OSM. C'est le cas par exemple pour les codes FANTOIR/RIVOLI (rayer la mention inutile) qui identifient une rue, laquelle rue peut être segmentée dans OSM... et là il faut avoir un objet englobant sous la forme d'une relation. Il y en a sûrement d'autres... Il va falloir se pencher sérieusement un de ces jours sur des identifiants pérennes que je pense devoir mixer les 2 dimensions d'OSM à savoir la dimension spatiale et la dimension sémantique en gardant un niveau de flou sur les deux pour retrouver des objets qui ont légèrement bougé ou légèrement changé de description. Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. C'est assez facile à mettre en œuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). L'utilisation pourrait se faire via une API interrogeant par exemple l'overpass en convertissant ce hash à la volée. Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ 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] expérimentations à Orange
Vincent de Château-Thierry wrote Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8= code INSEE de la commune source : identifiant de l'objet tel que géré par cette commune Le code INSEE de la commune est presque toujours déjà présent dans l'identifiant. Chez nous, l'identifiant est du type 84087V123456. Donc, pas besoin du code INSEE de la commune source:, surtout que les : se gèrent très mal dans les Bases de données des SIG. Vincent de Château-Thierry wrote Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:lt;identifiant de la maison selon la Ville de Parisgt; Là, je vois pas le rapport. L'idée n'est pas de savoir qui est le propriétaire ou le gestionnaire de la voie (ça, à la rigueur, c'est le tag operator, mais dans quelle commune elle se trouve. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757056.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] Liens de et vers OSM...
cquest wrote Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. C'est assez facile à mettre en œuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). Ça peut être encore plus complexe vue qu'une rue peut être coupée en deux et être renommée dans ces 2 parties. Mais on n'est pas obligé de commencer par le plus difficile. cquest wrote Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? Moi, carrément. Je suis ton homme !!! -- View this message in context: http://gis.19327.n5.nabble.com/Liens-de-et-vers-OSM-tp5757047p5757058.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] Imagerie aérienne de Fort Liberté
2013/4/14 Guillaume Allegre allegre.guilla...@free.fr Mais alors, ça veut dire qu'on ne récupère pas seulement l'orthophoto, mais aussi une nouvelle source de données d'élévation, et ça c'est aussi super intéressant, non ? Je découvre sans doute l'eau tiède, là, mais jusqu'à présent je pensais qu'on n'aurait jamais de données d'altitude contributives fiables. Attention. Si je comprends bien, seul le relief est reconstitué. C'est une altitude relative. Il faut encore un point de référence pour en déduire l'altitude par rapport au niveau de la mer. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
Le 14/04/2013 16:52, Tony Emery a écrit : Vincent de Château-Thierry wrote Pour revenir au sujet, je vais reformuler autrement ma proposition de ce matin. Pour combiner un nombre restreint de tags (ici 1 seul finalement) et un peu de robustesse, on pourrait renseigner ce type de tag : ref:FR:admin_level8= code INSEE de la commune source : identifiant de l'objet tel que géré par cette commune Le code INSEE de la commune est presque toujours déjà présent dans l'identifiant. Chez nous, l'identifiant est du type 84087V123456. Donc, pas besoin du code INSEE de la commune source:, surtout que les : se gèrent très mal dans les Bases de données des SIG. Mais on ne peut pas établir une règle en considérant que ce qui se fait à Orange se fait partout. Il faut toujours penser au pire quand tu réfléchis à un modèle, et là, le pire, c'est une commune qui dans son SIG aurait, par exemple, des IDs qui commencent à 1 et s'incrémentent. Si 2 communes font la même chose, on n'aura pas d'unicité des identifiants. Or ce scenario est gérable si le code INSEE de la commune est imposé en début de valeur, avant un séparateur, qui peut être ':' ou autre chose. Au passage, qu'un SIG gère mal ce caractère dans un nom de champ je peux le concevoir, mais dans une valeur de champ typé en caractère, ça me semble plus improbable. Vincent de Château-Thierry wrote Par rapport à ce que je proposais ce matin, on garde un seul tag, mais on n'est pas contraint par une inclusion géographique. On gèrerait correctement la Maison de Victor Hugo : ref:FR:admin_level8=75056:lt;identifiant de la maison selon la Ville de Parisgt; Là, je vois pas le rapport. L'idée n'est pas de savoir qui est le propriétaire ou le gestionnaire de la voie (ça, à la rigueur, c'est le tag operator, mais dans quelle commune elle se trouve. L'idée est de savoir quel organisme a affecté l'identifiant qu'on est en train de lire. La réponse à dans quelle commune se trouve l'objet n'a pas du tout besoin de tout ça, l'inclusion spatiale dans la limite de commune suffit. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Liens de et vers OSM...
Le 14/04/2013 16:00, Christian Quest a écrit : Pour prendre un peu de recul... si on réfléchissait au problème de façon plus globale ? Pour utiliser des ref:xx ? - pour lier des données OSM avec des jeux de données externes Peut-on/doit-on le faire pour n'importe quel jeu de données ? Je ne pense pas. Si ce sont des données librement accessibles et qui apportent plus d'information sur un objet OSM, oui, ça me semble avoir sa place dans OSM. Ca permet de ne pas inclure inutilement tout un ensemble de données dans OSM, données qu'il faudrait maintenir à jour pour qu'elles gardent de leur utilité. Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien. Comment faire l'inverse... avoir un lien dans des données externes vers des objets OSM ? Là ça se complique gravement pour plusieurs raisons: - les id OSM ne sont pas pérennes: ils peuvent changer suite à un effacement/recréation ou parce qu'on fait évoluer un objet (par exemple un POI initial sur un noeud peut disparaitre en étant reporté sur un polygone) - un objet dans le jeu de données externe peut correspondre à plusieurs objets dans OSM. C'est le cas par exemple pour les codes FANTOIR/RIVOLI (rayer la mention inutile) qui identifient une rue, laquelle rue peut être segmentée dans OSM... et là il faut avoir un objet englobant sous la forme d'une relation. Il y en a sûrement d'autres... Il va falloir se pencher sérieusement un de ces jours sur des identifiants pérennes que je pense devoir mixer les 2 dimensions d'OSM à savoir la dimension spatiale et la dimension sémantique en gardant un niveau de flou sur les deux pour retrouver des objets qui ont légèrement bougé ou légèrement changé de description. Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. C'est assez facile à mettre en oeuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). L'utilisation pourrait se faire via une API interrogeant par exemple l'overpass en convertissant ce hash à la volée. Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/s http://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Moi, J'ai la même problématique avec le SDIS 91 et une première étude sur le rapprochement des données. En fait, le problème est très simple et n'a simplement pas de solution : On ne peut pas synchroniser deux référentiels de données portant sur le même périmètre Maintenant on peut faire plein de choses, comme ne pas synchroniser, ou choisir des périmètres différents, etc. Je suis entrain d'écrire un papier open là dessus, mais je n'ai pas encore tout formulé. Le sujet m'intéresse donc particulièrement. Juste pour revenir à la discussion précédente, je pense que rajouter des ref vers des SI privés (fermés, non libre, etc.) n'a aucun sens. mes 0,02 EUR Marc (architecte technique et un peu urbaniste du SI d'un grand groupe de la distribution) -- m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Liens de et vers OSM...
Le 14/04/2013 17:04, Tony Emery a écrit : cquest wrote Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. C'est assez facile à mettre en œuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). Ça peut être encore plus complexe vue qu'une rue peut être coupée en deux et être renommée dans ces 2 parties. Mais on n'est pas obligé de commencer par le plus difficile. cquest wrote Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? Moi, carrément. Je suis ton homme !!! Je veux bien participer. Une page de wiki ? vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Liens de et vers OSM...
Effectivement la condition est qu'une partie des données est au minimum accessible au public, donc qu'on doit être capable d'utiliser ces références pour aller consulter ces ressources externes. Leur justification c'est d'une part de permettre de synchroniser la partie libre / ouverte de ces données qu'on aurait importées dans OSM, et de pouvoir les vérifier à leur source, et d'autre part de permettre aussi aux applications tierces (y compris non libres) de chercher des données déjà dans OSM pour les lier à d'autres données privées utilisant les mêmes identifiants. Cela peut aussi faciliter l'ouverture d'autres jeux de données depuis la même source, et lui permettre aussi à cette source de pouvoir mettre en place un outil lui permettant de faire ces mises à jour de façon plus ou moins automatisées, le but étant alors d'avoir sans OSM dans données ouvertes actualisées plus facilement et plus rapidement. Cela peut aussi permettre de résoudre certains problèmes avec des applications tierces qui ne permettent pas facilement de consulter des données pourtant ouvertes, qu'elles n'ontègrent pas elles-mêmes et aussi de compléter leurs propres données incomplètes. Ces identifiants leurs permettront aussi d'utiliser plus facilement leurs propres données quand à la place de celles présentes dans la base OSM, quand ils savent que les leurs sont meilleures, OSM leur permettant alors juste de boucher les trous sut ce qu'i chez eux sont des données en impasse. En fin de compte cela permet à tout le monde d'valuer la qualité des données et des sources utilisées, et permettre, quand plusieurs sources ont des données incompatibles entre elles, de se mettre d'accord et trouver là où sont leurs différences pour les résoudre entre eux, et finalement qu'on soit aussi d'accord dans OSM avec eux.. Ces références croisées sont un outil facilitant les échange puis à terme la convergence des données entre différents acteurs, même si por l'instant ils n'envisagent pas encore de libéraliser une bonne partie de leurs données. Globalement, tout le monde va y gagner en terme de qualité et facilité de réutilisation de ces données grâce à une codification et une nomenclature commune dont on ne peut pas décider réellement nous mêmes (et faciliter la réutilisation des données fait aussi partie des buts d'OSM). si en fin de compte une des soures décide d'abandonner sa propre maintenance et se fier à une autre, on le saura assez vite, et on pourra supprimer alors les références liés à ces bases abandonnées car maintenant par une source faisant plus référence que les autres. Le 14 avril 2013 16:00, Christian Quest cqu...@openstreetmap.fr a écrit : Pour prendre un peu de recul... si on réfléchissait au problème de façon plus globale ? Pour utiliser des ref:xx ? - pour lier des données OSM avec des jeux de données externes Peut-on/doit-on le faire pour n'importe quel jeu de données ? Je ne pense pas. Si ce sont des données librement accessibles et qui apportent plus d'information sur un objet OSM, oui, ça me semble avoir sa place dans OSM. Ca permet de ne pas inclure inutilement tout un ensemble de données dans OSM, données qu'il faudrait maintenir à jour pour qu'elles gardent de leur utilité. Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien. Comment faire l'inverse... avoir un lien dans des données externes vers des objets OSM ? Là ça se complique gravement pour plusieurs raisons: - les id OSM ne sont pas pérennes: ils peuvent changer suite à un effacement/recréation ou parce qu'on fait évoluer un objet (par exemple un POI initial sur un nœud peut disparaitre en étant reporté sur un polygone) - un objet dans le jeu de données externe peut correspondre à plusieurs objets dans OSM. C'est le cas par exemple pour les codes FANTOIR/RIVOLI (rayer la mention inutile) qui identifient une rue, laquelle rue peut être segmentée dans OSM... et là il faut avoir un objet englobant sous la forme d'une relation. Il y en a sûrement d'autres... Il va falloir se pencher sérieusement un de ces jours sur des identifiants pérennes que je pense devoir mixer les 2 dimensions d'OSM à savoir la dimension spatiale et la dimension sémantique en gardant un niveau de flou sur les deux pour retrouver des objets qui ont légèrement bougé ou légèrement changé de description. Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. C'est assez facile à mettre en œuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). L'utilisation pourrait se faire via une API interrogeant par exemple l'overpass en convertissant ce hash à la volée. Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon :
Re: [OSM-talk-fr] Liens de et vers OSM...
Le dim. 14 avril 2013 à 16:00 +0200, Christian Quest a écrit : Pour prendre un peu de recul... si on réfléchissait au problème de façon plus globale ? Pour utiliser des ref:xx ? - pour lier des données OSM avec des jeux de données externes Peut-on/doit-on le faire pour n'importe quel jeu de données ? Je ne pense pas. Si ce sont des données librement accessibles et qui apportent plus d'information sur un objet OSM, oui, ça me semble avoir sa place dans OSM. Ca permet de ne pas inclure inutilement tout un ensemble de données dans OSM, données qu'il faudrait maintenir à jour pour qu'elles gardent de leur utilité. Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien. Sauf dans le cas où on voudrait faciliter la vie des consommateurs de données métiers pour accélérer l'adoption d'OSM comme référence. Même la communauté OSM n'en profite pas immédiatement, à terme ce sera certainement bénéfique. Ce n'est pas une priorité (pour moi), mais si ça ne nous coûte qu'un tag en plus sur les objets concernés, c'est pas trop cher payé. Tu as aussi le cas intermédiaire où la collectivité considère qu'elle publie ses données uniquement dans OSM, et qu'elle veut suivre les modifications contributives (par exemple pour enrichir les données d'origine à la maison). -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
le ,ombre de caractères c'est ridicule, sinon au devrait écrire aussi le tag admin_level=08 et non admin_level=8; cela aurait un sens si c'était un identifiant servant de base à d'autres, mais ça n'a été modiflisé que comme une valeur strictement énumérée ayant une valeur numérique comparable sous forme d'entier, même sans le zéro (sans compter qu'à tout moment on va avoir une zone où on trouvera des valeurs non entières, pour gérer les cas de transitions lors de réformes adminsitratives dans un pays (qui entraineront des changements massifs et une perte de compatibilité avec les appilis tierces utilisant encore les anciennes entités pendant une période assez longue). Ajouter un zéro n'aidera pas dans ce cas les clés sont juste des clés, pas des valeurs ni des codes identifiants de bases externes, là il s'agit juste d'une convention strictement interne à OSM de nommage des clés et il vaut mieux être cohérent avec le schéma adopté dans OSM pour sa propre utilisation des admin_level=*. Le 14 avril 2013 16:30, Tony Emery tony.em...@yahoo.fr a écrit : cquest wrote ref:xxx dans un tel cas doit servir à lier avec un unique jeu de donnée, pour moi le xxx doit contenir un identifiant unique vers le jeu de donnée et ne doit pas être générique. ref:INSEE indique bien qu'on parle du jeu de données de l'INSEE ref:FR:RATP du jeu de données de la RATP ref:mhs du jeu de donnée Mérimée etc... ref:FR:08 c'est quel jeu de données ? ref:FR:84xxx me semblerai plus approprié et oui, ça va faire plein de ref:FR:x mais ils sont nécessaires pour savoir à quel jeu de donnée on fait référence vu qu'il n'ont rien en commun les uns avec les autres ! si on suit cette logique, alors il faut faire ref:FR:Communes car INSEE est une institution, pas un code de classification. Si on compare avec la même chose, c'est comme si on mettait ref:84087 pour ajouter le code INSEE derrière en valeur de clé. REF:FR:admin_level_08=* voudrait dire c'est la référence en France pour les niveaux administratif 8 (les communes. Pour quoi le 08 et non le 8, parce qu'il y a 10 niveaux administratifs recensés en France. C'est pour garder le même nombre de caractères pour ce type de tags. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757051.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] expérimentations à Orange
P. N'importe quoi. Les EPCI ne peuvent pas gérer *toutes* les donénes qu'on met dans OSM. Elles sont de toute façon obligées de faire le tri dans ce qui les intéresse, et de reclasser/regrouper des éléments qui ont été codifiés séparément dans OSM (par exemple à quoi cela peut servir à une collectivité française les clés qui séparents les concepts définis au Royaume-Uni ou aux USA, et à quoi sert la nomenclature de classification officielle française à une agence américaine qui a des lois carrément incompatibles et une toute autre classification ? Personne (j'insiste) ne peut utiliser toutes les clés simultanément, d'autant plus que certaines codifications dans OSM n'ont aucun équivalent officiel ailleurs et ne sont que des compromis orientés vers une utilisation plus grand public. Même nos serveur sde rendu sont obligés tous de faire ces requalifications quand ils créents leurs propres tables de features à partir des données OSM trop riches, et de résoudre aussi des ambiguités avec des heuristiques (car on n'a pas encore de règles claires, très souvent, sur la façon de taguer *partout* de la même façon). Dès qu'on commence à parler d'une telle couche d'adaptation, toutes les clés (et aussi les valeurs) doivent d'avord être interprêtées, et ce qu'on ne comprend pas selon le but de la base finale à créer, on le met déjà de côté. Les utilisations vont aussi changer, comme nos propres recommandations et expérimentations sur bon nombre de tags. Déjà assez souvent on doit ignorer des tags devenus obsolètes car trop ambigus. N'en ajoutons pas d'autres qui dès le départ seront ambigus. Le 14 avril 2013 16:43, Tony Emery tony.em...@yahoo.fr a écrit : Guillaume Allegre wrote Je continue de penser que ref:FR: code INSEE de la commune est une galère potentielle, tant en gestion qu'en compréhension. Pourquoi ? Ça gêne qui ? Ceux qui utilisent les données dans des SIG classiques (il y en a encore). Il ne faut pas seulement penser informatique et web... Guillaume Allegre wrote Quitte à considérer qu'au sein d'une commune on n'aura pas de chevauchements d'identifiants, alors je préfère largement un unique tag qui serait quasi la proposition de Tony, à savoir ref:FR:admin_level8 Et si une voie est à la limite de deux communes ayant toutes deux versé leur SIG, ça ne marche plus. C'est déjà le cas pour le nom de ces voies name:left et name:right. Ou alors les séparer par des ;. De toute façon, l'identifiant unique devrait contenir le n° INSEE de la commune (comme pour les parcelles). Guillaume Allegre wrote avec comme valeur l'identifiant externe fourni par le SIG communal. Un seul tag, c'est déjà beaucoup plus simple à intégrer (une seule colonne dans un schéma de BD par exemple) et à documenter : une page Qui va faire un schéma de BD contenant toutes les clés possibles ? Ça existe _en pratique_ ? ça me paraît tordu. Des communautés de communes, d'agglo ou tout autre EPCI qui gèrent plusieurs communes, par exemple. -- View this message in context: http://gis.19327.n5.nabble.com/experimentations-a-Orange-tp5755270p5757054.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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Décalage bing et trace gps
En plus rien n'interdit de refaire la mesure, de préférence dans l'autre sens, surtout si la première trace a été faite à bord d'un véhicule car les GPS bons marchés n'ont souvent pas accès à la vitesse instantanée du véhicule pour produire un résultat très précis. Cela permettra de voir que le même appareil GPS introduit ses propres divergences, ou se contente de suivre trop peu de signaux satellites pour faire une triangulation correcte, et qu'assez souvent ils dont juste une estimation raisonnable sans te situer réellement avec une précision aussi bonne que ce qu'il affiche. Une trace GPX en mouvement sans prise de mesure depuis un point fixe en consultant les statistiques du récepteur pour voir combien de signaux il capte et utilise, ce n'est pas fiable et on compense en en faisant plusieurs. Il suffit de regarder la base OSM annexe contenant des traces télkà téléchargées pour se rendre compte de la dispersion importante sur les mêmes trajets, même pour les trajets multiples réalisés dans les mêmes conditions par le même utilisateur, ou ente les utilisateurs à pied (moins de 7 km/h) et ceux en voiture ou camion... Les GPS des smartphones sont plutôt très mauvais dans une utilisation embarquée, et leurs calculs de triangulation très approximatifs (algos trop simplifiés, ou non adaptés à la latitude pour laquelle ils n'ont pas été conçus, ou des désaccords sur les modèles de projections ou les références orbitales des satellites captés). Le 14 avril 2013 15:03, Pierre Knobel pierr...@gmail.com a écrit : Ca depend aussi de la qualite de ton GPS et des conditions de mesure. Si tu avais le GPS a la main dans une plaine et en dehors d'une foret, tu peux lui faire confiance plus qu'a l'imagerie satellite. Si ton GPS etait au fond de ton sac ou dans l'habitacle d'une voiture dans une foret et au pied d'une falaise, tu aura toute sortes de sources d'erreurs qui vont faire que ta trace GPS va serieusement deriver. Tu peux peut-etre recaler l'imagerie satellite si par chance tu a une route bien couverte par au moins une dizine de traces GPS a proximite de ton chemin. Plus d'infos ici : http://wiki.openstreetmap.org/wiki/FR:Using_Imagery 2013/4/13 Dominique Lachgar dominique.lach...@laposte.net Prés d'Angoulême sur la commune de Soyaux Le 13/04/2013 23:03, Philippe Verdy a écrit : Sans indiquer le lieu où ça se produit, impossible de répondre. ing est correct presque partout en France métropolitaine continentale, mais pas encore partout car certaines images ne sont pas de l'orthophotographie dans certaines zones où elles ne sont pas disponibles. Par exemple si ta trace GPX est en Corse ou au sud du Léman (autour d'Evian) ou un peu au nord de Monaco dans les Alpes de Haute-Provence, ou dans une partie du Cotentin; les images Bing ne sont pas orthorectifiées (ça peut changer dans les mises à jour annoncées par Bing dont la couverture orthorectifiée est annoncée régulièrement). De même si c'est dans les DOM, et presque partout hors d'Europe continentale et d'Amérique du Nord continentale (en Afrique par exemple, cette couverture orthorectifiée est un vrai patchwork et on passe sans transition de zones correctement alignées à d'autres qui ne le sont pas; il y a aussi des cas nombreux en Espagne), Aucun pays d'Europe (ni même les USA) ne sont encore couverts à 100% par Bing en orthophoto. Le reste c'est une imagerie satellite avec un positionnement estimatif plus ou moins bien raccordé à l'orthophoto (et on voit assez nettement les transitions sur les tuiles servies, au delà des seuls changement de résolution ou de la colorimétrie et des contrastes, qui sont accessoires mais pas nuisibles en terme de précision de positionnement si on ne tente pas d'atteindre la précision du pixel affiché). Le 13 avril 2013 22:39, Dominique Lachgar dominique.lach...@laposte.neta écrit : Bonjour, Je viens d'ajouter un chemin via josm à partir d'une trace gps. J'observe un décalage entre cette trace et avec l'image bing. Qui a raison, la trace que j'ai réalisée ou l'imagerie bing ? Merci de vos lumières? Dominique ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-fr Aucun virus trouvé dans ce message. Analyse effectuée par AVG - www.avg.fr Version: 2013.0.3272 / Base de données virale: 3162/6242 - Date: 13/04/2013 ___ 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
Re: [OSM-talk-fr] Liens de et vers OSM...
Le 14 avril 2013 16:00, Christian Quest cqu...@openstreetmap.fr a écrit : Donc pour moi des ref:xx vers des données non ouvertes n'apportent rien. Pourquoi ? Si le id est correctement géré et que le droit d'usage de cet id est permis ? Est-ce non ouvertes qui te gène ? Il va falloir se pencher sérieusement un de ces jours sur des identifiants pérennes que je pense devoir mixer les 2 dimensions d'OSM à savoir la dimension spatiale et la dimension sémantique en gardant un niveau de flou sur les deux pour retrouver des objets qui ont légèrement bougé ou légèrement changé de description. Je suis curieux de connaître ce niveau de flou :-) mais la discussion en est déjà eu lieu je crois. Attention aussi qu'il faut s'entendre sur la notion d'identifiant d'objet. Soit l'identifiant se rapporte à l'objet, soit à la donnée dans la base. De mon point de vue, les deux sont inutiles, mais enfin quand même, dans l'hypothèse où il s'en mettrait un, j'aimerais bien savoir. Pour l'objet tout court, ça semble d'une telle évidence pour tout le monde qu'il existe, que je renonce à en discuter. Pour la culture générale, sachez qu'il existe dans le monde documentaire la technique du ARK ( http://fr.wikipedia.org/wiki/Archival_Resource_Key_%28ARK%29) (c'est moi qui ait eu l'honneur de créer cet article :-) Cette approche est intéressante, il me semble en toute modestie, car elle permet de suivre non seulement l'objet livre, mais encore toutes ses variations de rendu, et Dieu sait si on est chatouilleux sur le rendu à OSM ; il est possible, grâce à lui, de repérer tel livre est en PDF ici, en texte seul, là, etc. Ils ont tous le même identifiant avec un truc qui distingue le rendu. Donc avec OSM il serait possible de retrouver le rendu en mapquest, en leaflet, et patati, et patata. On n'est pas obligé de faire exactement pareil, mais juste de s'en inspirer peut être ? Mon idée (brute de décoffrage même si j'y pense depuis bien longtemps) serait un truc du genre bakery#u09v8z39 où bakery indique le type d'objet cherché et #u09v8z39 est le geohash de sa position approximative. Et une clairière, alors, c'est quoi ? Un trou ou un objet ? C'est assez facile à mettre en œuvre pour des objets ponctuels ou surfaciques, par contre pour du linéaire je pense qu'il faudra 2 geohash (début/fin). Déjà ça se complique ! Quand il faudra décider où est le début et la fin de la Corse, on va se marrer :-) Et l'idée type XML Schema où l'identifiant est donné non dans la donnée, mais dans le schéma ?... enfin moi ce que je dis... L'utilisation pourrait se faire via une API interrogeant par exemple l'overpass en convertissant ce hash à la volée. Ca inspire quelqu'un ? Qui m'accompagne sur ce projet ? Oui, moi, mais j'ai des idées un peu iconoclastes comme vous aurez remarqué, et je m'exprime pas toujours de façon claire. A+. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un LizPoi pour les vélos
Génial cette carte! Dommage que l'on puisse pas faire de permalink pour une région autre que Montpellier... Bref quand je regarde par chez moi j'ai l'impression que l'affichage bande cyclable sur les route-centrale dans le sens de circulation de la route n'affiche pas que des pistes cyclables, mais en général des voies avec le tag lane... -- View this message in context: http://gis.19327.n5.nabble.com/Un-LizPoi-pour-les-velos-tp5756922p5757105.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
