Re: [OSM-talk-fr] Lieux-dits Fantoir surfaciques

2019-10-03 Par sujet Vincent de Château-Thierry 

Bonsoir,

Le 03/10/2019 à 22:42, osm.sanspourr...@spamgourmet.com a écrit :


Du coup avec l'interface JOSM j'ai vu qu'un lieu-dit c'était plus qu'un 
place=unknown.


C'est aussi dans certains cas un périmètre.

Est-ce que ça ne vaut pas le coup de tenter de faciliter leur intégration ?


Tout ton propos est centré sur la technique, le "comment faire" : le 
greffon, la topologie, faire des relations pour ne pas dupliquer, etc.
Il faudrait peut-être avant tout ça se poser la question du sens ? La 
technique suivra, le souci n'est pas là.


Ce que j'appele "lieux-dits" dans le contexte de BANO ce sont les nodes 
place=*, essentiellement place=hamlet, place=isolated_dwelling et 
place=locality. Ce sont des points la majeure partie du temps car on est 
bien en peine de définir leurs contours aussi précisément que pour une 
commune. Côté Cadastre on a parfois (mais pas toujours) des parcelles 
nommées et c'est à première vue une manière de définir l'emprise d'un 
lieu-dit. Sauf qu'il n'est pas rare que la partie habitée, celle le long 
de la route, avec de petits panneaux en noir et blanc porteurs du nom du 
lieu-dit, ne soit pas incluse dans les parcelles nommées.


Je n'ai pas l'impression qu'on gagnera en pertinence en important des 
agrégats de parcelles nommées issues du cadastre (notre seule source 
surfacique) tant c'est un contenu partiel (on a bien plus de lieux-dits 
sur le terrain que de parcelles nommées côté Cadastre) et arbitraire, 
voire divergent par rapport au terrain.


vincent


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

[OSM-talk-fr] Lieux-dits Fantoir surfaciques

2019-10-03 Par sujet osm . sanspourriel 

Le 03/10/2019 à 14:24, Brice MALLET - brice...@free.fr a écrit :


Merci pour le travail réalisé / encore à réaliser.

+1

> Il reste à y (re)brancher les lieux-dits

Du coup avec l'interface JOSM j'ai vu qu'un lieu-dit c'était plus qu'un
place=unknown.

C'est aussi dans certains cas un périmètre.

Est-ce que ça ne vaut pas le coup de tenter de faciliter leur intégration ?

Une intégration "brute" avec le greffon JOSM pose problème car les
polygones sont jointifs et on abouti naturellement à des chemins dupliqués.

Il faut donc comme pour les communes découper en segments et créer une
relation type=boundary, boundary=place, place=, name= avec

 * en membres outer le contour découpé en segments

Contours éventuellement sans attributs ?
Avec name:left et name:right? Ce serait incompatible avec des rues
jouant le rôle de limite (qui ont souvent le même nom des deux côtés).
Avec le niveau le plus haut de place des deux place ? et boundary=place
? Ce serait homogène avec les boundary=administrative. Mais comme le nom
peut être celui d'une rue et non d'un boundary=place, ce serait
peut-être déroutant.

 * en membre label le "centre" avec lui aussi les attributs name= et
   place=. C'est homogène avec les boundary=administrative. Note : il y
   a des propositions de changer label en waypoint ou reference_point
   car c'est endroit où l'on va par défaut quand on nous dit d'aller
   dans ce lieu sans plus de précision.

Christian va me dire que name= et place= ne sont pas nécessaires sur le
nœud.
D'un point de vue théorique je suis d'accord.
D'un point de vue pratique sans cela, le style par défaut de la
fondation n'affiche rien et il est classique que les utilisateurs de
données s'attendent à n'avoir qu'un point prêt à l'emploi. Sur les
admin_centre des boundary=administrative il y a aussi duplication des
infos de la relation.

Exemples contigus :
https://www.openstreetmap.org/relation/10060749#map=19/47.78701/-3.48695
https://www.openstreetmap.org/relation/10110420#map=19/47.78696/-3.48731

A priori en créant des points et en créant des segments on peut faire un
CSV  à transformer en pilote
virtuel vrt que l'on peut exporter à son tour en GeoJSON.

https://github.com/topojson/topojson permet de transformer du GeoJSON en
TopoJSON.

Dit comme ça, ça semble simple, il y a quand même un peu de topologie à
faire, peut-être qu'une bibliothèque QGIS, python ou une requête PostGIS
permet de partir des données récupérées par le greffon cadastre (les
fichiers edigeo-.tar.bz2), je suppose que
Vincent et/ou Christian sauront éclairer notre lanterne.

En extrayant en même temps routes et lieux-dits on doit arriver à éviter
les doublons et à créer des segments (dans mon exemple j'ai dû
saucissonner la rue Général De Gaulle, ça aurait pu être fait
automatiquement par topologie.

Pour la petite histoire

cette modélisation résout le problème d'affichage des places en
surfacique signalé sur le style principal.

Jean-Yvon

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

Re: [OSM-talk-fr] Nouvelle API du géocodeur et communes nouvelles (code postal)

2019-10-03 Par sujet deuzeffe 

On 02/10/2019 19:50, Rpnpif wrote:

Le  2 octobre 2019, osm.sanspourr...@spamgourmet.com a écrit :


Le 02/10/2019 à 12:10, Rpnpif - rpn...@trob.eu a écrit :

Bonjour,

Merci à Christian pour la nouvelle API de consultation du géocodeur de
http://demo.addok.xyhz/.


Il n'y pas un h en trop que tu as oublié de fumer ? ;-)


Oups oui, d'où vient ce h parasite ?
http://demo.addok.xyz/ c'est mieux.


Mon FF 60.9.0esr refuse de l'afficher, snif
(oui, j'ai désactivé tous les bloqueurs d'intrus que j'ai pu et non, le 
code de la page n'est pas vide) re-snif


--
deuzeffe, frustrée

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

Re: [OSM-talk-fr] Amenity=telephone

2019-10-03 Par sujet deuzeffe 

On 02/10/2019 17:07, Laurent Magréault wrote:

Bonjour,


Bonsoir,


A titre de retour d'expérience, je viens d'en dégommer 12 sur 39 dans le
Jura en utilisant comme source Mapillary et les compte-rendus de conseils
municipaux qui se font souvent l'écho de la disparition des cabines.
On a une cabine qui est bien devenue une boîte à livres à Conliège. J'ai
préféré mettre was:amenity=telephone que historic=telephone 


Et ajouter amenity=public_bookcase je présume ?

--
deuzeffe

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

Re: [OSM-talk-fr] Moulinette pour convertir codes Insee en GPS > GPX ?

2019-10-03 Par sujet Shohreh 
cquest wrote
> De plus, pour moi, utiliser une API* pour résoudre ce type de problème est
> quand même une aberration... il s'agit de faire un simple JOIN entre 2
> fichiers, trucs que je ferai localement en ligne de commande avec csvjoin
> de csvkit.

Merci pour le CSV avec les coordonnées des villes.

Le "3190Moulins", c'est parce que je n'avais pas modifié la colonne dans
LibreOffice pour qu'elle prenne du texte et non du numérique, et le 0 a
giclé :-)

All is well.



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Rapprochement OSM/Fantoir : données cadastre obsolètes ?

2019-10-03 Par sujet Brice MALLET 

Le 30/09/2019 à 22:40, Vincent de Château-Thierry a écrit :

Merci pour votre patience


Merci pour le travail réalisé / encore à réaliser.

--
Britzz

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

Re: [OSM-talk-fr] effet SNT / quelle contribution ?

2019-10-03 Par sujet Brice MALLET 

Le 30/09/2019 à 17:58, Cédric Frayssinet a écrit :
> prévu de faire contribuer les élèves mais selon les classes, ce sera 
peut-être différent :

  * carto-partie ciblée autour du lycée,
  * repérer des contributions dans les quartiers des élèves et les faire
avec moi lors des séances en classe,
  * autre ?


Et une sorte de jeu de piste en identifiant les "Notes de carte" ou les 
fixme qui demandent vérification sur le terrain ?



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

Re: [OSM-talk-fr] Nouvelle API du géocodeur et communes nouvelles

2019-10-03 Par sujet Rpnpif 
Le  2 octobre 2019, Christian Quest a écrit :

> Le but de cette demo est surtout de trouver un lieu et de le montrer
> ensuite sur la carte, la présentation de ce qui ressemble à une adresse est
> très accessoire ;)
> C'est le mix adresses + POI qui n'est pas évident, ainsi que la volumétrie
> globale:
> - 16.4 millions d'adresses BANO
> - 4 millions de lieux-dits BANO
> - 2.8 millions de POI OSM
> - 68000 geonames
> 
> BANO n'est pas totalement à jour sur les fusions de communes, c'est pour
> cela que ce n'est pas forcément bien raccord.
> 
> Pour les codes postaux infra-communaux, on peut les cartographier dans OSM
> (boundary=postal_code si ma mémoire est bonne), les scripts de BANO en
> tiennent compte. C'est utilisé par exemple sur 75016/75116 ou 94100/94210.
> 
> Pour les communes nouvelles, il faut peut être revoir quelques trucs...
> 
> Et puis... La Poste ? Elle nous casse les pieds, qu'elle continue comme ça
> et le courrier se réduira encore plus vite vers le zéro.
> Ses bases contiennent les anciens noms de commune et peuvent très bien y
> distribuer le courrier si elle en a envie (ce qui est à se demander).

Merci pour ces explications.

Donc à réfléchir dans OSM sur les communes nouvelles.

Et on va tenter quand j'aurai un moment de bien faire le zonage du code
postal pour Angers par exemple.

HS : mais pourquoi le gouvernement complique encore en ajoutant des
règles électorales spécifiques aux communes nouvelles. Les fusions qui
devait simplifier, compliquent plus en créant une institution à part,
donc pas seulement dans OSM.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] adresses sur tronc d'arbres

2019-10-03 Par sujet Francois Gouget 
On Wed, 2 Oct 2019, Baptiste Lemoine - Cipher Bliss via Talk-fr wrote:
[...]
> https://www.mapillary.com/map/im/YC4fb2LeIVSO5ufjuw66bA (désolé pour 
> la qualité, y'a des affichages agraphés sur le plan, c'est malin) et 
> voici a quoi ressemblent les marquages sur les arbres. on dirait 
> clairement des adresses, sauf qu'il n'y a aucune maison dans cette 
> foret, pas de boite postale non plus. donc pour le moment j'ai mis des 
> POI marquant une adresse avec juste un numéro, mais pas de nom de rue.

C'est juste le numéro des stations du parcours sportif pour le faire 
dans l'ordre (on voit que le parcours fait un huit).

Donc mettre un point fitness_station=xxx pour chaque station, et les 
joindre dans une relation type=route + route=fitness_trail.

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dfitness_station
https://wiki.openstreetmap.org/wiki/FR:Tag:route%3Dfitness_trail

Les numéros iraient sur les points fitness_station. Le Wiki dit :

name=* a name for the fitness station
ref=* a reference number of the fitness station

Donc peut-être name="Station N" ou alors simplement ref=N.

-- 
Francois Gouget   http://fgouget.free.fr/
  Sufficently advanced incompetence is indistinguishable from malice.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adresses sur tronc d'arbres

2019-10-03 Par sujet Cyrille37 OSM 

Le 02/10/2019 à 17:30, osm.sanspourr...@spamgourmet.com a écrit :

Mais plutôt des repères propres au parcours.

ref= me semble correct, après il te reste à relier ces points 
dans un route=fitness_trail 
.



Super, ça semble bien ça.

Cyrille37.


Jean-Yvon

Le 02/10/2019 à 15:44, David Crochet - david.croc...@free.fr a écrit :

Bonjour

Ce sont soit des numéros de parcelles dont les arbres des coins 
desdites parcelles comportent ledit numéros, ou alors si cela se 
trouvent sur un prarcours, des points décamétrique comme ici : 
https://www.openstreetmap.org/node/2415885432


Cordialement



___
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] Moulinette pour convertir codes Insee en GPS > GPX ?

2019-10-03 Par sujet Christian Quest 
On peut déjà, mais l'API est conçue pour une recherche full-text et là on a
un code INSEE de départ (qui n'est pas indexé), c'est donc le libellé
(approximatif car pas unique et inutile vu qu'on a le code INSEE non
équivoque) qui est utilisé pour la recherche.

De plus, pour moi, utiliser une API* pour résoudre ce type de problème est
quand même une aberration... il s'agit de faire un simple JOIN entre 2
fichiers, trucs que je ferai localement en ligne de commande avec csvjoin
de csvkit.

Il faut juste trouver le CSV qui contient la liste des communes avec leur
lat/lon (voire l'extraire éventuellement d'OSM**).

* Les API c'est bien, en abuser ça craint:
https://medium.com/@cq94/les-api-cest-bien-en-abuser-ca-craint-b5d1c92b32f2
** exemple: https://gist.github.com/cquest/476c7b1a3a88c0e3592690257f7e8647
via https://overpass-turbo.eu/s/MOT

Le jeu. 3 oct. 2019 à 06:46, Jérôme Seigneuret 
a écrit :

> Bonjour,
>
> @christian sur l'api adresse on peut aussi imaginer de définir le niveau
> exact où une limite à prévoir dans les types d'objets recherchés,
> output=voie, lieudit,ville,commune
>
> Jérôme
>
>
>
>
>
>
> Le mer. 2 oct. 2019 à 22:56, Christian Quest  a
> écrit :
>
>> api-adresse.data.gouv.fr est fait pour géocoder des adresses, pas des
>> noms de ville avec leur code INSEE, ça c'est le boulot de geo.api.gouv.fr
>>
>> Du coup, oui, 3190 moulins, ça peut être plein de choses...
>>
>>
>> Le mer. 2 oct. 2019 à 19:17, Shohreh  a écrit :
>>
>>> Samy Mezani wrote
>>> > L'API est faite pour automatiser tout ça :
>>> >
>>> > https://geo.api.gouv.fr/adresse (descendre à /search/csv/)
>>>
>>> Merci beaucoup.
>>>
>>> Si d'autres cherchent à faire la même chose :
>>> 1. (nécessaire?) Convertir les données entrée en UTF8
>>> 2. Downloader curl.exe dans le même répertoire
>>> 3. curl --insecure -o output.csv -X POST -F data=@input.csv -F
>>> citycode=NOMCOLONNECODEINSEE
>>> https://api-adresse.data.gouv.fr/search/csv/
>>>
>>> Bizarrement, il y a des villes que le serveur n'a pas réussi à géocoder
>>> (lat,lon vides):
>>>
>>> 3190Moulins
>>> 44090   La Marne
>>> 77083   Champs-sur-Marne
>>> 88212   Grand
>>> 92072   Sèvres
>>> 93039   L'Île-Saint-Denis
>>> 93066   Saint-Denis
>>>
>>>
>>>
>>> --
>>> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>>>
>>> ___
>>> 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
>>
> ___
> 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