Re: [OSM-talk-fr] Image of the week

2016-02-09 Par sujet Philippe Verdy 
Dommage, la totalité des plages de cette zone est maintenant hors de la
ligne de côte, donc noyée en mer. Y compris le chemin tagué "GR 34" (qui
suit le haut d'une plage).

Personnellement je suis partisan d'avoir les plages coupées en deux par la
ligne de côte pour avoir une partie "à sec" (hors événements exceptionnels
qui de toute façon peuvent submerger non seulement les plages mais aussi
une partie des routes ou des ports et propriétés attenantes cadastrées), et
l'autre dans la zone "tidal" soumise au régime normal des marées.

Les zones exceptionnellement submersibles sont de toute façon bien plus
étendues que les zones "tidal" et doivent avoir une délimitation dans les
plans officiels de prévention des risques (submersion, zones inondables,
zones sismiques, terrain instable, risques d'effondrement d'anciennes mines
ou grottes sous-terraines naturelles, risques d'éboulement et couloirs
d'avalanche, volcanisme en outre-mer, dégagements gazeux du sol, eaux
toxiques, risques industriels permanents autour de certaines installations
en service ou désaffectées mais sous surveillance, pollution importante,
etc.)

Les risques possibles sont nombreux et la liste s'allonge chaque année au
point qu'une grande partie du territoire doit être dans une de ces zones à
risque (notamment pour le risque d'inondation qui touche une très grande
partie des terres habitées autour de nos nombreux cours d'eau).

Le risque de submersion exceptionnelle n'est finalement qu'un de ces
éléments, c'est assez mineur et il n'y a pas de raison de le privilégier
sur une carte. Une plage reste une plage la plus grande partie de l'année,
et la faire disparaître totalement sous les eaux est un peu abusif alors
qu'une bonne partie reste à sec et que c'est ce qu'on voit sur le terrain
(même à marée haute). On sait de toute façon qu'à certaines périodes les
plages sont moins accessibles mais on doit les situer et ces plages (ou
petites criques) ont un nom bien connu, bien visible (souvent fléché sur le
terrain), même si deux fois par jour elle est submergée pendant une heure
ou deux et qu'il ne reste que quelques rochers et le chemin ou l'escalier
qui y descend.


Donc pour moi une plage ne délimite pas la ligne de côte (ni le haut ni le
bas de la plage) :

- le haut de la plage est situé à la limite entre la zone sableuse (ou
galets) sans végétation et le terrain rocheux ou végétalisé (landes, voire
dunes, forêt) ou artificialisé (digue, rue/route/quai, immeubles).

- le bas est situé à la limite moyenne de basse mer (parfois plus haut si
en bas c'est en fait du rocher ou une vasière). Ce bas de plage devrait
être aussi le bas de la zone "tidal".

- entre les deux passe la ligne de côte (on en discute en ce moment: haute
eaux sur un coefficient à choisir). Cette ligne devrait être aussi le haut
de la zone "tidal".


Au delà de la plage passent:

- la ligne de base (le trait droit de loxodromie qui passe d'une pointe à
l'autre mais peut inclure des "eaux intérieures" dans les baies) qui
délimite les frontières administratives (boundary=administrative et
admin_level>=4) des collectivités ou administrations locales et leurs
groupements (communes, arrondissement, département, région, EPCI).

- la frontière administrative de la France (boundary=administrative et
admin_level=2, ou 3 pour la partie "France métropolitaine") à 12 miles
(environ) de cette ligne de base. Elle délimite aussi les "régions
maritimes" (mais pas les "régions" au sens des collectivités territoriales)
qui sont de la compétence des préfets et des autorités civiles et
militaires de l'Etat, mais pas des collectivités.


Le 8 février 2016 à 20:56, Eric Debeau  a écrit :

> 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
>
>
___
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

2016-02-09 Par sujet Jean-Michel Pouré 
Le mardi 09 février 2016 à 09:31 +0100, Stéphane Péneau a écrit :
> 2cm de précision, c'est du RTK, et ça ne fonctionnera pas avec ton 
> récepteur gnsss standard.
> Ensuite, comme je l'ai expliquée dans mon message d'hier soir, il
> faut 
> une base qui émette ses données brutes en temps réel. C'est un
> signal 
> RTCM, et s'il est diffusé via un réseau informatique (internet),
> c'est 
> du NTRIP.
> 
> Dans certains pays, on a accès gratuitement à tout un ensemble de
> bases. 
> Ce n'est pas le cas en France, où seule une petite douzaine de
> stations 
> du réseau EUREF fournissent leurs données en temps réel. Avec un 
> récepteur qui supporte le Raw uniquement en L1, il faut être à moins
> de 
> 10km.

OK, je comprends. Je suis à 30 km de la station de Creil. C'est
suffisant pour avoir une certaine précision, sans descendre à 2cm ?

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] Remise en place de taginfo et live + Extinction de oapi-fr

2016-02-09 Par sujet Jérôme Seigneuret 
Par contre il n'y a toujours rien sur  https://suivi.openstreetmap.fr


Le 9 février 2016 à 19:01, Philippe Verdy  a écrit :

> Il y a également un (ancien) problème concernant le serveur de tuiles
> français sur les requêtes de tuiles avec /dirty : pour certaines tuiles (en
> bas niveau de zoom), la page sensée donner un statut de la requête devrait
> être renvoyée en HTTPS mais la réponse n'est pas correctement encodée (elle
> est renvoyée sans l'encodage nécessaire), il semble que ce soit une
> redirection interne vers une page statique uniquement renvoyée en HTTP
> (cette page ignore totalement l'état de la session ayant demandé cette
> réponse).
>
> Bref la réponse n'est pas lisible et on a un échec de session HTTPS, la
> réponse ne s'affiche pas du tout (on n'a même pas de statut HTTP standard,
> même pas un HTTP 400 ou 500, c'est carrément une violation de protocole).
>
> Si on veut renvoyer une réponse statique non sécurisée il faut d'abord
> répondre à la requête HTTPS avec une réponse sécurisée de redirection
> ("HTTP/1.1 301 Moved Permanently" et "Location: http://;) vers une
> autre page HTTP, et c'est le navigateur qui alors ira lire cette autre page
> en suivant la redirection indiquée mais en faisant sa requête en HTTP et
> non dans la même session HTTPS.
>
> Ressource utile:
>
> https://sites.google.com/site/onlyvalidation/page/301-redirect-https-to-http-on-apache-server
>
> Peut-être que je ne suis pas assez clair. Mais ce problème est là depuis
> que le serveur de tuiles est passé (partiellement) en HTTPS.
>
> Cependant je ne vois pas tellement l'intérêt d'avoir presque tout en HTTPS
> sauf certaines pages statiques en HTTP.
>
>
> Le 8 février 2016 à 21:11, Jérôme Seigneuret  a
> écrit :
>
>> 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
>>
>>
>
> ___
> 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] Remise en place de taginfo et live + Extinction de oapi-fr

2016-02-09 Par sujet Jérôme Seigneuret 
Ok, comme mentionné par @Philippe c'est l'url *https *qui est à rediriger
vers du *http. *J'avais raté cette subtilité... Du coup c'est l'index.html
d'Apache qui est retournée.

Bonne soirée
Jérôme

Le 9 février 2016 à 19:41, Jérôme Seigneuret  a
écrit :

> Par contre il n'y a toujours rien sur  https://suivi.openstreetmap.fr
>
>
> Le 9 février 2016 à 19:01, Philippe Verdy  a écrit :
>
>> Il y a également un (ancien) problème concernant le serveur de tuiles
>> français sur les requêtes de tuiles avec /dirty : pour certaines tuiles (en
>> bas niveau de zoom), la page sensée donner un statut de la requête devrait
>> être renvoyée en HTTPS mais la réponse n'est pas correctement encodée (elle
>> est renvoyée sans l'encodage nécessaire), il semble que ce soit une
>> redirection interne vers une page statique uniquement renvoyée en HTTP
>> (cette page ignore totalement l'état de la session ayant demandé cette
>> réponse).
>>
>> Bref la réponse n'est pas lisible et on a un échec de session HTTPS, la
>> réponse ne s'affiche pas du tout (on n'a même pas de statut HTTP standard,
>> même pas un HTTP 400 ou 500, c'est carrément une violation de protocole).
>>
>> Si on veut renvoyer une réponse statique non sécurisée il faut d'abord
>> répondre à la requête HTTPS avec une réponse sécurisée de redirection
>> ("HTTP/1.1 301 Moved Permanently" et "Location: http://;) vers une
>> autre page HTTP, et c'est le navigateur qui alors ira lire cette autre page
>> en suivant la redirection indiquée mais en faisant sa requête en HTTP et
>> non dans la même session HTTPS.
>>
>> Ressource utile:
>>
>> https://sites.google.com/site/onlyvalidation/page/301-redirect-https-to-http-on-apache-server
>>
>> Peut-être que je ne suis pas assez clair. Mais ce problème est là depuis
>> que le serveur de tuiles est passé (partiellement) en HTTPS.
>>
>> Cependant je ne vois pas tellement l'intérêt d'avoir presque tout en
>> HTTPS sauf certaines pages statiques en HTTP.
>>
>>
>> Le 8 février 2016 à 21:11, Jérôme Seigneuret 
>> a écrit :
>>
>>> 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
>>>
>>>
>>
>> ___
>> 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] GPS à correction d'erreur / RTK GPS / RTKlib

2016-02-09 Par sujet Jean-Michel Pouré 
Le mardi 09 février 2016 à 09:31 +0100, Stéphane Péneau a écrit :
> Dans certains pays, on a accès gratuitement à tout un ensemble de
> bases. 
> Ce n'est pas le cas en France, où seule une petite douzaine de
> stations 
> du réseau EUREF fournissent leurs données en temps réel. Avec un 
> récepteur qui supporte le Raw uniquement en L1, il faut être à moins
> de 
> 10km.
> Il existe des réseaux avec un maillage plus serré, et qui savent
> créer 
> des stations de base "virtuelles" proches du Rover. Il s'agit des 
> réseaux Orpheons et Terria, mais l'accès est payant.

Je dispose de quelques machines embarquées et de serveurs récents. Quel
matériel me faut-il pour démarrer une station NTRIP ? La fonction
émission radio ne m'intéresse pas. Quelle puce de suivi satellite me
conseillez-vous ?

J'ai lu dans la documentation EUREF qu'il fallait un accès à la
totalité du ciel et qu'on devait utiliser un matériel à auto-calibrage. 
RTKlib peut-il faire l'affaire ?

Ici les photos de la station de Creil :

http://www.epncb.oma.be/_networkdata/pictures/stationpictures.php?stati
on=CREI_10016M001

La matériel à mettre en oeuvre n'a pas l'air phénoménal et j'ai
l'impression qu'une installation comprenant matériel embarqué, câble
réseau, puce de réception ne doit pas coûter très cher en DIY. A la
limite, on peut imaginer un matériel PoE à placer sur le toit.

Qu'est-ce que vous en pensez ? N'est-ce pas le type de projet qu'une
communauté devrait gérer ?

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

2016-02-09 Par sujet Ab_fab 
Bonjour,

RTKGPS, ou RTKGPS+ sur Google Play intègrent RTKlib (et toute sa complexité
de paramétrage !)

Effectivement, des données de correction sont émises par des stations
terrestres, mais ...
... ce n'est pas courant d'avoir un accès libre (gratuit) à des données de
correction en temps réel, et surtout à moins de 10 km de sa zone de relevés.

Dès lors, deux options :
_ Monter sa propre base, avec un deuxième récepteur GPS "raw"
_ Faire les corrections à postériori. Car en général, on peut récupérer les
infos de correction via le site http://rgp.ign.fr/

Bonne journée


Le 9 février 2016 à 08:26, Jean-Michel Pouré  a écrit :

> 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
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
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

2016-02-09 Par sujet Stéphane Péneau 

Le 09/02/2016 08:26, Jean-Michel Pouré a écrit :
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


2cm de précision, c'est du RTK, et ça ne fonctionnera pas avec ton 
récepteur gnsss standard.
Ensuite, comme je l'ai expliquée dans mon message d'hier soir, il faut 
une base qui émette ses données brutes en temps réel. C'est un signal 
RTCM, et s'il est diffusé via un réseau informatique (internet), c'est 
du NTRIP.


Dans certains pays, on a accès gratuitement à tout un ensemble de bases. 
Ce n'est pas le cas en France, où seule une petite douzaine de stations 
du réseau EUREF fournissent leurs données en temps réel. Avec un 
récepteur qui supporte le Raw uniquement en L1, il faut être à moins de 
10km.


Il existe des réseaux avec un maillage plus serré, et qui savent créer 
des stations de base "virtuelles" proches du Rover. Il s'agit des 
réseaux Orpheons et Terria, mais l'accès est payant.


Stf

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

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

2016-02-09 Par sujet Jocelyn Jaubert 
Bonjour,

On Mon, Feb 08, 2016 at 09:11:57PM +0100, Jérôme Seigneuret wrote:
> 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!

Effectivement, il y avait un souci. C'est maintenant corrigé.


> 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
> 

Là, je ne vois pas vraiment le souci. Ça reste de l'ascii standard, donc ça
devrait passer avec cet encoding CP-1252 aussi.

Je ne sais pas trop comment forcer les pages d'index automatiquement générées
par Apache en UTF-8. Une idée ?

-- 
Jocelyn



> 
> 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


___
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

2016-02-09 Par sujet Stéphane Péneau 

Hello Ab_fab,

Le 09/02/2016 09:00, Ab_fab a écrit :
_ Faire les corrections à postériori. Car en général, on peut 
récupérer les infos de correction via le site http://rgp.ign.fr/


Tu connais des tutos ou explications diverses sur le post processing 
depuis les données du rgp ? J'ai tenté plusieurs fois de mon côté, et je 
ne m'en sors pas vraiment.


Stf

___
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

2016-02-09 Par sujet Ab_fab 
Malheureusement non.
J'avais essayé le logiciel Rinexpresso sous Windows pour obtenir un fichier
Rinex, mais le post-traitement était compliqué à comprendre ... et je n'ai
pas persévéré


Le 9 février 2016 à 09:34, Stéphane Péneau  a
écrit :

> Hello Ab_fab,
>
> Le 09/02/2016 09:00, Ab_fab a écrit :
>
>> _ Faire les corrections à postériori. Car en général, on peut récupérer
>> les infos de correction via le site http://rgp.ign.fr/
>>
>
> Tu connais des tutos ou explications diverses sur le post processing
> depuis les données du rgp ? J'ai tenté plusieurs fois de mon côté, et je ne
> m'en sors pas vraiment.
>
> Stf
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
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

2016-02-09 Par sujet Tyndare 
Je ne sais pas ce qu'elle vaut dans ce coin mais en cas de doutes de callage 
j'ai tendance à faire confiance à la couche des traces Strava (en désactivant 
le zoom automatique dans JOSM pour zoomer plus que le fond qu'ils rendent 
disponible, et en affichant la couche plusieurs fois si il y a peu de points 
pour les rendre plus visibles) 



Le 8 février 2016 21:16:31 GMT+01:00, "Jean-Michel Pouré"  a 
écrit :
>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,
>
>
>
>___
>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] Remise en place de taginfo et live + Extinction de oapi-fr

2016-02-09 Par sujet sly (sylvain letuffe) 
Jocelyn Jaubert wrote
> Là, je ne vois pas vraiment le souci. Ça reste de l'ascii standard, donc
> ça
> devrait passer avec cet encoding CP-1252 aussi.
> 
> Je ne sais pas trop comment forcer les pages d'index automatiquement
> générées
> par Apache en UTF-8. Une idée ?

Voilà qui est réparé. J'avais renommé le dossier et j'avais oublié de mettre
à jour dans la config la partie qui indique :
AddDefaultCharset utf-8





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n5.nabble.com/Remise-en-place-de-taginfo-et-live-Extinction-de-oapi-fr-tp5867054p5867156.html
Sent from the France mailing list archive at Nabble.com.

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

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

2016-02-09 Par sujet Jérôme Seigneuret 
super ;-)

Le 9 février 2016 à 14:37, sly (sylvain letuffe)  a
écrit :

> Jocelyn Jaubert wrote
> > Là, je ne vois pas vraiment le souci. Ça reste de l'ascii standard, donc
> > ça
> > devrait passer avec cet encoding CP-1252 aussi.
> >
> > Je ne sais pas trop comment forcer les pages d'index automatiquement
> > générées
> > par Apache en UTF-8. Une idée ?
>
> Voilà qui est réparé. J'avais renommé le dossier et j'avais oublié de
> mettre
> à jour dans la config la partie qui indique :
> AddDefaultCharset utf-8
>
>
>
>
>
> -
> --
> sly, contact direct : sylvain /a\ letuffe o r g
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Remise-en-place-de-taginfo-et-live-Extinction-de-oapi-fr-tp5867054p5867156.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

2016-02-09 Par sujet Thomas Petillon 
2016-02-09 8:13 GMT+01:00 Philippe Verdy :

> 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)
>

La ligne de base et la ligne de côte sur laquelle on met le
natural=coastline sont deux lignes différentes.

La ligne de base est légèrement au large de la ligne de côte (ou au même
niveau au plus haut). C'est une ligne administrative. Elle peut servir de
limite pour les boundary=administrative, mais n'est pas la limite de la mer
au sens physique. (Et peut même correspondre à une ligne où la mer ne
descend jamais aussi bas.)

> La ligne de base est normalement constituée par la laisse de basse mer
 (limite des zones
toujours couvertes par la mer quelle que soit la marée, en l'absence de
phénomènes météo-océanographiques exceptionnels) ; dans certains cas
(présence d'îles proches du littoral, côte très découpée…), la laisse de
basse mer (« ligne de base normale ») peut être remplacée par une *ligne de
base droite*, composée de segments, ne s'écartant pas de la direction
générale de la côte et joignant des points situés sur la laisse de basse
mer.
(https://fr.wikipedia.org/wiki/Ligne_de_base )

La ligne de côte lui est là où s'arrête la mer en tant qu'entité physique
(au sens OSM, une fois un niveau de marée fixé). Les eaux portuaires sont
comprises dans la mer et sont à l'extérieur du natural=coastline. On le
voit par exemple sur le trait de côté de l'Histolitt, sur lequel les
contours portuaires sont visibles. Donc à mon sens il n'y a pas besoin de
taguer les eaux intérieures avec un tag décrivant une entité physique
(natural=coastline, natural=water, etc.), elles font partie de l'océan
autant que la haute mer.

Reste après la question de la fixation de la limite précise entre rivière
et mer dans le cas d'un estuaire soumis à la marée.
___
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

2016-02-09 Par sujet Stéphane Péneau 

Le 09/02/2016 20:17, Jean-Michel Pouré a écrit :
OK, je comprends. Je suis à 30 km de la station de Creil. C'est 
suffisant pour avoir une certaine précision, sans descendre à 2cm ?


Je ne peux pas te répondre, il faut essayer. Ce sera forcément beaucoup 
plus problématique en zone urbaine, à cause de l'effet "canyon" (les 
immeubles qui bloquent une partie des satellites et génèrent des rebonds).


Le 09/02/2016 21:30, Jean-Michel Pouré a écrit :

Je dispose de quelques machines embarquées et de serveurs récents. Quel
matériel me faut-il pour démarrer une station NTRIP ? La fonction
émission radio ne m'intéresse pas. Quelle puce de suivi satellite me
conseillez-vous ?

J'ai lu dans la documentation EUREF qu'il fallait un accès à la
totalité du ciel et qu'on devait utiliser un matériel à auto-calibrage.
RTKlib peut-il faire l'affaire ?
Je ne connais que très peu les spécifications minimum pour une station 
Ntrip "officielle", mais il me semble que la précision de l'horloge est 
primordiale, ainsi que la qualité de l'antenne de réception et sa 
calibration.
Tous ces paramètres sont un peu moins cruciaux lorsqu'on se crée sa 
propre station de base personnelle.


En récepteur, je ne m'y connais pas énormément. Je sais que les 
u-blox.com sont assez régulièrement utilisés pour le diy. Perso je suis 
chez Navspark. Pour en faire des stations de base, il faut qu'ils 
fournissent les données RAW.
Il doit exister des softs open source pour la conversion 
RAW->RTCM->NTRIP mais je ne me suis pas trop penché sur le sujet pour le 
moment. En revanche, notre cher Ratzilla$ bosse sur le sujet, il en 
parle un peu sur son twitter :

https://twitter.com/RatZillaS



La matériel à mettre en oeuvre n'a pas l'air phénoménal et j'ai
l'impression qu'une installation comprenant matériel embarqué, câble
réseau, puce de réception ne doit pas coûter très cher en DIY. A la
limite, on peut imaginer un matériel PoE à placer sur le toit.

Qu'est-ce que vous en pensez ? N'est-ce pas le type de projet qu'une
communauté devrait gérer ?
Oui, ce serait très intéressant. Et il existe déjà des communautés qui 
le font : les agriculteurs, particulièrement ceux qui cultivent de 
grandes surfaces, comme les céréaliers. Mais leurs réseaux de stations 
ne sont en général pas ouverts.


Pour un accès libre à tous, il y a un début de projet :
http://pylongps.com/doku.php

En tout cas, si tu avances sur le sujet, n'hésite pas à partager.

Stf

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

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

2016-02-09 Par sujet Philippe Verdy 
Le 8 février 2016 à 11:47, Jérôme Seigneuret  a
écrit :

> @Philippe: en effet, utiliser JOSM en 64x doit aider à charger le shape
> car j'atteins la limite de la mémoire.
>

Un truc : quand on utilise JOSM avec JNLP et Javaws (ce que je recommande
au lieu de télécharger le JAR, car ça fait la mise à jour automatiquement à
chaque lancement), il crée un raccourci sur le bureau. Mais ce raccourci
appelé "JOSM" est écrasé à chaque mise à jour pour le lancer ensuite en 32
bits.

Personnellement, j'ai renommé ce raccourci sur le bureau en "JOSM 64" afin
qu'il ne soit plus écrasé. Et ensuite j'ai modifié les paramètres pour
forcer le mode 64 bits :
"C:\*Program Files*\Java\jre1.8.0_66\bin\javaws.exe" au lieu de "C:\*Program
Files (x86)*\Java\jre1.8.0_66\bin\javaws.exe" (pour le mode 32 bits)
avant les autres paramètres (inchangés) du fichier JNLP et du cache, et
d'autres options éventuelles qu'on peut mettre pour "tuner" la VM Java
("-Xmx" etc.)

Si je mets à jour Java (32 bits ou 64 bits séparément), il faut remettre à
jour aussi le chemin de javaws avec le numéro de version installé (ici
"jre1.8.0_66").
___
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

2016-02-09 Par sujet Philippe Verdy 
Le 8 février 2016 à 21:16, Jean-Michel Pouré  a écrit :

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

Avant que ça arrive, ce ne sera autorisé que dans les zones où les
concepteurs des dispositifs qu'ils feront agréer auront fait les efforts de
calage de leur cartographie. Pour ça ils devront nécessairement mettre en
oeuvre un MNT précis.
Peu de chance que ça arrive pour l'instant dans les zones à fort relief. Au
mieux ça commencera par des autorisations seulement dans certaines villes
et hors de ces zones la conduite manuelle sera obligatoire. Il faudra
certainement aussi une signalisation radio pour activer ces dispositifs
automatiques (sans doute par téléphonie cellulaire), les autorités pouvant
alors couper ce signal zone par zone pour forcer la conduite manuelle en
cas d'urgence (accidents, incendies, inondations, forte tempête,
manifestations sur la voie publique, forts encombrements...)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Image of the week

2016-02-09 Par sujet osm . sanspourriel 
Tu veux dire le chemin E9 dont certains ont déposé pour la partie 
française GR 34 ? ;-).

Elles sont effectivement là en dehors de la terre ferme, c'est un fait.
Le problème ici n'est pas tant tidal=sand ou beach mais l'absence de tag 
qui fait penser à la pleine mer.
Très clairement là, le chemin passe sur un endroit recouvert d'eau à 
marée haute ordinaire.


Enfin le vrai problème c'est que l'on ne fait pas respecter la servitude 
littorale mais c'est un autre sujet.


N. B. : concrètement, est-ce que tu penses :
http://mc.bbbike.org/mc/?lon=-3.505597=48.825301=18=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=limite%20de%20la%20plage%20?
Ça ne me choque pas mais la différence c'est plus natural=sand au dessus 
(d'un point de vue altimétrique, au sud ici) et au nord c'est plutôt de 
la vase.
Ne mettre que beach dans la partie de coef supérieur à 100 va minimiser 
les plages, certes.
Mais que le piéton sache qu'il peut être coincé par la marée me semble 
plutôt une précision utile. Pas sûr que le trait de côte suffise.

Mettrais-tu un tidal=yes ?

Alors près du lieu de vacances d'Antoine (pour ceux qui ont suivi) :
http://mc.bbbike.org/mc/?lon=-4.430902=48.231103=18=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=passage%20du%20sentier%20:%20tidal%20:%20yes 



La carte y est plus précise.
Que voit-on :
- osm fr : les sols marins sont massacrés (la mer envahit tout y compris 
les beach).

- osm : le gué (fjord=yes) est rendu comme un chemin ordinaire.

Dézoomons au niveau 15 :
http://mc.bbbike.org/mc/?lon=-4.436395=48.22783=16=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=rocher%20visible%20par%20coef%20proche%20de%20100

Vous voyez un rocher visible par coef proche de 100 (non mappé) et une 
plage qui correspond grosso-modo à la mi-marée.

Au-delà il faudrait du tidal=yes sur l'essentiel de la partie sableuse.

Thomas dit ce que dit le wiki.
Tu veux aller au delà.

À quel niveau arrêter la plage ? Mi-marée ? Si tu prends autre chose que 
la ligne de côte c'est à peu près tout ce que tu peux faire de 
vérifiable. Mais quel intérêt ? L'isobathe du 0 terrestre ?

Avec la ligne de côte tu vois s'il reste du sable à marée haute.

Attention aussi au collage :
http://mc.bbbike.org/mc/?lon=-4.449497=48.23543=17=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100?marker=schiste
Entre le trait de côte et la plage on ici (comme souvent) une falaise ou 
une ancienne falaise rabotée. Donc tidal=yes


 * natural=bare_rock
   

Sinon on a l'impression que la plage commence en mer.

Et si tu regarde Wikipédia la plage commence au niveau des dunes, peut 
être composée de galets : c'est juste une accumulation de matériaux en 
pente douce ! : https://fr.wikipedia.org/wiki/Plage
tidal=yes, natural=sand est clair. natural 
 beach 
 ne 
l'est pas autant.
Sur OSM ils disent 
 : 
Coastal beaches should be mapped to high water (natural 
=coastline 
) sans 
préciser de quel côté !
Et que natural=sand serait réservé à ce qui n'est pas plages. Heu ? Les 
déserts 
Car hormis un banc de sable (et encore il y a des bancs de sable 
 
utilisés comme plage) potentiellement tidal=yes et natural=sand => 
beach. Que l'homme puisse y accéder ne change pas grand chose.


Ceux qui auront cliqué sur le lien auront vu la subtilité : l'embouchure 
de la Laïta est une riverbank en amont de la coastline, donc on voit la 
plage


Ici le armchair mapping a créé des landes en lieu et place des dunes. 
Mais en regardant les tags disponibles, ça ne semble pas si mauvais.


Jean-Yvon

Le 09/02/2016 20:02, Philippe Verdy - verd...@wanadoo.fr a écrit :
Dommage, la totalité des plages de cette zone est maintenant hors de 
la ligne de côte, donc noyée en mer. Y compris le chemin tagué "GR 34" 
(qui suit le haut d'une plage).


Personnellement je suis partisan d'avoir les plages coupées en deux 
par la ligne de côte pour avoir une partie "à sec" (hors événements 
exceptionnels qui de toute façon peuvent submerger non seulement les 
plages mais aussi une partie des routes ou des ports et propriétés 
attenantes cadastrées), et l'autre dans la zone "tidal" soumise au 
régime normal des marées.


___
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

2016-02-09 Par sujet osm . sanspourriel 
À 80% d'accord avec Thomas et à 20% avec Philippe sachant qu'ils sont 
proches on devrait y arriver.


OK avec Thomas sur la définition de la ligne de base.
> Et peut même correspondre à une ligne où la mer ne descend jamais 
aussi bas
c'est même assez usuel sur les zones qui s'érodent : la limite 
administrative ne bouge pas/peu alors que le littoral peut bouger tous 
les jours.


/La ligne de côte lui est là où s'arrête la mer en tant qu'entité 
physique (au sens OSM, une fois un niveau de marée fixé). Les eaux 
portuaires sont comprises dans la mer et sont à l'extérieur du 
natural=coastline. On le voit par exemple sur le trait de côté de 
l'Histolitt, sur lequel les contours portuaires sont visibles. Donc à 
mon sens il n'y a pas besoin de taguer les eaux intérieures avec un tag 
décrivant une entité physique (natural=coastline, natural=water, etc.), 
elles font partie de l'océan autant que la haute mer./
C'est là que je ne suis plus d'accord avec Thomas. Il y a une semaine 
j'étais d'accord (d'où la remarque sur le pont de Saint-Nazaire).


On peut conserver le système proposé par Thomas (avec le problème de la 
limite des embouchures mais ça on l'aura toujours).
Mais la version de Philippe suit la tendance actuelle qui consiste à 
dégager les eaux intérieures avec le gros inconvénient que les eaux 
intérieures ne sont pas taguées telles quelles. Du coup le trait de côte 
ressemble plus à une érosion de la ligne de base. Voir mon message 
d'hier sur le sujet et surtout le lien :
/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//

/
Si on regarde le trait de côté Histolitt, il connaît grosso-modo les l
Au fait sur http://data.shom.fr/#donnees/catalogue, il y a Marée => 
Marnage coefficient 95, et comme je disais sur 
http://cartelie.application.developpement-durable.gouv.fr/cartelie/voir.do?carte=Tables_Physiographiques_131212=CEREMA#
Il y a la "géomorphologie du trait de côte" et on voit ici que l'anse du 
Bas-Pouldu dans l'embouchure de la Laïta 
 
est considérée comme en mer et non en eaux intérieures. En amont du port 
de Guidel, ce sont des eaux intérieures.


Perso, j'aurais tendance à cartographier comme Thomas, mais Philippe est 
plus proche du wiki.
Sauf que dans ce cas manque un tag (tidal=yes ? sauf qu'au centre ça ne 
découvre pas).
internal_waters=yes ? Attention, c'est tout ce qui est en deçà de la 
ligne de base.
Ce n'est pas pour rien que Christoph (imagico.de) a fait la proposition 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement


Sur le rendu OSM Mapnik 
http://mc.bbbike.org/mc/?lon=-3.286824=47.733365=11=3=mapbox-satellite=osmfr=mapnik=ol_mapquest-labels=100
la rade de Lorient est plus visible que la ria d'Etel mais ça peut aller 
jusqu'à supprimer les eaux "intérieures" de la carte pour les contours 
utilisant le trait de côte comme MapQuest labels.


Une indication des eaux à l'intérieur du trait de côte mais soumis à 
l'influence de la marée serait dans ce cas utile.

Avis complémentaires bienvenus.

Jean-Yvon

Le 09/02/2016 22:15, Thomas Petillon - tpetil...@gmail.com a écrit :
2016-02-09 8:13 GMT+01:00 Philippe Verdy >:


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)




Reste après la question de la fixation de la limite précise entre 
rivière et mer dans le cas d'un estuaire soumis à la marée.





___
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

2016-02-09 Par sujet Philippe Verdy 
Le 9 février 2016 à 22:15, Thomas Petillon  a écrit :

> 2016-02-09 8:13 GMT+01:00 Philippe Verdy :
>
>> 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)
>>
>
> La ligne de base et la ligne de côte sur laquelle on met le
> natural=coastline sont deux lignes différentes.
>

Je n'ai PAS écrit que c'était la même chose (regarde un message précédent).
J'ai juste écrit ce qu'était les "eaux intérieures" (toutes les eaux à
l'intérieur de la ligne de base), je n'ai rien dit ci-dessus dans la phrase
que tu cites concernant la "ligne de côte" d'OSM.

Bref on est déjà d'accord, mais ne me fais pas dire ce qui n'est pas écrit.

Evidemment les eaux intérieures seront alors les eaux entre la ligne de
côte et la ligne de base (mais en fait un peu plus, car dans OSM on a aussi
des estuaires coupés par la ligne de côte (là on n'a pas d'élement
phyhsique, c'est un trait arbitraire juste là parce qu'il faut bien couper
quelquepart pour fermer les zones. De toute façon, attenant à ces traits
arbitraires, on aura des "riverbank" (sur un rendu comme celui de Mapnik
pour OSM.org ou le rendu d'OSM France, on ne voit pas la différence).

Mais il est préférable autant que possible de choisir ce trait arbitraire
(pour la "costline" d'OSM) à une position raisonnable :

- le dernier barrage (y compris une "barrière anti-sel" qui est un
dispositif passif de porte basculante, où les eaux fluviales tendent à
l'abaisser si leur pression est supérieure à celle des eaux marines qui
remontent sous les eaux fluviales et tendent à remonter cette porte) est
bien une ligne physique de séparation des eaux (sauf s'il est trop loin
dans les terres et que la mer ne remonte pas jusque là) ;

- pour le dernier pont ce n'est pas toujours le cas car l'influence des
marées peut se faire sentir au delà (si c'est le cas je pense qu'il vaut
mieux remonter la coasline plus haut sur le fleuve, afin que la zone
"tidal" soit entièrement du côté mer de la coastline, quitte alors à
utiliser le dernier pont uniquement comme limite administrative, avec
admin_level=4.)


Certaines données pourraient être utilisées pour que ce trait de côte soit
moins arbitraire (notamment celles sur les mesures de salinité moyenne, ou
des données sur les espèces marines protégées) si on n'a ni barrage ni de
barrière anti-sel.

Par exemple l'estuaire de la Gironde qui me semble coupé beaucoup trop
arbitrairement par la "coastline" d'OSM, et je ne pense même pas que c'est
une limite administrative réelle car il n'y a là ni pont ni barrage là où
elle est et les distances entre les points de côte sont trop grandes : le
domaine maritime doit en fait occuper la majeure partie sinon la totalité
de la Gironde, et sans doûte même une partie de ses deux principaux fleuves
(Dordogne et Garonne). D'ailleurs même le cadastre (pourtant très grossier)
des communes limitrophe de l'estuaire de la Gironde ne rend pas ces
communes limitrophes à travers l'estuaire (les polygones du cadastre
cependant incluent les zones portuaires dans l'estuaire, sans entrer dans
trop de détails, ainsi que les digues de protection des rives et pontons ou
embarcadères).

Ce trait de côte arbitraire cependant vient couper deux "îles" (en fait des
hauts fonds sableux, au contour changeant selon les saisons), qui pour moi
sont malgré tout des "îles" maritimes et non fluviales, même si leur
existence est liée à l'accumulation locale d'alluvions venus principalement
des fleuves de l'estuaire (mais une partie du sable vient aussi des côtes
atlantiques des Landes et un peu aussi de Charente-Maritime). Ces bancs de
la Gironde sont AMHA à traiter de la même manière que les bancs de sable
près de la baie d'Arcachon.

En revanche la ligne de base qui traverse la Gironde est une ligne
administrative effective (mais pas une ligne de côte pour autant).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Académies...

2016-02-09 Par sujet Christian Quest 
J'ai rajouté les limites des académies et les nouvelles zones pour les
vacances scolaires...

Je n'ai rien trouvé d'existant en terme de tags, à part 2
boundary=educational

Cela donne:
type=boundary
boundary=educational
boundary_type:FR=Circonscription académique
holiday_zone=A/B/C
name=Académie de XXX

Si vous avez mieux à proposer n'hésitez pas.

J'ai aussi mis à jour la pauvre relation type=defaults de la Zone A et
créé celles des zones B et C.

Il existe depuis le 1/1/2016 la notion de "Région académique", qui sont
les regroupements des circonscriptions académiques de chacune des
nouvelles régions.

Accès overpass: http://overpass-turbo.eu/s/ejb

Et un export en shapefile est disponible:
http://osm13.openstreetmap.fr/~cquest/openfla/export/academies-20160209-shp.zip

-- 
Christian Quest - OpenStreetMap France


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

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

2016-02-09 Par sujet Philippe Verdy 
Il y a également un (ancien) problème concernant le serveur de tuiles
français sur les requêtes de tuiles avec /dirty : pour certaines tuiles (en
bas niveau de zoom), la page sensée donner un statut de la requête devrait
être renvoyée en HTTPS mais la réponse n'est pas correctement encodée (elle
est renvoyée sans l'encodage nécessaire), il semble que ce soit une
redirection interne vers une page statique uniquement renvoyée en HTTP
(cette page ignore totalement l'état de la session ayant demandé cette
réponse).

Bref la réponse n'est pas lisible et on a un échec de session HTTPS, la
réponse ne s'affiche pas du tout (on n'a même pas de statut HTTP standard,
même pas un HTTP 400 ou 500, c'est carrément une violation de protocole).

Si on veut renvoyer une réponse statique non sécurisée il faut d'abord
répondre à la requête HTTPS avec une réponse sécurisée de redirection
("HTTP/1.1 301 Moved Permanently" et "Location: http://;) vers une
autre page HTTP, et c'est le navigateur qui alors ira lire cette autre page
en suivant la redirection indiquée mais en faisant sa requête en HTTP et
non dans la même session HTTPS.

Ressource utile:
https://sites.google.com/site/onlyvalidation/page/301-redirect-https-to-http-on-apache-server

Peut-être que je ne suis pas assez clair. Mais ce problème est là depuis
que le serveur de tuiles est passé (partiellement) en HTTPS.

Cependant je ne vois pas tellement l'intérêt d'avoir presque tout en HTTPS
sauf certaines pages statiques en HTTP.


Le 8 février 2016 à 21:11, Jérôme Seigneuret  a
écrit :

> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr