Re: [OSM-talk-fr] Tag pour constructeur de maisons ?

[pepilepi...@ovh.fr]

  
  
Le 22/10/2016 à 21:35, Romain MEHUT a
  écrit :


  

  Bonsoir,

  
  Celui-ci http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbuilder
  pourrait faire l'affaire ?
  

Romain
  

Pas exactement... Mais c'est vrai que j'avais pas pensé au tag
  "craft". En fait le "constructeur de maison" auquel je fais
  référence est plus du bureau d'études que de la réalisation.
Merci,
JP


  
Le 22 octobre 2016 à 15:34, pepilepi...@ovh.fr
  
  a écrit :
  

  Bonjour,
  Après mon angoisse sur les kinés je
  suis aujourd'hui confronté à un autre problème :
  comment taggue-t-on un constructeur de maisons ? À
  savoir le gars à qui vous expliquez ce que vous voulez
  et qui vous fait les plans, organise et coordonne tous
  les corps de métiers et vous livre votre petite maison
  terminée. Pas vraiment, d'ailleurs, un promoteur
  immobilier, puisque lui achète en gros et revend au
  détail.

  Dans le wiki j'ai bien vu un
  "office=estate_agent", mais le "estate agent" se
  traduit parfaitement en français par "agent
  immobilier" et ce n'est pas ça qui corespond à ce que
  je veux indiquer.
  Question annexe : quand on ne
  trouve pas dans la nomenclature officielle ce dont on
  a besoin précisément y a-t-il un moyen de préciser une
  approximation ? Par exemple ici mettre office=estate_agent et un fr:=constructeur de maisons individuelles ?
  Merci,
  Jean-Pierre



___
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] données maritimes pour Osmose ?

[Frédéric Rodrigo]

Salut,

Pas sûr que ça puisse servir pour Osmose.
Pour pouvoir valider les mers et océans, il faut :
- des extracts de ces régions,
- un polygone exact par zone,
- des idées de règles à que l'on cherche à valider.

Frédéric.


Le 21/10/2016 à 21:53, osm.sanspourr...@spamgourmet.com a écrit :


Bonjour,

MarineRegions vient de sortir sa nouvelle version des ZEE.

Attention, ils prennent non la définition légale mais celle des zones 
de pêches.


Elles vont donc jusqu'à la côte.

Ils ont par le passé envisagé de mettre leurs données dans OSM, elles 
ne sont pas en ODbL pour le moment mais si d'autres voix se joignent à 
la demande...


À noter aussi un gazeetter intéressant pour nommer les objets en mer.

Jean-Yvon


*From:*users-ow...@marineregions.org 
[mailto:users-ow...@marineregions.org] *On Behalf Of *Marine Regions 
users

*Sent:* Friday, October 21, 2016 1:24 PM
*To:* us...@marineregions.org
*Subject:* [Marine Regions] New version Maritime Boundaries on 
MarineRegions.org


*Dear Marine Regions User,*

**

*MarineRegions.org  is proud to launch 
the new version of the Maritime Boundaries Geodatabase. **In this new 
release, Marine Regions updates the global Exclusive Economic Zones 
(EEZ) (version 9), and **launches global datasets for **Territorial 
Seas (TS), Contiguous Zones (CZ), Internal Waters (IW) and 
Archipelagic Waters (AW). The global baseline used in this new 
version is a combination of the publically available straight and 
archipelagic baselines and the coastline as a proxy for the low-water 
line. The source for the straight baselines is the United Nations 
repository on maritime claims, together with national publications on 
maritime delimitations and agreements. The ESRI Countries 2014 
database has been used as the primary source for the Maritime 
Boundaries coastline. The coastline was further updated with reefs 
data extracted from the Coral Reef Distribution database from UNEP 
for the countries where reefs were fundamental for the correct 
calculation of the maritime areas. *


**

*With the new release, we hope to further serve the global marine 
data user community working on geospatial analysis. As Marine Regions 
depends on data and knowledge sharing from global, European, regional 
and national data providers and relevant experts, we aim to set up 
Collaboration Agreements with our users and data providers. An 
example template of a Collaboration Agreement can be found online, 
please contact i...@marineregions.org  
if your organization is interested to explore this collaboration.*


**

*All datasets from marineregions.org’s Maritime Boundaries 
Geodatabase continue to be the only freely-available global datasets 
on the World’s Maritime Boundaries.*


**

*With Kind Regards*

**

*The Marine Regions Team*

*Follow us on Twitter @marineregions *



Jean-Yvon

*From:*users-ow...@marineregions.org *On Behalf Of *Marine Regions users
*Sent:* Friday, October 21, 2016 1:24 PM
*To:* us...@marineregions.org
*Subject:* [Marine Regions] New version Maritime Boundaries on 
MarineRegions.org


*Dear Marine Regions User,*

**

*MarineRegions.org  is proud to launch 
the new version of the Maritime Boundaries Geodatabase. **In this new 
release, Marine Regions updates the global Exclusive Economic Zones 
(EEZ) (version 9), and **launches global datasets for **Territorial 
Seas (TS), Contiguous Zones (CZ), Internal Waters (IW) and 
Archipelagic Waters (AW). The global baseline used in this new version 
is a combination of the publically available straight and archipelagic 
baselines and the coastline as a proxy for the low-water line. The 
source for the straight baselines is the United Nations repository on 
maritime claims, together with national publications on maritime 
delimitations and agreements. The ESRI Countries 2014 database has 
been used as the primary source for the Maritime Boundaries coastline. 
The coastline was further updated with reefs data extracted from the 
Coral Reef Distribution database from UNEP for the countries where 
reefs were fundamental for the correct calculation of the maritime 
areas. *


**

*With the new release, we hope to further serve the global marine data 
user community working on geospatial analysis. As Marine Regions 
depends on data and knowledge sharing from global, European, regional 
and national data providers and relevant experts, we aim to set up 
Collaboration Agreements with our users and data providers. An example 
template of a Collaboration Agreement can be found online, please 
contact i...@marineregions.org  if your 
organization is interested to explore this collaboration.*


**

*All datasets from marineregions.org’s Maritime Boundaries Geodatabase 
continue to be the only freely-available global datasets on the 
World’s Maritime Boundaries.*


**

*With Kind 

Re: [OSM-talk-fr] Tag pour constructeur de maisons ?

[Romain MEHUT]

Bonsoir,

Celui-ci http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbuilder pourrait
faire l'affaire ?

Romain

Le 22 octobre 2016 à 15:34, pepilepi...@ovh.fr  a écrit
:

> Bonjour,
>
> Après mon angoisse sur les kinés
> 
> je suis aujourd'hui confronté à un autre problème : comment taggue-t-on un
> constructeur de maisons ? À savoir le gars à qui vous expliquez ce que vous
> voulez et qui vous fait les plans, organise et coordonne tous les corps de
> métiers et vous livre votre petite maison terminée. Pas vraiment,
> d'ailleurs, un promoteur immobilier, puisque lui achète en gros et revend
> au détail.
>
> Dans le wiki j'ai bien vu un "office=estate_agent", mais le "estate agent"
> se traduit parfaitement en français par "agent immobilier" et ce n'est pas
> ça qui corespond à ce que je veux indiquer.
>
> Question annexe : quand on ne trouve pas dans la nomenclature officielle
> ce dont on a besoin précisément y a-t-il un moyen de préciser une
> approximation ? Par exemple ici mettre office=estate_agent et un fr: sais pas>=constructeur de maisons individuelles ?
>
> Merci,
>
> Jean-Pierre
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Map4Haiti Ouragan Matthew Une premiere - 15km2 images UAV disponibles pour évaluation des dommages

[Pierre Béland]

Envois aux listes hot-francophone, talk-ht, et talk-fr


 
--
Deux semaines après l'arrivée de l'ouragan Matthew en Haiti, plus de 1.4 
millions de personnes ont besoin d'aide et la situation est encore très 
précaire. De nombreux villages n'ont pas encore reçu d'aide. Les services de 
santé déjà précaires avant le séisme ont été fortement touchés. MSF rapporte 
que 23 centres de santé ont été endommagés ou partiellement détruits. Le risque 
d'épidémie de choléra inquiète les organisations de santé. De nouvelles 
dépressions tropicales sont arrivées sur Haiti causant encore des inondations 
et augmentant les risques de glissement de terrain.
Les organismes internationaux qui planifient la reconstruction ont besoin 
d'évaluer l'ampleur des dégâts et estimer l'effort financier nécessaire.
Images UAV couvrant 15km2
Une première avec les réponses humanitaires, des images UAV de grande précision 
couvrant déjà plus de 15km2 et une dizaine de sites sont disponbiles. Elles 
sont hébergées sur les serveurs TMS et WMS de OSM-fr. Ces images ciblent des 
localités fortement affectées par l'ouragan. Elles viennent compléter 
l'information fournie par les images satellite post-désastre. La carte 
UAVCompare, en ligne depuis hier, avec des panneaux Avant / Après permet 
d'observer l'ampleur du désastre. Les images pré-désastre prises par avion sont 
mises à disposition par le CNIGS, l'agence geospatiale du gouvernement haitien. 
http://pierzen.dev.openstreetmap.org/swipe/UAVCompare-Haiti-Matthews-before-after.php

Les images UAV fournissent des images souvent jusqu'à 10 fois plus précises que 
les images satellite. Zoomez sur ces images, et vous verrez quels détails elles 
fournissent sur l'état des structures dans les diverses localités et comment 
elles peuvent être utilisées pour l'évaluation des dommages. Pour rappel, les 
contributeurs expérimentés sont invités à nous contacter pour contribuer à 
l'évaluation des dommages.Voir http://taches.francophonelibre.org/

Les missions UAV sur le terrain ont été réalisées par deux équipes, travaillant 
dans des conditions difficiles et des moyens matériels réduits.  Nos collègues 
Fred Moine et Presler Jean de la ONG haitienne Potentiel3.0 et Nicolas Clarens, 
consultant pour la Banque inter-américaine de développement, ont organisé les 
missions sur le terrain. 

Les plans de vol, les missions de collecte d'images sur le terrain, le 
traitement et le transfert de données sont des éléments essentiels pour assurer 
le succès de telles opérations. Malgré les difficultés matérielles, les 
problèmes d'électricité et de transfert internet, Fred, Presler et Xavier ont 
fait le traitement à partir d'ordinateurs personnels, et fait le transfert de 
données vers le serveur OSM-France. Jean-Guilhem Cailton a alors pris le 
relais, converti ces images lorsque c'était nécessaire, et les a intégrées aux 
serveurs WMS et TMS de OSM-Fr.
.Avec les pluies abondantes et le pont endommagé sur la route principale, Fred 
et Presler ont de la difficulté à rejoindre les localités sinistrées. Ils 
poursuivent néanmoins leurs efforts et vont organiser des missions de vols UAV 
notamment au dessus de zones à risque de glissement de terrain.
Chapeau à tous ces collègues qui ont réussi à travailler en flux tendus avec 
très peu de moyens et livrer des images saisissantes.  
Pierre twitter pierzen
   ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[Philippe Verdy]

Déjà les "bus_stop" (ancienne version) devraient correspondent point par
point aux nouveaux objets "public_transport:platform" s'ils ne sont pas sur
le chemin mais doivent servir à indiquer les abris, les bancs ou
l'accessibilité et la zone d'attente (ou le poteau indicateur)

S'ils sont sur le chemin (donc sans indication du côté) ce sont des
"public_transport:stop_position" (et il n'y a pas d'attributs pour les
bancs, abris et l'accessibilité).

Selon que c'est un type ou l'autre tu en déduis le rôle qu'il faut mettre
dans la relation route. Idéalement on devrait avoir deux rôles pour chaque
arrêt: stop et platform

Les "route segments" (proposés) sont une autre problématique liée à la
topologie des chemins, et la multiplicité des variantes qui empruntent des
sections communes. Mais ils sont surtout nécessaire pour lever les
ambiguités de parcours sur les chemins quand ils ne forment pas une ligne
continue sans intersection, car dans l'immédiat on est amené à devoir
mettre tous les ways membres dans l'ordre, y compris avec des doublons pour
les segments communs, et il n'est pas facile de déterminer un ordre des
segments quand il y a des intersections, même sur une seule route et après
avoir séparé chaque direction et chaque variante de la ligne dans des
relations "route" séparées mais regroupées dans un "route_master"

Quand on a compris tout ça, on peut faire une appli qui saura distinguer
les vrais "stop_position" des "plateform" (c'est facile: le "stop" est sur
le chemin, mais pas la "plateform"), ce que "bus_stop" ne sait pas classer
correctement. Juste faire ça fera beaucoup avancer les choses.



Pour aller au delà avec les "stop_area" par exemple pour regrouper
différents arrêts et plateformes de différentes lignes destinées à la
correspondance directe ou même pour revenir en arrière sur la même ligne
mais par une autre route), c'est un autre travail à faire: celui de
vérifier et assurer les correspondances.

De même que les objets "station" qui sont des regroupements plus large
comprenant plusieurs "stop_area", des batiments, des accès (escaliers,
portes, ascenseurs...) où la correspondance est plus complexe (et où on
peut avoir des services annexes (comme la vente des billets et abonnements)
et peut grouper des réseaux de nature différente et différents opérateurs
pour l'intermodalité (exemple: les gares routières et gares ferroviaires)


Le 22 octobre 2016 à 12:10, Florian LAINEZ  a écrit :

> Si on propose ce que l'on sait déjà de l'arrêt et qu'on propose de
>> confirmer/infirmer/ne pas se prononcer, on gagne des possibilités de
>> réponse rapide.
>
> tout à fait, je pense à de l'autocomplétion avec la meilleure proposition
> mise en avant le cas échéant.
>
> Peut-être que si on laisse la personne dessiner le trajet (juste en
>> chaînant les arrêts) on a pas mal de matière.
>> Ensuite un moteur de calcul de trajet (favorisant les rues larges et
>> droites) peut être utilisé côté serveur pour avoir un trajet vraisemblable.
>> Trajet à valider bien-sûr.
>
>  C'est à peu près ça que j'ai en tête. Avec la possibilité de drag le
> chemin pour le replacer (du style de ce que propose OSRM sur osm.org)
> sans avoir à gérer des way un par un.
>
> @philippe tout ceci est passionnant mais ce sont des problématiques
> complexes, or mon appli est vraiment focalisée sur la simplicité. D'où le
> parti pris de ne gérer que les highway=bus_stop (ou son équivalent
> public_transport=platform).
>
> Mon idée est bien de pouvoir gérer les deux modèles, ancien et nouveau, de
> manière transparente pour l'utilisateur.
> Charge aux mappeurs expérimentés de compléter le travail avec des outils
> plus classiques.
>
>
> Le 21 octobre 2016 à 22:26, Philippe Verdy  a écrit :
>
>> Les tags "from=*", "via=*" et "to=*" sont plutôt destinés à un
>> utilisateur humain qu'à subir un vrai rapprochement avec un arrêt.
>>
>> Dans le shéma actuel ("public_transport:version=2" dans les relations
>> "route"), ce sont les noeuds membres (posés sur un les ways membres) ayant
>> un rôle "stop" qui servent à ça, le premier noeud (from) devrait être de
>> rôle "stop_enter_only", le dernier de rôle "stop_exit_only". La direction
>> de la ligne devrait s'en déduire L'ennui c'est qu'il existe parfois des
>> stations intermédiaires qui n'autorisent que la descente ou que la montée,
>> ayant ces même rôles (c'est rare...). On n'a en fait rien de clair pour
>> indiquer réellement quels arrêts (noeuds de rôle "stop") sont les deux
>> terminus (l'idéal serait d'ajouter un suffixe ":start" ou ":end" à ces
>> rôles)
>>
>> On peut ajouter aussi les plateformes (noeuds, lines ou polygones) en
>> membres de rôle "platform" (avec "platform_enter_only",
>> "platform_exit_only" pour le premier et le dernier arrêt, mais cela me
>> semble inutile si on a identifié clairement les deux noeuds "stop" de
>> départ et d'arrivée: le rôle "platform" suffit à lui seul; ces rôles
>> variantes sont plutôt destinés à 

[OSM-talk-fr] Tag pour constructeur de maisons ?

[pepilepi...@ovh.fr]

  
  
Bonjour,
Après mon
  angoisse sur les kinés je suis aujourd'hui confronté à un
autre problème : comment taggue-t-on un constructeur de maisons
? À savoir le gars à qui vous expliquez ce que vous voulez et
qui vous fait les plans, organise et coordonne tous les corps de
métiers et vous livre votre petite maison terminée. Pas vraiment,
d'ailleurs, un promoteur immobilier, puisque lui achète en gros
et revend au détail.
  
Dans le wiki j'ai bien vu un "office=estate_agent",
mais le "estate agent" se traduit parfaitement en français par
"agent immobilier" et ce n'est pas ça qui corespond à ce que je
veux indiquer.
Question annexe : quand on ne trouve pas
dans la nomenclature officielle ce dont on a besoin précisément
y a-t-il un moyen de préciser une approximation ? Par exemple
ici mettre office=estate_agent et un
fr:=constructeur de maisons individuelles ?
Merci,
Jean-Pierre
  
  


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

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[Florian LAINEZ]

>
> Si on propose ce que l'on sait déjà de l'arrêt et qu'on propose de
> confirmer/infirmer/ne pas se prononcer, on gagne des possibilités de
> réponse rapide.

tout à fait, je pense à de l'autocomplétion avec la meilleure proposition
mise en avant le cas échéant.

Peut-être que si on laisse la personne dessiner le trajet (juste en
> chaînant les arrêts) on a pas mal de matière.
> Ensuite un moteur de calcul de trajet (favorisant les rues larges et
> droites) peut être utilisé côté serveur pour avoir un trajet vraisemblable.
> Trajet à valider bien-sûr.

 C'est à peu près ça que j'ai en tête. Avec la possibilité de drag le
chemin pour le replacer (du style de ce que propose OSRM sur osm.org) sans
avoir à gérer des way un par un.

@philippe tout ceci est passionnant mais ce sont des problématiques
complexes, or mon appli est vraiment focalisée sur la simplicité. D'où le
parti pris de ne gérer que les highway=bus_stop (ou son équivalent
public_transport=platform).

Mon idée est bien de pouvoir gérer les deux modèles, ancien et nouveau, de
manière transparente pour l'utilisateur.
Charge aux mappeurs expérimentés de compléter le travail avec des outils
plus classiques.


Le 21 octobre 2016 à 22:26, Philippe Verdy  a écrit :

> Les tags "from=*", "via=*" et "to=*" sont plutôt destinés à un utilisateur
> humain qu'à subir un vrai rapprochement avec un arrêt.
>
> Dans le shéma actuel ("public_transport:version=2" dans les relations
> "route"), ce sont les noeuds membres (posés sur un les ways membres) ayant
> un rôle "stop" qui servent à ça, le premier noeud (from) devrait être de
> rôle "stop_enter_only", le dernier de rôle "stop_exit_only". La direction
> de la ligne devrait s'en déduire L'ennui c'est qu'il existe parfois des
> stations intermédiaires qui n'autorisent que la descente ou que la montée,
> ayant ces même rôles (c'est rare...). On n'a en fait rien de clair pour
> indiquer réellement quels arrêts (noeuds de rôle "stop") sont les deux
> terminus (l'idéal serait d'ajouter un suffixe ":start" ou ":end" à ces
> rôles)
>
> On peut ajouter aussi les plateformes (noeuds, lines ou polygones) en
> membres de rôle "platform" (avec "platform_enter_only",
> "platform_exit_only" pour le premier et le dernier arrêt, mais cela me
> semble inutile si on a identifié clairement les deux noeuds "stop" de
> départ et d'arrivée: le rôle "platform" suffit à lui seul; ces rôles
> variantes sont plutôt destinés à combler des données manquantes quand il
> manque des noeuds "stop", mais les plateformees sont pas faciles du tout à
> gérer et associer avec le parcours de la ligne sans un noeud "stop"
> correspondant).
>
> Il reste cependant le cas des lignes circulaires dont le départ et
> l'arrivée sont au même point: si ce point n'est pas sur un way en sens
> unique (par exemple une petite voie de service latérale à la chaussée), là
> on a bsoin que ce premier chemin ait un rôle "forward" ou "backward" (je ne
> vois pas comment faire autrement) pour indiquer le sens de la ligne.
> L'autre solution serait d'utiliser deux noeuds très proches mais séparés
> pour distinguer le départ et l'arrivée (mais sans mettre alors dans la
> "route" le segment qui les relie ! Ces noeuds étant cependant associés à la
> même plateforme.
>
> Les chemins sont ensuite parcours dans le sens indiqués par leur jonction,
> mais il reste la difficulté des lignes dont l'itinéraire repasse plusieurs
> fois par le même noeud (voire même par un même chemin en cas de détour, et
> pas non plus forcément en sens opposé si ce détour fait une boucle): là
> encore les chemins doivent être orientés pour réduire (avec backward ou
> forward) le nombre de possibilités de succession des chemins, mais il peut
> rester des ambiguités.
>
> Pour éliminer totalement ces ambiguïtés, il a été proposé de créer des
> relation "route" avec un tag "segment=yes", où les chemins forment une
> ligne ininterrompue et ne repassant jamais par un même noeud ou chemin,
> puis d'inclure ces segments de routes en tant que membres d'une relation
> "route" normale. Mais ce n'est pas encore mis en oeuvre.
>
> En attendant, on a encore besoin que les relations "route" mentionnent la
> liste des arrêts ("stop") dans l'ordre exact. Et il est impératif
> d'utiliser des noeuds rôle "stop" (tagués "public_transport=stop_position"
> + "bus=yes") sur les chemins. Ces noeuds n'ont aucun tag pour les abris,
> poubelles, accès handicap, etc. qui sont à mettre plutôt sur les objets
> "public_transport=platform".
>
> Le nouveau schéma recommande même de placer dans l'ordre dans la relation
> les noeuds "stop" suivis immédiatement de l'objet "platform" auquel il se
> réfère; la liste des chemins se met plutôt ensuite après (avec des chemins
> en doublons parfois, faute de prise en charge pour l'instant des "segments"
> de route).
>
> Noter que les chemins peuvent aller commencer et aller plus loin que le
> premier et le dernier arrêt (généralement on inclue dans une route aussi