Re: [OSM-talk-fr] Doute sur le calage Bing/Cadastre

[Christian Quest]

Dans les zones à fort relief, l'image aérienne aura des chances d'être
partiellement orthorectifiée.
Des parties proches peuvent être plus ou moins bien calées à cause de la
parallaxe... sauf si on a un super modèle numérique de terrain pour
remettre ça "droit".
C'est donc plutôt l'image en qui je ferai le moins confiance, surtout
sur les parties encaissées (celles à problème en fait).

Les traces GPS vont perdre en précision, mais là, la solution c'est de
les cumuler pour éliminer petit à petit les erreurs.

Le cadastre... difficile de dire quel niveau de précision il a, surtout
que ça peut varier d'une feuille à l'autre.

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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[Nicolas Moyroud]

Bonjour,

Intéressant ce projet ! Ce n'est pas trop ma zone de contribution mais 
je viendrai peut-être quand même donner un petit coup de main à 
l'occasion. Juste une petite remarque je ne suis pas trop d'accord avec 
le tag network=rwn qui est préconisé. Pour moi c'est plutôt du 
network=lwn. Voir la description :

http://wiki.openstreetmap.org/wiki/Walking_Routes#Tags_of_the_relation
rwn = Regional walking network: used for walking routes that cross regions
lwn = Local walking network: used for small local walking routes
En tout cas pour des petites boucles de quelques heures ou à la journée 
c'est plutôt lwn que j'utilise. Même si il y a peut-être dans le lot de 
vos données quelques grands itinéraires qui justifieraient un rwn.


Nicolas M



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

Re: [OSM-talk-fr] JOSM et Opendata

[Christian Quest]

On 08/02/2016 11:47, Jérôme Seigneuret wrote:
> Bonjour,
> Les liens sont tronqués. Il y a eu une mise à jour
>
> Bon les lien sont à mettre à jour:
>
> - RPG 2010
> https://www.data.gouv.fr/fr/datasets/registre-parcellaire-graphique-2010-contours-des-ilots-culturaux-et-leur-groupe-de-cultures-majorita/
> - PPG 2011
> https://www.data.gouv.fr/fr/datasets/registre-parcellaire-graphique-2011-contours-des-ilots-culturaux-et-leur-groupe-de-cultures-majorita/
> - RPG 2012
> https://www.data.gouv.fr/fr/datasets/registre-parcellaire-graphique-2012-contours-des-ilots-culturaux-et-leur-groupe-de-cultures-majorita/
>
> Pour les années suivantes c'est plus généré ainsi... Changer l'année
> ne renvoi rien...
>
> Normalement des données n-1 sont mise à disposition au 1 septembre
> donc au 01/09/2015 nous devrions pouvoir utiliser les données de
> 2013,2014.
>

Le producteur de cette donnée est (très) en retard sur les diffusions
2013, 2014...

On peut cependant en trouver des bouts diffusés par certaines DDT(M).

-- 
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

[Plop76]

Thomas Petillon a écrit :

2016-02-07 11:51 GMT+01:00 Plop76 :


osm.sanspourr...@spamgourmet.com a écrit :

Mais pour OSM c'est limite des marées hautes de vives-eaux de 70.




Les marées de vives-eaux moyenne c'est 95 ("mean high water spring" en
anglais). 70 ce n'est qu'une marée moyenne.

D'après les wiki OSM, c'est sur la ligne des marées de coeff 95 que se
trouve le trait de côte.



+1 sur le fait que ce que dit le wiki _n'est pas_ un coefficient de 70.

D'après le wiki le way natural=coastline est sur la ligne de « mean high
water spring ».

On peut trouver une définition de MHWS sur le site de la NOAA à l'adresse
http://shoreline.noaa.gov/glossary.html :

The average height of the high waters of the spring tides is called

spring high water or mean high water springs (MHWS)

Et si l'on se réfère au SHOM (
http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/)


Par convention, le coefficient 100 est attribué au marnage semi-diurne

moyen lors des vives-eaux voisines des équinoxes (21 mars, 21septembre).

Les deux définitions concordant, le trait de côte dans OSM serait à caler
sur une marée (haute) de coefficient 100. (Et le wiki francophone à
corriger.)


Ce n'est pas exactement la même définition, le coeff 100 étant pour les 
marées de vives-eaux *proches des équinoxes* (2 fois par an) alors que 
le MHWS est la moyenne pour toutes les marées de vives-eaux (2 fois par 
mois).


En se référant également au SHOM, cette moyenne correspond à un coeff 
95 : 
http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/


Je maintiens donc que, d'après le wiki anglais, c'est sur les marées 
hautes de coeff 95 qu'on doit placer le trait de côte sur OSM :)



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

Re: [OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

[Jérôme Seigneuret]

>
>
>
> Je maintiens donc que, d'après le wiki anglais, c'est sur les marées
> hautes de coeff 95 qu'on doit placer le trait de côte sur OSM :)
>

Si c'est le cas, doit-on prendre ce trait de côte pour définir la limite
communale ou on à deux traits... ducoup les plages entre deux coef sont sur
quel territoire ou niveau territorial?

Les eaux intérieur ça se tag comment?
natural=water+ ...

Ce trait sert-il a définir la zone de wetland=tidalflat coté océan et que
mettre coté continent? (eau, plage, zone de marais, ...)

Des cas d'usage seraient bien venus (des schémas simple)

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

Re: [OSM-talk-fr] Doute sur le calage Bing/Cadastre

[Dominique Faure]

Merci pour l'info, je vais tâcher des points de calages pertinents aux
alentours.

2016-02-08 10:53 GMT+01:00 Jérôme Seigneuret :

> Bonjour,
>
> Attention sur les zones de montagne
>
> J'ai déjà vu des décalages de fou autant sur l'ortho, le cadastre, que les
> données GPS. Il est très difficile de savoir comment rectifier
> correctement. On l'observe sur certaines jointures de photo Bing; Sur le
> Cadastre ce sont les limites de communes qui montre bien le problème; Le
> GPS quant à lui est complètement foireux quand la couverture est opéré par
> des satellite ne sont pas assez écartés et peut causer des décalages de
> plusieurs dizaines de mètres (on voit un écartement entre les traces prise
> sur différents jours voir même différentes heures pour une même position).
> Pour rappel, c'est pas la richesse en nombre de satellites qui est gage de
> qualité pour la localisation.
>
> Je vous invites à vous renseigner sur les contraintes et les limites des
> différents systèmes avant de choisir un calage comme étant une source
> d'information. En effet la source des points géodésiques reste la meilleure
> source (et pour le moment la seule qui fournie une info de qualité)
>
> Sur le cadastre il me semble que les points repérés avec des infos
> géodésiques de levé de géomètre sont entourés au niveau des limites de
> parcelles.
>
> Cordialement,
> Jérôme
>
> Le 7 février 2016 à 22:46, GarenKreiz  a écrit :
>
>> Bonsoir,
>>
>> A priori il faut se recaler sur les bornes géodesiques RGF quand on
>> arrive à les repérer sur la couche photographique. Dans le coin, les
>> plus exploitables pourraient être le sommet du Moutet (Mont-de-Lans I)
>> et la Grande Aiguille (Mont-de-Lans V) qui semblent indiquer un
>> décalage d'une quinzaine de mètre vers l'est des photos. Mais ces
>> repères sont assez loins : il faudrait aller repérer sur le terrain et
>> les photos la borne la plus proche du hameau (Mont-de-Lans II).
>>
>> Ceci étant, si beaucoup de choses des environs ont été saisies d'après
>> les photos sans recalage, cela va être délicat de garder la cohérence
>> de la carte!
>>
>>
>> Le 6 février 2016 à 18:56, Dominique Faure  a
>> écrit :
>> > Bonjour,
>> >
>> > Voulant donner plus de détails autour d'un hameau alpin
>> > (http://www.openstreetmap.org/#map=17/45.03642/6.09351), je me suis
>> aperçu
>> > dans JOSM qu'à la fois les couches Bing et cadastrale étaient décalées
>> par
>> > rapport aux traces GPS.
>> >
>> > Je me doute que par sa situation quasiment au fond d'une gorge, les
>> traces
>> > GPS manquent cruellement de précision.
>> >
>> > De plus, d'après le sujet déjà abordé ici quelques années auparavant
>> > (http://gis.19327.n5.nabble.com/Alignement-cadastre-tt5729650.html),
>> je ne
>> > peux pas m'appuyer sur le cadastre non plus.
>> >
>> > Que puis-je / dois-je / ai-je le droit de faire dans ce cas?
>> >
>> > --
>> > Dominique
>> >
>> > ___
>> > 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
>
>


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

Re: [OSM-talk-fr] réponses à des notes

[Pierre-Yves Berrard]

Merci

Le 7 février 2016 à 20:50, Antoine Riche  a écrit :

> J'ai répondu à la seconde note, un histoire de name / old_name.
> La première note est sur le trait de côte à Granville : je laisse aux
> spécialistes ayant récemment débattu sur le sujet le soin d'y répondre ;-)
>
> Antoine.
>
>
> Le 07/02/2016 18:07, Pierre-Yves Berrard a écrit :
>
> Quelqu'un pour répondre à ces deux notes ?
>
> http://www.openstreetmap.org/note/508562
> http://www.openstreetmap.org/note/509229
>
> PY
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] JOSM et Opendata

[Jérôme Seigneuret]

Bonjour,
Les liens sont tronqués. Il y a eu une mise à jour

Bon les lien sont à mettre à jour:

- RPG 2010
https://www.data.gouv.fr/fr/datasets/registre-parcellaire-graphique-2010-contours-des-ilots-culturaux-et-leur-groupe-de-cultures-majorita/
- PPG 2011
https://www.data.gouv.fr/fr/datasets/registre-parcellaire-graphique-2011-contours-des-ilots-culturaux-et-leur-groupe-de-cultures-majorita/
- RPG 2012
https://www.data.gouv.fr/fr/datasets/registre-parcellaire-graphique-2012-contours-des-ilots-culturaux-et-leur-groupe-de-cultures-majorita/

Pour les années suivantes c'est plus généré ainsi... Changer l'année ne
renvoi rien...

Normalement des données n-1 sont mise à disposition au 1 septembre donc au
01/09/2015 nous devrions pouvoir utiliser les données de 2013,2014.

Il semble cependant que pour 2015 le processus ai changé en 2016. A voir
donc pour la suite.

Deux choses à voir donc:

   1. Mise à jour des liens
  - la mise à jour du wiki (liens https://www.data.gouv.fr/)
  - la mise à jour du plugin (liens https://www.data.gouv.fr/)
  2. Compléter le site data.gouv.fr pour ajouter les années manquantes
   car pour l'arrachage des vignes avec des données de 2011 c'est un peu loin
   même Bing sera plus à jour.


@Philippe: en effet, utiliser JOSM en 64x doit aider à charger le shape car
j'atteins la limite de la mémoire.
Mais je ne sais pas si le plugin utiliser des données via une emprise ou si
il charge le jeu de données complet.
Si c'est le jeu de données complet c'est un problème ou alors il faut
télécharger le fichier dans un répertoire temporaire et "piocher" dedans en
fonction de l'étendu comme le fait l'outil d'import Overpass ce qui
corrigera partiellement le problème de mémoire.


Cordialement,
Jérôme



Le 7 février 2016 à 12:14, didier2020  a écrit :

>
> est-ce lié au fait que les liens de
> http://wiki.openstreetmap.org/wiki/WikiProject_France/data.gouv.fr
>
> ne sont plus valides ?
>
>
>
>
>
>
> ___
> 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] Doute sur le calage Bing/Cadastre

[Jérôme Seigneuret]

Bonjour,

Attention sur les zones de montagne

J'ai déjà vu des décalages de fou autant sur l'ortho, le cadastre, que les
données GPS. Il est très difficile de savoir comment rectifier
correctement. On l'observe sur certaines jointures de photo Bing; Sur le
Cadastre ce sont les limites de communes qui montre bien le problème; Le
GPS quant à lui est complètement foireux quand la couverture est opéré par
des satellite ne sont pas assez écartés et peut causer des décalages de
plusieurs dizaines de mètres (on voit un écartement entre les traces prise
sur différents jours voir même différentes heures pour une même position).
Pour rappel, c'est pas la richesse en nombre de satellites qui est gage de
qualité pour la localisation.

Je vous invites à vous renseigner sur les contraintes et les limites des
différents systèmes avant de choisir un calage comme étant une source
d'information. En effet la source des points géodésiques reste la meilleure
source (et pour le moment la seule qui fournie une info de qualité)

Sur le cadastre il me semble que les points repérés avec des infos
géodésiques de levé de géomètre sont entourés au niveau des limites de
parcelles.

Cordialement,
Jérôme

Le 7 février 2016 à 22:46, GarenKreiz  a écrit :

> Bonsoir,
>
> A priori il faut se recaler sur les bornes géodesiques RGF quand on
> arrive à les repérer sur la couche photographique. Dans le coin, les
> plus exploitables pourraient être le sommet du Moutet (Mont-de-Lans I)
> et la Grande Aiguille (Mont-de-Lans V) qui semblent indiquer un
> décalage d'une quinzaine de mètre vers l'est des photos. Mais ces
> repères sont assez loins : il faudrait aller repérer sur le terrain et
> les photos la borne la plus proche du hameau (Mont-de-Lans II).
>
> Ceci étant, si beaucoup de choses des environs ont été saisies d'après
> les photos sans recalage, cela va être délicat de garder la cohérence
> de la carte!
>
>
> Le 6 février 2016 à 18:56, Dominique Faure  a
> écrit :
> > Bonjour,
> >
> > Voulant donner plus de détails autour d'un hameau alpin
> > (http://www.openstreetmap.org/#map=17/45.03642/6.09351), je me suis
> aperçu
> > dans JOSM qu'à la fois les couches Bing et cadastrale étaient décalées
> par
> > rapport aux traces GPS.
> >
> > Je me doute que par sa situation quasiment au fond d'une gorge, les
> traces
> > GPS manquent cruellement de précision.
> >
> > De plus, d'après le sujet déjà abordé ici quelques années auparavant
> > (http://gis.19327.n5.nabble.com/Alignement-cadastre-tt5729650.html), je
> ne
> > peux pas m'appuyer sur le cadastre non plus.
> >
> > Que puis-je / dois-je / ai-je le droit de faire dans ce cas?
> >
> > --
> > Dominique
> >
> > ___
> > 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] Erosion du littoral : une cartographie des côtes françaises est disponible

[Philippe Verdy]

Le 8 février 2016 à 21:02, Thomas Petillon  a écrit :

> 2016-02-08 11:38 GMT+01:00 Plop76 :
>
>> Ce n'est pas exactement la même définition, le coeff 100 étant pour les
>> marées de vives-eaux *proches des équinoxes* (2 fois par an) alors que le
>> MHWS est la moyenne pour toutes les marées de vives-eaux (2 fois par mois).
>>
>> En se référant également au SHOM, cette moyenne correspond à un coeff 95
>> :
>> http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/
>>
>> Je maintiens donc que, d'après le wiki anglais, c'est sur les marées
>> hautes de coeff 95 qu'on doit placer le trait de côte sur OSM :)
>
>
> Après relecture, on est d'accord. Je me suis trompé et ça correspond
> plutôt au coeff de 95.
>
>
> 2016-02-08 12:02 GMT+01:00 Jérôme Seigneuret :
>
>> Si c'est le cas, doit-on prendre ce trait de côte pour définir la limite
>> communale ou on à deux traits... ducoup les plages entre deux coef sont sur
>> quel territoire ou niveau territorial?
>>
>
> Jusqu'à présent on utilise le trait de côte comme limite communale. Il est
> pas déconnant de continuer comme ça je pense. (La vraie réponse quant aux
> limites communales en mer semble... compliquée ! cf.
> http://www.gridauh.fr/fileadmin/gridauh/MEDIA/2011/compte_rendu_de_travaux/seminaire_thematique/ecriture_des_plu/LP%20PLU%20littoral%20Fiche1.pdf
> )
>
> Pour ce qui est des plages, d'après le wiki natural=beach couvre la partie
> au-dessus de la ligne de côte. Pour l'estran natural=sand + tidal=yes. (cf.
> http://wiki.openstreetmap.org/wiki/Key:tidal )
>
>
>> Les eaux intérieur ça se tag comment?
>> natural=water+ ...
>>
>
> À quelles eaux tu penses ? J'ai l'impression que ce qu'il reste est
> couvert par les cas habituels (rivière, étang).
>

Non car il reste les eaux des ports, et les eaux entre continent et iles
côtières et ilots. Ce ne sont que des eaux marines (pas de rivière ni
étang). Ces eaux sont coupées par un trait reliant deux points proches sur
la ligne de base (quelle qu'en soit sa définition: basses/hautes eaux,
extrème/moyenne, annuelle ou d'équinoxe, coefficient équivalent...
correspondant ou pas selon les endroits à la ligne de côte OSM)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Jean-Michel Pouré]

Le lundi 08 février 2016 à 22:33 +0100, Jean-Yvon Landrac a écrit :
> Le GPS différentiel est effectivement très performant (10 cm ?) mais
> je ne sais s'il est disponible sur smartphone.
> Tiens je vois que toi aussi tu dis 10 cm.

Sur OpenStreetMap, j'ai découvert cette page :
http://wiki.openstreetmap
.org/wiki/RTKLIB

Sous Android, il faut installer RTKGPS :
https://f-droid.org/repository/browse/?fdid=ru0xdc.rtkgps

Ensuite, connecter un GPS externe via USB ou blutooth. Un simple GPS
intégré USB+antenne suffit. Il n'est pas nécessaire d'utiliser un GPS
haut de gamme.

Les données de correction sont émises par des stations terrestres, via
Internet. Certains utilisateurs annoncent 2 cm de précision pour la
version Internet et quelques millimètres lorsqu'on dispose d'un
récepteur radio.

Je n'ai pas testé, mais je vais le faire, vu que je dispose d'un GPS
externe. J'ai simplement besoin d'un adaptateur USB.

Cordialement,
Jean-Michel


smime.p7s
Description: S/MIME cryptographic signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Jean-Michel Pouré]

Merci pour les informations.

Je dispose également d'une carte de développement avec un GPS intégré.
Quand on n'a pas de base fixe, on peut utiliser un service Internet.

Pour OpenStreetMap, la précision de quelques dizaines de centimètres me
suffit. J'aimerais surtout caler les cartes Bing avec précision.

Cordialement,
Jean-Michel


Le lundi 08 février 2016 à 23:04 +0100, Stéphane Péneau a écrit :
> Et il faut 2 récepteurs pas trop éloignés (10km max pour les
> récepteurs L1). 1 qui est fixe (la base) et 1 qui est mobile (le
> rover).
> La base dont idéalement on connait la position exacte transmet ses
> infos au rover qui va recalculer sa position.
> Ce calcul peut être fait via la librairie RTKLIB qui est open source
> (sur ordi, smartphone), ou directement intégrée dans le récepteur.
> 
> On commence à trouver des récepteurs RAW sur 1 seule bande de
> fréquence, à pas trop cher. Par exemple le NS-HP que je teste en ce
> moment, et qui intègre une puce pour les calculs RTK (pas besoin de
> matériel externe) :
> http://navspark.mybigcommerce.com/ns-hp-rtk-capable-gps-receiver/
> 
> Les restrictions sont qu'il faut recevoir environ 6 satellites en
> commun entre la base et le rover, avec un bon rapport signal/bruit,
> et qu'ils ne soient pas trop bas sur l'horizon. En utilisant
> uniquement le GPS, ce n'est pas toujours gagné, il faut vraiment de
> bonnes conditions.

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] JOSM et Opendata

[Jérôme Seigneuret]

Merci pour l'info.
J'ai regardé pour l'Hérault mais malheureusement, nous n'avons rien de
disponible (DDTM 34)

Coté plugin, ça ne risque plus de marcher pour 2012. Il y a une partie
commune, en effet, mais le dernier répertoire n'est plus commun à
l'ensemble des jeux de données vu que c'est basé sur la date de mise à
disposition (ou chargement) sur le serveur de la données. Il faudrait créer
les URL statique comme pour 2011.

Voici le lien existant( sur de l'année 2010...)
*"http://www.data.gouv.fr/var/download/ign/RPG_2010_
"+number+".ZIP"*


Pour le* RPG 2011* ça sera:

   - *"http://static.data.gouv.fr/rpg-2011/RPG_2011_
   "+number+".zip"*

Sauf qu'il n'y a rien pour l'outre-mer (971-974,976) sur ce format d'url.
Le 095 renvoi une archive vide (Je n'ai pas tous vérifié)Le 30 et le 34
c'est OK.

Un analyseur de lien mort et de contenu ça pourrait être bien.

Voici les nouvelles URL pour le *RPG 2012* (pas d'URL statique pour le
moment):

   - https://www.data.gouv.fr/storage/f/2014-02-12T09-57-24/RPG_2012_001.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T13-26-51/RPG_2012_002.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T13-35-22/RPG_2012_003.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T13-42-17/RPG_2012_004.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T13-53-11/RPG_2012_005.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T13-57-27/RPG_2012_006.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-00-43/RPG_2012_007.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-03-51/RPG_2012_008.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-06-17/RPG_2012_009.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-08-32/RPG_2012_010.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-12-01/RPG_2012_011.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-30-50/RPG_2012_012.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-32-22/RPG_2012_013.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-36-39/RPG_2012_014.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-44-31/RPG_2012_015.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T14-55-38/RPG_2012_016.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T15-38-31/RPG_2012_017.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T15-42-30/RPG_2012_018.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T15-52-12/RPG_2012_019.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T13-28-03/RPG_2012_02A.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T13-29-20/RPG_2012_02B.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T15-57-55/RPG_2012_021.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-07-16/RPG_2012_022.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-13-37/RPG_2012_023.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-20-10/RPG_2012_024.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-24-24/RPG_2012_025.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-31-22/RPG_2012_026.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-35-21/RPG_2012_027.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-38-14/RPG_2012_028.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-46-26/RPG_2012_029.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-49-17/RPG_2012_030.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T16-53-43/RPG_2012_031.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T20-13-32/RPG_2012_032.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T20-18-58/RPG_2012_033.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T20-27-00/RPG_2012_034.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T20-35-52/RPG_2012_035.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T20-40-38/RPG_2012_036.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T20-44-52/RPG_2012_037.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T20-50-03/RPG_2012_038.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T21-47-49/RPG_2012_039.zip
   - https://www.data.gouv.fr/storage/f/2014-02-12T21-50-40/RPG_2012_040.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T12-07-09/RPG_2012_041.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T12-11-44/RPG_2012_042.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T12-19-12/RPG_2012_043.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T12-26-07/RPG_2012_044.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T13-02-01/RPG_2012_045.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T13-07-33/RPG_2012_046.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T13-15-51/RPG_2012_047.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T13-17-29/RPG_2012_048.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T13-19-35/RPG_2012_049.zip
   - https://www.data.gouv.fr/storage/f/2014-02-13T13-23-11/RPG_2012_050.zip
   - 

Re: [OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

[Denis Bigorgne]

Si on vise le wiki *francophone*, il me semble qu'on devrait se limiter à
la notion de marée de vives-eaux moyenne, valable aussi bien à Dunkerque
qu'à Dakar,  à Pointe à Pitre ou à Halifax, plutôt que de faire intervenir
le "coefficient", approximation de la marée de Brest, approximativement
applicable aux marées des côtes métropolitaine de la Manche et de
l'Atlantique. (cf le lien donné par Thomas Pétillon : définition SHOM du
coefficient de marée )


Le 8 février 2016 à 11:38, Plop76  a écrit :

> Thomas Petillon a écrit :
>
>> 2016-02-07 11:51 GMT+01:00 Plop76 :
>>
>> osm.sanspourr...@spamgourmet.com a écrit :
>>>
>>> Mais pour OSM c'est limite des marées hautes de vives-eaux de 70.
>>>


>>> Les marées de vives-eaux moyenne c'est 95 ("mean high water spring" en
>>> anglais). 70 ce n'est qu'une marée moyenne.
>>>
>>> D'après les wiki OSM, c'est sur la ligne des marées de coeff 95 que se
>>> trouve le trait de côte.
>>>
>>>
>> +1 sur le fait que ce que dit le wiki _n'est pas_ un coefficient de 70.
>>
>> D'après le wiki le way natural=coastline est sur la ligne de « mean high
>> water spring ».
>>
>> On peut trouver une définition de MHWS sur le site de la NOAA à l'adresse
>> http://shoreline.noaa.gov/glossary.html :
>>
>>> The average height of the high waters of the spring tides is called
>>>
>> spring high water or mean high water springs (MHWS)
>>
>> Et si l'on se réfère au SHOM (
>>
>> http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/
>> )
>>
>>>
>>> Par convention, le coefficient 100 est attribué au marnage semi-diurne
>>>
>> moyen lors des vives-eaux voisines des équinoxes (21 mars, 21septembre).
>> 
>> Les deux définitions concordant, le trait de côte dans OSM serait à caler
>> sur une marée (haute) de coefficient 100. (Et le wiki francophone à
>> corriger.)
>>
>
> Ce n'est pas exactement la même définition, le coeff 100 étant pour les
> marées de vives-eaux *proches des équinoxes* (2 fois par an) alors que le
> MHWS est la moyenne pour toutes les marées de vives-eaux (2 fois par mois).
>
> En se référant également au SHOM, cette moyenne correspond à un coeff 95 :
> http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/
>
> Je maintiens donc que, d'après le wiki anglais, c'est sur les marées
> hautes de coeff 95 qu'on doit placer le trait de côte sur OSM :)
>
>
>
> ___
> 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] Geofabrik downloads

[Francescu GAROBY]

Bonjour,
@Jean-Yvon : OSM montre le présent. Mais la façon d'extraire les données
n'a pas à se baser obligatoirement sur des choix politiques...
Mais si on veut des fichiers petits à télécharger et qui reflètent la
situation actuelle , pourquoi alors ne pas se tourner vers des découpages
départementaux ?

Francescu

Le 8 février 2016 à 14:32, Nicolas Moyroud  a écrit :

> Bonjour,
>
> J'exploite également les données geofabrik avec des scripts d'extractions
> de données. Je m'inquiétais justement du choix qui allait être fait à ce
> sujet concernant les fichiers geofabrik. Je suis aussi d'avis de conserver
> les anciens découpages qui sont beaucoup plus pratiques à exploiter. Je
> pense que mon extracteur aurait du mal à tenir la charge avec un territoire
> deux fois plus grand.
> Peut-être que fournir les deux découpages serait un bonne solution mais ça
> risque peut-être de faire beaucoup de fichiers de votre côté ?
> En tout cas merci à vous de solliciter l'avis des utilisateurs français de
> vos données.
>
> Nicolas
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Geofabrik downloads

[Nicolas Moyroud]

Bonjour,

J'exploite également les données geofabrik avec des scripts 
d'extractions de données. Je m'inquiétais justement du choix qui allait 
être fait à ce sujet concernant les fichiers geofabrik. Je suis aussi 
d'avis de conserver les anciens découpages qui sont beaucoup plus 
pratiques à exploiter. Je pense que mon extracteur aurait du mal à tenir 
la charge avec un territoire deux fois plus grand.
Peut-être que fournir les deux découpages serait un bonne solution mais 
ça risque peut-être de faire beaucoup de fichiers de votre côté ?
En tout cas merci à vous de solliciter l'avis des utilisateurs français 
de vos données.


Nicolas


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

Re: [OSM-talk-fr] Geofabrik downloads

[Nicolas Moyroud]

@Jean-Yvon : OSM montre le présent. Mais la façon d'extraire les 
données n'a pas à se baser obligatoirement sur des choix politiques...
Mais si on veut des fichiers petits à télécharger et qui reflètent la 
situation actuelle , pourquoi alors ne pas se tourner vers des 
découpages départementaux ?
Oui de toute façon il y a toujours moyen de s'en sortir à partir d'un 
fichier plus gros en commençant par une étape de découpage avec les 
anciennes limites régionales. Mais vu que la demande initiale semblait 
orientée vers le besoin des utilisateurs, j'ai juste exposé mon cas 
d'utilisation.


Nicolas

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

[OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Jean-Michel Pouré]

Bonsoir à tous,

En lisant des discussions sur la mailing list GPSd (le démon GPS de
GNU/Linux, projet initié par Eric S. Raymond), je me suis rendu compte
qu'il existait des GPS à correction d'erreur.

Par exemple, on peut adjoindre à un GPS un récepteur radio DGPS offrant
une précision jusqu'à 10 cm. Mais on peut recevoir certaines
informations par flux Internet.

Sous Android, j'ai installé RTK GPS, mais je ne sais pas comment cela
fonctionne. Avez-vous testé RTKlib et qu'est-ce que cela pourrait
apporter à OpenStreetMap ? J'adorerais descendre de 5 mètre à 1 mètre
de précision, le tout sur un smartphone ...

Votre avis concernant les technos de correction d'erreur ?

Cordialement,
Jean-Michel

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

[Thomas Petillon]

2016-02-08 11:38 GMT+01:00 Plop76 :

> Ce n'est pas exactement la même définition, le coeff 100 étant pour les
> marées de vives-eaux *proches des équinoxes* (2 fois par an) alors que le
> MHWS est la moyenne pour toutes les marées de vives-eaux (2 fois par mois).
>
> En se référant également au SHOM, cette moyenne correspond à un coeff 95 :
> http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/
>
> Je maintiens donc que, d'après le wiki anglais, c'est sur les marées
> hautes de coeff 95 qu'on doit placer le trait de côte sur OSM :)


Après relecture, on est d'accord. Je me suis trompé et ça correspond plutôt
au coeff de 95.


2016-02-08 12:02 GMT+01:00 Jérôme Seigneuret :

> Si c'est le cas, doit-on prendre ce trait de côte pour définir la limite
> communale ou on à deux traits... ducoup les plages entre deux coef sont sur
> quel territoire ou niveau territorial?
>

Jusqu'à présent on utilise le trait de côte comme limite communale. Il est
pas déconnant de continuer comme ça je pense. (La vraie réponse quant aux
limites communales en mer semble... compliquée ! cf.
http://www.gridauh.fr/fileadmin/gridauh/MEDIA/2011/compte_rendu_de_travaux/seminaire_thematique/ecriture_des_plu/LP%20PLU%20littoral%20Fiche1.pdf
)

Pour ce qui est des plages, d'après le wiki natural=beach couvre la partie
au-dessus de la ligne de côte. Pour l'estran natural=sand + tidal=yes. (cf.
http://wiki.openstreetmap.org/wiki/Key:tidal )


> Les eaux intérieur ça se tag comment?
> natural=water+ ...
>

À quelles eaux tu penses ? J'ai l'impression que ce qu'il reste est couvert
par les cas habituels (rivière, étang).


2016-02-08 16:21 GMT+01:00 Denis Bigorgne :

> Si on vise le wiki *francophone*, il me semble qu'on devrait se limiter à
> la notion de marée de vives-eaux moyenne, valable aussi bien à Dunkerque
> qu'à Dakar,  à Pointe à Pitre ou à Halifax, plutôt que de faire intervenir
> le "coefficient", approximation de la marée de Brest, approximativement
> applicable aux marées des côtes métropolitaine de la Manche et de
> l'Atlantique.
>

Autant donner les deux, ainsi que la correspondance, non ? (Si tant est
qu'on arrive à la déterminer de manière sûre.)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Doute sur le calage Bing/Cadastre

[Jean-Michel Pouré]

J'ai un très gros doute sur le calage ...

Sur les plans auquels j'ai collaboré, certaines rues sont calées sur
Bing et d'autres sont décalées. J'ai des doutes et je ne sais pas
comment corriger ces petits décalages.

Quand on pense aux futures applications de guidage et de conduire
automatique pour automobile ...

Est-ce qu'il existe une synthése concernant le calage sur le wiki ?

Par ailleurs, dans JOSM, il existe plusieurs plugins de calage. Existe-
t-il un modèle numérique pour caler de manière fiable et corriger tous
les petits défauts de l'imagerie satellite ? Quel plugin choisir ?

Cordialement,

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Jean-Michel Pouré]

J'ai trouvé plus d'informations ici :
https://fr.wikipedia.org/wiki/Cin%C3%A9matique_temps_r%C3%A9el

A priori on peut connecter à son smartphone Android un GPS traditionnel
en USB et descendre à la précision d'environ mètre. Les informations de
correction sont alors reçues via Internet.

Vous avez déjà testé ?

smime.p7s
Description: S/MIME cryptographic signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Remise en place de taginfo et live + Extinction de oapi-fr

[Jocelyn Jaubert]

Bonjour,

Suite aux soucis rencontrés régulièrement sur la machine osm3, il a été 
décidé de déplacer certains services, et d'en couper d'autres.


Les services déplacés, qui devraient maintenant être bien plus stables:

 - http://live.openstreetmap.fr - suivi en temps réel des contributions
 - http://taginfo.openstreetmap.fr - analyse des tags utilisés en 
France Métropolitaine
 - https://suivi.openstreetmap.fr - quelques informations sur les 
données OSM (communes et cours d'eau)

 - http://export.openstreetmap.fr - exports au format .shp

Concernant suivi et export, il est possible de rajouter des choses - on 
attend toute contribution !



Un service est supprimée, mais pourrait être remis en marche si il y a 
une demande:


 - http://oapi-fr.openstreetmap.fr - une instance Overpass API ne 
couvrant que la France Métropolitaine


Sachant qu'on héberge déjà une instance Overpass API monde, qui est 
utilisable pour faire des requêtes ciblées sur la France.



--
Jocelyn (et l'équipe tech d'osm-fr)

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

[OSM-talk-fr] Image of the week

[Eric Debeau]

Bonsoir

Pour infos, l'image de la semaine de OSM est française.

Il s'agit d'une photo de la fabrication d'une carte des routes de
Lannion-Tregor Communauté utilisant une découpeuse laser du FabLab de
Lannion.

L'image est mise en avant sur le wiki OSM:
http://wiki.openstreetmap.org/wiki/Main_Page

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

Re: [OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

[Thomas Petillon]

2016-02-08 20:48 GMT+01:00 :

> dans l'anglais il y a spring qu'il ne faut pas oublier.
>

 On a fait la même erreur j'ai l'impression. En fait « spring tide » est
l'équivalent anglais de marée de vive-eau, pas de marée d'équinoxe.

> These are called *spring tides*, a common historical term that has
nothing to do with the season of spring. Rather, the term is derived from
the concept of the tide "springing forth." Spring tides occur twice each
lunar month all year long, without regard to the season.

http://oceanservice.noaa.gov/facts/springtide.html
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

[osm . sanspourriel]

Bonjour,
en théorie je suis d'accord avec Denis (pas de wiki franco-français) 
sauf que les données d'Ifremer et du SHOM ne sont pas franco-françaises 
et que le coefficient de marée parle plus au Français moyen que la marée 
haute de la "marée de vives-eaux d'équinoxe" moyenne. Sinon on n'aurait 
pas discuté pour savoir si c'était 70, 95 ou 100.


Vous remarquerez qu'au vu des définitions du SHOM, du NOOA et du NTSLF 
(National Tidal and Sea Level Facility, l'équivalent britannique) j'ai 
légèrement changé les termes.


Un compromis me semble-t-il acceptable est de parler de *marée haute 
moyenne d'équinoxe* et de mettre un renvoi "*Soit en France un 
coefficient de marée de 100* avec la référence au lien passé par Thomas 
(http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/) 
."



Il me semble que ce n'est pas clair puisque certains parlent des marée 
moyennes d'équinoxe (ce qui correspond à la définition anglaise).


/On peut trouver une définition de MHWS sur le site de la NOAA à l'adresse//
http://shoreline.noaa.gov/glossary.html//://
///

   /The average height of the high waters of the spring tides is called//
   / 


/spring high water or mean high water springs (MHWS)//
/Et si on prend Wikipedia (pas forcément un référence) on trouve :

The *mean high water spring (MHWS)* is the highest level that spring 
tides  reach on the average 
over a period of time (often 19 years). The height of mean high water 
springs is the average throughout the year (when the average maximum 
declination  of the moon 
 is 23.5°) of two successive high 
waters  during those periods 
of 24 hours when the range of the tide is at its greatest.^[1] 



This level is generally close to being the "high water mark 
" where debris 
accumulates on the shore annually.


Cette définition de http://www.ntslf.org/tgi/definitions qui à bien lire 
est équivalent : la moyenne des marée d'équinoxe qui correspond bien à 
un coefficient de 100, et non à une "marée de vives-eaux moyenne" (qui 
serait la moyenne des marrées de coefficient supérieur à 70 et donc 
inférieur à la moyenne des marrées d'équinoxe) : dans l'anglais il y a 
spring qu'il ne faut pas oublier.


En espérant avoir éclaircit ce point, commentaires bienvenus (dont une 
formulation plus claire ?)

Jean-Yvon

Le 08/02/2016 16:21, Denis Bigorgne - denis.bigor...@gmail.com a écrit :
Si on vise le wiki *francophone*, il me semble qu'on devrait se 
limiter à la notion de marée de vives-eaux moyenne, valable aussi bien 
à Dunkerque qu'à Dakar, à Pointe à Pitre ou à Halifax, plutôt que de 
faire intervenir le "coefficient", approximation de la marée de Brest, 
approximativement applicable aux marées des côtes métropolitaine de la 
Manche et de l'Atlantique. (cf le lien donné par Thomas Pétillon : 
définition SHOM du coefficient de marée ) 



Le 8 février 2016 à 11:38, Plop76 > a écrit :


Thomas Petillon a écrit :

2016-02-07 11:51 GMT+01:00 Plop76 >:

osm.sanspourr...@spamgourmet.com
 a écrit :

Mais pour OSM c'est limite des marées hautes de vives-eaux
de 70.



Les marées de vives-eaux moyenne c'est 95 ("mean high
water spring" en
anglais). 70 ce n'est qu'une marée moyenne.

D'après les wiki OSM, c'est sur la ligne des marées de
coeff 95 que se
trouve le trait de côte.


+1 sur le fait que ce que dit le wiki _n'est pas_ un
coefficient de 70.

D'après le wiki le way natural=coastline est sur la ligne de «
mean high
water spring ».

On peut trouver une définition de MHWS sur le site de la NOAA
à l'adresse
http://shoreline.noaa.gov/glossary.html :

The average height of the high waters of the spring tides
is called

spring high water or mean high water springs (MHWS)

Et si l'on se réfère au SHOM (

http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/)


Par convention, le coefficient 100 est attribué au marnage
semi-diurne

moyen lors des vives-eaux voisines des équinoxes (21 mars,
21septembre).

Les deux définitions concordant, le trait de côte dans OSM
serait à caler
sur 

Re: [OSM-talk-fr] Remise en place de taginfo et live + Extinction de oapi-fr

[Jérôme Seigneuret]

Bonjour,

Il y a problème sur - https://suivi.openstreetmap.fr c'est la racine du
serveur http sans redirection vers le service. Du coup il y a justeIt works!

Coté page html contenu dans http://export.openstreetmap.fr

Il y a un problème d'encodage par défaut pour les OS Windows
A ajouter dans les pages HEADER.html sinon par défaut c'est du CP-1252


Bonne soirée
Jérôme

Le 8 février 2016 à 20:50, Jocelyn Jaubert  a
écrit :

> Bonjour,
>
> Suite aux soucis rencontrés régulièrement sur la machine osm3, il a été
> décidé de déplacer certains services, et d'en couper d'autres.
>
> Les services déplacés, qui devraient maintenant être bien plus stables:
>
>  - http://live.openstreetmap.fr - suivi en temps réel des contributions
>  - http://taginfo.openstreetmap.fr - analyse des tags utilisés en France
> Métropolitaine
>  - https://suivi.openstreetmap.fr - quelques informations sur les données
> OSM (communes et cours d'eau)
>  - http://export.openstreetmap.fr - exports au format .shp
>
> Concernant suivi et export, il est possible de rajouter des choses - on
> attend toute contribution !
>
>
> Un service est supprimée, mais pourrait être remis en marche si il y a une
> demande:
>
>  - http://oapi-fr.openstreetmap.fr - une instance Overpass API ne
> couvrant que la France Métropolitaine
>
> Sachant qu'on héberge déjà une instance Overpass API monde, qui est
> utilisable pour faire des requêtes ciblées sur la France.
>
>
> --
> Jocelyn (et l'équipe tech d'osm-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] Erosion du littoral : une cartographie des côtes françaises est disponible

[Jérôme Seigneuret]

>
>
> Pour ce qui est des plages, d'après le wiki natural=beach couvre la partie
> au-dessus de la ligne de côte. Pour l'estran natural=sand + tidal=yes. (cf.
> http://wiki.openstreetmap.org/wiki/Key:tidal )
>

Ca entre en conflit aussi avec *wetland*=tidalflat
 il me semble.


>
>
>> Les eaux intérieur ça se tag comment?
>> natural=water+ ...
>>
>
> À quelles eaux tu penses ? J'ai l'impression que ce qu'il reste est
> couvert par les cas habituels (rivière, étang).
>
>
Je parle des eau qui serait entre la limite choisi pour le costline et les
eaux restant derrière ce trait de cote si la limite administrative est
choisie sur un autre niveau de marée qui serait plus dans les terre

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

Re: [OSM-talk-fr] Erosion du littoral : une cartographie des côtes françaises est disponible

[osm . sanspourriel]

Pour le coefficient je me range aux arguments de Thomas et propose donc 
écrire dans le wiki :

marées hautes de vive-eau moyenne (*)

(*) Ce qui correspond en France à un coefficient de 95, 
http://www.shom.fr/les-activites/activites-scientifiques/maree-et-courants/marees/coefficient-de-maree/


Pour la question de Jérôme, non, les zones sableuses et les zones 
vaseuses sont distinctes.
La vase c'est plus fin et quand tu es tombe dedans tu comprends aussi 
que ça pue ;-).


Il est vrai que les bas de plages sont souvent vaseux, mais on n'est pas 
dans ce cas du côté de la limite de 95.


Les eaux intérieures ne sont pas ce à quoi tu penses (en fait si, mais 
la grosse différence ce n'est pas le niveau au niveau des "vraies" côtes 
mais au niveau des lignes virtuelles séparant la mer de l'estuaire).


En image :
http://imagico.de/map/pict/coast_bissau.png
O-ton : http://imagico.de/map/coastline_quality4_de.php
Et pour les anglophones : http://imagico.de/map/coastline_quality4_en.php

Ça fait par exemple que la Loire de Nantes à Saint-Nazaire n'est pas 
considérée comme maritime mais comme une eau intérieure 
.


Vous remarquez qu'en droit ils semblent vraiment parler de laisse de 
basse mer aussi étonnant que cela puisse paraitre.


Jean-Yvon

Le 08/02/2016 21:24, Jérôme Seigneuret - jseigneuret-...@yahoo.fr a écrit :



Pour ce qui est des plages, d'après le wiki natural=beach couvre
la partie au-dessus de la ligne de côte. Pour l'estran
natural=sand + tidal=yes. (cf.
http://wiki.openstreetmap.org/wiki/Key:tidal )


Ca entre en conflit aussi avec *wetland*=tidalflat 
 il me 
semble.


Les eaux intérieur ça se tag comment?
natural=water+ ...


À quelles eaux tu penses ? J'ai l'impression que ce qu'il reste
est couvert par les cas habituels (rivière, étang).

Je parle des eau qui serait entre la limite choisi pour le costline et 
les eaux restant derrière ce trait de cote si la limite administrative 
est choisie sur un autre niveau de marée qui serait plus dans les terre
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GPS à correction d'erreur / RTK GPS / RTKlib

[Stéphane Péneau]

Hello !

Je bidouille sur le sujet depuis quelque temps.
En réponse très rapide :

En dgps, je ne crois pas qu'on puisse descendre sous 1m de précision. Et 
même 1m, avec des récepteurs standard, je suis assez sceptique. Pour 
ceux qui reçoivent 2 bandes de fréquences (L1 et L2) pourquoi pas, mais 
c'est du professionnel.
C'est assez courant comme système dans les récepteurs de rando, mais pas 
dans les smartphones.
Perso, je bidouille avec un Navspark-gl que je connecte en bluetooth à 
mon smartphone en attendant d'en faire un logger autonome (stockage sur 
carte µSD) :

http://navspark.mybigcommerce.com/navspark-gl-arduino-compatible-development-board-with-gps-glonass/

En RTK, on peut arriver à quelques cm, mais les conditions sont bien 
plus drastiques :
Le principe de base est proche du dgps, mais on n'utilise pas seulement 
les données reçues depuis les satellites, mais la porteuse qui 
transporte ce signal. Il faut des récepteurs capables de récupérer les 
données brutes reçues depuis les satellites. On dit qu'ils sont 
compatibles "RAW". Ici, idem, les récepteurs travaillant sur plusieurs 
bandes de fréquences obtiennent de meilleurs résultats.


Et il faut 2 récepteurs pas trop éloignés (10km max pour les récepteurs 
L1). 1 qui est fixe (la base) et 1 qui est mobile (le rover).
La base dont idéalement on connait la position exacte transmet ses infos 
au rover qui va recalculer sa position.
Ce calcul peut être fait via la librairie RTKLIB qui est open source 
(sur ordi, smartphone), ou directement intégrée dans le récepteur.


On commence à trouver des récepteurs RAW sur 1 seule bande de fréquence, 
à pas trop cher. Par exemple le NS-HP que je teste en ce moment, et qui 
intègre une puce pour les calculs RTK (pas besoin de matériel externe) :

http://navspark.mybigcommerce.com/ns-hp-rtk-capable-gps-receiver/

Les restrictions sont qu'il faut recevoir environ 6 satellites en commun 
entre la base et le rover, avec un bon rapport signal/bruit, et qu'ils 
ne soient pas trop bas sur l'horizon. En utilisant uniquement le GPS, ce 
n'est pas toujours gagné, il faut vraiment de bonnes conditions.


Pour l'instant, j'ai un seul NS-HP, car pas trop les moyens financiers, 
et j'aimerais bien un modèle GPS+GLONASS et rêvons un peu, Galileo 
aussi. Ça existe déjà partiellement, le REACH de Emlid, mais on est dans 
les 500€ la paire.

http://www.emlid.com/reach/

Il existe d'autres solutions pour la station de base du système RTK, 
mais je ne vais pas m’étendre plus pour ce soir.


Stf

Le 08/02/2016 22:38, Jean-Michel Pouré a écrit :

J'ai trouvé plus d'informations ici :
https://fr.wikipedia.org/wiki/Cin%C3%A9matique_temps_r%C3%A9el

A priori on peut connecter à son smartphone Android un GPS traditionnel
en USB et descendre à la précision d'environ mètre. Les informations de
correction sont alors reçues via Internet.

Vous avez déjà testé ?


___
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