Re: [OSM-talk-fr] Imagerie mondiale DigitalGloble disponible pour OSM

[George Kaplan]

> Date: Thu, 10 Apr 2014 23:34:57 +0200
> From: fred.rodr...@gmail.com
> To: talk-fr@openstreetmap.org
> Subject: [OSM-talk-fr] Imagerie mondiale DigitalGloble disponible pour OSM
> 
> Bonjour,
> 
> MapBox a annoncé que "Mapbox Satellite" qui provient de DigitalGlobe est 
> disponible pour le décalquage pour OSM. Le calque est déjà dans iD et 
> dans la liste de ceux disponibles pour JOSM.
> 
> Le message original :
> http://www.openstreetmap.org/user/lxbarth/diary/21622
> 
> L'info chez DigitalGloble :
> http://www.digitalglobeblog.com/2014/04/09/mappingtheworldinosm/
> 
> US et Europe de l'ouest disponible au zoom 19, le reste au zoom 17.



Bonjour,


Je viens de regarder quelques zones sous JOSM :
A Paris et aux alentours, Mapbox Satellite est identique à Bing, ce sont les 
mêmes photos (circulation, véhicules stationnés identiques)
A Nuremberg, MapBox et Bing sont bien différents, l'un pris en été et l'autre 
en hiver (feuillage sur les arbres)
A la Réunion, Mapbox et Bing sont différents. Mapbox a plus de constructions 
que Bing, je suppose donc que c'est la prise de vue la plus récente.




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

Re: [OSM-talk-fr] Imagerie mondiale DigitalGloble disponible pour OSM

[Eric SIBERT]

Le 10/04/2014 23:34, Frédéric Rodrigo a écrit :

Bonjour,

MapBox a annoncé que "Mapbox Satellite" qui provient de DigitalGlobe est
disponible pour le décalquage pour OSM.

[...]

US et Europe de l'ouest disponible au zoom 19, le reste au zoom 17.


Wow!!!

Grand pas en avant pour Madagascar même s'il n'y a pas réellement le 
niveau 17 partout, c'est bien complémentaire avec Bing.


Eric


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

Re: [OSM-talk-fr] Problème de décalage du cadastre vs GPS sur une commune

[Pierre Knobel]

Merci pour les conseils. Ça m'étonne parce que c'est la première fois
que je vois ce genre de soucis après avoir traité une petite centaines
de communes sans problèmes. On doit avoir du bol avec notre cadastre.

On fait comment pour charger les sections séparément ?

Je ferais un tour sur place à mon prochain passage dans la région pour
relever tous les chemins, les routes et quelques points d'intérêt au
GPS, ça devrait suffire pour déterminer tous les décalages et corriger
en conséquence.

2014-04-10 22:15 GMT+02:00 DH :
> Le 10/04/2014 21:09, Pierre Knobel a écrit :
>
>> Bonsoir,
>>
>> J'ai un soucis avec le cadastre sur le Hameau de Wengelsbach (commune
>> de Niedersteinbach) : http://osm.org/go/0DN6pIou?layers=C
>>
>> Le premier problème est que le cadastre semble décalé par rapport aux
>> traces GPS. Je compte y faire un tour pour enregistrer quelques
>> nouvelles traces avec un récepteur GPS auquel je fais confiance pour
>> confirmer que ce n'est pas juste des traces GPS de mauvaise qualité.
>>
>> Le deuxième problème est que les positions des maisons sur le cadastre
>> actuel ne correspond pas aux positions des maisons importés. Ce n'est
>> pas juste un problème de décalage linéaire, car quand je sélectionne
>> tous les bâtiments et que je les déplace ensemble  je n'arrive pas à
>> trouver un décalage qui leur convienne à tous. Je ne sais pas si c'est
>> dû à une mise à jour du cadastre, ou si lors de l'import initial les
>> bâtiments ont été corrigés un par un en se basant sur l'imagerie
>> aérienne (peut-être mal orthorectifiée, vu que je n'arrive pas à la
>> faire coller proprement aux traces GPS non plus).
>>
>> Au final c'est un gros casse tête pour essayer de placer les bâtiments
>> proprement en respectant la position des rues basée sur les traces
>> GPS. J'ai laissé tomber pour le moment, mais ça m'embête parce qu'il
>> faudrait que la positions des maisons soit correcte avant que je
>> puisse importer les adresses.
>>
>> Est-ce que quelqu'un a déjà eu à gérer un problème similaire ? Des
>> conseils ?
>>
>> Pierre
>>
>
> Trace et enregistre sur un calque séparé les 13 sections de la commune et tu
> découvriras probablement les sections qui posent problèmes (dont Wengelsbach
> probablement). La feuille cadastrale est l'unité de travail ; les raccords
> entre feuilles ne sont redressés que dans des marges normées dans les
> cahiers des charges de digitalisation (comme aux limites communales). A
> Niedersteinbach, on est quand même en bordure des Vosges du Nord (effet
> relief soudain en bordure de feuille même si c'est pas les Alpes ;-). Le
> fait que le cadastre soit vectorisé indique juste que les erreurs du plan
> cadastral papier ont été numérisées.
> Bravo pour ton travail sur l'Alsace du Nord et n'hésites pas à me solliciter
> en cas de besoin sur la liste locale.
>
> Denis
> PS : le tracé de la Réserve Naturelle Régionale de Wegscheid (fin fond du
> Haut-Rhin côté massif vosgien) m'avait coûté des heures en raison de
> sections cadastrales complètement nazes. Je compatis donc
>
>
> ___
> 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] Imagerie mondiale DigitalGloble disponible pour OSM

[Frédéric Rodrigo]

Bonjour,

MapBox a annoncé que "Mapbox Satellite" qui provient de DigitalGlobe est 
disponible pour le décalquage pour OSM. Le calque est déjà dans iD et 
dans la liste de ceux disponibles pour JOSM.


Le message original :
http://www.openstreetmap.org/user/lxbarth/diary/21622

L'info chez DigitalGloble :
http://www.digitalglobeblog.com/2014/04/09/mappingtheworldinosm/

US et Europe de l'ouest disponible au zoom 19, le reste au zoom 17.

Frédéric.

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

Re: [OSM-talk-fr] Highway=unclassified en ville

[didier2020]

Le jeudi 10 avril 2014 à 09:08 +0200, Jean-Baptiste Holcroft a écrit :
> Didier, peux tu nous mettre quelque chose a disposition pour discuter 
> sur des éléments concrets ?

j'ai pris une commune en seine et marne
le fichier html suivant charge les ways avec josm 
http://osm2020.free.fr/teste/analyser_osmosis_residential_landuse-debugwithjosm.xml.html



> 
> Pour précision : effectivement mon propos concerne bien uniquement les
> way des 'zones habitées' que j'estime être dans un landuse
> résidential.
> 
> Cette détection permettrait deux choses : détecter des rues mal tagées
> ou des landuse mal découpés.
> 
> À mon avis, la présomption d'une vitesse à 50km/h sur ces voies a du
> sens faute de maxspeed explicite.
> 
> Le concept de unclassified en ville ne me semble peu probable.
> Exemple : on peut parfaitement materialiser une residential avec une
> largeur de 6m et sidewalk=no si c'est important de caractériser que ça
> ne ressemble pas a une rue résidentielle de carte postale.
> 
> La seule interrogation que j'ai réside sur les voies d'accès a des
> zones industrielles ou commerciales.
> 
> Pour savoir où j'ai fait ma modification, il suffit de regarder les
> deux dernières modifications récentes de JIBEC. C'est dans mon commit
> de mise a jour manuelle du cadastre.
> 
> Le 9 avr. 2014 18:15, "didier2020"  a écrit :
> Le mercredi 09 avril 2014 à 17:46 +0200, Jean-Baptiste
> Holcroft a
> écrit :
> > Bonjour,
> >
> >
> > Ayant travaillé hier sur Châtillon (ville collée au
> sud-ouest de
> > Paris) j'ai découvert des highway=unclassified en centre
> ville.
> >
> >
> > Il me semble qu'il s'agit systématiquement d'une erreur, que
> j'ai
> > corrigé en residential (d'autant plus qu'il y avait un name
> > renseigné).
> > Si vous confirmez que pour vous il s'agit également d'un
> élément
> > étrange, serait-il pertinent d'avoir une analyse osmose sur
> voies dans
> > un landuse=residential pour détecter ce genre de choses ?
> j'avais tenté une analyse pour detecter les highways
> incohérents:
> residential, living_street, etc... a l'intérieur/chevauchant
> des
> landuses allotments,farm, industrial ...
> ou
> unclassified pour les landuses residential
> 
> il y avait énormément d'erreur:
> - mauvaise emprise/description des landuses (clc)
> - les description residential/unclassified ne s'arretent pas a
> la limite
> des landuses
> 
> ->
> >
> >
> > Cordialement,
> > --
> > Jean-Baptiste Holcroft
> > ___
> > 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] Problème de décalage du cadastre vs GPS sur une commune

[DH]

Le 10/04/2014 21:09, Pierre Knobel a écrit :

Bonsoir,

J'ai un soucis avec le cadastre sur le Hameau de Wengelsbach (commune
de Niedersteinbach) : http://osm.org/go/0DN6pIou?layers=C

Le premier problème est que le cadastre semble décalé par rapport aux
traces GPS. Je compte y faire un tour pour enregistrer quelques
nouvelles traces avec un récepteur GPS auquel je fais confiance pour
confirmer que ce n'est pas juste des traces GPS de mauvaise qualité.

Le deuxième problème est que les positions des maisons sur le cadastre
actuel ne correspond pas aux positions des maisons importés. Ce n'est
pas juste un problème de décalage linéaire, car quand je sélectionne
tous les bâtiments et que je les déplace ensemble  je n'arrive pas à
trouver un décalage qui leur convienne à tous. Je ne sais pas si c'est
dû à une mise à jour du cadastre, ou si lors de l'import initial les
bâtiments ont été corrigés un par un en se basant sur l'imagerie
aérienne (peut-être mal orthorectifiée, vu que je n'arrive pas à la
faire coller proprement aux traces GPS non plus).

Au final c'est un gros casse tête pour essayer de placer les bâtiments
proprement en respectant la position des rues basée sur les traces
GPS. J'ai laissé tomber pour le moment, mais ça m'embête parce qu'il
faudrait que la positions des maisons soit correcte avant que je
puisse importer les adresses.

Est-ce que quelqu'un a déjà eu à gérer un problème similaire ? Des conseils ?

Pierre



Trace et enregistre sur un calque séparé les 13 sections de la commune 
et tu découvriras probablement les sections qui posent problèmes (dont 
Wengelsbach probablement). La feuille cadastrale est l'unité de travail 
; les raccords entre feuilles ne sont redressés que dans des marges 
normées dans les cahiers des charges de digitalisation (comme aux 
limites communales). A Niedersteinbach, on est quand même en bordure des 
Vosges du Nord (effet relief soudain en bordure de feuille même si c'est 
pas les Alpes ;-). Le fait que le cadastre soit vectorisé indique juste 
que les erreurs du plan cadastral papier ont été numérisées.
Bravo pour ton travail sur l'Alsace du Nord et n'hésites pas à me 
solliciter en cas de besoin sur la liste locale.


Denis
PS : le tracé de la Réserve Naturelle Régionale de Wegscheid (fin fond 
du Haut-Rhin côté massif vosgien) m'avait coûté des heures en raison de 
sections cadastrales complètement nazes. Je compatis donc


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

Re: [OSM-talk-fr] Problème de décalage du cadastre vs GPS sur une commune

[Jean-Baptiste Holcroft]

C'est un cas classique, il faut prendre le courage de les déplacer grappe
par grappe jusqu'à ce que tout corresponde. Bing est très souvent juste.
Une seule trace GPS traversant le village te le confirmera. Si ce n'est que
as le cas, mieux vaut ne rien importer.

A titre de comparaison, il m'arrive fréquemment de repositionner 100% des
bâtiments d'un village dans le calvados.

Bon courage,
Le 10 avr. 2014 21:09, "Pierre Knobel"  a écrit :

> Bonsoir,
>
> J'ai un soucis avec le cadastre sur le Hameau de Wengelsbach (commune
> de Niedersteinbach) : http://osm.org/go/0DN6pIou?layers=C
>
> Le premier problème est que le cadastre semble décalé par rapport aux
> traces GPS. Je compte y faire un tour pour enregistrer quelques
> nouvelles traces avec un récepteur GPS auquel je fais confiance pour
> confirmer que ce n'est pas juste des traces GPS de mauvaise qualité.
>
> Le deuxième problème est que les positions des maisons sur le cadastre
> actuel ne correspond pas aux positions des maisons importés. Ce n'est
> pas juste un problème de décalage linéaire, car quand je sélectionne
> tous les bâtiments et que je les déplace ensemble  je n'arrive pas à
> trouver un décalage qui leur convienne à tous. Je ne sais pas si c'est
> dû à une mise à jour du cadastre, ou si lors de l'import initial les
> bâtiments ont été corrigés un par un en se basant sur l'imagerie
> aérienne (peut-être mal orthorectifiée, vu que je n'arrive pas à la
> faire coller proprement aux traces GPS non plus).
>
> Au final c'est un gros casse tête pour essayer de placer les bâtiments
> proprement en respectant la position des rues basée sur les traces
> GPS. J'ai laissé tomber pour le moment, mais ça m'embête parce qu'il
> faudrait que la positions des maisons soit correcte avant que je
> puisse importer les adresses.
>
> Est-ce que quelqu'un a déjà eu à gérer un problème similaire ? Des
> conseils ?
>
> Pierre
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Problème de décalage du cadastre vs GPS sur une commune

[Pierre Knobel]

Bonsoir,

J'ai un soucis avec le cadastre sur le Hameau de Wengelsbach (commune
de Niedersteinbach) : http://osm.org/go/0DN6pIou?layers=C

Le premier problème est que le cadastre semble décalé par rapport aux
traces GPS. Je compte y faire un tour pour enregistrer quelques
nouvelles traces avec un récepteur GPS auquel je fais confiance pour
confirmer que ce n'est pas juste des traces GPS de mauvaise qualité.

Le deuxième problème est que les positions des maisons sur le cadastre
actuel ne correspond pas aux positions des maisons importés. Ce n'est
pas juste un problème de décalage linéaire, car quand je sélectionne
tous les bâtiments et que je les déplace ensemble  je n'arrive pas à
trouver un décalage qui leur convienne à tous. Je ne sais pas si c'est
dû à une mise à jour du cadastre, ou si lors de l'import initial les
bâtiments ont été corrigés un par un en se basant sur l'imagerie
aérienne (peut-être mal orthorectifiée, vu que je n'arrive pas à la
faire coller proprement aux traces GPS non plus).

Au final c'est un gros casse tête pour essayer de placer les bâtiments
proprement en respectant la position des rues basée sur les traces
GPS. J'ai laissé tomber pour le moment, mais ça m'embête parce qu'il
faudrait que la positions des maisons soit correcte avant que je
puisse importer les adresses.

Est-ce que quelqu'un a déjà eu à gérer un problème similaire ? Des conseils ?

Pierre

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

Re: [OSM-talk-fr] Tag "noexit=yes"

[Vincent Privat]

Pour info on a un ticket josm sur le sujet
http://josm.openstreetmap.de/ticket/9895
Le 10 avr. 2014 16:44, "Pieren"  a écrit :

> 2014-04-10 16:15 GMT+02:00 Christophe Merlet :
>
> > Je crois l'avoir déjà utiliser sur les impasses qui se finissent juste à
> > coté d'une autre voie pour supprimer des erreurs de voies "non connectés"
>
> C'est probablement la seule justification pour l'existence de ce tag.
> Parce que dans les autres cas, les logiciels de routage par exemple
> n'en ont pas besoin (le tag étant absent dans la plupart des impasses
> de toute façon).
>
> > Sur le dernier noeud me semble être la bonne pratique
>
> Mais en même temps, s'il est vraiment utile que valider le "non
> connecté", ça fonctionne aussi si le tag est sur le way... Comme 40%
> de ces tags sont déjà sur des ways, je ne vois pas pourquoi on devrait
> s'en passer.
>
> Pieren
>
> ___
> 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] Tag "noexit=yes"

[Pieren]

2014-04-10 16:15 GMT+02:00 Christophe Merlet :

> Je crois l'avoir déjà utiliser sur les impasses qui se finissent juste à
> coté d'une autre voie pour supprimer des erreurs de voies "non connectés"

C'est probablement la seule justification pour l'existence de ce tag.
Parce que dans les autres cas, les logiciels de routage par exemple
n'en ont pas besoin (le tag étant absent dans la plupart des impasses
de toute façon).

> Sur le dernier noeud me semble être la bonne pratique

Mais en même temps, s'il est vraiment utile que valider le "non
connecté", ça fonctionne aussi si le tag est sur le way... Comme 40%
de ces tags sont déjà sur des ways, je ne vois pas pourquoi on devrait
s'en passer.

Pieren

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

[OSM-talk-fr] Contact Wiki

[Waxy]

Salut,

Savez-vous qui contacter eu égard aux filtres sur le Wiki ?

Comme dyndns.org cesse son offre gratuite, j'ai pris une adresse chez
No-ip. Mais quand je veux mettre à jour les liens dans le wiki (OSM Map
On Garmin/Download) un filtre anti-spam empêche la validation :-(

@+

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

Re: [OSM-talk-fr] Tag "noexit=yes"

[Romain MEHUT]

Le 10 avril 2014 16:09, Pieren  a écrit :

> Bonjour,
>
> Y-a-t-il des gens sur cette liste qui utilisent ou ont utilisé le tag
> "noexit=yes" ? Dans quel but ? Et sur quel élément, le dernier node ou
> sur le way ?
>

J'ai mis noexit=yes sur le dernier node dans le cas de chemins forestiers
pour préciser qu'il n'y a aucun moyen d'aller plus loin.

Par contre dans le cas d'impasse en ville, je le mets sur le way lui-même
car il n'est pas impossible que l'impasse se poursuive par un sentier...

C'est d'ailleurs ce que laisse entendre le wiki dans le paragraphe "Usage"
cf. http://wiki.openstreetmap.org/wiki/Key:noexit

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

Re: [OSM-talk-fr] Tag "noexit=yes"

[Pierre-Yves Berrard]

Mon interprétation :

En théorie ce tag n'a pas d'utilité, car le fait que la route n'aboutit
nulle part suffit à déterminer que la voie est sans issue.
À mon avis, il est utilisé pour simplifier certains algorithmes de routage
: exclusion d'office de certaines routes sans avoir à parcourir tous les
noeuds.

Pour une optimisation de l'algorithme, faut-il le mettre sur la voie ou sur
le dernier noeud ?
Je dirais sur la voie (pas besoin de parcourir tous les noeuds) mais je ne
connais pas assez les algo de routage pour répondre à cette question.


Le 10 avril 2014 16:09, Pieren  a écrit :

> Bonjour,
>
> Y-a-t-il des gens sur cette liste qui utilisent ou ont utilisé le tag
> "noexit=yes" ? Dans quel but ? Et sur quel élément, le dernier node ou
> sur le way ?
> Pensez-vous comme certains sur la liste tagging@ que mettre ce tag sur
> le way est une mauvaise pratique et qu'il ne faudrait le mettre que
> sur le dernier noeud ?
>
> Pieren
>
> ___
> 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] Tag "noexit=yes"

[Olivier Patrice Griffet]

*Bonjour Pieren et à toutes et tous.*
*personnellement j'utilise ce Tag *"noexit=yes"

* sur le dernier ' Node ' des voies qui ce trouvent être des impasses. *

*Ceci pour que les site de calcules d'itinéraires sache que ce sont des
impasses pour les véhicules routiers.*










*Amicalement.Olivier Griffet | Contributeur
OpenStreetMap =>
http://www.openstreetmap.org/user/olivier_griffet_83660_carnoules
  | |
Habitant de 83660

- Carnoules  - Var | Adhérent de GULLIVAR et ToulonuX
| Utilisateur de GNU/LINUX > de *




*(X)Ubuntu 12.04 [  XFCE ] ; Lives USB >> ASRI.EDU.300 ; Etc...Site web de
GULLIVAR : http://gullivar.org/  Site web de ToulonuX
: http://toulonux.tuxfamily.org/ *

-
Le 10 avril 2014 16:09, Pieren  a écrit :

> Bonjour,
>
> Y-a-t-il des gens sur cette liste qui utilisent ou ont utilisé le tag
> "noexit=yes" ? Dans quel but ? Et sur quel élément, le dernier node ou
> sur le way ?
> Pensez-vous comme certains sur la liste tagging@ que mettre ce tag sur
> le way est une mauvaise pratique et qu'il ne faudrait le mettre que
> sur le dernier noeud ?
>
> Pieren
>
> ___
> 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] Tag "noexit=yes"

[Christophe Merlet]

Le 10/04/2014 16:09, Pieren a écrit :
> Bonjour,
> 
> Y-a-t-il des gens sur cette liste qui utilisent ou ont utilisé le tag
> "noexit=yes" ? Dans quel but ? Et sur quel élément, le dernier node ou
> sur le way ?

Je crois l'avoir déjà utiliser sur les impasses qui se finissent juste à
coté d'une autre voie pour supprimer des erreurs de voies "non connectés"

> Pensez-vous comme certains sur la liste tagging@ que mettre ce tag sur
> le way est une mauvaise pratique et qu'il ne faudrait le mettre que
> sur le dernier noeud ?

Sur le dernier nœud me semble être la bonne pratique


Librement,
-- 
Christophe Merlet (RedFox)

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

[OSM-talk-fr] Tag "noexit=yes"

[Pieren]

Bonjour,

Y-a-t-il des gens sur cette liste qui utilisent ou ont utilisé le tag
"noexit=yes" ? Dans quel but ? Et sur quel élément, le dernier node ou
sur le way ?
Pensez-vous comme certains sur la liste tagging@ que mettre ce tag sur
le way est une mauvaise pratique et qu'il ne faudrait le mettre que
sur le dernier noeud ?

Pieren

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

Re: [OSM-talk-fr] Chemins de randonnée (GR et autres)

[Philippe Verdy]

De toute façon cette fédé parasite n'a aucune vocation à rester la seule à
représenter les autres assos (qui elles reçoivent des subventions en
fonction d'objectifs locaux réels à réaliser).
Je ne vois absolument pas quel est encore l'intérêt pour n'importe quelle
asso à rester membre de la FRPP alors qu'elles auront bien plus d'intérets
à travailler même avec des fédés d'autres sports ou des asso
environnementales ou des offices de tourisme des collectivités, avec de
réelles synergies locales.
Cette FRPP me semble aujourd'hui totalement obsolète dans ce qu'elle fait
(et surtout ce qu'elle ne sait pas faire et ne fait pas : communiquer). Les
"topoguides" ne sont même pas une nécessité, chaque région peut avoir ses
propres publications et ses propres plans et communications et ses propres
concertations locales. Et quoi qu'elle fasse elle devrra le faire en
respectant ce qui est dans le domaine public ou collectif, ce parasitisme
basé sur une situation de fait cherche juste à durer pour s'imposer comme
si c'était un droit, de la même façon que les "propriétaires" de paillottes
qui se sont posés sur les plages : que l'Etat les expulse et se réapproprie
le domaine public volé (et ce n'est pas la présence de deux coups de
pinceau sur le domaine public qui constitue une oeuvre d'art).

Pour moins la FRPP agir exactement comme les tagueurs sauvages des villes ;
elle a juste imposé sa présence en espérant que personne ne proteste et
cela a assez duré et cette durée dans un vieux flou juridique ayant empêché
l'Etat de voir pendant quelques décennies qu'il y avait un problème devrait
cesser. Au besoin par la loi pour reconnaître que ces circuits tracés sur
le domaine public et dans les réserves naturelles appartiennent bien au
domaine public national.


Le 10 avril 2014 12:10, Romain MEHUT  a écrit :

> Le 10 avril 2014 12:05, Christian Quest  a écrit
> :
>
>
>
>> Pas de réponse car en cas de non elle va devoir se justifier et aura bien
>> du mal (arguments faibles) et elle ne veut pas dire oui car ça serait la
>> fin du monopole qu'elle a construit par parasitisme.
>>
>
> Mais comme le dit Philippe, les subventions risquent de ne plus suivre...
>
> ___
> 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] Chemins de randonnée (GR et autres)

[Romain MEHUT]

Le 10 avril 2014 12:05, Christian Quest  a écrit :


> Pas de réponse car en cas de non elle va devoir se justifier et aura bien
> du mal (arguments faibles) et elle ne veut pas dire oui car ça serait la
> fin du monopole qu'elle a construit par parasitisme.
>

Mais comme le dit Philippe, les subventions risquent de ne plus suivre...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chemins de randonnée (GR et autres)

[Christian Quest]

Pas de réponse car en cas de non elle va devoir se justifier et aura bien
du mal (arguments faibles) et elle ne veut pas dire oui car ça serait la
fin du monopole qu'elle a construit par parasitisme.


Le 9 avril 2014 22:01, Romain MEHUT  a écrit :

> Le 9 avril 2014 17:11, Marc SIBERT  a écrit :
>
>
>
>> Étrange ! c'est un beau OpenDataFail ou bien ?
>>
>> "Informations
>> Open Data Commons Open Database License (ODbL)" et en même temps une
>> belle réserve :
>> "Les itinéraires connus sous le nom de << GR >> et << GRP >>, balisés
>> respectivement de marques blanc-rouge et jaune-rouge, sont des créations de
>> la FFRandonnée. Ils sont protégés au titre du code de la propriété
>> intellectuelle. Les marques utilisées sont déposées à l'INPI. Nul ne peut
>> en disposer sans autorisation expresse. (c) FFRandonnée. Autorisation 2012."
>>
>
> Cela a déjà été évoqué précédemment cf.
> https://lists.openstreetmap.org/pipermail/talk-fr/2012-December/052685.html
>
> Le département de la Loire Atlantique a engagé des démarches auprès de son
> comité départemental et de la fédération elle-même pour mettre en open data
> ces données. Le département n'a pas reçu de réponse formelle de la
> fédération.
>
> Il faut que d'autres départements fassent la même démarche comme suggéré
> par Benjamin JEAN lors de sa présentation au SOTM-FR.
>
> Romain
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Conférence "State Of The Map" France du 4 au 6 avril à
Paris
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Highway=unclassified en ville

[Jean-Baptiste Holcroft]

Didier, peux tu nous mettre quelque chose a disposition pour discuter sur
des éléments concrets ?

Pour précision : effectivement mon propos concerne bien uniquement les way
des 'zones habitées' que j'estime être dans un landuse résidential.

Cette détection permettrait deux choses : détecter des rues mal tagées ou
des landuse mal découpés.

À mon avis, la présomption d'une vitesse à 50km/h sur ces voies a du sens
faute de maxspeed explicite.

Le concept de unclassified en ville ne me semble peu probable. Exemple : on
peut parfaitement materialiser une residential avec une largeur de 6m et
sidewalk=no si c'est important de caractériser que ça ne ressemble pas a
une rue résidentielle de carte postale.

La seule interrogation que j'ai réside sur les voies d'accès a des zones
industrielles ou commerciales.

Pour savoir où j'ai fait ma modification, il suffit de regarder les deux
dernières modifications récentes de JIBEC. C'est dans mon commit de mise a
jour manuelle du cadastre.
Le 9 avr. 2014 18:15, "didier2020"  a écrit :

> Le mercredi 09 avril 2014 à 17:46 +0200, Jean-Baptiste Holcroft a
> écrit :
> > Bonjour,
> >
> >
> > Ayant travaillé hier sur Châtillon (ville collée au sud-ouest de
> > Paris) j'ai découvert des highway=unclassified en centre ville.
> >
> >
> > Il me semble qu'il s'agit systématiquement d'une erreur, que j'ai
> > corrigé en residential (d'autant plus qu'il y avait un name
> > renseigné).
> > Si vous confirmez que pour vous il s'agit également d'un élément
> > étrange, serait-il pertinent d'avoir une analyse osmose sur voies dans
> > un landuse=residential pour détecter ce genre de choses ?
> j'avais tenté une analyse pour detecter les highways incohérents:
> residential, living_street, etc... a l'intérieur/chevauchant des
> landuses allotments,farm, industrial ...
> ou
> unclassified pour les landuses residential
>
> il y avait énormément d'erreur:
> - mauvaise emprise/description des landuses (clc)
> - les description residential/unclassified ne s'arretent pas a la limite
> des landuses
>
> ->
> >
> >
> > Cordialement,
> > --
> > Jean-Baptiste Holcroft
> > ___
> > 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