[OSM-talk-fr] Fwd: [gulliver] Journées du patrimoine : sur OSM

[Yannick]

 Message transféré 
Sujet : [gulliver] Journées du patrimoine : sur OSM
Date : Wed, 24 Aug 2016 22:56:13 +0200
De : Vincent Mahe 
Répondre à : gulli...@listes.gulliver.eu.org
Pour : gulli...@listes.linux-france.org

Hello

Fait notable, le site français des journées européennes du patrimoine
est basé sur Open Street Map :
http://journeesdupatrimoine.culturecommunication.gouv.fr/Programme

-- 

Cordialement

Vincent MAHÉ


 Liste gulliver 
Archives,http://gulliver.eu.org/ml-archives/
Description, http://gulliver.eu.org/ml/ml.html
Bons usages, http://gulliver.eu.org/wiki/UsagesCourriels



-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[osm . sanspourriel]

La double validation me semble bien.

Pour revenir à la remarque pertinente de Christian sur la nécessité de 
ne pas tirer trop sur l'imagerie spatiale et d'avoir de la validation 
multiple une idée c'est de proposer quelques endroits (1 par région ?) 
pour commencer et de continuer à travailler sur le coin.


Et pour la validation de faire un peu comme TranslateWiki : on a des 
propositions de relecture.


Ou des présentations graphiques : deux boutons : les formes non 
fusionnées ou les formes non fusionnées.


On clique et on passe au lieu suivant.

Si on chaîne logiquement (même geoash par exemple), les relecteurs 
peuvent valider les zones assez rapidement.


Et oui c'est vite fait. Je sais que je répare rarement a la mano. Via un 
outil comme ça on peut gagner en productivité.


N. B. : en Italie, les bâtiments fractionnés ne sont pas dus au cadastre 
:-(.


Jean-Yvon


Le 24/08/2016 à 11:06, Tyndare - tynd...@wanadoo.fr a écrit :




On 24/08/2016 07:40, Christian Quest wrote:
Le 24 août 2016 à 00:01, Jérôme Seigneuret 
> a 
écrit :


Pour les retours en effet, je pense qu'on peut aussi hacker le
code d'opensolarmap pour améliorer l’auto-détection des
découpages sur l'ortho en post traitement des détections
existante pour valider ou annuler la génération d'une alerte.


Il est possible de reprendre la logique d'opensolarmap pour une 
confirmation rapide.




Une Interface comme OpenSolarMap se prêterais bien effectivement pour 
analyser les cas de bâtiments fractionnés. Je pense qu'on pourrais 
peut être même envisager une correction automatique si il y a double 
validation.



___
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] Extraire une géométrie représentative d'une relation

[François Lacombe]

Merci pour vos retour, j'ai essayé de mieux définir le besoin

Voyez ci-dessous

Le 23 août 2016 à 17:53, Topographe Fou  a écrit
:

> Bonjour
>
> Quid de l'algorithme de Douglas-Peucker ? C'est efficace pour éliminer le
> bruit. Quant à l'appliquer sur autre chose qu'une *unique* ligne *non
> fermée* cela demandera un peu d'adaptation.
>

Merci pour le nom, je ne connaissais pas :)

Ça s'approche oui, et si ce n'est pas le processus complet, en tout cas ça
peut aider

Le 23 août 2016 à 18:54, Christian Quest  a écrit :

> Je ne suis pas sûr que ça donne un résultat pertinent et surtout en ne
> définissant pas clairement ce que tu veux en sortie je pense qu'on peut
> sortir plein de choses bien variées. Si tu veux précisément la géométrie de
> la ligne sans les autres objets de la relation (même cas pour une ligne de
> bus) il faut filtrer sur le rôle et éventuellement le type de géométrie
> (linestring ou polygon).
>
Non vraiment je ne souhaite travailler que sur la géométrie, pas de
filtrage sur le rôle ou les attributs et que ça soit valide pour toute
relation.
Le rôle n'est pas représentatif de la géométrie mais plus de la fonction.
Pour faire un "dessin grossier" de ce à quoi ressemble une relation sur le
terrain, on ne vas pas regarder la fonction des éléments (la conduite
forcée issue d'un barrage peut mesurer 50m comme 10 km)

Pour la définition je pense à : "ne garder que les éléments qui ont des
dimensions à l'échelle de celles de la relation entière".
Pour une autoroute par exemple, on ne va pas garder les petites bretelles
qui sont négligeables mais celle-ci par exemple, un peu plus :
https://www.openstreetmap.org/way/83016524

Il faudrait préalablement assembler les segments de chemin avec des
attributs équivalents (ou avec les mêmes rôles) qui sont placés les uns à
la suite des autres pour obtenir les plus grands objets possibles avant de
filtrer sur leur taille.
Ici travailler en relatif sur les attributs/rôle pose moins de problème :
on compare les membres de la relation entre eux et on a pas besoin de
définir des règles absolues.

L'autoroute est d'ailleurs un bon exemple à bien des égards : le besoin est
de sortir l'itinéraire en supprimant tous les petits éléments de part et
d'autre en ne regardant que la géométrie de ces éléments.
Bon sous OSM, les relations sont uniquement constituées des voies
principales sans ajouter les péages et autres bretelles, mais vous voyez
l'esprit non ?

Il y a aussi une fonction "squelette" dans postgis, elle permet par exemple
> d'avoir une ligne médiane d'un polygone.
>
> Pour le placement de textes, c'est utile, ça permet d'avoir des textes qui
> suivent la forme globale plutôt que d'être placé à l'horizontal, mais je
> n'ai pas encore essayé d'utiliser ça pour les rendus.
>
Comme l'algo de topographe fou, ça peut être utile.

Bref, vaste sujet ;)
>
A plusieurs c'est quand même plus pratique pour réfléchir :)

A+

François
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Contribution à OpenStreetMap sur Android

[Rogelio Canedo]

Salut Loïc,
Moi aussi je suis partant.

Le 22 août 2016 5:34 PM, "loic ortola"  a écrit :

> Bonjour à tous,
>
> il y a un peu plus d'un an, on a lancé OSM Contributor, une appli
> Android de contribution à OSM.
> Après un StateOfTheMap FR très encourageant, l'équipe a décidé de
> tordre le cou à la roadmap inspirée par de nombreux membres de la
> communauté (merci à eux), et de préparer une nouvelle version de
> l'appli.
> Au menu:
> - OAuth et Sign-in with Google
> - Fonds de carte vectoriels
> - Détection de type de données et widgets adaptés (horaires, date, etc...)
> - Marketplace Opensource pour ajouter des presets (un mode dégradé
> permettant à des utilisateurs non techniques de contribuer de façon
> fléchée et SIMPLE) (https://github.com/jawg/h2geo-presets)
> - Beaucoup d'améliorations de l'expérience utilisateur
> - Mode hors-ligne (possibilité de charger des régions hors-ligne)
> - Duplication de POI
> - Amélioration du crawler h2geo (https://github.com/jawg/h2geo)
>
> On souhaite release la version majeure pour le State-Of-The-Map à
> Bruxelles, et recherchons des volontaires pour beta-tester
> l'application avant sa sortie.
>
> Si vous êtes tentés pour l'utiliser pour une Cartopartie ou juste pour
> vous, on serait vraiment très heureux de pouvoir vous confier une
> distribution et prendre vos retours.
>
> Les types de retours qui nous sont chers:
> - Love / Hate: les choses qui font sens, les choses qui ne servent à
> rien, les nice to have, les choses appréciées, les choses géniales
> - Bugs: Nous avons déjà un bug tracker, mais il ne filtre évidemment pas
> tout
> - Feature requests: Des choses qui manquent et que vous voudriez, ou
> que vous voyiez de manière différente.
>
> L'objectif d'OSM Contributor, c'est de "réduire le cout d'entrée à
> OpenStreetMap" (pour paraphraser Christian Quest) et de permettre à
> des utilisateurs débutants comme confirmés de contribuer sans blabla.
>
> Merci infiniment pour ceux qui auront la patience de s'y intéresser,
> n'hésitez pas à répondre à ce mail pour avoir votre accès à la beta.
>
> Screenshot:
> https://twitter.com/jawgio/status/767731944964644865
>
> Loïc
>
> ___
> 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] Cela vaut le coup ?

[David Crochet]

Bonjour

Quand je reviens à l'histoire du pont mathilde de rouen, OSMR avait pris 
en compte l'info en 3-4 jours. Mais maintenant lorsque je prend 
l'exemple de OsmAnd, lorsqu'on l'utilise, il est à jour avec des données 
très récent (après avoir ajoute des turn:lanes:*=* dans OSM, le 
lendemain, OsmAnd les affichait correctement et la synthèse vocale était 
cohérente.


Cela veut dire que l'on se retrouve avec les réutilisation quasiment en 
direct des données.


et le "est-ce que cela vaut le coup", c'est de savoir si les données 
temporaires de durée non négligeable sont a intégrer dans OSM. Comment 
définir non négligeable.


Autre exemple avec 
https://twitter.com/CaenOfficiel/status/768418755810648065
Ici les travaux vont modifier la circulation jusqu'en juin 2017. Donc 
elle seront logiquement dans OSM car cela va changer radicalement.


Ensuite je rejoins ton avis sur le "retour à la normale".

Je sais que pour ma part je suis friand des "notes" et que je verrais 
bien une note du style : "Merci de réactualiser les données sur cette 
zone à partir du xx/yy/ afin de remettre les informations suivante : 
suppression du access:conditional=*" par exemple.


Cordialement

--
David Crochet


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cela vaut le coup ?

[Christian Quest]

Disons que c'est fait pour ça... pour compléter OSM sur des données trop 
temporaires pour avoir leur place dans OSM, des données liées à la géo 
et au temps...


Ceci dit, il n'y a pas encore d'utilisateur de l'API et des données, 
mais il faut bien commencer par quelque chose, un oeuf ou une poule...



Le 24/08/2016 à 15:40, Francescu GAROBY a écrit :
Pour avoir déjà posé la même question, la réponse qui me fut donnée 
était : "faut mettre ça dans open event database !"
C'est donc par là que ça se passe, semble-t-il : 
https://www.data.gouv.fr/fr/organizations/openeventdatabase/#datasets



Francescu

Le 24 août 2016 à 15:24, Jérôme Seigneuret 
> a 
écrit :


Je pense que sur des événements  non permanent lié à des
perturbations il vaut mieux gérer ça en surcouche... Ce qui n'est
pas exploitable en l'état dans la carto générale...

Il faut la base OSM et une surcouche perturbation que l'on
pourrait alimenter avec des formulaires et exploiter pour le routing.
Dommage que l'interface générale ne le permette pas. C'est le
système exploiter par google il me semble. Les événements sont
plus ou moins permanent avec des clôtures conditionnelles (selon
une durée ou une date de fin)
Ca permettra aussi d'avoir les opérateur autoroutier dans le
système quand il décideront d'une fermeture autoroutière pour
cause de travaux.


En l'état il faudra aussi que tu ajoutes l'année dans ta condition
pour éviter que ce soit conservé dans les résultats d'itinéraires
après un retour à la normale en attendant qu'un contributeur
supprime la condition car celle-ci ne se supprimera pas toute seule.

Il faudra un *fixme *pour une remise en état normal. Et une note
pour expliquer qu'il faut supprimer la clé *access:conditional*
car elle sera inutile une fois les conditions revenues à la normale

access:conditional=/*no @ 2016 Aug 24-31 : 00:00-24:00 "Currently
closed for renovation work"*/
fixme: supprimer access:conditional à partir de la semaine 36 de
l'année 2016

PS: Yohours ne reconnait pas ce format mais il répond au
spécification



Pour le moment il n'y a pas d'application pour faire des fixme
avec une date de prise en compte ni de niveau d'urgence des
corrections à réaliser ou d'auto suppression de tag à date ou
d'auto-reverter sur des infos temporaires.
Il y a surement quelque chose à faire ;-)

-- 
Cordialement,

Jérôme Seigneuret

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-fr





--
Francescu


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
Christian Quest - OpenStreetMap France

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cela vaut le coup ?

[Francescu GAROBY]

Pour avoir déjà posé la même question, la réponse qui me fut donnée était :
"faut mettre ça dans open event database !"
C'est donc par là que ça se passe, semble-t-il :
https://www.data.gouv.fr/fr/organizations/openeventdatabase/#datasets


Francescu

Le 24 août 2016 à 15:24, Jérôme Seigneuret  a
écrit :

> Je pense que sur des événements  non permanent lié à des perturbations il
> vaut mieux gérer ça en surcouche... Ce qui n'est pas exploitable en l'état
> dans la carto générale...
>
> Il faut la base OSM et une surcouche perturbation que l'on pourrait
> alimenter avec des formulaires et exploiter pour le routing.
> Dommage que l'interface générale ne le permette pas. C'est le système
> exploiter par google il me semble. Les événements sont plus ou moins
> permanent avec des clôtures conditionnelles (selon une durée ou une date de
> fin)
> Ca permettra aussi d'avoir les opérateur autoroutier dans le système quand
> il décideront d'une fermeture autoroutière pour cause de travaux.
>
>
> En l'état il faudra aussi que tu ajoutes l'année dans ta condition pour
> éviter que ce soit conservé dans les résultats d'itinéraires après un
> retour à la normale en attendant qu'un contributeur supprime la condition
> car celle-ci ne se supprimera pas toute seule.
>
> Il faudra un *fixme *pour une remise en état normal. Et une note pour
> expliquer qu'il faut supprimer la clé *access:conditional* car elle sera
> inutile une fois les conditions revenues à la normale
>
> access:conditional=*no @ 2016 Aug 24-31 : 00:00-24:00 "Currently closed
> for renovation work"*
> fixme: supprimer access:conditional à partir de la semaine 36 de l'année
> 2016
>
> PS: Yohours ne reconnait pas ce format mais il répond au spécification
> 
>
> Pour le moment il n'y a pas d'application pour faire des fixme avec une
> date de prise en compte ni de niveau d'urgence des corrections à réaliser
> ou d'auto suppression de tag à date ou d'auto-reverter sur des infos
> temporaires.
> Il y a surement quelque chose à faire ;-)
>
> --
> Cordialement,
> Jérôme Seigneuret
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Francescu
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cela vaut le coup ?

[Jérôme Seigneuret]

Je pense que sur des événements  non permanent lié à des perturbations il
vaut mieux gérer ça en surcouche... Ce qui n'est pas exploitable en l'état
dans la carto générale...

Il faut la base OSM et une surcouche perturbation que l'on pourrait
alimenter avec des formulaires et exploiter pour le routing.
Dommage que l'interface générale ne le permette pas. C'est le système
exploiter par google il me semble. Les événements sont plus ou moins
permanent avec des clôtures conditionnelles (selon une durée ou une date de
fin)
Ca permettra aussi d'avoir les opérateur autoroutier dans le système quand
il décideront d'une fermeture autoroutière pour cause de travaux.


En l'état il faudra aussi que tu ajoutes l'année dans ta condition pour
éviter que ce soit conservé dans les résultats d'itinéraires après un
retour à la normale en attendant qu'un contributeur supprime la condition
car celle-ci ne se supprimera pas toute seule.

Il faudra un *fixme *pour une remise en état normal. Et une note pour
expliquer qu'il faut supprimer la clé *access:conditional* car elle sera
inutile une fois les conditions revenues à la normale

access:conditional=*no @ 2016 Aug 24-31 : 00:00-24:00 "Currently closed for
renovation work"*
fixme: supprimer access:conditional à partir de la semaine 36 de l'année
2016

PS: Yohours ne reconnait pas ce format mais il répond au spécification


Pour le moment il n'y a pas d'application pour faire des fixme avec une
date de prise en compte ni de niveau d'urgence des corrections à réaliser
ou d'auto suppression de tag à date ou d'auto-reverter sur des infos
temporaires.
Il y a surement quelque chose à faire ;-)

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Cela vaut le coup ?

[David Crochet]

Bonjour


http://www.normandie-actu.fr/breves/le-pont-de-graville-au-havre-ferme-a-la-circulation-jusqu-au-31-aout_226636/


Cela vaut le coup d'un access:conditional=no@week 34 Mo-Su 00:00-24:00; 
week 35 Mo-We 00:00-24:00 ?


Cordialement

--
David Crochet


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

On 24/08/2016 07:40, Christian Quest wrote:
Le 24 août 2016 à 00:01, Jérôme Seigneuret 
> a 
écrit :


Pour les retours en effet, je pense qu'on peut aussi hacker le
code d'opensolarmap pour améliorer l’auto-détection des découpages
sur l'ortho en post traitement des détections existante pour
valider ou annuler la génération d'une alerte.


Il est possible de reprendre la logique d'opensolarmap pour une 
confirmation rapide.




Une Interface comme OpenSolarMap se prêterais bien effectivement pour 
analyser les cas de bâtiments fractionnés. Je pense qu'on pourrais peut 
être même envisager une correction automatique si il y a double validation.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

On 23/08/2016 16:18, Christian Quest wrote:

En croisant avec un peu plus d'infos, il serait possible d'être plus fin.

Je pense à un croisement en amont avec les parcelles et les adresses 
des parcelles. Lorsque 2 polygones de bâtiments on la même limite que 
les parcelles et que ces parcelles ont la même adresse, on a de fortes 
chance pour qu'il ne s'agisse que d'un seul bâtiment...


C'est un traitement à faire en amont, avant import dans OSM, mais 
qu'on pourrait aussi tester sur les bâtiments qui ont été importés 
sans aucun déplacement.


Tu avais déjà mention cette idée intéressante sur la liste dev-fr, mais 
j'avoue je n'ai pas voulu me lancer dans cette analyse car je
n'était pas convaincu du bénéfice, faut dire que j'ai une vision 
biaisée, j'ai vu trop de cas tordus dans les adresses du cadastre...


J'ai essayé de regarder rapidement quelques cas sur Caen: si on ne 
considère que les parcelles ayant une adresse complète (avec un numéro 
de rue),
l'info semble effectivement pertinente, peut être autant pour éliminer 
des faux positifs que pour détecter de nouveaux cas.
Par contre pour la mise en œuvre d'un tel rapprochement je ne vois pas 
trop comment faire pour l'instant (surtout à l'échelle de la France).



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr