Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Philippe Verdy]

sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
afficher. les "stop_position" du nouveau schéma sont destinés aux
interconnexions et outils de vérification des lignes qui peuvent détecter
avec eux des arrêts non desservis par le chemin (soit parce que le chemin
est brisé, soit parce que c'est le "'stop_position" associé à la mauvaise
plateforme qui a été sélectionné).

Je ne vois pas trop l'intérêt dans le rendu **généraliste** d'afficher les
"stop_position" au milieu de la rue (pas même leur nom), mais peut-être que
ça peut être utile dans un rendu public transport, qui préférera les
utiliser au lieu des plateforme. Les stop position devraient être
particulièrement utiles pour les recherches d'itinéraires, et identifier le
nom et la localisation exacte des arrêts pour monter ou descendre sur un
itinéraire. Dans un tel cas, le rendu spécialisé pourra largement
simplifier ou même ne pas afficher du tout le reste de la carte et
présenter un plan plus schématique avec juste les chemins reliant les
"stop_position", et dont la géométrie peut être alors simplifiée.


Le 22 décembre 2016 à 03:02, Christian Quest  a
écrit :

> Le 22 décembre 2016 à 01:05, Jérôme Amagat  a
> écrit :
>
>> on parle beaucoup des transport public en ce moment, ça serait bien que
>> les arrets de bus, tram metro ... soit rendu qu'avec des tag
>> public_transport= et aussi si ce n'est pas un node mais un way ou
>> multipolygon.
>>
>
>>
>
> Je ne pense pas que ce soit une bonne idée de forcer ainsi la main pour
> adopter un modèle bien complexe pour le contributeur lambda.
>
> Si on veut détecter les arrêts à mettre à jour, il faut le faire avec des
> outils de QA comme osmose, pas avec un rendu assez généraliste.
>
>
> Pour la prise en compte des polygones, je vais regarder ce qu'il est
> possible de faire, mais mes souvenirs c'est qu'il est bien complexe de
> prendre en compte le schéma public_transport au niveau du rendu.
>
> On met quoi sur le rendu ? public_transport=stop_position ou
> public_transport=platform ?
>
> Si on a un highway=bus_stop comment on évite d'avoir un doublon ?
>
> Heureusement que postgis a maintenant de quoi générer des cluster... ça va
> peut être être la solution: on met tout ensemble et on fait un cluster ;)
>
> --
> Christian Quest - OpenStreetMap France
>
> ___
> 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] Rendu FR, bientôt en version 2017 !

[PanierAvide]

Youpi, le premier rendu à considérer un minimum les objets indoor est le 
rendu FR :-) C'est pas mal l'idée d'estomper, moins agressif que le 
binaire afficher/cacher, tout en cachant quand même un peu ces objets 
qui ne sont pas au niveau du sol.


Ce serait également pertinent d'adapter le rendu pour les routes/chemins 
avec un level > 0 (à voir si c'est faisable), exemple du parking aérien 
sur 2 niveaux :


http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.08312/-1.67948

Cordialement,

PanierAvide.


Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



--
Christian Quest - OpenStreetMap France


___
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] pulic_transport et rendu...

[Christian Quest]

J'ai regardé plus en détail la logique du modèle public_transport et
comment en tirer le meilleur pour le rendu.

On a donc 4 objets (du plus général au plus fin):
- stop_area
- station
- stop_position
- platform

En fonction du niveau de zoom du rendu, on devrait pouvoir se limiter à
certains objets:
- station pour les premiers niveaux (pour n'avoir que les gares, donc des
sites importants)
- stop_area pour les zoom intermédiaires
- stop_position pour zoom élevés (en gros là où les arrêts de bus
commencent à être rendus)
- platform pour le/les tout derniers zoom de détail

Est-ce que ceci vous semble cohérent ?

Le problème ensuite est de trouver la cohérence avec les tags "classiques".

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

Re: [OSM-talk-fr] osmose et adresses bis

[Philippe Verdy]

Plusieurs batiments à la même adresse postale (et cadastrale... mais pas
forcément fiscale!) ça s'appelle une résidence et c'est pour des
copropriétés. Elles ont alors leur propre numérotation interne des
résidents avec des numéros de portes, noms ou lettres de
batiments/escaliers/halls.

Pour la base adresse ces diférents points sont des assignations privées,
qui ne seront pas dans la base BANO qui ne connaitra que le numéro
postal/cadastral.

Le fisc cependant a besoin d'identifier les résidents et utilise alors les
autres indications: numéro d'appartement/porte, batiment/escalier/hall,
étage.

Mais en général on trouve presque toujours un numéro de porte/appartement,
lequel figure aussi sur les boites à lettres individuelles souvent (mais
pas toujours) regroupées au même endroit pour la même adresse postale
(certaines résidences regroupent les boites hall d'entrée par hall, la
numérotation interne de la résidence assigne des tranches de numéros
d'appartement selon le hall, souvent par centaines, les étages numérotant
les portes par dizaines et tout le monde s'y retrouve sans même avoir à
utiliser sur les adresses postales les noms/lettres d'immeubles ou halls
d'entrée...).

Ces numérotations étant privées, internes à la résidence/copropriété, ne
devraient même pas être dans OSM, sauf s'il y a un accès public (par
exemple pour géolocaliser un cabinet médiacal installé dans la résidence et
accessible aux visiteurs à ses heures d'ouverture. Mais on ne cartographie
pas directement les autres résidences privées non accessibles au public.
S'il y a un pas de porte commercial accessible en périphérie de la
copropriété avec son accès distinct, il suffit de mettre le POI mais il
n'est pas nécessaire du tout d'indiquer le numéro de porte privé: le seul
point d'adresse commun à la copro suffit.

S'il y a des cheminements accessibles au public (parkings privés, allées
piéton) on peut les mettre tout en indiquant que ce sont des accès privés
(ne pas oublier les restrictions): highway=service + service=alley par
exemple pour les accès en véhicule, et access=private (il peut y avoir
aussi un portail à ajouter, ouvert en journée mais fermé le soir ou le
week-end avec un automate pour l'ouvrir uniquement par les résidents.

Situation comparable à celle de nombre de centres commerciaux ou de
stations service (qui cependant ont rarement un portail, d'autant plus que
la plupart des stations ont des pompes automatiques 24/24 qui restent
ouvertes la nuit quand la station est fermée (paiement par CB uniquement
avec autorisation préalable avant de pouvoir se servir, et souvent avec une
télésurveillance qui détecte et photographie les véhicules ou piétons qui
entrent dans la zone privée de la station, la télésurveillance devant être
légalement signalée par un affichage près des pompes, et destinée à
prévenir des actes de malveillance).



Le 21 décembre 2016 à 16:50, Julien Lepiller  a écrit :

> Bon, ça ne m'avance pas tellement tout ça... Si je comprends bien, il n'y
> a pas de consensus concernant l'espace ou non. Concernant l'import depuis
> les données de Rennes Métropole, il faudrait le corriger pour qu'il inclue
> aussi les lettres (A, B, ...) des bâtiments. Dans l'immédiat, est-il
> possible de rendre osmose insensible aux espaces dans le numéro ?
>
> En parlant d'adresses en double et d'anecdote, je connais un cas où
> plusieurs bâtiments distincts ont la même adresse postale.
> https://www.openstreetmap.org/way/269025821 et
> https://www.openstreetmap.org/way/26902 sont tous les deux situés au
> 420, chemin des chaussièyes ainsi que les bâtiments voisins. Ce n'est
> d'ailleurs même pas le nom du chemin auquel ces bâtiments sont rattachés,
> mais d'un autre plus loin. Les boîtes aux lettres sont toutes regroupées
> plus loin, au niveau du croisement entre le chemin du Pélissier et le
> chemin sans nom qui donne à ces maisons. Comment devrais-je m'y prendre
> pour ajouter ces adresses ? Un point par maison, ou un seul point au niveau
> des boîtes aux lettres ?
>
> Le 2016-12-21 16:07, Mathias Jérôme a écrit :
>
>> Bien sûr des contre exemples il y aura à la pelle..j'énonçais
>> seulement des généralités et on aura aussi les 10-1 , 10-2 , 10-3 ,
>> 10-4 à la place de ce que voulez.
>> Ce qui est sûr c'est que c'est de la numérotation dans tous les cas,
>> ce qui plaide pour le mettre tout ce qui est numérotation avec la
>> numérotation (ou dans le même "mot" ce qui reviens au même).
>>
>> -
>>  DE : Florian_G 
>> À : Discussions sur OSM en français 
>> ENVOYÉ LE : Mercredi 21 décembre 2016 14h20
>> OBJET : Re: [OSM-talk-fr] osmose et adresses bis
>>
>> Hello,
>>
>> Le 20/12/2016 à 20:44, Mathias Jérôme a écrit :
>>
>> Les bis, ter etc... sont des indices de répétitions, mais les
>>> A,B,C etc... sont plutôt ce que j'appellerais des indices de
>>> déclinaisons (dans le cas du 36bis c'est que le 36 existe (ou
>>> existait) et est (était)  vraiment distinct, tandis que le 36A il
>>> est souvent si

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Francescu GAROBY]

Je trouve moi aussi que c'est très bien, cette estompe pour les choses
"souterraines" !
1 remarque toutefois : le rendu d'une voie souterraine n'a pas la même
couleur, selon que le bâtiment en surface a des murs ou pas ! Cf. la voie
souterraine, à coté du texte "Communauté d'agglomération Caen-la-Mer"
.
Je me rends bien compte que cela doit être dû à la couleur de la zone sans
mur "qui est l'allée principale de la galerie commerciale), mais du coup,
ça fait ressortir un tronçon...

Autre remarque : les entrées (entrance=main) ont un rendu qui n'est pas
clair : un simple point noir.



Francescu

Le 22 décembre 2016 à 09:51, PanierAvide  a écrit :

> Youpi, le premier rendu à considérer un minimum les objets indoor est le
> rendu FR :-) C'est pas mal l'idée d'estomper, moins agressif que le binaire
> afficher/cacher, tout en cachant quand même un peu ces objets qui ne sont
> pas au niveau du sol.
>
> Ce serait également pertinent d'adapter le rendu pour les routes/chemins
> avec un level > 0 (à voir si c'est faisable), exemple du parking aérien sur
> 2 niveaux :
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_
> 99740#18/48.08312/-1.67948
>
> Cordialement,
>
> PanierAvide.
>
> Le 21/12/2016 à 19:45, Christian Quest a écrit :
>
> Je profite des congés pour avancer sur le rendu FR...
>
> La liste des commit s'allonge et donne une idée des changements:
> https://github.com/cquest/osmfr-cartocss/commits/master
>
> Après avoir passé pas mal de temps sur les optimisations pour accélrer le
> rendu là où c'était le plus urgent, je suis de retour sur le côté graphique.
>
> Une grosse nouveauté: l'estompage des objets "indoor" qui devrait alléger
> les abords de certaines gares ;) Pour ça, le rendu considère tout objet
> avec un level=* négatif comme indoor.
>
> Les "shield" sur les routes sont mieux répartis. Pour cela, la requête SQL
> regroupe les différents tronçons ayant le même highway+ref car vu qu'on
> tronçonne de plus en plus il faut en passer par là !
>
> Résultat visible sur http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_
> 99740#6/47.376/2.186
>
> Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo et
> peut nécessiter un délais de génération...
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] pulic_transport et rendu...

[PanierAvide]

J'aurais inversé stop_position et platform, d'un point de vue 
information usager c'est plus important de savoir où attendre (platform) 
plutôt que où le bus va s'arrêter (stop_position).


Cordialement,

PanierAvide.


Le 22/12/2016 à 09:56, Christian Quest a écrit :
J'ai regardé plus en détail la logique du modèle public_transport et 
comment en tirer le meilleur pour le rendu.


On a donc 4 objets (du plus général au plus fin):
- stop_area
- station
- stop_position
- platform

En fonction du niveau de zoom du rendu, on devrait pouvoir se limiter 
à certains objets:
- station pour les premiers niveaux (pour n'avoir que les gares, donc 
des sites importants)

- stop_area pour les zoom intermédiaires
- stop_position pour zoom élevés (en gros là où les arrêts de bus 
commencent à être rendus)

- platform pour le/les tout derniers zoom de détail

Est-ce que ceci vous semble cohérent ?

Le problème ensuite est de trouver la cohérence avec les tags 
"classiques".


--
Christian Quest - OpenStreetMap France


___
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] osmose et adresses bis

[Philippe Verdy]

La seule raison réglementaire qui vaille c'est pour le fisc: il taxe
séparément les propriétés/copropriétés (pour la taxe foncière) et les
résidents individuels (taxes locatives, redevance télé). Les collectivités
en général taxent la copropriété concernant le ramassage des ordures
ménagères ou l'assainissement, et c'est la copro qui refecture les
résidents dans leurs charges sur la base des quantièmes.

La loi obligeant maintenant d'avoir des compteurs individuels pour l'eau et
l'énergie, les résidents sont identifiés séparément de la copropriété pour
leurs propre consommation. Cependant la copropriété peut encore être
facturée de l'ensemble, les résidents payant ensuite leur consommation
propre dans leurs charges. Mais souvent ils demandent de pouvoir choisir
leur fournisseur d'énergie, et dans ce cas l'électricité ou le gaz sont
séparés (il y a encore des consommations partagées dans les charges
concernant les parties communes ou l'eau utilisée pour l'entretien des
parties communes ou des extérieurs).

Mais ces infos d'individualisation sont des infos privées liant les
résidents à leur fournisseur (et indirectement au réseau de distribution)
et ne sont pas des données publiques qu'on peur utiliser dans OSM. Il ne
reste donc que les numéros de portes des résidents professionnels disposant
d'un accueil du public (commerces, cabinets médicaux et services divers),
dont on connaitre le numéro de porte uniquement parce qu'ils le publient ou
parce qu'on peut aller le voir sur place. Mais on ne verra pas ça dans le
cadastre.


Le 21 décembre 2016 à 19:19, Christian Quest  a
écrit :

> Un peu d'explication: Rennes Métropole différencie en fait la notion
> d'adresse et de bâtiment aussi pour une raison réglementaire très simple:
> - les numéros d'adresses (y compris bis/ter) sont attribué officiellement
> par le maire de la commune
> - les autres extensions (A/B/C/D pour différencier des bâtiments) ne sont
> pas forcément attribuées par le maire.
>
> Est-ce que des A/B/C/D sont attribués par des maires ? OUI, aussi, donc on
> ne peut pas généraliser ce qui se fait à Rennes.
>
> Il n'y a aucun règle en la matière, malheureusement.
>
>
> Le 21 décembre 2016 à 16:50, Julien Lepiller  a écrit :
>
>> Bon, ça ne m'avance pas tellement tout ça... Si je comprends bien, il n'y
>> a pas de consensus concernant l'espace ou non. Concernant l'import depuis
>> les données de Rennes Métropole, il faudrait le corriger pour qu'il inclue
>> aussi les lettres (A, B, ...) des bâtiments. Dans l'immédiat, est-il
>> possible de rendre osmose insensible aux espaces dans le numéro ?
>>
>> En parlant d'adresses en double et d'anecdote, je connais un cas où
>> plusieurs bâtiments distincts ont la même adresse postale.
>> https://www.openstreetmap.org/way/269025821 et
>> https://www.openstreetmap.org/way/26902 sont tous les deux situés au
>> 420, chemin des chaussièyes ainsi que les bâtiments voisins. Ce n'est
>> d'ailleurs même pas le nom du chemin auquel ces bâtiments sont rattachés,
>> mais d'un autre plus loin. Les boîtes aux lettres sont toutes regroupées
>> plus loin, au niveau du croisement entre le chemin du Pélissier et le
>> chemin sans nom qui donne à ces maisons. Comment devrais-je m'y prendre
>> pour ajouter ces adresses ? Un point par maison, ou un seul point au niveau
>> des boîtes aux lettres ?
>>
>> Le 2016-12-21 16:07, Mathias Jérôme a écrit :
>>
>>> Bien sûr des contre exemples il y aura à la pelle..j'énonçais
>>> seulement des généralités et on aura aussi les 10-1 , 10-2 , 10-3 ,
>>> 10-4 à la place de ce que voulez.
>>> Ce qui est sûr c'est que c'est de la numérotation dans tous les cas,
>>> ce qui plaide pour le mettre tout ce qui est numérotation avec la
>>> numérotation (ou dans le même "mot" ce qui reviens au même).
>>>
>>> -
>>>  DE : Florian_G 
>>> À : Discussions sur OSM en français 
>>> ENVOYÉ LE : Mercredi 21 décembre 2016 14h20
>>> OBJET : Re: [OSM-talk-fr] osmose et adresses bis
>>>
>>> Hello,
>>>
>>> Le 20/12/2016 à 20:44, Mathias Jérôme a écrit :
>>>
>>> Les bis, ter etc... sont des indices de répétitions, mais les
 A,B,C etc... sont plutôt ce que j'appellerais des indices de
 déclinaisons (dans le cas du 36bis c'est que le 36 existe (ou
 existait) et est (était)  vraiment distinct, tandis que le 36A il
 est souvent situé au situé au 36, de même que le 36B se situera
 aussi au 36 , de fait les A,B,C,etc... sont souvent de la
 numérotation d'ordre "privative" : accès ou cages d'escaliers).

>>>
>>> Petit contre-exemple :
>>>
>>> *
>>> OSM :
>>> http://www.openstreetmap.org/way/253831784#map=19/49.13026/6.15980
>>> * Google :
>>> https://www.google.fr/maps/@49.130211,6.1595164,3a,51y,332.2
>>> 6h,91.02t/data=!3m6!1e1!3m4!1soFRU1NinEVLGt68Nufyx0A!2e0!7i1
>>> 3312!8i6656!6m1!1e1
>>>
>>> Ce 13 A aurait pu être un 13 bis, mais c'est bien un 13 A, autonome,
>>> distinct et non dépendant du 13 (qui est bien une autre maison). Les
>>> parcelles 

Re: [OSM-talk-fr] pulic_transport et rendu...

[Francescu GAROBY]

Je rejoins PanierAvide sur l'inversion stop_position/platform, pour la même
raison que lui.
D'ailleurs, indiquer où le bus/tram/... s'arrête ne me paraît pas vraiment
utile, sur une carte généraliste.

Francescu

Le 22 décembre 2016 à 10:06, PanierAvide  a écrit :

> J'aurais inversé stop_position et platform, d'un point de vue information
> usager c'est plus important de savoir où attendre (platform) plutôt que où
> le bus va s'arrêter (stop_position).
>
> Cordialement,
>
> PanierAvide.
>
> Le 22/12/2016 à 09:56, Christian Quest a écrit :
>
> J'ai regardé plus en détail la logique du modèle public_transport et
> comment en tirer le meilleur pour le rendu.
>
> On a donc 4 objets (du plus général au plus fin):
> - stop_area
> - station
> - stop_position
> - platform
>
> En fonction du niveau de zoom du rendu, on devrait pouvoir se limiter à
> certains objets:
> - station pour les premiers niveaux (pour n'avoir que les gares, donc des
> sites importants)
> - stop_area pour les zoom intermédiaires
> - stop_position pour zoom élevés (en gros là où les arrêts de bus
> commencent à être rendus)
> - platform pour le/les tout derniers zoom de détail
>
> Est-ce que ceci vous semble cohérent ?
>
> Le problème ensuite est de trouver la cohérence avec les tags "classiques".
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Nicolas Moyroud]

Salut,

Merci Christian pour ce travail de fou sur le rendu FR !

Une remarque qui n'est pas directement liée au rendu FR, mais plutôt à 
la couche "zones à mapper" sur tile fr. Il y a toujours des communes qui 
s'affichent avec le rond vert/bleu des bâtiments manquants alors qu'elle 
sont totalement renseignées en bati. Exemples :

http://tile.openstreetmap.fr/?zoom=15&lat=43.73936&lon=3.8602&layers=B000TF
http://tile.openstreetmap.fr/?zoom=16&lat=43.56325&lon=3.28654&layers=B000TF
http://tile.openstreetmap.fr/?zoom=15&lat=43.62998&lon=3.24387&layers=B000TF
Le problème c'est que dans l'Hérault il ne reste plus beaucoup de 
communes à faire. Du coup, avec tout ce bruit la couche n'aide plus à 
savoir où il reste vraiment du travail...


Tant qu'à signaler un petit souci dans les outils d'aide à la 
contribution, j'en profite aussi au passage pour demander une 
amélioration concernant l'outil "voies récentes manquantes" 
(http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html).
Dans la liste par département, ça affiche les 50 occurrences les plus 
récentes, mais on ne peut malheureusement pas naviguer vers la suite. Le 
problème c'est que maintenant dans l'Hérault je suis presque à la fin de 
la liste parce qu'il y a plein de rues que je n'ai jamais réussi à 
trouver (même en cherchant beaucoup) et donc que je ne peux pas faire. 
Donc je vais bientôt être bloqué. Si c'était possible de prévoir un 
bandeau de navigation "page suivante / page précédente" ce serait super !


Nicolas


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Vincent de Château-Thierry]

Salut Nicolas et tous,

Le 22/12/2016 à 10:31, Nicolas Moyroud a écrit :


Tant qu'à signaler un petit souci dans les outils d'aide à la
contribution, j'en profite aussi au passage pour demander une
amélioration concernant l'outil "voies récentes manquantes"
(http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html).
Dans la liste par département, ça affiche les 50 occurrences les plus
récentes, mais on ne peut malheureusement pas naviguer vers la suite. Le
problème c'est que maintenant dans l'Hérault je suis presque à la fin de
la liste parce qu'il y a plein de rues que je n'ai jamais réussi à
trouver (même en cherchant beaucoup) et donc que je ne peux pas faire.
Donc je vais bientôt être bloqué. Si c'était possible de prévoir un
bandeau de navigation "page suivante / page précédente" ce serait super !


J'aurais aimé caser ça avant Noël, mais de façon plus réaliste ce sera 
pour la rentrée.


vincent

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Jérôme Amagat]

Le 22 déc. 2016 03:03, "Christian Quest"  a écrit :

Le 22 décembre 2016 à 01:05, Jérôme Amagat  a
écrit :

> on parle beaucoup des transport public en ce moment, ça serait bien que
> les arrets de bus, tram metro ... soit rendu qu'avec des tag
> public_transport= et aussi si ce n'est pas un node mais un way ou
> multipolygon.
>

>

Je ne pense pas que ce soit une bonne idée de forcer ainsi la main pour
adopter un modèle bien complexe pour le contributeur lambda.


Oups, je me suis mal exprimé. Je voulais dire qu'il faudrait que les arrêts
qu'avec le nouveau schéma public transport soit rendu comme ceux avec les
plus anciens tags. Et oui garder le rendu pour les anciens tags.


Si on veut détecter les arrêts à mettre à jour, il faut le faire avec des
outils de QA comme osmose, pas avec un rendu assez généraliste.


Pour la prise en compte des polygones, je vais regarder ce qu'il est
possible de faire, mais mes souvenirs c'est qu'il est bien complexe de
prendre en compte le schéma public_transport au niveau du rendu.

On met quoi sur le rendu ? public_transport=stop_position ou
public_transport=platform ?

Si on a un highway=bus_stop comment on évite d'avoir un doublon ?

Heureusement que postgis a maintenant de quoi générer des cluster... ça va
peut être être la solution: on met tout ensemble et on fait un cluster ;)

-- 
Christian Quest - OpenStreetMap France

___
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] Rendu FR, bientôt en version 2017 !

[Nicolas Moyroud]

J'aurais aimé caser ça avant Noël, mais de façon plus réaliste ce sera 
pour la rentrée.
Le petit papa Vincent sera donc un peu en retard par rapport à son 
homologue vêtu de rouge. Alors ce sera un cadeau de nouvelle année ! ;-)

J'ai d'autres trucs pour m'occuper de toute façon...

Nicolas

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

Re: [OSM-talk-fr] pulic_transport et rendu...

[osm . sanspourriel]

Nicolas, quand tu as fini avec l'Hérault, tu peux passer à un autre 
département ;-).


Je pense que Christian a voulu dire : si on a les deux informations, à 
un niveau où on ne voit pas les trottoirs, autant mettre un seul point 
pour les deux arrêts au niveau de la rue.


Sinon je suis d'accord avec vous : stop_position ne sert pas au grand 
public.


Jean-Yvon


Le 22/12/2016 à 10:21, Francescu GAROBY - windu...@gmail.com a écrit :
Je rejoins PanierAvide sur l'inversion stop_position/platform, pour la 
même raison que lui.
D'ailleurs, indiquer où le bus/tram/... s'arrête ne me paraît pas 
vraiment utile, sur une carte généraliste.


Francescu

Le 22 décembre 2016 à 10:06, PanierAvide > a écrit :


J'aurais inversé stop_position et platform, d'un point de vue
information usager c'est plus important de savoir où attendre
(platform) plutôt que où le bus va s'arrêter (stop_position).

Cordialement,

PanierAvide.


Le 22/12/2016 à 09:56, Christian Quest a écrit :

J'ai regardé plus en détail la logique du modèle public_transport
et comment en tirer le meilleur pour le rendu.

On a donc 4 objets (du plus général au plus fin):
- stop_area
- station
- stop_position
- platform

En fonction du niveau de zoom du rendu, on devrait pouvoir se
limiter à certains objets:
- station pour les premiers niveaux (pour n'avoir que les gares,
donc des sites importants)
- stop_area pour les zoom intermédiaires
- stop_position pour zoom élevés (en gros là où les arrêts de bus
commencent à être rendus)
- platform pour le/les tout derniers zoom de détail

Est-ce que ceci vous semble cohérent ?

Le problème ensuite est de trouver la cohérence avec les tags
"classiques".

-- 
Christian Quest - OpenStreetMap France



___
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
 


--
Francescu

___
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] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Le 22/12/2016 à 02:53, Christian Quest - cqu...@openstreetmap.fr a écrit :

Le 21 décembre 2016 à 23:56, > a écrit :


Niveau 11


:

et sans doute ailleurs : pas de repliement de ligne sue la BAN de
Lann-Bihoué mais sur Guidel-Plages.


?? lien ??

Voir ci-dessus !
Tiens on pourrait ajouter B.A.N. en abréviation de Base d'aéronautique 
navale**



Pourtant le nom déborde de la zone militaire.


ça , les noms peuvent déborder si la forme est très allongée. La 
taille du texte varie avec la surface du polygone, mais pas en prenant 
compte sa largeur et/ou hauteur.
Sauf que pour Guidel-Plages il y a repliement de ligne et pas pour "Base 
d'aéronautique navale de Lann-Bihoué" qui est particulièrement long.




http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.38764/-4.46565




Difficile avec les voies à chaussées séparées. Ce sont deux lignes 
distinctes et pas facile de les fusionner en une seule...
Bah, on va bien trouver quelqu'un pour nous pondre un schéma highway V2 
incompatible avec le précédent ;-).

Mais en dessous la Rue de Kiel n'est pas à chaussée-séparée.


Aller dans le détail des intersections comme tu le suggère n'est pas 
simple non plus... j'imagine la complexité des requêtes pour obtenir 
ces infos !

Ne nous abaissons pas à un simple problème d'algorithmique :-D
Oui, pour que ça marche bien il faut laisser le client afficher au moins 
la partie textuelle par un tuilage vectoriel.


> Un polygone englobant toute l'emprise du collège est bien sûr la 
solution parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est 
une cour, un parking, des terrains de sport, etc... j'ai corrigé.

Merci.


Rendu ou données incorrectes ?

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/48.39896/-4.40997


http://www.openstreetmap.org/#map=19/48.39886/-4.40977



Là je sèche...

Beaucoup de considérations à celui ou celle qui trouvera !

Au sud-ouest du rond-point : "Collège Priv. Diwan Penn ar Bed".
Pourquoi cette abréviation qui ne fait guère gagner de place ? De plus 
la version "longue" tenait largement dans l'emplacement.
Et en plus Diwan aurait bien aimé être public, mais c'est une autre 
histoire.


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Florian LAINEZ]

Bon boulot Christian, ravi de voir que le rendu avance.

Concernant le indoor tu dis que les objets en sous-sol ont disparus mais je
vois toujours la gare sous-terraine de Magenta ;)
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.88077/2.35857
Les données sont pourtant bien tagguées avec un level négatif.

Autre remarque : afficher les entrance sans visualiser les espaces
intérieurs, ça donne ça sur Montparnasse :
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062

Tu remarqueras que je me plains sans apporter de solution !

sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
afficher

+1

Le 22 décembre 2016 à 13:11,  a écrit :

> Le 22/12/2016 à 02:53, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Le 21 décembre 2016 à 23:56,  a écrit :
>
> Niveau 11
>> 
>> :
>>
>> et sans doute ailleurs : pas de repliement de ligne sue la BAN de
>> Lann-Bihoué mais sur Guidel-Plages.
>>
>
> ?? lien ??
>
> Voir ci-dessus !
> Tiens on pourrait ajouter B.A.N. en abréviation de Base d'aéronautique
> navale
>
>
>
>> Pourtant le nom déborde de la zone militaire.
>>
>
> ça , les noms peuvent déborder si la forme est très allongée. La taille du
> texte varie avec la surface du polygone, mais pas en prenant compte sa
> largeur et/ou hauteur.
>
> Sauf que pour Guidel-Plages il y a repliement de ligne et pas pour "Base
> d'aéronautique navale de Lann-Bihoué" qui est particulièrement long.
>
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
>> 740#17/48.38764/-4.46565
>>
>
> Difficile avec les voies à chaussées séparées. Ce sont deux lignes
> distinctes et pas facile de les fusionner en une seule...
>
> Bah, on va bien trouver quelqu'un pour nous pondre un schéma highway V2
> incompatible avec le précédent ;-).
> Mais en dessous la Rue de Kiel n'est pas à chaussée-séparée.
>
>
> Aller dans le détail des intersections comme tu le suggère n'est pas
> simple non plus... j'imagine la complexité des requêtes pour obtenir ces
> infos !
>
> Ne nous abaissons pas à un simple problème d'algorithmique :-D
> Oui, pour que ça marche bien il faut laisser le client afficher au moins
> la partie textuelle par un tuilage vectoriel.
>
> > Un polygone englobant toute l'emprise du collège est bien sûr la
> solution parce qu'en plus un collège ce n'est pas qu'un bâtiment, c'est une
> cour, un parking, des terrains de sport, etc... j'ai corrigé.
> Merci.
>
>
>
>> Rendu ou données incorrectes ?
>> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
>> 740#19/48.39896/-4.40997
>> http://www.openstreetmap.org/#map=19/48.39886/-4.40977
>>
>>
> Là je sèche...
>
> Beaucoup de considérations à celui ou celle qui trouvera !
>
> Au sud-ouest du rond-point : "Collège Priv. Diwan Penn ar Bed".
> Pourquoi cette abréviation qui ne fait guère gagner de place ? De plus la
> version "longue" tenait largement dans l'emplacement.
> Et en plus Diwan aurait bien aimé être public, mais c'est une autre
> histoire.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

[OSM-talk-fr] site cadastre.openstreetmap.fr

[Laurent Combe]

A partir de ce site
http://cadastre.openstreetmap.fr/
ou de
http://cadastre.openstreetmap.fr/fantoir

je ne vois pas de lien vers les listes départementales (citées
récemment par nicolas)
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html

àm on humble avis, ce serait un plus d'avoir à partir du site accès à
l'ensemble des outils disponibles (par un simple lien)

autre point
sur la page d'accueil http://cadastre.openstreetmap.fr/ il y a bien un
lien vers le wiki mais qui pointe sur la page qui décrit l'historique
de nos relations avec la DgFiP

il manque à mon avis un lien vers la page du wiki : comment contribuer à la BANO
http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO


Laurent

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[JB]

Salut Christian,
Sacré boulot que tu fais là !
Par contre, en zone rurale (mon dada), le rendu international a bien 
avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale 
: la réorganisation des tirets selon le tracktype serait très bienvenue, 
la progression actuelle étant incohérente pour le tracktype=grade4. 
(Sinon, le boulot fait sur les path/footway est intéressant aussi)
Voilà voilà, n'hésite pas à différencier encore un peu plus les locality 
des autres lieu-dits (j'aurais mis un coup de font-stretch ou son 
équivalent s'il existe sur mapnik sur les locality, par exemple).

JB.

Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



--
Christian Quest - OpenStreetMap France


___
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] Rendu FR, bientôt en version 2017 !

[Jean-Claude Repetto]

Le 22/12/2016 à 15:40, JB a écrit :
> Salut Christian,
> Sacré boulot que tu fais là !
> Par contre, en zone rurale (mon dada), le rendu international a bien
> avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale
> : la réorganisation des tirets selon le tracktype serait très bienvenue,
> la progression actuelle étant incohérente pour le tracktype=grade4.
> JB.
> 

Bonjour,

En ce qui concerne les pistes(highway=track), je pense que la priorité
serait de leur donner une épaisseur, comme sur la carte
http://maps.refuges.info/ .
En effet, la représentation filaire actuelle est trompeuse et devrait
être réservée aux sentiers (highway=path).

Jean-Claude


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

[OSM-talk-fr] Contributeur du mois: Philippe Verdy

[Marc Gemis]

Bonsoir,

Dans notre série "Contributeur du mois" [1] nous avons une entrevue
avec Philippe Verdy:
http://www.openstreetmap.org/user/escada/diary/40120

m.

[1] 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Belgian_Mapper_of_the_Month

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Christian Quest]

Le 22 décembre 2016 à 15:19, Florian LAINEZ  a écrit :

> Bon boulot Christian, ravi de voir que le rendu avance.
>
> Concernant le indoor tu dis que les objets en sous-sol ont disparus mais
> je vois toujours la gare sous-terraine de Magenta ;)
> http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99
> 740#17/48.88077/2.35857
> Les données sont pourtant bien tagguées avec un level négatif.
>
>

Les shop=* n'avaient pas droit à ce traitement, mais pour le reste j'ai
vérifié avec les données et ça estompe bien si level<0.




> Autre remarque : afficher les entrance sans visualiser les espaces
> intérieurs, ça donne ça sur Montparnasse : http://umap.openstreetmap.fr/f
> r/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062
>
> Tu remarqueras que je me plains sans apporter de solution !
>
>
Effectivement, ça pique un peu, mais bon, c'est pas nouveau. :(



> sans discussion, ce sont les platform (=anciens bux_stop) qu'il faut
> afficher
>
> +1
>
>
On continue sur l'autre fil pour ça...


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

Re: [OSM-talk-fr] cartes.xyz / bad request

[Florian LAINEZ]

Merci, j'ai mis à jour la requête
https://www.cartes.xyz/t/fcd984-Bornes_Trilib#
Les données devraient apparaitre lorsque le cache se mettra à jour ... y
a-t-il moyen de forcer cela ? ça serait très utile ...

Je profite de ce fil de discussion sur MapContrib pour vous dire que la
version 1.0.0 pourrait arriver par la cheminée ce week-end

Huge !! Encore bravo pour ce boulot extra Guillaume.

Question subsidiaire : je n'arrive pas à afficher une image pour chaque
type de POI, comme tu l'avais fait la dernière fois pour mon exemple du
covoiturage. Où est-ce caché ?
Y a-t-il moyen de définir une image pour chaque POI individuellement ? En
attendant que cela soit géré dynamiquement ;)
Merci


Le 21 décembre 2016 à 20:55, Guillaume AMAT  a écrit :

> Pas mieux, merci Éric pour la réponse.
>
> Je profite de ce fil de discussion sur MapContrib pour vous dire que la
> version 1.0.0 pourrait arriver par la cheminée ce week-end, mais chut ^^
>
> Bon réveillon à tous,
> Guillaume
>
> Le 21/12/2016 à 20:39, Éric Gillet a écrit :
>
> Le 21 décembre 2016 à 19:53, Florian LAINEZ  a écrit :
>
>> Désolé de relancer le sujet mais j'ai créé une nouvelle carte des bornes
>> Trilib' à Paris https://www.cartes.xyz/t/fcd984-Bornes_Trilib
>> Cette fois j'ai bien retenu la leçon et je n'ai pas mis de requête
>> overpass-turbo mais bien une requête API overpass.
>> J'ai toujours le même soucis : bad request ... help !
>>
>
> Il faut mettre la requête Overpass en elle-même et pas une URL vers l'API
> Overpass :
> https://www.cartes.xyz/t/34563d-MapContrib
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[Christian Quest]

Le 22 décembre 2016 à 17:16, Christian Quest  a
écrit :

> Le 22 décembre 2016 à 15:19, Florian LAINEZ  a écrit :
>
>>
>> Autre remarque : afficher les entrance sans visualiser les espaces
>> intérieurs, ça donne ça sur Montparnasse : http://umap.openstreetmap.fr/f
>> r/map/preview-rendu-fr-2017_99740#18/48.84084/2.32062
>>
>> Tu remarqueras que je me plains sans apporter de solution !
>>
>>
> Effectivement, ça pique un peu, mais bon, c'est pas nouveau. :(
>


Humm... ça pique vraiment:
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#17/48.86067/2.33558

Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle,
entrée... ça me démange de rendre ça visible ;)


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

Re: [OSM-talk-fr] Contributeur du mois: Philippe Verdy

[Marc SIBERT]

Bonjour,

Je n'aurais qu'un mot : édifiant.

A+

On 22/12/2016 16:46, Marc Gemis wrote:

Bonsoir,

Dans notre série "Contributeur du mois" [1] nous avons une entrevue
avec Philippe Verdy:
http://www.openstreetmap.org/user/escada/diary/40120

m.

[1] 
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Belgian_Mapper_of_the_Month

___
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] Rendu FR, bientôt en version 2017 !

[PanierAvide]

Le 22/12/2016 à 17:24, Christian Quest a écrit :
Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle, 
entrée... ça me démange de rendre ça visible ;)


Genre comme ça :
http://dev.openlevelup.net/?l=1#19/48.86059/2.33575

#placement produit :-)

Cordialement,

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

Re: [OSM-talk-fr] site cadastre.openstreetmap.fr

[Tyndare]

J'ai rajouté les liens que tu mentionnent sur 
http://cadastre.openstreetmap.fr/


Mais Hélène Petit m'avais fait remarquer que cette page n'est pas très 
simple pour ceux qui la découvrent pour la première fois, et à force de 
rajouter des trucs ça ne s'améliore pas.


Si quelqu'un a une proposition a faire qui rendrait cette page plus 
claire (quitte à découper en plusieurs sous pages), surtout n'hésitez pas.



Le 22/12/2016 à 15:32, Laurent Combe a écrit :

A partir de ce site
http://cadastre.openstreetmap.fr/
ou de
http://cadastre.openstreetmap.fr/fantoir

je ne vois pas de lien vers les listes départementales (citées
récemment par nicolas)
http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html

àm on humble avis, ce serait un plus d'avoir à partir du site accès à
l'ensemble des outils disponibles (par un simple lien)

autre point
sur la page d'accueil http://cadastre.openstreetmap.fr/ il y a bien un
lien vers le wiki mais qui pointe sur la page qui décrit l'historique
de nos relations avec la DgFiP

il manque à mon avis un lien vers la page du wiki : comment contribuer à la BANO
http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO


Laurent

___
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] cartes.xyz / bad request

[Vincent Bergeot]

Bonjour,
suite à nos échanges privés, le résultat pour tout le monde néanmoins !

Le 22/12/2016 à 17:19, Florian LAINEZ a écrit :
Y a-t-il moyen de définir une image pour chaque POI individuellement ? 
En attendant que cela soit géré dynamiquement ;)


c'est le cas, en faisant un appel de l'image avec la valeur du tag 
mapillary :

![](https://d1cuyjsrcm0gby.cloudfront.net/{mapillary}/thumb-640.jpg)

Visible ici : https://www.cartes.xyz/t/2519bc-Les_bornes_trilib_pour_Florian

bonnes fêtes :)

--
Vincent Bergeot


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

Re: [OSM-talk-fr] Rendu FR, bientôt en version 2017 !

[osm . sanspourriel]

Et aussi pour l'exemple à ne pas imiter :
http://dev.openlevelup.net/?l=0#18/48.85987/2.33761
Plusieurs salles portent le même nom, il faudrait mieux définir un 
multipolygone avec un seul nom.


Au fait, Christian, c'est sympa pour les aveugles, tu as fait une carte 
en braille :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.85987/2.33761

Adrien, quand il y a plusieurs niveaux superposés on aimerait savoir 
s'il y a une information pertinente.
Par exemple à côté il y a l'Église Saint-Leu - Saint-Gilles 
http://www.openstreetmap.org/way/53933240 par exemple qui apparaît à 
plusieurs niveaux mais il n'y a aucune information spécifique.
Donc présenter les niveaux 3 et 4 qui sont identiques n'apporte guère 
d'info (3-4 suffirait).
LevelUp c'est super quand diverses couches se superposent. Si c'est 
juste l'épaisseur d'une couche, sauf à prendre une vue 3D (isométrique 
par exemple) ça n'a pas un intérêt fou pour l'utilisateur final (au plus 
un +/- sur les bâtiments pour savoir ceux qui continuent au dessus/en 
dessous???).
Oui, je me vois ici comme utilisateur, je laisse l'algorithmique de côté 
;-).


Jean-Yvon

Le 22/12/2016 à 18:02, PanierAvide - panierav...@riseup.net a écrit :

Le 22/12/2016 à 17:24, Christian Quest a écrit :
Tout le Musée du Louvre est hyper détaillé en indoor... chaque salle, 
entrée... ça me démange de rendre ça visible ;)


Genre comme ça :
http://dev.openlevelup.net/?l=1#19/48.86059/2.33575

#placement produit :-)

Cordialement,

PanierAvide.


___
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] Rendu FR, bientôt en version 2017 !

[PanierAvide]

C'est prévu dans la liste des améliorations de n'afficher que les 
niveaux qui ont un intérêt pour l'utilisateur final (dans la version de 
base) ;-)


Cordialement.


Le 22/12/2016 à 19:19, osm.sanspourr...@spamgourmet.com a écrit :

Et aussi pour l'exemple à ne pas imiter :
http://dev.openlevelup.net/?l=0#18/48.85987/2.33761
Plusieurs salles portent le même nom, il faudrait mieux définir un 
multipolygone avec un seul nom.


Au fait, Christian, c'est sympa pour les aveugles, tu as fait une 
carte en braille :

http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#18/48.85987/2.33761

Adrien, quand il y a plusieurs niveaux superposés on aimerait savoir 
s'il y a une information pertinente.
Par exemple à côté il y a l'Église Saint-Leu - Saint-Gilles 
http://www.openstreetmap.org/way/53933240 par exemple qui apparaît à 
plusieurs niveaux mais il n'y a aucune information spécifique.
Donc présenter les niveaux 3 et 4 qui sont identiques n'apporte guère 
d'info (3-4 suffirait).
LevelUp c'est super quand diverses couches se superposent. Si c'est 
juste l'épaisseur d'une couche, sauf à prendre une vue 3D (isométrique 
par exemple) ça n'a pas un intérêt fou pour l'utilisateur final (au 
plus un +/- sur les bâtiments pour savoir ceux qui continuent au 
dessus/en dessous???).
Oui, je me vois ici comme utilisateur, je laisse l'algorithmique de 
côté ;-).


Jean-Yvon



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

Re: [OSM-talk-fr] site cadastre.openstreetmap.fr

[Laurent Combe]

merci
et
parfait pour moi

si un débutant sur Toulouse se plaint de la complexité de la page vous
me l'envoyez et je le formerai :-)

Laurent


Le 22 décembre 2016 à 18:24, Tyndare  a écrit :
>
> J'ai rajouté les liens que tu mentionnent sur
> http://cadastre.openstreetmap.fr/
>
> Mais Hélène Petit m'avais fait remarquer que cette page n'est pas très
> simple pour ceux qui la découvrent pour la première fois, et à force de
> rajouter des trucs ça ne s'améliore pas.
>
> Si quelqu'un a une proposition a faire qui rendrait cette page plus claire
> (quitte à découper en plusieurs sous pages), surtout n'hésitez pas.
>
>
>
> Le 22/12/2016 à 15:32, Laurent Combe a écrit :
>>
>> A partir de ce site
>> http://cadastre.openstreetmap.fr/
>> ou de
>> http://cadastre.openstreetmap.fr/fantoir
>>
>> je ne vois pas de lien vers les listes départementales (citées
>> récemment par nicolas)
>> http://cadastre.openstreetmap.fr/fantoir/voies_recentes_manquantes.html
>>
>> àm on humble avis, ce serait un plus d'avoir à partir du site accès à
>> l'ensemble des outils disponibles (par un simple lien)
>>
>> autre point
>> sur la page d'accueil http://cadastre.openstreetmap.fr/ il y a bien un
>> lien vers le wiki mais qui pointe sur la page qui décrit l'historique
>> de nos relations avec la DgFiP
>>
>> il manque à mon avis un lien vers la page du wiki : comment contribuer à
>> la BANO
>> http://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO
>>
>>
>> Laurent
>>
>> ___
>> 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] question osmose/limite administrative

[osm . sanspourriel]

Le 21/12/2016 à 01:56, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

Moi ce que j'ai compris aux lois françaises sachant que je vis très 
loin de toute les mers et océans :) c'est ça :
tu parles beaucoup des eaux intérieurs mais j'ai l'impression que ce 
terme a une définition mais dans la réalité ne sert à rien. Rien ne 
s'applique qu'aux eaux intérieurs.

C'est essentiellement exact pour les eaux intérieures au sens légal.
Je parlais surtout des eaux intérieures au sens OSM (ce qui est à 
l'intérieur du trait de côte 95 natural=coastline).


> qui le reste (dans le domaine maritime public).
ou pas. Par exemple le port de commerce de Brest a été revu pour que 
tout soit sous la même administration. Car si une zone est 
définitivement perdue pour la mer, elle finit par changer de statut.
Par contre pour osm la ligne natural=coastline pour moi c'est pas 
claire du tout où elle se trouve.
C'est bien ça mon problème, tu vois un terrien peut bien intervenir sur 
le sujet (j'interviens bien sur des poubelles à Paris ;-)).


Dans le cas "normal" elle devrait être, d’après le wiki, au niveau de 
la "mean high water spring" (j'ai pas compris ce que c’était) ce qui 
correspond (toujours d’après le wiki) à la limite des débris que l'on 
voit sur les photo aérienne sur les plages.

Ça c'est presque simple : c'est la marée haute de coefficient 95.

Et pour le cas des estuaires, il n'y a pas de règle est des fois la 
limite est au niveau d'un pont ou s'enfonce pas du tout dans les terre 
ou s'enfonce beaucoup.

Exactement. Pas de critère objectif. *C'est bien ça que j'aimerais éviter.*
Et ce n'est pas un détail : les eaux intérieures n'apparaissent pas dans 
OpenStreetMapData  qui sert pour les 
petits niveaux de zoom.
Du coup on voit le fin-fond de certains abers mais la Loire de 
Saint-Nazaire à Nantes a disparu. Pourtant des bateaux de haute mer 
remontent le fleuve.


pour les communes littorales, ce que j'ai rapidement comprit c'est que 
au niveau des estuaires il n'y a pas d’obligation que la commune qui a 
quand même l'influence de la marée mais pas l’océan à ses frontières 
soit une commune littorales.
C'est assez vaseux (sans jeu de mot) et un pont a été cédé à une commune 
pour que l'autre ne soit plus une commune littorale. C'est ça. En 
général si la commune a un lien avec la mer (non anecdotique) elle est 
littorale. Quimperlé connaît bien les marées (inondations) mais n'est 
pas une commune littorale (l'eau n'est jamais salée même si le niveau de 
la Laïta varie lors des grandes marées).


J'ai lu sur le wiki par contre que limite de pays et limite des cote 
donc boundary=administrative au niveau du bord de mer n'est pas 
obligatoirement au même endroit que natural=coastline. (mais je trouve 
que c'est plus simple et clair d'avoir qu'une seul "frontière")

Là ce serait plutôt entre commune et état.
On voit que sur le cadastre à peu près à l'endroit indiqué 
 
sur les cadastres ils passent de deux communes séparées par un fleuve à 
une seule commune.

Ça me semble être un bon endroit pour le faire.

Pour objectiver un peu la manip' je propose que l'on s'arrête là où les 
cartes marines détaillées (mieux que 1:5) s'arrêtent.
Ici les cartes 7138 et 7140 : 
http://diffusion.shom.fr/searchproduct/product/configure/id/202.

Mais j'ajouterai les rives ouest de l'Elorn (Kerhuon : carte 7400).
Pas mal en phase !
On voit que les cartes détaillées incluent les embouchures de la Laïta 
et de la ria d'Etel, mais pas l'estuaire de la Loire.


D'autres avis ?
Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données du STIF sur Osmose

[Noémie Lehuby]

Bonsoir,

Je vote pour le retrait des arrêts de bus d'Osmose.

J'ai ajouté à la main les références sur une ligne (une soixantaine 
d'arrêts)
J'avais pré-filtré les références opendata sur la ligne en question pour 
ne pas être polluée par les arrêts des autres transporteurs qui ne 
m'intéressaient pas dans un premier temps.
Et malgré ça, j'avais quand même un peu plus d'un cas sur 6 où l'arrêt 
opendata le plus proche n'était pas le bon mais celui de l'autre côté de 
la route.


Je pense que si on intègre les ref juste avec Osmose, ce n'est pas 
possible de faire ça correctement, en particulier dès qu'on a plusieurs 
transporteurs qui partagent des arrêts.



Du coup, j'ai commencé un outil (qui fait le travail de pré-filtrer les 
arrêts opendata par ligne, en se basant sur les ref opendata des lignes 
qu'on a intégrées). Je le bêta-teste après les fêtes, et je vous tiens 
au jus.


Noémie


Date: Wed, 21 Dec 2016 10:47:17 +0100
From: Frédéric Rodrigo 
To: Discussions sur OSM en français  
Subject: Re: [OSM-talk-fr] Données du STIF sur Osmose
Message-ID: <1b367f08-ee38-fd91-5be6-07c7b9868...@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed

Le 21/12/2016 à 09:58, Florian LAINEZ a écrit :

Merci Fred, Noémie pour ces outils.
Je rejoins les critiques : c'est pour l'instant un peu galère voir
trompeur.
Je comprends néanmoins qu'on ne puisse faire mieux pour l'instant ...

En ce moment j'aborde le problème de qualité avec divers acteurs du
transport et j'ai fait un petit comparatif rapide sur deux quartiers
exemple : https://www.slideshare.net/secret/yhSSpQ6mzE6SH6
Des suggestions d'amélioration ?

Y aurait-il moyen de générer des stats plus poussées ? Je cherche par
exemple l'écart moyen de la distance entre les données STIF et OSM,
les valeurs max/min, voir l'écart-type.
Fred peut-être est-ce déjà intégré à OSMOSE ? Je n'ai pas trouvé.
Oui Osmose génère en même temps des CSV, mais je ne retrouve pas 
l'URL



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

Re: [OSM-talk-fr] fiber=yes ?

[Laurent Choisie]

Bonsoir à tous,

Travaillant dans le métier des télécoms et en particulier dans celui des
déploiements de fibre optique, je me permets d'apporter quelques éléments
au débat.
Tout d'abord, mes réserves :
- je ne rentre pas dans le débat des réseaux HFC ou autre FttLA. Je ne
parle que de réseau FttH.
- je ne rentre pas non plus dans la question de comment tagguer tout ça
sous OSM. Je laisse ça aux spécialistes, mais oui il faudrait pouvoir
préciser "medium=fiber".

Ce que je veux vous dire c'est :
1. "Le Plan"
La France vit actuellement un déploiement massif de fibre optique, ayant
pour but de couvrir 100% des foyers d'ici 2022. Il s'agit du Plan France
Thrès Haut Débit http://www.francethd.fr/. Saluons l'initiative et ne nous
attardons pas sur les probables retards à terme.
Il s'agit de remplacer à terme le réseau Cuivre d'Orange.
On peut comparer ce déploiement à celui du réseau d'électricité, ou à celui
du réseau de téléphonie Cuivre de France Telecom à l'époque.

2. Les bonnes vielles recettes, et comment on s'est découpé le gâteau
Le territoire français a été découpé en plusieurs zones en fonction de leur
rentabilité :
- ZTD (Zone Très Dense) = une 100aine de communes (arrondissements de
Paris, Lyon, Strasbourg ...) représentant ~5 millions de foyers, pour
laquelle chaque opérateur peut déployer tout le réseau qu'il souhaite.
C'est rentable donc chacun peut déployer à sa guise. En gros c'est la libre
concurrence.
- Zone d'initiative privé = 3 600 communes dites "conventionnées" soit 57%
de la population et représentant un investissement de 6 à 7 milliards
d'euros. Ce sont les agglos, les préfectures, les sous-préf. Là 1 seul
opérateur privé investit (Orange ou SFR). Mais il a la garantie qu'il n'y
aura pas de concurrence sur les infras. Donc celui qui déploie la fibre
devra la commercialiser à tous de façon équitable, contrôlé par l'ARCEP.
- Zone RIP (Réseau d'Initiative Publique) = tout le reste du territoire,
soit plus de 30 000 communes mais représentant un investissement de 13 à 14
milliards. C'est du rural. Dans ce cas, pas de rentabilité. Donc l'Etat et
les Collectivités Locales co-investissent avec des acteurs privés. C'est le
principe des DSP (Délégation de Service Public), une bonne vieille recette
qui fonctionne pour l'eau, les transports en commun etc ...

3. Les infrastructures
D'un point de vue architecture, les points intéressants à cartographier,
selon moi, sont (en partant des GIX nationaux vers les client final) :
- les POP (PointOfPresence), les points d'échanges entre opérateurs,
souvent équivalents à des datacenters dans les grandes villes,
- les NRO (Noeud de Raccordement Optique), généralement un shelter ou un
petit local ou co-localisé dans un NRA d'Orange, dans lequel on va activer
= allumer la fibre optique. Dans le NRO, on trouve l'équipement OLT
équivalent du DSLAM en adsl.
- les SRO (Sous-Répartiteur Optique), ou PM (Point de Mutualisation), ou
armoire de brassage. C'est dans ces armoires qu'arrive chacune des fibres
des abonnés pour ensuite les brasser càd les renvoyer vers le NRO de
l'opérateur. Un bon moyen pour les distinguer est la présence d'un picto
"danger optique"
https://aua-signaletique.com/panneaux-iso-7010/4696-danger-rayonnement-optique-w027.html
. Un SRO alimente entre 500 et 1000 foyers. Donc on en trouve 1 par petite
commune rurale ou 1 par quartier résidentiel d'une ville.

4. Les adresses ...
Quand on commence l'étude d'une commune à déployer en fibre optique, le
premier problème est de savoir où sont les gens !
Le cadastre a une base, les impôts ont une base, les exploitants de réseaux
(ErDF, GrDF, Orange) ont chacun leur base, LaPoste a sa base, l'Insee a sa
base, l'IGN a sa base, OSM a la BANO mais personne n'a la vérité ... Donc
on paye des sous-traitants pour aller faire des relevés de
boîtes-aux-lettres. En 2016 ! ...A chaque fois que j'en parle, le sujet me
désespère. Bref.
Heureusement, la BAN est en cours de conception. Mais pas facile de
satisfaire tout le monde. Christian Quest saura mieux vous en parler.

J'ai essayé de faire court et espère avoir intéressé quelques-uns d'entre
vous.
Pour ma part, je commence à cartographier les SRO dès ce soir.

Cordialement,
Laurent CHOISIE

PS : Désolé pour tous ces acronymes.


Le 22 décembre 2016 à 00:55, François Lacombe  a
écrit :

> Bonjour Jean-Yvon,
>
> Le 18 décembre 2016 à 20:49,  a écrit :
>
>> Je vais te proposer de mettre fin à ton dilemme :
>> telecom:medium:fiber=yes
>> telecom:medium:coax=yes
>>
>> Pas de soucis pour les armoires à usage multiple.
>> Et comme il y a trois et non deux cas (yes, no, absence de tag)
>>
>
> En fait le dilemme se situait entre les listes à ; :
> telecom:medium=fiber;coax et les tag "yes" : telecom:medium:fiber=yes +
> telecom:medium:coax=yes
> J'avais d'ailleurs reproché ça à une proposition d'extension du modèle des
> écoles/universités en début d'année où trop de clés avec pour seule valeur
> yes étaient utilisées.
>
> Vu qu'il n'y a pas de solution parfaite, à mo