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

[Christian Quest]

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.
>
> @Christian: pour Opensolarmap, peux tu ajouter la saisie d'une commune
> comme zone de départ? On a plus de facilité à connaitre notre territoire et
> à vouloir bosser dessus ;-)
>
>
C'est pas si simple... pour déterminer l'orientation d'un toit, il faut
plusieurs contributions concordantes.
Si chacun choisit sa zone, il y aura très peu de contributions
concordantes, voilà pourquoi actuellement on n'a pas le choix.

Il faut que je modifie complètement la logique du backend pour permettre un
mix entre une zone que l'on choisit et une zone imposée à
compléter/finaliser... le tout en essayant de proposer des batiments à
proximité pour éviter les temps de chargements de tuiles d'images aériennes.



> Pour ma part, dans le Sud les détections sont justifiées car les
> résidences (et certaines maisons individuelles) sont placées sur un lots de
> parcelles achetées sans avoir été regroupées au préalable (remembrement).
>

C'est on ne peut plus classique et pas que dans le sud, les fusions de
parcelles sont rares car ça oblige à une démarche supplémentaire, donc du
temps et délais supplémentaires, et quand on fait construire il y a
tellement de démarches qu'on profite de pouvoir en éviter une !


> A contrario on a aussi des garages accolés(15m2 chacun)  qui ont leur
> numéro de parcelle.
>
> Très peu de faux-positif... Il y a même une sous détection des découpages.
> Après on peut télécharger la zone et la traiter lors d'une première
> détection.
>
> Une autre manière serait de prendre la liste des alertes de ce type et de
> faire un déplacement rapide sur les alertes à la opensolarmap pour choisir
> de mettre au non en faux positif les alertes plus rapidement.
>
>
Il est possible de reprendre la logique d'opensolarmap pour une
confirmation rapide.


-- 
Christian Quest - OpenStreetMap France
___
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.

[Jérôme Seigneuret]

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.

@Christian: pour Opensolarmap, peux tu ajouter la saisie d'une commune
comme zone de départ? On a plus de facilité à connaitre notre territoire et
à vouloir bosser dessus ;-)

Pour ma part, dans le Sud les détections sont justifiées car les résidences
(et certaines maisons individuelles) sont placées sur un lots de parcelles
achetées sans avoir été regroupées au préalable (remembrement).
A contrario on a aussi des garages accolés(15m2 chacun)  qui ont leur
numéro de parcelle.

Très peu de faux-positif... Il y a même une sous détection des découpages.
Après on peut télécharger la zone et la traiter lors d'une première
détection.

Une autre manière serait de prendre la liste des alertes de ce type et de
faire un déplacement rapide sur les alertes à la opensolarmap pour choisir
de mettre au non en faux positif les alertes plus rapidement.

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

> 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.
>
> Autre chose un peu liée aux bâtiments... quelqu'un m'a suggéré d'ajouter à
> OpenSolarMap le moyen de créer une note sur les "bugs" que l'on peut
> repérer, peut être un simple bouton à ajouter en plus des 4 existants.
>
>
>
> Le 23/08/2016 à 14:22, Tyndare a écrit :
>
>>
>> La détection des bâtiments en forme de triangles existe déjà dans Osmose
>> (grâce à Didier2020 et à Frédéric Rodrigo)
>>
>> Avec cette analyse je voulais effectivement essayer de détecter des cas
>> plus compliqués.
>>
>> On 23/08/2016 13:42, David Crochet wrote:
>>
>>> Bonjour
>>>
>>>
>>> Le 23/08/2016 à 13:36, Jean-Claude Repetto a écrit :
>>>
 Au contraire, je vois surtout des trapèzes,

>>>
>>> C'est probablement plus difficile à détecter...
>>>
>>> Cordialement
>>>
>>>
>>
>> ___
>> 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
>



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

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

[Jérôme Seigneuret]

Salut,

J'ai un Samsung X3 Cover pour le plan de test. Je suis partant ;-)

Pour les tests tu prépares un APK?


Le 23 août 2016 à 20:43, Charles MILLET  a écrit :

> Bonjour Loïc,
>
> Je suis partant pour tester, par contre le mois de septembre est super
> chargé donc je ne suis pas certain de pouvoir faire beaucoup de remontées
> avec SotM.
>
> Je me permets déjà de te demander s'il est prévu que les données hors
> lignes soient mutualisées avec celle d'OSMAnd et/ou Maps.Me ; pour des
> raisons de simplification de la mise à jour et de stockage.
>
> Amicalement.
>
> Charles MILLET
> charlesmil...@free.fr
>
>
> Le 22/08/2016 à 17:33, 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
>



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

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

[Charles MILLET]

Bonjour Loïc,

Je suis partant pour tester, par contre le mois de septembre est super 
chargé donc je ne suis pas certain de pouvoir faire beaucoup de 
remontées avec SotM.


Je me permets déjà de te demander s'il est prévu que les données hors 
lignes soient mutualisées avec celle d'OSMAnd et/ou Maps.Me ; pour des 
raisons de simplification de la mise à jour et de stockage.


Amicalement.

Charles MILLET
charlesmil...@free.fr

Le 22/08/2016 à 17:33, 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] Problème de rafraichissement des tuiles

[Philippe Verdy]

Il y a pas mal de petits sites qui utilisent ces tuiles, la plupart pour
des cartes thématiques sur des blogues associatifs qui n'ont pas la
capacité de gérer leur serveur de tuiles et encore moins de payer un
fournisseur comme Mapquest (qui auparavant le permettait mais qui impose
maintenant des paiements disproportiennés par rapport à l'usage): ils se
sont rabattus sur les tuiles d'OSM, mais leur trafic est faible et les
cartes sont souvent très locales avec peu d'exploitation du zoom.
A-t-on d'autres offres de rendu par défaut pour les sites associatifs ou
individuels type blogues ?
Peut-on avoir pour ces sites un rendu à faible rafraîchissement qui
permettrait malgré tout d'avoir un raffraîchissement plus rapide pour le
rendu (davantage technique) par défaut d'OSM utilisé pour les contributions?

L'effet Pokemon Go joue sans doute (ces jours-ci on a vu fleurir divers
outils (non officiels) pour leurs joueurs, qui ne s'embarrassent pas de
demander l'autorisation mais demandent des rafraichissements élevés: ces
applis mal fichues forcent aussi des raffraichissements trop souvent, et ne
gèrent pas bien leur cache (ou le désactive). Même pour le jeu lui-même,
Google a mis en place un fond de carte réduit avec peu de détails: ça ne
plait pas aux joueurs qui veulent plus de détails (mais ne veulent pas
payer non plus Google).

Le retrait de Mapquest est certainement le plus significatif : nombre de
contributeurs et de petits sites préféraient travailler avec le fond
Mapquest mais il n'ont plujs d'autre alternative (seul le rendu OSM
supporte une charge correcte, mais on note que même pour afficher les
cartes, on a maintenant souvent des tuiles grises, qu'on a peine à afficher
après plusieurs minutes, même à des niveaux de zoom modérés autour de 12).
Pour ces niveaux voisins de 12, OSM aura besoin d'augmenter la taille des
caches pour moins solliciter le rendu avec les tuiles expirées ou qui ont
débordé du cache et ont été purgées trop tôt. Cela demandera des espaces
disques supplémentaires et d'avantage de proxy. Le CDN actuel ne suffit
plus et notamment pour travailler sur les zones blanches des pays moins
développés : cela devient même une gêne pour des activités critiques type
HOT (même si là on a un rendu spécifique qui permettrait de prioritiser
certaines zones où une tâche HOT urgente est actif).

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

> Les serveurs de tuiles sont pas mal sollicités en ce moment d'après ce que
> j'ai compris. C'est peut être l'explication.
>
> Côté OSM-FR, l'effet MapQuest a multiplié le traffic par 3 environ. A cela
> s'est ajouté aussi un effet Pokemon... plusieurs sites utilisent les tuiles
> de tile.openstreetmap.fr et ça se sent aussi. Pour info, en juillet, on a
> atteint 297 millions de tuiles servies par le cache, soit presque 10
> millions par jour.
>
> J'ai fait un peu d'optimisation cet été pour le serveur pour compenser.
>
>
> Le 23/08/2016 à 18:47, Jérôme Seigneuret a écrit :
>
>> Arf d'habitude le rafraichissement sur les niveaux 18 à 14 sont assez
>> rapide... C'est globalement inférieur à 15min. Là on est plutôt sur
>> plusieurs heures voir jours. Le niveau 18 s'est mis à jour au bout de
>> 2jours. Pour les niveaux 17 et inférieurs, j'attends encore...
>>
>>
> --
> Christian Quest - OpenStreetMap France
>
>
>
> ___
> 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] Problème de rafraichissement des tuiles

[Jérôme Seigneuret]

Ok,

Donc c'est en effet un problème technique mais lié à la montée en charge de
la demande de service... Arf. Coté serveur FR, j'ai pas vu le problème car
ArcGIS ne fourni que le service de tuilage openstreetmap.org...

Merci pour le taf coté serveur Français. Du coup en édition je vérifie sur
les fonds FR la prise en compte des modifications.



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

> Les serveurs de tuiles sont pas mal sollicités en ce moment d'après ce que
> j'ai compris. C'est peut être l'explication.
>
> Côté OSM-FR, l'effet MapQuest a multiplié le traffic par 3 environ. A cela
> s'est ajouté aussi un effet Pokemon... plusieurs sites utilisent les tuiles
> de tile.openstreetmap.fr et ça se sent aussi. Pour info, en juillet, on a
> atteint 297 millions de tuiles servies par le cache, soit presque 10
> millions par jour.
>
> J'ai fait un peu d'optimisation cet été pour le serveur pour compenser.
>
>
> Le 23/08/2016 à 18:47, Jérôme Seigneuret a écrit :
>
>> Arf d'habitude le rafraichissement sur les niveaux 18 à 14 sont assez
>> rapide... C'est globalement inférieur à 15min. Là on est plutôt sur
>> plusieurs heures voir jours. Le niveau 18 s'est mis à jour au bout de
>> 2jours. Pour les niveaux 17 et inférieurs, j'attends encore...
>>
>>
> --
> Christian Quest - OpenStreetMap France
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Problème de rafraichissement des tuiles

[Christian Quest]

Les serveurs de tuiles sont pas mal sollicités en ce moment d'après ce 
que j'ai compris. C'est peut être l'explication.


Côté OSM-FR, l'effet MapQuest a multiplié le traffic par 3 environ. A 
cela s'est ajouté aussi un effet Pokemon... plusieurs sites utilisent 
les tuiles de tile.openstreetmap.fr et ça se sent aussi. Pour info, en 
juillet, on a atteint 297 millions de tuiles servies par le cache, soit 
presque 10 millions par jour.


J'ai fait un peu d'optimisation cet été pour le serveur pour compenser.


Le 23/08/2016 à 18:47, Jérôme Seigneuret a écrit :
Arf d'habitude le rafraichissement sur les niveaux 18 à 14 sont assez 
rapide... C'est globalement inférieur à 15min. Là on est plutôt sur 
plusieurs heures voir jours. Le niveau 18 s'est mis à jour au bout de 
2jours. Pour les niveaux 17 et inférieurs, j'attends encore...




--
Christian Quest - OpenStreetMap France


___
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

[Christian Quest]

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).


Avec postgis, un ST_Buffer négatif, permet de virer ces 
excroissances...  mais ça marchera sur ce type de géométrie pas 
forcément sur d'autres.


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.


Bref, vaste sujet ;)


Le 23/08/2016 à 16:59, François Lacombe a écrit :
En fait, je donnais un exemple et le but est de trouver une méthode 
pour toutes les relations.

Toutes n'ont pas de membre avec le role line.

On peut se demander ce qu'est une géométrie représentative (je 
raisonne tout haut)
Le périmètre qui encadre tous les membres par exemple, mais trop 
"grossier".

Ou alors la concaténation des plus gros membres de la relation
Il doit surement y avoir d'autres moyens de l'exprimer

Dans mon exemple, on devrait être capable de retrouver la forme de la 
ligne qui constitue le plus gros de la relation en éliminant le 
"bruit" aux extrémités provoqué par des objets proches les uns des 
autres au regarde de l'étendue de la relation.
Mais surtout il ne faut travailler que sur la géométrie des membres, 
dès qu'on passe aux attributs, ca revient à définir des règles 
spécifiques dont je ne veux pas.


Pas sur que ce soit plus clair :)

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com 
@InfosReseaux 

Le 22 août 2016 à 16:45, Christian Quest > a écrit :


Dans overpass une requête permet de ne sélectionner que les
membres portant un certain rôle dans la relation:

rel(5430194 );
way(r:"line");
(._;>;);out skel;

Après il faut en récupérer la version geojson...


Le 22/08/2016 à 15:25, François Lacombe a écrit :

Bonjour Philippe, Guillaume,

Personne n'est a coté de la plaque ;)

Cependant, seule la méthode m’intéresse.
En effet il y a déjà quelques outils qui parviennent à présenter
graphiquement une relation mais j'ai besoin de l'implémenter de
mon côté.

Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas
une géométrie unique. Il affiche tous les objets de la relation
et c'est vite le fouillis, en plus de devoir être découpé pour
être intégré dans du geojson.
Voir ici : http://www.openstreetmap.org/relation/5430194

Je m'attends à récupérer une ligne toute simple sans les deux
polygones aux extrémités. C'est la seule géométrie "simple" et
représentative qu'on puisse exploiter sans faire appel à des
FeatureCollections ou autre.

Et ça me semble très dur de trouver une méthode générique qui
puisse faire cette synthèse parce qu'il semble qu'il y ait autant
de possibilités que de cas :'(

François

Le 22 août 2016 à 14:45, Philippe Verdy > a écrit :

Le site web OSM le fait déjà quand on "explore" une relation:
ça télécharge un jeu de données JSON permettant le rendu
vectoriel de l'objet sélectionné par dessus le fond de carte.
La Wikipédie francophone le fait aussi sur ses cartes (mais
elle requête son propre serveur pour obtenir aussi des POIs
géolocalisés sur Wikipédia ou des photos géolocalisées sur
Commons)
Attention en cas d'inclusion dans un script web : l'API ne
doit pas surcharger le serveur interrogé (on a vu le problème
ces jours-ci sur Overpass API avec des centaines de milliers
de requêtes par heure au lieu de quelques dizaines
habituellement, deux serveurs Overpass API sont tombés
plusieurs fois de suite, peut-être à cause d'un script d'un
réseau publicitaire abusif ou d'une appli non-officielle type
Pokemon).
Bref gérer des caches sur votre serveur et éviter de faire
des requêtes automatiques en boucle par le client sur chaque
page web du site ou chaque page de l'appli mobile, respecter
les protocoles !


Le 22 août 2016 à 14:30, François Lacombe
> a écrit :

Bonjour à tous,

Avec la récente mise en place et adoption croissante
d'open event 

Re: [OSM-talk-fr] Problème de rafraichissement des tuiles

[Jérôme Seigneuret]

Arf d'habitude le rafraichissement sur les niveaux 18 à 14 sont assez
rapide... C'est globalement inférieur à 15min. Là on est plutôt sur
plusieurs heures voir jours. Le niveau 18 s'est mis à jour au bout de
2jours. Pour les niveaux 17 et inférieurs, j'attends encore...

Le 23 août 2016 à 18:04, Philippe Verdy  a écrit :

> Ca se met à jour, mais c'est très lent (plusieurs jours à partir du niveau
> 13, beaucoup plus au niveaux faibles).
>
> Le 23 août 2016 à 16:41, Jérôme Seigneuret 
> a écrit :
>
>> Bonjour,
>>
>> J'observe des problèmes de rafraichissement sur
>> http://www.openstreetmap.org/
>>
>> Avez-vous aussi des problèmes. Seul de niveau 19 se met à jour...
>>
>> Merci
>>
>>
>> --
>> Cordialement,
>> Jérôme Seigneuret
>>
>> ___
>> 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
>
>


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

Re: [OSM-talk-fr] Problème de rafraichissement des tuiles

[Philippe Verdy]

Ca se met à jour, mais c'est très lent (plusieurs jours à partir du niveau
13, beaucoup plus au niveaux faibles).

Le 23 août 2016 à 16:41, Jérôme Seigneuret  a
écrit :

> Bonjour,
>
> J'observe des problèmes de rafraichissement sur http://www.openstreetmap.
> org/
>
> Avez-vous aussi des problèmes. Seul de niveau 19 se met à jour...
>
> Merci
>
>
> --
> Cordialement,
> Jérôme Seigneuret
>
> ___
> 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

[Philippe Verdy]

le "bruit" est subjectif selon ce que tu définis. Dans OSM les données sont
précises. Les relations peuvent contenir des enclaves: veux-tu les inclure
ou pas ? tu peux essayer d'exclure le rôle "inner", mais il y a certains
pièges avec parfois des "outer" à l'intérieur d'une zone "inner".

Overpass API ne fait pas de traitement de géométrie, il retourne les
données telles qu'elles sont dans la base, point barre.
Les simplifications géométriques sont faites côté client (et c'est le cas
avec le javascript émis par Overpass Turbo qui réduit les points non
nécessaires selon le niveau de zoom à l'affichage quand cela ne fait pas de
différences significatives en termes de pixels rendus, d'autant plus que
les lignes tracées ont aussi une épaisseur qui peut masquer des points).

Si on veut faire ça côté serveur, il faut une requête plus compliquée non
prise en charge par l'Overpass API, utilisant les transformations prises en
charge en PostgreSQL, mais ce n'est pas disponible publiquement (il te faut
un accès administrateur ou utiliser ta propre base de données, comme le
fait Osmose par exemple).

Mais les Javascripts fournis par Overpass Turbo fonctionnent bien (côté
client) et font pas mal de chose pour faire ces transformations ou
simplifications et afficher correctement ce qu'on cherche sur un fond de
carte.

Enfin, pour certains objets, il n'y a pas que des lignes mais aussi des
noeuds individuels (qui ne sont pas toujours inclus dans la surface:
exemple les chef-lieux d'arrondissements départementaux ne sont pas
nécessairement dans l'arrondissement): c'est à toi de juger de la
pertinence de les inclure ou pas (et de la façon de les représenter: icône
centrée sur le noeud, ou cercle autour, à toi de décider le rayon), ou de
les attacher à la surface par des traits (assez arbitraires) supplémentaires

Comme toujours ce sont des décisions propres à chaque rendu, et OSM ne
tague pas pour le rendu, chacun des rendus ayant ses préférences
éditoriales pour déterminer ce qui est pertinent. Selon chaque choix, il y
aura donc autant de méthodes à définir, il n'y a pas de méthode générale
pour tout.


Le 23 août 2016 à 16:59, François Lacombe  a
écrit :

> En fait, je donnais un exemple et le but est de trouver une méthode pour
> toutes les relations.
> Toutes n'ont pas de membre avec le role line.
>
> On peut se demander ce qu'est une géométrie représentative (je raisonne
> tout haut)
> Le périmètre qui encadre tous les membres par exemple, mais trop
> "grossier".
> Ou alors la concaténation des plus gros membres de la relation
> Il doit surement y avoir d'autres moyens de l'exprimer
>
> Dans mon exemple, on devrait être capable de retrouver la forme de la
> ligne qui constitue le plus gros de la relation en éliminant le "bruit" aux
> extrémités provoqué par des objets proches les uns des autres au regarde de
> l'étendue de la relation.
> Mais surtout il ne faut travailler que sur la géométrie des membres, dès
> qu'on passe aux attributs, ca revient à définir des règles spécifiques dont
> je ne veux pas.
>
> Pas sur que ce soit plus clair :)
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> Le 22 août 2016 à 16:45, Christian Quest  a
> écrit :
>
>> Dans overpass une requête permet de ne sélectionner que les membres
>> portant un certain rôle dans la relation:
>>
>> rel(5430194 );
>> way(r:"line");
>> (._;>;);out skel;
>>
>> Après il faut en récupérer la version geojson...
>>
>> Le 22/08/2016 à 15:25, François Lacombe a écrit :
>>
>> Bonjour Philippe, Guillaume,
>>
>> Personne n'est a coté de la plaque ;)
>>
>> Cependant, seule la méthode m’intéresse.
>> En effet il y a déjà quelques outils qui parviennent à présenter
>> graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.
>>
>> Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
>> géométrie unique. Il affiche tous les objets de la relation et c'est vite
>> le fouillis, en plus de devoir être découpé pour être intégré dans du
>> geojson.
>> Voir ici : http://www.openstreetmap.org/relation/5430194
>> Je m'attends à récupérer une ligne toute simple sans les deux polygones
>> aux extrémités. C'est la seule géométrie "simple" et représentative qu'on
>> puisse exploiter sans faire appel à des FeatureCollections ou autre.
>>
>> Et ça me semble très dur de trouver une méthode générique qui puisse
>> faire cette synthèse parce qu'il semble qu'il y ait autant de possibilités
>> que de cas :'(
>>
>> François
>>
>> Le 22 août 2016 à 14:45, Philippe Verdy  a écrit :
>>
>>> Le site web OSM le fait déjà quand on "explore" une relation: ça
>>> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
>>> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
>>> aussi sur ses cartes (mais elle 

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

[Topographe Fou]

  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.LeTopographeFou   De:fl.infosrese...@gmail.comEnvoyé:23 août 2016 8:00 AMÀ:talk-fr@openstreetmap.orgRépondre à:talk-fr@openstreetmap.orgObjet:Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation  En fait, je donnais un exemple et le but est de trouver une méthode pour toutes les relations.Toutes n'ont pas de membre avec le role line.On peut se demander ce qu'est une géométrie représentative (je raisonne tout haut)Le périmètre qui encadre tous les membres par exemple, mais trop "grossier".Ou alors la concaténation des plus gros membres de la relationIl doit surement y avoir d'autres moyens de l'exprimerDans mon exemple, on devrait être capable de retrouver la forme de la ligne qui constitue le plus gros de la relation en éliminant le "bruit" aux extrémités provoqué par des objets proches les uns des autres au regarde de l'étendue de la relation.Mais surtout il ne faut travailler que sur la géométrie des membres, dès qu'on passe aux attributs, ca revient à définir des règles spécifiques dont je ne veux pas.Pas sur que ce soit plus clair :)François Lacombefl dot infosreseaux At gmail dot comwww.infos-reseaux.com@InfosReseaux
Le 22 août 2016 à 16:45, Christian Quest  a écrit :
  

  
  
Dans overpass une requête permet de ne sélectionner que les
  membres portant un certain rôle dans la relation:
rel(5430194);
  way(r:"line");
  (._;>;);out skel;

Après il faut en récupérer la version geojson...


Le 22/08/2016 à 15:25, François Lacombe
  a écrit :


  

  

  Bonjour Philippe, Guillaume,

  
  Personne n'est a coté de la plaque ;)
  

Cependant, seule la méthode m’intéresse.
  
  En effet il y a déjà quelques outils qui parviennent à
  présenter graphiquement une relation mais j'ai besoin de
  l'implémenter de mon côté.
  

Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas
une géométrie unique. Il affiche tous les objets de la relation
et c'est vite le fouillis, en plus de devoir être découpé pour
être intégré dans du geojson.

  

  
Voir ici : http://www.openstreetmap.org/relation/5430194

Je m'attends à récupérer une ligne toute simple
  sans les deux polygones aux extrémités. C'est la seule
  géométrie "simple" et représentative qu'on puisse
  exploiter sans faire appel à des FeatureCollections ou
  autre.


  


Et ça me semble très dur de
  trouver une méthode générique qui puisse faire
  cette synthèse parce qu'il semble qu'il y ait
  autant de possibilités que de cas :'(



François
  


  Le 22 août 2016 à 14:45,
Philippe Verdy 
a écrit :

  Le site web OSM le fait déjà
quand on "explore" une relation: ça
télécharge un jeu de données JSON permettant
le rendu vectoriel de l'objet sélectionné
par dessus le fond de carte. La Wikipédie
francophone le fait aussi sur ses cartes
(mais elle requête son propre serveur pour
obtenir aussi des POIs géolocalisés sur
Wikipédia ou des photos géolocalisées sur
Commons)
Attention en cas d'inclusion dans un
  script web : l'API ne doit pas surcharger
  le serveur interrogé (on a vu le problème
  ces jours-ci sur Overpass API avec des
  centaines de milliers de requêtes par
  heure au lieu de quelques 

Re: [OSM-talk-fr] Extraire une géométrie représentative d'une relation

[François Lacombe]

En fait, je donnais un exemple et le but est de trouver une méthode pour
toutes les relations.
Toutes n'ont pas de membre avec le role line.

On peut se demander ce qu'est une géométrie représentative (je raisonne
tout haut)
Le périmètre qui encadre tous les membres par exemple, mais trop "grossier".
Ou alors la concaténation des plus gros membres de la relation
Il doit surement y avoir d'autres moyens de l'exprimer

Dans mon exemple, on devrait être capable de retrouver la forme de la ligne
qui constitue le plus gros de la relation en éliminant le "bruit" aux
extrémités provoqué par des objets proches les uns des autres au regarde de
l'étendue de la relation.
Mais surtout il ne faut travailler que sur la géométrie des membres, dès
qu'on passe aux attributs, ca revient à définir des règles spécifiques dont
je ne veux pas.

Pas sur que ce soit plus clair :)

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 22 août 2016 à 16:45, Christian Quest  a écrit :

> Dans overpass une requête permet de ne sélectionner que les membres
> portant un certain rôle dans la relation:
>
> rel(5430194 );
> way(r:"line");
> (._;>;);out skel;
>
> Après il faut en récupérer la version geojson...
>
> Le 22/08/2016 à 15:25, François Lacombe a écrit :
>
> Bonjour Philippe, Guillaume,
>
> Personne n'est a coté de la plaque ;)
>
> Cependant, seule la méthode m’intéresse.
> En effet il y a déjà quelques outils qui parviennent à présenter
> graphiquement une relation mais j'ai besoin de l'implémenter de mon côté.
>
> Relativement à l'exemple du résultat d'OSM.org. Il n'emploie pas une
> géométrie unique. Il affiche tous les objets de la relation et c'est vite
> le fouillis, en plus de devoir être découpé pour être intégré dans du
> geojson.
> Voir ici : http://www.openstreetmap.org/relation/5430194
> Je m'attends à récupérer une ligne toute simple sans les deux polygones
> aux extrémités. C'est la seule géométrie "simple" et représentative qu'on
> puisse exploiter sans faire appel à des FeatureCollections ou autre.
>
> Et ça me semble très dur de trouver une méthode générique qui puisse faire
> cette synthèse parce qu'il semble qu'il y ait autant de possibilités que de
> cas :'(
>
> François
>
> Le 22 août 2016 à 14:45, Philippe Verdy  a écrit :
>
>> Le site web OSM le fait déjà quand on "explore" une relation: ça
>> télécharge un jeu de données JSON permettant le rendu vectoriel de l'objet
>> sélectionné par dessus le fond de carte. La Wikipédie francophone le fait
>> aussi sur ses cartes (mais elle requête son propre serveur pour obtenir
>> aussi des POIs géolocalisés sur Wikipédia ou des photos géolocalisées sur
>> Commons)
>> Attention en cas d'inclusion dans un script web : l'API ne doit pas
>> surcharger le serveur interrogé (on a vu le problème ces jours-ci sur
>> Overpass API avec des centaines de milliers de requêtes par heure au lieu
>> de quelques dizaines habituellement, deux serveurs Overpass API sont tombés
>> plusieurs fois de suite, peut-être à cause d'un script d'un réseau
>> publicitaire abusif ou d'une appli non-officielle type Pokemon).
>> Bref gérer des caches sur votre serveur et éviter de faire des requêtes
>> automatiques en boucle par le client sur chaque page web du site ou chaque
>> page de l'appli mobile, respecter les protocoles !
>>
>>
>> Le 22 août 2016 à 14:30, François Lacombe  a
>> écrit :
>>
>>> Bonjour à tous,
>>>
>>> Avec la récente mise en place et adoption croissante d'open event
>>> database, je me pose une question que certains ont déjà du résoudre.
>>>
>>> Existe-t-il une méthode générique pour convertir une relation OSM en
>>> geojson ?
>>> Cela reviendrait à convertir la relation en géométrie simple (points /
>>> polyline).
>>>
>>> Le besoin est d'attribuer une géométrie représentative à des événements
>>> dégagés par des ouvrages décrit avec une relation.
>>> Après on peut les envoyer sur open event db.
>>>
>>> Mais il peut y avoir des tonnes d'autres usages à cela, sans se limiter
>>> à cet exemple.
>>>
>>> J'aimerais éviter les scripts avec des if/else à rallonge pour cibler
>>> tel ou tel type de relation, à la recherche de tel ou tel objet qui au
>>> final n'est pas forcé de se trouver là où on l'attend, etc...
>>>
>>>
>>> Merci par avance pour vos retours
>>>
>>> François
>>>
>>>
>>> --
>>> *François Lacombe*
>>>
>>> fl dot infosreseaux At gmail dot com
>>> www.infos-reseaux.com
>>> @InfosReseaux 
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> 

[OSM-talk-fr] Problème de rafraichissement des tuiles

[Jérôme Seigneuret]

Bonjour,

J'observe des problèmes de rafraichissement sur
http://www.openstreetmap.org/

Avez-vous aussi des problèmes. Seul de niveau 19 se met à jour...

Merci


-- 
Cordialement,
Jérôme Seigneuret
___
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.

[Christian Quest]

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.


Autre chose un peu liée aux bâtiments... quelqu'un m'a suggéré d'ajouter 
à OpenSolarMap le moyen de créer une note sur les "bugs" que l'on peut 
repérer, peut être un simple bouton à ajouter en plus des 4 existants.



Le 23/08/2016 à 14:22, Tyndare a écrit :


La détection des bâtiments en forme de triangles existe déjà dans 
Osmose (grâce à Didier2020 et à Frédéric Rodrigo)


Avec cette analyse je voulais effectivement essayer de détecter des 
cas plus compliqués.


On 23/08/2016 13:42, David Crochet wrote:

Bonjour


Le 23/08/2016 à 13:36, Jean-Claude Repetto a écrit :

Au contraire, je vois surtout des trapèzes,


C'est probablement plus difficile à détecter...

Cordialement




___
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] Osmose-dev: bâtiments fractionnés par le Cadastre.

[Tyndare]

La détection des bâtiments en forme de triangles existe déjà dans Osmose 
(grâce à Didier2020 et à Frédéric Rodrigo)


Avec cette analyse je voulais effectivement essayer de détecter des cas 
plus compliqués.


On 23/08/2016 13:42, David Crochet wrote:

Bonjour


Le 23/08/2016 à 13:36, Jean-Claude Repetto a écrit :

Au contraire, je vois surtout des trapèzes,


C'est probablement plus difficile à détecter...

Cordialement




___
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]

Effectivement, c'est un faux négatif, la détection est loin d'être 
parfaite, elle marche en comparant avec une base d'exemples qu'il faudra 
encore améliorer.


Dans ce cas là la difficulté vient du fait que le bâtiments est coupé 
deux fois (il est en trois morceaux), du coup la majorité des angles ne 
sont pas droits, un peut comme pour les maisons des centres historiques 
des villes où l'algo détecte beaucoup trop de faux positifs... difficile 
de trouver le juste milieu.



On 23/08/2016 13:22, Hamlet wrote:

Bonjour,
a priori pas trop de faux positifs par chez moi.

Par contre un faux négatif, celui-ci est bien à corriger :
http://www.openstreetmap.org/browse/way/298268148
Mais celui juste au-dessus n'est pas détecté !
En fait dans le hameau il y en a pas mal.


2016-08-23 12:52 GMT+02:00 Tyndare :

Bonjour,

j'ai lancé une analyse Osmose pour essayer de détecter des bâtiments
fractionnés par le cadastre.
(cad des bâtiments que le cadastre a scinder en morceaux à cause des limites
de parcelles ou autre).

Le résultat est visible temporairement sur le serveur de développement
d'Osmose:

http://dev.osmose.openstreetmap.fr/fr/map/#source=26121=3

J'aurais aimé votre retour sur la pertinence de cette détection, s'il n'y a
pas trop de faux positifs et donc si la qualité serait suffisante pour
l'intégrer de façon plus pérenne dans Osmose.

Le Cadastre n'est en fait pas utilisé pour l'analyse, seule la forme des
bâtiments comparés deux-à-deux est prise en compte.
Pour les motivés vous pouvez déjà faire des corrections dans OSM (en
vérifiant bien avec les images du Cadastre et les photos aériennes IGN si le
fractionnement est effectivement un artefact du Cadastre ou si au contraire
il a bien une réalité physique qui doit être conservée dans OSM).
Ne vous embêter pas a signaler les faux-positifs sur Osmose, c'est un
serveur de dev, l'info sera perdue.

Je sais qu'il y a beaucoup de faux positifs dans les centre ville à cause de
la forme moins carrée des bâtiments.
En théorie il y a aussi proportionnellement beaucoup de faux positifs dans
la région Rhône-Alpes étant donné que j'y ai déjà corrigé une majorité de
cas.


Tyndare.

___
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] Osmose-dev: bâtiments fractionnés par le Cadastre.

[David Crochet]

Bonjour


Le 23/08/2016 à 13:36, Jean-Claude Repetto a écrit :

Au contraire, je vois surtout des trapèzes,


C'est probablement plus difficile à détecter...

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.

[Jean-Claude Repetto]

Le 23/08/2016 à 13:21, David Crochet a écrit :
> Bonjour
> 
> 
> Est-ce que la détection ne pourrait pas être :
> 
> type:way de forme Triangle rectangle avec building=* accolé par le plus
> long côté à un type:way bulding=*
> 
> car une bonne majorité des coupure ont lieu dans un coin de bâtiment qui
> sont majoritairement orthogone


Bonjour,

Au contraire, je vois surtout des trapèzes, car il est rare que les
angles des bâtiments coïncident exactement avec les limites de parcelles.

Jean-Claude



___
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.

[Hamlet]

Bonjour,
a priori pas trop de faux positifs par chez moi.

Par contre un faux négatif, celui-ci est bien à corriger :
http://www.openstreetmap.org/browse/way/298268148
Mais celui juste au-dessus n'est pas détecté !
En fait dans le hameau il y en a pas mal.


2016-08-23 12:52 GMT+02:00 Tyndare :
>
> Bonjour,
>
> j'ai lancé une analyse Osmose pour essayer de détecter des bâtiments
> fractionnés par le cadastre.
> (cad des bâtiments que le cadastre a scinder en morceaux à cause des limites
> de parcelles ou autre).
>
> Le résultat est visible temporairement sur le serveur de développement
> d'Osmose:
>
> http://dev.osmose.openstreetmap.fr/fr/map/#source=26121=3
>
> J'aurais aimé votre retour sur la pertinence de cette détection, s'il n'y a
> pas trop de faux positifs et donc si la qualité serait suffisante pour
> l'intégrer de façon plus pérenne dans Osmose.
>
> Le Cadastre n'est en fait pas utilisé pour l'analyse, seule la forme des
> bâtiments comparés deux-à-deux est prise en compte.
> Pour les motivés vous pouvez déjà faire des corrections dans OSM (en
> vérifiant bien avec les images du Cadastre et les photos aériennes IGN si le
> fractionnement est effectivement un artefact du Cadastre ou si au contraire
> il a bien une réalité physique qui doit être conservée dans OSM).
> Ne vous embêter pas a signaler les faux-positifs sur Osmose, c'est un
> serveur de dev, l'info sera perdue.
>
> Je sais qu'il y a beaucoup de faux positifs dans les centre ville à cause de
> la forme moins carrée des bâtiments.
> En théorie il y a aussi proportionnellement beaucoup de faux positifs dans
> la région Rhône-Alpes étant donné que j'y ai déjà corrigé une majorité de
> cas.
>
>
> Tyndare.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Hamlet

___
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.

[David Crochet]

Bonjour


Le 23/08/2016 à 12:52, Tyndare a écrit :
Le Cadastre n'est en fait pas utilisé pour l'analyse, seule la forme 
des bâtiments comparés deux-à-deux est prise en compte.


Je cois que c'est çà qui fait beaucoup de faux positif dans Caen 
intra-muros.


Est-ce que la détection ne pourrait pas être :

type:way de forme Triangle rectangle avec building=* accolé par le plus 
long côté à un type:way bulding=*


car une bonne majorité des coupure ont lieu dans un coin de bâtiment qui 
sont majoritairement orthogone


Cordialement

--
David Crochet


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

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

[Tyndare]

Bonjour,

j'ai lancé une analyse Osmose pour essayer de détecter des bâtiments 
fractionnés par le cadastre.
(cad des bâtiments que le cadastre a scinder en morceaux à cause des 
limites de parcelles ou autre).


Le résultat est visible temporairement sur le serveur de développement 
d'Osmose:


http://dev.osmose.openstreetmap.fr/fr/map/#source=26121=3

J'aurais aimé votre retour sur la pertinence de cette détection, s'il 
n'y a pas trop de faux positifs et donc si la qualité serait suffisante 
pour l'intégrer de façon plus pérenne dans Osmose.


Le Cadastre n'est en fait pas utilisé pour l'analyse, seule la forme des 
bâtiments comparés deux-à-deux est prise en compte.
Pour les motivés vous pouvez déjà faire des corrections dans OSM (en 
vérifiant bien avec les images du Cadastre et les photos aériennes IGN 
si le fractionnement est effectivement un artefact du Cadastre ou si au 
contraire il a bien une réalité physique qui doit être conservée dans OSM).
Ne vous embêter pas a signaler les faux-positifs sur Osmose, c'est un 
serveur de dev, l'info sera perdue.


Je sais qu'il y a beaucoup de faux positifs dans les centre ville à 
cause de la forme moins carrée des bâtiments.
En théorie il y a aussi proportionnellement beaucoup de faux positifs 
dans la région Rhône-Alpes étant donné que j'y ai déjà corrigé une 
majorité de cas.



Tyndare.

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

Re: [OSM-talk-fr] Problème avec Achavi ?

[Pierre-Yves Berrard]

Le 22 août 2016 à 21:57, Romain MEHUT  a écrit :

> Et j'imagine qu'on ne peut pas basculer sur overpass france ?
>
> Romain
>

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

Re: [OSM-talk-fr] Saisie d'une entité bâtiment avec différents services

[althio]

Je suis aussi d'accord, le premier jet me paraît utile et globalement
correct.

Les détails que j'aurai fait différemment si c'était mon édition :

Au niveau de l'area
>
> building = public [OK]
>
> amenity = social_facility [pas de tag amenity pour le building, à mon avis
> il n'y pas a d'entité à ce niveau dans ta représentation]
>
> name = Msap XXX [pas abréviation/acronyme]
>

name =  Maison de service au public XXX
short_name = MSAP XXX

> [...]
>


> Rajouter un point par service proposé dans le bâtiment avec les attributs
>
[rajouter un élément par service dans le bâtiment (point ou aire selon la
précision et l'importance de la localisation)]

> name = Service XXX [OK]
>
> Amenity = social_facility [OK]
>
> social_facility =XXX [OK]
>
> social_facility:for =XXX [OK]
>
> opening_hours = (*pour les permanences)* [OK]
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr