Re: [OSM-talk-fr] Projet du mois de Juillet : analyse Osmose des postes électriques

2018-09-28 Par sujet Philippe Verdy
les postes électriques sont intéressants car il permettent de repérer les
lignes moyennes tension pas toujorus facile à voir et manquantes, et de
trouver notamment les points d'entrée du réseau de distribution (souvent
des transfos 20 000 volts - 400 volts, reliés à des lignes 20 000 volts le
plus souvent, parfois 25000 ou plus pour les plus longues), et voir ce qui
manque pour former le maillage depuis les gros postes de transformation
(qui en général sont cartographiés et ont leurs lignes haute tension la
plupart du temps).

Les lignes moyennes tension (je ne parle pas des poteaux basse tension en
380/400 volts qui sont souvent aussi enterrés ou le long des façades en
ville) sont des éléments de repérage importants et on les voit de loin et
donnent de bons repères de localisation précise des lieux et de recadrage
des orthophotos (à condition de bien positionner les pieds au sol et non le
sommet). Et on voit souvent ces pieds précisément mais pas toujours les
autres tours construites entourées de végétation ou gênées par d'autres
constructions, ces lignes étant assez bien dégagées autour au moins de
pylones ou posés en plein milieu des champs. De plus les poteaux suivent
des lignes relativement régulières et on peut aussi repérer les pylones
manquants rien que par les grosses différences de longueurs de lignes
(hormis les poteaux rapprochés avant un angle important ou une portée
importante au dessus d'une vallée où la ligne suit un grand arc rarement
droit sur les clichés aériens). Elles forment un maillage assez fin du
territoire pour recadrer précisément plein de choses autour.


Le sam. 29 sept. 2018 à 00:22, deuzeffe  a écrit :

> On 9/28/18 11:37 PM, SALLES Quentin wrote:
> > Bonsoir,
>
> Bonjour,
>
> > Je suis à la recherche de l'analyse Osmose des postes électriques
> > (Projet du mois de juillet) qui n'ont toujours pas été référencés.
> > Est-ce que quelqu'un pourrait me fournir le lien ?
>
> Ça https://osmose.openstreetmap.fr/fr/errors?item=8280 ou ça
> https://osmose.openstreetmap.fr/fr/errors?item=8281 par exemple ?
>
> > Et je voulais savoir également pour cette analyse, si les données de
> > l'analyse Osmose se mettent à jour en temps réel ?
>
> Je ne comprends pas bien la question, mais je réponds quand même
> qu'osmose intègre immédiatement les éditions correctrices. Quant à
> restituer les erreurs, compter 2-3 jours (le temps que l'analyse
> parcourt le monde entier...)
>
> --
> deuzeffe - étonnée.
>
> ___
> 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] Projet du mois de Juillet : analyse Osmose des postes électriques

2018-09-28 Par sujet deuzeffe

On 9/28/18 11:37 PM, SALLES Quentin wrote:

Bonsoir,


Bonjour,

Je suis à la recherche de l'analyse Osmose des postes électriques 
(Projet du mois de juillet) qui n'ont toujours pas été référencés. 
Est-ce que quelqu'un pourrait me fournir le lien ?


Ça https://osmose.openstreetmap.fr/fr/errors?item=8280 ou ça 
https://osmose.openstreetmap.fr/fr/errors?item=8281 par exemple ?


Et je voulais savoir également pour cette analyse, si les données de 
l'analyse Osmose se mettent à jour en temps réel ?


Je ne comprends pas bien la question, mais je réponds quand même 
qu'osmose intègre immédiatement les éditions correctrices. Quant à 
restituer les erreurs, compter 2-3 jours (le temps que l'analyse 
parcourt le monde entier...)


--
deuzeffe - étonnée.

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


[OSM-talk-fr] Projet du mois de Juillet : analyse Osmose des postes électriques

2018-09-28 Par sujet SALLES Quentin
Bonsoir,

Je suis à la recherche de l'analyse Osmose des postes électriques (Projet
du mois de juillet) qui n'ont toujours pas été référencés. Est-ce que
quelqu'un pourrait me fournir le lien ?
Et je voulais savoir également pour cette analyse, si les données de
l'analyse Osmose se mettent à jour en temps réel ?

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


Re: [OSM-talk-fr] Vincennes et segment entre voies séparées par un terre-plein

2018-09-28 Par sujet nicolas parizet
Le 28/09/2018 à 12:34, Christian Quest a écrit :
> Je connais bien le coin, vu le bâtiment qu'on trouve juste au sud-est
> du carrefour ;)
>
> Sur ce genre de carrefour, on pourrait refusionner les voies séparées
> en une seule car il n'y a effectivement pas à cet endroit de
> séparation physique, mais ce type de cas est quand même souvent mappé
> de cette façon pour plus de clareté.

Il n'y a donc pas de règle précise dans ce cas ? C'est l'usage qui prime
? (Heureusement que je ne suis pas de ce coin car moi, ça ne m'a pas
paru clair du tout ce mappage).

Reste à savoir comment doit se nommer ce segment. Je dirai Avenue de
Paris. J'ai bon ? :-)


Bon, je laisse les connaisseurs du coin en débattre.

Nicolas



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


[OSM-talk-fr] Données des mobilités : bientôt une carte nationale des aires de covoiturage

2018-09-28 Par sujet thevenon . julien
Ca parle entre autre d OSM
https://www.caissedesdepotsdesterritoires.fr/cs/ContentServer?pagename=Territoires/Articles/Articles=1250281680014

Julien

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


Re: [OSM-talk-fr] Vincennes et segment entre voies séparées par un terre-plein

2018-09-28 Par sujet Christian Quest
Je connais bien le coin, vu le bâtiment qu'on trouve juste au sud-est du
carrefour ;)

Sur ce genre de carrefour, on pourrait refusionner les voies séparées en
une seule car il n'y a effectivement pas à cet endroit de séparation
physique, mais ce type de cas est quand même souvent mappé de cette façon
pour plus de clareté.

Pour moi rien de choquant, il n'y a que la voie pour tourner Avenue
Gambetta que je n'aime pas trop. Je ne mettrais pas de name=Avenue Gambetta
dessus et j'aurais utilisé lanes + turn:lanes plutôt que ce tracé.



Le ven. 28 sept. 2018 à 07:47, nicolas parizet 
a écrit :

> Le 27/09/2018 à 22:15, Philippe Verdy a écrit :
> > L'autre solution aurait été de joindre les deux extrémités de se
> > segment en un même nœud central pour former un unique carrefour, même
> > si les voies de l'Avenue de Paris sont séparées (sauf justement là!)
>
> Bonjour,
>
> je suis entièrement d'accord avec cette solution. Perso, c'est ce que
> j'aurai fait, en supposant que la situation sur le terrain corresponde à
> ce que je suppose.
>
> Pour moi, «ma» logique personnelle à moi :-) indique que l'on sépare une
> voie s'il y a un terre-plein et qu'elle ne soit plus séparée s'il n'y a
> pas de terre-plein.
>
> Mais je me serai sûrement trompé car j'ai vu ce genre de segment sur
> d'autres avenues de Paris dans des situations identiques.
>
> Bonne journée et merci pour les réponses et pistes apportées,
>
> Nicolas
>
>
>
>
>
> ___
> 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] [OSM-Talk-fr] Import arbres Hauts-de-Seine

2018-09-28 Par sujet Florian LAINEZ
Bonjour à tous,
Pour info j'ai renoncé à mon projet d'intégration des arbres sur tout le
département : beaucoup trop compliqué.
Je vais déjà essayer de bien gérer cela au niveau de ma commune, et ce
n'est pas gagné d'avance ! J'explique ma démarche ici :
https://wiki.openstreetmap.org/wiki/Montrouge#Arbres
Feedbacks bienvenus

Le mer. 26 sept. 2018 à 18:29, Florian LAINEZ  a écrit :

> Dans le 92 (prononcer neuf-deux) on a aujourd'hui référencé 12 083 arbres
> cf. https://overpass-turbo.eu/s/ChP
> On a pas mal de données d'arbres en Open Data sous-exploitées
> https://opendata.hauts-de-seine.fr/explore/dataset/cadastre-vert-les-arbres
>
> J'envisage d'en importer une partie dans OSM, fort de l'expérience de
> Grenoble (cf. discussions précédentes) et évidemment mû par un sentiment de
> jalousie vis-à-vis de Paris ^^
> J'ai documenté ma démarche ici
> https://wiki.openstreetmap.org/wiki/Hauts-de-Seine#Arbres
>
> J'envisageais un import manuel des données mais je me rend compte qu'il y
> a des serveurs pour le cadastre des arbres :
> -Service WMS
>
> https://geoserviceweb.hauts-de-seine.fr/agspublic/services/Public/CadastreVert/MapServer/WMSServer
> ?
> -Service WFS
>
> https://geoserviceweb.hauts-de-seine.fr/agspublic/services/Public/CadastreVert/MapServer/WFSServer
> ?
>
> Peut-être est-il plus à jour ? J'ai essayé sans succès d'utiliser ces
> serveurs dans JOSM, votre aide est donc la bienvenue.
> Merci
>
> --
>
> *Florian Lainez*
> @overflorian 
>


-- 

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


Re: [OSM-talk-fr] [Hot-francophone] Règles de l'édition dirigée, nouvelle version de travail

2018-09-28 Par sujet Jo
Je ne vois rien là-dedans qui n'est pas raisonnable.

Polyglot

Op vr 28 sep. 2018 om 08:49 schreef Severin Menard :

> Bonjour à tous,
>
> Pour a dernière réunion du bureau de l'OSMF il y a une semaine, est
> apparue une version refondue de la fameuse Policy/guidelines de l'édition
> organisée préparée par le Data Working Group et qui n'avait pas été
> diffusée auparavant. Voici le texte :
>
>
> https://wiki.osmfoundation.org/w/images/1/13/Organised_editing_guidelines_version_20180908.pdf
>
> Le bureau de l'OSMF n'a pas eu le temps de discuter de cette nouvelle
> version et y travaillera d'ici la prochaine. Peter Barth souhaite que ces
> échanges soient publics ou du moins publiés. Pour leur implication
> professionnelle dans Telenav et Mapbox, Martjn van Exel et Mikel Matin
> seront écartés du vote. À la fin de la réunion, quand la parole a été
> ouverte à l'auditoire, Nakaner a fait remarquer à Heather Leson qu'il
> devrait en être de même en ce qui la concerne, compte tenu de l'implication
> de la Fédération Internationale des Croix-Rouge dans le mouvement Missing
> Maps (qui avec les sociétés engagées dans des activités de cartographie
> OSM, est l'autre raison de la lise en oeuvre de ces guidelines, au vu de la
> qualité souvent produite). Ce point n'a pas ensuite été éclairci.
>
> Christoph Hormann a envoyé un courriel très critique sur ce nouveau texte
> sur la liste de discussion de l'OSMF, reprenant ce qu'il avait dit en fin
> de réunion. Le flou sur les activités concernées par le texte de ces
> guidelines est notamment particulièrement impressionnant.
>
> Bref, mieux vaut lire ce texte et faire connaître son opinion avant qu'il
> ne soit adopté.
>
> Séverin
>
> ___
> Hot-francophone mailing list
> hot-francoph...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot-francophone
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Règles de l'édition dirigée, nouvelle version de travail

2018-09-28 Par sujet Severin Menard
Bonjour à tous,

Pour a dernière réunion du bureau de l'OSMF il y a une semaine, est apparue
une version refondue de la fameuse Policy/guidelines de l'édition organisée
préparée par le Data Working Group et qui n'avait pas été diffusée
auparavant. Voici le texte :

https://wiki.osmfoundation.org/w/images/1/13/Organised_editing_guidelines_version_20180908.pdf

Le bureau de l'OSMF n'a pas eu le temps de discuter de cette nouvelle
version et y travaillera d'ici la prochaine. Peter Barth souhaite que ces
échanges soient publics ou du moins publiés. Pour leur implication
professionnelle dans Telenav et Mapbox, Martjn van Exel et Mikel Matin
seront écartés du vote. À la fin de la réunion, quand la parole a été
ouverte à l'auditoire, Nakaner a fait remarquer à Heather Leson qu'il
devrait en être de même en ce qui la concerne, compte tenu de l'implication
de la Fédération Internationale des Croix-Rouge dans le mouvement Missing
Maps (qui avec les sociétés engagées dans des activités de cartographie
OSM, est l'autre raison de la lise en oeuvre de ces guidelines, au vu de la
qualité souvent produite). Ce point n'a pas ensuite été éclairci.

Christoph Hormann a envoyé un courriel très critique sur ce nouveau texte
sur la liste de discussion de l'OSMF, reprenant ce qu'il avait dit en fin
de réunion. Le flou sur les activités concernées par le texte de ces
guidelines est notamment particulièrement impressionnant.

Bref, mieux vaut lire ce texte et faire connaître son opinion avant qu'il
ne soit adopté.

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


Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR

2018-09-28 Par sujet Maël REBOUX
je vois l’idée mais c’est pas encore ça.

…
"table": "( 
SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
FROM planet_osm_point
JOIN (
WITH numbered AS(
SELECT row_number() OVER() AS row, entry
FROM(
SELECT unnest(members) AS entry
FROM planet_osm_rels
WHERE ARRAY['boundary','administrative']<@tags AND 
ARRAY['admin_level','6']<@tags) AS mylist)
SELECT ltrim(a.entry,'n')::bigint AS osm_id
FROM numbered AS a JOIN numbered AS b
ON a.row = b.row-1 AND b.entry = 'admin_centre'
) x
USING(osm_id)
 ) AS data",
"geometry_table":"numbered",
"key_field": "",
"geometry_field": "way",
"asynchronous_request": "true",
"max_async_connection": "4",
"simplify_geometries": "true",
"extent_cache": "auto",
"extent": "-1363990,3994624,1824475,9411676"
  },
…

donne une erreur différente :

Postgis Plugin: ERROR:  relation "numbered" does not exist
LINE 1: SELECT ST_SRID("way") AS srid FROM numbered WHERE "way" IS N...
   ^
in executeQuery Full sql was: 'SELECT ST_SRID("way") AS srid FROM numbered 
WHERE "way" IS NOT NULL LIMIT 1;'

logique : la géométrie n’est pas dans « numbered » (c’est pour récupérer le 
admin_level dans la table des relations)
mais dans planet_osm_point

donc on essaie :

"table": "( 
SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
FROM planet_osm_point
JOIN (
WITH numbered AS(
SELECT row_number() OVER() AS row, entry
FROM(
SELECT unnest(members) AS entry
FROM planet_osm_rels
WHERE ARRAY['boundary','administrative']<@tags AND 
ARRAY['admin_level','8']<@tags) AS mylist)
SELECT ltrim(a.entry,'n')::bigint AS osm_id
FROM numbered AS a JOIN numbered AS b
ON a.row = b.row-1 AND b.entry = 'admin_centre'
) x
USING(osm_id)
 ) AS data",
"geometry_table":"planet_osm_point",
"key_field": "",
"geometry_field": "way",
"asynchronous_request": "true",
"max_async_connection": "4",
"simplify_geometries": "true",
"extent_cache": "auto",
"extent": "-1363990,3994624,1824475,9411676"
  },

et là ça passe : plus d’erreur MAIS je récupère pas de géométrie non plus :(

> Le 27 sept. 2018 à 09:31, Christian Quest  a écrit :
> 
> Les requêtes SQL sont ré-empaquetées par le driver postgis de mapnik et là je 
> pense qu'il ne sait pas détecter que c'est dans "data" qu'il va trouver "way".
> 
> Essaye en ajoutant un paramètre "geometry_table": "data" voire aussi 
> "geometry_field": "way"
> 
> Pour l'ensemble des paramètres qu'on peut passer, voir: 
> https://github.com/mapnik/mapnik/wiki/PostGIS 
> 
> 
> Je pense aussi qu'un && !bbox! quelque part sera peut être nécessaire pour 
> être sûr que la requête soit limitée à l'emprise à rendre...
> 
> 
> Le jeu. 27 sept. 2018 à 07:45, Maël REBOUX  a écrit :
> J’ai oublié de mettre la déclaration de la couche dans le projet :
> 
> 
> {
>   "id": "places_admin_6",
>   "name": "places_admin_6",
>   "class": "",
>   "Datasource": {
> "type": "postgis",
> "host": "db.openstreetmap.local",
> "user": "osm",
> "password": "osm",
> "dbname": "osm",
> "table": "( 
> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
> FROM planet_osm_point
> JOIN (
> WITH c AS(
> SELECT row_number() OVER() AS row, entry
> FROM(
> SELECT unnest(members) AS entry
> FROM planet_osm_rels
> WHERE ARRAY['boundary','administrative']<@tags AND 
> ARRAY['admin_level','6']<@tags) AS mylist)
> SELECT ltrim(a.entry,'n')::bigint AS osm_id
> FROM c AS a JOIN c AS b
> ON a.row = b.row-1 AND b.entry = 'admin_centre'
> ) x
> USING(osm_id)
>  ) AS data",
> "key_field": "",
> "geometry_field": "way",
> "asynchronous_request": "true",
> "max_async_connection": "4",
> "simplify_geometries": "true",
> "extent_cache": "auto",
> "extent": "-1363990,3994624,1824475,9411676"
>   },
>   "geometry": "point",
>   "srs-name": "3857",
>   "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 
> +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
>   "extent": [ -10, 34, 20, 70 ],
>   "advanced": {}
> }
> 
> 
>> Le 27 sept. 2018 à 00:10, Maël REBOUX > > a écrit :
>> 
>> Bonjour tous,
>> 
>> Je cherche à faire apparaître sur une carte en ligne les préfectures et leur 
>> nom en breton.
>> 
>> La façon d’y arriver est « connue » : il faut faire une jointure entre la 
>> table planet_osm_point (qui contient le point et le nom) et la