Re: [OSM-talk-fr] routage surfacique
Le 19/06/2019 à 14:34, Phyks - ph...@phyks.me a écrit : Je mets volontairement de côté une place aussi complexe que https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal au passage…) Ce n'est pas le rendu qui a un soucis, c'est le concepteur. Car les inners ne sont pas disjoints. Donc tu as une partie qui est décrite comme étant à la fois dedans et dehors : la partie commune est à la fois limite intérieure au nord/extérieure au sud et limite extérieure au nord/intérieure au sud. Il faudrait créer une zone comportant toute la place qui n'est pas de niveau et la mettre en inner de la relation. Jean-Yvon ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
Ben en faite la zone ne tiens pas compte du bati ou non. Les cave à fromage c'est tous le problème. l(IGP est à la fois sur la provenance du lait et sur le lieu de production est de transformation. C'est pour ça que l'on parle de territoire et pas forcément de parcellaire Bref l'exploitation fait parti de l'IGP vu que le lieu de transformation doit être sur place. ok pour product et non produce Le mer. 19 juin 2019 à 17:07, marc marc a écrit : > à propos des étendues des appellations > > Le 19.06.19 à 14:41, Jérôme Seigneuret a écrit : > > produce=* me semble largement suffisant > > cela signifierait que cette étendue fait tel produit > hors ce n'est qu'une partie qui en fait. > produce=* ne doit à mon avis pas déborder des terres > ou des exploitations (pas de produce=* sur une étendue qui > contient le magasin de chaussure et le bureau de poste) > > > boudary=produce_protection (ou produce_certification) > > oui pour quelques choses du genre > voir product (le vin est un produit <> produce= c'est le raisin) > > > produce_protection:name=Indication Géographique Protégée > > sur la relation c'est encore + simple : > name= > > > produce_protection:zone=UE, suisse, RPC > > ce serrait renseigner la législation, à éviter. > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Cordialement, Jérôme Seigneuret ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
Bonjour, Je saute dans la discussion pour dire rapidement : 1. les zones géographique de label devrait être faites en zone (polygone) et pas utiliser par des tags parce que la règle de One feature, one OSM element 2. ce qui porte le label c'est le produit, le vin pas la vigne. 3. utiliser plutôt product parce que «Produce or Product? A guide by example. If the whole live animal/fish or plant is sold off the 'farm' then tag it as produce. If it is killed and then sold with little processing then that is ok for tagging as produce. *If the processing is 'extensive' then it is a product=* not produce, so it should use the product=* key.*» La production de vin est un processus industriel complexe où le label peut obliger à des limitations. Clé à mettre plutôt sur le chai donc. Le mer. 19 juin 2019 à 17:07, marc marc a écrit : > à propos des étendues des appellations > > Le 19.06.19 à 14:41, Jérôme Seigneuret a écrit : > > produce=* me semble largement suffisant > > cela signifierait que cette étendue fait tel produit > hors ce n'est qu'une partie qui en fait. > produce=* ne doit à mon avis pas déborder des terres > ou des exploitations (pas de produce=* sur une étendue qui > contient le magasin de chaussure et le bureau de poste) > > > boudary=produce_protection (ou produce_certification) > > oui pour quelques choses du genre > voir product (le vin est un produit <> produce= c'est le raisin) > > > produce_protection:name=Indication Géographique Protégée > > sur la relation c'est encore + simple : > name= > > > produce_protection:zone=UE, suisse, RPC > > ce serrait renseigner la législation, à éviter. > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Florimond Berthoux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] routage surfacique
Le 18/06/2019 à 20:33, marc marc a écrit : j'ai bien vu cela (même si n'est pas compréhensible sur la capture) mais aucun des 4 itinéraires n’atteint l'itinéraire réel alors que ce sont 2 points de osm de la place. donc même ce site a du limiter le nuage de way représentant la place. alors imagine les dégâts si tu routes entre Paris et Monpellier en surfacique. A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied (même quand j'étais jeune, je ne le faisais pas). Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit : Le 18.06.19 à 18:48, lenny.libre a écrit : donc pour ma part, les routes donnant sur une place se rejoignent en un point + souvent place=square c'est une représentation imparfaite, mais c'est à l'heure actuelle sans doute le meilleur compromis Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès sur la place à quoi bon tracer un chemin fictif qui n'est pas nécessaire aux calculateurs) Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ? les évolutions des tags dans osm se font généralement - soit par des tags supplémentaires (highway puis maxspeed puis lanes puis turn:lanes par ex) - soit par un changement de tags (par ex power=sub_Station divisé en 2 power=substation et power=generator). Si on suit cette logique, c'est area:highway qui devrait être utilisé pour une transitions sans dégradation. casser en disant "yaka faire du routage surfacique", c'est méconnaître ce que cela implique techniquement : Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne devrais pas en parler ... , je serais bien incapable de faire ces outils" donc je ne suis peut-être pas technique, mais je remarque simplement qu'il y a des outils qui font sans ces "chemins" il y a un gros travail de prétraitement à faire. je ne retrouve plus hélas l'article qui était publiée sur osmweekly mais la moindre place avec qlq rues est transformée en un nuage de way qui connectent tous les paires de points de la surface. en passant, cela veux dire aussi qu'une place surfacique avec 8 nœuds consomme 9x l'espace disque et mémoire comparé à sa version linéaire et ce n'est pas en un claquement de doigt qu'on augmente la puissance d'un serveur gratuit. je pense que les outils continueront de s'améliorer simplement à la demande de leur utilisateur, en fonction des ressources dispo. alors quehttps://moodwalkr.com/@montpellier/itineraire peut calculer un itinéraire https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png j'espère que tu partageras mon avis que l'amélioration par rapport à une représentation filaire ne saute pas aux yeux alors que le point de départ et d'arrivée sont accessible en ligne droite sans obstacle. Mais non, je ne partages pas ton avis, pas plus droit avec OSRM, PS: je n'ai pas chercher à mettre l'outil en difficulté, j'ai juste demandé la place et une adresse de la place. Peut-être parce que la partie pour aller à une adresse précise sur une place est améliorable, (alors qu'il permet de faire des recherches d'itinéraire par thèmes.) Tout produit est améliorable (tout comme mes contributions), je vais donc continuer à faire comme d'hab, je ne créerais pas de chemins virtuels et je n’effacerais pas ceux des copains. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
à propos des étendues des appellations Le 19.06.19 à 14:41, Jérôme Seigneuret a écrit : > produce=* me semble largement suffisant cela signifierait que cette étendue fait tel produit hors ce n'est qu'une partie qui en fait. produce=* ne doit à mon avis pas déborder des terres ou des exploitations (pas de produce=* sur une étendue qui contient le magasin de chaussure et le bureau de poste) > boudary=produce_protection (ou produce_certification) oui pour quelques choses du genre voir product (le vin est un produit <> produce= c'est le raisin) > produce_protection:name=Indication Géographique Protégée sur la relation c'est encore + simple : name= > produce_protection:zone=UE, suisse, RPC ce serrait renseigner la législation, à éviter. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] routage surfacique
Pour l'exemple de Montpellier, les tracés ont été supprimés par mes soins puis rajouté par les services de la métropole qui utilise des extractions pour ses propres outils de routing (non OSM compliant) et qui existe historiquement. Donc les linéaires correspondent à une nécessité de leurs outils pour le routing et je pense pour l'intermodalité (adresse vers adresse). (non compatible avec de l'itinéraire polygonale) D'où un commentaire dans les tracés. C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a aussi des tracés en double pour palier au problème d'affichage des noms (linéaire plus zone en dessous) L'autres système qui a encore d'autres implications c'est *area:highway=**. Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut mieux faire un post traitement sous forme de maille avec détection d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit sur ta capture d'écran. Le mer. 19 juin 2019 à 16:54, lenny.libre a écrit : > > Le 18/06/2019 à 20:33, marc marc a écrit : > > j'ai bien vu cela (même si n'est pas compréhensible sur la capture) > mais aucun des 4 itinéraires n’atteint l'itinéraire réel > alors que ce sont 2 points de osm de la place. > donc même ce site a du limiter le nuage de way représentant la place. > alors imagine les dégâts si tu routes entre Paris et Monpellier > en surfacique. > > A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied (même > quand j'étais jeune, je ne le faisais pas). > > Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit : > > Le 18.06.19 à 18:48, lenny.libre a écrit : > > donc pour ma part, les routes donnant sur une place > se rejoignent en un point + souvent place=square > c'est une représentation imparfaite, mais c'est > à l'heure actuelle sans doute le meilleur compromis > > Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès sur la > place à quoi bon tracer un chemin fictif qui n'est pas nécessaire aux > calculateurs) > > Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ? > > les évolutions des tags dans osm se font généralement > - soit par des tags supplémentaires (highway puis maxspeed > puis lanes puis turn:lanes par ex) > - soit par un changement de tags (par ex power=sub_Station > divisé en 2 power=substation et power=generator). > Si on suit cette logique, c'est area:highway qui devrait > être utilisé pour une transitions sans dégradation. > > casser en disant "yaka faire du routage surfacique", > c'est méconnaître ce que cela implique techniquement : > > Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne devrais > pas en parler ... , je serais bien incapable de faire ces outils" donc je > ne suis peut-être pas technique, mais je remarque simplement qu'il y a des > outils qui font sans ces "chemins" > > il y a un gros travail de prétraitement à faire. > je ne retrouve plus hélas l'article qui était publiée sur osmweekly > mais la moindre place avec qlq rues est transformée en un nuage > de way qui connectent tous les paires de points de la surface. > en passant, cela veux dire aussi qu'une place surfacique > avec 8 nœuds consomme 9x l'espace disque et mémoire > comparé à sa version linéaire et ce n'est pas en un claquement > de doigt qu'on augmente la puissance d'un serveur gratuit. > > je pense que les outils continueront de s'améliorer simplement > à la demande de leur utilisateur, en fonction des ressources dispo. > > > alors quehttps://moodwalkr.com/@montpellier/itineraire > peut calculer un itinéraire > > https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png > j'espère que tu partageras mon avis que l'amélioration par > rapport à une représentation filaire ne saute pas aux yeux > alors que le point de départ et d'arrivée sont accessible > en ligne droite sans obstacle. > > Mais non, je ne partages pas ton avis, pas plus droit avec OSRM, > > PS: je n'ai pas chercher à mettre l'outil en difficulté, > j'ai juste demandé la place et une adresse de la place. > > Peut-être parce que la partie pour aller à une adresse précise sur une > place est améliorable, (alors qu'il permet de faire des recherches > d'itinéraire par thèmes.) > > Tout produit est améliorable (tout comme mes contributions), je vais donc > continuer à faire comme d'hab, je ne créerais pas de chemins virtuels et je > n’effacerais pas ceux des copains. > ___ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > -- Cordialement, Jérôme Seigneuret ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
Le 19.06.19 à 14:20, djo_man via Talk-fr a écrit : > on est pas obligé de mapper des régions quand on a > des landuses déjà présents. Ils sont bien réels. obligé bien sur que non, mais analogie avec les bâtiments : on n'est pas obligé (c'est même "déprécié") de mettre quelques millions de is_in:region= quand une poignée de relation suffisent pour définir toutes les régions du pays. cette poignée de relation permettrait par exemple de faire un export depuis osm pour documenter la page wikipedia au lieu de passer en revue 80k landuse=vineyard avec un risque d'erreur bien supérieur. >> *=blabla AOP ou *=truc IGP ne va pas ? > les landuses peuvent être à la fois AOP et IGP et leur nom est différent. *="blabla AOP;truc IGP" pour fusionner avec l'idée de Jérome, si tu veux le faire sur un landuse crop=grape ou produce=grape (pléonasme implicite) for:product="blabla AOP;truc IGP" manque-t-il quelque chose ? > c'est pas de l'humour noir, c'est sarcastique... ce n'était pas mon but d'être blessant. mon but était de caricaturer l'inutile complication. > les appellations françaises ne sont pas si simples donc... donc simplifions en un truc compréhensible, utilisant au maximum les tags existant lorsqu'ils conviennent afin que les contributeurs retrouve des mécanismes connus. sinon on aura juste un schéma de + qui se superpose aux autres qui rend l'utilisation des données partielle et aléatoire. Cordialement, Marc ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
Pour rentrer un peu plus dans le détail, voici les infos sur la base et sont contenu parcellaire sous licence etalab2 *Allias* (optionnel) Délimitations parcellaires AOP/IGP (INAO) *Définition* La Directive 2015-03 de l’INAO désigne sous le terme « aire parcellaire délimitée» une délimitation qui repose sur les limites administratives du cadastre (les parcelles) et dont le maillage suffisamment fin permet de tenir compte de variations très localisées des éléments du milieu physique. *La délimitation parcellaire des AOP/IGP est utilisée essentiellement pour les vins*. Elle correspond dans ce cas à l’*aire de production de la matière première*. Elle est incluse dans une aire géographique qui constitue l’aire de production du produit. Elle est le résultat d’une procédure de délimitation validée par l’INAO. *Regroupement* Parcelle, agrégat de parcelles ou de parties de parcelle *Type d’objet *Polygone simple ou multiple *Modélisation géométrique* La géométrie d'une aire parcellaire délimitée se construit par l'*agrégation des polygones représentant les limites des parcelles cadastrales vectorisées par commune mais agrégées à l’appellation* dans cette base. Contraintes La généalogie des données induit des *hiatus aux frontières des communes (des vides ou des superpositions)*. Leur utilisation est optimale par la prise en compte d’un territoire communale unique. Les plans délimités officiels restent ceux détenus par l’INAO et déposés dans les mairies des communes concernées par au moins une délimitation parcellaire en AOP ou en IGP. Donc en clair c'est basé sur les parcelles du cadastre. Les limites concernant la date et le type de données L’utilisation du PCI-Vecteur par les services de l’INAO pour la vectorisation des aires parcellaires date de 2008. A l’époque, le système de référence utilisé était le Lambert II étendu. Il est ensuite passé au Lambert 93 Maintenance 3 à 4 fois par an. Avertissement Ces données sont encore à l’état de constitution, elles ne sont pas complètes et constituent à ce stade une version Bêta. L’INAO remercie toute personne faisant remonter des anomalies pour permettre une amélioration de la donnée. Le mer. 19 juin 2019 à 14:41, Jérôme Seigneuret a écrit : > si l'on par sur produce on est sur des éléments complémentaires de landuse > qui sont en relation avec un produit donc plus cohérent > > Les IGP AOC se chevauchent vachement car il y en à pour plein de > produits. Il doit y avoir des limites communes... Peut être faudrait-il > initier ce travail de recouvrement pour les relations avec une forme de > topologie et pas une intégration de shape comme ça l'est des fois avec les > Aire protégées... > > Le cahier des charges défini explicitement les territoires. Donc le shape > peut aider mais ne doit pas servir pour faire les relations!!! > De plus, c'est pas parce qu'on est dans une zone IGP AOC ou AOP que le > terrain sert à produire une denrée en lien avec l'indication... donc rien à > faire sur le landuse... > > Qui plus est, on est en lien avec un cahier des charges pour la production > donc ce reporter au cahier des charges > > Marc ta proposition est pas mal ;-) Mais on peut faire > plus simple > > ref:FR:INAO > ref;EU ? > > ou international? c'est pas reconnu qu'en France > > pour la clé produit > produce=* me semble largement suffisant > boudary=produce_protection (ou produce_certification) > produce_protection:short_name=IGP > produce_protection:name=Indication Géographique Protégée > produce_protection:zone=UE, suisse, RPC > > etc > produce_protection:level= à définir car on n'est pas les seul à > protéger nos productions et nos processus > > name=* plutôt qu'une denomination ou appelation est suffisant > name:fr > name:en > > Les labels sont IGP, AOC, AOP, et les autres label si tu veux jouer : Bio, > label rouge, AB etc > > Attention les IGP peuvent être parcellaires!!! > > A+ Jérôme > > > > > > Le mer. 19 juin 2019 à 12:49, marc marc a > écrit : > >> Bonjour, >> >> Le 19.06.19 à 11:41, djo_man via Talk-fr a écrit : >> > https://wiki.openstreetmap.org/wiki/Key:winery >> > Cette page me semble inopérante >> >> elle est l’œuvre d'une seule personne connue pour faire des >> pages controversées présentées comme "la bonne façon de faire" >> on voit bien à la description et aux valeurs que cela ne rime >> à rien et que cela réinvente une fois de plus ce qui existe >> par ex le fait qu'un poi vend du vin est parfois renseigné par drink >> >> > car elle est basée sur le tag craft=winery >> > plutot que landuse=vineyard. >> >> j'ai rien compris à l'argument : si le gars veux maper >> le chai d'un bordeaux, je vois pas pq il devrait aller >> maper la parcelle de la vigne qu'il n'a même pas visité. >> ce sont 2 choses différente (c'est comme maper une >> usine agroalimentaire de chips ou le champs de patate) >> >> > Je propose alors sur le landuse=vineyard (un ensemble de parcelles): >> > - vineyard:regions= regions selon la page de wikipedia >> > https://en.w
Re: [OSM-talk-fr] Re: zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
https://wiki.openstreetmap.org/wiki/Key:winery
Cette page me semble inopérante
inopérante pour décrire le vin geographiquement car bien souvent, il y a plusieurs vins par domaine. ils peuvent etre de plusieurs AOP ou IGP et des fois rien pour certains domaines. par exemple, il est tres courant dans le beaujolais qu'il y ai 2 AOp différents plus un IGP. Cela vient du fait que les appellations sont assises sur les parcelles.
il pas question de taguer à la parcelle mais pour un landuse
donc il faut décrire ce qui est potentiellement possible sur le landuse
les appellations sont bien géographique
://en.wikipedia.org/wiki/List_of_wine-producing_regions
si tu veux mapper des régions, mape des régions.
on est pas obligé de mapper des régions quand on a des landuses
déjà présents. Ils sont bien réels.
je ne comprends pas la remarque de
osm.sanspourr...@spamgourmet.com : Loire Valley n'est pas une
region adminstative. ces regions sont des dénominations qui sont
aussi reprises sur le traité de lisbonne qui décrit les
protections des AOP.
le nom des régions est important car par exemple : Madiran juste
à coté de la région de Bordeaux à un nom très spécifique.
Comme Champagne ou Bourgogne, Rhône. la limite être ses régions
est importante
- vineyard:appellation:aop= issu de la base INAO ("appellation" car la
WIPO (wolrd intellectual property organization) l'utilise
oui, pourquoi pas mettre les termes internationaux. PDO et PGI
je comprend pas la différence.
*=blabla AOP ou *=truc IGP ne va pas ?
les landuses peuvent être à la fois AOP et IGP et leur nom est
différent.
il faut trouver une manière de lister la classification puis leur
nom
oui, peut être se limiter à ne mettre que
vineyard:appellation:pdo = "name" et vineyard:appellation:pgi =
"name"
c'est pas de l'humour noir, c'est sarcastique...
les appellations françaises ne sont pas si simples donc...
djo
___
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] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
si l'on par sur produce on est sur des éléments complémentaires de landuse
qui sont en relation avec un produit donc plus cohérent
Les IGP AOC se chevauchent vachement car il y en à pour plein de produits.
Il doit y avoir des limites communes... Peut être faudrait-il initier ce
travail de recouvrement pour les relations avec une forme de topologie et
pas une intégration de shape comme ça l'est des fois avec les Aire
protégées...
Le cahier des charges défini explicitement les territoires. Donc le shape
peut aider mais ne doit pas servir pour faire les relations!!!
De plus, c'est pas parce qu'on est dans une zone IGP AOC ou AOP que le
terrain sert à produire une denrée en lien avec l'indication... donc rien à
faire sur le landuse...
Qui plus est, on est en lien avec un cahier des charges pour la production
donc ce reporter au cahier des charges
Marc ta proposition est pas mal ;-) Mais on peut faire
plus simple
ref:FR:INAO
ref;EU ?
ou international? c'est pas reconnu qu'en France
pour la clé produit
produce=* me semble largement suffisant
boudary=produce_protection (ou produce_certification)
produce_protection:short_name=IGP
produce_protection:name=Indication Géographique Protégée
produce_protection:zone=UE, suisse, RPC
etc
produce_protection:level= à définir car on n'est pas les seul à
protéger nos productions et nos processus
name=* plutôt qu'une denomination ou appelation est suffisant
name:fr
name:en
Les labels sont IGP, AOC, AOP, et les autres label si tu veux jouer : Bio,
label rouge, AB etc
Attention les IGP peuvent être parcellaires!!!
A+ Jérôme
Le mer. 19 juin 2019 à 12:49, marc marc a
écrit :
> Bonjour,
>
> Le 19.06.19 à 11:41, djo_man via Talk-fr a écrit :
> > https://wiki.openstreetmap.org/wiki/Key:winery
> > Cette page me semble inopérante
>
> elle est l’œuvre d'une seule personne connue pour faire des
> pages controversées présentées comme "la bonne façon de faire"
> on voit bien à la description et aux valeurs que cela ne rime
> à rien et que cela réinvente une fois de plus ce qui existe
> par ex le fait qu'un poi vend du vin est parfois renseigné par drink
>
> > car elle est basée sur le tag craft=winery
> > plutot que landuse=vineyard.
>
> j'ai rien compris à l'argument : si le gars veux maper
> le chai d'un bordeaux, je vois pas pq il devrait aller
> maper la parcelle de la vigne qu'il n'a même pas visité.
> ce sont 2 choses différente (c'est comme maper une
> usine agroalimentaire de chips ou le champs de patate)
>
> > Je propose alors sur le landuse=vineyard (un ensemble de parcelles):
> > - vineyard:regions= regions selon la page de wikipedia
> > https://en.wikipedia.org/wiki/List_of_wine-producing_regions
>
> si tu veux mapper des régions, mape des régions.
> ex 12 relations type=boundary boundary=wine ou truc du genre.
> dire que chaque parcelle de Bordeaux peux produire un vin de Bordeaux,
> c'est lourd
>
> > - vineyard:classification= AOP ou/et IGP
>
> il y a un cas d'usage ou quelqu'un connaîtrait le fait que c'est une aop
> mais ne serrait pas capable de renseigner le nom de l'aop dans l'un des
> tags que tu proposes ensuite ? sinon c'est juste doublon
> ce serrait comme mettre name:classification=Rue name=Rue de la gare
>
> > - vineyard:appellation:aop= issu de la base INAO ("appellation" car la
> > WIPO (wolrd intellectual property organization) l'utilise
> > https://www.wipo.int/ipdl/en/search/lisbon/search-struct.jsp)
> > - vineyard:appellation:igp= issu de la base INAO (conforme à l'europe)
> > - vineyard:denomination= issu de la base INAO ("denomination" franco
> > français mais pas uniquement car d'autre régions du monde ont repis
> l'idée)
>
> je comprend pas la différence.
> *=blabla AOP ou *=truc IGP ne va pas ?
>
> > ça fait réagir quelqu'un ?
>
>
> je pense qu'il faut faire beaucoup plus compliqué
> et différent de tout ce qui existe déjà
> sinon cela risque d'être utilisable et pire utilisé
> il faut aussi ne pas hésiter à rallonger avec plein de namespace
> pour que chaque tag ne soie utilisable que sur un objet
> genre vineyard:appellation:aop qui n'est possible qu'en France
> (puisqu'en anglais c'est pdo), que sur un vignoble, etc
> je propose ref:FR:vineyard:appellation:aop:INAO:2019=*
> mais on doit pouvoir sûrement faire + long.
>
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
--
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] routage surfacique
Bonjour, casser en disant "yaka faire du routage surfacique", c'est méconnaître ce que cela implique techniquement : il y a un gros travail de prétraitement à faire. je ne retrouve plus hélas l'article qui était publiée sur osmweekly mais la moindre place avec qlq rues est transformée en un nuage de way qui connectent tous les paires de points de la surface. en passant, cela veux dire aussi qu'une place surfacique avec 8 nœuds consomme 9x l'espace disque et mémoire comparé à sa version linéaire et ce n'est pas en un claquement de doigt qu'on augmente la puissance d'un serveur gratuit. je pense que les outils continueront de s'améliorer simplement à la demande de leur utilisateur, en fonction des ressources dispo. Dans la plupart des cas, le routage surfacique n'est pas un problème quand même. Je mets volontairement de côté une place aussi complexe que https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal au passage…) pour se concentrer sur des espaces sans trous (tels que les espaces dans l'erreur Osmose initiale https://osmose.openstreetmap.fr/fr/map/#item=1270&zoom=18&lat=47.497894&lon=-0.580999&level=1%2C2%2C3&tags=&fixable=). La plupart des moteurs de routage ne vont pas gérer le routage surfacique à travers la place (qui est un problème compliqué). En revanche, tous vont pouvoir traiter la place comme un way fermé (le contour) et tous savent a priori emprunter des portions de way. Du coup, le routage ne sera pas "joli" (on ne va pas traverser la place comme on le voudrait, simplement contourner en suivant la bordure), mais le routage restera néanmoins fonctionnel. Dans un cas simple comme ceci, à mon avis, il n'y a aucune raison de tracer des continuités des chemins à travers les places, si ce n'est alourdir la base avec des ways inutiles (et qui n'existent pas sur le terrain). La description en termes d'air a une réelle plus value (notamment pour le rendu, mais pas que), et reste parfaitement utilisable, à condition que les aires portent bien les attributs corrects (highway et droits d'accès). Sur un cas similaire à l'exemple initial d'Osmose : * BRouter suit le contour, http://brouter.de/brouter-web/#map=19/45.77393/3.08337/standard&lonlats=3.083773,45.77412;3.083596,45.773869 * Géovélo aussi, https://www.geovelo.fr/clermont/itinerary/search?profile=MEDIAN&bikeType=TRADITIONAL&wayPoints=45.774108,3.08372%7C45.7739,3.0836 * GraphHopper et OSRM aussi, https://www.openstreetmap.org/directions?engine=graphhopper_foot&route=45.77411%2C3.08376%3B45.77387%2C3.08360 Mon avis serait donc que sur des places simples (sans trou), il suffit de connecter le polygone aux chemins voisins et tout tracé de chemin en travers du polygone relève plutôt du "tag to router", en créant des chemins qui amélioreront le rendu du routage, mais en aucun cas sa justesse. D'ailleurs, malgré l'erreur Osmose, le routage se fait très bien http://brouter.de/brouter-web/#map=19/47.49783/-0.58158/standard&lonlats=-0.581248,47.497738;-0.581433,47.498012. Ma remarque ne tient plus évidemment lorsqu'on considère des surfaces avec des trous (multipolygone) où le routage est épouvantable et catastrophique s'il n'y a pas de chemins intérieurs "fictifs", comme le montre http://brouter.de/brouter-web/#map=17/48.84022/2.32019/standard&lonlats=2.319813,48.841791;2.321146,48.841137&profile=hiking-beta par exemple (BRouter ne gère pas le routage surfacique). Ce point est beaucoup plus sujet à débat à mon avis et des chemins "fictifs" pourraient être justifiés, même si certains ont des avis assez tranchés sur la question https://www.openstreetmap.org/note/1654211. -- Phyks ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
Bonjour,
Le 19.06.19 à 11:41, djo_man via Talk-fr a écrit :
> https://wiki.openstreetmap.org/wiki/Key:winery
> Cette page me semble inopérante
elle est l’œuvre d'une seule personne connue pour faire des
pages controversées présentées comme "la bonne façon de faire"
on voit bien à la description et aux valeurs que cela ne rime
à rien et que cela réinvente une fois de plus ce qui existe
par ex le fait qu'un poi vend du vin est parfois renseigné par drink
> car elle est basée sur le tag craft=winery
> plutot que landuse=vineyard.
j'ai rien compris à l'argument : si le gars veux maper
le chai d'un bordeaux, je vois pas pq il devrait aller
maper la parcelle de la vigne qu'il n'a même pas visité.
ce sont 2 choses différente (c'est comme maper une
usine agroalimentaire de chips ou le champs de patate)
> Je propose alors sur le landuse=vineyard (un ensemble de parcelles):
> - vineyard:regions= regions selon la page de wikipedia
> https://en.wikipedia.org/wiki/List_of_wine-producing_regions
si tu veux mapper des régions, mape des régions.
ex 12 relations type=boundary boundary=wine ou truc du genre.
dire que chaque parcelle de Bordeaux peux produire un vin de Bordeaux,
c'est lourd
> - vineyard:classification= AOP ou/et IGP
il y a un cas d'usage ou quelqu'un connaîtrait le fait que c'est une aop
mais ne serrait pas capable de renseigner le nom de l'aop dans l'un des
tags que tu proposes ensuite ? sinon c'est juste doublon
ce serrait comme mettre name:classification=Rue name=Rue de la gare
> - vineyard:appellation:aop= issu de la base INAO ("appellation" car la
> WIPO (wolrd intellectual property organization) l'utilise
> https://www.wipo.int/ipdl/en/search/lisbon/search-struct.jsp)
> - vineyard:appellation:igp= issu de la base INAO (conforme à l'europe)
> - vineyard:denomination= issu de la base INAO ("denomination" franco
> français mais pas uniquement car d'autre régions du monde ont repis l'idée)
je comprend pas la différence.
*=blabla AOP ou *=truc IGP ne va pas ?
> ça fait réagir quelqu'un ?
je pense qu'il faut faire beaucoup plus compliqué
et différent de tout ce qui existe déjà
sinon cela risque d'être utilisable et pire utilisé
il faut aussi ne pas hésiter à rallonger avec plein de namespace
pour que chaque tag ne soie utilisable que sur un objet
genre vineyard:appellation:aop qui n'est possible qu'en France
(puisqu'en anglais c'est pdo), que sur un vignoble, etc
je propose ref:FR:vineyard:appellation:aop:INAO:2019=*
mais on doit pouvoir sûrement faire + long.
Cordialement,
Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
Ça me fait réagir : la page liste les régions administratives, pas les AOP/IGP. Le 19/06/2019 à 11:41, djo_man via Talk-fr - talk-fr@openstreetmap.org a écrit : - vineyard:regions= regions selon la page de wikipedia https://en.wikipedia.org/wiki/List_of_wine-producing_regions De plus l'abréviation d'IGP est PGI en anglais (protected geographical indication). Et celle d'AOP est PDO (protected designation of origin). Source : IATE évidemment https://iate.europa.eu/search/standard/result/1560939408913/1 https://iate.europa.eu/search/standard/result/1560939330717/1 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO
Une page du wiki m'en a donné l'idée.
https://wiki.openstreetmap.org/wiki/Key:winery
Cette page me semble inopérante car elle est basée sur le tag
craft=winery + winery= "" plutot que landuse=vineyard.
En europe et assez largement dans le monde ou des appellations
sont présentes, le classement des vins est basé sur le type de
cépages sur des parcelles repérées donc de la vigne.
Je propose alors sur le landuse=vineyard (un ensemble de
parcelles):
- vineyard:regions= regions selon la page de wikipedia
https://en.wikipedia.org/wiki/List_of_wine-producing_regions
- vineyard:classification= AOP ou/et IGP
- vineyard:appellation:aop= issu de la base INAO ("appellation"
car la WIPO (wolrd intellectual property organization) l'utilise
https://www.wipo.int/ipdl/en/search/lisbon/search-struct.jsp)
- vineyard:appellation:igp= issu de la base INAO (conforme à
l'europe)
- vineyard:denomination= issu de la base INAO ("denomination"
franco français mais pas uniquement car d'autre régions du monde
ont repis l'idée)
on pourrait rajouter le reste au besoin :
- vineyard:grape= cépages selon la page wikipedia
https://en.wikipedia.org/wiki/List_of_grape_varieties (il faudrait
le faire à la parcelle mais on le fait bien pour les arbres...)
ça plait ?
ça fait réagir quelqu'un ?
djoman
Le 17/06/2019 à 10:07, djo_man via
Talk-fr a écrit :
Bonjour à tous,
Je ne trouve pas de file de discussion parlant de la
possibilité de préciser par un tag les appellations AOC/AOP/IGP
des zones landuse=vineyard.
On en a jamais parlé ? si ?
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dvineyard
l'INAO en France fourni actuellement un shp des zones
d'appellation (480Mo !) et met actuellement à jour sa base. Une
reforme est en ce moment en cours pour simplifier et rénover les
périmètres. Une bonne moitié des périmètres sont déjà approuvés
et disponibles sur le site de l'INAO. Le reste est en cours de
concertation et les projets sont disponibles sur le site de
l'INAO.
https://www.inao.gouv.fr/Espace-professionnel-et-outils/Suivi-des-demarches/Consultations-publiques-des-projets-d-aires-geographiques-ou-parcellaires-delimitees-des-AOC-et-IGP
Personnellement, je n'envisage pas d'intégrer les périmètres
mais plutôt d'ajouter 1 tag ou 2 sur des ways existants de
landuse=vineyard en les recoupant au besoin.
Djoman
___
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] exporter les tags d'un projet/style vers taginfo
Bonjour à tous,
Pour donner un peu plus de détails sur la question, j'ai actuellement un
script
(https://github.com/cyclosm/cyclosm-cartocss-style/blob/master/scripts/generate_taginfo.py)
qui permet à partir d'un fichier YAML de déclaration de style CartoCSS
(testé sur CyclOSM, mais ça devrait fonctionner tout pareil sur osm-fr,
osm-bzh etc) de générer un fichier JSON pour taginfo listant tous les
tags utilisés. Le seul pré-requis pour l'instant est que la base de
données utilisée soit une base de données standard d'un import osm2pgsql
(pour les noms des colonnes), éventuellement avec --hstore.
Mon problème principal actuellement, c'est que j'aimerais pouvoir avoir
dynamiquement la liste des valeurs (et non seulement les tags) utilisés.
Par exemple (hypothétique), je voudrais savoir que j'affiche les
shop=bicycle mais pas tous les autres shop. Le problème est que le
filtrage peut se faire dans les tables SQL ou dans les styles carto,
sans compter que les colonnes peuvent être fusionnées, renommées etc
dans les requêtes SQL. Bref, ça me paraît très compliqué de sortir les
valeurs vraiment prises en compte sans se constraindre assez fortement
sur les requêtes SQL qu'on peut écrire.
En y réfléchissant un peu, une idée me semble être de faire tourner les
requêtes SQL complètes sur une grosse base (monde ?) et de regarder les
valeurs uniques pour chaque colonne. Ce ne sera pas parfait (une valeur
pourrait être ignorée car elle n'est pas en base et non parce qu'elle
n'est pas gérée par le style), mais ça devrait fournir une assez bonne
approximation en général.
Ceci n'est bien sûr pas parfait, j'ignore notamment les colonnes dans
les clauses WHERE ainsi que des valeurs renommées / fusionnées /
transformées dans les requêtes SQL, mais ça devrait être "good enough"
pour la plupart des usages. Qu'en pensez-vous ?
Je prends bien sûr tout avis ou idée pour gérer ça mieux !
Bonne soirée,
--
Phyks
Le 2019-06-06 18:10, marc marc a écrit :
Bonjour,
Je discutais avec Phyks sur irc à propos de la fonction projet
de taginfo. elle permet de connaitre la liste des tags et/ou
valeurs utilisé par un projet.
C'est pratique par exemple pour faire la différence entre
des tags utilisé ou pas encore, ou pour savoir qui prévenir
quand un tag est affecté par une proposition.
A mes yeux, ce serrait aussi pratique pour détecter
quand un poi est rendu dans un style mais pas dans un autre,
afin de pouvoir faire des PR croisé du code ou de l’icône.
exemple de tag déclaré par des projets
https://taginfo.openstreetmap.org/projects#tags
exemple tag&valeur utilisant des vues
https://github.com/giggls/openstreetmap-carto-de/issues/39
une adaptation tag avec les tables sans vue
https://github.com/cyclosm/cyclosm-cartocss-style/issues/123
exemple tag&valeur
https://github.com/der-stefan/OpenTopoMap/blob/master/mapnik/tools/maketaginfo.pl
les problèmes :
le premier utilise des vues ce qui n'est pas le cas par défaut
sur un fork osm-carto
le deuxième ne gère pas les valeurs, seulement les tags
et selon Phyks le troisième a le défaut "meh, du perl :("
j'ouvre donc ce sujet pour voir si les différentes personnes
(Christian, Maël, Yohan, sncf?, autre ?) serraient intéressées de :
- mettre en place la création du fichier nécessaire pour taginfo
avec leur projet (je peux ouvrir les tickets si vous voulez)
- collaborer pour améliorer les outils existant
Cordialement,
MArc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
--
Phyks
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Nomad Maps, le film, est en ligne!
Bonjour à tous, J'ai le plaisir de vous partager le lien de mon film "Nomad Maps, une itinérance cartographique andine à vélo", sur le Peertube d'OSM France. A ce jour j'ai les sous titres en français et espagnol, les sous titres anglais arriveront dans les prochains jours. https://peertube.openstreetmap.fr/videos/watch/384d14d7-9d19-4d15-a958-74aae719b48f Le film est en CC BY SA 3.0, vous pouvez bien entendu l'utiliser comme matériel pédagogique et faire tourner dans vos réseaux. Si vous souhaitez organiser une projection dans une asso ou autre vers chez vous en ma présence pour un "ciné débat", n'hésitez pas à me contacter. Au plaisir et bonne visualisation! à bientôt, * Alban Vivert* http://www.nomadmaps.net/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] OpenEventDatabase - était OpenStreetMap dans « Libre à vous ! » - demain mardi 11 juin sur radio Cause Commune
> > Bonjour, Christian, Avais tu essayé d'importer les données TMC ? https://fr.m.wikipedia.org/wiki/Traffic_Message_Channel -- Yves > « Christian Quest : Oui. Tout à fait. OpenStreetMap a vocation à décrire > le monde, on va dire un monde un petit peu statique, une base de données > géographiques mais relativement statiques avec des choses qui ont de la > pérennité. Donc tout ce qui est très temporaire comme des travaux, des > bouchons ou des accidents, effectivement ça n’a pas sa place dans la > base OpenStreetMap. > Je vais faire une toute petite parenthèse : j’ai essayé de démarrer un > projet qui s’appelle OpenEventDatabase pour venir combler ce manque et > pour venir compléter OpenStreetMap en apportant des données qui, elles, > sont localisées dans l’espace mais aussi dans le temps, donc avec des > choses beaucoup plus liées au temps réel. Mais là, pareil, il va falloir > qu’il y ait de la collaboration, il faut que tout le monde partage ses > données en temps réel, ce qui n’est pas évident. Déjà, quand on a > démarré, ce n’était pas évident pour les données cartographiques, mais > alors pour les données en temps réel. aujourd’hui c’est encore considéré > comme le petit trésor ! »1 > > ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
