Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE… non rapproché

[Yves Pratter]

> La dernière modification de ce fichier remonte à 3j donc l’ajout de cette 
> entrée dans le dictionnaire ne semble pas suffire ?
La rue est passée en vert ce matin.
742130520Y  CHE ANC CHEM DE MOIRY   Ancien Chemin de Moiry  ORG 
  FR 
  
BANO 

JOSMID 

 P2 


Mais je constate que plusieurs rues ajoutées ou nommées hier avant la mise à 
jour de BANO sont encore en gris
742130140K  CHE DE CHANTEPOULET --  ORG 
  FR 
  
BANO 

JOSMID 

 P2 

742130200A  CHE DE COMBAVEY --  ORG 
  FR 
  
BANO 

JOSMID 

 P2 

742130080V  CHE DE LA CAFETA--  ORG 
  FR 
  
BANO 

JOSMID 

 P2 

742130835R  CHE DE LA TREILLE   --  ORG 
  FR 
  
BANO 

JOSMID 

 P2 

742130450X  CHE DE LETTRAZ  --  ORG 
  FR 
  
BANO 

JOSMID 

 P2 


Peut-être y a-t-il encore un retard dans la mise à jour effective des données 
OMS ?

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

[OSM-talk-fr] [BANO] màj nuit dernière ko ?

[Laurent Choisie]

Bonjour à tous,
J'ai complété des rues de plusieurs communes du 76 hier et la carte de
rendu BANO est restée désespérément rouge ce matin.
Comment peut-on savoir si le traitement de rapprochement des adresses
FANTOIR-BANO a bien eu lieu ? (pour éviter de vous reposer la question les
prochaines fois)
Merci d'avance de vos réponses,
Laurent CHOISIE (nouveau contributeur BANO depuis 3 semaines, proche Rouen)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?

[Vincent de Château-Thierry]

Bonjour,

> De: "Laurent Choisie" 
> 
> J'ai complété des rues de plusieurs communes du 76 hier et la carte
> de rendu BANO est restée désespérément rouge ce matin.
> Comment peut-on savoir si le traitement de rapprochement des adresses
> FANTOIR-BANO a bien eu lieu ? (pour éviter de vous reposer la
> question les prochaines fois)
> Merci d'avance de vos réponses,

(Réponse à Yves en même temps)
La cause cette fois-ci semble être l'arrêt des mises à jour de la base monde 
OSM qui nous sert de référence, depuis hier mi-journée :
http://munin.openstreetmap.fr/static/dynazoom.html?cgiurl_graph=/munin-cgi/munin-cgi-graph&plugin_name=osm12.free.org/osm105.openstreetmap.fr/osm_replication_lag_osm2pgsql&size_x=800&size_y=400&start_epoch=1416797537&stop_epoch=1416905537

> Laurent CHOISIE (nouveau contributeur BANO depuis 3 semaines, proche
> Rouen)
Bienvenue :)

vincent

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

Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?

[Pierre-Yves Berrard]

Le 25 novembre 2014 09:43, Laurent Choisie  a
écrit :

> Comment peut-on savoir si le traitement de rapprochement des adresses
> FANTOIR-BANO a bien eu lieu ? (pour éviter de vous reposer la question les
> prochaines fois)
>

Tu peux le voir ici par exemple :
https://github.com/osm-fr/bano-data/commits/master/1_statistiques_rapprochement_voirie.txt

J'allais justement dire que j'avais aussi repéré quelques bizarreries mais
je vais attendre que tout se remette d'applomb à la prochaine mise à jour.

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

Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?

[HELFER Denis]

-Message d'origine-
De : Vincent de Château-Thierry [mailto:osm.v...@free.fr] 
Envoyé : mardi 25 novembre 2014 10:03
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?


(Réponse à Yves en même temps)
La cause cette fois-ci semble être l'arrêt des mises à jour de la base monde 
OSM qui nous sert de référence, depuis hier mi-journée :
http://munin.openstreetmap.fr/static/dynazoom.html?cgiurl_graph=/munin-cgi/munin-cgi-graph&plugin_name=osm12.free.org/osm105.openstreetmap.fr/osm_replication_lag_osm2pgsql&size_x=800&size_y=400&start_epoch=1416797537&stop_epoch=1416905537


Ceci explique donc qu'une partie de mes modifs ont été prises en compte mais 
pas toutes. Je commençais à m'interroger sérieusement...
Une petite météo de la syncho BANO serait la bienvenue.

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

Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?

[Vincent de Château-Thierry]

> De: "HELFER Denis" 
> 
> Une petite météo de la syncho BANO serait la bienvenue.

La météo locale aura bientôt son bulletin commune par commune :
https://github.com/osm-fr/bano/issues/75
(mais ne dira rien pour la pluie à 1h)

Ce sera répercuté sur les pages de rapprochement Fantoir/OSM.

vincent

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

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[althio forum]

2014-11-24 16:24 GMT+01:00 sly (sylvain letuffe) :
> J'accompagne avec plaisir cette discussion afin que nous trouvions une
> méthode commune de gérer ça.
2014-11-24 18:16 GMT+01:00 Christian Quest :
> Garder la géométrie et modifier les tags me semble le plus intéressant, ça
> parmet de de conserver l'historique dans OSM et de comparer la géométrie à
> une "nouvelle".
2014-11-24 18:36 GMT+01:00 sly (sylvain letuffe) :
> Excellente idée.
> +1 de ma part pour conserver la géométrie et ne changer que les tags
> nécessaires.

+1 pour cette approche.


2014-11-24 16:24 GMT+01:00 sly (sylvain letuffe) :
> http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts sont
> limité à ce qui est (ou au pire, à ce qui reste)

Avec les éléments de Comparison_of_life_cycle_concepts, on peut tagger en
namespace:building :

A1. ce qui est [mais pas en état fonctionnel] et qui sera
*construction*: (being constructed at this time)

A2. ce qui était et qui est [mais pas en état fonctionnel]
*disused*: (not currently available for use, but could be reinstated
easily='in a reasonable state of repair but which are currently unused')

A3. ce qui était et ce qui reste [mais loin d'être en état fonctionnel]
*abandoned*: ('fallen into serious disrepair and which could only be put
back into operation with expensive effort')
*ruined*: (when in ruin)

B1. ce qui n'est pas encore [rien ou presque sur le terrain] mais qui
devrait être
*proposed*: [planned:] (planned, with a high likelihood of being
constructed)

B2. ce qui était et qui n'est plus [rien ou presque sur le terrain]
*demolished*: [destroyed:] (not existing anymore, without any traces left)
*historic*: (a previously valid characteristic)

Avec les éléments de Comparison_of_life_cycle_concepts, il manque le cas
spécial déjà mentionné (futur antérieur au conditionnel ascendant grammaire
subjonctivo-foireuse):
B3. ce qui était prévu mais n'a pas été construit (permis de construire,
avec trace dans le cadastre, mais jamais de réalisation, donc aucun
bâtiment sur le terrain)
Quelques propositions rapides pour tagger cette dernière catégorie...
* Cela peut être inclus dans un cas générique à définir, avec une note.
* Ou alors rentrer ça dans la case existante *historic*: .
* Ou alors une combinaison double *historic*:*proposed*: ou *disused*:
*proposed*: qui me semble sémantiquement proche de la réalité mais plus
complexe à comprendre à cause de la caractérisation à tiroirs.


Mais parfois on ne connaît pas la catégorie B[B1/B2/B3]... et il y a déjà
eu quelques propositions dans les messages précédents pour définir un cas
générique :

>> Tu peux mettre error:building=* plus note=* ?
> Ainsi, on peut choisir :
> error:building=yes
> ou, si on est sûr qu'il a existé :
> demolished:building=yes

Les options déjà proposées pour cette catégorie générique B[B1/B2/B3] :
* [building=no] n'est pas satisfaisant (cf. sly: risque de mauvaise
interprétation par les usagers qui feraient un building=* => bâtiment
générique)
* *error:*building=yes
* *non_existing:*building=yes
* *nobuilding*=yes
J'aime bien l'esprit de non_existing et je propose également :
** no:*building=yes
** absent:*building=yes

Avec note:building="pas de bâtiment sur le terrain, erreur dans le
cadastre, ne pas ré-importer ou retracer"

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

Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?

[Stéphane Péneau]

Le mardi 25 novembre 2014 10:26:04, Vincent de Château-Thierry a écrit :



De: "HELFER Denis" 

Une petite météo de la syncho BANO serait la bienvenue.


La météo locale aura bientôt son bulletin commune par commune :
https://github.com/osm-fr/bano/issues/75
(mais ne dira rien pour la pluie à 1h)


Avec les variations de température ?
Depuis hier, grâce à l'anticyclone des açores, nous gagnons 3 
degrés/rues. En parallèle, les températures clémentes nous ont permis 
de terminer les travaux de la nouvelle rue de la paix. Nous passons 
donc à un total de 358 rues au lieu de 357, sur lesquels 321 rues sont 
rapprochées, pour seulement 318 hier.


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

Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché

[Christian Quest]

Oui, problème de disque saturé sur osm105/layers utilisé par BANO pour
récupérer les données OSM récentes.
La mise à jour à été suspendue hier vers 14h, donc les contributions faites
après ne sont pas encore prises en compte dans BANO.

Le 25 novembre 2014 09:37, Yves Pratter  a écrit :

>
> La dernière modification de ce fichier remonte à 3j donc l'ajout de cette
> entrée dans le dictionnaire ne semble pas suffire ?
>
> La rue est passée en vert ce matin.
> 742130520YCHE ANC CHEM DE MOIRYAncien Chemin de MoiryORG
> FR
> 
> BANO
> 
> JOSMID
> 
> P2
> 
> Mais je constate que plusieurs rues ajoutées ou nommées hier avant la mise
> à jour de BANO sont encore en gris
> 742130140KCHE DE CHANTEPOULET--ORG
> FR
> 
> BANO
> 
> JOSMID
> 
> P2
> 
> 742130200ACHE DE COMBAVEY--ORG
> FR
> 
> BANO
> 
> JOSMID
> 
> P2
> 
> 742130080VCHE DE LA CAFETA--ORG
> FR
> 
> BANO
> 
> JOSMID
> 
> P2
> 
> 742130835RCHE DE LA TREILLE--ORG
> FR
> 
> BANO
> 
> JOSMID
> 
> P2
> 
> 742130450XCHE DE LETTRAZ--ORG
> FR
> 
> BANO
> 
> JOSMID
> 
> P2
> 
>
> Peut-être y a-t-il encore un retard dans la mise à jour effective des
> données OMS ?
>
> --
> Yves
>
> ___
> 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

[OSM-talk-fr] carte OSM pour l'Observatoire des Saisons

[lenny]

Bonjour
l'Observatoire des Saisons utilise aussi une carte umap OSM pour 
présenter les relais de l'observatoire

http://www.obs-saisons.fr/node/4264

cordialement
Lenny

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

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[sly (sylvain letuffe)]

On mardi 25 novembre 2014, you wrote:
> Avec les éléments de Comparison_of_life_cycle_concepts, il manque le
> (...) futur antérieur au conditionnel ascendant grammaire subjonctivo-
> foireuse):

Je vais laisser ça de coté pour l'instant, mon niveau linguistique 
n'atteignant pas le niveau requis, ainsi que la crainte d'un éparpillement 
certain qui nous attend si on commence à discuter du life_cycle_concepts.

Je vais me concentrer sur le problème à l'oeuvre ici: comment fait on pour 
réduire les chances qu'un importeur "(trop) rapide" n'ajoute et rajoute encore 
à chaque mise à jour un bâtiment toujours indiqué sur le cadastre, mais 
n'existant plus en réalité et ayant été supprimé par un contributeur terrain ?


> J'aime bien l'esprit de non_existing et je propose également :
> ** no:*building=yes

J'adore ! Efficace et simple à se souvenir. 
On ajoute donc "no:" devant les tags dont on sait qu'ils n'ont aucune réalité 
sur le terrain et dont l'objet a une très forte chance d'être ré-importé par 
un "armchair mapper"

En plus, cadeau bonux, il est déjà utilisé une petite centaine de fois.
http://taginfo.openstreetmap.org/search?q=no%3A

Il ne lui manquait plus qu'une page sur le wiki :
http://wiki.openstreetmap.org/wiki/Key:no
(commentaires bienvenus)

> Avec note:building="pas de bâtiment sur le terrain, erreur dans le
> cadastre, ne pas ré-importer ou retracer"

Tout à fait, la note reste vivement recommandée en plus. Bien que je préfère 
note=* car plus de chance d'être vue que note:building=*


-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825349.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?

[HELFER Denis]

-Message d'origine-
De : Vincent de Château-Thierry [mailto:osm.v...@free.fr] 
Envoyé : mardi 25 novembre 2014 10:26
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] [BANO] màj nuit dernière ko ?


> De: "HELFER Denis" 
> 
> Une petite météo de la syncho BANO serait la bienvenue.

La météo locale aura bientôt son bulletin commune par commune :
https://github.com/osm-fr/bano/issues/75
(mais ne dira rien pour la pluie à 1h)

Ce sera répercuté sur les pages de rapprochement Fantoir/OSM.

Trop cool ...
Mais comment fais-tu pour anticiper nos besoins ? Tu as une machine à voyager 
dans le futur ? T'as réalisé Interstellar ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[Yves Pratter]

> Avec les éléments de Comparison_of_life_cycle_concepts, on peut tagger en 
> namespace:building :
Merci althio pour ta synthèse (et ton humour) :-)

> B3. ce qui était prévu mais n'a pas été construit (permis de construire, avec 
> trace dans le cadastre, mais jamais de réalisation, donc aucun bâtiment sur 
> le terrain)
> Quelques propositions rapides pour tagger cette dernière catégorie...
> * Cela peut être inclus dans un cas générique à définir, avec une note.
> * Ou alors rentrer ça dans la case existante historic: .
> * Ou alors une combinaison double historic:proposed: ou disused:proposed: qui 
> me semble sémantiquement proche de la réalité mais plus complexe à comprendre 
> à cause de la caractérisation à tiroirs.
L’idée est là, mais il faut faire plus simple : proposer l’un des préfixe que 
tu as listé (ou pas) plus bas.
Quelque soit le préfixe, il aura l’effet que les moteurs de rendu n’afficheront 
pas l’objet.

Il faut « seulement » bien le choisir pour qu’il soit adopté par la communauté 
(et éviter une multiplication inutile et complexifiante).

> Mais parfois on ne connaît pas la catégorie B[B1/B2/B3]... et il y a déjà eu 
> quelques propositions dans les messages précédents pour définir un cas 
> générique :

> Les options déjà proposées pour cette catégorie générique B[B1/B2/B3] :
> * [building=no] n'est pas satisfaisant (cf. sly: risque de mauvaise 
> interprétation par les usagers qui feraient un building=* => bâtiment 
> générique)
Oui et n’empêche pas le rendu par les moteurs qui ne géreraient pas 
explicitement la valeur « no »

> * nobuilding=yes
Similaire au cas précédent

> * error:building=yes
> * non_existing:building=yes
> * no:building=yes
> * absent:building=yes
Ok

> Avec note:building="pas de bâtiment sur le terrain, erreur dans le cadastre, 
> ne pas ré-importer ou retracer »
Effectivement, la note avec le préfixe est plus ciblée.
note=* ou note:building=* peu importe, ces informations sont à destination des 
êtres humains ;-)

—
Yves

PS: pour les outils je propose deux variantes :
un script ou greffon sous JOSM qui compare le cadastre actuel dans une couche 
avec les données actuelles dans une autre
un script dans les serveur OSM France qui compare le cadastre actuel à sa 
version précédente et qui renvoie des propositions d’intégration ou de « 
démolition » à Osmose ?

L’algo :
Pour chaque bâtiment de la couche cadastre actuelle
nœuds_différents = 0
Pour chaque nœud
si pas de nœud à la même position dans l’autre couche alors nœuds_différents++
si nœuds_différents > 0 alors renvoyer une erreur

Il me semble que le plus efficace est de faire la comparaison entre deux 
versions du cadastre.
Avantage : pas de faux positifs si le bâtiment est recalé sur l’image Bing
Inconvénient : ça consomme de la place disque

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

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[sly (sylvain letuffe)]

On mardi 25 novembre 2014, you wrote:
> ** no:*building=yes
> ** absent:*building=yes

Évidement, c'est quand j'ai fini d'écrire la page :
http://wiki.openstreetmap.org/wiki/Key:no

et que je commence à lister les usages qui y ressemblent que je tombe sur :
http://wiki.openstreetmap.org/wiki/Key:removed

qui est utilisé ~1000 fois et qui semble avoir très exactement le même but.

Multiplier les tags pour un même usage est évidement une mauvaise idée comme 
dit yves, je propose de tout fusionner dans ce qui existe déjà :
removed:

Même "demolished", a bien y réfléchir, le peu qu'on gagne à dire que ça a été 
détruit par rapport à "n'est plus" ne me semble pas justifier deux tags

-- 
sly, direct contact : sylv...@letuffe.org
http://wiki.openstreetmap.org/wiki/User:Sletuffe




-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Outils-pour-mise-a-jour-du-bati-tp5825219p5825356.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché

[JB]

Le 25/11/2014 12:27, Christian Quest a écrit :
Oui, problème de disque saturé sur osm105/layers utilisé par BANO pour 
récupérer les données OSM récentes.
La mise à jour à été suspendue hier vers 14h, donc les contributions 
faites après ne sont pas encore prises en compte dans BANO.
Avec mon informatique balbutiant, ça veut dire plusieurs jours avant 
reprise ?

JB.


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

Re: [OSM-talk-fr] Création automatique de relations associated street

[Tony Emery]

J'ai réussi à relancer le fichier asso.rb.

Par contre, je ne pense pas que l'on puisse paramétrer le fichier .sh sous
windows, pas avec le bloc-note ou notepad, en tout cas.

Du coup, je te donne les relation_id des communes de la CCPRO, si tu peux me
faire plusieurs fichiers :

Villeosm_relation_id 
Bédarrides   147 870   
Caderousse   148 147   
Châteauneuf-du-Pape  148 164   
Courthézon   148 169   
Jonquières   148 979   
Orange   187 038   
Sorgues  181 308   


Merci d'avance



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Creation-automatique-de-relations-associated-street-tp5823180p5825364.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché

[Christian Quest]

J'espère que ça prendra bien moins. Quelques tables grossissent trop vite à
force d'être mises à jour. Des "trous" se créent et occupent inutilement de
l'espace que l'on ne récupère qu'en faisant des manip un peu longues et
bloquantes (obligé de suspendre les updates).

Je viens par exemple de "compacter" la table des ways qui est passée de
108Go à 65Go... ça faisait quand même une belle éponge !



Le 25 novembre 2014 15:40, JB  a écrit :

> Le 25/11/2014 12:27, Christian Quest a écrit :
>
>> Oui, problème de disque saturé sur osm105/layers utilisé par BANO pour
>> récupérer les données OSM récentes.
>> La mise à jour à été suspendue hier vers 14h, donc les contributions
>> faites après ne sont pas encore prises en compte dans BANO.
>>
> Avec mon informatique balbutiant, ça veut dire plusieurs jours avant
> reprise ?
> JB.
>
>
>
> ___
> 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] Outils pour mise à jour du bâti ?

[Pieren]

2014-11-25 13:13 GMT+01:00 sly (sylvain letuffe) :

>> J'aime bien l'esprit de non_existing et je propose également :
>> ** no:*building=yes
>
> J'adore ! Efficace et simple à se souvenir.

J'ai moi aussi un avis positivement négatif sur ce genre de tag, qui
me rappelle les "entrance=exit" (!) ou les "amenity=drinking_water" +
"drinkable=no" (!!)

Pieren

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

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[Pieren]

Notez que cette thématique n'est pas exclusive au cadastre ni à la
France. Elle se pose pour tous les endroits où plusieurs sources
existent (ou la même source mais avec des dates différentes). Je me
souviens d'un cas où un contributeur s'échinait à supprimer un bout de
route visible sur Bing mais qui n'existait plus sur le terrain après
travaux.

Pieren

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

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[Pieren]

2014-11-25 13:31 GMT+01:00 Yves Pratter :

> * [building=no] n'est pas satisfaisant (cf. sly: risque de mauvaise
> interprétation par les usagers qui feraient un building=* => bâtiment
> générique)
>
> Oui et n’empêche pas le rendu par les moteurs qui ne géreraient pas
> explicitement la valeur « no »


Pas d'accord avec ça. La valeur 'no' est courante dans OSM (voir
taginfo) et de nombreux tags sont vérifiés avec ça. Par exemple, le
"oneway=no", cher à notre ami Sly qui voulait en mettre partout à ses
débuts ;-)

Pieren

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

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[althio forum]

Je récapitule par ordre de préférence approximatif :

** removed:*building=* (déjà utlisé, un peu)
** no:*building=* (déjà utlisé, un peu)
** absent:*building=*
* *non_existing:*building=*
* *error:*building=*
* *nobuilding*=*
* building=no (sly et Yves le trouvent gênant, Pieren pas tant que ça ; en
tout cas il supprime éventuellement une partie de l'historique puisque
'yes' ou 'value' est remplacé par 'no')

Autres tags à ajouter/modifier:

Une belle note[:building]=blabla

Coller aussi removed: devant la source obsolète
+ removed:source=cadastre ou imagerie ou survey /MM [source obsolète]
et mettre à jour avec un nouveau tag source
+ source[:building]=cadastre ou imagerie ou survey /MM [source
actualisée]



2014-11-25 15:57 GMT+01:00 Pieren :

> Notez que cette thématique n'est pas exclusive au cadastre ni à la
> France. Elle se pose pour tous les endroits où plusieurs sources
> existent (ou la même source mais avec des dates différentes). Je me
> souviens d'un cas où un contributeur s'échinait à supprimer un bout de
> route visible sur Bing mais qui n'existait plus sur le terrain après
> travaux.
>
> Pieren
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[Jérôme Cornet]

Tu n'es pas le premier à poser cette question sur la liste. Ma contribution:

J'ai écrit et utilisé (ainsi que d'autres) un outil permettant de gérer la 
problématique de fusion du bâti cadastre par rapport à de l'existant). Ça ne 
fait pas la moitié des trucs évoqués sur ce fil mais c'est dispo.

http://github.com/jecor/bati-fusion

N'hésites  pas si tu as besoin d'aide,

Jérôme 


> Le 24 nov. 2014 à 18:02, Yves Pratter  a écrit :
> 
> Bonjour,
> 
> Je profile du retour de BANO pour intégrer les nouveaux bâtiments et modifier 
> ceux qui ont changés.
> 
> Avec JOSM, je fais un « diff visuel » en chargeant le cadastre en arrière 
> plan et par dessus j’affiche les données OSM.
> 
> Pour que ça soit plus facile :
> je n’affiche que le bâti sur la couche OSM (filtre building=* et E H I cochés)
> je change la couleur de la couche du dessous en rouge (préférences -> 
> paramètres d’affichage -> Couleurs : inactif=#FF
> 
> Ça fonctionne assez bien, mais on peut passer à côté de quelques bâtiments.
> 
> Existe-t-il un outil pour faire ça quasi-automatiquement et/ou indiquer les 
> changements à faire dans Osmose ?
> 
> —
> Yves
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Outils pour mise à jour du bâti ?

[Yves Pratter]

@Sly
> 
> http://wiki.openstreetmap.org/wiki/Key:removed qui est utilisé ~1000 fois et 
> qui semble avoir très exactement le même but.
Pas trop vite ;-)
Sur les 1000, il y a 770 removed:power 
 éditées par 
seulement 7 utilisateurs différents et 6 valeurs différentes.

> Même "demolished", a bien y réfléchir, le peu qu'on gagne à dire que ça a été 
>  détruit par rapport à "n'est plus" ne me semble pas justifier deux tags
Je ne suis pas un spécialiste de la création, validation, standardisation de 
tags (le tout en dehors du cercle franco-français), mais le sens de demolished 
est clair.
removed:* me va aussi pour un élément du cadastre qui n’a jamais été construit, 
mais pour une bâtisse qui a été démolie c’est moins clair.

Que disent nos experts de la liste tag ?

@Pieren
> Je me souviens d'un cas où un contributeur s'échinait à supprimer un bout de 
> route visible sur Bing mais qui n'existait plus sur le terrain après travaux.
Dans le même genre, j’ai dessiné un chemin dans les terrains de 
Paris-Charles-de-Gaulle et je me suis aperçu plus tard en regardent les cartes 
aériennes qu’il y avait de nouveaux terminaux à la place :D
Il y avait peut-être quelqu’un qui a effacé ce chemin un peu plus tôt ?

Le fait que les objets effacés ne soient plus « visibles » facilement est 
problématique (d’autant plus qu’ils restent ou pas en base de données OSM 
consomme de toutes façon des IDs).
Donc les garder mais avec un préfixe acceptable (et accepté) me semble beaucoup 
mieux (ou les rendre visibles facilement par les logiciels d’éditions).

> Pas d'accord avec ça. La valeur 'no' est courante dans OSM (voir taginfo) et 
> de nombreux tags sont vérifiés avec ça.
OK, si Mapnik et la plupart des outils gèrent building=no, amenity=no… ça me va 
aussi :)

Comme ça été déjà dit, cette solution à l’inconvénient de « perdre » la valeur 
du tag.

@althio
> Coller aussi removed: devant la source obsolète + removed:source=cadastre ou 
> imagerie ou survey /MM [source obsolète]

J’ai compris qu’il fallait mettre ce préfixe devant l’objet lui même, pas sa 
source.
Et pour un bâtiment réellement détruit, la source cadastre est aussi? fiable ;-)

@Jérôme
> J'ai écrit et utilisé (ainsi que d'autres) un outil permettant de gérer la 
> problématique de fusion du bâti cadastre par rapport à de l’existant)
Je n’ai pas encore regardé les détails du source C.
Je viens de voir les versions compilées, je testerais demain :-)

En pratique, ça marche assez bien pour les ajouts et les démolitions ?


Bonne soirée,

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

Re: [OSM-talk-fr] Suivi qualité des frontières communales

[Stéphane Péneau]

J'ai tenté de bidouiller quelque chose avec Maperitive que je 
découvrais, et voici un extrait  en pièce jointe.


On distingue facilement les zones superposées, les "no man's land", et 
les endroits où la limite d'Osm s'écarte de l'idéal.



Stf


Le 23/11/2014 18:19, Stéphane Péneau a écrit :

Bonsoir,

En dégommant du rouge dans le 44 pour Bano, je me suis retrouvé à 
utiliser régulièrement les couches cadastres, ce que je n'avais pas 
fait depuis un moment.
La surprise est que les frontières sont assez régulièrement 
imprécises, décalées, voire parfois très décalées.


Ce que j'ai surtout remarqué, c'est vouloir les corriger est assez 
fastidieux avec les 2 méthodes que je connais :


- Charger les limites communales depuis casastre.openstreetmap.gouv : 
Les récupérer prend du temps, et une fois fait, on se mélange assez 
rapidement les pinceaux entre celles de la commune A, de la commune B, 
et la frontière existante dans Osm.


- Charger les couches cadastrales des 2 communes, basculer de l'une à 
l'autre, jouer de la touche F10, jouer avec la transparence, etc...


Sauf s'il y a une autre méthode plus efficace, je me disais qu'une 
couche à la route 500/hydro/etc... serait bien pratique.


On pourrait imaginer récupérer les limites de toutes les communes dont 
le cadastre est vectorisé à intervalle régulier (mensuel ?) et pouvoir 
les afficher sur cette couche.


Ensuite, on peut remplir les espaces entre les 2 limites avec 2 
couleurs différentes en fonction de la situation (Il y a un espace 
"vide" entre les 2 limites, ou bien les limites englobent des surfaces 
communes.). Ces couleurs devront être assez transparentes si c'est 
possible.


Je ne suis pas certain qu'afficher la limite présente dans Osm soit 
utile (elle est déjà sur le fond de carte), sauf à réussir à mettre en 
valeur les zones où elle s'éloigne beaucoup de son emplacement idéal.


Oui, c'est du yakafokon.

Stéphane

___
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] BANO/FANTOIR : CHE ANC CHEM DE... non rapproché

[Yves Pratter]

> Le 25 nov. 2014 à 15:53, Christian Quest  a écrit :
> 
>  Des "trous" se créent et occupent inutilement de l'espace que l'on ne 
> récupère qu'en faisant des manip un peu longues et bloquantes (obligé de 
> suspendre les updates).
Tu utilises VACCUUM de pgsql ?


La doc  indique un 
mode qui n’est pas bloquant et qui est conseillé de faire régulièrement sur des 
tables qui grossissent trop vites :
Plain VACUUM (without FULL) simply reclaims space and makes it available for 
re-use.
This form of the command can operate in parallel with normal reading and 
writing of the table, as an exclusive lock is not obtained.

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

[OSM-talk-fr] De l'usage des tags postal_code addr:postcode

[Frédéric Rodrigo]

Bonsoir,

De ce que j'en comprend on utilise postal_code pour des zones et 
addr:postcode pour des points et bâtiment. En tout cas c'est comme ça 
que c'est ça se présente à l'étranger. En France les relations de 
communes utilisent addr:postcode.


On trouve en France finalement assez peu de tag postal_code, et surtout 
utilisé dans le nord et l'est :

http://taginfo.openstreetmap.fr/keys/postal_code
http://taginfo.openstreetmap.fr/keys/postal_code#map
(tag info n'affiche pas les relations)

C'est cependant beaucoup plus utilisé chez nos voisins :
http://taginfo.openstreetmap.org/keys/postal_code#map

D'un point de vue franco-français la distinction n'est pas forcement 
visible.


Mais les codes postaux dans certains pays sont plus court pour les zones 
que pour les rues ou bloc de maison. Avec pour exemple typique des codes 
postaux hiérarchiques des UK ou des Payas-Bas

https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom

Il me semble que dans un soucie de cohérence globale avec le taging dans 
les autres pays il nous faudrait basculer pour les communes vers la tag 
postal_code.


http://wiki.openstreetmap.org/wiki/Postal_code
http://wiki.openstreetmap.org/wiki/Key:addr:postcode

Frédéric.

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