Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

D'accord pour conserver ces adresses, mais on a toujours un problème car on
n'a encore strictement rien de clair (et non ambigu) pour attribuer une
adresse aux autres objets autour !
Ces adresses restent aussi incomplètes (batiment, escalier, étage, porte,
pièce...) et pourtant ces éléments font bien partie du schema addr:*
standard.*.

En déporter une partie sur "contact:*" est stupide car ce n'est pas fait
pour ça et là encore contact:* n'a rien de commun avec addr:*, c'est pour
donner une autre adresse, pas nécessairement au même endroit (utiliser
contact:* avec des éléments d'adresse c'est pour écrire à leurs
responsable/gérant/service commercial, ce peut être une boite postale, pas
pour se rendre au lieu indiqué; les autres élements de "contact:*" sont des
numéros de téléphone fixes ou mobiles, fax, boites mail, sites internets,
réseaux sociaux : tous délocalisés ou délocalisables n'importe où sans
qu'on puisse savoir réellement où, donc NON géolocalisés; vouloir faire un
lien entre un bout de contact:* et un bout de addr:* pour former une
adresse est carrément faux et stupide) !

Le 15 juin 2016 à 08:37,  a écrit :

>
> Le 14/06/2016 à 16:28, Romain MEHUT - romain.me...@gmail.com a écrit :
>
> On les encadre où celles-ci "*Une adresse cadastrale n'est même pas un
> objet en soit (le noeud anonyme qu'on met dans OSM est arbitraire et ne
> correspond pas à la réalité qui désigne une surface incluant plusieurs
> éléments.*" et "*Le noeud d'adresse n'est qu'une position approximative.
> Ce n'est pas un objet, il n'a aucune réalité en lui-même sur le terrain.*"
> ?
>
> Help...
>
> Romain
>
> Dans l'encadré, tu pourras aussi mettre que le nœud d'adresse est
> grosso-modo le centroïde des bàl de cette adresse, c'est à dire le
> barycentre géographique des boîtes aux lettres de l'adresse ;-).
>
> L'adresse c'est soit où on voit la plaque de l'adresse (40 par exemple),
> soit où se trouvent les bàl. Sur certains endroits c'est modélisé comme les
> centres des polygones, sur d'autres le projeté du polygone sur la voie
> (plutôt le milieu de l'arrête du polygone tangent à la voie).
>
> Sur Lorient les adresses géolocalisées ont été libérées, un test avec QGis
> m'a semblé donner des résultats très pertinents.
>
> Supporter les adresses via les POIs réels (commerces, ...) me semble
> douteux : si le commerce ferme, l'adresse elle existe toujours.
> Soit on appuie l'adresse sur un nœud "vide" soit sur un polygone de bâti.
>
> D'accord avec Christian & Christian : on n'a en général besoin que d'une
> adresse.
> *En général*, sinon je vous laisse le soin de trouver l'adresse de ce
> nœud :
> http://www.openstreetmap.org/node/3801507766#map=19/48.84462/2.40224
>
> N. B. : suivant les villes, par exemple Brest ou Lorient, les schémas
> utilisés sont différents.
>
> Perso je mets les infos du POI sur le polygone si le bâtiment n'a qu'un
> POI, sinon je mets les POI au niveau du polygone, sans adresse en général
> (ou associé avec l'associatedStreet. Grosso modo comme d'autres je regarde
> ce qui se fait dans le coin histoire d'être *raccord*.
>
> Jean-Yvon
>
> ___
> 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] Import de données OSM dans PostGIS

[csv]

Bonjour

Personnellement j'ai laissé tomber spatialite qui me plantait certaines 
bases. Il a l'avantage de la légèreté, c'est sûr, avec des process de 
requête très simples et agréables, mais je trouve postgis/postgresql 
plus sûr.


Evidemment je ne suis pas un pro de la DB, donc je peux aussi mal 
prendre en compte certaines situations. Mais bon, un retour d'expérience 
parmi d'autres...


Cyril


Le 14/06/2016 à 16:42, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / 
DT ALCA APPUI PERFORMANCE) a écrit :

Tu as pensé à une solution spatialite ?
Avantages :
- installation enfantine
- multi-plateforme
- s'intègre directement dans ArcGIS (v 10.3 minimum) selon la doc (mais pas 
encore testé)
- base mono-utilisateur
- très paramétrable (et automatisable, y compris avec du python)
- fonctionne très bien aussi avec QGis (testé du coup ;-)
- export possible en shapefile
-  compatbible OGC

Inconvénients
- je ne sais pas comment ça tient la charge si volume très important de données.

Pour ma part c'est les choix sur lesquels je m'oriente pour un projet similaire 
que je vais démarrer très prochainement.
Pourquoi une geodatabase ?

Denis


-Message d'origine-
De : Tony Emery [mailto:tony.em...@yahoo.fr]
Envoyé : mardi 14 juin 2016 15:18
À : talk-fr@openstreetmap.org
Objet : [OSM-talk-fr] Import de données OSM dans PostGIS

Bonjour à tous,

Suite aux différentes présentations du dernier SOTM-FR et en lien avec une 
réflexion que je mène déjà depuis quelques temps, je me lance (enfin) dans le 
grand bain de l'import quasi-big data.

En fait, je souhaite aller plus loin dans la démarche d'import des données OSM 
en local que celle que j'ai présenté à Clermont-Ferrand.

Jusqu'à présent, j'utilise un script python pour automatiser l'import de 
certaines données OSM dans des fichiers planet en local, puis, avec la 
bibliothèque arcpy d'ESRI, qui renvoi tout ça dans une géodatabase ESRI (je 
vous entends siffler dans le fond).

J'ai bien écouté les présentations qui expliquaient comment utiliser osm2pgsql, 
switch2osm et autre imposm3. Mais il y a 2 contraintes que je n'arrive pas à 
lever :
- comment ça s'installe, ça se paramètre et ça fonctionne ?
- Est-ce qu'il existe la même chose pour un environnement Windows, car nos 
serveurs sont ainsi ?

Du coup, je recherche un tutoriel à jour (donc récent) et qui explique
(très) simplement comment mettre en place une solution automatisée permettant :
- de télécharger les données d'une emprise géographique tous les soirs (ou, à 
défaut, le différentiel)
- que ces données soient versées plus ou moins directement dans une Base 
PostGIS.
Pour le coup, je suis aussi éventuellement preneur d'une solution full open 
source Ubuntu que je testerai chez moi.

Merci d'avance pour vos idées.

Tony



-
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/Import-de-donnees-OSM-dans-PostGIS-tp5875478.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
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it.
___
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] Bonnes et moins bonnes visibilités OSM

[osm . sanspourriel]

Le 14/06/2016 à 16:28, Romain MEHUT - romain.me...@gmail.com a écrit :
On les encadre où celles-ci "/Une adresse cadastrale n'est même pas un 
objet en soit (le noeud anonyme qu'on met dans OSM est arbitraire et 
ne correspond pas à la réalité qui désigne une surface incluant 
plusieurs éléments./" et "/Le noeud d'adresse n'est qu'une position 
approximative. Ce n'est pas un objet, il n'a aucune réalité en 
lui-même sur le terrain./" ?


Help...

Romain
Dans l'encadré, tu pourras aussi mettre que le nœud d'adresse est 
grosso-modo le centroïde des bàl de cette adresse, c'est à dire le 
barycentre géographique des boîtes aux lettres de l'adresse ;-).


L'adresse c'est soit où on voit la plaque de l'adresse (40 par exemple), 
soit où se trouvent les bàl. Sur certains endroits c'est modélisé comme 
les centres des polygones, sur d'autres le projeté du polygone sur la 
voie (plutôt le milieu de l'arrête du polygone tangent à la voie).


Sur Lorient les adresses géolocalisées ont été libérées, un test avec 
QGis m'a semblé donner des résultats très pertinents.


Supporter les adresses via les POIs réels (commerces, ...) me semble 
douteux : si le commerce ferme, l'adresse elle existe toujours.

Soit on appuie l'adresse sur un nœud "vide" soit sur un polygone de bâti.

D'accord avec Christian & Christian : on n'a en général besoin que d'une 
adresse.

/En général/, sinon je vous laisse le soin de trouver l'adresse de ce nœud :
http://www.openstreetmap.org/node/3801507766#map=19/48.84462/2.40224

N. B. : suivant les villes, par exemple Brest ou Lorient, les schémas 
utilisés sont différents.


Perso je mets les infos du POI sur le polygone si le bâtiment n'a qu'un 
POI, sinon je mets les POI au niveau du polygone, sans adresse en 
général (ou associé avec l'associatedStreet. Grosso modo comme d'autres 
je regarde ce qui se fait dans le coin histoire d'être /raccord/.


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

Re: [OSM-talk-fr] Adresses, lotissements et résidences

[Tyndare]

On 14/06/2016 15:51, Tony Emery wrote:

Du coup, j'ai un problème pour gérer dans un système unique les voies qui
sont à l'intérieur d'un lotissement ou d'une résidence et qui, soit:
- contienne un nom officiel (délibération de la commune) ;

official_name ?

- contienne un nom non-officiel (donné par les riverains) ;

local_name ?

- sont officiellement ou non dénommées comme le lotissement ;
Je me suis posé la question de savoir si on doit considérer 
"Lotissement" comme un type de voie valide au même titre que Allée, 
Impasse, etc... Je penche pour oui.

- n'ont pas de nom ;
SI on considère "Lotissement" comme un type valide de voie, je pense 
qu'il n'y a pas de problème à dupliquer le nom du lotissement sur le nom 
des voies, mais si elles n'ont officiellement pas de noms, c'est 
correcte aussi de ne pas les nommer dans OSM.


*La problématique adresses*
Et à tout cela, y ajouter :
- les adresses avec un numéro qui peut être le même dans 2 lotissement
différents et desservis pas la même voie ;
C'est que le numéro se réfère au lotissement et non pas à la rue, comme 
tu as judicieusement utilisé place= pour cartographier les lotissement 
tu peux utiliser addr:place à la place de addr:street pour les adresses 
associées.

Mais ici la relation associatedStreet montre ses limites.

- les anciennes numérotations classiques qui côtoient les nouvelles
numérotations métriques ;

Normalement cela doit être une situation de transition.
Tant que les deux numérotations sont considérée comme valides, je ne 
vois pas d'autres alternatives que de les faire cohabiter même si cela 
donne des adresses dupliquées.

Ensuite il faut peut être passer l'ancienne numérotation en disused: ?


- la notion de bâtiment ou de porte dans les résidences (et qu'ils
apparaissent dans osm.org) ;

Avec addr:housename, addr:unit, addr:door  tu ne trouves pas ton bonheur ?
On peut aussi donner une valeur name= à un nœud entrance=* (je crois 
qu'il apparaîtra sur le rendu mapnik)


S'il y a un même numéro addr:housenumber pour toute la résidence il faut 
pouvoir l'associer à chacune des portes ou bâtiments.
Donc soit il faut indiquer l'addr:housenumber sur an polygone englobant 
soit il faut le dupliquer sur chacune des portes et bâtiments 
adressables distinctement.


REM: L'utilisation de contact:housenumber à la place de addr:housenumber 
comme souvent proposé dans cette mailing list pour éviter la duplication 
me paraîtrait très étrange dans cette situation (cad en association avec 
addr:door ou addr:unit) au point ou je commence à pencher pour le fait 
que l'utilisation de contact:housenumber est effectivement un «tagguer 
pour le non rendu», et qu'il faut que je me résolve à considérer 
addr:housenumber comme un simple attribut au même titre que le nom pour 
une voie qui se retrouve dupliqué sur chacun des segments.

La pertinence des réponses de Pieren me manque...


- les voies qui n'ont jamais été numérotées mais pour lesquelles on a
recensé des logements ;
Ça n'empêche pas d'utiliser addr:street ou associatedStreet pour faire 
le lien.





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

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[Sylvain Maillard]

Les bases spatialite ça marche bien pour de la carto, j'utilise ça pour
plusieurs projets au boulot !

Il faut surtout éviter de créer de trop grosses bases, au delà de 2Go il y
a une perte de performance ...


Sylvain

Le 14 juin 2016 à 16:35, Tony Emery  a écrit :

> Du coup, quand on créé une requête overpass pour récupérer les données dans
> un fichier xml (par défaut), est-ce qu'on peut paramétrer la requête pour
> qu'elle ne télécharge que la différence entre la base osm et ce qui est
> dans
> le fichier xml ?
>
>
>
> -
> 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/Import-de-donnees-OSM-dans-PostGIS-tp5875478p5875492.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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Avis de thèse à l'IGN

[Emilie Laffray]

Peut etre que c'est mon ticket pour rentrer en France :p

2016-06-14 8:14 GMT-07:00 Frédéric Rodrigo :

> Le 14/06/2016 à 15:24, Nicolas Moyroud a écrit :
>
>> Même réflexion en lisant le titre. Certians diront peut-être que j'ai
>> l'esprit mal placé mais en lisant  le résumé voici ce que j'entend à
>> demi-mot : comment nous le grand IGN pouvons-nous aider ces pauvres diables
>> qui se démènent avec un système collaboratif (donc défectueux par nature) à
>> faire des choses aussi bonnes que les notres ? Quand je vois certains des
>> trucs qu'il propose dans le sujet, je ne sais pas si ils croient innover,
>> mais moi la plupart du temps j'ai juste l'impression qu'ils parlent
>> d'osmose... Fred devrait postuler il a déjà presque fait les 3 ans de
>> travail ;-)
>>
>> Ça a été posté aujourd'hui sur georezo avec une date limite de
> candidature au 12 juin... les candidats n'ont pas du se bousculer, j'ai
> encore toutes mes chances ;-), et puis ça fait 6 ans que je bosse sur
> Osmose !
>
> Frédéric, Dr. ès QA.
>
>
>
> ___
> 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] Bonnes et moins bonnes visibilités OSM

[Tony Emery]

verdy_p wrote
> L'ennui c'est que les adresses ne se limitent pas seulemetn à un
> housenumber (notion liée à la propriété cadastrale, formée sur une ou
> plusieurs parcelles). 

Le tag "housenumber" porte sur le numéro de l'adresse. Dans ce cas, cette
information n'est absolument pas liée à la propriété cadastrale car je peux
te donner des milliers d'exemples en France où l'adresse cadastrale ne
contient pas de numéro.


verdy_p wrote
> Elle est même insuffisante puisqu'à cette notion de propriété vient se
> greffer celle de résidents/locataires (qui ont aussi une existence
> fiscale, mais non cadastrale) : ils ont aussi leurs adresses toutes aussi
> importantes, et quand le housenumber ne suffit plus, on doit rentrer dans
> plus de détails : numéo ou nom de bâtiment, étage, numéro de porte... (des
> propriétés aussi importantes du schéma addr:*).

Là encore, ce n'est pas juste, mais je ne détaille pas car j'en aurais pour
la semaine à expliquer les différences.


verdy_p wrote
> Je crois qu'ici on est trop obnubilé par vouloir une base BANO "propre" ne
> tenant qu'à établir une liste des propriétés et ignorer totalement ceux
> qui les occupent (résidents/locataires).
> 
> A vouloir utiliser contact:* pour lever les ambiguités, on a détourné la
> finalité de contact:* et crée de nouvelles ambiguités (ou impossibilités
> de codification).

Au contraire, utiliser contact:* permet d'utiliser, pour les commerces et
autres activités, des adresses qui peuvent être postale et, donc, pas du
tout des adresses physiques.


verdy_p wrote
> Si vous voulez absolument un housenumber unique pour faire plaisir à BANO
> (j'appelle ça taguer pour le rendu, ici les rendus et analyses BANO  !) je
> ne vois pas comment procéder autrement que de créer des relations
> associatedHousenumber pour pouvoir y rattacher les *différents* objets
> distincts qui y sont rattachés (les résidents/locataires, et dans le cas
> présent les commerces).

Encore une fois, au contraire, je prône plutôt pour doubler les numéros
d'adresses identiques dans certains cas à définir.

Reste à définir comment qualifier les noms/numéros de bâtiments ou des
entrées dans les résidences collectives.
De même pour les numéros de lot dans certains lotissement qui ne sont pas
forcément de numéros d'adresse de voie mais pour lesquels on n'a rien
d'autre pour distinguer chaque logement ou maison.

C'est d'ailleurs le sujet en plein de mon message "Adresses, lotissements et
résidences"



-
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/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875508.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] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

Le 14 juin 2016 à 19:01, Christian Rogel 
a écrit :

> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
>
> Bonjour,
>
> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>
>
>> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
>> des noeuds différents, proches mais taguant des objets différents ayant
>> *certaines* propriétés communes (dont le numéro de rue associé).
>>
>
> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de ne
> décrire un objet qu'une fois, et c'est une règle générale pas spécifique
> aux adresses.*"
>
>
>> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
>> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
>> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
>> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
>> que les deux autres, il n'ajoute rien de mieux.
>>
>
> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
> justement l'adresse en question. Partant du constat qu'on ne décrit un
> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
> sens.
>
>
> Malgré l’accord entre vous, je suis convaincu que vous mélangez deux
> objets différents qui ne font jamais des doublons, principalement parce que
> cela vous irrite l’œil de voir côte à côte deux nombres (esprit geek ?).
> En réalité, la création de chaque objet relève d’une logique différente
> qui doit empêcher d’appliquer la règle «  one feature, one tag ».
> Vouloir fusionner les expressions apparemment identiques de deux objets
> est, commme je l’ai dit, une variété de taggage pour le rendu.
>

Le fait est que l'adresse où Romain l'entends est réduite à sa seule
définition communale/cadastrale, du point de vue de son unique propriétaire
(une personne ou une communauté de personnes dans le cas d'une
copropriété). le schéma addr:* n'est pas réduit à seulement cela. Vouloir
éliminer les résidents/locataires est quelquechose que même
l'administration fiscale ne fait pas. Sinon il n'y aurait que les taxes
foncières, pas les taxes locatives et autres taxes communales à la charge
non du propriétaire mais du/des résident(s).

Et ce n'est d'ailleurs pas spécifiquement français, partout dans le monde
il y a des adresses partagées *en partie* par leurs occupants: si on place
le curseur de l'unicité sur le seul numéro dans une rue on oublie
totalement les résidents et dans ce cas on peut oublier une bonne partie du
schéma addr:*

De plus la pseudo-solution qui consiste à surcharger "contact:housebumber"
n'a jamais été documentée ou approuvée. On la découvre par hasard mais
c'est undétournement de la fonction qui crée une nouvelle ambiguïté. le
schéma contact:* a justement été fait pour mentionner des infos qui ne sont
pas directement liées à la position géographique de l'objet qui est annoté
de cette façon: les numéros de téléphones sont portables, comme les email,
comme les adresses de facturation; dans le commerce et les entrerprises en
général il est extrèmement courant qu'un établissement ne soit pas
contactable sur place mais dans un autre établissement, voire même dans une
autre société, même pas nécessairement dans le même pays.

Il faut revenir au schéma addr:* tel qu'il est standardisé. Si le doublon
de valeurs vous choque à cause de BANO créez un objet ad hoc pour les
housenumber, tout en étant conscient que les adresses BANO de cette façon
ne peuvent représenter de façon correcte les adresses exactes des occupants.

Ces adresses sont insuffisantes, il manque des détails: batiment, escalier
,étage, porte, nom de l'occupant réel, et la géométrie du noeud est tout
aussi insuffisante, quelle que soit la précision de placement de ce noeud
totalement virtuel qui ne correspond en rien à ce que connait le cadastre
ou la commune, sa position étant en fait dans OSM étant en fait totalement
arbitraire: l'adresse réelle c'est une surface délimitée (pas un noeud dans
cette surface et encore moins en bordure ce cette surface sur une ligne
mitoyenne avec la voirie publique, une ligne qui n'est en fait même pas
tracée dans OSM puisqu'on n'a pas inclus le découpage parcellaire, et
qu'une adresse se compose souvent de plusieurs parcelles réunies pour des
raisons historiques !)

Ajoutez à ça que la numérotation des rues peut avoir des trous très
irréguliers (notammeent dans les communes à numérotation métrique), on voit
bien qu'on ne peut rien déduire de l'adresse d'un occupant en cherchant un
noeud d'adresse proche: on a toutes les chances de se planter de numéro !
Admettons que ce numéro serve au repérage, c'est alors juste une
alternative aux coordonnées géographiques mais ça n'indique rien de précis
autour. On n'a rien pour réunir des objets proches et aucun critère fiable
pour déterminer le numéro si ce numéro n'est pas porté ou par chacun des
objets qui l'ont en partage ou s'il n'existe aucune rel

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Christian Rogel]

> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
> 
> Bonjour,
> 
> Le 13 juin 2016 à 20:19, Philippe Verdy  > a écrit :
>  
> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont des 
> noeuds différents, proches mais taguant des objets différents ayant 
> *certaines* propriétés communes (dont le numéro de rue associé).
> 
> Je suis de l'avis de l'autre Christian soit "Le principe d'OSM est de ne 
> décrire un objet qu'une fois, et c'est une règle générale pas spécifique aux 
> adresses."
>  
> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide de 
> tags et PAS les deux deux des POIs distincts des deux commerces qui sont au 
> 40: en effet ce noeud vierge a toutes ses propriétés communes avec les deux 
> autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité que les 
> deux autres, il n'ajoute rien de mieux.
> 
> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier justement 
> l'adresse en question. Partant du constat qu'on ne décrit un objet qu'une 
> seule fois, si tu supprimes ce nœud, il te faudrait choisir entre les deux 
> POI pour y associer l'adresse... or cela n'a pas plus de sens.

Malgré l’accord entre vous, je suis convaincu que vous mélangez deux objets 
différents qui ne font jamais des doublons, principalement parce que cela vous 
irrite l’œil de voir côte à côte deux nombres (esprit geek ?).
En réalité, la création de chaque objet relève d’une logique différente qui 
doit empêcher d’appliquer la règle «  one feature, one tag ».
Vouloir fusionner les expressions apparemment identiques de deux objets est, 
commme je l’ai dit, une variété de taggage pour le rendu.

L’adresse est attribuée par la commune à une parcelle de terrain, uniquement 
celle-ci supporte un immeuble taxable (hors immeubles non clos ou légers, comme 
les abris de jardin, taxables forfaitairement).
J’insiste sur le fait qu’il s’agit de l’immeuble et de la parcelle.Les données 
sur la nouvelle construction sont transmises au cadastre (impôts) qui utilise 
le numéro de parcelle et l’adresse, si la commune a numéroté la rue.

Dans le cas du quartier commerçant de Dinan, certains usagers d’une fraction de 
l’immeuble utilisent légitimemen un bien commun à tous les occupants, 
l’adresse, pour fournir un repère géospatial à leurs éventuels clients.
C’est donc favoriser la privatisation d’un bien commun que d’effacer l’adresse 
qui préexistait pour donner le pas pour des raisons esthétiques et moins 
logiques qu’il n’y paraît.

C’est d’alleurs moi qui l’année dernière avait mis ces adresses et, finalement, 
je trouve cavalier qu’un point de vue fondé aussi légèrement aboutisse à une 
sorte de vandalisme.


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

Re: [OSM-talk-fr] Avis de thèse à l'IGN

[Frédéric Rodrigo]

Le 14/06/2016 à 15:24, Nicolas Moyroud a écrit :
Même réflexion en lisant le titre. Certians diront peut-être que j'ai 
l'esprit mal placé mais en lisant  le résumé voici ce que j'entend à 
demi-mot : comment nous le grand IGN pouvons-nous aider ces pauvres 
diables qui se démènent avec un système collaboratif (donc défectueux 
par nature) à faire des choses aussi bonnes que les notres ? Quand je 
vois certains des trucs qu'il propose dans le sujet, je ne sais pas si 
ils croient innover, mais moi la plupart du temps j'ai juste 
l'impression qu'ils parlent d'osmose... Fred devrait postuler il a 
déjà presque fait les 3 ans de travail ;-)


Ça a été posté aujourd'hui sur georezo avec une date limite de 
candidature au 12 juin... les candidats n'ont pas du se bousculer, j'ai 
encore toutes mes chances ;-), et puis ça fait 6 ans que je bosse sur 
Osmose !


Frédéric, Dr. ès QA.


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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

L'ennui c'est que les adresses ne se limitent pas seulemetn à un
housenumber (notion liée à la propriété cadastrale, formée sur une ou
plusieurs parcelles). Elle est même insuffisante puisqu'à cette notion de
propriété vient se greffer celle de résidents/locataires (qui ont aussi une
existence fiscale, mais non cadastrale) : ils ont aussi leurs adresses
toutes aussi importantes, et quand le housenumber ne suffit plus, on doit
rentrer dans plus de détails : numéo ou nom de bâtiment, étage, numéro de
porte... (des propriétés aussi importantes du schéma addr:*).

Je crois qu'ici on est trop obnubilé par vouloir une base BANO "propre" ne
tenant qu'à établir une liste des propriétés et ignorer totalement ceux qui
les occupent (résidents/locataires).

A vouloir utiliser contact:* pour lever les ambiguités, on a détourné la
finalité de contact:* et crée de nouvelles ambiguités (ou impossibilités de
codification).

Si vous voulez absolument un housenumber unique pour faire plaisir à BANO
(j'appelle ça taguer pour le rendu, ici les rendus et analyses BANO  !) je
ne vois pas comment procéder autrement que de créer des relations
associatedHousenumber pour pouvoir y rattacher les *différents* objets
distincts qui y sont rattachés (les résidents/locataires, et dans le cas
présent les commerces).

Faut de quoi (sans relation), renseigner addr:housenumber est parfairtement
propre (et tant pis si l'analyse BANO "gueule" sur de speudo-doublons:
c'est l'analyse BANO qu'il faudra corriger si elle ne sait pas tenir compte
de la réalité.

En attendant, un simple noeud pour BANO ne décrit pas correctement
l'adresse puisqu'il n'a aucune géométrie suffisante, il a une surface nulle
et le reste n'est qu'une approximation (il n'y a rien de solide pour
rattacher ce qui voisine ce noeud à la même adresse, et on le voit bien
ici: un numéro 40 sera en fait placé à mi-chemin entre le noeud 40 et le
noeud 44, et ce n'est pourtant pas le 42 !  On a le même problème aux
angles de rues. On a aussi le problème pour rattacher une même résidence à
plusieurs numéros d'adresse (parfois sur deux rues différentes).

Bref c'est bancale, et je suis contre le fait de surcharger contact:* pour
tenter maladroitement de contourner le problème des analyses BANO. Le but
n'est pas pour nous de dégommer systématiquement tous les signalements BANO
en faisant de façon aussi "dégueu" (et aussi insuffisante, peu précise et
toujours aussi ambiguë au final).




Le 14 juin 2016 à 16:52, Tony Emery  a écrit :

> Si on part du principe d'écarter la notion d'adresse postale (on laisse ça
> à
> La Poste), il faut définir les enjeux de l'adresse physique pour savoir
> comment on la décrit.
>
> On a dit que, pour les adresses des commerces, on utilise les tags
> contact:xxx. Quant à la description des plaques des noms des rues et des
> numéros d'adresse mais, en soit, cela n'a pas beaucoup d'utilité.
>
> Par contre, la notion d'adresse physique pour la navigation routière, le
> déplacement des services d'urgence, le dénombrement des logements,...
>
> De fait, si une adresse dessert plusieurs bâtiments physiquement séparés,
> cela ne me semble pas incohérent d'attribuer à chaque bâtiment  (Exemple)
>   .
>
>
>
> -
> 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/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875494.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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Tony Emery]

Si on part du principe d'écarter la notion d'adresse postale (on laisse ça à
La Poste), il faut définir les enjeux de l'adresse physique pour savoir
comment on la décrit.

On a dit que, pour les adresses des commerces, on utilise les tags
contact:xxx. Quant à la description des plaques des noms des rues et des
numéros d'adresse mais, en soit, cela n'a pas beaucoup d'utilité.

Par contre, la notion d'adresse physique pour la navigation routière, le
déplacement des services d'urgence, le dénombrement des logements,...

De fait, si une adresse dessert plusieurs bâtiments physiquement séparés,
cela ne me semble pas incohérent d'attribuer à chaque bâtiment  (Exemple)
  .



-
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/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875494.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] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

Tu peux encadrer. Trouve moi ce noeud sur le terrain et dis moi pourquoi
les noeuds voisins à la même adresse ne sont pas non plus cette adresse !
C'est un problème de représentation car le noeud ne désigne que lui-même et
le reste c'est de l'approximation.

Je maintiens qu'il n'y a strictement rien qui rattache ce noeud à ce qui
est autour et qui a besoin pourtant d'être distingué (deux commerces
différents).

Et si les adresses de contact de ces commerces sont totalement ailleurs
(pas à l'adresse du noeud d'adresse le plus proche), ta "pseudo-solution"
avec contact:* est totalement bancale et ne tient pas la route.

Je maintiens que cces commerces sont distincts, qu'ils ne sont représenyés
qu'une seule fois mais qu'ils ont chacun besoin d'être rattaché à une
adresse qui n'est pas positionné dessus: il n'y a aucune solution sans
relation ni sans attribut addr:* qui a été détourné dans votre vision
franco-française, de la vision initiale de ces attributs tels qu'ils ont
été définis.

Note: je n'ai jamais dit qu'il ne faillait pas fusionner les noeuds quand
c'est possible, mais là c'est impossible car les deux commerces sont
voisins et bien distincts.

Franchement je ne vois absolument pas le problème à mettre un attribut (pas
un nouvel objet) addr:housenumber sur chacun des deux commerces, **même**
si la valeur est identique. Il n'y a aucun doublon "d'objet" ce ne sont pas
les mêmes objets !

Le 14 juin 2016 à 16:28, Romain MEHUT  a écrit :

> On les encadre où celles-ci "*Une adresse cadastrale n'est même pas un
> objet en soit (le noeud anonyme qu'on met dans OSM est arbitraire et ne
> correspond pas à la réalité qui désigne une surface incluant plusieurs
> éléments.*" et "*Le noeud d'adresse n'est qu'une position approximative.
> Ce n'est pas un objet, il n'a aucune réalité en lui-même sur le terrain.*"
> ?
>
> Help...
>
> Romain
>
> Le 14 juin 2016 à 16:23, Philippe Verdy  a écrit :
>
>> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
>>
>>> Bonjour,
>>>
>>> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>>>
>>>
 Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
 des noeuds différents, proches mais taguant des objets différents ayant
 *certaines* propriétés communes (dont le numéro de rue associé).

>>>
>>> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de
>>> ne décrire un objet qu'une fois, et c'est une règle générale pas spécifique
>>> aux adresses.*"
>>>
>>
>> Une adresse cadastrale n'est même pas un objet en soit (le noeud anonyme
>> qu'on met dans OSM est arbitraire et ne correspond pas à la réalité qui
>> désigne une surface incluant plusieurs éléments. Et non il ne s'agit PAS
>> des mêmes objets puisqu'ils n'ont PAS les mêmes attributs. Et RIEN du tout
>> n'attanche réelelment les POIs (batiments entiers ou noeuds d'un commerce)
>> à son adresse réelle hormis une très relative proximité entre eux et un
>> point arbitraire d'adresse !
>>
>>
>>>
 Dans le cas présent, le doublon est en fait le noeud d'adresse "40"
 vide de tags et PAS les deux deux des POIs distincts des deux commerces qui
 sont au 40: en effet ce noeud vierge a toutes ses propriétés communes avec
 les deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus
 d'autorité que les deux autres, il n'ajoute rien de mieux.

>>>
>>> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
>>> justement l'adresse en question. Partant du constat qu'on ne décrit un
>>> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
>>> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
>>> sens.
>>>
>>
>> Le noeud d'adresse n'est qu'une position approximative. Ce n'est pas un
>> objet, il n'a aucune réalité en lui-même sur le terrain. Tu peux tourner la
>> question comme tu veux mais il ne décrit que lui-même et pas du tout ce qui
>> est autour !
>>
>>>
>>>
 En revanche le "contact:housenumber" n'est pas une indication
 géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
 pour en faire une adresse suffisante comme adresse de contact) il n'est
 même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
 aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
 avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
 objet).

>>>
>>> D'accord, qu'il manque un contact:street.
>>>
>>
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[Tony Emery]

Du coup, quand on créé une requête overpass pour récupérer les données dans
un fichier xml (par défaut), est-ce qu'on peut paramétrer la requête pour
qu'elle ne télécharge que la différence entre la base osm et ce qui est dans
le fichier xml ?



-
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/Import-de-donnees-OSM-dans-PostGIS-tp5875478p5875492.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] Bonnes et moins bonnes visibilités OSM

[Romain MEHUT]

On les encadre où celles-ci "*Une adresse cadastrale n'est même pas un
objet en soit (le noeud anonyme qu'on met dans OSM est arbitraire et ne
correspond pas à la réalité qui désigne une surface incluant plusieurs
éléments.*" et "*Le noeud d'adresse n'est qu'une position approximative. Ce
n'est pas un objet, il n'a aucune réalité en lui-même sur le terrain.*" ?

Help...

Romain

Le 14 juin 2016 à 16:23, Philippe Verdy  a écrit :

> Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :
>
>> Bonjour,
>>
>> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>>
>>
>>> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
>>> des noeuds différents, proches mais taguant des objets différents ayant
>>> *certaines* propriétés communes (dont le numéro de rue associé).
>>>
>>
>> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de
>> ne décrire un objet qu'une fois, et c'est une règle générale pas spécifique
>> aux adresses.*"
>>
>
> Une adresse cadastrale n'est même pas un objet en soit (le noeud anonyme
> qu'on met dans OSM est arbitraire et ne correspond pas à la réalité qui
> désigne une surface incluant plusieurs éléments. Et non il ne s'agit PAS
> des mêmes objets puisqu'ils n'ont PAS les mêmes attributs. Et RIEN du tout
> n'attanche réelelment les POIs (batiments entiers ou noeuds d'un commerce)
> à son adresse réelle hormis une très relative proximité entre eux et un
> point arbitraire d'adresse !
>
>
>>
>>> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
>>> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
>>> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
>>> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
>>> que les deux autres, il n'ajoute rien de mieux.
>>>
>>
>> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
>> justement l'adresse en question. Partant du constat qu'on ne décrit un
>> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
>> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
>> sens.
>>
>
> Le noeud d'adresse n'est qu'une position approximative. Ce n'est pas un
> objet, il n'a aucune réalité en lui-même sur le terrain. Tu peux tourner la
> question comme tu veux mais il ne décrit que lui-même et pas du tout ce qui
> est autour !
>
>>
>>
>>> En revanche le "contact:housenumber" n'est pas une indication
>>> géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
>>> pour en faire une adresse suffisante comme adresse de contact) il n'est
>>> même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
>>> aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
>>> avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
>>> objet).
>>>
>>
>> D'accord, qu'il manque un contact:street.
>>
>
>
> ___
> 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] Bonnes et moins bonnes visibilités OSM

[Philippe Verdy]

Le 14 juin 2016 à 16:15, Romain MEHUT  a écrit :

> Bonjour,
>
> Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :
>
>
>> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
>> des noeuds différents, proches mais taguant des objets différents ayant
>> *certaines* propriétés communes (dont le numéro de rue associé).
>>
>
> Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de ne
> décrire un objet qu'une fois, et c'est une règle générale pas spécifique
> aux adresses.*"
>

Une adresse cadastrale n'est même pas un objet en soit (le noeud anonyme
qu'on met dans OSM est arbitraire et ne correspond pas à la réalité qui
désigne une surface incluant plusieurs éléments. Et non il ne s'agit PAS
des mêmes objets puisqu'ils n'ont PAS les mêmes attributs. Et RIEN du tout
n'attanche réelelment les POIs (batiments entiers ou noeuds d'un commerce)
à son adresse réelle hormis une très relative proximité entre eux et un
point arbitraire d'adresse !


>
>> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
>> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
>> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
>> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
>> que les deux autres, il n'ajoute rien de mieux.
>>
>
> Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
> justement l'adresse en question. Partant du constat qu'on ne décrit un
> objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
> entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
> sens.
>

Le noeud d'adresse n'est qu'une position approximative. Ce n'est pas un
objet, il n'a aucune réalité en lui-même sur le terrain. Tu peux tourner la
question comme tu veux mais il ne décrit que lui-même et pas du tout ce qui
est autour !

>
>
>> En revanche le "contact:housenumber" n'est pas une indication
>> géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
>> pour en faire une adresse suffisante comme adresse de contact) il n'est
>> même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
>> aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
>> avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
>> objet).
>>
>
> D'accord, qu'il manque un contact:street.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT ALCA APPUI PERFORMANCE)]

Quelques liens : 
http://www.gaia-gis.it/gaia-sins/
https://www.gaia-gis.it/spatialite-2.3.0/install-windows.html
https://www.gaia-gis.it/spatialite-2.3.0/docs.html 
https://www.gaia-gis.it/gaia-sins/spatialite-cookbook/index.html#haute_cuisine 

je sais pas si c'est assez user-friendly pour toi.

-Message d'origine-
De : Tony Emery [mailto:tony.em...@yahoo.fr] 
Envoyé : mardi 14 juin 2016 15:59
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] Import de données OSM dans PostGIS

Tu as de la doc "user friendly" là-dessus ?



-
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/Import-de-donnees-OSM-dans-PostGIS-tp5875478p5875487.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
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Romain MEHUT]

Bonjour,

Le 13 juin 2016 à 20:19, Philippe Verdy  a écrit :


> Je suis aussi de cet avis. Le doublon n'en est pas vraiment un: ce sont
> des noeuds différents, proches mais taguant des objets différents ayant
> *certaines* propriétés communes (dont le numéro de rue associé).
>

Je suis de l'avis de l'autre Christian soit "*Le principe d'OSM est de ne
décrire un objet qu'une fois, et c'est une règle générale pas spécifique
aux adresses.*"


> Dans le cas présent, le doublon est en fait le noeud d'adresse "40" vide
> de tags et PAS les deux deux des POIs distincts des deux commerces qui sont
> au 40: en effet ce noeud vierge a toutes ses propriétés communes avec les
> deux autres noeuds. Il ne sert à rien d'autre et n'a pas plus d'autorité
> que les deux autres, il n'ajoute rien de mieux.
>

Vide de tag le nœud adresse ? C'est LE nœud de base pour spécifier
justement l'adresse en question. Partant du constat qu'on ne décrit un
objet qu'une seule fois, si tu supprimes ce nœud, il te faudrait choisir
entre les deux POI pour y associer l'adresse... or cela n'a pas plus de
sens.


> En revanche le "contact:housenumber" n'est pas une indication
> géographique. Employé seul (sans "contact:street" et tout ce qu'il faut
> pour en faire une adresse suffisante comme adresse de contact) il n'est
> même pas associable à une rue précise, il n'a AUCUN sens ! Le bon tag ici
> aurait du être "addr:housenumber", même s'il fait un **pseudo** doublon
> avec un autre noeud voisin (mais qui a d'autres tags et sert à un autre
> objet).
>

D'accord, qu'il manque un contact:street.

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

Re: [OSM-talk-fr] Import de données OSM dans PostGIS

[Tony Emery]

Tu as de la doc "user friendly" là-dessus ?



-
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/Import-de-donnees-OSM-dans-PostGIS-tp5875478p5875487.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

[OSM-talk-fr] Adresses, lotissements et résidences

[Tony Emery]

Bonjour à tous,

Bon, allez, comme je suis en forme aujourd'hui, je vous propose un autre
défi qui concerne les adresses.

*Le contexte :* 
- Création des adresses directement dans OpenStreetMap ;
- Utilisation de la relation associatedStreet pour lier les points d'adresse
et les tronçons de voies ;
- Utilisation de l'outil http://cadastre.openstreetmap.fr/ pour importer les
adresses ;
- Travail avec les communes pour récupérer les délibérations de création,
dénomination et numérotation des voies ;
- Travail avec les services urbanisme pour récupérer les permis de
construire et de lotir (= nouveaux logements et donc nouvelles adresses
potentielles) ;
- Travail de terrain pour consolider tout ça ;
- Travail avec l'INSEE pour mettre à jour et corriger le Répertoire des
Immeubles Localisés, qui sert de base pour les recensements annuels de la
population.

Tout ça fonctionne plutôt bien avec des adresses normées numéro, type voie,
libellé voie (ex : 3 Avenue de la République).

*La problématique voirie*
Par contre, dès que l'on entre dans une résidence ou un lotissement, c'est
le caca.
J'ai pris le parti de dessiner dans OSM les contours des lotissements et des
résidences (immeubles collectifs) avec les tags landuse=residential et
place=neighbourhood. C'est peut-être pas le bon tag, mais j'ai pas trouvé
mieux.
Du coup, j'ai un problème pour gérer dans un système unique les voies qui
sont à l'intérieur d'un lotissement ou d'une résidence et qui, soit:
- contienne un nom officiel (délibération de la commune) ;
- contienne un nom non-officiel (donné par les riverains) ;
- sont officiellement ou non dénommées comme le lotissement ;
- n'ont pas de nom ;

*La problématique adresses*
Et à tout cela, y ajouter :
- les adresses avec un numéro qui peut être le même dans 2 lotissement
différents et desservis pas la même voie ;
- les anciennes numérotations classiques qui côtoient les nouvelles
numérotations métriques ;
- la notion de bâtiment ou de porte dans les résidences (et qu'ils
apparaissent dans osm.org) ;
- les voies qui n'ont jamais été numérotées mais pour lesquelles on a
recensé des logements ;

Voilà, si c'est trop compliqué à traiter ici, on peut, peut-être, ouvrir une
page spéciale dans le wiki.



-
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/Adresses-lotissements-et-residences-tp5875483.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] Import de données OSM dans PostGIS

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT ALCA APPUI PERFORMANCE)]

Tu as pensé à une solution spatialite ?
Avantages :
- installation enfantine
- multi-plateforme
- s'intègre directement dans ArcGIS (v 10.3 minimum) selon la doc (mais pas 
encore testé)
- base mono-utilisateur
- très paramétrable (et automatisable, y compris avec du python)
- fonctionne très bien aussi avec QGis (testé du coup ;-)
- export possible en shapefile
-  compatbible OGC

Inconvénients
- je ne sais pas comment ça tient la charge si volume très important de données.

Pour ma part c'est les choix sur lesquels je m'oriente pour un projet similaire 
que je vais démarrer très prochainement.
Pourquoi une geodatabase ?

Denis


-Message d'origine-
De : Tony Emery [mailto:tony.em...@yahoo.fr] 
Envoyé : mardi 14 juin 2016 15:18
À : talk-fr@openstreetmap.org
Objet : [OSM-talk-fr] Import de données OSM dans PostGIS

Bonjour à tous,

Suite aux différentes présentations du dernier SOTM-FR et en lien avec une 
réflexion que je mène déjà depuis quelques temps, je me lance (enfin) dans le 
grand bain de l'import quasi-big data.

En fait, je souhaite aller plus loin dans la démarche d'import des données OSM 
en local que celle que j'ai présenté à Clermont-Ferrand.

Jusqu'à présent, j'utilise un script python pour automatiser l'import de 
certaines données OSM dans des fichiers planet en local, puis, avec la 
bibliothèque arcpy d'ESRI, qui renvoi tout ça dans une géodatabase ESRI (je 
vous entends siffler dans le fond).

J'ai bien écouté les présentations qui expliquaient comment utiliser osm2pgsql, 
switch2osm et autre imposm3. Mais il y a 2 contraintes que je n'arrive pas à 
lever :
- comment ça s'installe, ça se paramètre et ça fonctionne ?
- Est-ce qu'il existe la même chose pour un environnement Windows, car nos 
serveurs sont ainsi ?

Du coup, je recherche un tutoriel à jour (donc récent) et qui explique
(très) simplement comment mettre en place une solution automatisée permettant :
- de télécharger les données d'une emprise géographique tous les soirs (ou, à 
défaut, le différentiel)
- que ces données soient versées plus ou moins directement dans une Base 
PostGIS.
Pour le coup, je suis aussi éventuellement preneur d'une solution full open 
source Ubuntu que je testerai chez moi.

Merci d'avance pour vos idées.

Tony



-
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/Import-de-donnees-OSM-dans-PostGIS-tp5875478.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
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Avis de thèse à l'IGN

[Nicolas Moyroud]

Même réflexion en lisant le titre. Certians diront peut-être que j'ai 
l'esprit mal placé mais en lisant  le résumé voici ce que j'entend à 
demi-mot : comment nous le grand IGN pouvons-nous aider ces pauvres 
diables qui se démènent avec un système collaboratif (donc défectueux 
par nature) à faire des choses aussi bonnes que les notres ? Quand je 
vois certains des trucs qu'il propose dans le sujet, je ne sais pas si 
ils croient innover, mais moi la plupart du temps j'ai juste 
l'impression qu'ils parlent d'osmose... Fred devrait postuler il a déjà 
presque fait les 3 ans de travail ;-)


Nicolas

Le 14/06/2016 14:53, Tony Emery a écrit :

La problématique est peine orientée : "fraude, confiance et crédibilité".
Ils auraient pu écrire "Dites-nous pourquoi OSM est pourri ?"





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

[OSM-talk-fr] Import de données OSM dans PostGIS

[Tony Emery]

Bonjour à tous,

Suite aux différentes présentations du dernier SOTM-FR et en lien avec une
réflexion que je mène déjà depuis quelques temps, je me lance (enfin) dans
le grand bain de l'import quasi-big data.

En fait, je souhaite aller plus loin dans la démarche d'import des données
OSM en local que celle que j'ai présenté à Clermont-Ferrand.

Jusqu'à présent, j'utilise un script python pour automatiser l'import de
certaines données OSM dans des fichiers planet en local, puis, avec la
bibliothèque arcpy d'ESRI, qui renvoi tout ça dans une géodatabase ESRI (je
vous entends siffler dans le fond).

J'ai bien écouté les présentations qui expliquaient comment utiliser
osm2pgsql, switch2osm et autre imposm3. Mais il y a 2 contraintes que je
n'arrive pas à lever :
- comment ça s'installe, ça se paramètre et ça fonctionne ?
- Est-ce qu'il existe la même chose pour un environnement Windows, car nos
serveurs sont ainsi ?

Du coup, je recherche un tutoriel à jour (donc récent) et qui explique
(très) simplement comment mettre en place une solution automatisée
permettant :
- de télécharger les données d'une emprise géographique tous les soirs (ou,
à défaut, le différentiel)
- que ces données soient versées plus ou moins directement dans une Base
PostGIS.
Pour le coup, je suis aussi éventuellement preneur d'une solution full open
source Ubuntu que je testerai chez moi.

Merci d'avance pour vos idées.

Tony



-
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/Import-de-donnees-OSM-dans-PostGIS-tp5875478.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] Avis de thèse à l'IGN

[Tony Emery]

La problématique est peine orientée : "fraude, confiance et crédibilité".
Ils auraient pu écrire "Dites-nous pourquoi OSM est pourri ?"



-
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/Avis-de-these-a-l-IGN-tp5875464p5875473.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

[OSM-talk-fr] Avis de thèse à l'IGN

[Vincent de Château-Thierry]

Bonjour,
vu passer à l'instant : 
http://georezo.net/forum/viewtopic.php?pid=283341#p283341

Sujet :
"Qualification des contributions dans un système de saisie cartographique 
collaborative : fraude, confiance et crédibilité"

Le PDF avec les détails : 
http://recherche.ign.fr/labos/cogit/pdf/PROPOSITIONS/2016/sujet-these-2016_touya.pdf

vincent

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

Re: [OSM-talk-fr] Nouvelle affiche disponible : on s'amuse avec les cathédrales !

[Nicolas Moyroud]

Salut JB,

Génial le résultat ! Merci pour l'explication détaillée de la procédure.
Si je peux me permettre une remarque je trouve que dans le résultat 
final c'est dommage de mettre un carré rouge et aussi de faire 
apparaître le label sur la cathédrale. Dans la feuille de style utilisée 
avec Maperitive il me semble qu'il serait relativement facile de faire 
disparaître le carré et de positionner le label en dessous de chaque 
objet. Peut-être même qu'avec un autre couleur mieux choisie que ce 
rouge un peu pétard ce serait encore mieux.
Dans l'idée d'automatiser quasi intégralement le processus peux tu me 
dire quelles sont les manips finales que tu réalises avec Gimp ? Je 
pense notamment à l'utilisation d'magemagick qui permet également de 
faire des retouches d'images mais en ligne de commande.


Nicolas

Le 13/06/2016 19:33, JB a écrit :

Bonjour,

Après l'essai de faisabilité vite fait avec les églises d'Auvergne 
pour le SotM-FR pour ceux qui y étaient, j'ai essayé de faire quelque 
chose de plus complet : l'affiche des cathédrales de France. Le final 
ici : http://jb.isonoe.net/demo/Cathedrales_A1_400dpi_v0.png, fait 
pour être imprimé en A1 à 400dpi.


La démarche :

 - trouver une source de données qui liste les cathédrales. J'ai 
utilisé wikipédia, qui n'est peut-être pas forcément parfait (voir 
plus loin) :

https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_de_France
https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_catholiques_de_France 

https://upload.wikimedia.org/wikipedia/commons/b/b7/Cath%C3%A9drales_catholiques_romaines_de_France.png 



 - vérifier les données dans OSM :

- première extraction des building=cathedral. Quelques petits 
villages se sont attribués des cathédrales, je les repasse en 
building=church


- plus embêtant, trouver les batiments non indiqués en cathédrales 
: il faut se payer la comparaison entre la liste des existants dans 
OSM et la liste globale. Dans la plupart des cas, ça se fait 
relativement bien. Parfois c'est un peu plus tordu, rarement, aucune 
information ne recoupe les indications de wikipédia. Dans ces quelques 
cas, je n'ai touché à rien. La liste des éléments : 
http://jb.isonoe.net/cath/cath.csv (parmi les plus litigieux : Mâcon 
et celles marquées comme telles dans la dernière colonne). Je 
n'affirme pas avoir été parfait ni que ma source de données l'était : 
je pense avoir amélioré la qualité globale de la base de données mais 
si vous n'êtes pas d'accord avec le résultat, n'hésitez pas à modifier.


 - ré-extraire les données : Geofabrik est là pour la France d'ici 
avec un coup d'Osmosis derrière, Overpass pour les dom-tom. On 
rassemble les deux, on élimine la cathédrale de Monaco (et on gère 
l’éphémère doublon de Rodez).


La suite se fait par un petit script python/Maperipy exécuté sous 
Maperitive.


 - géocoder : l'api d'adresse.data.gouv.fr fait le gros du travail. 
Dans quelques territoires éloignés où la ban avoue son échec, le 
géocodage est fait à la main.


 - déplacer les éléments et les placer « au carré » : toujours 
python/Maperipy. Une première version assez crado ne reprojetait pas 
les objets, d'où des déformations assez importantes, surtout pour les 
éléments des dom-tom mais aussi certains en métropole : 
http://jb.isonoe.net/cath/Reproj.png. Le script est modifié pour 
respecter distances/formes (si je m'y suis bien pris).


 - exporter l'image, mettre en forme sous Gimp.

Le code, pas fait pour être partagé et qui ne fonctionnera 
probablement pas (très moche, non retravaillé, à peine commenté), est 
visible ici : http://jb.isonoe.net/cath/Eglises_rel1.py


Quelques autres documents intermédiaires :

 - Cathédrales utilisées, avec géocodage : 
http://jb.isonoe.net/cath/cath_brut_geocode_manuel.osm


 - Cathédrales au carré :
- non reprojetées : 
http://jb.isonoe.net/cath/Egl_offset_direct_ok.osm

- reprojetées : http://jb.isonoe.net/cath/Egl_offset_reproj_ok.osm

Ma version personnelle : http://jb.isonoe.net/cath/Photo_affiche.jpg

JB.


PS : pour le teasing, j'ai une autre idée plus matérielle… ça arrive 
dans quelques semaines !



___
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