Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Luca Delucchi]

Il mar 5 mag 2020, 14:54 Anisa Kuci  ha scritto:

> Ciao a tutti,
>
> Ciao anisa,

>
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
> Italia.
>
Congratulazioni e buon lavoro

>
> Ci sentiamo presto,
>

A presto

> Anisa
>

Ciao
Luca

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

Re: [Talk-it] Nomi delle vie

[Francesco Ansanelli]

Ciao Martin,

penso che dipenda dai comuni, come per Camillo Benso che è scritto in tutte
le varianti.
Appoggio l'idea di scrivere "von" in minuscolo in ogni caso, come per la
famiglia d'Azeglio.

Francesco


Il mer 6 mag 2020, 00:57 Martin Koppenhoefer  ha
scritto:

>
>
> sent from a phone
>
> On 6. May 2020, at 00:33, Martin Koppenhoefer 
> wrote:
>
> Ho notato che ci sono alcune vie “Via Wolfgang Von Goethe” e mi chiedevo
> se non dovrebbe essere “Via Johann Wolfgang von Goethe”?
>
>
> https://nominatim.openstreetmap.org/search.php?q=Via+Wolfgang+von+Goethe_geojson=1=
>
> Che ne dite?
>
>
>
> in realtà ho adesso visto che sono solo 2 vie. Correggo?
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Présentation et cas particulier des ref sur ronds points

[Philippe Verdy]

Le mar. 5 mai 2020 à 14:56, Marc M.  a écrit :

> Bonjour,
>
> Le 05.05.20 à 10:29, BEGUIN,Bruno a écrit :
> > nous avions présenté cette application de validation d'imports OSM
> 'LeBonTag', lors du dernier SOTM France à domicile.
>
> bienvenue :) j'avais vu la présentation (sur peertube de mémoire),
> très sympa, même si le nom me fait penser à un outil tel le traducteur
> "humain -> tag" de l'assistant d'overpass turbo
>
> > Le wiki indique que les ronds-points n'ont pas à être tagués avec REF
>
> la logique selon moi est qu'on ne met pas la ref de la route sur tous
> les nœuds de celle-ci, pas même sur les croisements avec d'autres voies.
> Si on ne met pas la ref de la route sur un carrefour en croix,
> par extension on fait de même si ce "carrefour" est un rond-point.
> Le carrefour en croix ou en rond-point n'étant qu'un lieu
> ponctuel de plusieurs voies et non ces voies.
>

Cette extension  dans la dernière phrase est abusive, d'autant que certains
"rond-points" sont très grands pour avoir leurs adresses pour tout ce qui
est autour et forme une vraie place (mais pourtant intégrée à la voie au
milieu de laquelle le "rond-point" figure. Personnellement je préfère le
terme "giratoire".

Toutes ces places traversées par une voie et qui portent le nom de cette
voie dans dans les adresses situées autour ne sont pas rondes, certaines
sont nettement rectangulaires, ou ovales , ou avec une "pointe" sur un seul
des côtés comme pour un oeuf, ou taillées en "8" avec un resserrement entre
deux cotés sans pour autant qu'on puisse traverser en véhicule (dans
certains cas, un seul giratoire en "8" a été créé en fusionnant deux
giratoires proches).

Le sens réel de "giratoire" est de contraindre une voie dans un sens de
circulation unique avec une séparation des sens, puis ensuite de créer des
priorités avec plusieurs intersections (et non plus une seule intersection
centrale). La longueur des sections de voies régies en giratoires est
suffisante assez souvent pour qu'il y ait des adresses tout autour et sans
interruption de la numération de la voie qui transite via cette section
giratoire. Le giratoire peut cependant avoir encore un nom local, mais
surtout pour désigner ce qui est au milieu et non pas ce qui est autour
(place=locality si personne ne réside au milieu, place=square si de nom
couvre aussi le contour, place=neighbourhood si ça s'étend plus loin).

Hors de cette voie principale, les autres voies croisant le giratoire
voient leur numération interrompue, ces voies "secondaires" (PAS au sens de
"highway=secondary" qui qualifie plutôt le trafic, et non la désignation
des adresses et toponymie comme ici) sont scindées en deux parties
physiquement séparées tant par un écart, que par le nom et la numérotation
d'une autre rue "principale".

Le nom du giratoire lui-même (ou n'importe quel autre carrefour ou place)
est souvent indépendant des noms de rues qui le traversent

Il peut cependant arriver aussi que ce giratoire à lui tout seul devienne
le nom d'une place avec ses propres adresses: le giratoire est alors le
seul à avoir ce nom, et aucune des autres rues qui s'y connectent ne porte
ce nom, toutes ces rues ont leur numérotation interrompue avant de
reprendre de l'autre côté.

Dans certains autres cas, la rue qui traverse la place voit sa numérotation
interrompue uniquement d'un seul côté, mais la rue donne son nom à une
partie de la boucle du giratoire, le reste adoptant le nom de la place ou
le noms d'autres rues qui s'y connecte: le giratoire n'a donc pas toujours
un nom unique pour les segments de voies qui composent sa boucle, même si
la "localité" au milieu et autour est désignée par le nom de la place (ce
cas se rencontre pour diverses occurence de "Place de la Mairie", "Place de
l'Eglise", "Place de la Gare"...).

Et de plus en plus nombreuses places sont maintenant régies par les règles
de circulation d'un giratoire (quand les municipalités décident de
supprimer les feux tout autour).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tags multiples dans OSM (API v0.7)

[Philippe Verdy]

Mais ça ne résoud pas la question des valeurs réellement trop longues (dont
opening_hours, qu'on ne peut toujours pas découper facilement, d'autant que
cette proposition pour v0.7 ne concerne QUE les valeurs multiples sans
aucun ordre de tri significatif, alors que opening_hours impose un ordre
précis d'interprétation).
Si on doit respecter un ordre et pouvoir découper les valeurs longues, il
faut un système permettant le réassemblage correct des multiples valeurs et
ne pas imposer un découpage seulement sur certains caractères (comme le
seul point-virgule qui ne suffit pas aux données structurées).

C'est pour ça que j'ai émis la proposition de valeurs dans un format
compatible JSON (mais un JSON simplifié, avec quelques règles
d'équivalence, et où on n'impose pas les quotes) et où existe des règles
sur les noms des clés (distinction des clés qui sont des entiers pour les
valeurs séparées mais ordonnées, des identifiants opaques pour les valeurs
dans un ensemble sans tri significatif, et des autres identifiants
clairement nommés pour les tags conventionnels et documentés).

Dans ce cas on peut tout représenter plus facilement sous forme d'objets
structuré contenant des propriétés et sous-propriétés, comme autant de tags
et sous-tags possédant chacun une clé suivant les conventions et la
possibilité de créer un "chemin de clés" bien défini (mais potentiellement
très long) vers n'importe quel propriété ou sous-propriété, au lieu d'une
syntaxe limités avec beaucoup de redondance avec le système des préfixes et
suffixes délimités par des ":")

Ce JSON simplifié, compactable, aurait des règles d'analyse précises et non
ambiguës. Il resterait très lisible même pour une utilisation directe,
juste quelques règles pour encapsuler les quotes dans les valeurs ou les
crochets ou signes "="), et éventuellement si on a besoin d'un signe
d'échappement comme "\" pour les quelques caractères encore réservés si on
les veut dans les valeurs: \\ ou \" ou \' ou \= ou \[ ou \] ou \
(concernant les quotes je suis plutôt partisan de les ôter partout comme
délimiteurs de chaines, pour ne pas avoir non plus à les échapper avec un
"\".
Il ne resterait alors plus que \[ ou \= ou \] ou \\ qui se rencontreront
très peu souvent dans quelques valeurs, et pas du tout dans les noms des
clés standards. Donc peu de risques d'erreurs.

Et cela n'empêche pas d'avoir des "valeurs très longues" étant donné qu'on
peut les fragmenter et les réassembler dans un ordre précis, sans aucun
séparateur supposé (comme le ";" séparateur des listes non ordonnées, ou le
"," pour certaines listes ordonnées et pour le ":" dans les clés actuelles).





Le mar. 5 mai 2020 à 16:44, Yves P.  a écrit :

> Pour faire suite à mon message précédent sur les tags longs, j'aimerais
> aussi discuter à propos des tags  avec des valeurs multiples (séparées par
> des ; )
>
> J'ai lu un article d'Andy Allan (l'un des développeurs du site web d'OSM)
> au sujet d'une mise à jour en "douceur" de l'API :
> Smoother API upgrades for OpenStreetMap
> 
>
> Il ne parle pas de ce point. Par contre on l'avait abordé sur cette liste.
> Il est accessoirement évoqué sur  la page concernant la future API v0.7
> 
>
>
> Ce point est explicitement évoqué dans la page précédente :
> https://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags
>
> Je propose que la version 0.7 gère des tags de plus de 255 caractères :)
> Et pour le passage en douceur, que ce tag soit découpé/réasssemblé
> automatiquement en plusieurs tags pour les logiciels fonctionnant en v0.6
>
>
> La solution proposé ressemble assez à ma proposition pour les grands tags
> (on coupe la valeur arbitrairement tous les 255 caractères).
>
> Ici, on coupe/réassemble à chaque séparateur (fonctions SPLIT / EXPLODE de
> certains langages)
>
> Exemple :
>
> v0.7
>
> my_tag=value 1
> my_tag=value 2
> my_tag=value 3
>
> donnerait en 0.6
> my_tag=value 1;value 2;value 3
>
> Si la valeur est trop grande, on combine ça avec ma proposition précédente
> (en essayant si possible de couper au niveau d'un séparateur)
>
> C'est compatible avec tous les éditeurs et une fois tous les outils en
> v0.7, TagInfo permettra de compter "correctement' les tags utilisés.
>
> __
> Yves
> ___
> 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] Ecole maternelle / primaire : amenity=school ou kindergarten

[Violaine_Do]

Hello


Pourquoi est-il dit qu’il n’y a pas d’avis contre ?

Pourquoi est-il dit qu’il n’y a pas d’avis contre ?
Consensus ? Pour moi ça n'implique pas l'absence d'opposition. Ou j'ai mal 
tourné une autre phrase ?
Ce n'était pas mon intention en tous cas.



Euh.. c'est moi qui est dit qu'il n'y avait pas d'avis contre. :) 
Pourquoi? Juste car je n'en ai pas vu à l'écriture du mail, aussi simple 
que ça. J'attendais vos retours :p



Je suis contre la manipulation des tags sans vérifier que cela ne s’inscrit pas 
dans une vision
internationale.
Cela paraît être un cas flagrant de nombrilisme franco-français.

Si je reprends les versions anglophones :
school :
===
Use amenity=school to identify a place where pupils, normally between the ages 
of about 6 and 18 are taught under the supervision of teachers.


Et fin de la définition en anglais : "This includes primary and 
secondary school".


Donc on reste dans le cadre international, mettre les maternelles dans 
amenity=school, pour la France, ne remet pas en question la définition 
de amenity=school à l'échelle internationale. Pas de manipulation de 
tags en vue, pour moi... SI? Alors pourquoi? J'ai du mal a comprendre 
pourquoi on aurait besoin d'un vote pour une traduction... (je ne parle 
que des maternelles). Après autant le faire si ça permet d'avancer sur 
cette discussion.


@+


--
Violaine_Do


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

Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

[Philippe Verdy]

Moi aussi je suis favorable à l'embauche d'employés (qui au moins seront
soumis à une autorité et une étique de travail pour assurer aussi une
certaine neutralité : l'employeur de son côté ne doit pas intervenir dans
chaque décision prise, sauf pour régler des problème sérieux nécessitant de
remonter les problème hiérarchiquement à une autorité supérieure pouvant
déléguer cela à un médiateur avant une sanction disciplinaire qui elle
aussi est équilibrée par le droit du travail).

Certes cela a un coût, mais comme cela devient une structure permanente, ce
que fait cette structure sera aussi ce qu'affiche l'organisation pour sa
communication au public: l'organisation devient responsable autant
vis-à-vis du public indépendant que vis à vis de ses employés (à qui elle
doit aussi des conditions de travail correctes, sinon ils démissionnent ou
il y aura de l'absentéisme coûteux).

N'avoir que des bénévoles (dont certains idéalement placés et ayant tous
les moyens à leur disposition pour faire tout ce qu'ils veulent) n'est pas
équitable et pas responsable vis-à-vis d'une communauté aussi large.

C'est pour ça que Wikimedia a une structure permanente d'employés, qui en
revanche sont tenus par leurs contrat de travail, les clauses de
confidentialité et d'équité et neutralité vis à vis de la communauté. Mais
cette permanence a de gros avantages: tout le monde est traité à égalité,
les moyens utilisés sont mieux contrôlés (et en continu), il y a des
objectifs à remplir (dont les objectifs affichés publiquement par la
fondation et établis en concertation avec la communauté: la fondation
elle-même ne décide pas de cette charte, mais elle assure uniquement la
légalité et la protection du projet).

Et là la Fondation OSM ne fonctionne pas du tout comme il devrait, et ne
contrôle même pas du tout ce qui est décidé et appliqué autoritairement par
quelques bénévoles trop influents que personne n'ose contredire.

On a le même problème avec Wikipédia où ses communautés locales sont tenues
par quelques bénévoles trop influents, mais pas du tout dans les wikis
internationaux (MetaWiki, Commons, Wikidata) où c'est beaucoup plus
collégial et où cela progresse en permettant la participation du plus grand
nombre et l"émergence de nouvelles idées (pas sanctionnées immédiatement
par des reverts ou suppressions abusives : on laisse le temps de stabiliser
les choses, les problèmes sont signalés, listés et suivis, il y en a
beaucoup donc aucune urgence le plus souvent à devoir les régler tous très
vite: on a le temps de faire des recherches, tester des alternatives,
évaluer les solutions possibles, discuter... les admins sur ces wikis ne
sont pas débordés et pourtant ils sont nettement moins nombreux.

Les admins sur Wikipédia en revanche sont trop nombreux pour qu'on puisse
suivre ce qu'ils font, ils ont des pouvoir trop forts (d'ailleurs ils ne
sont même pas d'accord entre eux mais ils n'osent pas non plus se
contredire publiquement: ils ont chacun leur domaine privilégié et
globalement ils se sont juste partagés sans le dire leurs activités en
évitant seulement d'empiéter sur le domaine suivi par un autre admin: le
résultat c'est des contenus fragmentés, très peu homogènes entre eux), ils
ne rendent pas compte assez de leurs actions et justifient très peu leurs
décisions qui ensuite ne sont plus contestables du tout même quand la
situation a évolué: Wikipédia comme OSM souffre d'une paralysie chronique
imposée de force par quelques bénévoles trop influents et qui arrivent même
à imposer aux autres la conservation de leurs privilèges par une forme très
claire de contrainte).

Cependant concernant Wikipédia, cela s'est nettement amélioré grâce aux
efforts de rationalisation faits sur Wikidata (déjà commencés avant sur
Commons): la structuration des données a nettement clarifié les sujets et
permis de cerner et isoler les conflits éventuels. Cette isolation a permis
de séparer mieux les sujets sur Wikipédia ainsi que les points de vue: cela
se voit dans la neutralité, la couverture des sujets, un meilleur
référencement des sources, et sur les wikis les plus actifs, une meilleure
coopération (il reste cependant des zones d'ombre sur les wikis de
certaines langues, comme en serbe, croate, turc, chinois, où on voit
nettement l'influence des conflits politiques nationaux et le problème de
suprématie selon le point de vue d'une zone "majoritaire"; même pour le
Wikipéfia francophone, on a une trop forte influence du point de vue
franco-français, au détriment des francophones belges, suisses, canadiens
ou ouest-africains sous-représentés).

Je ne vois qu'une solution pour OSM: ne pas segmenter les projets par
langue, veiller à ce que toutes les nations soient représentées, ne pas
imposer une langue majoritaire à un pays, ni imposer un pays pour une
langue. Assurer la neutralité des traductions (quelle que soit la langue:
pas de préférence ou priorité contrairement à ce qui a été fait sur le wiki
OSM et ses 8 langues dont 1 l'anglais est 

Re: [OSM-talk-fr] Tag "covid19" - Info sur le port obligatoire du masque

[Philippe Verdy]

Je pense que "safety_equipment=chain" veut dire l'obligation d'avoir des
chaines aux roues (et de les installer si nécessaire) pour passer des cols
enneigés ou verglacés (cette obligation peut être indiquée par un panneau
permanent, éventuellement complété d'un panonceau automatique surveillant
la température ou relayant un message émis par l'autorité routière, ou
mettant cette obligation certains mois de l'année).

Il pourrait aussi être utilisé pour mentionner les zones permettant l'ARRÊT
en sécurité le temps d'installer les chaines : de petits parkings avec des
places réservés à ça ou de simples "bateaux" en bordure de voie, où le
stationnement n'est cependant pas autorisé mais réservés à cette
utilisation temporaire, mais sur une surface sans pente (le véhicule sur
cric est instable, le frein à main ne suffit pas à retenir si on décolle
des roues du sol) et avec un espace suffisant tout autour pour assurer la
sécurité du conducteur et du véhicule contre les collisions par les autres
usagers de la route, ou sur une aire de service où la vitesse est limitée
et où il y a une protection physique par la séparation des voies ou des
barrières de sécurité.

* Je ne pense pas sinon que cela concerne les barrières sous forme de
simple chaîne, sauf pour bloquer le passage des véhicules tout en laissant
passer les piétons (n'assure que la sécurité limitée, des piétons contre
les véhicules de l'autre coté).

* Pour ces chaines là je pense que c'est un tag "barrier=chain" qui
conviendra le mieux. Une chaîne n'est pas adaptée non, plus à prévenir les
piétons d'un danger, tout au plus elle peut marquer une limite de propriété
et restreint l'accès aux véhicules, ou alors c'est un simple guidage des
files d'attente de piétons (et donc ce n'est pas du tout un "équipement de
sécurité").

* Le seul cas de chaîne-barrière pouvant constituer un équipement de
sécurité c'est celui des très lourdes chaines tenues entre piliers, le long
d'un quai (canalisé, fluvial, lacustre ou maritime), capable de réellement
retenir un véhicule et contraindre leur circulation sur une voie
suffisamment éloignée du bord du bassin et de protéger les promeneurs ou
pêcheurs à la ligne en leur gardant un espace où ils pourront aussi
circuler et de croiser dans chuter dans le bassin ; si cet espace est peu
large, et la chute dans le bassin est dangereuse, une chaine de séparation
des piétons et du bassin ne suffira pas, il faudra un parapet, un muret,
une vraie barrière.


Le mar. 5 mai 2020 à 23:38, Frantz  a écrit :

> 4 mai 2020 21:43 "Marc M."  a écrit:
>
> > Le 01.05.20 à 22:01, Georges Dutreix via Talk-fr a écrit :
> >
> >> Pour être plus universel, on pourrait alors proposer
> >> safety:covid19 = mask; glove; ...
> >
> > cela me semble une très bonne idée.
>
> tag info nous donne :
> - 12 safety=* (3 Terrorism, 3 for cylindric lock, 2 life_bouy, 2 no, 1
> cylindric lock et 1 DPI)
> - 4 safety_equipment=chain
> - 0 epp
>
> epp est précis mais abscons
> safety est facilement compréhensible mais semble avoir une tendance
> fourre-tout
> safety_equipment ?
>
> --
> Frantz
>
> ___
> 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] Bridge area construction

[Warin]

On 6/5/20 8:41 am, Martin Koppenhoefer wrote:



sent from a phone


On 6. May 2020, at 00:08, Pierre Béland  wrote:

I dont think that it is appropriate to superpose a landuse over a 
waterway.



this is a good point, but you could spare the waterway out and just 
tag the construction site on the land. Depending on the details, 
bridge span and kind of construction, this can lead to good 
(temporary) representations or also be inadequate.



Devils advocate hat on:

Water is simply a land cover. So landuse is fine over water. In fact it 
is used for landuse=aquaculture.







Since the tag man_made=bridge is used, it seems better to  refer to 
the construction project with the tags as proposed by Jack Armstrong


- man_made=construction
- construction=bridge
- layer=1



there are only 40 man_made=construction in the whole world: 
https://taginfo.openstreetmap.org/tags/man_made=construction


the tag sounds reasonable, but it isn’t really done this way.



Yet according to the wiki a bridge is normally tagged man_made=bridge,  
so it is logical to deduct that a bridge under construction should be


man_made=construction

construction=bridge

layer=1

-- Use?
Less than 10% of landuse=construction have construction=*

There are one 3 landuse=bridge.

There are over 86,000 man_made=bridge.


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

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Philippe Verdy]

Note: ce qui est trompeur sur le site du Wiki OSM c'est que les noms
d'espaces pour les traductions de pages dans 7 langues hors de l'anglais
(DE, ES, FR, IT, JA, NL, RU) sont en capitales et non en minuscules.

Toutes les autres langues sont dans l'espace principal. Ce n'est pas
évident à voir car les espaces de nom n'ont pas de casse significative, et
on peut les capitaliser comme on veut pour former les liens, y compris en
minuscules, mais la page affichera son titre avec l'espace de nom en
capitales pour ces seules 7 langues (et aucune autre puisqu'il a été décidé
il y a longtemps de ne pas créer d'autres espaces de noms pour chacune des
langues possibles)

Donc "Tag:school" est traduit en portugais dans "Pt:Tag:school" avec "Tag"
qui fait partie du nom de la page et n'est pas un espace de noms séparé,
mais qu'on ne peut plus écrire "tag", alors "pt" est en minuscules et seule
l'initiale peut être capitalisée).

Cette incohérence de traitement des codes langues sur le wiki OSM est là
depuis le début, et n'a jamais changé. Cela vient de décisions prises il y
a longtemps par les administrateurs du wiki (et leur refus d'y changer quoi
que ce soit). Pour faire les traductions dans d'autres langues que
l'anglais et ces 7 langues, il a fallu "ruser" et trouver une méthode
compatible avec ces décisions passées.

Elle a aussi une autre conséquence: les outils complémentaires de
traductions de Wikimedia ne fonctionnent pas : pas moyen de convaincre les
administrateurs du wiki OSM d'utiliser non pas des espaces de noms pour les
langues, mais des sous-pages "/de, /es, /fr, /it, /nl, /ru" en minuscules
comme aussi "/pt" et toutes les autres langues).

Ces mêmes admins sont restés même totalement inactifs pendant des années en
ne répondant à aucune des demandes concernant la gestion des traductions du
site. Ils ont beaucoup tardé aussi à mettre à jour les versions de
Mediawiki (pour corriger de nombreuses anomalies) et à installer le support
de Lua (arrivé très tardivement) et le nouveau parseur (bien plus efficace
et utilisant moins de mémoire et de CPU, sur un serveur déjà très lent!).
Quand un d'eux s'est réveillé (après des années de laisser-aller), leurs
décisions ont été inconséquentes voire expéditives. Ils n'ont rien retenu
des discussion ou problèmes passés (mais pourtant toujours existants).

La maintenance du wiki a totalement été négligée par eux, et ceux qui ont
essayé de s'en occuper (avec beaucoup d'effort) ont été bannis
définitivement sans aucune considération du travail continu.
Depuis la maintenance de ce wiki est totalement abandonnée et les
incohérences et saccages se multiplient. Plus rien ne
fonctionne correctement, il n'y a que des contributeurs séparés qui font
chacun ce qu'ils veulent dans leur coin (mais que les admins
pourtant laissent faire, alors qu'ils font des tas d'erreurs non corrigées)
chacun avec ses méthodes: ce wiki est devenu un enfer (et il n'y a
strictement aucune "coopération" ni démocratie participative, quelques uns
décident de tout, tous les autres font tout dans le désordre le plus
complet)





Le mer. 6 mai 2020 à 00:50, Philippe Verdy  a écrit :

> Je suis d'accord concernant l'utilisation du tag "school=*" qui devrait
> être internationale.
>
> En revanche, la classification franco-française a sa place... dans le tag
> "school:FR=*" qu'aucun autre pays ne viendra disputer (le consensus sur
> "school:FR" peut être établi par une discussion ici et dans le forum et
> avec les utilisateurs finaux, y compris les adminsitrations françaises, qui
> pourront donc apporter les précisions et références concernant la
> classification française).
>
> (ne pas confondre avec le nom de page wiki "FR:Tag:school" où le préfixe
> ne désigne QUE la langue française et pas la France uniquement, cette page
> continuant donc à parler de la classification internationale "school=*" et
> "amenity=kindergarden", il faudra donc y ajouter une section spécifique ou
> une autre page liée pour le tag secondaire "school:FR=*" (décrit en
> français sur le wiki dans la page "FR:Tag:school:FR", mais décrit en
> anglais dans la page "Tag:school:FR" !).
>
> Bref je ne suis pas favorable du tout à modifier le sens du tag "school=*"
> dans la page wiki "FR:Tag:school" qui doit être conforme par son contenu
> avec la page "Tag:school" en anglais et ne devrait qu'en donner une
> traduction à peine adaptée pour préciser le sens (mais on peut y ajouter un
> lien vers la page "[FR:]Tag:school:FR" pour parler de la classification
> nationale, comme on pourrait avoir aussi une page
> "[FR/NL/DE:]Tag:school:BE" pour la classification scolaire en Belgique ou
> une page "[FR:]Tag:school:CA" pour la classification canadienne, toutes ces
> pages pouvant avoir des traductions, dont une faisant référence qui n'est
> pas forcément la version anglaise sans le préfixe de langue.).
>
>
> Le mar. 5 mai 2020 à 23:48, Christian Rogel <
> christian.ro...@club-internet.fr> a écrit :
>
>>
>>
>> > Le 5 mai 2020 à 23:01, Frantz  

Re: [Talk-it] Nomi delle vie

[Martin Koppenhoefer]

sent from a phone

> On 6. May 2020, at 00:33, Martin Koppenhoefer  wrote:
> 
> Ho notato che ci sono alcune vie “Via Wolfgang Von Goethe” e mi chiedevo se 
> non dovrebbe essere “Via Johann Wolfgang von Goethe”? 
> 
> https://nominatim.openstreetmap.org/search.php?q=Via+Wolfgang+von+Goethe_geojson=1=
> 
> Che ne dite?


in realtà ho adesso visto che sono solo 2 vie. Correggo?

Ciao Martin ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-is] Adjusting flow of Jökulsá á Fjöllum river

[Sveinn í Felli]

A couple of anecdotes;

The old Danish maps adopted a specific hatch to represent "variable" 
riverbeds, both for glacier floodplains and marshlands.


But the last time a similar situation occurred; a lava flow moving a big 
river representing administrative boundaries; that was in 1783 when the 
second branch of lava from the Laki eruption (Eldhraun) deviated the 
river Hverfisfljót from it's riverbed. In one place the river found new 
course east and south of a mountain called Hnúta [1] instead of running 
north and west of it down into the valley below.


Now, this upper part of Hverfisfljót separated two different types of 
land; the shared common (afréttur) for the county of Kleifahreppur on 
the west bank, and a private property of the farm Dalshöfði in 
Fljótshverfi on the east bank. This distinction used to be hugely 
important because all the farms had duty of supplying n persons (or pay 
else) for collecting sheep in the autumn, hunting foxes, and some more. 
This duty (fjallskil) was considered equal to taxes.


When the farm properties extended all the way up to the glacier, like 
many do in Fljótshverfi, the owner was only responsible to himself and 
his neighbors, but nevertheless had to fulfill the duty of collecting 
sheep, etc. from his land.


With the new course of the river Hverfisfljót, the mountain Hnúta was 
all of a sudden on the west bank inside the shared common area, even if 
still being property of the farm Dalshöfði; so the farmers in Dalshöfði 
became obliged to supply 2 men each autumn to gather sheep from that 
mountain even if they didn't have any sheep on that side of the river.
The interesting or funny part of this story is that this continued to be 
so for about 200 years; it wasn't until in the 1980s when this duty was 
finally abolished for the farmers í Dalshöfði.


But if I'm not mistaken, the administration boundary from pre-1783 still 
persists around Hnúta...


Best regards,
Sveinn í Felli

[1]: 


Þann 5.5.2020 20:12, skrifaði Hauke Stieler:

Hi,

thanks for the quick reply. As you said, I separated them, so that the
boundaries haven't moved.

Hauke

On 05.05.20 18:55, Jóhannes Birgir Jensson wrote:

The boundaries will have to be separated from the river flow.

Digital markers are now above geography in boundary marking.

 Upprunalegt skeyti 
Frá: Hauke Stieler 
Dagsetning: 5.5.2020 16:35 (GMT+00:00)
Til: OpenStreetMap in Iceland 
Efni: [Talk-is] Adjusting flow of Jökulsá á Fjöllum river

Hi all,

I would like to edit the flow of the Jökulsá á Fjöllum river [0] near
the Holuhraun lava field [1] as the lava field is quite new and the
river flow outdated.

But: The river is also within several administration boundary relations.
When I change the river flow, I also change the course of the boundaries.

Is that even a problem or is it ok to edit the river and therefore also
change the boundaries?

In case this is a problem and the boundaries should stay where they are,
I would create a new way for the river and tag the existing line with
"boundary=administrative".

What do you think about this, I would like to hear some feedback :)

Hauke

[0] https://www.openstreetmap.org/way/741064529
[1] https://www.openstreetmap.org/relation/11071456


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




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




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

Re: [OSM-talk] Bridge area construction

[Martin Koppenhoefer]

sent from a phone

> On 6. May 2020, at 00:28, Tobias Knerr  wrote:
> 
> The =construction + construction= tagging is only really
> common for highway, building and railway tags (where it sticks around
> for historic reasons, in my impression).


interestingly, these are also the leading tags for the lifecycle tagging:

https://taginfo.openstreetmap.org/search?q=construction%3A

construction:man_made has 215 uses, of which 152 with the value “bridge”, 
that’s not an incredibly huge amount, but likely the most established and 
consistent version as of now, given that “construction:” is quite established 
as a concept.


Cheers Martin 

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

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Philippe Verdy]

Je suis d'accord concernant l'utilisation du tag "school=*" qui devrait
être internationale.

En revanche, la classification franco-française a sa place... dans le tag
"school:FR=*" qu'aucun autre pays ne viendra disputer (le consensus sur
"school:FR" peut être établi par une discussion ici et dans le forum et
avec les utilisateurs finaux, y compris les adminsitrations françaises, qui
pourront donc apporter les précisions et références concernant la
classification française).

(ne pas confondre avec le nom de page wiki "FR:Tag:school" où le préfixe ne
désigne QUE la langue française et pas la France uniquement, cette page
continuant donc à parler de la classification internationale "school=*" et
"amenity=kindergarden", il faudra donc y ajouter une section spécifique ou
une autre page liée pour le tag secondaire "school:FR=*" (décrit en
français sur le wiki dans la page "FR:Tag:school:FR", mais décrit en
anglais dans la page "Tag:school:FR" !).

Bref je ne suis pas favorable du tout à modifier le sens du tag "school=*"
dans la page wiki "FR:Tag:school" qui doit être conforme par son contenu
avec la page "Tag:school" en anglais et ne devrait qu'en donner une
traduction à peine adaptée pour préciser le sens (mais on peut y ajouter un
lien vers la page "[FR:]Tag:school:FR" pour parler de la classification
nationale, comme on pourrait avoir aussi une page
"[FR/NL/DE:]Tag:school:BE" pour la classification scolaire en Belgique ou
une page "[FR:]Tag:school:CA" pour la classification canadienne, toutes ces
pages pouvant avoir des traductions, dont une faisant référence qui n'est
pas forcément la version anglaise sans le préfixe de langue.).


Le mar. 5 mai 2020 à 23:48, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
>
> > Le 5 mai 2020 à 23:01, Frantz  a écrit :
> >
> > 5 mai 2020 19:25 "deuzeffe"  a écrit:
> >
> >> Le 04/05/2020 à 21:44, Violaine_Do a écrit :
> >>> Donc je suis ok avec la proposition de Deuzeffe/Franck et tout le
> monde,
> >>> je ne vois pas ce qui bloque de passer la maternelle sous
> >>> amenity=school, il n'y a pas d'avis contre, non?
> >>
> >> Bah non, pour une fois qu'il semble qu'il y ait un consensus clair, ça
> >> traîne, je ne sais pas pourquoi :/
> >
> > Je viens de modifier les pages du Wiki FR:Tag:amenity=school et
> FR:Tag:amenity=kindergarten, en ajoutant la référence à ce fil dans la
> partie discussion.
> >
> > --
>
>
> Pourquoi est-il dit qu’il n’y a pas d’avis contre ?
>
> Je suis contre la manipulation des tags sans vérifier que cela ne
> s’inscrit pas dans une vision internationale.
> Cela paraît être un cas flagrant de nombrilisme franco-français.
>
>
>
> Christian R.
>
>
> ___
> 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] Bridge area construction

[Martin Koppenhoefer]

sent from a phone

>> On 6. May 2020, at 00:08, Pierre Béland  wrote:
> I dont think that it is appropriate to superpose a landuse over a waterway.


this is a good point, but you could spare the waterway out and just tag the 
construction site on the land. Depending on the details, bridge span and kind 
of construction, this can lead to good (temporary) representations or also be 
inadequate.


> 
> Since the tag man_made=bridge is used, it seems better to  refer to the 
> construction project with the tags as proposed by Jack Armstrong
> 
> - man_made=construction
> - construction=bridge
> - layer=1


there are only 40 man_made=construction in the whole world: 
https://taginfo.openstreetmap.org/tags/man_made=construction

the tag sounds reasonable, but it isn’t really done this way.


Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Bridge area construction

[stevea]

On May 5, 2020, at 3:29 PM, Rafael Avila Coya  wrote:
>> I use the lifecycle prefixes a lot, specially for shops, restaurants and 
>> others that close. Like for example disused:shop=* or 
>> disused:amenity=restaurant, etc. The abandoned:*=* prefix is also quite 
>> useful.

This is terrific, however I ask that caution be used with some of these, in 
particular abandoned and with railways.  There is such a tag as 
railway=abandoned and some renderers use it (OpenRailwayMap) and others don't 
(Carto).  It would be "less correct" to use the tag abandoned:railway=rail 
whereas tag railway=abandoned is "perfectly correct."  There are other examples.

The upshot is to please do your best with wiki research and perhaps some 
taginfo and / or OverpassTurbo queries.  That is simply a good idea if you 
really don't know how to tag and really want to tag "more correctly."  (And 
hasn't this been true for all of us, to some extent?!)

Thanks for reading,
SteveA
California
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] Nomi delle vie

[Martin Koppenhoefer]

Ho notato che ci sono alcune vie “Via Wolfgang Von Goethe” e mi chiedevo se non 
dovrebbe essere “Via Johann Wolfgang von Goethe”? 

https://nominatim.openstreetmap.org/search.php?q=Via+Wolfgang+von+Goethe_geojson=1=

Che ne dite?

Ciao Martin 

sent from a phone___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Bridge area construction

[Rafael Avila Coya]

You may consider to use the lifecycle namespace prefix [1] to map the 
bridge. In your case it would be:


construction:man_made=bridge

layer=1

In the near future, when the construction is finished and the bridge is 
already operative, you just delete the construction: prefix.


I use the lifecycle prefixes a lot, specially for shops, restaurants and 
others that close. Like for example disused:shop=* or 
disused:amenity=restaurant, etc. The abandoned:*=* prefix is also quite 
useful.


Cheers,

Rafael.

[1] https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

O 06/05/20 ás 00:08, Pierre Béland via talk escribiu:



On 5. May 2020, Martin Koppenhoefer wrote:

I think the common tag would be landuse=construction




I dont think that it is appropriate to superpose a landuse over a 
waterway.


Since the tag man_made=bridge is used, it seems better to  refer to 
the construction project with the tags as proposed by Jack Armstrong


- man_made=construction
- construction=bridge
- layer=1



Pierre


Le mardi 5 mai 2020 17 h 53 min 59 s UTC−4, Martin Koppenhoefer 
 a écrit :





sent from a phone


On 5. May 2020, at 22:27, Jack Armstrong  wrote:

I assume the best way to map a large bridge *area* that's under 
construction would be with the minimum following tags? I'm not asking 
about the ways associated with/on the bridge.


man_made=construction
construction=bridge
layer=1



I think the common tag would be landuse=construction

Cheers Martin
___
talk mailing list
talk@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] Bridge area construction

[Tobias Knerr]

On 05.05.20 22:24, Jack Armstrong wrote:
> man_made=construction
> construction=bridge
> layer=1

The =construction + construction= tagging is only really
common for highway, building and railway tags (where it sticks around
for historic reasons, in my impression).

Other tags are more likely to use to use lifecycle prefixes:
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix

For your example, that would be:

construction:man_made = bridge
layer = 1

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

Re: [OSM-talk] Bridge area construction

[Pierre Béland via talk]

On 5. May 2020,   Martin Koppenhoefer wrote:


I think the common tag would be landuse=construction



I dont think that it is appropriate to superpose a landuse over a waterway.

Since the tag man_made=bridge is used, it seems better to  refer to the 
construction project with the tags as proposed by Jack Armstrong

- man_made=construction- construction=bridge- layer=1

 
Pierre 
 

Le mardi 5 mai 2020 17 h 53 min 59 s UTC−4, Martin Koppenhoefer 
 a écrit :  
 
 

sent from a phone

On 5. May 2020, at 22:27, Jack Armstrong  wrote:



I assume the best way to map a large bridge area that's under construction 
would be with the minimum following tags? I'm not asking about the ways 
associated with/on the bridge.
man_made=constructionconstruction=bridgelayer=1


I think the common tag would be landuse=construction
Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Frantz]

5 mai 2020 23:48 "Christian Rogel"  a écrit:

> Pourquoi est-il dit qu’il n’y a pas d’avis contre ?

Consensus ? Pour moi ça n'implique pas l'absence d'opposition. Ou j'ai mal 
tourné une autre phrase ?
Ce n'était pas mon intention en tous cas.

> Je suis contre la manipulation des tags sans vérifier que cela ne s’inscrit 
> pas dans une vision
> internationale.
> Cela paraît être un cas flagrant de nombrilisme franco-français.

Si je reprends les versions anglophones :
school : 
===
Use amenity=school to identify a place where pupils, normally between the ages 
of about 6 and 18 are taught under the supervision of teachers.
===

kindergarten :
===
Use the amenity=kindergarten for establishments offering early years education 
and supervision (also known as pre-schools) for children up to the age of 
formal (often mandatory) school education. This tag is also currently used for 
establishments where parents can leave their young children but which provide 
no formal education. 
===

teatchers pour school et no formal education pour kindergarten, je trouve qu'on 
revient plutôt vers ces définitions.
Mais si ça pose problème, j'annule la modif bien sûr.

-- 
Frantz

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

Re: [OSM-talk] Bridge area construction

[Martin Koppenhoefer]

sent from a phone

> On 5. May 2020, at 22:27, Jack Armstrong  wrote:
> 
> I assume the best way to map a large bridge area that's under construction 
> would be with the minimum following tags? I'm not asking about the ways 
> associated with/on the bridge.
> 
> man_made=construction
> construction=bridge
> layer=1


I think the common tag would be landuse=construction

Cheers Martin ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Christian Rogel]

> Le 5 mai 2020 à 23:01, Frantz  a écrit :
> 
> 5 mai 2020 19:25 "deuzeffe"  a écrit:
> 
>> Le 04/05/2020 à 21:44, Violaine_Do a écrit :
>>> Donc je suis ok avec la proposition de Deuzeffe/Franck et tout le monde,
>>> je ne vois pas ce qui bloque de passer la maternelle sous
>>> amenity=school, il n'y a pas d'avis contre, non?
>> 
>> Bah non, pour une fois qu'il semble qu'il y ait un consensus clair, ça
>> traîne, je ne sais pas pourquoi :/
> 
> Je viens de modifier les pages du Wiki FR:Tag:amenity=school et 
> FR:Tag:amenity=kindergarten, en ajoutant la référence à ce fil dans la partie 
> discussion.
> 
> -- 


Pourquoi est-il dit qu’il n’y a pas d’avis contre ?

Je suis contre la manipulation des tags sans vérifier que cela ne s’inscrit pas 
dans une vision internationale.
Cela paraît être un cas flagrant de nombrilisme franco-français.



Christian R.


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

Re: [OSM-talk-fr] Limite de 255 caractères dans les tags OSM

[Philippe Verdy]

Cela ne dit pas comment les clés _1, _2 seront assemblées en une seule: en
séparant les valeurs par des point-virgules, des virgules, des espaces ou
rien du tout (concaténation simple).

L'usage actuel serait que des valeurs multiples sont dans des _1, _2, etc.
séparés et que leur séparation par défaut serait alors le point-virgule (ce
que fait déjà iD et certains éditeurs pour des valeurs multiples ou
différentes après une fusion de deux objets: ces _2 sont plutôt
l'indication d'une erreur ou ambiguïté à traiter manuellement, l'éditeur
ayant été incapable de choisir entre des valeurs potentiellement
incompatibles)...

Mais alors cela ne résoud toujours pas le problème des valeurs longues où
ce point-virgule "'implicite" sera faux (par exemple les balises
"opening_hours" qui ont des règles spécifiques de séparation).

Si OSM doit évoluer, c'est pour permettre des valeurs de balises
"structurées". Actuellement les balises sont de simple tableaux
unidimensionnels avec une clé unique quasiment opaque.

L'évolution normale serait d'avoir un balisage de type DOM: chaque objet
OSM dispose d'un tableau associatif de clés dont les valeurs seraient: soit
une chaine, soit un autre tableau associatif avec ses propres sous-clés; de
quoi mettre fin alors aux conventions de nommage des clés avec le ":" et
autres "_" ; la seule nouveauté étant en fait sur les valeurs de clés et
non les clés principales des balises).

Et sa représentation en JSON ou XML est simplissime: actuellement un tag
OSM est un unique élément XML, et la valeur du tag OSM est codée comme la
clé OSM dans des attributs d'élement XML; cette valeur OSM pourrait être
plutôt dans le contenu de cet élément, qui serait: soit du texte, soit
d'autres tags OSM... (un peu comme le HTML avec son "mixed content model").
Mais encore mieux: on peut aussi garder cet attribut XML mais n'admettre
alors dans le contenu de la balise XML QUE d'autres tags OSM
réprésentés comme éléments XML

Et dans ce cas, un tag OSM est valide si l'attribut de valeur est vide mais
s'il y a des tags OSM codés dans le contenu de l'éléments XML. Il est alors
possible de faire une bijections avec une représentation "compacte" où les
valeurs simples ou composées seraient toutes codées en JSON : si une valeur
en attribut commence par "{", elle doit finir par "}" et doit être un
tableau associatif au format JSON valide ; si cette valeur commence par
"[", elle doit finir par un "]" et être une liste ordonnées JSON valide
(équivalente aussi à un tableau associatif indexé par des entiers naturels
implicites).

L'avantage de cette méthode serait que dans la base de données, on n'a plus
de limites en nombre de clés, les valeurs trop longues sont convertibles en
liste ordonnée (tableau associatif indexé par des entiers), aucun
séparateur implicite n'est imposé, on n'a plus besoin des ";" dans les
valeurs qui seront plutôt converties en sous-liste:

Par exemple le tag:
"truc" = "valeur1;valeur2"
devient
"truc" = "[_1='valeur1','_2='valeur2'}"
en format JSON préservant la séparation des valeurs par l'utilisation de
clés "_1", "_2" arbitraires dans une table associative. Toutes les valeurs
longues sont encore possibles:
"truc" = "{_1=['valeur1a', 'valeur1b'], '_2='valeur2'}"

Cela représente l'arbre "DOM" suivant (où les "valeurs longues" ont été
concaténées :

  'truc'
|
+--> '_1' --> 'valeur1avaleur1b'
|
+--> '_2' --> 'valeur2'

Ou encore les tags OSM classiques (si y admet les valeurs longues, et en
supposant que ":" reste utilisé pour structurer les clés qui du coup ont un
problème de taille et de duplication des préfixes):

"truc:_1" = "valeur1avaleur1b"
   "truc:_2" = "valeur2"

Et si on veut pour OSM, on peut utiliser un format JSON "simplifié" pour
les tables et listes: pas d'obligation de mettre les clés ou valeurs entre
quotes simples ou double, tant qu'elles ne contiennent pas de ',' ni
parenthèses ni crochets, ni guotes, et les espaces touchant les "{}", ou
"[]", ou "," ou"," sont non-significatifs:
truc = { _1 = [valeur1a, valeur1b], _2 = valeur }
équivalent aussi à
truc = {_1=[valeur1a,valeur1b],_2=valeur}

On peut encore simplifier JSON plus en imposant aucun signe "=" dans les
clés OSM valides, et dans ce cas pas besoin de distinguer "{}" et "[]"
comme en JSON, on peut aussi bien utiliser "[]" partout:
   truc = [_1=[valeur1a,valeur1b],_2=valeur]
toujours équivalent aussi à
   truc = [_1=valeur1avaleur1b,_2=valeur]

Mais à tout moment on conserve des donnés structurées, on n'a plus aucune
limite sur les clés ou les longueurs de valeur et on a le même arbre DOM,
qu'on peut représenter en JSON valide (mais avec des valeurs longues non
limitées en taille:
  truc =  { '_1' = 'valeur1avaleur1b', '_2' = 'valeur' }
Dans cette structure les clés "_1', _2" sont arbitrairement générées et
n'ont aucune notion d'ordre, les valeurs n'ont pas de clé d'accès unique
identifiable autrement qu'en les parcourant toutes depuis une clé de base,
un peu comme le ";" des 

Re: [OSM-talk-fr] Tag "covid19" - Info sur le port obligatoire du masque

[Frantz]

4 mai 2020 21:43 "Marc M."  a écrit:

> Le 01.05.20 à 22:01, Georges Dutreix via Talk-fr a écrit :
> 
>> Pour être plus universel, on pourrait alors proposer
>> safety:covid19 = mask; glove; ...
> 
> cela me semble une très bonne idée.

tag info nous donne :
- 12 safety=* (3 Terrorism, 3 for cylindric lock, 2 life_bouy, 2 no, 1 
cylindric lock et 1 DPI)
- 4 safety_equipment=chain
- 0 epp

epp est précis mais abscons
safety est facilement compréhensible mais semble avoir une tendance fourre-tout
safety_equipment ?

-- 
Frantz

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

[Talk-dk] Tagging of No Pedestrian Crossings

[Theodore Ahlvin via Talk-dk]

Hejso! The Apple team has recently been investigating pedestrian navigability 
in Denmark and we’ve come across some issues that would be best handled with 
consensus from the OSM Denmark community.

Often streets intersect with dual carriageways where there are no crossings 
marked for pedestrians. For example, how Fyensgade intersects with Viborgvej at 
56.4631795, 10.0156701 (way 30155258). In this situation, and similar 
situations across the country, it could be dangerous or illegal for pedestrians 
to cross the dual carriageway. These crossings can also be all but impossible 
for individuals with disabilities using OSM to navigate. Our team has been 
adding ‘foot=no’ tags to these sections, but after a conversation with user 
MikkoLukas (https://www.openstreetmap.org/changeset/76508518 
) we’ve decided to 
investigate a solution which the rest of the OSM Denmark community agrees on.

There are several potential solutions to this problem. It could be argued that 
‘foot=no’ could be inferred from Danish law on jay-walking and added to these 
sections. It could also be argued that ‘sidewalk=no’ or ‘sidewalk=none’ can be 
added to these sections, and would be accurate to ground truth, and used to 
discourage pedestrian crossings. Finally, it could also be argued that 
‘crossing=no’ could be added to these sections, as it true to what is on the 
ground and the most accurate tag to describe why pedestrians should not be 
using these crossings.

I think this information would be very valuable to include in OSM for both 
individuals with disabilities as well as for pedestrians. What solution to this 
issue would the OSM Denmark community prefer going forward? Our team can go 
back and add whichever tags are decided on in place of the ‘foot=no’ tags 
previously added. Med venlig hilsen,
-Theodore___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Frantz]

5 mai 2020 19:25 "deuzeffe"  a écrit:

> Le 04/05/2020 à 21:44, Violaine_Do a écrit :
>> Donc je suis ok avec la proposition de Deuzeffe/Franck et tout le monde,
>> je ne vois pas ce qui bloque de passer la maternelle sous
>> amenity=school, il n'y a pas d'avis contre, non?
> 
> Bah non, pour une fois qu'il semble qu'il y ait un consensus clair, ça
> traîne, je ne sais pas pourquoi :/

Je viens de modifier les pages du Wiki FR:Tag:amenity=school et 
FR:Tag:amenity=kindergarten, en ajoutant la référence à ce fil dans la partie 
discussion.

-- 
Frantz

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

Re: [Talk-ht] Aidez à résoudre les problèmes routiers en Haïti avec MapRoulette / Help fix road problems in Haiti with MapRoulette

[Andrew Wiseman via Talk-ht]

Bonjou tout moun,
Sa a se Andre soti nan ekip la Apple Kat ankò. Mwen jis mete ajou defi 
MapRoulette yo pou amelyore wout an Ayiti ak done nouvo soti nan OSM: 
https://maproulette.org/browse/projects/39078

Epitou, nou devlope yon style penti pou JOSM fè li pi fasil jwenn ak ranje erè. 
Gen plis enfòmasyon isit la: https://github.com/osmlab/applepaintstyles

Mèsi!

Andrew

//

Hello everyone,
This is Andrew from the Apple Maps team again. I just updated the MapRoulette 
challenges for improving roads in Haiti with new data from OSM: 
https://maproulette.org/browse/projects/39078

Also, we developed a paint style for JOSM to make it easier to find and fix 
errors. There is more information here: 
https://github.com/osmlab/applepaintstyles

Thanks!

Andrew

> On Jan 9, 2020, at 2:33 PM, Andrew Wiseman via Talk-ht 
>  wrote:
> 
> Tradiksyon otomatik anba a / La traduction automatique ci-dessous:
> 
> Hello all,
> 
> This is Andrew from the Apple Maps team. We recently used our Atlas data 
> analysis tool (https://github.com/osmlab/atlas) to look at a few types of 
> potential issues related to roads and routing.
> 
> I've posted the results of those checks on MapRoulette, a tool that lets you 
> go through potential issues one by one and either correct them or indicate 
> they are not a problem. I wanted to let you know they are available in case 
> others wanted to try fixing some of them — I also plan to go through some of 
> them myself. It looks like a few challenges were already finished, thanks!
> 
> In MapRoulette you can either pick a random task to fix or click on a 
> specific one. If you want to do tasks around a certain location, such as 
> somewhere you are familiar with, you can click on one from the map view, and 
> then click Next task: Nearby when you finish it.
> 
> All the challenges are in this project, including things like overlapping 
> roads, roads that aren't connected to other roads, roads that cross without a 
> connection, and similar issues.  https://maproulette.org/browse/projects/39078
> 
> Thanks!
> Andrew
> 
> //
> 
> Bonjour à tous,
> 
> Voici Andrew de l'équipe Apple Maps. Nous avons récemment utilisé notre outil 
> d'analyse de données Atlas (https://github.com/osmlab/atlas) pour examiner 
> quelques types de problèmes potentiels liés aux routes et au routage.
> 
> J'ai publié les résultats de ces contrôles sur MapRoulette, un outil qui vous 
> permet de passer en revue les problèmes potentiels un par un et de les 
> corriger ou d'indiquer qu'ils ne sont pas un problème. Je voulais vous faire 
> savoir qu'ils sont disponibles au cas où d'autres voudraient essayer de 
> réparer certains d'entre eux - je prévois également de les parcourir 
> moi-même. Il semble que quelques défis étaient déjà terminés, merci!
> 
> Dans MapRoulette, vous pouvez choisir une tâche aléatoire à corriger ou 
> cliquer sur une tâche spécifique. Si vous souhaitez effectuer des tâches 
> autour d'un certain emplacement, par exemple dans un endroit que vous 
> connaissez, vous pouvez cliquer sur l'une d'elles dans la vue Carte, puis sur 
> Tâche suivante: à proximité lorsque vous l'avez terminée.
> 
> Tous les défis sont dans ce projet, y compris des choses comme des routes qui 
> se chevauchent, des routes qui ne sont pas connectées à d'autres routes, des 
> routes qui traversent sans connexion et des problèmes similaires. 
> https://maproulette.org/browse/projects/39078
> 
> Merci!
> Andrew
> 
> //
> 
> 
> 
> //
> 
> Bonjou tout,
> 
> Sa a se Andre soti nan Apple Maps ekip la. Nou dènyèman te itilize Atlas done 
> nou an zouti analiz (https://github.com/osmlab/atlas) yo gade nan yon kalite 
> kèk nan pwoblèm potansyèl ki gen rapò ak wout ak routage.
> 
> Mwen te afiche rezilta yo nan sa yo chèk sou MapRoulette, yon zouti ki pèmèt 
> ou ale nan pwoblèm potansyèl youn pa youn ak swa korije yo oswa endike yo pa 
> yon pwoblèm. Mwen te vle fè ou konnen yo disponib nan ka lòt moun te vle 
> eseye repare kèk nan yo - Mwen menm mwen te planifye yo ale nan kèk nan yo 
> tèt mwen. Li sanble tankou yon defi kèk yo te deja fini, mèsi!
> 
> Nan MapRoulette ou ka swa chwazi yon travay o aza ranje oswa klike sou yon 
> yon sèl espesifik. Si ou vle fè travay alantou yon sèten kote, tankou yon 
> kote ou abitye ak, ou ka klike sou youn nan gade nan kat, ak Lè sa a klike 
> sou Next travay: tou pre lè ou fini li.
> 
> Tout defi yo nan pwojè sa a, enkli bagay tankou wout sipèpoze, wout ki pa 
> konekte ak lòt wout, wout ki travèse san yon koneksyon, ak pwoblèm menm jan 
> an. https://maproulette.org/browse/projects/39078
> 
> Mèsi!
> Andrew
> 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> ___
> Talk-ht mailing list
> Talk-ht@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ht
> Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) 
> pour traduire les messages.

Re: [Talk-dk] MapRoulette challenges for Denmark

[Andrew Wiseman via Talk-dk]

Hi all,

I just updated the MapRoulette challenges in Denmark with new OSM data, take a 
look: https://maproulette.org/browse/projects/39285 


Hope it’s helpful! Thanks!

Andrew 

> On Feb 25, 2020, at 10:11 AM, Andrew Wiseman  wrote:
> 
> Hello everyone,
> 
> This is Andrew again from Apple. I wanted to let everyone know that we just 
> updated the MapRoulette challenges related to road network issues in Denmark 
> with new OSM data. 
> 
> You can find the challenges in this MapRoulette project: 
> https://maproulette.org/browse/projects/39285 
>  and they include things like 
> overly sharp road angles, roads that cross but aren’t connected, roads that 
> aren’t connected to anything, overlapping roads, turn restrictions, roads 
> that are close but not connected to others, and other similar issues. I plan 
> to work on some of them myself too.
> 
> If you haven’t used it before, MapRoulette lets you go through potential 
> issues in OSM data one by one and either correct them or indicate they are 
> not a problem. The challenges were created with our Atlas data analysis tool: 
> https://github.com/osmlab/atlas .
> 
> If you aren’t sure what challenge to try, sharp angles or crossing roads are 
> probably the easiest but they should all be fairly straightforward.
> 
> Please let me know if you have any suggestions or feedback. Thank you! 
> 
> Andrew 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Apr 12, 2019, at 10:07 AM, Andrew Wiseman via Talk-dk 
>> mailto:talk-dk@openstreetmap.org>> wrote:
>> 
>> Hi all,
>> 
>> It looks like those are finished, so I created a few more, which are mostly 
>> related to routing or unconnected roads. Here they are if you want to take a 
>> look. I have been working on them too.
>> 
>> Connectivity check means roads that are near each other but not connected, 
>> floating way is way (usually a road) that isn’t connected to anything else, 
>> crossing ways are ways that cross but don't share a node or vertex, and 
>> impossible routing and sink islands are places where you can’t route into or 
>> out of, usually due to one ways, highway types or unconnected roads. (Some 
>> may be pedestrian, which is ok.)
>> 
>> * Denmark Connectivity Check: https://maproulette.org/challenge/4089 
>> 
>> * Denmark Floating Way Check: https://maproulette.org/challenge/4090 
>> 
>> * Denmark Crossing Ways: https://maproulette.org/challenge/4091 
>> 
>> * Denmark Impossible Routing and Sink Islands: 
>> https://maproulette.org/challenge/4088 
>>    
>> 
>> Let me know what you think!
>> 
>> Thanks,
>> 
>> Andrew
>> 
>> Andrew Wiseman |  Maps | andrew_wise...@apple.com 
>> 
>> 
>>> On Dec 20, 2018, at 11:12 AM, Andrew Wiseman >> > wrote:
>>> 
>>> Oops, I pasted the wrong links:
>>> 
>>> https://maproulette.org/mr3/browse/challenges/3425 
>>>  is building-road 
>>> intersections
>>> https://maproulette.org/mr3/browse/challenges/3427 
>>>  is sharp angles.
>>> 
>>> Sorry about that.
>>> 
>>> Andrew
>>> 
>>> Andrew Wiseman |  Maps | andrew_wise...@apple.com 
>>> 
>>> 
>>> 
 On Dec 19, 2018, at 1:21 PM, Andrew Wiseman >>> > wrote:
 
 Hello OSM Denmark,
 
 This is Andrew from Apple’s Maps team. We’ve been working on the a few 
 road issues and buildings for some time 
 (https://github.com/osmlab/appledata/issues/69 
  and 
 https://github.com/osmlab/appledata/issues/118 
 ) and recently used our 
 Atlas data analysis tool (https://github.com/osmlab/atlas 
 ) to look for a few types of potential 
 issues, such as roads with sharp angles and buildings that intersect 
 roads. I posted the results of those checks on MapRoulette, a tool that 
 lets you go through potential issues one by one and either correct them or 
 indicate they are not a problem. I wanted to let you know they are 
 available in case others wanted to try fixing some of them — I also plan 
 to go through some of them myself. 
 
 In MapRoulette you can either pick a random task to fix or click on a 
 specific one. If you want to do tasks around a certain location, such as 
 somewhere you are familiar with, you can click “more options” then “load 
 tasks by proximity.” 
 
 The checks are:
 

Re: [Talk-hr] Kucni brojevi

[Martin Sever]

Pozdrav!

Kod označavanje kućnih brojeva odnosno adresa nisam siguran kako tagirati
pojedine vrijednosti.
Jasno mi je što ide pod "addr:housenumber", "addr:street" i
"addr:postcode", ali nisam siguran kod "addr:place" ili "addr:city". Npr.
kad se ime naselja i poštanskog ureda nisu jednaki.
Evo primjer jednog šoping centra https://www.openstreetmap.org/way/230131183
Ovdje je pod "addr:place" ime naselja u kojem se objekt nalazi, a pod
"addr:city" ime naselja u kojem je odredišni poštanski ured.
Da li je ovakvo označavanje u redu, ili treba nešto promjeniti?

uto, 5. svi 2020. u 14:05 hbogner  napisao je:

> On 02. 05. 2020. 13:55, Janko Mihelić wrote:
> > On Fri, May 1, 2020, 03:37 Matija Nalis <
> mnalis-openstreetmapl...@voyager.hr>
> > wrote:
> >
> >>
> >> Slabo mapiram broj katova uopce (jer ga najcescen niti ne znam, a i
> >> nije mi prioritetan), osim eventualno na terenu sa StreetComplete,
> >> ali onda on to sam odradi na koji god nacin odradi :)
> >>
> >> Kako uopce oznacavas katove ako je jedna gradjevina sa vise katova?
> >> Ili ne mozes oznaciti katove, ili moras rasjeci u dvije gradjevine?
> >> Ili nesto trece?
> >>
> >
> > Označavaš maksimalan broj katova u cijeloj zgradi, a onda ako se baš
> > zainatiš, ucrtaš building:part=yes unutra, i njemu daš pravi broj za taj
> > dio.
>
> Vidiš to nisam znao, za building:part=yes.
>
> čekaj da onda vidite kako izgleda katastar, on nema podatke za visine i
> to ne označava, već samo tolocrte, ali za terase, zgrade, stepenice,
> ..., neznam što sve već ne, ima posebne slojeve...
>
> Mislim da smo malo ispremješali teme, kućne brojeve, mapiranje zgrada i
> kako mapirati zgrade.
>
>
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

Re: [Talk-is] Adjusting flow of Jökulsá á Fjöllum river

[Jóhannes Birgir Jensson]

Thank you for your work!

My previous reply was sent on the run so somewhat brief.

5. maí 2020 kl. 20:12, skrifaði "Hauke Stieler" :

> Hi,
> 
> thanks for the quick reply. As you said, I separated them, so that the
> boundaries haven't moved.
> 
> Hauke
> 
> On 05.05.20 18:55, Jóhannes Birgir Jensson wrote:
> 
>> The boundaries will have to be separated from the river flow.
>> 
>> Digital markers are now above geography in boundary marking.
>> 
>>  Upprunalegt skeyti 
>> Frá: Hauke Stieler 
>> Dagsetning: 5.5.2020 16:35 (GMT+00:00)
>> Til: OpenStreetMap in Iceland 
>> Efni: [Talk-is] Adjusting flow of Jökulsá á Fjöllum river
>> 
>> Hi all,
>> 
>> I would like to edit the flow of the Jökulsá á Fjöllum river [0] near
>> the Holuhraun lava field [1] as the lava field is quite new and the
>> river flow outdated.
>> 
>> But: The river is also within several administration boundary relations.
>> When I change the river flow, I also change the course of the boundaries.
>> 
>> Is that even a problem or is it ok to edit the river and therefore also
>> change the boundaries?
>> 
>> In case this is a problem and the boundaries should stay where they are,
>> I would create a new way for the river and tag the existing line with
>> "boundary=administrative".
>> 
>> What do you think about this, I would like to hear some feedback :)
>> 
>> Hauke
>> 
>> [0] https://www.openstreetmap.org/way/741064529
>> [1] https://www.openstreetmap.org/relation/11071456
>> 
>> ___
>> Talk-is mailing list
>> Talk-is@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-is
> 
> ___
> Talk-is mailing list
> Talk-is@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-is

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

Re: [talk-cz] Neexistující ulice v obci Tři Dvory (okres Kolín)

[Miroslav Suchý]

Dne 05. 05. 20 v 22:33 Jan Macura napsal(a):
ale v reálu, aspoň některé, zřejmě existují: 
https://mapy.cz/turisticka?x=15.2534002=50.0320444=17=1=67474589=1.426=1.257=0.168

nebo existovaly...



Jj, "lomená" i "nová" na panoramě je taky vidět. Takže za OK. Maximalně 
bych napsal starostovi proč to neposlal na RUIAN :)


M.

--
,,,
   (o o)
  =oOO==(_)==OOo===
 )  mailto:miros...@suchy.cz  tel:+420-603-775737
(   One picture is worth 128K words.
 )Oooo.
 .oooO   (   )
 (   )) /
  \ ((_/
   \_)


___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-br] Desafios MapRoulette no Brasil

[Andrew Wiseman por (Talk-br)]

Olá a todos,

Este é Andrew da equipe do Apple Maps novamente. Acabei de atualizar os 
desafios do MapRoulette para melhorar as estradas no Brasil com novos dados do 
OSM: https://maproulette.org/browse/projects/38970 
 . Diz-me o que pensas!

Obrigado,

Andrew

> On Jan 3, 2020, at 9:39 AM, Andrew Wiseman por (Talk-br) 
>  wrote:
> 
> Olá OSM Brasil. 
> 
> Coloquei todos os desafios ativos do MapRoulette que criei para o Brasil 
> neste projeto, para que você possa acessá-los facilmente: Brasil - todos os 
> desafios ativos: https://maproulette.org/browse/projects/38970 
>  
> 
> Eles são principalmente redes rodoviárias problemas, além de questões 
> costeiras e cidades desaparecidas de Pascal Neis.
> 
> Obrigado,
> 
> Andrew
> 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Sep 3, 2019, at 2:49 PM, Andrew Wiseman > > wrote:
>> 
>> Olá OSM Brasil,
>> 
>> Publiquei mais desafios do MapRoulette, que tratam de estradas e rotas. 
>> Alguns deles são atualizações dos desafios que eu postei antes.
>> 
>> Áreas de roteamento impossíveis: 
>> https://maproulette.org/browse/challenges/8655 
>>  
>> Ângulos agudos da estrada: https://maproulette.org/browse/challenges/8652 
>>  
>> Restrições de turno inválidas: 
>> https://maproulette.org/browse/challenges/8660 
>>  
>> Estradas desconectadas ou flutuantes: 
>> https://maproulette.org/browse/challenges/8649 
>>  
>> Cruzando estradas: https://maproulette.org/browse/challenges/8659 
>>  
>> Verificação de conectividade: https://maproulette.org/browse/challenges/8657 
>>  
>> Verificação do link da estrada: 
>> https://maproulette.org/browse/challenges/8654 
>>  
>> Rotatórias malformadas: https://maproulette.org/browse/challenges/8650 
>>  
>> 
>> Entre em contato se tiver alguma dúvida ou comentário.
>> 
>> Obrigado,
>> 
>> Andrew
>> 
>> 
>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
>> 
>> 
>>> On Jul 29, 2019, at 10:34 AM, Andrew Wiseman por (Talk-br) 
>>> mailto:talk-br@openstreetmap.org>> wrote:
>>> 
>>> Olá OSM Brasil
>>> 
>>> Eu publiquei um novo desafio MapRoulette, que analisa linhas costeiras que 
>>> podem ser muito longas ou com ângulos agudos. Estes podem ter sido 
>>> digitalizados mal ou com imagens antigas. Há mais detalhes e instruções 
>>> sobre o desafio: https://maproulette.org/challenge/8267 
>>> 
>>> 
>>> Deixe-me saber se você tiver alguma dúvida or feedback.
>>> 
>>> Obrigado,
>>> 
>>> Andrew
>>> 
>>> 
>>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | 
>>> andrew_wise...@apple.com 
>>> 
 On Feb 26, 2019, at 11:31 AM, Andrew Wiseman por (Talk-br) 
 mailto:talk-br@openstreetmap.org>> wrote:
 
 Olá OSM Brasil
  
 Eu sou Andrew Wiseman do Maps time da Apple. Recentemente, usamos nossa 
 ferramenta de análise de dados Atlas (https://github.com/osmlab/atlas 
 ) para examinar alguns tipos de problemas 
 possíveis, como intercessão de construções com estradas, vias de acesso à 
 rodovias que não têm as classificações corretas, formas sobrepostas 
 (geralmente estradas duplicadas) e ângulos da estrada que são muito 
 agudos. Eu postei os resultados dessas verificações no MapRoulette, uma 
 ferramenta que permite que você passe por possíveis problemas um por um e 
 os corrija ou indique que eles não são um problema. Eu queria que você 
 soubesse que eles estão disponíveis no caso de outros quererem tentar 
 consertar alguns deles - eu também pretendo passar por alguns deles.
  
 No MapRoulette você pode escolher uma tarefa aleatória para corrigir ou 
 clicar em uma específica. Se você quiser executar tarefas em um 
 determinado local, como em algum lugar com o qual esteja familiarizado, 
 clique em "mais opções" e em "carregar tarefas por proximidade".
  
 As verificações são:
  
 - Ângulos agudos: https://maproulette.org/mr3/challenge 
 /3666
 - Vias de acesso à rodovias: https://maproulette.org/mr3/challenge 
 /3667
 - Interseções construção-estrada: https://maproulette.org/mr3/challenge 
 /3669
 - Formas sobrepostas: https://maproulette.org/mr3/challenge 

Re: [talk-cz] Neexistující ulice v obci Tři Dvory (okres Kolín)

[Jan Macura]

Ahoj,

zajímavý, v adresách ty ulice taky vedený nejsou:
https://www.openstreetmap.org/node/2860466826
ale v reálu, aspoň některé, zřejmě existují:
https://mapy.cz/turisticka?x=15.2534002=50.0320444=17=1=67474589=1.426=1.257=0.168
nebo existovaly...

Do OSM ty ulice někdo přidal před 8 lety a od tý doby na to nikdo nesáhnul.
Zdroj dat uveden není, ale můžeme se zeptat přímo autora
, odkud čerpal. Je stále
OSM-aktivní.

H.

On Tue, 5 May 2020 at 22:17, Jiří Sedláček  wrote:

> Ahoj, dobrý den,
> kolega Wikipedista narazil na to, že v OSM jsou vyplněny názvy ulic v obci
> Tři Dvory (okres Kolín) - https://www.openstreetmap.org/way/30669855
>
> Co s tím? Jsou to nějaký místní názvy? V RUIANu nic, v mapy.cz taky ne.
>
> Dík, Jirka.
>
> --
> S pozdravem,
> Jirka Sedláček
> ---
> jirisedla...@gmail.com
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk] Bridge area construction

[Jack Armstrong]

I assume the best way to map a large bridge area that's under construction would be with the minimum following tags? I'm not asking about the ways associated with/on the bridge.man_made=constructionconstruction=bridgelayer=1

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

Re: [Talk-ar] Retos de MapRoulette en Argentina

[Andrew Wiseman via Talk-ar]

Hola a todos,

Los retos de MapRoulette de la red vial ahora se actualizan con nuevos datos de 
OSM: https://maproulette.org/browse/projects/39170 
. Incluyen ángulos agudos, 
problemas de conectividad, y otros.

Avíseme si tiene alguna sugerencia o comentario. ¡Gracias!

Andrew

Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Mar 10, 2020, at 10:58 AM, Andrew Wiseman via Talk-ar 
>  wrote:
> 
> Hola,
> 
> Las retos de ángulos agudos, cruces y carreteras superpuestas ya han 
> terminado, ¡muchas gracias a quienes participaron! Si alguien quería seguir 
> mapeando, todavía quedan algunos otros como la conectividad (caminos que 
> están cerca de otros pero no conectados), caminos flotantes y problemas de 
> restricción de giro. Gracias.
> 
> https://maproulette.org/browse/projects/39170 
> 
> 
> Andrew 
> 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 
> 
>> On Feb 26, 2020, at 12:08 PM, Andrew Wiseman via Talk-ar 
>> mailto:talk-ar@openstreetmap.org>> wrote:
>> 
>> Hola a todos,
>> 
>> Este es Andrew de Apple. Acabamos de actualizar los desafíos de la red de 
>> carreteras MapRoulette en Argentina con nuevos datos de OSM.
>> 
>> Puede encontrar los retos en este proyecto de MapRoulette: 
>> https://maproulette.org/browse/projects/39170 
>> , e incluyen cosas como 
>> ángulos de carretera demasiado afilados, carreteras que se cruzan pero no 
>> están conectadas, carreteras que no están conectadas a nada, carreteras 
>> superpuestas, restricciones de giro, carreteras cercanas pero no conectadas 
>> a otras, y otros problemas similares. Planeo trabajar en algunos de ellos 
>> también.
>> 
>> Si no lo ha usado antes, MapRoulette le permite analizar problemas 
>> potenciales en los datos de OSM uno por uno y corregirlos o indicar que no 
>> son un problema. Los desafíos se crearon con nuestra herramienta de análisis 
>> de datos Atlas: https://github.com/osmlab/atlas 
>> .
>> 
>> Si no está seguro de qué desafío intentar, los ángulos agudos o el cruce de 
>> carreteras son probablemente los más fáciles, pero todos deberían ser 
>> bastante sencillos.
>> Avíseme si tiene alguna sugerencia o comentario. ¡Gracias!
>> 
>> Andrew 
>> 
>> 
>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
>> 
>> 
>>> On Oct 24, 2019, at 2:11 PM, Andrew Wiseman >> > wrote:
>>> 
>>> Hola,
>>> 
>>> Recientemente actualizamos los desafíos de MapRoulette con datos nuevos y 
>>> agregamos algunos más desafíos. Aquí hay nuevos enlaces a ellos. Por favor 
>>> hazme saber si tienes alguna pregunta.
>>> 
>>> Argentina caminos y vías cruzados: https://maproulette.org/challenge/9460 
>>> 
>>> Argentina caminos y vías flotantes y desconectadas: 
>>> https://maproulette.org/challenge/9461 
>>> 
>>> Argentina restricciones de giro no válidas: 
>>> https://maproulette.org/challenge/9466 
>>> 
>>> Argentina rotondas malformadas: https://maproulette.org/challenge/9464 
>>> 
>>> Argentina comprobación de conectividad vial: 
>>> https://maproulette.org/challenge/9459 
>>> 
>>> Argentina líneas superpuestas: https://maproulette.org/challenge/9457 
>>> 
>>> Argentina enrutamiento imposible: https://maproulette.org/challenge/9458 
>>> 
>>> Saludos,
>>> 
>>> Andrew
>>> 
>>> 
>>> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | 
>>> andrew_wise...@apple.com 
>>> 
 On Jul 23, 2019, at 11:47 AM, Andrew Wiseman via Talk-ar 
 mailto:talk-ar@openstreetmap.org>> wrote:
 
 Hola,
 
 He publicado otro reto de MapRoulette, para las líneas de costa en 
 Argentina. Esta reto busca partes de la costa que están muy largas o con 
 esquinas agudos, que pueden deberse a digitalización inexacta o a muy 
 pocos vértices o esquinas como sea necesario. Hay más detalles y 
 instrucciones en el reto: https://maproulette.org/challenge/8252 
 
 
 Por favor, hágamelo saber si tiene alguna pregunta o comentario. 
 
 Saludos,
 
 Andrew
 
 Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | 
 andrew_wise...@apple.com 
 
> On Dec 12, 2018, at 6:46 PM, Andrew Wiseman  > wrote:
> 
> Hola OSM Argentina,
> 
> Esto es Andrew del equipo de mapas de Apple. Llevamos 

[talk-cz] Neexistující ulice v obci Tři Dvory (okres Kolín)

[Jiří Sedláček]

Ahoj, dobrý den,
kolega Wikipedista narazil na to, že v OSM jsou vyplněny názvy ulic v obci
Tři Dvory (okres Kolín) - https://www.openstreetmap.org/way/30669855

Co s tím? Jsou to nějaký místní názvy? V RUIANu nic, v mapy.cz taky ne.

Dík, Jirka.

-- 
S pozdravem,
Jirka Sedláček
---
jirisedla...@gmail.com
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Workflow pour opendata

[Marc M.]

je n'ai pas retrouvé la discussion, mais voici 2 versions de l'idée

assistant de configuration
https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2019/Project_ideas#Osmose-QA

éditeur pour faciliter des modifs du code
https://github.com/osm-fr/osmose-backend/issues/859

fred me renseigne aussi
https://framagit.org/PanierAvide/opendata4osmose/blob/master/doc/Analyser_spec.md

Le 05.05.20 à 15:33, Nicolas Bétheuil a écrit :
> Bah en fait c'est un peu l'idée même si le côté "sans code" mof : il va
> bien falloir convertir le jeu de données en tag pour faire rentrer les
> ronds dans les carrés. Il va bien falloir faire un peu de code, mais
> dans mon option il n'y a rien d'imposé.
> Pour m'inspirer, elle était où cette discussion ?
> 
> Le mar. 5 mai 2020 à 14:59, Marc M.  > a écrit :
> 
> Bonjour,
> 
> Le 05.05.20 à 12:24, Magalie Dartus a écrit :
> > je n'ai toujours pas acquis la compétence "charger le fichier
> > open data dans osmose".
> 
> le plus simple pour avancer me semble être :
> - publier le fichier quelque part
> - créer un ticket https://github.com/osm-fr/osmose-backend/issues
> de là, ceux "qui savent" pourront sans doute mieux guider
> sur comment faire l'analyse.
> 
> Il y avait aussi eu une discussion pour faire un système plus simple,
> sans code, genre on liste le fichier, les tags osm, et "voilà".
> mais ce n'est pas encore une réalité.
> 
> Cordialement,
> Marc
> 
> ___
> 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] attribut mono-utilisateur

[Yves P.]

> Ça va faire plaisir à Yves, et en plus une clé en français !
> 
Au moins, je comprends en français :D

> https://overpass-turbo.eu/s/TFi 
> J'ai essayé d'ajouter :
> 
> (user:"Bibi6")
> 
> mais là ça ne trouve plus rien. Un effet de bord de la modification pour la 
> RGPD ou le problème est entre le clavier et l'écran ? Je n'ai pas trouvé de 
> ticket ouvert sur
> 
Je ne suis pas familier des recherches par métadonnées, mais ceci fonctionne : 
https://overpass-turbo.eu/s/TFr
Le problème est peut-être entre la souris et la chaise de bureau ? :D

> Donc à la question de Garen_kreiz, tu peux ne pas discuter et créer une clé 
> de nom aberrant pour toi tout seul et créer une entrée grande_circulation 
>  dans le 
> wiki...
> 
L'idée n'est peut-être pas mauvaise, mais il existe probablement un tag pour ça 
chez les britanniques ?
Nom "aberrant" oui.
Le tag approprié aurait eu sa place plutôt sur les relations ;)

Pour l'entrée dans le wiki, il a au moins le mérite de documenter son boulot :)
> J'hésite franchement à faire une édition de masse avec "attribut mal nommé, 
> non approuvé"
> 
Il y a peut-être un intérêt, et un projet qui utilise ce tag. Pourquoi pas une 
édition de masse pour renommer le tag et le mettre sur les relations…
… après discussion ;)

Il y en a 5008. Ça sent l'import ?
> et discuter avec le contributeur…
> 
> Je n'ai pas trouvé l'équivalent (une clé traffic) mais on a la hiérarchie du 
> réseau avec primary, secondary..., alors ?
> 
Ce serait donc redondant avec primary ET secondary ??

Le décret 

 couvre toute la France alors que ce tag est circonscrit au Nord et au 
Pas-de-Calais.

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

Re: [Talk-it] Prova di "nuova grafica" per su.openstreetmap.it

[Damjan Gerl]

  
  
Grazie a tutti per il super lavoro!
  
  Aggiungo solo una nota, che nella pagina sotto viene riportato un
  testo (non so se voluto) che normalmente riporta la categoria o
  altro testo.
  
  Ciao
  Damjan
  
  
  Francesco Ansanelli je 5.5.2020 ob 18:01 napisal:


  
  
Ringrazio Nap Osm per il contributo e la pazienza
  nel risolvere tutte le mie osservazioni! 
  Ho fatto merge delle sue modifiche e ora la nuova veste
grafica è anche rilasciata in produzione.
  
  
  Buona serata
  Francesco



  Il giorno lun 4 mag 2020
alle ore 20:34 Francesco Ansanelli 
ha scritto:
  
  
Ciao,
  
  
  ho fatto una veloce review delle modifiche... Aspetto
che naposm sistemi e poi penso si possa mettere in
produzione.
  
  
  Buona serata
  Francesco



  Il giorno lun 4 mag 2020
alle ore 19:28 Alessandro Sarretta 
ha scritto:
  
  

  On 04/05/20 14:11, Cascafico Giovanni wrote:
  
  A me pare OK: possiamo
metterla in produzione sull'url su.openstreetmap.it?
  Per me sì! :-)
  Grazie,
  Ale
  

  

  

  


  


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

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Rachele Amerini]

Ti auguro buon lavoro! :)
In bocca al lupo!

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

Re: [Talk-it] [Import] civici Bergamo

[Cascafico Giovanni]

Il giorno mar 5 mag 2020 alle ore 11:36 Cascafico Giovanni <
cascaf...@gmail.com> ha scritto:

> Per contattarlo non c'è problema, ha risposto via messaggistica osm.
> Ha detto che aggiusta, non sul revert, ma riferendosi al problema che un
> migliaio di housenumber era andato nel tag housename.
>

Abbiamo dato una passata e adesso tutti gli addr:housename importati sono
su addr:street.
http://overpass-turbo.eu/s/TFp
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[Christian Rogel]

> Le 5 mai 2020 à 19:25, deuzeffe  a écrit :
> 
> 
>>> Et la garderie qui peut se trouver dans le même area :
>>> 
>>> amenity=kindergarten ??? 
>> Rien contre...
> 
> Euh... Aucune réalité terrain en France :/ Ou alors on efface le passé et on 
> change le sens usuel de l'expression "jardin d'enfants" ? Mouais.

On peut, soit se référer à la traduction, soit tenter une essentialisation, 
kindergarten est l’attribut OSM générique pour l’enseignement préscolaire.

C’est vrai que la grande section des maternelles a été inscrite dans un « cycle 
1 », mais, est-ce que ces décisions ministérielles doivent impacter OSL ?

A contrario, les EM ressortissent aux établissements scolaires, si on se place 
sur un 3ème point de vue, celui des gestionnaires municipaux.

Ou bien, on suit le ministère et les municipaux et on diverge à l’international
ou
on ajoute school au tag franco-français

ou…?

Qui peut produitre des éléments comparatifs, comme un système proche de la 
France, mais, que les locaux continueraient de tagger « kindergarten » ?

Ou, peiut-être que les crèches françaises  sont des kindergarten. Mais, alors 
comment sont taggées les crèches à l’international ?

Une traduction ne suffit pas épuiser les faits concrets.


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

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Mike Baggaley via Talk-GB]

>Highway=no seems acceptable to me where a path is permanently physically
>blocked by a building or such-like. We're not serving anyone by directing
>people into wals. I do, however, disagree with its use to tag definitive
>rights of way which are useable but which merely deviate from the route a
>mapper mapped on the ground. Eg. I don't think a highway=no tag should be
>added to a cross field definitive footpath just because a path round the
>field has been mapped.

In the case where a path has been permanently blocked, I would suggest 
disused:highway=footway/bridleway, abandonded:highway=footway  or 
removed:highway=footway, depending on whether the path is still visible and 
whether the blockage would be relatively easy or difficult to remove. This 
seems to me to be much better than highway=no.

Regards,
Mike


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

[OSM-talk-fr] attribut mono-utilisateur

[osm . sanspourriel]

Ça va faire plaisir à Yves, et en plus une clé en français !

https://overpass-turbo.eu/s/TFi

J'ai essayé d'ajouter :

(user:"Bibi6")

mais là ça ne trouve plus rien. Un effet de bord de la modification pour
la RGPD ou le problème est entre le clavier et l'écran ? Je n'ai pas
trouvé de ticket ouvert sur https://github.com/tyrasd/overpass-turbo.

Donc à la question de Garen_kreiz, tu peux ne pas discuter et créer une
clé de nom aberrant pour toi tout seul et créer une entrée
grande_circulation
 dans le
wiki...

J'hésite franchement à faire une édition de masse avec "attribut mal
nommé, non approuvé" et discuter avec le contributeur... Mais comme j'ai
la flemme pour le 2, si quelqu'un•e veut s'en charger...

Je n'ai pas trouvé l'équivalent (une clé traffic) mais on a la
hiérarchie du réseau avec primary, secondary..., alors ?

Jean-Yvon

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

[OSM-talk-fr] Schémas de nommages locaux et cas de ref:FR:RTE_nom

[François Lacombe]

Bonjour à tous,

Nous en avons déjà discuté ici, les schémas de références et nommage locaux
est un sujet qui me tient à cœur.

Il existe un cas un peu particulier avec RTE qui exploite le réseau de
transport d'électricité puisque 2 clés sont disponibles avec des cas
d'usage différents : ref:FR:RTE (le "codnat") et ref:FR:RTE_nom (le nommage
officiel en plus du codnat).
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:RTE_nom

Récemment je me suis aperçu qu'un contributeur avait eu la bonne idée
d'utiliser name:FR:RTE.
Cela me semble être une bonne idée selon les points suivants :
* ref:FR:RTE_nom fait passer un nom comme une ref, c'est plutôt un nom avec
des règles particulières, en plus d'une ref.
* ref:FR:RTE_nom n'est pas affiché sur le terrain il me semble et les
valeurs répondent à des règles précises
* name:FR:RTE permet de recevoir ces règles particulières et autorise
l'emploi d'une valeur en minuscules pour name=*, notamment utilisé pour le
rendu.

Je réfléchi pour remplacer ref:FR:RTE_nom par name:FR:RTE
Quels pourraient être les arguments contre ?

Merci par avance, bonne soirée

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

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Marcello]

Il 05/05/20 14:53, Anisa Kuci ha scritto:


Ciao a tutti,


sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia 
Italia.



Benvenuta Anisa, e buon lavoro!

--
Ciao
Marcello Arcangeli

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

Re: [Talk-us] Underground railways, indoor mapping, and overlapping features

[Michael Reichert]

Hi Clay,

Am 04/05/2020 um 20.15 schrieb Clay Smalley:
> We've come up with some potential solutions, each of which seems to have
> its own drawbacks:
> 
> 1. Sharing nodes between levels, as in the Simple Indoor Tagging schema.
> This is the approach IsStatenIsland has taken, with a working example at
> the West 4th Street–Washington Square station [2].
> 2. Duplicate nodes with identical positions.
> 3. Duplicate nodes, but positions scooched off-center a negligible
> distance. This is how I mapped out Grand Central Terminal [3], with the
> lower level mapped a foot or so away from where it should be.
> 
> Personally, I'm leaning more towards #2. My qualm with #1 is that it adds
> intersections to the two overlapping levels of railways, which I find
> misleading. And with #3 I worry that I'm mapping for the renderer.

I recommend option 3 and I strongly recommend not to use option 1.

Examples of option 3:
Dusseldorf, Germany between Steinstraße/Königsallee and Oststraße
https://www.openrailwaymap.org/?lang=null=51.2230429467944=6.78480327129364=17=standard

Duisburg, Germany: Hauptbahnhof and König-Heinrich-Platz
https://www.openrailwaymap.org/?lang=null=51.43331030240311=6.773768663406372=16=standard

Note: The operators of the tram and subway systems in Germany often uses
OSM data for routing in cases where safety does not matter.

Using the same nodes (like mapping to adjacent landuse polygons) breaks
routing because routing engines would allow trains to switch between the
levels. Using duplicated nodes at the same location is likely to trigger
quality assurance services and therefore mappers trying to "repair" it
by merging them. Using two identical geometries in straight sections
with nodes at different locations, will likely provoke the same as
duplicated nodes.

Regarding option 2: GraphHopper assembles its routing graph by relying
on the node IDs in OSM. It would not suffer from using this option but I
doubt that it is safe for the future. If OSM adopts to drop its 64 bit
node IDs in favour of the location (32 bit latitude + 32 bit longitude),
such cases will cause difficulties.

Best regards

Michael
(maintainer of a railway map style and routing engine)



signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[deuzeffe]

Le 04/05/2020 à 21:44, Violaine_Do a écrit :

Bonjour à tous

Merci pour la discussion

D'aprèshttps://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dkindergarten  
, les écoles pour les moins de 5 ans sont à classer en kindergarten.
Je ne me baserais pas la dessus, peut être revenir à la version anglaise 
qui l'associe à du préscolaire? La maternelle rentre dans la case scolaire.


Donc je suis ok avec la proposition de Deuzeffe/Franck et tout le monde, 
je ne vois pas ce qui bloque de passer la maternelle sous 
amenity=school, il n'y a pas d'avis contre, non?


Bah non, pour une fois qu'il semble qu'il y ait un consensus clair, ça 
traîne, je ne sais pas pourquoi :/



Et la garderie qui peut se trouver dans le même area :

amenity=kindergarten ??? 

Rien contre...


Euh... Aucune réalité terrain en France :/ Ou alors on efface le passé 
et on change le sens usuel de l'expression "jardin d'enfants" ? Mouais.


Et pour les crèches? ...  Ma position serait d'utiliser 
amenity=childcare (bon je sais le tag n'est pas validé mais utilisé).


Yep, moins que validé, même : 
https://wiki.openstreetmap.org/wiki/Proposed_features/childcare :(


Propal :
amenity=social_facility + social_facility=day_care + 
social_facility:for=child ?


--
deuzeffe - on va y arriver

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

Re: [Talk-is] Adjusting flow of Jökulsá á Fjöllum river

[Jóhannes Birgir Jensson]

The boundaries will have to be separated from the river flow.Digital markers 
are now above geography in boundary marking.
 Upprunalegt skeyti Frá: Hauke Stieler  
Dagsetning: 5.5.2020  16:35  (GMT+00:00) Til: OpenStreetMap in Iceland 
 Efni: [Talk-is] Adjusting flow of Jökulsá á Fjöllum 
river Hi all,I would like to edit the flow of the Jökulsá á Fjöllum river [0] 
nearthe Holuhraun lava field [1] as the lava field is quite new and theriver 
flow outdated.But: The river is also within several administration boundary 
relations.When I change the river flow, I also change the course of the 
boundaries.Is that even a problem or is it ok to edit the river and therefore 
alsochange the boundaries?In case this is a problem and the boundaries should 
stay where they are,I would create a new way for the river and tag the existing 
line with"boundary=administrative".What do you think about this, I would like 
to hear some feedback :)Hauke[0] https://www.openstreetmap.org/way/741064529[1] 
https://www.openstreetmap.org/relation/11071456___
Talk-is mailing list
Talk-is@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-is

Re: [OSM-talk-fr] Ecole maternelle / primaire : amenity=school ou kindergarten

[deuzeffe]

Le 05/05/2020 à 09:14, Vincent Bergeot a écrit :

 Et outre la traduction littérale en 
"jardin d'enfants" qui a mon avis ne semble pas évidente, il ne 
faudrait pas projeter non plus sur ce terme (jardin d'enfants) un 
regard genre "c'est moins bien que ce que l'on fait à l'école et

donc il faut que cela soit school", cela laisse entendre que l'école
c'est "plus mieux" que le jardin d'enfants. Je ne pense pas que cela
soit une échelle de valeurs mais des objectifs différents, tout
aussi important les uns que les autres, dans certains cas se référant
à un programme national, décliné par les enseignants et dans les
autres à des projets pédagogiques fréquemment liés à des mouvements
nationaux associatifs, pédagogiques et éducatifs. 



En France, le terme "jardin d'enfants" était utilisé au siècle dernier
pour désigner des structures accueillant des enfants qui avaient l'âge
de fréquenter l'école maternelle (mais qui pour différentes raisons, n'y
allaient pas), avant l'âge minimum (ancien) de l'instruction
obligatoire donc. Puis les écoles maternelles ont fleuri sur le
territoire, puis l'âge de début de l'instruction obligatoire est passé
de 6 à 3 ans au cours de ce siècle. Ergo, il me semble que le terme
"jardin d'enfants" ne recouvre plus aucune réalité en France.


--
deuzeffe - reste les crèches, halte-garderies & so on

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

Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

[Florimond Berthoux]

Je ne comprend pas, il ne t'a pas insulté il veut juste pas faire ce que tu
veux.
C'est des bénévoles ils sont libre de faire ou de ne pas faire, ils sont
libre d'argumenter ou non.
Fais une PR si tu veux.
Et rien n'empêche de créer un nouveau frontend plus mieux à osm.org si
c'est méga bloquant.

Après sur le fond, a priori je suis pour qu'une structure OSM embauche et
développe un meilleur service pour attirer un public plus large.


Le mar. 5 mai 2020 à 14:25, Yves P.  a écrit :

> Bonjour,
>
> J'ai oublié de copier le passage qui fait le lien entre mon message et
> celui de Jean-Guilhem Cailton :
>
>
> https://wiki.openstreetmap.org/wiki/User:Jgc/TraductionJournalConsultationsApm-wa#.28Quatri.C3.A8me_place_ex_aequo.29_Diversit.C3.A9.2Finclusion
>
> De nombreuses personnes interrogées se sont plaintes des questions de
> "pilotage" ou de "domination" des intérêts particuliers au détriment des
> intérêts plus larges de la communauté des OSM. Comme l'a dit l'un d'entre
> eux, "Si vous laissez les grandes gueules diriger la stratégie, rien ne se
> passera". Un autre l'a formulé différemment : "L'utilisation du projet est
> mise en péril par quelques voix fortes".
>
>
> En espérant que ça vous aidera à comprendre mieux mon propos :)
>
> Le 04.05.20 à 20:45, Florimond Berthoux a écrit :
>
> Perso les gens qui me demande quelque chose en disant aussitôt merci
> ça a le don de particulièrement m'agacer.
> Pourquoi ? Parce que c'est retirer la liberté de faire ou de ne pas
> faire à celui qui reçoit la demande.
>
>
> je pense que c'est très variable selon la personne qui l'écrit
> ou le recoit. pour d'autre, c'est une expression de gratitude
> envers le gars qui va passer du temps à cela.
>
> +1
>
> Un autre facteur, je n'ai pas fais mes études à Oxford et ne maitrise donc
> pas les subtilités de la langue anglaise à l'écrit ;)
>
> il y a plus qu'une personne :)
>
> Tom ou Allan ?
>
> En tout cas, que les choix sur le devenir du site web OSM ne repose que
> sur les épaules d'une (ou deux) personne(s) est un problème :/
> Si en plus ce sont des "grandes gueules" ça ne permettra encore moins
> d'avancer :(
>
> TomH *parait* souvent très sec (moi aussi m'a-t-on fait remarquer).
> c'est toujours difficile de suposer l'intention de l'autre.
> Quand je réponds d'apparence "sec", c'est parfois sinplement
> parce que je vois pas l'utilité de répondre à un message utilitaire
> en y mettant 2 tonnes d'emballage. genre si on demande le tag pour tel
> truc, je répond ce qui me parait être le tag pour tel truc. si on
> demande si c'est utile, je répond mon avis sur l'utilité.
> ca dit pas que j'ai la science infuse ou que la discussion est
> refusée, c'est juste un avis :) mon avis :)
>
>
> Le 04.05.20 à 20:45, Florimond Berthoux a écrit :
>
> Et justement il dit qu'il est contre, normal qu'il t’envoie bouler.
>
>
> Le problème n'est pas de donner son avis, le problème est la bonne fois.
>
> Comme l'a fait remarquer eehpcm (issuecomment-623478783
> ),
> Tom utilise des arguments fallacieux (Slippery-slope arguments
> ).
>
> Cette discussion n'est que le sommet de l'iceberg…
>
>
>
> https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-623479719
>
>
> perso je lis la première ligne et je m'arrête. une ref qui n'est avec
> ref, c'est une erreur de tag même si c'est la pratique courante pour
> cette ref. idem avec CLC:id par ex
> personne
>
> On peut discuter de la forme originale de cette clé (il serait en effet
> plus logique que ce soit *ref:openplaques*).
>
> Mais la question n'est pas là. Cette clé existe, elle répond au besoin des
> "historiens" et autre "amateurs" de patrimoine.
>
> Et au-delà de cette clé, il en existe d'autres qui pourraient bénéficier
> d'un lien.
>
> de plus les 2 messages précédents explicants les 2 raisons ne semblent
> pas prise en considération, donc fatalement le gars répond pas très
> positivement si on lui répond sans tenir compte de ce qu'il répond.
>
> J'ai relu la "discussion", Tom n'argumente pas : c'est son avis, son
> "jugement", point barre.
>
> Si il est seul à décider de ce qui est bien ou mal pour OSM me dérange
> vraiment.
> Les projets informatiques ont souvent besoin de "dictateurs"
> bienveillants. Ici je ne voit pas la bienveillance :(
>
>  même si le code était écrit, je serrais tenté par passer
> mon temps à lire un autre ticket plutôt qu'encourager cette clef :)
>
> Encore une fois, est-ce a une ou 2 personnes de décider des clés à
> encourager ou pas ?
>
>
> https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-623479719
>
> If somebody else wants to offer a PR to do it then that can be considered
> when it happens. Until then this issue is just so much hot air.
>
>
> Ecrire une PR dans un gros projet comme celui-ci nécessite beaucoup de
> prérequis.
> Maitriser l'anglais est utile (cf ma 

[Talk-is] Adjusting flow of Jökulsá á Fjöllum river

[Hauke Stieler]

Hi all,

I would like to edit the flow of the Jökulsá á Fjöllum river [0] near
the Holuhraun lava field [1] as the lava field is quite new and the
river flow outdated.

But: The river is also within several administration boundary relations.
When I change the river flow, I also change the course of the boundaries.

Is that even a problem or is it ok to edit the river and therefore also
change the boundaries?

In case this is a problem and the boundaries should stay where they are,
I would create a new way for the river and tag the existing line with
"boundary=administrative".

What do you think about this, I would like to hear some feedback :)

Hauke

[0] https://www.openstreetmap.org/way/741064529
[1] https://www.openstreetmap.org/relation/11071456



signature.asc
Description: OpenPGP digital signature
___
Talk-is mailing list
Talk-is@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-is

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Robert Whittaker (OSM lists)]

On Tue, 5 May 2020 at 11:54, Adam Snape  wrote:
> I'd consider this particular proposed use of highway=no to mean "there is a 
> public highway here but there's no visible path on the ground" to be a 
> somewhat country-specific and counter-intuitive tagging practice. It's 
> certainly being suggested here as a solution to a country-specific issue 
> regarding the mapping of England and Wales' rights of way network.

That's not precisely how I've been using highway=no or would advocate
others to use it. I would only use highway=no in the case where there
is a legal right of way that either is not or cannot be used on the
ground. The "is not" might be a case where there is a regularly
ploughed or cropped field and the cross-field path is never
reinstated, so everyone always walks around the edge of the field
instead. (Though if the cross-field line is usually passable, I'd
possibly still use highway=path there.) The "cannot" might be a case
where there's an impassible ditch or a house blocking the legal line
(where higwhay=path would certainly not be appropriate).

I'd be quite happy adding a highway=footway to e.g. a cross-field path
even if there's no physical sign of it on the ground, as long as I'm
confident it will be walked by users of the public footpath.

In terms of how highway=no should be interpreted by data users, I
would say highway=no means no more and no less than "there is not a
(physical) highway here". I think the tagging is needed on objects
(e.g. ways with designation=public_footpath) where you'd normally
expect to find a highway=* tag, in order to distinguish this case from
the case where it hasn't been established whether or what type of
highway is present. (Some people will add rights of way lines to the
map, and omit the highway tag until they've done a ground survey to
determine what is there on the ground.)

The main point I think, is that if you've tagged the definitive line
of a Right of Way, and there's no suitable highway=* type for it, it's
good to add highway=no, to confirm that's the case. This distinguishes
that case from the case where the correct highway=* type still needs
to be determined and added.

Robert.

-- 
Robert Whittaker

-- 
Robert Whittaker

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

[Talk-it] Interessante app

[Lorenzo Rolla]

Gentilissimi, segnalo quest’app che permette un rapido riscontro a chi
cerca le mascherine... Lo segnalo perché usano le nostre mappe. Buona
serata. Lorenzo

https://www.trovamascherine.org

https://torino.repubblica.it/cronaca/2020/05/04/news/coronavirus_nasce_ad_asti_la_app_per_trovare_le_mascherine-255630494/


-- 
Lorenzo Rolla
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Prova di "nuova grafica" per su.openstreetmap.it

[Francesco Ansanelli]

Ringrazio Nap Osm per il contributo e la pazienza nel risolvere tutte le
mie osservazioni! 
Ho fatto merge delle sue modifiche e ora la nuova veste grafica è anche
rilasciata in produzione.

Buona serata
Francesco

Il giorno lun 4 mag 2020 alle ore 20:34 Francesco Ansanelli <
franci...@gmail.com> ha scritto:

> Ciao,
>
> ho fatto una veloce review delle modifiche... Aspetto che naposm sistemi e
> poi penso si possa mettere in produzione.
>
> Buona serata
> Francesco
>
> Il giorno lun 4 mag 2020 alle ore 19:28 Alessandro Sarretta <
> alessandro.sarre...@gmail.com> ha scritto:
>
>> On 04/05/20 14:11, Cascafico Giovanni wrote:
>>
>> A me pare OK: possiamo metterla in produzione sull'url
>> su.openstreetmap.it?
>>
>> Per me sì! :-)
>>
>> Grazie,
>>
>> Ale
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Francesco Pelullo]

Ciao,
benvenuta e buon lavoro.

/niubii/


Il giorno mar 5 mag 2020 alle ore 17:43 Marco Minghini <
marco.minghin...@gmail.com> ha scritto:

> Ciao Anisa,
> sono molto contento di ritrovarti qui dopo la bellissima esperienza di
> SotM 2017.
> In bocca al lupo per tutto!
> Marco
>
> Il giorno mar 5 mag 2020 alle ore 17:14 Andrea Musuruane <
> musur...@gmail.com> ha scritto:
>
>> Benvenuta.
>>
>> A presto,
>>
>> Andrea
>>
>>
>> On Tue, May 5, 2020 at 2:54 PM Anisa Kuci 
>> wrote:
>>
>>> Ciao a tutti,
>>>
>>>
>>> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
>>> Italia.
>>>
>>> Sono di origine albanese ma vivo in Italia da due anni, ho già
>>> contribuito ad OSM e sono stata parte della prima comunità/hackerspace che
>>> ha promosso e continua a
>>>
>>> promuovere le tecnologie FLOSS in Albania.
>>>
>>>
>>> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
>>> comunità nel mio paese, contribuendo online (mapping) e offline,
>>> promuovendo il progetto,
>>>
>>> organizzando mapathons, workshops, OSM infobooths etc.
>>>
>>>
>>> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di
>>> tanti paesi e ho fatto anche una presentazione sul "Community building”.
>>>
>>> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
>>> co-organizzato workshops riguardo a OSM e progetti Wikimedia
>>> nell'hackerspace e nelle scuole.
>>>
>>> Sono stata parte del core team che ha fatto un accordo con il Municipio
>>> di Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>>>
>>>
>>> Sono molto entusiasta ed interessata a far crescere ancora di più il
>>> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
>>> su Wikimedia Italia
>>>
>>> e dovrò affrontare un periodo di formazione, ma a breve spero di
>>> interagire più attivamente con la comunità.
>>>
>>> Quindi mi farò sentire presto con delle proposte e delle richieste.
>>>
>>>
>>> A causa della situazione per il Covid-19 lavorerò inizialmente da
>>> remoto. Quando la situazione e le misure di lockdown cambieranno, sarò
>>> presente in sede a Milano.
>>>
>>>
>>> Per qualsiasi cosa potete contattarmi a questo indirizzo:
>>> anisa.k...@wikimedia.it
>>>
>>> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>>>
>>>
>>> Ci sentiamo presto,
>>>
>>> Anisa
>>>
>>>
>>> --
>>> Anisa Kuci
>>> Responsabile OpenStreetMap e Wikidata
>>> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
>>> Via Bergognone 34 - 20144 Milano
>>> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>>>
>>> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
>>> Devolvi il 5x1000 a Wikimedia Italia:
>>> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Marco Minghini]

Ciao Anisa,
sono molto contento di ritrovarti qui dopo la bellissima esperienza di SotM
2017.
In bocca al lupo per tutto!
Marco

Il giorno mar 5 mag 2020 alle ore 17:14 Andrea Musuruane 
ha scritto:

> Benvenuta.
>
> A presto,
>
> Andrea
>
>
> On Tue, May 5, 2020 at 2:54 PM Anisa Kuci  wrote:
>
>> Ciao a tutti,
>>
>>
>> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
>> Italia.
>>
>> Sono di origine albanese ma vivo in Italia da due anni, ho già
>> contribuito ad OSM e sono stata parte della prima comunità/hackerspace che
>> ha promosso e continua a
>>
>> promuovere le tecnologie FLOSS in Albania.
>>
>>
>> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
>> comunità nel mio paese, contribuendo online (mapping) e offline,
>> promuovendo il progetto,
>>
>> organizzando mapathons, workshops, OSM infobooths etc.
>>
>>
>> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
>> paesi e ho fatto anche una presentazione sul "Community building”.
>>
>> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
>> co-organizzato workshops riguardo a OSM e progetti Wikimedia
>> nell'hackerspace e nelle scuole.
>>
>> Sono stata parte del core team che ha fatto un accordo con il Municipio
>> di Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>>
>>
>> Sono molto entusiasta ed interessata a far crescere ancora di più il
>> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
>> su Wikimedia Italia
>>
>> e dovrò affrontare un periodo di formazione, ma a breve spero di
>> interagire più attivamente con la comunità.
>>
>> Quindi mi farò sentire presto con delle proposte e delle richieste.
>>
>>
>> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
>> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
>> sede a Milano.
>>
>>
>> Per qualsiasi cosa potete contattarmi a questo indirizzo:
>> anisa.k...@wikimedia.it
>>
>> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>>
>>
>> Ci sentiamo presto,
>>
>> Anisa
>>
>>
>> --
>> Anisa Kuci
>> Responsabile OpenStreetMap e Wikidata
>> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
>> Via Bergognone 34 - 20144 Milano
>> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>>
>> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
>> Devolvi il 5x1000 a Wikimedia Italia:
>> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Ennesima mancata attribuzione stessa testata

[Jeawrong]

Sim la scritta l'hanno messa (dopo svariate mail di protesta...) ma
ovviamente l'attribuzione va fatta in altro modo, ho spiegato loro passo
passo la procedura, ma nisba... Lo so, continuiamo a discuterne da tempo, ma
non si arriva mai ad una soluzione efficace.



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Andrea Musuruane]

Benvenuta.

A presto,

Andrea


On Tue, May 5, 2020 at 2:54 PM Anisa Kuci  wrote:

> Ciao a tutti,
>
>
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
> Italia.
>
> Sono di origine albanese ma vivo in Italia da due anni, ho già contribuito
> ad OSM e sono stata parte della prima comunità/hackerspace che ha promosso
> e continua a
>
> promuovere le tecnologie FLOSS in Albania.
>
>
> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
> comunità nel mio paese, contribuendo online (mapping) e offline,
> promuovendo il progetto,
>
> organizzando mapathons, workshops, OSM infobooths etc.
>
>
> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
> paesi e ho fatto anche una presentazione sul "Community building”.
>
> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
> co-organizzato workshops riguardo a OSM e progetti Wikimedia
> nell'hackerspace e nelle scuole.
>
> Sono stata parte del core team che ha fatto un accordo con il Municipio di
> Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>
>
> Sono molto entusiasta ed interessata a far crescere ancora di più il
> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
> su Wikimedia Italia
>
> e dovrò affrontare un periodo di formazione, ma a breve spero di
> interagire più attivamente con la comunità.
>
> Quindi mi farò sentire presto con delle proposte e delle richieste.
>
>
> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
> sede a Milano.
>
>
> Per qualsiasi cosa potete contattarmi a questo indirizzo:
> anisa.k...@wikimedia.it
>
> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>
>
> Ci sentiamo presto,
>
> Anisa
>
>
> --
> Anisa Kuci
> Responsabile OpenStreetMap e Wikidata
> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
> Via Bergognone 34 - 20144 Milano
> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>
> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
> Devolvi il 5x1000 a Wikimedia Italia:
> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[maurizio galli]

Benvenuta !!

Il mar 5 mag 2020, 14:54 Anisa Kuci  ha scritto:

> Ciao a tutti,
>
>
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
> Italia.
>
> Sono di origine albanese ma vivo in Italia da due anni, ho già contribuito
> ad OSM e sono stata parte della prima comunità/hackerspace che ha promosso
> e continua a
>
> promuovere le tecnologie FLOSS in Albania.
>
>
> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
> comunità nel mio paese, contribuendo online (mapping) e offline,
> promuovendo il progetto,
>
> organizzando mapathons, workshops, OSM infobooths etc.
>
>
> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
> paesi e ho fatto anche una presentazione sul "Community building”.
>
> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
> co-organizzato workshops riguardo a OSM e progetti Wikimedia
> nell'hackerspace e nelle scuole.
>
> Sono stata parte del core team che ha fatto un accordo con il Municipio di
> Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>
>
> Sono molto entusiasta ed interessata a far crescere ancora di più il
> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
> su Wikimedia Italia
>
> e dovrò affrontare un periodo di formazione, ma a breve spero di
> interagire più attivamente con la comunità.
>
> Quindi mi farò sentire presto con delle proposte e delle richieste.
>
>
> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
> sede a Milano.
>
>
> Per qualsiasi cosa potete contattarmi a questo indirizzo:
> anisa.k...@wikimedia.it
>
> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>
>
> Ci sentiamo presto,
>
> Anisa
>
>
> --
> Anisa Kuci
> Responsabile OpenStreetMap e Wikidata
> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
> Via Bergognone 34 - 20144 Milano
> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>
> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
> Devolvi il 5x1000 a Wikimedia Italia:
> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Volker Schmidt]

Benvenuta!
Buon Lavoro!

Volker

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

[OSM-talk-fr] Tags multiples dans OSM (API v0.7)

[Yves P.]

Pour faire suite à mon message précédent sur les tags longs, j'aimerais aussi 
discuter à propos des tags  avec des valeurs multiples (séparées par des ; )

> J'ai lu un article d'Andy Allan (l'un des développeurs du site web d'OSM) au 
> sujet d'une mise à jour en "douceur" de l'API :
> Smoother API upgrades for OpenStreetMap 
> 
> 
> Il ne parle pas de ce point. Par contre on l'avait abordé sur cette liste.
> Il est accessoirement évoqué sur  la page concernant la future API v0.7 
> 
Ce point est explicitement évoqué dans la page précédente : 
https://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags

> Je propose que la version 0.7 gère des tags de plus de 255 caractères :)
> Et pour le passage en douceur, que ce tag soit découpé/réasssemblé 
> automatiquement en plusieurs tags pour les logiciels fonctionnant en v0.6

La solution proposé ressemble assez à ma proposition pour les grands tags (on 
coupe la valeur arbitrairement tous les 255 caractères).

Ici, on coupe/réassemble à chaque séparateur (fonctions SPLIT / EXPLODE de 
certains langages)

Exemple :

v0.7

my_tag=value 1
my_tag=value 2
my_tag=value 3

donnerait en 0.6
my_tag=value 1;value 2;value 3

Si la valeur est trop grande, on combine ça avec ma proposition précédente (en 
essayant si possible de couper au niveau d'un séparateur)

C'est compatible avec tous les éditeurs et une fois tous les outils en v0.7, 
TagInfo permettra de compter "correctement' les tags utilisés.

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

Re: [OSM-talk-fr] Workflow pour opendata

[Frédéric Rodrigo]

Le 05/05/2020 à 14:09, Nicolas Bétheuil a écrit :
Je ne voyais pas comment faire mon analyse osmose avec des fois des 
shop, des fois amenity, des fois autre chose. Trop de typologie 
différentes.


Quand il y a à boire et à manger, il faut partir sur une analyse 
dynamique. La plupart du temps on décrit le mapping dans un fichier de 
configurations


https://github.com/osm-fr/osmose-backend/blob/master/merge_data/shop_FR.mapping.json

https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merge_shop_FR.py



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

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Alessandro Vitali]

Ciao e benvenuta!!

Ale Vit

Il giorno mar 5 mag 2020 alle ore 16:10 mbranco2  ha
scritto:

> Ciao Anisa, benvenuta!
>
> Marco
>
> Il giorno mar 5 mag 2020 alle ore 14:54 Anisa Kuci <
> anisa.k...@wikimedia.it> ha scritto:
>
>> Ciao a tutti,
>>
>>
>> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
>> Italia.
>>
>> Sono di origine albanese ma vivo in Italia da due anni, ho già
>> contribuito ad OSM e sono stata parte della prima comunità/hackerspace che
>> ha promosso e continua a
>>
>> promuovere le tecnologie FLOSS in Albania.
>>
>>
>> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
>> comunità nel mio paese, contribuendo online (mapping) e offline,
>> promuovendo il progetto,
>>
>> organizzando mapathons, workshops, OSM infobooths etc.
>>
>>
>> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
>> paesi e ho fatto anche una presentazione sul "Community building”.
>>
>> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
>> co-organizzato workshops riguardo a OSM e progetti Wikimedia
>> nell'hackerspace e nelle scuole.
>>
>> Sono stata parte del core team che ha fatto un accordo con il Municipio
>> di Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>>
>>
>> Sono molto entusiasta ed interessata a far crescere ancora di più il
>> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
>> su Wikimedia Italia
>>
>> e dovrò affrontare un periodo di formazione, ma a breve spero di
>> interagire più attivamente con la comunità.
>>
>> Quindi mi farò sentire presto con delle proposte e delle richieste.
>>
>>
>> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
>> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
>> sede a Milano.
>>
>>
>> Per qualsiasi cosa potete contattarmi a questo indirizzo:
>> anisa.k...@wikimedia.it
>>
>> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>>
>>
>> Ci sentiamo presto,
>>
>> Anisa
>>
>>
>> --
>> Anisa Kuci
>> Responsabile OpenStreetMap e Wikidata
>> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
>> Via Bergognone 34 - 20144 Milano
>> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>>
>> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
>> Devolvi il 5x1000 a Wikimedia Italia:
>> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Workflow pour opendata

[Yves P.]

> pour l'instant curl, un formulaire d'upload serait pas compliqué à proposer 
> en coup unique.
Ok :)

> mais vu que l'open data est évolutif et mis à jour, que ce soit automatisé 
> sera mieux.
Dans le cas d'un "gros" fichier mis à jour périodiquement, ça me parait plus du 
ressort dOsmose.

Dans le cas des "petits" fichiers de bibliothèque de Magalie, un formulaire 
serait le bienvenu :)

Et toujours pour les "petits" fichiers, est-ce que postgresql est vraiment 
nécessaire ?

Une carte peut charger directement en mémoire quelques centaines voir un 
millier de POI.
(cas des requêtes Overpass).

ça permettrait peut-être de déployer le code plus facilement, et en tout cas 
d'éviter l'installation de Docker ou Postgresql.
(c'est facile pour un dév qui travaille avec ça toute la journée, plus 
difficile pour les autres).

> Le contributeur n'aura pas à rentrer dans node / postgres / clevercloud / git 
> …
Oui :) Je pensais plus à de gros logiciels QA comme Osmose ;)

> Le premier fourni le fichier OD à od2osm le fera le langage/traitement qui 
> lui va, même un tableur pour produire un geojson.
> Les autres n'auront "qu'à" cliquer dans od2osm pour tout traiter.


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

Re: [Talk-it] Ennesima mancata attribuzione stessa testata

[Martin Koppenhoefer]

io vedo una scritta:
[image: Screenshot 2020-05-05 at 16.21.40.png]
non è l'attribuzione perfetta, ma qualcosa c'è (legalmente non è
sufficiente).

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] Limite de 255 caractères dans les tags OSM

[Yves P.]

Bonjour,

J'ai lu un article d'Andy Allan (l'un des développeurs du site web d'OSM) au 
sujet d'une mise à jour en "douceur" de l'API :
Smoother API upgrades for OpenStreetMap 


Il ne parle pas de ce point. Par contre on l'avait abordé sur cette liste.
Il est accessoirement évoqué sur  la page concernant la future API v0.7 


Je propose que la version 0.7 gère des tags de plus de 255 caractères :)
Et pour le passage en douceur, que ce tag soit découpé/réasssemblé 
automatiquement en plusieurs tags pour les logiciels fonctionnant en v0.6

Exemple:

En v0.7

exemple_key="super long value…"

ça donnerait pour la v0.6 :

exemple_key="super long value"
exemple_key_1="super long value part 2…"
exemple_key_2="super long value part 3…"
…

c'est compatible avec iD :) (qui fait déjà çà :/ )
c'est compatible avec les autres éditeurs :)

Une fois tout le monde en v0.7, les clés _1, _2… vont disparaitre (presque) 
toutes seules :)

__
Yves
 


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

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[mbranco2]

Ciao Anisa, benvenuta!

Marco

Il giorno mar 5 mag 2020 alle ore 14:54 Anisa Kuci 
ha scritto:

> Ciao a tutti,
>
>
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
> Italia.
>
> Sono di origine albanese ma vivo in Italia da due anni, ho già contribuito
> ad OSM e sono stata parte della prima comunità/hackerspace che ha promosso
> e continua a
>
> promuovere le tecnologie FLOSS in Albania.
>
>
> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
> comunità nel mio paese, contribuendo online (mapping) e offline,
> promuovendo il progetto,
>
> organizzando mapathons, workshops, OSM infobooths etc.
>
>
> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
> paesi e ho fatto anche una presentazione sul "Community building”.
>
> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
> co-organizzato workshops riguardo a OSM e progetti Wikimedia
> nell'hackerspace e nelle scuole.
>
> Sono stata parte del core team che ha fatto un accordo con il Municipio di
> Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>
>
> Sono molto entusiasta ed interessata a far crescere ancora di più il
> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
> su Wikimedia Italia
>
> e dovrò affrontare un periodo di formazione, ma a breve spero di
> interagire più attivamente con la comunità.
>
> Quindi mi farò sentire presto con delle proposte e delle richieste.
>
>
> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
> sede a Milano.
>
>
> Per qualsiasi cosa potete contattarmi a questo indirizzo:
> anisa.k...@wikimedia.it
>
> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>
>
> Ci sentiamo presto,
>
> Anisa
>
>
> --
> Anisa Kuci
> Responsabile OpenStreetMap e Wikidata
> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
> Via Bergognone 34 - 20144 Milano
> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>
> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
> Devolvi il 5x1000 a Wikimedia Italia:
> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Import] civici Bergamo

[Martin Koppenhoefer]

sent from a phone

> On 5. May 2020, at 13:30, Cascafico Giovanni  wrote:
> 
> "A condizione di: indicare la fonte delle Informazioni e il nome del 
> Licenziante, "
> 
> Io avevo inteso che osm non può garantire qs condizione.


questo lo possiamo fare, credo. Io avevo pensato la IODL fosse una versione 
della ODbL in italiano, ma riferito all’attribuzione sembra meno severa (la 
ODbL richiede che chiunque veda un’opera prodotta deve vedere l’attribuzione)

Ciao Martin  
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Offener Stammtisch: Vorstellung BleibtOffen - COVID19 Öffnungszeiten

[Christine Karch]

Auf dem Stuttgarter Stammtisch kam die Idee auf für Bleibt Offen Flyer
bereitzustellen. Carsten hat das Design übernommen und die Geofabrik hat
sich bereit erklärt die Flyer drucken zu lassen und den Versand zu
übernehmen.

Hier der Flyer:

https://github.com/bleibtoffen/bleibtoffen/files/4580031/Flyer_DIN_lang_schmal_100x210mm_2Seiten_DE_Druck_PF.pdf

Wenn jemand ein paar davon haben möchte, um sie in der Nachbarschaft zu
verteilen, bitte bei der Geofabrik melden (i...@geofabrik.de). Wir
schicken sie euch dann zu.

Am 21.04.20 um 23:08 schrieb Holger Bruch:
> Hallo zusammen,
> 
> der OSM Stammtisch Stuttgart lädt für 
> 
>   Morgen Abend, 22.4., 20 Uhr 
> 
> zur offenen Web-Assembly zu „BleibtOffen“ [1] ein, einer Karte zur 
> Darstellung und einfachen Erfassung von Öffnungszeiten während des 
> Corona-Lockdown.
> 
> Christine Karch stellt das Projekt vor, dessen Portierung aus dem 
> französischen „Ça reste ouvert" Claas Augner vor nicht mal drei Wochen hier 
> gestartet hat, und zu dem schon viele hier beigetragen haben.
> 
> Teilnahme über: https://meet.systect.de/b/hol-hmx-nk7
> 
> [1] https://www.bleibtoffen.org/
> 
> Viele Grüße,
> Holger
> 


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

Re: [OSM-talk-fr] Workflow pour opendata

[Nicolas Bétheuil]

> Il y a un formulaire quelque part ou il faut utiliser cURL ?

pour l'instant curl, un formulaire d'upload serait pas compliqué à proposer
en coup unique.
mais vu que l'open data est évolutif et mis à jour, que ce soit automatisé
sera mieux.

Le contributeur n'aura pas à rentrer dans node / postgres / clevercloud /
git ...
Le premier fourni le fichier OD à od2osm le fera le langage/traitement qui
lui va, même un tableur pour produire un geojson.
Les autres n'auront "qu'à" cliquer dans od2osm pour tout traiter.

Le mar. 5 mai 2020 à 15:33, Yves P.  a écrit :

> En local j'ai un postgres dans un docker. Sur une plateforme comme clever
> cloud ou scalingo ce sera une application d'API node et un frontale. Il y a
> un point d'entrée d'api qui permet de téléverser le geojson et qui fait
> l'ajout en base (un post multipart sur /quests
> https://github.com/wadouk/od2osm/blob/363351488d06a2194e0975a15143fd3e841932e5/server.js#L81)
> qui recharge l'ensemble des points.
>
> Merci pour les explications.
>
> Tu envois comment le fichier en petits-morceaux sur l'api /quests ?
> Il y a un formulaire quelque part ou il faut utiliser cURL ?
>
> Tu m'avais causé d'open refine. Il fallait scripter pour aller plus loin
> pour un outil juste en local. Je trouve le coup d'entrée par contributeur
> un peu élevé pour un jeu de données évoluant.
>
> Le coup d'entrée est "relatif".
> Un contributeur lambda va avoir du boulot pour assimiler node.js, GitHub,
> clever cloud… ou Python… pour d'autres projets.
>
> OpenRefine est un couteau suisse assez facile à utiliser après une phase
> de digestion de la doc :)
> Et pas besoin de git, GitHub, PR et de cierges pour les merges ;D
>
> Pour que ce soit utilisable par un non développeur, il faut écrire un bon
> tutoriel :)
>
> De plus cet outil n'a pas à vocation à remplacer ni Osmose, ni JOSM,
> ni od2osm…
> C'est un bon complément selon moi.
> Il ne fait pas tout, mais le fait très bien :)
>
> Concrètement on peut triturer les données en "temps réel" avec quelques
> clics et des éditions de scripts.
> En saisissant une "formule" on voit les données se recalculer/reformatter
> (sur un échantillon de 5, 10 25 ou 50 lignes).
>
> Un fois la recette au point, on obtient un fichier directement utilisable :
>
>- en local avec JOSM,
>- ou en ligne avec Osmose, MapRoulette… ou peut-être od2osm.
>
>
> __
> Yves
> ___
> 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: [Talk-it] [Import] civici Bergamo

[Martin Koppenhoefer]

sent from a phone

> On 5. May 2020, at 11:53, Andrea Musuruane  wrote:
> 
> Continuo a non capire. La IODLv2 non richiede che l'attribuzione sia 
> appiccicata al dato (ovvero messa nel tag source dei nodi importati). Solo 
> che sia data (ovvero come abbiamo sempre fatto nella pagina dei Contributors).
> https://web.archive.org/web/20170126111950/http://www.dati.gov.it/iodl/2.0/


in effetti anche a me non sembra ci sia il requisito di attribuire direttamente 
sulla mappa (l’abbiamo fatto vedere ad un avvocato esperto in materia di 
diritti intellettuali e di banca dati?), invece sembra ci sia una possibile 
incompatibilità in quanto ci sono restrizioni sull’uso: “
prendere ogni misura ragionevole affinché gli usi innanzi consentiti non 
traggano in inganno altri soggetti e le Informazioni medesime non vengano 
travisate.
“

grassetto da me, questo è certamente soggetto ad interpretazioni, ma noi al 
solito modifichiamo i dati, e consentiamo a chiunque di farlo.

Ciao Martin ___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Workflow pour opendata

[Nicolas Bétheuil]

Bah en fait c'est un peu l'idée même si le côté "sans code" mof : il va
bien falloir convertir le jeu de données en tag pour faire rentrer les
ronds dans les carrés. Il va bien falloir faire un peu de code, mais dans
mon option il n'y a rien d'imposé.
Pour m'inspirer, elle était où cette discussion ?

Le mar. 5 mai 2020 à 14:59, Marc M.  a écrit :

> Bonjour,
>
> Le 05.05.20 à 12:24, Magalie Dartus a écrit :
> > je n'ai toujours pas acquis la compétence "charger le fichier
> > open data dans osmose".
>
> le plus simple pour avancer me semble être :
> - publier le fichier quelque part
> - créer un ticket https://github.com/osm-fr/osmose-backend/issues
> de là, ceux "qui savent" pourront sans doute mieux guider
> sur comment faire l'analyse.
>
> Il y avait aussi eu une discussion pour faire un système plus simple,
> sans code, genre on liste le fichier, les tags osm, et "voilà".
> mais ce n'est pas encore une réalité.
>
> Cordialement,
> Marc
>
> ___
> 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] Workflow pour opendata

[Yves P.]

> En local j'ai un postgres dans un docker. Sur une plateforme comme clever 
> cloud ou scalingo ce sera une application d'API node et un frontale. Il y a 
> un point d'entrée d'api qui permet de téléverser le geojson et qui fait 
> l'ajout en base (un post multipart sur /quests 
> https://github.com/wadouk/od2osm/blob/363351488d06a2194e0975a15143fd3e841932e5/server.js#L81
>  
> )
>  qui recharge l'ensemble des points.
Merci pour les explications.

Tu envois comment le fichier en petits-morceaux sur l'api /quests ?
Il y a un formulaire quelque part ou il faut utiliser cURL ?

> Tu m'avais causé d'open refine. Il fallait scripter pour aller plus loin pour 
> un outil juste en local. Je trouve le coup d'entrée par contributeur un peu 
> élevé pour un jeu de données évoluant.
Le coup d'entrée est "relatif".
Un contributeur lambda va avoir du boulot pour assimiler node.js, GitHub, 
clever cloud… ou Python… pour d'autres projets.

OpenRefine est un couteau suisse assez facile à utiliser après une phase de 
digestion de la doc :)
Et pas besoin de git, GitHub, PR et de cierges pour les merges ;D

Pour que ce soit utilisable par un non développeur, il faut écrire un bon 
tutoriel :)

De plus cet outil n'a pas à vocation à remplacer ni Osmose, ni JOSM, ni od2osm…
C'est un bon complément selon moi.
Il ne fait pas tout, mais le fait très bien :)

Concrètement on peut triturer les données en "temps réel" avec quelques clics 
et des éditions de scripts.
En saisissant une "formule" on voit les données se recalculer/reformatter (sur 
un échantillon de 5, 10 25 ou 50 lignes).

Un fois la recette au point, on obtient un fichier directement utilisable :
en local avec JOSM,
ou en ligne avec Osmose, MapRoulette… ou peut-être od2osm.

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

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[dam...@damjan.net]

> Ciao a tutti,
> 
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia 
> Italia.

Ciao, auguri, benvenuta e buon lavoro!

Damjan

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

Re: [Talk-it] [Import] civici Bergamo

[Martin Koppenhoefer]

sent from a phone

> On 5. May 2020, at 10:47, Andrea Musuruane  wrote:
> 
> Invece di rifare tutto, riusciamo a fargli documentare l'import e a sistemare 
> quello che c'è? Com'è la qualità dei dati? Hai già contattato l'utente?


c’è il consenso di attribuire sulla pagina copyright di OpenStreetMap piuttosto 
che sulla mappa?

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Martin Koppenhoefer]

sent from a phone

> On 5. May 2020, at 14:54, Anisa Kuci  wrote:
> 
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia Italia.


Ciao Anisa,

congratulazioni e buon lavoro!

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

[Talk-it] Ennesima mancata attribuzione stessa testata

[Jeawrong]

Ennesima mancata attribuzione da parte della stessa testata locale [1], ho
scritto decine di volte spiegandogli per filo e per segno come attribuire
correttamente, inizio ad essere stufo... Vogliamo continuare a non vedere
riconosciuto il nostro lavoro?

[1] 
https://www.cronachemaceratesi.it/2020/05/05/scossa-ad-amandola-magnitudo-3-6/1400772/

  



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Rossella Di Bari]

Ciao Anisa,
Congratulazioni e in bocca al lupo 

Rossella

Il mar 5 mag 2020, 14:54 Anisa Kuci  ha scritto:

> Ciao a tutti,
>
>
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
> Italia.
>
> Sono di origine albanese ma vivo in Italia da due anni, ho già contribuito
> ad OSM e sono stata parte della prima comunità/hackerspace che ha promosso
> e continua a
>
> promuovere le tecnologie FLOSS in Albania.
>
>
> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
> comunità nel mio paese, contribuendo online (mapping) e offline,
> promuovendo il progetto,
>
> organizzando mapathons, workshops, OSM infobooths etc.
>
>
> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
> paesi e ho fatto anche una presentazione sul "Community building”.
>
> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
> co-organizzato workshops riguardo a OSM e progetti Wikimedia
> nell'hackerspace e nelle scuole.
>
> Sono stata parte del core team che ha fatto un accordo con il Municipio di
> Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>
>
> Sono molto entusiasta ed interessata a far crescere ancora di più il
> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
> su Wikimedia Italia
>
> e dovrò affrontare un periodo di formazione, ma a breve spero di
> interagire più attivamente con la comunità.
>
> Quindi mi farò sentire presto con delle proposte e delle richieste.
>
>
> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
> sede a Milano.
>
>
> Per qualsiasi cosa potete contattarmi a questo indirizzo:
> anisa.k...@wikimedia.it
>
> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>
>
> Ci sentiamo presto,
>
> Anisa
>
>
> --
> Anisa Kuci
> Responsabile OpenStreetMap e Wikidata
> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
> Via Bergognone 34 - 20144 Milano
> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>
> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
> Devolvi il 5x1000 a Wikimedia Italia:
> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Jo]

complimenti e buona fortuna!

Polyglot

On Tue, May 5, 2020, 14:54 Anisa Kuci  wrote:

> Ciao a tutti,
>
>
> sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia
> Italia.
>
> Sono di origine albanese ma vivo in Italia da due anni, ho già contribuito
> ad OSM e sono stata parte della prima comunità/hackerspace che ha promosso
> e continua a
>
> promuovere le tecnologie FLOSS in Albania.
>
>
> E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la
> comunità nel mio paese, contribuendo online (mapping) e offline,
> promuovendo il progetto,
>
> organizzando mapathons, workshops, OSM infobooths etc.
>
>
> Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di tanti
> paesi e ho fatto anche una presentazione sul "Community building”.
>
> Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho
> co-organizzato workshops riguardo a OSM e progetti Wikimedia
> nell'hackerspace e nelle scuole.
>
> Sono stata parte del core team che ha fatto un accordo con il Municipio di
> Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.
>
>
> Sono molto entusiasta ed interessata a far crescere ancora di più il
> progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap sia
> su Wikimedia Italia
>
> e dovrò affrontare un periodo di formazione, ma a breve spero di
> interagire più attivamente con la comunità.
>
> Quindi mi farò sentire presto con delle proposte e delle richieste.
>
>
> A causa della situazione per il Covid-19 lavorerò inizialmente da remoto.
> Quando la situazione e le misure di lockdown cambieranno, sarò presente in
> sede a Milano.
>
>
> Per qualsiasi cosa potete contattarmi a questo indirizzo:
> anisa.k...@wikimedia.it
>
> Sono anche sul gruppo telegram di OpenStreetMap Italia.
>
>
> Ci sentiamo presto,
>
> Anisa
>
>
> --
> Anisa Kuci
> Responsabile OpenStreetMap e Wikidata
> Wikimedia Italia - Associazione per la diffusione della conoscenza libera
> Via Bergognone 34 - 20144 Milano
> Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it
>
> DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
> Devolvi il 5x1000 a Wikimedia Italia:
> nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Adam Snape]

On Tue, 5 May 2020, 13:26 Martin Wynne,  wrote:

> Is a "public right of way" a highway?
>
> I suggest not. It's a legal construct, similar to a boundary line.
>
> Perhaps it should be mapped as a separate way, sometimes sharing nodes
> with a physical highway, sometimes not.
>

In English/Welsh law a highway is a right of passage, so a public right of
way is a highway by definition.

For OSM purposes? I don't know, but I've always assumed so. As discussed
for practical reasons I wouldn't tag a completely inaccessible prow as a
highway but I've never considered a physically worn path on the ground a
requirement for being a highway=footway, bridleway etc.

Adam

>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[Marc M.]

Le 05.05.20 à 12:54, GarenKreiz a écrit :
> Comment sont tracées ce type de décisions?

aucune idée pour ce cas précis mais généralement cela se discute
sur la page talk du wiki et/ou sur la liste tagging
le commentaire de la modif fait alors idéalement référence
au lieu de la discussion

généralement et idéalement :)

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

Re: [OSM-talk-fr] Workflow pour opendata

[Marc M.]

Bonjour,

Le 05.05.20 à 12:24, Magalie Dartus a écrit :
> je n'ai toujours pas acquis la compétence "charger le fichier 
> open data dans osmose".

le plus simple pour avancer me semble être :
- publier le fichier quelque part
- créer un ticket https://github.com/osm-fr/osmose-backend/issues
de là, ceux "qui savent" pourront sans doute mieux guider
sur comment faire l'analyse.

Il y avait aussi eu une discussion pour faire un système plus simple,
sans code, genre on liste le fichier, les tags osm, et "voilà".
mais ce n'est pas encore une réalité.

Cordialement,
Marc

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

Re: [OSM-talk-fr] Présentation et cas particulier des ref sur ronds points

[Marc M.]

Bonjour,

Le 05.05.20 à 10:29, BEGUIN,Bruno a écrit :
> nous avions présenté cette application de validation d'imports OSM 
> 'LeBonTag', lors du dernier SOTM France à domicile.

bienvenue :) j'avais vu la présentation (sur peertube de mémoire),
très sympa, même si le nom me fait penser à un outil tel le traducteur
"humain -> tag" de l'assistant d'overpass turbo

> Le wiki indique que les ronds-points n'ont pas à être tagués avec REF

la logique selon moi est qu'on ne met pas la ref de la route sur tous
les nœuds de celle-ci, pas même sur les croisements avec d'autres voies.
Si on ne met pas la ref de la route sur un carrefour en croix,
par extension on fait de même si ce "carrefour" est un rond-point.
Le carrefour en croix ou en rond-point n'étant qu'un lieu
ponctuel de plusieurs voies et non ces voies.

> 1- dans un soucis de continuité d'une route, 

un ronds-points peux aussi être représenté par un simple point
d'intersection des voies (par exemple quand il n'est pas encore
sur la vue sat ou qu'on veux faire simple)
mettriez-vous la ref sur le noeud dans ce cas ?
moi pas.
Je ne vois pas trop quelle continuité est rompue par l'absence
de ref sur les carrefours. c'est lors de sa récupération
en se basant sur la ref ?

> Et lorsque 2 départementales se croisent, la plus importante sur notre 
> hiérarchie donne son ref au rond point.

dans votre logique, la départementale la plus "faible" est discontinue ?
Si vous acceptez cette discontinuité, alors il est aussi
acceptable/gérable pour la voie la plus "importante"

> 2- <...> notamment pour le guidage GPS.

je n'arrive pas à imaginer le cas concret.
je n'aimerais pas que le guidage me dise "prenez le rond-point ref N1"
alors qu'il n'y a aucune ref sur celle-ci (et en plus, arrivant à
celui-ci, je peux difficilement en prendre un autre)
as-tu un exemple (lieu "osm" + app) où cette ref serrait utile ?

PS: en passant : merci pour la politique de la métropole concernant
l'OD et osm. en espérant toujours plus, toujours mieux :)
Il faudrait un "concours" entre métropoles/communes pour mettre
en lumière ce que d'autres ont fait et qui pourraient être transposée
ailleurs.

Cordialement,
Marc

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

[Talk-it] Nuova Responsabile OpenStreetMap e Wikidata - Wikimedia Italia

[Anisa Kuci]

Ciao a tutti,


sono Anisa Kuci, la nuova responsabile OSM e Wikidata presso Wikimedia 
Italia.


Sono di origine albanese ma vivo in Italia da due anni, ho già 
contribuito ad OSM e sono stata parte della prima comunità/hackerspace 
che ha promosso e continua a


promuovere le tecnologie FLOSS in Albania.


E lì che ho conosciuto il progetto OSM e ho aiutato a far crescere la 
comunità nel mio paese, contribuendo online (mapping) e offline, 
promuovendo il progetto,


organizzando mapathons, workshops, OSM infobooths etc.


Ho partecipato a SOTM 2017, dove ho creato contatti con comunità di 
tanti paesi e ho fatto anche una presentazione sul "Community building”.


Sono stata “Mapper of the Month” per OSM Belgium nel 2018. Ho 
co-organizzato workshops riguardo a OSM e progetti Wikimedia 
nell'hackerspace e nelle scuole.


Sono stata parte del core team che ha fatto un accordo con il Municipio 
di Tirana per liberare i dati geospaziali e inserirli in OpenStreetMap.



Sono molto entusiasta ed interessata a far crescere ancora di più il 
progetto, anche se devo ancora imparare tante cose sia su OpenStreetMap 
sia su Wikimedia Italia


e dovrò affrontare un periodo di formazione, ma a breve spero di 
interagire più attivamente con la comunità.


Quindi mi farò sentire presto con delle proposte e delle richieste.


A causa della situazione per il Covid-19 lavorerò inizialmente da 
remoto. Quando la situazione e le misure di lockdown cambieranno, sarò 
presente in sede a Milano.



Per qualsiasi cosa potete contattarmi a questo indirizzo: 
anisa.k...@wikimedia.it


Sono anche sul gruppo telegram di OpenStreetMap Italia.


Ci sentiamo presto,

Anisa


--
Anisa Kuci
Responsabile OpenStreetMap e Wikidata
Wikimedia Italia - Associazione per la diffusione della conoscenza libera
Via Bergognone 34 - 20144 Milano
Tel. (+39) 02 97677170 | anisa.k...@wikimedia.it | www.wikimedia.it

DAI ALLA CONOSCENZA LIBERA UN NUOVO NOME. IL TUO.
Devolvi il 5x1000 a Wikimedia Italia:
nella tua dichiarazione dei redditi inserisci il Codice Fiscale 94039910156

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

Re: [Talk-it] [Import] civici Bergamo

[Alessandro Sarretta]

On 05/05/20 12:27, Andrea Musuruane wrote:

La pagina è ancora presente, non so perché prima non me la caricasse:
https://www.dati.gov.it/iodl/2.0/
Ottimo, anche a me prima dava errore e mi aveva parecchio confuso non 
poter leggere il testo legale della licenza.


Ale


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

[OSM-talk-fr] Appel à volontaire: référent JOSM au sein de la fonction publique

[Vincent Privat]

Bonjour,
J'ai proposé que JOSM soit ajouté au Socle interministériel des logiciels
libres: https://disic.github.io/sill/

Pour que la proposition soit acceptée, il faut un référent: "Tout agent
public travaillant dans un organisme public de la fonction publique d’État
ou hospitalière peut être référent d’un logiciel libre dont il connaît
l’usage au sein de son administration."

C'est expliqué plus en détail ici: https://disic.github.io/sill/#org58fdd0a
Si vous utilisez JOSM, êtes éligible en tant que référent et avez envie de
candidater, il faut se manifester ici:
https://github.com/DISIC/sill/issues/97

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[osm . sanspourriel]

Et la dernière discussion sur le sujet sur le wiki n'a pas d'élément
nouveau depuis 2018 :

https://wiki.openstreetmap.org/wiki/Talk:Tag:natural%3Dbeach#Between_high_and_low_water


Le 05/05/2020 à 14:14, Jean-Yvon Landrac a écrit :


Pas entendu parler d'un tel vote.

Et à lire l'explication

/Adding actual description and fixing rendering examples, clarifying
mapping instructions and removing suggestion to map the tidal part of
beaches with natural=shoal (which is not practically done)/, il aurait
dû juste supprimer "The area between the mean high water spring line
and the low water line could be mapped using {{Tag|natural|shoal}}."

Je doute qu'il existe. Tu le contactes ?

Dans tous les cas tu dois avoir une partie tidal=yes et une partie
sans. Regrouper les deux en une plage, pourquoi pas (c'est assez
logique, quand Castaner aura fini de jouer les pères fouettards et
compris que sur une zone en deux dimensions on respecte plus
facilement la distanciation que sur des allées de parcs), tu pourras à
nouveau constater que la plage n'est pas que la zone non submersible
mais bien le haut et l'estran.

Par contre modifier ex abrupto le wiki...

Le coastline n'était pas non plus un critère absolu, puisque des
zonesnatural=sand, tidal=yes

pouvaient se trouver de part et d'autres. En effet la ligne ne remonte
pas le long des abers, fjords et autres rias. Avec un critère douteux
(ici différent de celui du SHOM qui inclut logiquement le port de
plaisance en amont).

La Plage de l'Aber

dans la presqu'île de Crozon est déjà dans ce cas.

La Plage de Laber

du côté de Roscoff est un point et visiblement coincé entre une
étendue vaseuse (?) et un enrochement il ne fait aucun doute que selon
la définition précédente ce n'était pas une plage selon OSM.

Jean-Yvon

Le 05/05/2020 à 12:54, GarenKreiz - garenkr...@gmail.com a écrit :

Bonjour,

Je viens de m'apercevoir que les règles concernant le positionnement
des surfaces "beach" par rapport au chemin "coastline" ont été
modifiées en février 2019 dans le wiki anglophone (par "imagico"),
modification qui n'a pas encore été répercutée dans le wiki français.

Une plage pourrait être maintenant positionnée sous la ligne de côte
ou même être traversée par elle. Une telle évolution des règles me
semble assez structurante et j'aimerais connaître le processus de
décision : y a-t-il eu un vote? Comment sont tracées ce type de
décisions?

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[GarenKreiz]

Ok, merci pour les éléments. Je vais contacter l'auteur de la modif et
peut-être aussi demander confirmation dans le wiki de discussion sur le tag
"beach".

Et attendre un peu pour faire un "revert" sur les plages en Bretagne Nord
que j'avais modifiées pour respecter les règles OSM!





On Tue, 5 May 2020 at 14:15,  wrote:

> Pas entendu parler d'un tel vote.
>
> Et à lire l'explication
> 
>  *Adding
> actual description and fixing rendering examples, clarifying mapping
> instructions and removing suggestion to map the tidal part of beaches with
> natural=shoal (which is not practically done)*, il aurait dû juste
> supprimer "The area between the mean high water spring line and the low
> water line could be mapped using {{Tag|natural|shoal}}."
>
> Je doute qu'il existe. Tu le contactes ?
>
> Dans tous les cas tu dois avoir une partie tidal=yes et une partie sans.
> Regrouper les deux en une plage, pourquoi pas (c'est assez logique, quand
> Castaner aura fini de jouer les pères fouettards et compris que sur une
> zone en deux dimensions on respecte plus facilement la distanciation que
> sur des allées de parcs), tu pourras à nouveau constater que la plage n'est
> pas que la zone non submersible mais bien le haut et l'estran.
>
> Par contre modifier ex abrupto le wiki...
>
> Le coastline n'était pas non plus un critère absolu, puisque des zones
> natural=sand, tidal=yes
> 
> pouvaient se trouver de part et d'autres. En effet la ligne ne remonte pas
> le long des abers, fjords et autres rias. Avec un critère douteux (ici
> différent de celui du SHOM qui inclut logiquement le port de plaisance en
> amont).
>
> La Plage de l'Aber
>  dans
> la presqu'île de Crozon est déjà dans ce cas.
>
> La Plage de Laber
> 
> du côté de Roscoff est un point et visiblement coincé entre une étendue
> vaseuse (?) et un enrochement il ne fait aucun doute que selon la
> définition précédente ce n'était pas une plage selon OSM.
>
> Jean-Yvon
> Le 05/05/2020 à 12:54, GarenKreiz - garenkr...@gmail.com a écrit :
>
> Bonjour,
>
> Je viens de m'apercevoir que les règles concernant le positionnement des
> surfaces "beach" par rapport au chemin "coastline" ont été modifiées en
> février 2019 dans le wiki anglophone (par "imagico"), modification qui n'a
> pas encore été répercutée dans le wiki français.
>
> Une plage pourrait être maintenant positionnée sous la ligne de côte ou
> même être traversée par elle. Une telle évolution des règles me semble
> assez structurante et j'aimerais connaître le processus de décision : y
> a-t-il eu un vote? Comment sont tracées ce type de décisions?
>
> Cordialement
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Public Rights of Way - legal vs reality

[Martin Wynne]

Is a "public right of way" a highway?

I suggest not. It's a legal construct, similar to a boundary line.

Perhaps it should be mapped as a separate way, sometimes sharing nodes 
with a physical highway, sometimes not.


Martin.

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

Re: [OSM-talk-fr] questions de "pilotage" ou de "domination"

[Yves P.]

Bonjour,

J'ai oublié de copier le passage qui fait le lien entre mon message et celui de 
Jean-Guilhem Cailton :

https://wiki.openstreetmap.org/wiki/User:Jgc/TraductionJournalConsultationsApm-wa#.28Quatri.C3.A8me_place_ex_aequo.29_Diversit.C3.A9.2Finclusion

> De nombreuses personnes interrogées se sont plaintes des questions de 
> "pilotage" ou de "domination" des intérêts particuliers au détriment des 
> intérêts plus larges de la communauté des OSM. Comme l'a dit l'un d'entre 
> eux, "Si vous laissez les grandes gueules diriger la stratégie, rien ne se 
> passera". Un autre l'a formulé différemment : "L'utilisation du projet est 
> mise en péril par quelques voix fortes".

En espérant que ça vous aidera à comprendre mieux mon propos :)

> Le 04.05.20 à 20:45, Florimond Berthoux a écrit :
>> Perso les gens qui me demande quelque chose en disant aussitôt merci 
>> ça a le don de particulièrement m'agacer.
>> Pourquoi ? Parce que c'est retirer la liberté de faire ou de ne pas
>> faire à celui qui reçoit la demande.
> 
> je pense que c'est très variable selon la personne qui l'écrit
> ou le recoit. pour d'autre, c'est une expression de gratitude
> envers le gars qui va passer du temps à cela.
+1

Un autre facteur, je n'ai pas fais mes études à Oxford et ne maitrise donc pas 
les subtilités de la langue anglaise à l'écrit ;)

> il y a plus qu'une personne :)
Tom ou Allan ?

En tout cas, que les choix sur le devenir du site web OSM ne repose que sur les 
épaules d'une (ou deux) personne(s) est un problème :/
Si en plus ce sont des "grandes gueules" ça ne permettra encore moins d'avancer 
:(

> TomH *parait* souvent très sec (moi aussi m'a-t-on fait remarquer).
> c'est toujours difficile de suposer l'intention de l'autre.
> Quand je réponds d'apparence "sec", c'est parfois sinplement
> parce que je vois pas l'utilité de répondre à un message utilitaire
> en y mettant 2 tonnes d'emballage. genre si on demande le tag pour tel
> truc, je répond ce qui me parait être le tag pour tel truc. si on
> demande si c'est utile, je répond mon avis sur l'utilité.
> ca dit pas que j'ai la science infuse ou que la discussion est
> refusée, c'est juste un avis :) mon avis :)

> Le 04.05.20 à 20:45, Florimond Berthoux a écrit :
> Et justement il dit qu'il est contre, normal qu'il t’envoie bouler.

Le problème n'est pas de donner son avis, le problème est la bonne fois.

Comme l'a fait remarquer eehpcm (issuecomment-623478783 
),
 Tom utilise des arguments fallacieux (Slippery-slope arguments 
).

Cette discussion n'est que le sommet de l'iceberg…

> 
>>
>> https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-623479719
> 
> perso je lis la première ligne et je m'arrête. une ref qui n'est avec
> ref, c'est une erreur de tag même si c'est la pratique courante pour
> cette ref. idem avec CLC:id par ex
> personne
On peut discuter de la forme originale de cette clé (il serait en effet plus 
logique que ce soit ref:openplaques).

Mais la question n'est pas là. Cette clé existe, elle répond au besoin des 
"historiens" et autre "amateurs" de patrimoine.

Et au-delà de cette clé, il en existe d'autres qui pourraient bénéficier d'un 
lien.

> de plus les 2 messages précédents explicants les 2 raisons ne semblent
> pas prise en considération, donc fatalement le gars répond pas très
> positivement si on lui répond sans tenir compte de ce qu'il répond.
J'ai relu la "discussion", Tom n'argumente pas : c'est son avis, son 
"jugement", point barre.

Si il est seul à décider de ce qui est bien ou mal pour OSM me dérange vraiment.
Les projets informatiques ont souvent besoin de "dictateurs" bienveillants. Ici 
je ne voit pas la bienveillance :(

>  même si le code était écrit, je serrais tenté par passer
> mon temps à lire un autre ticket plutôt qu'encourager cette clef :)
Encore une fois, est-ce a une ou 2 personnes de décider des clés à encourager 
ou pas ?

https://github.com/openstreetmap/openstreetmap-website/issues/2405#issuecomment-623479719
> If somebody else wants to offer a PR to do it then that can be considered 
> when it happens. Until then this issue is just so much hot air.

Ecrire une PR dans un gros projet comme celui-ci nécessite beaucoup de 
prérequis.
Maitriser l'anglais est utile (cf ma remarque plus haut),
Se former au langage,
Au projet,
A l'environnement de développement pour réussir à tester et débogguer son code 
en local,
A GitHub,
A l'aspect social dans GitHub…

Ça fait beaucoup d'énergie dépenser pour se faire insulter.
Et même en arrivant à faire une PR propre du premier coup, il faut allumer des 
cierges pour espérer l'accord du "dictateur" (le merge de la PR).

__
Yves



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

Re: [OSM-talk-fr] Workflow pour opendata

[Nicolas Bétheuil]

En local j'ai un postgres dans un docker. Sur une plateforme comme clever
cloud ou scalingo ce sera une application d'API node et un frontale. Il y a
un point d'entrée d'api qui permet de téléverser le geojson et qui fait
l'ajout en base (un post multipart sur /quests
https://github.com/wadouk/od2osm/blob/363351488d06a2194e0975a15143fd3e841932e5/server.js#L81)
qui recharge l'ensemble des points.

Tu m'avais causé d'open refine. Il fallait scripter pour aller plus loin
pour un outil juste en local. Je trouve le coup d'entrée par contributeur
un peu élevé pour un jeu de données évoluant. En regardant map roulette
j'ai vu qu'il fallait lui expliquer si c'était un ajout ou une modification
du coup compliqué aussi : charger les données spatiales et faire les diff.
Là l'idée est de faire des étapes plus petites, plus itératif.

Le mar. 5 mai 2020 à 13:27, Yves P.  a écrit :

> Bonjour,
>
> L'idée est de passer sur chaque point, de faire une requête overpass pour
> trouver un point "proche" et "similaire" et de créer ou fusionner les
> informations.
> L'outil stockera les points déjà rapprochés pour ne pas les re proposer
> par défaut.
>
>
> J'ai jeté un oeil rapide.
>
> Ton outil utilise une base postgresql dans un conteneur Docker.
> Comment sont chargées les données ?
>
>
> Pour info, j'ai bricolé un outil similaire avec OpenRefine (il n'y a que
> ce soft à installé et c'est facile).
> Une "formule" dans une colonne permet de lancer une requête overpass pour
> chaque POI.
>
> Je n'ai pas été plus loin, mais il existe un système de "réconciliation"
> avec comme source de données Wikidata… mais aussi n'importe quel point de
> connection SPARQL.
> Ça vaut la peine d'essayer avec celui d'OSM (Sophox)
>
> Par rapport à Omose ou ton outil, ça ne tourne qu'en local.
>
> Par contre il est facile de partager les "recettes" et les données pour
> réaliser une intégration à plusieurs contributeurs.
>
> __
> Yves
>
> PS: OpenRefine semble être beaucoup utilisé par les bibliothécaires ;)
> ___
> 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: [Talk-it] [Import] civici Bergamo Re: Digest di Talk-it, Volume 162, Numero 22

[Lorenzo Stucchi]

Ciao,

Come dice giustamente Andrea il tag è errato. L’utente è già stato contattato 
da Cascafico per correggere il tag.

Ciao,
Lorenzo Stucchi

Il giorno 5 mag 2020, alle ore 13:37, Andrea Musuruane 
mailto:musur...@gmail.com>> ha scritto:

Ciao,

On Tue, May 5, 2020 at 1:23 PM cxc mailto:t49...@gmail.com>> 
wrote:
Non entro in merito alle licenze. Ho notavo che i nomi delle strade indicate 
sono inseriti con tag addr:housename e vengono renderizzati da osm.
https://www.openstreetmap.org/#map=19/45.68988/9.66001

Ovviamente è errato e bisogna usare addr:street.

Ciao,

Andrea

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

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[osm . sanspourriel]

Pas entendu parler d'un tel vote.

Et à lire l'explication

/Adding actual description and fixing rendering examples, clarifying
mapping instructions and removing suggestion to map the tidal part of
beaches with natural=shoal (which is not practically done)/, il aurait
dû juste supprimer "The area between the mean high water spring line and
the low water line could be mapped using {{Tag|natural|shoal}}."

Je doute qu'il existe. Tu le contactes ?

Dans tous les cas tu dois avoir une partie tidal=yes et une partie sans.
Regrouper les deux en une plage, pourquoi pas (c'est assez logique,
quand Castaner aura fini de jouer les pères fouettards et compris que
sur une zone en deux dimensions on respecte plus facilement la
distanciation que sur des allées de parcs), tu pourras à nouveau
constater que la plage n'est pas que la zone non submersible mais bien
le haut et l'estran.

Par contre modifier ex abrupto le wiki...

Le coastline n'était pas non plus un critère absolu, puisque des
zonesnatural=sand, tidal=yes

pouvaient se trouver de part et d'autres. En effet la ligne ne remonte
pas le long des abers, fjords et autres rias. Avec un critère douteux
(ici différent de celui du SHOM qui inclut logiquement le port de
plaisance en amont).

La Plage de l'Aber

dans la presqu'île de Crozon est déjà dans ce cas.

La Plage de Laber

du côté de Roscoff est un point et visiblement coincé entre une étendue
vaseuse (?) et un enrochement il ne fait aucun doute que selon la
définition précédente ce n'était pas une plage selon OSM.

Jean-Yvon

Le 05/05/2020 à 12:54, GarenKreiz - garenkr...@gmail.com a écrit :

Bonjour,

Je viens de m'apercevoir que les règles concernant le positionnement
des surfaces "beach" par rapport au chemin "coastline" ont été
modifiées en février 2019 dans le wiki anglophone (par "imagico"),
modification qui n'a pas encore été répercutée dans le wiki français.

Une plage pourrait être maintenant positionnée sous la ligne de côte
ou même être traversée par elle. Une telle évolution des règles me
semble assez structurante et j'aimerais connaître le processus de
décision : y a-t-il eu un vote? Comment sont tracées ce type de décisions?

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

Re: [OSM-talk-fr] Workflow pour opendata

[Nicolas Bétheuil]

En fait je vois 2 étapes dans cette première étape : convertir le jeu de
données en données compatible OSM (coordonnées et tags) puis envoyer ce jeu
de données pour qualification / trie / fusion.
od2osm ne convertie pas, il va attendre que ce travail soit déjà fait.
lui donner pour qu'il puisse aider les contributeurs, plus dans son
périmétre effectivement.

Le mar. 5 mai 2020 à 12:24, Magalie Dartus  a écrit :

> Bonjour,
>
> Pour l'instant juste en local, mais plus tard je publierais et peut être
>> même héberger si vous trouvez ça intéressant.
>> Ça demande à s'étoffer mais si ça vous parle ou si vous êtes curieux.
>>
>
>
> Très intéressée par ce genre d'outil car je travaille régulièrement sur
> l'ouverture de fichier (cf la discussion sur les bibliothèques), j'essaie
> de faire en sorte que les fichiers soient compatibles avec OSM (sinon je
> peux les retraiter à posteriori).
> N'étant qu'une simple humaine :-D je n'ai toujours pas acquis la
> compétence "charger le fichier open data dans osmose".
>
> Est-ce que l'outil od2osm permet de réaliser cette première étape?
>
> Merci
> Magalie
>
>
> Le mar. 5 mai 2020 à 12:10, Marc M.  a écrit :
>
>> Bonjour,
>>
>> Comment ton outil se compare avec osmose ?
>>
>> par ailleurs, les magasin dans osm peuvent aussi être des polygones,
>> dans la requête overpass, il suffit de changer node en nwr
>>
>> Cordialement,
>> Marc
>>
>> Le 05.05.20 à 11:42, Nicolas Bétheuil a écrit :
>> > Bonjour,
>> >
>> > Trouvant le taf un peu laborieux et la source de données grossissant
>> > (800 points il y a quelques jours) je me suis lancé dans un outil pour
>> > aider l'humain (en bon informaticien plutôt que faire le taf en 3j, ça
>> > fait longtemps que je joue à ça).
>> >
>> > L'idée est de passer sur chaque point, de faire une requête overpass
>> > pour trouver un point "proche" et "similaire" et de créer ou fusionner
>> > les informations.
>> > L'outil stockera les points déjà rapprochés pour ne pas les re proposer
>> > par défaut.
>> >
>> > Pour l'instant juste en local, mais plus tard je publierais et peut être
>> > même héberger si vous trouvez ça intéressant.
>> > Ça demande à s'étoffer mais si ça vous parle ou si vous êtes curieux.
>> >
>> > https://github.com/wadouk/od2osm
>> >
>> > Bon, j'aurais sûrement pas fini pour la fin du confinement (le jeu de
>> > données est sur les commerces qui livrent pendant le confinement) mais
>> > bon, ça fait quand même des infos sur des commerces.
>> > Je charge un geojson retraité
>> >
>> https://github.com/wadouk/opendata-paris-commerces-ouvert-covid19-vers-osm
>> >
>>
>>
>>
>> ___
>> 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: [Talk-GB] Public Rights of Way - legal vs reality

[Adam Snape]

Hi,

Highway=no seems acceptable to me where a path is permanently physically
blocked by a building or such-like. We're not serving anyone by directing
people into wals. I do, however, disagree with its use to tag definitive
rights of way which are useable but which merely deviate from the route a
mapper mapped on the ground. Eg. I don't think a highway=no tag should be
added to a cross field definitive footpath just because a path round the
field has been mapped.

Kind regards,

Adam


On Tue, 5 May 2020, 12:35 Andy Townsend,  wrote:

> On 05/05/2020 11:53, Adam Snape wrote:
> > Hi Tom,
> >
> > I'd consider this particular proposed use of highway=no to mean "there
> > is a public highway here but there's no visible path on the ground" to
> > be a somewhat country-specific and counter-intuitive tagging practice.
> > It's certainly being suggested here as a solution to a
> > country-specific issue regarding the mapping of England and Wales'
> > rights of way network.
>
> For the avoidance of doubt, we already have "trail_visibility" as a
> useful tag here.  It's well used worldwide
> https://taginfo.openstreetmap.org/keys/trail_visibility#values and in
> the UK https://taginfo.openstreetmap.org.uk/keys/trail_visibility#values
> and I (at least) use it to decide whether to render a path or not.
>
> That said, I'd be reluctant to use any other highway tag other than "no"
> when there is a legal right of way but (say) someone's built a house
> there so there is no physical access.  By all means add
> "designation=public_footpath" (with some sort of note) but please not
> "highway=footway" (my apologies if no-one was suggesting this - it
> wasn't 100% clear in the conversation).
>
> Personally I'd tend to just omit the highway tag for cases like this.  I
> wouldn't personally have a problem with people using "highway=no" for
> them but I take Andy Allan's point earlier, and he has far more
> experience dealing with how data consumers misuse OSM tags than I.
>
> On the "country specific" bit England and Wales are pretty unique with
> their "public footpaths" etc.  More civilised countries (like Scotland)
> have something like "allemansrätten" in law. :)
>
> Best Regards,
>
> Andy
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Workflow pour opendata

[Nicolas Bétheuil]

Je ne voyais pas comment faire mon analyse osmose avec des fois des shop,
des fois amenity, des fois autre chose. Trop de typologie différentes.

Plutôt que partir sur une analyse en python qui se base sur une région,
l'idée est de faire un pré formatage en geojson (dans le langage de son
choix, même un simple tableur) qui rapproche le format de la donnée vers
les tags OSM (voir
https://github.com/wadouk/opendata-paris-commerces-ouvert-covid19-vers-osm)
et de téléverser le fichier résultat dans od2osm (upload sur une api). On a
donc des Features geojson avec des coordonnée et des tags. Comparer les
tags des points existants avec ceux de l'open data pour avoir une vue en
diff (un plus pour les tags ajoutées, un moins pour les tags enlevés, en
tilde ~ pour les tags modifiés)
Charge au contributeur de dire si le rapprochement est correct ou si c'est
faux et rajouter le point ou de passer ce rapprochement s'il ne comprends
pas.
Pas d'analyse géospatiale pour toute une région alors que l'on veut juste
quelques point à 20m aux alentours.

Gérer les polygones plutôt que juste les points viendra plus tard.
Interroger overpass n'est pas le plus compliqué mais mettre à jour OSM va
être une première étape, et peut être que je vais me rendre compte que ce
sera simple.

Le mar. 5 mai 2020 à 12:08, Marc M.  a écrit :

> Bonjour,
>
> Comment ton outil se compare avec osmose ?
>
> par ailleurs, les magasin dans osm peuvent aussi être des polygones,
> dans la requête overpass, il suffit de changer node en nwr
>
> Cordialement,
> Marc
>
> Le 05.05.20 à 11:42, Nicolas Bétheuil a écrit :
> > Bonjour,
> >
> > Trouvant le taf un peu laborieux et la source de données grossissant
> > (800 points il y a quelques jours) je me suis lancé dans un outil pour
> > aider l'humain (en bon informaticien plutôt que faire le taf en 3j, ça
> > fait longtemps que je joue à ça).
> >
> > L'idée est de passer sur chaque point, de faire une requête overpass
> > pour trouver un point "proche" et "similaire" et de créer ou fusionner
> > les informations.
> > L'outil stockera les points déjà rapprochés pour ne pas les re proposer
> > par défaut.
> >
> > Pour l'instant juste en local, mais plus tard je publierais et peut être
> > même héberger si vous trouvez ça intéressant.
> > Ça demande à s'étoffer mais si ça vous parle ou si vous êtes curieux.
> >
> > https://github.com/wadouk/od2osm
> >
> > Bon, j'aurais sûrement pas fini pour la fin du confinement (le jeu de
> > données est sur les commerces qui livrent pendant le confinement) mais
> > bon, ça fait quand même des infos sur des commerces.
> > Je charge un geojson retraité
> >
> https://github.com/wadouk/opendata-paris-commerces-ouvert-covid19-vers-osm
> >
>
>
>
> ___
> 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: [Talk-hr] Kucni brojevi

[hbogner]

On 02. 05. 2020. 13:55, Janko Mihelić wrote:

On Fri, May 1, 2020, 03:37 Matija Nalis 
wrote:



Slabo mapiram broj katova uopce (jer ga najcescen niti ne znam, a i
nije mi prioritetan), osim eventualno na terenu sa StreetComplete,
ali onda on to sam odradi na koji god nacin odradi :)

Kako uopce oznacavas katove ako je jedna gradjevina sa vise katova?
Ili ne mozes oznaciti katove, ili moras rasjeci u dvije gradjevine?
Ili nesto trece?



Označavaš maksimalan broj katova u cijeloj zgradi, a onda ako se baš
zainatiš, ucrtaš building:part=yes unutra, i njemu daš pravi broj za taj
dio.


Vidiš to nisam znao, za building:part=yes.

čekaj da onda vidite kako izgleda katastar, on nema podatke za visine i 
to ne označava, već samo tolocrte, ali za terase, zgrade, stepenice, 
..., neznam što sve već ne, ima posebne slojeve...


Mislim da smo malo ispremješali teme, kućne brojeve, mapiranje zgrada i 
kako mapirati zgrade.



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

Re: [Talk-hr] Mapiranje svih gradjevina u RH

[hbogner]

On 02. 05. 2020. 13:46, Janko Mihelić wrote:

On Fri, May 1, 2020, 11:37  wrote:


Imamo li digitalni layer katastarskih cestica odnosno gradevina od drzavne
uprave? Ja bih krenuo u mapiranje toga kad to bude bilo dostupno. Sve
ostalo nije bas previse tocno.

Sto se tice adresa, ustaljena praksa u drugim drzavama je ulaz (su ulazi)
u zgradu tocno na liniji zgrade prema cesti (vidi npr Beč).



Ima li smisla ucrtavati, o tome bi se dalo pričati. Ako digitalni layer
dobijemo za 5 godina, to znači da ćemo toliko vremena biti bez
koliko-toliko okej građevina. Nitko se neće tjerati da ucrtava. Jedino ako
ima neki pametniji posao koji bi bio korisniji ili lakši pa da na to
usmjerimo snage.

Što se adresa tiče, moj pristup je bio da se (a slično sam čitao na glavnoj
tagging mailing listi), kad god je moguće, cijela zgrada označi sa adresom.
Na taj način ako stavimo POI u zgradu, on bi u nekim pametnijim geokoderima
mogao preuzeti adresu zgrade oko njega (ako već nema adresu). Također, ako
se ucrta 5 ulaza u neku veliku zgradu, onda bi ruter mogao rutati u
najbliži ulaz od zgrade sa tom adresom.

Ako svaki ulaz neke zgrade ima drugu adresu, onda sam za pristup adrese na
ulazima.

Inače nisam protiv toga da se adresa mapira više puta, dakle ako se mapira
na zgradi i na ulazu, ne vidim problem.

Malo je zeznuto u slučaju industrijskog dvorišta koje ima jednu adresu.
Možeš adresu staviti na ulaznu kapiju, ulaznu recepciju, na upravnu zgradu,
na cijelo zemljište.. Po meni je sve to okej, ako ih se adresira nekoliko,
sve je ispravno. Ali opet, ako se stavi adresa na cijelo zemljište, pametni
geokoder bi mogao dodijeliti svima unutra tu adresu.

Janko



Ima smisla, to i je smisao OSM-a. Odradi ono što možeš s onim što imaš, 
a kasnije se to nadograđuje. Ako čekamo ostvaranje državnih podataka 
možemo odmah prestai sve što radimo, gasimo sve i čekamo da to netko 
drugi odradi umjesto nas.


Ja sam do sad preferirao POI unutar građevine, ili POI na ulazu koji je 
označen kao ulaz i kao kućni broj.



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

Re: [Talk-hr] Mapiranje svih gradjevina u RH

[hbogner]

On 01. 05. 2020. 11:37, 
martinswo...@gmail.com wrote:

Imamo li digitalni layer katastarskih cestica odnosno gradevina od drzavne 
uprave? Ja bih krenuo u mapiranje toga kad to bude bilo dostupno. Sve ostalo 
nije bas previse tocno.

Sto se tice adresa, ustaljena praksa u drugim drzavama je ulaz (su ulazi) u 
zgradu tocno na liniji zgrade prema cesti (vidi npr Beč).


Sloj katastra sa građevinama postoji, ali je on samo za registirane 
korisnike, i on se naplaćuje koliko se sjećam. Znam da smo za geodetske 
potrebe plaćali određeni iznos za svaku katastarsku česticu...


Kolega je pokušao dobiti Registar prostornih jedinica za korištenje i 
odbijen je, koliko bi samo trebali čekati za katastar...


Bolje je iskoristiti potojeći DOF i buduće koji su naručeni(pratim 
njihove objave) te na njima raditi.


Bolje grška od metar-dva nego ono što smo dobili kad je Venko samo 
copy/paste zgrade okolo jer ne želi imati praznu kartu:

https://www.dropbox.com/s/158ygs94cjj3dsn/osm-Venko1.png
https://www.dropbox.com/s/6ys12pizpsvfs9f/osm-venko2.png

Ako ikad dobijemo katastar i građevine možemo iskoristiti iskustvo koje 
bi trebali dobiti sa obradom Zagrebačkih vektora...



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