Re: [OSM-talk-fr] Bornes incendie : base de données

[Jérôme Seigneuret]

Bonjour, rien au national. C'est gérer par antenne et chacun choisi les
bases et les outils qu'il veut comme pour les référentiels communaux.
Certains proposent l'info d'autres pas. On a fait un travail sur l'agglo de
Nîmes mais ces eux qui nous ont fourni des données et on se tape l'analyse
qualité et le terrain pour vérifier la véracité et la précision des
données. A+

Le sam. 24 mars 2018 11:10 PM, deuzeffe  a écrit :

> Le 24/03/2018 à 18:47, Guillaume Largeau a écrit :
> > Bonjour,
> >
> > Selon les permis de construire (industries, extension de lotissement,
> > ...) le service prévision/prévention du SDIS est interrogé pour savoir
> > si la ressource pour la lutte contre les feux est en adéquation avec la
> > demande. Si ce n’est pas le cas, un avis de création de poteau ou autre
> > réserve d’eau est fait.
>
> Oui, pas mal des nouveaux lotissements qui poussent autour de chez moi
> possèdent des "Réserves pompiers", avec mention de la capacité, en plus
> ! (sans compter les bassins de rétention pour éviter les inondations...)
>
> « Bêtement », je pensais que l'existence de tel équipement, même à usage
> réservé, faisait l'objet d'une base de données nationales (y a bien la
> base des équipements sportifs, donc, bon). Je ne sais pas si la
> cartographie des bornes/bouches/réservoir pompier a déjà été proposée
> comme Projet du mois...
>
> --
> deuzeffe - qui va se balader à la recherche des petits êtres rouges locaux
>
> ___
> 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 - Support HTTPS

[marc marc]

Je ne sais pas quoi penser de ce ticket..
2 exemples :

tms.cadastre.openstreetmap.fr est mis en status 200 car le proxy 
supporte le https
j'ai même fait un commit pour migrer en https en me basant sur ce 
résultat... mais non le certificat est bien valide mais le prox ne gère 
pas la demande en http vers l'upstream
https://tms.cadastre.openstreetmap.fr/*/tout/22/2124425/1442952.png
ticket https://github.com/osm-fr/infrastructure/issues/26

data.loire-atlantique.fr [302 Moved Temporarily]:
en effet https://data.loire-atlantique.fr redirige vers 
http://data.loire-atlantique.fr
il voudrait qu'on fasse quoi Dirk ?
j'ai répondu dans le ticket josm pour le manque de test

Le 24. 03. 18 à 18:02, Pierre Béland a écrit :
> Dirk Stöcker a ouvert un ticket pour lister les divers liens josm 
> (styles, imagerie, etc) non encore convertis au protocole https. J'y 
> vois plusieurs liens en France.
> https://josm.openstreetmap.de/ticket/16123
> 
> Pierre
> 
> 
> - Message transféré -
> *De :* Dirk Stöcker 
> *À :* "josm-...@openstreetmap.org" 
> *Envoyé :* samedi 24 mars 2018 10 h 58 min 36 s HAE
> *Objet :* Support HTTPS
> 
> Hello,
> 
> for some years we are step by step migrating JOSM to https. Many others
> are doing the same, so the https usage is increasing a lot everyday.
> 
> Now JOSM server is completely https itself and in the last weeks also
> external resources like maps, styles, plugins, rules, presets step by step
> have been migrated. There are still some hundred links not using https,
> but many hundreds have been fixed already.
> 
> To get rid of the remaining ones I created a ticket:
> https://josm.openstreetmap.de/ticket/16123
> 
> This contains a list of servers, which answer on port 443, but links are
> still in http. Servers who not answer on port 443 are not included!
> 
> Please help fixing these entries!
> 
> 1) Some entries may simply be fixed by switching the link (e.g. these
> with 200 OK message).
>    a) If in the wiki simply fix it (and test it!)
>    b) If external inform the author and document it in the ticket
> 
> 2) Some are broken server setups
>    a) If an openstreetmap service please inform the authors to fix it and
> document this in the ticket
>    b) If not OSM and you know the contacts, ask them friendly to fix it and
> document what you did in the ticket
>    c) Otherwise only document the server state in the ticket for later
> checks
> 
> Ciao
> -- 
> http://www.dstoecker.eu/ (PGP key available)
> 
> 
> 
> ___
> 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] Bornes incendie : base de données

[deuzeffe]

Le 24/03/2018 à 18:47, Guillaume Largeau a écrit :

Bonjour,

Selon les permis de construire (industries, extension de lotissement, 
...) le service prévision/prévention du SDIS est interrogé pour savoir 
si la ressource pour la lutte contre les feux est en adéquation avec la 
demande. Si ce n’est pas le cas, un avis de création de poteau ou autre 
réserve d’eau est fait.


Oui, pas mal des nouveaux lotissements qui poussent autour de chez moi 
possèdent des "Réserves pompiers", avec mention de la capacité, en plus 
! (sans compter les bassins de rétention pour éviter les inondations...)


« Bêtement », je pensais que l'existence de tel équipement, même à usage 
réservé, faisait l'objet d'une base de données nationales (y a bien la 
base des équipements sportifs, donc, bon). Je ne sais pas si la 
cartographie des bornes/bouches/réservoir pompier a déjà été proposée 
comme Projet du mois...


--
deuzeffe - qui va se balader à la recherche des petits êtres rouges locaux

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

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[Denis Bigorgne]

Le 24 mars 2018 à 18:01, marc marc  a écrit :

>
> pour pile <> accu <> interne <> externe :
> de ce que j'ai compris ceux qui font du trek préfère un appareil
> sans fil donc pile intégré.
> Pour d'autre raccorder un pack lithium à l'usage
> est-ce réaliste d'avoir 2 boîtiers (pile interne <> pack externe usb)
> ou cela complique la chose vu le volume modeste attendu ?
>

Non, un appareil avec un emplacement pour y mettre ou bien un accu,
ou bien des piles. On peut amener en plus un  stock d'accus ou de piles,
ad lib.

Par exemple, une frontale LED Lenser SEO 7R




> ___
> 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] Bornes incendie : base de données

[Philippe Verdy]

Comme il faut un raccordement, et un controle du débit, du fonctionnement,
et des fuites, le services des eaux devrait être compétent et posséder
cette information, si cela vient de lui. En revanche si c'est seulement une
réserve (faute de raccordement au réseau public), je ne pense pas qu'il
s'occupe de contrôler l'alimentation (mais la collectivité peut imposer la
pose d'un compteur d'eau pour les puisages, et je pense que c'est même
obligatoire maintenant dans nombre de régions, mais l'état des pompes n'est
pas à la charge de la collectivité mais du résident qui ne fait que les
déclarer pour que les compteurs soient ensuite certifiés et scellés et que
soit installé aussi un instrument de mesure des hauteurs d'eau dans les
puits).
Je ne pense pas que ces déclarations privées en mairie soient du domaine
public, même si la ressource (l'eau puisée) l'est (et soumise aux décisions
administratives de restriction d'usage), et les contrôles de qualité des
eaux (frais des labos agréés) sont à la charge des propriétaires.

Les SDIS doivent donc disposer d'un accès aux données des mairies, ou bien
les mairies vont déléguer totalement la gestion de ces données à l'agence
de bassin locale. Je ne sais pas ce qu'il en est des réserves d'eau privées
(toutes les piscines et tous les bassins de rétention agricoles sont-ils
tous déclarés ou soumis à permis de construire...).

Quant aux pompes installées, je ne pense pas que les pompiers comptent
beaucoup dessus, ils amènent leurs propres pompes dans leurs véhicules
d'intervention; mêmes les points d'eau installé "pressurisés" peuvent avoir
un débit/une pression insuffisante et ils peuvent faire un "tirage forcé"
en branchant leurs pompes dessus pour monter le débit (même si ça coupe
l'eau dans tout le voisinage) !

J'ai déjà vu une intervention de pompiers pas loin de chez moi alors en
région parisienne complètement purger les canalisations, et ne plus avoir
d'eau du tout pendant plus d'une journée, ils avaient du pomper fort dans
le réseau public ! Ca gargouillait dans les tuyaux et la première eau qui
est revenue après cette purge forcée était peu ragoutante, juste bonne pour
la chasse d'eau des toilettes ou faire le ménage, et même pas pour laver le
linge correctement et la pression était assez faible. En revanche plusieurs
jours après, l'eau n'avait jamais été aussi limpide (mais elle avait été
plus fortement traitée en amont) et la pression revenue était plus forte
qu'avant: comme quoi le service des eaux tient compte de ces interventions
et sont prévenus et ces purges forcées peuvent avoir un effet bénéfique
aussi sur le réseau de distribution (bien que je pense que ça peut aussi
faire des dégâts et de nouvelles fuites).

Le 24 mars 2018 à 18:47, Guillaume Largeau  a
écrit :

> Bonjour,
>
> Selon les permis de construire (industries, extension de lotissement, ...)
> le service prévision/prévention du SDIS est interrogé pour savoir si la
> ressource pour la lutte contre les feux est en adéquation avec la demande.
> Si ce n’est pas le cas, un avis de création de poteau ou autre réserve
> d’eau est fait.
> Les contrôles (débits/fonctionnement) sont à la charge du service des eaux
> en lien avec la mairie. Certains SDIS font seulement un contrôle visuel.
>
> Le sam. 24 mars 2018 à 18:35, Philippe Verdy  a
> écrit :
>
>> Est-ce bien les SDIS qui gèrent ces données ? Ne sont-ils pas juste
>> informés lors des visites de conformité des installations quand elles sont
>> requises par la loi pour certains types d'établissements ou certains
>> aménagements résidentiels, et sinon soumis au bon vouloir des occupants
>> pour les remettre en conformité en cas de dégradation ? Qui fait les
>> contrôles ? Est-ce purement déclaratif (sous les responsabilité engagée des
>> résidents locaux qui le font ou ne le font pas) ? Si c'est installé sur
>> "le" domaine public, quelle collectivité en a la charge d'entretien ?
>>
>> Au final j'ai peu que même les SDIS n'en ont pas une vision complète et
>> qu'en pratique ils se fient juste à ce qu'ils peuvent voir installé sur le
>> terrain et à leur expérience, et sur le fait que la loi leur donne un droit
>> d'accès à tout point d'eau qui peut les intéresser (à la collectivité
>> ensuite de prendre en charge les frais, tels que les factures d'eau que les
>> résidents vont leur réclamer si les pompiers entre dans une propriété et
>> viennent pomper l'eau dans leur piscine ou vident une réserve d'eau
>> agricole). Les collectivités elles-mêmes doivent être couvertes par des
>> assurances publiques ou privées, pour prendre en charge ces frais qu'on va
>> leur réclamer (par les résidents eux-mêmes, ou par délégation leurs propres
>> assureurs), ou pourront utiliser les fonds exceptionnellement accordés par
>> l'Etat aux collectivités dans les arrêtés ou décrets de classement des
>> catastrophes.
>>
>> Au final il n'y a sans doute pas de base unique, la donnée doit exister
>> et est accessible aux 

Re: [OSM-talk-fr] Bornes incendie : base de données

[Guillaume Largeau]

Bonjour,

Selon les permis de construire (industries, extension de lotissement, ...)
le service prévision/prévention du SDIS est interrogé pour savoir si la
ressource pour la lutte contre les feux est en adéquation avec la demande.
Si ce n’est pas le cas, un avis de création de poteau ou autre réserve
d’eau est fait.
Les contrôles (débits/fonctionnement) sont à la charge du service des eaux
en lien avec la mairie. Certains SDIS font seulement un contrôle visuel.

Le sam. 24 mars 2018 à 18:35, Philippe Verdy  a écrit :

> Est-ce bien les SDIS qui gèrent ces données ? Ne sont-ils pas juste
> informés lors des visites de conformité des installations quand elles sont
> requises par la loi pour certains types d'établissements ou certains
> aménagements résidentiels, et sinon soumis au bon vouloir des occupants
> pour les remettre en conformité en cas de dégradation ? Qui fait les
> contrôles ? Est-ce purement déclaratif (sous les responsabilité engagée des
> résidents locaux qui le font ou ne le font pas) ? Si c'est installé sur
> "le" domaine public, quelle collectivité en a la charge d'entretien ?
>
> Au final j'ai peu que même les SDIS n'en ont pas une vision complète et
> qu'en pratique ils se fient juste à ce qu'ils peuvent voir installé sur le
> terrain et à leur expérience, et sur le fait que la loi leur donne un droit
> d'accès à tout point d'eau qui peut les intéresser (à la collectivité
> ensuite de prendre en charge les frais, tels que les factures d'eau que les
> résidents vont leur réclamer si les pompiers entre dans une propriété et
> viennent pomper l'eau dans leur piscine ou vident une réserve d'eau
> agricole). Les collectivités elles-mêmes doivent être couvertes par des
> assurances publiques ou privées, pour prendre en charge ces frais qu'on va
> leur réclamer (par les résidents eux-mêmes, ou par délégation leurs propres
> assureurs), ou pourront utiliser les fonds exceptionnellement accordés par
> l'Etat aux collectivités dans les arrêtés ou décrets de classement des
> catastrophes.
>
> Au final il n'y a sans doute pas de base unique, la donnée doit exister et
> est accessible aux SDIS mais pas nécessairement ouverte à tous si aucune
> loi ne l'impose. On peut supposer que ce à quoi ont accès les SDIS, et les
> permissions que leur accorde la loi est suffisant pour leur permettre
> d'intervenir efficacement sans avoir à se soucier eux-mêmes des coûts
> générés par leurs interventions (d'autant que même les assurances privées
> ont aussi intérêt à ce que ces services fonctionnent bien, pour limiter
> l'impact financier des dommages: elles doivent abonder à un fond de la même
> façon qu'elles investissent aussi dans les systèmes et campagnes de
> prévention des risques, car c'est en fin de compte rapidement et
> globalement "rentable" pour elles).
>
> Le 24 mars 2018 à 18:14, deuzeffe  a écrit :
>
>> Bonjour tout le monde,
>>
>> J'ai comme l'impression qu'à part aller sur le terrain ou éventuellement
>> s'adresser au SDIS local, il n'y a pas moyen d'avoir une liste/DB de toutes
>> les bornes/bouches d'incendie présentes sur une collectivité territoriale
>> donnée.
>>
>> J'ai mal cherché ou bien ?
>>
>> --
>> deuzeffe
>>
>> ___
>> 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] Bornes incendie : base de données

[Philippe Verdy]

Est-ce bien les SDIS qui gèrent ces données ? Ne sont-ils pas juste
informés lors des visites de conformité des installations quand elles sont
requises par la loi pour certains types d'établissements ou certains
aménagements résidentiels, et sinon soumis au bon vouloir des occupants
pour les remettre en conformité en cas de dégradation ? Qui fait les
contrôles ? Est-ce purement déclaratif (sous les responsabilité engagée des
résidents locaux qui le font ou ne le font pas) ? Si c'est installé sur
"le" domaine public, quelle collectivité en a la charge d'entretien ?

Au final j'ai peu que même les SDIS n'en ont pas une vision complète et
qu'en pratique ils se fient juste à ce qu'ils peuvent voir installé sur le
terrain et à leur expérience, et sur le fait que la loi leur donne un droit
d'accès à tout point d'eau qui peut les intéresser (à la collectivité
ensuite de prendre en charge les frais, tels que les factures d'eau que les
résidents vont leur réclamer si les pompiers entre dans une propriété et
viennent pomper l'eau dans leur piscine ou vident une réserve d'eau
agricole). Les collectivités elles-mêmes doivent être couvertes par des
assurances publiques ou privées, pour prendre en charge ces frais qu'on va
leur réclamer (par les résidents eux-mêmes, ou par délégation leurs propres
assureurs), ou pourront utiliser les fonds exceptionnellement accordés par
l'Etat aux collectivités dans les arrêtés ou décrets de classement des
catastrophes.

Au final il n'y a sans doute pas de base unique, la donnée doit exister et
est accessible aux SDIS mais pas nécessairement ouverte à tous si aucune
loi ne l'impose. On peut supposer que ce à quoi ont accès les SDIS, et les
permissions que leur accorde la loi est suffisant pour leur permettre
d'intervenir efficacement sans avoir à se soucier eux-mêmes des coûts
générés par leurs interventions (d'autant que même les assurances privées
ont aussi intérêt à ce que ces services fonctionnent bien, pour limiter
l'impact financier des dommages: elles doivent abonder à un fond de la même
façon qu'elles investissent aussi dans les systèmes et campagnes de
prévention des risques, car c'est en fin de compte rapidement et
globalement "rentable" pour elles).

Le 24 mars 2018 à 18:14, deuzeffe  a écrit :

> Bonjour tout le monde,
>
> J'ai comme l'impression qu'à part aller sur le terrain ou éventuellement
> s'adresser au SDIS local, il n'y a pas moyen d'avoir une liste/DB de toutes
> les bornes/bouches d'incendie présentes sur une collectivité territoriale
> donnée.
>
> J'ai mal cherché ou bien ?
>
> --
> deuzeffe
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Bornes incendie : base de données

[deuzeffe]

Bonjour tout le monde,

J'ai comme l'impression qu'à part aller sur le terrain ou éventuellement 
s'adresser au SDIS local, il n'y a pas moyen d'avoir une liste/DB de 
toutes les bornes/bouches d'incendie présentes sur une collectivité 
territoriale donnée.


J'ai mal cherché ou bien ?

--
deuzeffe

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

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[pepilepi...@ovh.fr]

Le 22/03/2018 à 16:05, Stéphane Péneau a écrit :
> [...]
> Et maintenant j'ai besoin de toi cher lecteur :
>
> 1) Ca t'intéresse ? Tu es prêt à mettre un peu d'argent pour faire des
> belles traces GPS ? Heu non, des belles traces
> Galileo/Gps/Glonass/Beidou ?
> Alors dis-le, car il faudra être un certain nombre pour que ça soit
> possible.

Oui.

Et en fonction de l'ambition du projet il y a des sites comme
https://www.kickstarter.com/ ou https://fr.ulule.com/ qui permettent de
faire appel à un investissement participatif.

Bonne soirée,

JP

>
> 2) Est-ce que tu préfères utiliser une antenne integrée ou externe ?
> Une antenne externe magnétique, sur le toit de la voiture, sur ta
> casquette, ça marche beaucoup beaucoup mieux.
>
> 3) J'imagine que tu veux qu'il fasse enregistreur autonome, c'est
> prévu. Mais sur quelle durée souhaites-tu pouvoir le faire ?
>
> 4) De quelle autonomie as-tu besoin ? 6h ? 12h? 24h ? plus ?
>
> 5) Est-ce que tu poserais quelques limites sur l'encombrement, le poids ?
>
> 6) Autre chose ?
>
>
> A bientôt
>
> Stéphane
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



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

[OSM-talk-fr] JOSM - Support HTTPS

[Pierre Béland]

Dirk Stöcker a ouvert un ticket pour lister les divers liens josm (styles, 
imagerie, etc) non encore convertis au protocole https. J'y vois plusieurs 
liens en France.
https://josm.openstreetmap.de/ticket/16123
 
Pierre 
 

   - Message transféré - De : Dirk Stöcker 
À : "josm-...@openstreetmap.org" 
Envoyé : samedi 24 mars 2018 10 h 58 min 36 s 
HAEObjet : Support HTTPS
 Hello,

for some years we are step by step migrating JOSM to https. Many others 
are doing the same, so the https usage is increasing a lot everyday.

Now JOSM server is completely https itself and in the last weeks also 
external resources like maps, styles, plugins, rules, presets step by step 
have been migrated. There are still some hundred links not using https, 
but many hundreds have been fixed already.

To get rid of the remaining ones I created a ticket:
https://josm.openstreetmap.de/ticket/16123

This contains a list of servers, which answer on port 443, but links are 
still in http. Servers who not answer on port 443 are not included!

Please help fixing these entries!

1) Some entries may simply be fixed by switching the link (e.g. these 
with 200 OK message).
  a) If in the wiki simply fix it (and test it!)
  b) If external inform the author and document it in the ticket

2) Some are broken server setups
  a) If an openstreetmap service please inform the authors to fix it and 
document this in the ticket
  b) If not OSM and you know the contacts, ask them friendly to fix it and 
document what you did in the ticket
  c) Otherwise only document the server state in the ticket for later 
checks

Ciao
-- 
http://www.dstoecker.eu/ (PGP key available)

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

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[marc marc]

Histoire d'être utile pour Stéphane, il pourrait être utile d'être 
concis, parce que je doute qu'il ai envie de lire 4x3 pages par jour 
pour trouver la ligne applicable au projet.
Ou alors une page wiki histoire de classer cela par point et renvoyer
le blabla sur la page discussion ?

pour pile <> accu <> interne <> externe :
de ce que j'ai compris ceux qui font du trek préfère un appareil
sans fil donc pile intégré.
Pour d'autre raccorder un pack lithium à l'usage
est-ce réaliste d'avoir 2 boîtiers (pile interne <> pack externe usb)
ou cela complique la chose vu le volume modeste attendu ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[Philippe Verdy]

Le 24 mars 2018 à 17:18,  a écrit :

> Bonjour les Stéphane et les autres,
>
> SP : *Je ne connais aucun satellite GNSS multi-constellation.*
> Moi non plus, mais dans la doc de SatStat
> , ils le disent bien
> explicitement et ce ne sont pas des Mickeys :
>
> *Red is GPS, though nowadays most devices also support GLONASS and/or
> Beidou. Those hybrid chips report all of these systems as extra GPS
> satellites, thus you get multiple systems under one provider.*
>

La citation en question parle surtout de la possibilité technique de faire
de tels satellites avec des composants hybrides et donc de pouvoir
bénéficier de certaines coopérations pour les lancements futurs, afin que
finalement un certain nombre de satellites puissent servir à tout le monde.
Cela me semble documenter les composants électroniques, pas les satellites
ou constellations elles-mêmes qui font leurs propres choix. Il est naturel
qu'un fondeur de composants électronique cherche à vendre à tout le monde
et ne se ferme pas un marché potentiel (ceci dit la citation ci-dessus na
parle même pas encore de Galiléo qui a trop traîné pendant des décennies et
commence à peine à fonctionner un peu alors que plusieurs de ses satellites
sont déjà hors services, et c'était avant même que GLONASS et Beidou se
lancent et deviennent rapidement opérationnels pour leur zones de
couverture initiale maintenant étendue au monde, et probablement on aura
bientôt une autre constellation indienne voire indo-mexico-brésilienne: les
consortiums gérant GPS, Galileo et GLONASS commencent déjà à s'entendre
entre eux et devraient donc pouvoir lancer des satellites hybrides pouvant
servir au secours de l'une ou l'autre constellation en cas de panne d'un de
leur satellite: je doute que les satellites fonctionneront réellement en
hybride mais ils pourraient passer de l'un à l'autre).

Peut-être que la nouvelle agence d'Elon Musk va vouloir se lancer dans le
marché et lancer des satellites hybrides qu'il pourra louer à la demande,
au plus offrant à l'un ou l'autre des consortiums, le temps de monter alors
sa propre constellation et finalement de la mettre sur le marché. Les
sociétés privées se lancent dans l'espace là où les agences spatiales
nationales officielles ont de moins en moins de moyens et prennent des
retards sérieux dans tous leurs projets.

On peut s'attendre donc à la concurrence dans l'espace. Alors où sont ces
satellites multiconstellation ?

Peut-être qu'il y en a déjà mais qu'il sont seulement en phase d'évaluation
avec juste une ou deux unités et pas encore opérationnels sur les réseaux
commercialisés. Et que cela pourra intéresser des pays qui n'ont pas les
moyens de développer leur propre agence spatiale pour les lancements mais
voudraient pouvoir participer sans avoir à choisir ou en utilisant une
plateforme neutre permettant de choisir à tout moment les fournisseurs et
d'en changer, ou de pouvoir reconvertir aussi des satellites initialement
lancés pour d'autres missions courtes en satellites GNSS pouvant servir à
l'un ou l'autre des systèmes (au plus offrant...)

Note ce n'est pas moi qui ai lancé cette idée de leur existence : elle est
peut-être possible, mais pas encore réalisée.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[osm . sanspourriel]

Bonjour les Stéphane et les autres,

 

> Est-il possible, et simple, d'ajouter une centrale inertielle pour mémoriser ces portions de parcours "hors ciel", et améliorer la précision des traces depuis un point de départ connu précisément ?

Si je propose d'utiliser le téléphone c'est notament parce qu'il y a des capteurs qui existent dedans.

Faire un "petit" développement spécifique embarqué c'est déjà du boulot, si on ajoute des centrales intertielles et tutti quanti ça permet d'améliorer, tout comme capter le signal de satellites basse orbite ou les Wifi, mais je pense (et suis prêt à me tromper) qu'il vaut mieux que le récepteur ne fasse que du RTK (voir même pas puisque selon Stéphane P. ça ne pose pas de soucis de transférer les données brutes au téléphone) et transmette des trames NMEA et qu'une appli sur le téléphone utilise ce flux et d'autres flux afin de compléter les données manquantes (fusion de sources).

Si le récepteur peut profiter de SBAS (EGNOS), c'est bien car ça tourne autour du flux GNSS. Pour ce qui est des autres sources, je laisserai ça plutôt à d'autres applis (style AvNav). grosso-modo, on prend en théorie ce que peut donner NMEA. En pratique, je laisse Stéphane dire ce qu'il observe !

Dans un téléphone un tant soit peu moderne on a plus de capteurs, de puissance et de logiciels libres que dans un récepteur fait par quelques passionnés. Et des applis comme SmartNavi le font déjà.

 

Attention : quand je parlais d'AvNav je parlais de l'appli Rasberry Pi et Android (licence MIT), un moteur de recherche favorise l'appli payante qui se trouve sur le magasins d'appli de la maison mère du moteur de recherche... Je n'ai pas beaucoup de temps libre ces temps-ci (douce litote) mais si besoin je peux traduire, le schéma lui est directement compréhensible (et sur Github les échanges sont en anglais).

 


Le 24/03/2018 à 03:21, osm.sanspourr...@spamgourmet.com a écrit :


En fait un codage pas trop con c’est plus compact : date et position absolues puis en relatif avec encodage en Z.


SP: L'inconvénient d'un codage particulier, c'est qu'il faudrait une appli spécifique pour récupérer quelque chose d'exploitable. Alors qu'un simple fichier nmea sera réutilisable facilement.
On peut imaginer enregistrer directement en Gpx pour économiser de l'espace, mais on perd des informations.
La fréquence des points, (jusqu'à 10hz) est à adapter en fonction de l'utilisation.
Pas faux, mais je pensais à la compression sur le récepteur (et décompression), donc pas de soucis, les trames peuvent être passées au monde extérieur en NMEA standard.

Par contre je pense que c'est compatible avec une compression classique style zip, à condition qu'il soit possible d'avoir de la négociation entre le téléphone et le récepteur.  A minima de configurer le GPS.

Si tu a un codage particulier et tu fournis le décodeur en bibliothèque _javascript_, à peu près n'importe appli pourra être adaptée, maintenant pouvoir configuer le récepteur pour passer uniquement du brave NMEA c'est un plus.

La configuration serait possible depuis un PC/téléphone ou il faudrait flasher le GPS ? Le premier cas serait plus simple.

 


Certains satellites sont multi-constellation donc ça n’enrichit pas toujours autant qu’espéré (en plus des rq de Philippe).


SP : Je ne connais aucun satellite GNSS multi-constellation.

Moi non plus, mais dans la doc de SatStat, ils le disent bien explicitement et ce ne sont pas des Mickeys :

Red is GPS, though nowadays most devices also support GLONASS and/or Beidou. Those hybrid chips report all of these systems as extra GPS satellites, thus you get multiple systems under one provider. 

 


 
Quel intérêt d’avoir en plus un Rasberry-Pi ? Ne pas avoir de câble entre le récepteur et le téléphone ? Car les données brutes doivent être difficile à faire passer.



> Non, ça va, je l'ai fait de nombreuses fois.

> Le raspberry à d'autres inconvénients :

Que n'ont pas les téléphones.

Pour l'horodatage, le GPS fournit normalement une bonne source et on peut imposer l'heure du GPS à un système Linux ou Windows, je ne sais si c'est ainsi que tu fais.

 

À propos d'horodatage : le changement heure d'été/heure d'hiver, on s'en fiche un peu. D'arbord Pierre vous dira que pour lui c'était il y a deux semaines, moi il y a une semaine, d'autres jamais. Un GPS travaille normalement en TUC (UTC/GMT). C'est la présentation qui se fait en heure locale. De même dans l'EXIF ça doit être du TUC. Ne pas le faire c'est arriver à des pb sans nom. J'ai vu deux téléphones Android du même fabricant mais sur des réseaux français différents se caler en itinérance (même réseau à l'étranger) l'un correctement l'autre faire le décalage dans le mauvais sens !

 

Une heure de décalage par an, c'est à la fois énorme mais ça fait environ 1/1000, 4 s sur 10 h. Dans ton cas, si tu t'arrêtes 4 s pour prendre la photo, ce n'est pas critique, sinon tu passes en GPX et tu utilises un tableur pour faire une transformation affine et remet en 

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[Philippe Verdy]

Pour les batiments c'est assez compliqué de gérer des capteurs alors qu'on
a certianement des moyens facile d'estimer les formes générales (on peut y
circuler) et même d'avoir des mesures par des moyens simples (un petit
mètre laser portable) pour vérifier les longueurs effectives. On travaille
sur plans classiques (tout en reconnaissant les limites du fait qu'on est
sur du terrain privé et qu'on ne peut le faire sans accord du propriétaire
et des résidents).

Pour le reste c'est du côté des clubs de spéléo qu'il faut aller avec leur
matériel adéquat aux mesures souterraines (ils utilisent des émetteurs
radar, de la magnétométrie qu'on peut détecter en surface malgré des
distortions importantes).
C'est tellement particulier (et sur le terrain ils chercheront des
instruments adaptés à chaque situation pour évaluer ce qui peut être le
plus précis ou convenable à leurs besoins) que c'est indépendant des GPS.
De plus ce n'est pas pour cartographier ce qu'on met dans OSM car ce n'est
pas un terrain "grand public" où on peut s'aventurer seul et sans
équipement et formation.

Le 24 mars 2018 à 13:40,  a écrit :

> Bonjour,
>
> Il y a quelques temps je suis trouvé confronté à la difficulté
> d'enregistrer une trace dans un tunnel, ou un bâtiment, ou une grotte !
> Est-il possible, et simple, d'ajouter une centrale inertielle pour
> mémoriser ces portions de parcours "hors ciel", et améliorer la précision
> des traces depuis un point de départ connu précisément ?
>
> Si ma demande est trop exotique, n'en tenez pas compte !
> Merci en tout cas d'avoir lancé cette idée de logger performant. Des
> fablabs pourraient aussi être intéressés à poursuivre ce projet sous
> licence libre.
>
> Longue vie à toutes vos contributions
> Christian (osm sur Lyon)
>
> --
> *De: *"Stéphane Péneau" 
> *À: *"Discussions sur OSM en français" 
> *Envoyé: *Jeudi 22 Mars 2018 16:05:20
> *Objet: *[OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?
>
>
> Bonjour tout le monde,
>
> Trouver un récepteur/enregistreur GPS de bonne qualité est un exercice
> compliqué : Il y a peu de modèles récents, la qualité de réception est
> inconnue, l'autonomie pas toujours adaptée, et quasiment aucun ne
> propose de recevoir les satellites Galileo qui nous promettent une
> meilleur précision.
>
> Il y a eu de nombreuses discussions autour de ces produits ici-même, ou
> ailleurs sur le web, sans trouver le récepteur ultime, celui qui est
> bien plus performant qu'un smartphone, celui que tous les contributeurs
> Osm rêveraient d'avoir dans leur poche ou leur voiture.
>
> J'avais en tête d'en faire un "maison" depuis un moment, mais sans en
> avoir le temps pour avancer vraiment. Il s'agissait d'une ligne sur une
> todo-list comme on en a tous. Une discussion très récente avec
> Jean-Louis Zimmerman m'a fait dire qu'a défaut de m'en charger, on
> pourrait peut-être faire appel à un professionnel pour s'en occuper.
>
> - Coup de chance, j'en connais un tout à fait capable de réaliser ce
> genre de produit. Il m'a déjà aidé pour mes bidouilles autour des caméras.
>
> - Re coup de chance, c'est un libriste convaincu.
>
> - Re-re coup de chance, c'est un contributeur Osm.
>
> - Re-re-re coup de chance, c'est un projet qui l'intéresse.
>
> Bien entendu, ses services de conceptions et de fabrications ne sont pas
> gratuits, mais il est prêt à faire un effort pour la communauté, et s'il
> a des coups de main.
>
> Maintenant, il faut s'occuper du cahier des charges, voilà ou nous en
> sommes pour le moment :
>
> - puce Ublox Neo-M8N (standard) ou Neo-M8T(Raw, RTK en post-traitement
> ou traitement externe) ou Neo-M8P(calcul RTK intégré)
> - Enregistrement de la trace sur mémoire interne ou carte µSD
> - Connecteur pour antenne externe
> - Liaison Bluetooth pour connecter un smartphone/tablette/ordi, etc...
> - Batterie intégrée (recharge via connecteur µUsb)
>
> Et maintenant j'ai besoin de toi cher lecteur :
>
> 1) Ca t'intéresse ? Tu es prêt à mettre un peu d'argent pour faire des
> belles traces GPS ? Heu non, des belles traces Galileo/Gps/Glonass/Beidou ?
> Alors dis-le, car il faudra être un certain nombre pour que ça soit
> possible.
>
> 2) Est-ce que tu préfères utiliser une antenne integrée ou externe ? Une
> antenne externe magnétique, sur le toit de la voiture, sur ta casquette,
> ça marche beaucoup beaucoup mieux.
>
> 3) J'imagine que tu veux qu'il fasse enregistreur autonome, c'est prévu.
> Mais sur quelle durée souhaites-tu pouvoir le faire ?
>
> 4) De quelle autonomie as-tu besoin ? 6h ? 12h? 24h ? plus ?
>
> 5) Est-ce que tu poserais quelques limites sur l'encombrement, le poids ?
>
> 6) Autre chose ?
>
>
> A bientôt
>
> Stéphane
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> 

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[gnrc]

Bonjour, 

Il y a quelques temps je suis trouvé confronté à la difficulté d'enregistrer 
une trace dans un tunnel, ou un bâtiment, ou une grotte ! 
Est-il possible, et simple, d'ajouter une centrale inertielle pour mémoriser 
ces portions de parcours "hors ciel", et améliorer la précision des traces 
depuis un point de départ connu précisément ? 

Si ma demande est trop exotique, n'en tenez pas compte ! 
Merci en tout cas d'avoir lancé cette idée de logger performant. Des fablabs 
pourraient aussi être intéressés à poursuivre ce projet sous licence libre. 

Longue vie à toutes vos contributions 
Christian (osm sur Lyon) 

- Mail original -

De: "Stéphane Péneau"  
À: "Discussions sur OSM en français"  
Envoyé: Jeudi 22 Mars 2018 16:05:20 
Objet: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ? 

Bonjour tout le monde, 

Trouver un récepteur/enregistreur GPS de bonne qualité est un exercice 
compliqué : Il y a peu de modèles récents, la qualité de réception est 
inconnue, l'autonomie pas toujours adaptée, et quasiment aucun ne 
propose de recevoir les satellites Galileo qui nous promettent une 
meilleur précision. 

Il y a eu de nombreuses discussions autour de ces produits ici-même, ou 
ailleurs sur le web, sans trouver le récepteur ultime, celui qui est 
bien plus performant qu'un smartphone, celui que tous les contributeurs 
Osm rêveraient d'avoir dans leur poche ou leur voiture. 

J'avais en tête d'en faire un "maison" depuis un moment, mais sans en 
avoir le temps pour avancer vraiment. Il s'agissait d'une ligne sur une 
todo-list comme on en a tous. Une discussion très récente avec 
Jean-Louis Zimmerman m'a fait dire qu'a défaut de m'en charger, on 
pourrait peut-être faire appel à un professionnel pour s'en occuper. 

- Coup de chance, j'en connais un tout à fait capable de réaliser ce 
genre de produit. Il m'a déjà aidé pour mes bidouilles autour des caméras. 

- Re coup de chance, c'est un libriste convaincu. 

- Re-re coup de chance, c'est un contributeur Osm. 

- Re-re-re coup de chance, c'est un projet qui l'intéresse. 

Bien entendu, ses services de conceptions et de fabrications ne sont pas 
gratuits, mais il est prêt à faire un effort pour la communauté, et s'il 
a des coups de main. 

Maintenant, il faut s'occuper du cahier des charges, voilà ou nous en 
sommes pour le moment : 

- puce Ublox Neo-M8N (standard) ou Neo-M8T(Raw, RTK en post-traitement 
ou traitement externe) ou Neo-M8P(calcul RTK intégré) 
- Enregistrement de la trace sur mémoire interne ou carte µSD 
- Connecteur pour antenne externe 
- Liaison Bluetooth pour connecter un smartphone/tablette/ordi, etc... 
- Batterie intégrée (recharge via connecteur µUsb) 

Et maintenant j'ai besoin de toi cher lecteur : 

1) Ca t'intéresse ? Tu es prêt à mettre un peu d'argent pour faire des 
belles traces GPS ? Heu non, des belles traces Galileo/Gps/Glonass/Beidou ? 
Alors dis-le, car il faudra être un certain nombre pour que ça soit 
possible. 

2) Est-ce que tu préfères utiliser une antenne integrée ou externe ? Une 
antenne externe magnétique, sur le toit de la voiture, sur ta casquette, 
ça marche beaucoup beaucoup mieux. 

3) J'imagine que tu veux qu'il fasse enregistreur autonome, c'est prévu. 
Mais sur quelle durée souhaites-tu pouvoir le faire ? 

4) De quelle autonomie as-tu besoin ? 6h ? 12h? 24h ? plus ? 

5) Est-ce que tu poserais quelques limites sur l'encombrement, le poids ? 

6) Autre chose ? 


A bientôt 

Stéphane 



___ 
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] Mission sur les données géographiques souveraines...

[Rpnpif]

Le 22 mars 2018, Vincent Privat a écrit :

> Je comprends le questionnaire comme devant aboutir à une réforme profonde
> de l'IGN.
> Pour moi l'institut devrait être financé à 100% avec des fonds publics (à
> voir si c'est que l’État ou aussi les collectivités) et en échange mettre
> en ligne tout son contenu (nouvellement produit, mais aussi les archives)
> en licence libre (les seules exceptions à cette règle étant ce qui relève
> du secret défense).
> Pas encore eu le temps de tout lire :)

Tout à fait d'accord.

La donnée géographique est sensible. Un financement privé pourrait
influencé le choix du type et la valeur de cette donnée en fonction de
l'intérêt exclusif du financeur sans moyen d'intervention des 
« clients ». Cela s'est déjà vu ailleurs.

Un financement public donne la capacité (théorique) au citoyen
d'intervenir sur les choix. La mise à disposition de tous permet un
contrôle direct de tout un chacun.

Je suis aussi très favorable aux échanges bidirectionnels entre l'IGN et
OSM.

OSM est complémentaire de l'IGN. L'IGN est plus en soutien des
pouvoirs publics, OSM met les données SIG dans les mains de tous.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] BD Topo Suppression de cours d'eau et ses impacts

[marc marc]

Le 24. 03. 18 à 11:46, Rpnpif a écrit :
> ajouter la date de la décision qui a une valeur importante.

dans osm ?
pour moi, même si cela acte le gachi écologique, c'est une tempête
dans un verre d'eau pour osm.
Vu qu'on ne tag pas le fait qu'un ruisseau était dans Cartage/Topo
bon on ne tagera pas + le fait qu'il n'y est plus.
Osm n'a selon moi pas pour vocation de servir d'encyclopédie universelle 
oü mettrait l'ensemble de la connaissance d'un objet et toutes les refs 
et date de tout infos s'y rapportant.
La seule chose qui change pour osm c'est qu'on perdra une source d'info

> existe t-il une carte archive d'OSM consultable facilement 
> comme on consulte la version ancienne formatée d'un article
> sous Wikipédia ?

Cela dépend si tu parles des données ou de leur représentation graphique
Pour les données, un serveur overpass attic te permet de demander les 
données qui existait à tel date.
Il te les met sur la carte actuelle, mais ce n'est pas un rendu, juste 
une surcouche.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] BD Topo Suppression de cours d'eau et ses impacts

[Rpnpif]

Le 22 mars 2018, osm.sanspourr...@spamgourmet.com a écrit :

> > De notre coté quel est l'impact? Car même si les cours d'eaux sont 
> > intermittents, on les saisie. Peux-on ajouter une information sur cette 
> > déclassification?
>  
> Comme j'avais eu l'occasion de le dire le déclassement est faible là où les 
> associaitions luttent (SEPNB-Bretagne Vivante : peu de déclassements en 
> Bretagne).
> La pluie n'ayant pas lu les arrêtés préfectoraux, les ruisseuax intermittents 
> continueront à se former.
>  
> Ca peut avoir une influence sur nos sources, ça ne doit pas en avoir sur 
> notre carte !
> On sait déjà indiquer d'un cours n'est pas permanent :
> intermittent=yes
>  
> Peut-être description=ruisseau (ou fossé...) déclassifié par l'autorité 
> préfectorale
> Jean-Yvon
>  
>  
> Gesendet: Mittwoch, 21. März 2018 um 16:30 Uhr
> Von: "Philippe Verdy - verd...@wanadoo.fr" 
> 
> An: "Discussions sur OSM en français" 
> Betreff: Re: [OSM-talk-fr] BD Topo Suppression de cours d'eau et ses impacts
>  
> (...)
>  
> > Le 21 mars 2018 à 09:06, Jérôme Seigneuret  a 
> > écrit :
> > Bonjour, les préfets déclassent certains cours d'eau. (chaque département y 
> > va de son arrêté). Je pense que ça va avoir un impact direct sur les 
> > sources de données que l'on utilise.
> >>  
> >> Je dévi un peu mais c'est volontaire vu l'impact d'une telle décision.
> >>  
> >> L'impact est la suppression de zones de non traitement aux pesticides
> >> https://www.legifrance.gouv.fr/eli/arrete/2017/5/4/AGRG1632554A/jo/texte
> >>  
> >> FNE a déposé des recours contre ces déclassifications. Je vous invite à 
> >> lire l'article
> >> https://www.fne.asso.fr/actualites/p%C3%A9tition%C2%A0-encore-plus-de-pesticides-dans-nos-cours-deau%C2%A0-cest-non%C2%A0-0
> >>  
> >> De notre coté quel est l'impact? Car même si les cours d'eaux sont 
> >> intermittents, on les saisie. Peux-on ajouter une information sur cette 
> >> déclassification?

Et bien retenir que c'est une affaire purement politique, avec des
changements qui peuvent être plus ou moins rapides dans un sens comme
dans l'autre suivant les rapports de force sur le terrain comme le dit
Philippe.

Il faut bien savoir que de nombreux cas ne font que valider une action
illégale de suppression physique du cours d'eau soit par tarissement
en amont ou plus souvent par destruction au bulldozer ou au tracteur
pour les plus petits. Et le préfet valide trop souvent sous la
pression de certains groupes :/. Ce genre de forçage illégal de la
décision publique n'est malheureusement pas rare dans certaines
campagnes de l'ouest de la France. Il est attaqué en justice quand des
associations le détectent et en ont les moyens financiers et techniques.

Tout aussi illégalement, c'est la même chose avec les mares, les zones
humides, les bois rasés à blanc du jour au lendemain. Les destructions
se sont accélérées dans certains secteurs depuis 10 ans et surtout
depuis 5 ans. Certaines associations ne savent plus où donner de la
tête face aux actions concertées de certains lobbies directement sur
le terrain, j'en ai été témoin.

Openstreetmap est précieux pour faire un état des lieux.

Dans la description proposée par Jean-Yvon, Il ne faut pas oublier
d'ajouter la date de la décision qui a une valeur importante.

À ce propos, existe t-il une carte archive d'OSM consultable
facilement comme on consulte la version ancienne formatée d'un article
sous Wikipédia ?

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[François]

Le 23/03/2018 à 16:12, Stéphane Péneau a écrit :
Synchroniser des photos depuis la trace reste possible en photographiant 
l'écran d'un smartphone, qui lui, afficherait en gros l'heure GPS.


Autre méthode :
GPSCorrelate lit la trace et inscrit les coordonnées dans les EXIF des 
photos. Il vaut mieux que l'APN soit à l'heure (d'été demain), sinon une 
correction horaire est possible.


--
François


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

Re: [OSM-talk-fr] Et si on fabriquait notre récepteur/logger GPS ?

[Denis Bigorgne]

Le 23 mars 2018 à 16:12, Stéphane Péneau  a
écrit :

> Je vais essayer de répondre aux différentes questions :
> ...
>
> Utilisation sur piles :
>
> Le souci des piles, c'est leurs capacités plus faibles que les batteries
> Li-ion.
> Est-ce qu'une batterie Usb externe pour recharger le récepteur serait
> problématique en situation de trek
>

  Batterie externe de recharge : je n'en connais pas qui sont sur piles, en
avoir de nombreuses li-ion, c'est cher...
J'ai une frontale où le même boitier peut accepter une batterie li-ion de
3,2Wh ou bien 3 piles AAA. C'est très pratique.


>
> ___
> 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] Et si on fabriquait notre récepteur/logger GPS ?

[Stéphane Péneau]

Le 24/03/2018 à 03:21, osm.sanspourr...@spamgourmet.com a écrit :
En fait un codage pas trop con c’est plus compact : date et position 
absolues puis en relatif avec encodage en Z.
L'inconvénient d'un codage particulier, c'est qu'il faudrait une appli 
spécifique pour récupérer quelque chose d'exploitable. Alors qu'un 
simple fichier nmea sera réutilisable facilement.
On peut imaginer enregistrer directement en Gpx pour économiser de 
l'espace, mais on perd des informations.
La fréquence des points, (jusqu'à 10hz) est à adapter en fonction de 
l'utilisation.



Certains satellites sont multi-constellation donc ça n’enrichit pas 
toujours autant qu’espéré (en plus des rq de Philippe).

Je ne connais aucun satellite GNSS multi-constellation.



Quel intérêt d’avoir en plus un Rasberry-Pi ? Ne pas avoir de câble 
entre le récepteur et le téléphone ? Car les données brutes doivent 
être difficile à faire passer.



Non, ça va, je l'ai fait de nombreuses fois.

Le raspberry à d'autres inconvénients :
- On ne peut pas monitorer la tension de sortie de la batterie pour 
déclencher l'arrêt en cas de niveau trop bas
- On ne peut pas éteindre complètement le raspberry (les périfs restent 
partiellement alimentés)
- Pas de RTC (horloge alimentée en permanence), l'horodatage des 
fichiers sera faux. Ça se contourne, mais pas si simplement que ça 
lorsqu'on enregistre en RAW.


Stf

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