Re: [Talk-it] Via Abarth Torino

[Marco]

Ciao, dovrebbe essere il tratto di via Anselmetti, tra la rotonda di via Plava 
e l'incrocio con corso Orbassano

http://www.comune.torino.it/ucstampa/comunicati/article_717.shtml

On October 25, 2019 10:01:21 AM GMT+02:00, Gianluca Boero 
 wrote:
>Avevo già letto anche io della notizia su altre fonti.
>
>Non so in che punto è della circoscrizione di Mirafiori.
>
>Per mapparla correttamente bisogna visionare il luogo. Ci passo 
>raramente da quelle parti e ora con il blocco del traffico ancora di 
>meno. Spero che qualche mappatore di Torino città provveda a inserirla.
>
>
>Il 24/10/19 22:43, Lorenzo Rolla ha scritto:
>> Buonasera, non volendo creare problemi sulle mappe, segnalo che è 
>> stata dedicata una via a Carlo Abarth (costruttore auto sportive). Un
>
>> cordiale saluto.
>>
>> https://www.fcaheritage.com/it-it/heritage/eventi/via-carlo-abarth
>>
>> -- 
>> Lorenzo Rolla
>>
>>
>> ___
>> 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] Mappare una scuola due

[claudio62PG]

Ho questa proposta

Istituto comprensivo
office=educational_institution
ref=numcodice IC
Name=nome IC

Scuola ordinaria
amenity=school
name=nome scuola
ref= codice scuola
operator=nome IC

Rimangono fuori 
le succursali cioè scuole che risiedono su edifici diversi e distanti fra
loro (anche qualche chilometro)
che non hanno un proprio codice 
ciao
Claudio 



--
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-GB] Zebra crossings being lost in iD - how to respond

[Dave F via Talk-GB]

On 25/10/2019 12:04, Andy Townsend wrote:

On 25/10/2019 11:43, Jez Nicholson wrote:

+1 for a bot edit


Perhaps Maproulette would be a better option?  Zebra markings would 
often be visible on aerial imagery, and a comparison of newer vs older 
imagery might allow people to identify recent changes*.


crossing=marked as a solo sub-tag should also be verified

* Somewhat offtopic, with almost all of the wood/forest edits I've 
been doing recently I've used surveys to confirm which imagery is 
latest (and around 
https://www.openstreetmap.org/#map=13/54.2593/-1.2397 it's Maxar 
Premium), but using Bing for extra clarity and better alignment, and 
also using OS OpenData waterway and road centreline data for alignment.


I've found that not only location, but editor can affect the quality of 
aerial imagery. I find it frustrating Bing is displayed at the same high 
zoom levels as others in Potlatch.


General:
I've updated crossing=zebra to crossing=uncontrolled where 
crossing_ref=zebra exists (OP+JOSM, 220 objects). I used uncontrolled as 
it's much more popular than 'marked'


DaveF



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

Re: [Talk-ca] [OpenStreetMap] Revision de l'attribut lcn=yes pour le Québec

[Alouette955]

Bonjour,

Juste pour ne pas être mal interprété je cite ici mon introduction:

“La discussion n’est peut-être pas terminée mais advenant qu’on y aille 
d’un projet il y a deux avenues possibles.”

Il n’y a pas encore consensus mais quelques pour et quelques contre.

Heureux par contre que ça ait réveillé le sujet.

Claude

From: Marc-André Miron 
Sent: Friday, October 25, 2019 3:57 PM
To: talk-ca@openstreetmap.org 
Subject: [Talk-ca] [OpenStreetMap] Revision de l'attribut lcn=yes pour le Québec

J'aimerais signaler que le sujet s'est dédoublé:

Pertinence de lcn=yes pour le Québec a commencé ici:

https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009459.html  


Et son dernier échange se trouve ici:

https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009473.html  

Claude semble interpréter que le sujet soit clos et passer à la suppression de 
la balise lcn, mais ces interventions précédentes sont pourtant restées lettres 
mortes.

Pour rappel, nous sommes plusieurs à ne pas être convaincu de l'inutilité de 
"lcn=yes", sans que cela empêche un développement des relations de pistes dont 
les libellés sont disponibles. Autrement dit, pourquoi jeter le bébé avec l'eau 
du bain? Les deux ne peuvent-ils pas coexister?

En particulier, nous avons souligné que les dénominations de réseaux locaux 
sont soutenus par la documentation précise des villes et arrondissements, ont 
des éléments physiques qui leur correspondent et que la distinction des réseaux 
locaux versus régionaux ainsi que de l'ensemble d'un réseau lcn et des pistes 
qui le traversent peuvent avoir leur utilité.

J'aimerais aussi remarquer que l'utilité d'une balise dépasse les 
interprétations des différents moteurs de rendu. J'ai l'impression qu'il y a 
confusion sur ce point et qu'on s'évite ce questionnement en se disant que 
l'utilité repose sur la présentation particulière ou judicieuse de la balise 
dans un moteur de rendu particulier. De façon plus générale, la balise contient 
une information géographique réelle, documentée et pertinente. Par exemple, 
dans l'usage de Pierre:

"Pour moi lcn=yes me permet en un clin d'oeil davoir une vue d'ensemble sur le 
réseau cyclable de toutes ces municipalités incluant les chemins dit 
"designated, yes, permissive, etc." comme cycleway=designated par exemple qui 
n'apparait pas sur la carte sans l'utilisation de lcn=yes."

L'intérêt de baliser le réseau local du reste transcende l'implémentation d'un 
rendu quelconque. Autre cas de figure: celui où un citoyen ou un arrondissement 
souhaite sélectionner les éléments de la base de donnée qui correspondent au 
réseau local pour étudier quelconque donnée pouvant être ou non corrélée à la 
balise et croiser celles-ci avec le taux géographique d'accidents, à tout 
exemple.

Ma suggestion est donc d'implémenter les relations mais de laisser les balises 
lcn, puisqu'elles constituent toutes deux des éléments géographiques pertinents 
d'usages différents. Il serait également dommage de procéder à la suppression 
de ces données pertinentes, implémentées manuellement, par manque de créativité 
d'usages potentiels.

Marc-André






 Virus-free. www.avg.com  




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

Re: [Talk-ca] [OpenStreetMap] Revision de l'attribut lcn=yes pour le Québec

[stevea]

Merci Marc-André pour votre excellent exposé sur les raisons pour lesquelles 
nous devrions taguer lcn=yes (j’applique rcn ou ncn, le cas échéant).

En effet, la Route Verte est à la fois étiquetée network = ncn et rcn = yes (à 
certains endroits), ce qui indique que cette route est "aux" niveaux régional 
et national (mais que l’étiquette de réseau ne peut pas contenir deux valeurs 
simultanées). transmet correctement la sémantique.

Nous POUVONS (mais ne devrions pas) attribuer une balise pour le rendu, nous 
DEVRAIONS étiqueter "ce qui est" et "ce que nous savons être vrais", aussi bien 
que les balises de OSM peuvent en tenir compte.  Plusieurs balises OSM 
orientées cycle peuvent, devraient et doivent coexister.

(S'il te plaît, pardonne à mon écolier français, je fais de mon mieux).

SteveA
Californie
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] [OpenStreetMap] Revision de l'attribut lcn=yes pour le Québec

[Marc-André Miron]

J'aimerais signaler que le sujet s'est dédoublé:

Pertinence de lcn=yes pour le Québec a commencé ici:

https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009459.html

Et son dernier échange se trouve ici:

https://lists.openstreetmap.org/pipermail/talk-ca/2019-October/009473.html

Claude semble interpréter que le sujet soit clos et passer à la suppression
de la balise lcn, mais ces interventions précédentes sont pourtant restées
lettres mortes.

Pour rappel, nous sommes plusieurs à ne pas être convaincu de l'inutilité
de "lcn=yes", sans que cela empêche un développement des relations de
pistes dont les libellés sont disponibles. Autrement dit, pourquoi jeter le
bébé avec l'eau du bain? Les deux ne peuvent-ils pas coexister?

En particulier, nous avons souligné que les dénominations de réseaux locaux
sont soutenus par la documentation précise des villes et arrondissements,
ont des éléments physiques qui leur correspondent et que la distinction des
réseaux locaux versus régionaux ainsi que de l'ensemble d'un réseau lcn et
des pistes qui le traversent peuvent avoir leur utilité.

J'aimerais aussi remarquer que l'utilité d'une balise dépasse les
interprétations des différents moteurs de rendu. J'ai l'impression qu'il y
a confusion sur ce point et qu'on s'évite ce questionnement en se disant
que l'utilité repose sur la présentation particulière ou judicieuse de la
balise dans un moteur de rendu particulier. De façon plus générale, la
balise contient une information géographique réelle, documentée et
pertinente. Par exemple, dans l'usage de Pierre:

"Pour moi lcn=yes me permet en un clin d'oeil davoir une vue d'ensemble sur
le réseau cyclable de toutes ces municipalités incluant les chemins dit
"designated, yes, permissive, etc." comme cycleway=designated par exemple
qui n'apparait pas sur la carte sans l'utilisation de lcn=yes."

L'intérêt de baliser le réseau local du reste transcende l'implémentation
d'un rendu quelconque. Autre cas de figure: celui où un citoyen ou un
arrondissement souhaite sélectionner les éléments de la base de donnée qui
correspondent au réseau local pour étudier quelconque donnée pouvant être
ou non corrélée à la balise et croiser celles-ci avec le taux géographique
d'accidents, à tout exemple.

Ma suggestion est donc d'implémenter les relations mais de laisser les
balises lcn, puisqu'elles constituent toutes deux des éléments
géographiques pertinents d'usages différents. Il serait également dommage
de procéder à la suppression de ces données pertinentes, implémentées
manuellement, par manque de créativité d'usages potentiels.

Marc-André
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk] FOSS4G SOTM Oceania 2019 - November 12-15, 2019

[Suchith Anand via talk]

 I wish to send my greetings to FOSS4G and OpenStreetMap communities of 
Australia, New Zealand, and Pacific Islands who are gathering for FOSS4G SotM 
Oceania in Wellington during November 12-15, 2019 . This is a great opportunity 
for knowledge sharing on open source geospatial technology & open data. Details 
athttps://2019.foss4g-oceania.org



In 2018, The University of Melbourne, home to Australia’s first Open Source 
Geospatial Laboratory [1] hosted FOSS4G SotM Oceania [2]. FOSS4G SotM Oceania 
2019 will help further expand geoeducation and digital economy opportunities to 
the region. The videos from FOSS4G SotM Oceania 2018 are 
athttps://www.youtube.com/channel/UCbqmnF77HxLCmO9d7LrEbpg/videos


GeoForAll [3] is a simple idea powered by a global community who are all 
working for a selfless aim on providing Open Education opportunities for all. 
Openness is fundamental in harnessing the true potential of Geospatial Science 
and expanding digital economy opportunities for all.





Best wishes,




Suchith










[1]http://spatial.unimelb.edu.au/engagement/ica-osgeo-laboratory/ 


[2]https://2018.foss4g-oceania.org



[3] https://www.osgeo.org/initiatives/geo-for-all/



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

[OSM-ja] 11/10 京都！街歩き！マッピングパーティ：第14回 鍬山神社

[yasunari yamashita]

京都！街歩き！マッピングパーティ世話役の山下です。
皆さんこんにちわ。

京都を街歩きして、楽しみながら 自由な地図である OpenStreetMap を創り上げていくマッピングパーティ！

11 月の京都！街歩き！マッピングパーティは、
丹波国桑田郡十九座の内の一社で創祀1300年を迎える古社 鍬山神社
紅葉がきれいにみられるかもしれません


イベントの詳細と参加申し込みは connpass にて
https://openstreetmap-kyoto.connpass.com/event/152674/

皆様の参加をお待ちしています！
-- 
山下康成＠京都府向日市
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] annonce des modifs importantes des données

[Cyrille37 OSM]

Le 25/10/2019 à 18:30, osm.sanspourr...@spamgourmet.com a écrit :


Version courte : KISS, une page sur le wiki. S'y abonne qui veut.

Et annonce sur talk-fr@, pour savoir que la page existe et que l'on peut 
s'y abonner.


Cyrille37.



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

Re: [OSM-talk-fr] annonce des modifs importantes des données [était: Osmose et les mauvais noms de communes]

[osm . sanspourriel]

Version courte : KISS, une page sur le wiki. S'y abonne qui veut.

Version longue : s'il y a des consommateurs autistes, s'ils subissent
des modifications de schéma c'est un peu leur problème.
On est une communauté ouverte, on centralise je dirais les propositions
de modification (lien vers le fil de discussion sur talk-fr) puis la
date de mise en œuvre si la modification est acceptée.

Au pire juste avant cette date ils cessent les mise-à-jour pour rester
sur un modèle compatible avec le leur.

Pourquoi s'imposer des dates ? Je ne vois pas ce que ça apporte.

Soit le consommateur-autiste s'abonne au wiki, voit le fil de discussion
et discute d'un délai (le cas échéant c-à-d s'il a besoin d'un certain
temps pour se retourner).

Soit il est vraiment autiste. La prochaine fois il comprendra ;-).

Jean-Yvon


Le 25/10/2019 à 17:18, marc marc - marc_marc_...@hotmail.com a écrit :

version courte :
on commence par une page wiki annonce-fr ?
notification par email possible.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-es] Modelos 3d en OSM via Kendzi3D

[yo paseopor]

¡Buenas! Para empezar necesitaría más datos. ¿Qué modelo? ¿Dónde? ¿Qué nodo
has usado? ¿Qué XML has usado? ¿Dónde lo has colgado? ¿Como está
configurada tu biblioteca? ¿Qué modelo pretendes proyectar? ¿Cómo está
orientado? ¿Qué sistema usas? ¿qué programas usas?

Sabiendo esto será más fácil ayudarte.
Salut i models 3D ;)
yopaseopor

On Wed, Oct 23, 2019 at 11:01 AM dis3d  wrote:

> Buenos días,
>
> Alguien a podido subir Modelos .obj a OSM a través de JOSM y Kendzi3D. ES
> que yo lo estoy intentando pero no me deja, creo que me falta algún paso.
>
> Si alguien me podría ayudar. Gracias
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[marc marc]

Le 25.10.19 à 15:52, Stéphane Péneau a écrit :
> ticket pour Osmose, il ne devrait pas proposer ce genre de modification 
> sur les nodes "place", uniquement sur les relations.

ou mieux : proposer de vérifier que le nœud a bien le nom du lieu
en plus de virer ref:INSEE

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

[OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap-Carto release v4.24.0

[marc marc]

maj du rendu par défaut sur osm.org dans peu de temps.
résumé personnel :
- modifs cosmétiques des rivières/canaux/parking/carrefours.
- waterway=wadi n'est plus rendu (que 5 cas en fr,
à traiter pour qui veux)
- qlq modifs qui semble préparer/faciliter le passage en rendu vectoriel


 Message transféré 
Sujet : [OSM-dev] OpenStreetMap-Carto release v4.24.0
Date : Fri, 25 Oct 2019 23:40:13 +0900
De : Joseph Eisenberg 
Pour : d...@openstreetmap.org, t...@openstreetmap.org

Dear all,

Today, v4.24.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include:

- Create darker river-color for river & canal areas and waterway lines 
(#3930)

The color of river, canal, ditch and drain waterway lines
and river and canal areas is changed to #8fcadd (Lch78,21,227)

- Fix rendering of water body labels (#3919)

Restores rendering of water body labels on points (node features)
Fixes rendering of natural=bay to use italic font at all z levels
Cleans up duplicate natural=strait code in water.mss

- Precedence of junctions over POIs (#3915)

Junction=yes, =motorway and man_made=bridge labels now render before
amenity-points
This prevents icons from blocking the display of these text labels

- Remove rendering of waterway=wadi (#3931)

The tag waterway=wadi is deprecated, suggested replacement:
waterway=river/stream + intermittent=yes OR natural=valley

- Move parking to amenity-points layers, change way_pixels limit and
initial zoom level (#3923)

Moved parking features back to amenity-points layers
Changed parking text intial zoom to z14, as planned in PR #3612
Change way_pixels limit for parking icon (750) and text (3000)

- Don't use classes anymore (#3912)
- Convert state & country layers to ST_PointOnSurface (#3920)
- Convert addresses to use ST_PointOnSurface (#3898)
- Apply bbox to part of "addresses" query (#3942)

The 4 changes above are needed to allow use of vector tiles
ST_PointOnSurface is used to generate a point for labeling
Classes are removed, replaced with the layer id

- Documentation updates (#3911) & (#3910), Code clean-up (#3899) & (#3922)

Document inner line rendering, update docker documentation
Clean-up text-placement / marker-placement, remove natural=marsh

Thanks to all the contributors for this release, including Adrian
Piotrowicz (@nexces), a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.23.0...v4.24.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

We would love to have new contributors who might be interested in
solving some of the
many open issues.

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

Re: [OSM-talk-fr] annonce des modifs importantes des données [était: Osmose et les mauvais noms de communes]

[marc marc]

version courte :
on commence par une page wiki annonce-fr ?
notification par email possible.
parce que le reste fait un peu usine à gaz pour peu de volume.

version longue :

Le 25/10/2019 à 15:40, Vincent de Château-Thierry a écrit :
>> atteindre les consommateurs (je choisis 
>> volontairement ce mot) de nos données *en dehors* de notre ecosystème. 

c'est la quadrature du cercle : on ne sait pas contacter quelqu'un qui 
est hors de nos moyens de contact. même si on crée un nouveau canal,
il faut bien que les "consommateurs" l'apprennent, s'y abonnent.
ceux qui utilisent les données tout en étant autiste de la communauté
l'apprendront uniquement en subissant la modif (comme pour le centre 
géodésique).
tout ce que nous pouvons faire c'est créer ce canal "épuré" et 
l'annoncer sur nos moyen de contact existant.
si tous les consommateurs lisent au moins l'un de ces canaux,
ils auront l'info, sinon non.
Et comme chacun a son moyen de contact favori, je sens qu'il
va falloir X canaux supplémentaires : email, réseaux sociaux, www/rss
idéalement ces canaux doivent rester communautaire : un compte social 
contrôlé par une seule personne a le défaut de dépendre du temps
de celle-ci, et pas grand monde n'a en permanence du temps libre en rab.

>> on pourrait inciter à s'abonner notamment sur les pages de téléchargement  
>> de données (planet.osm.org, download.geofabrik.de, etc).

ce serrait un bon endroit en effet pour mettre un lien.
côté osm.fr c'est facile à faire.
côté osm.org c'est à discuter, de préférence après la mise en place 
osm-fr afin d'avoir qlq chose à montrer.

Le 25.10.19 à 16:01, Stéphane Péneau a écrit :

> On pourrait aussi essayer de regrouper les différents changements à des 
> dates fixes et peut-être essayer de les annoncer à l'avance.

De quoi parle-t-on ? d'édition de masse ? en France ?
en 2019 : 4 avec celles encore à faire et celle en cours de discussion
  UNE édition de masse faite (crossing:island)
  DEUX éditions de masse demandée/discutées/acceptées
  mais pas encore faites (crossing_ref=zebra et reservation=*)
  UNE en cours de discussion (ref:INSEE)
en 2018 : une ok (les piscines)
en 2017 : 3 ok (2 harmonisations de tag, le bug wheelchair=unknown)

si on parle de si peu, je pense que dire qu'on le fait début/fin
du mois est plus qu'assez contraignant vu le faible nombre de gens motivés.
si on parle d'y annoncer toutes les éditions de masse (y compris 
mondiale donc), faut quelqu'un motivé pour faire les annonces
parce que pour ma part, j'en ai + en attente que de temps dispo.
J'attends déjà des semaines voir des mois pour être sur que tout le 
monde ai eu le temps de s'exprimer. alors encore attendre 2 mois après 
cette période ultra longue, cela finit par favoriser l'immobilisme et 
donc le problème persiste beaucoup plus longtemps qu'il ne faudrait.
pendant ce temps, qlq fait des corrections de masse non documentée
ou et donc parfois erronées sous le radar, c'est pire.
ou bien c'est iD-team qui les fait en distribué, tout aussi pire.
Je ne suis que très faiblement convaincu qu'il faille passer + de temps 
à contacter les autistes/consommateurs comparés à passer + de temps
à corriger les problèmes "de masse" (problème dans lequel j'inclus
l'intégration opendata dispo mais pas assez utilisé et l'accueil
des nouveaux contributeurs)


> annoncer qu'au 01 janvier 2020 les noeuds "place" ne porteront   
> plus le code insee de la commune

faire une annonce avant l'accord ? alors il en faut 2 : appel
à discussion et annonce de quand la discussion est "validée".

j'ai l’impression qu'on est parti pour monter une usine à gaz
donc le rapport temps/bénéfice est faible comparé à une page wiki
auquel les gens intéressés s'abonnent.
page qui n'empercherait pas de + tard ajouter la diffusion email
(déjà possible avec un compte wiki), pouet, www/rss, autres...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] OpenStreetMap-Carto release v4.24.0

[Joseph Eisenberg]

Dear all,

Today, v4.24.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include:

- Create darker river-color for river & canal areas and waterway lines (#3930)

The color of river, canal, ditch and drain waterway lines
and river and canal areas is changed to #8fcadd (Lch78,21,227)

- Fix rendering of water body labels (#3919)

Restores rendering of water body labels on points (node features)
Fixes rendering of natural=bay to use italic font at all z levels
Cleans up duplicate natural=strait code in water.mss

- Precedence of junctions over POIs (#3915)

Junction=yes, =motorway and man_made=bridge labels now render before
amenity-points
This prevents icons from blocking the display of these text labels

- Remove rendering of waterway=wadi (#3931)

The tag waterway=wadi is deprecated, suggested replacement:
waterway=river/stream + intermittent=yes OR natural=valley

- Move parking to amenity-points layers, change way_pixels limit and
initial zoom level (#3923)

Moved parking features back to amenity-points layers
Changed parking text intial zoom to z14, as planned in PR #3612
Change way_pixels limit for parking icon (750) and text (3000)

- Don't use classes anymore (#3912)
- Convert state & country layers to ST_PointOnSurface (#3920)
- Convert addresses to use ST_PointOnSurface (#3898)
- Apply bbox to part of "addresses" query (#3942)

The 4 changes above are needed to allow use of vector tiles
ST_PointOnSurface is used to generate a point for labeling
Classes are removed, replaced with the layer id

- Documentation updates (#3911) & (#3910), Code clean-up (#3899) & (#3922)

Document inner line rendering, update docker documentation
Clean-up text-placement / marker-placement, remove natural=marsh

Thanks to all the contributors for this release, including Adrian
Piotrowicz (@nexces), a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.23.0...v4.24.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

We would love to have new contributors who might be interested in
solving some of the
many open issues.

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

Re: [Talk-it] Mappare una scuola due

[Lorenzo Beltrami]

Il giorno ven 25 ott 2019 alle ore 16:00 Cascafico Giovanni <
cascaf...@gmail.com> ha scritto:

> Qualcuno ha mai mappato shop=supermarket name=pincopallo l'area
> dell'edificato e dei parcheggi di un intero centro commerciale?
> IMHO questo è il problema dell'ostinarsi ad assegnare ad un terreno gli
> attributi di una scuola.
>
> Insisto nel dire che si dovrebbe mappare l'area di proprietà  comunale che
> ospita la scuola con un uso del suolo (tipicamente ricreativo), mentre
> l'edificio (o il piano dell'edificio) come gli effettivi
> amenity=school|kindergarten
>

Credo che se il Supermarket avesse gli scaffali anche nel parcheggio io
userei shop=supermarket includendo anche il parcheggio. :-P
Questo per dire che se attorno alla scuola ci fosse un grande orto botanico
didattico o una zona in cui fare educazione fisica all'aperto, ecc. ecc.
comunque ad uso didattico/educativo anche quella, in qualche modo, fa parte
della scuola.
Discorso diverso se attorno alla scuola c'è un'area che è proprietà della
scuola, ma non ad uso educativo (parcheggi, altre strutture non
scolastiche...) o un'altra scuola differente.

Per certi versi ricorda la questione di amenity=hospital[1].

landuse=school[2] (utilizzato 5.464 volte) come contenitore generico
potrebbe risolvere questo problema? O ne creerebbe altri?
Qualcuno ha provato ad usare anche landuse=education, ma è presente solo
548 volte.

Lorenzo

[1] https://wiki.openstreetmap.org/wiki/IT:Tag:amenity%3Dhospital
[2] https://taginfo.openstreetmap.org/tags/landuse=school
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[Stéphane Péneau]

J'oubliais,

Il y a eu aussi pas mal de modifications de nom de commune sur les 
relations du type :

Saint-Martin-derrière-la-colline -> Saint Martin derrière la colline
Alors que le nom sans les tirets était déjà dans le tag official_name.

Je n'ai pas touché à ces modifs.

Stf

Le 25/10/2019 à 15:52, Stéphane Péneau a écrit :

Le 25/10/2019 à 13:09, marc marc a écrit :

Le 25.10.19 à 12:08, Stéphane Péneau a écrit :

A) Corriger les noeuds place qui ont été modifiés par erreur.

Je ne sais pas si la liste des "erreurs" corrigée donnée par Osmose
recense tous les cas. Si non, il y a t-il un moyen de vérifier tout ça
simplement ?

de quelle liste d'erreur corrigés parles-tu ?
osmose donne généralement la liste des erreurs NON corrigées.


J'avais pensé faire une requête Adiff, mais finalement,j'ai tout fait 
à la main en vérifiant le statut de la commune sur wikipedia.


la liste des erreurs corrigée est là pour encore quelques heures/jours :

http://osmose.openstreetmap.fr/fr/errors/done?item=6040=802


Donc le point A) est réglé.

Reste

B) Supprimer les tags ref:INSEE des noeuds "place" qui sont des noeuds 
membres d'une relation commune déléguée
C) Proposer la suppression de tous les tags ref:INSEE de tous les 
noeuds "place"




c'est une édition de masse vu si tu ne vérifies pas les 2052 objets
individuellement. pour la doc et pour être tranquille, perso
je le ferrai dans les règles de l'art ou ne le ferrait pas.
le plus long dans ce genre d'opération, ce n'est pas de faire la page
wiki et les 3 tags en plus sur le changeset, c'est tout le reste qui
doit de toute façon être fait (discuter, faire la requête, vérifier
si on n'a pas de cas tordus, ...)


Maintenant que la majorité des erreurs est corrigée, on peut peut-être 
éviter le point B, et tout gérer d'un seul coup en supprimant tous les 
ref:INSEE des noeuds "place", non ?


En attendant, je vais faire un ticket pour Osmose, il ne devrait pas 
proposer ce genre de modification sur les nodes "place", uniquement 
sur les relations.



Stf



___
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] OSM very old data

[Tom Ka]

pá 25. 10. 2019 v 15:08 odesílatel Frederik Ramm  napsal:
> On 25.10.19 09:52, Tom Ka wrote:
> > - any recommendation for tool/app/etc to process v0.3 data (up to
> > 01.05.2006 on planet/cc-by-sa) (and convert them to v0.6)?
>
> There's a perl script "04to05.pl" in SVN, this works for 0.3 data as well.

Perfect, will try. For archive, it can be found here:
https://svn.openstreetmap.org/applications/utils/conv05/

> > - is history before 01.05.2006 (easily) available (other archive or
> > local source) (Europe or CZ would be enough)?
>
> We didn't have history files at the time and those were times when we
> still used segments, so in today's history files these early times
> cannot be represented (at least not for ways). I am not aware of any
> older files. But the amount of .cz data in that old planet file is so
> small (7251 nodes and 7453 extremely short ways) that it probably
> wouldn't make a lot of sense to go back further.

OK, one question that remains unanswered will be: what was the first
object in Czech republic :-)

Thanks tkk.

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

Re: [OSM-talk-fr] annonce des modifs importantes des données [était: Osmose et les mauvais noms de communes]

[Stéphane Péneau]

Le 25/10/2019 à 15:40, Vincent de Château-Thierry a écrit :


Talk-fr, le wiki, taginfo, osmweekly : certes, mais mon point est justement de 
chercher à atteindre les consommateurs (je choisis volontairement ce mot) de 
nos données *en dehors* de notre ecosystème. Tout ce que tu énumères est à 
l'intérieur de notre microcosme. Ce que j'imagine est plutôt un canal (quelle 
que soit sa composante technique) auquel toute personne qui veut être tenue au 
courant des évolutions notables de contenu et/ou de modélisation pourrait 
s'abonner, afin que les annonces faites par ce canal trouvent leur cible. Je 
pense à un canal auquel, par exemple, on pourrait inciter à s'abonner notamment 
sur les pages de téléchargement de données (planet.osm.org, 
download.geofabrik.de, etc).

vincent


On pourrait aussi essayer de regrouper les différents changements à des 
dates fixes et peut-être essayer de les annoncer à l'avance.


S'il y avait une liste de diffusion (ou autre) pour ce genre d'infos, 
elle pourrait par exemple être utilisée en ce moment pour annoncer qu'au 
01 janvier 2020 les noeuds "place" ne porteront plus le code insee de la 
commune.


Stf


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

Re: [Talk-it] Mappare una scuola due

[Cascafico Giovanni]

Qualcuno ha mai mappato shop=supermarket name=pincopallo l'area
dell'edificato e dei parcheggi di un intero centro commerciale?
IMHO questo è il problema dell'ostinarsi ad assegnare ad un terreno gli
attributi di una scuola.

Insisto nel dire che si dovrebbe mappare l'area di proprietà  comunale che
ospita la scuola con un uso del suolo (tipicamente ricreativo), mentre
l'edificio (o il piano dell'edificio) come gli effettivi
amenity=school|kindergarten



Il ven 25 ott 2019, 13:06 Lorenzo Pesci  ha scritto:

> Ho cercato di seguire il dibattito sulle scuole, perdendomi un po' nei
> dettagli.
> La cosa che ancora mi confonde è perché la wiki dice:
> Il nome della scuola deve essere riportato nel tag name=* e deve essere
> applicato sullo stesso elemento che possiede il tag amenity=school.
>
> Io trovo un'area con più edifici (es. materna e elementare e media) ma
> senza nome proprio;
> gli edifici hanno un nome proprio ma, secondo Wiki, questo va accanto
> ad amenity.
>
> Dunque delle due l'una:
> 1) name (scuola) accanto a building e name (del plesso se ne ha uno)
> accanto ad amenity
> 2) Spezzo l'area principale in varie sotto-aree amenity=school con il
> name della singola scuola
>
> Il primo contrasta con wiki, il secondo con la realtà.
>
> Infine se voglio pescare dati in maniera semplice per filtrare le
> scuole del mio comune (caso reale) recupero una miscela di
> building/amenity/name poco gestibile.
>
> Lorenzo
>
>
> Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a
> soli 7,99€ al mese. L'attivazione è gratis e disdici quando vuoi.
> http://tisca.li/smart30
>
>
>
> ___
> 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] Osmose et les mauvais noms de communes

[Stéphane Péneau]

Le 25/10/2019 à 13:09, marc marc a écrit :

Le 25.10.19 à 12:08, Stéphane Péneau a écrit :

A) Corriger les noeuds place qui ont été modifiés par erreur.

Je ne sais pas si la liste des "erreurs" corrigée donnée par Osmose
recense tous les cas. Si non, il y a t-il un moyen de vérifier tout ça
simplement ?

de quelle liste d'erreur corrigés parles-tu ?
osmose donne généralement la liste des erreurs NON corrigées.


J'avais pensé faire une requête Adiff, mais finalement,j'ai tout fait à 
la main en vérifiant le statut de la commune sur wikipedia.


la liste des erreurs corrigée est là pour encore quelques heures/jours :

http://osmose.openstreetmap.fr/fr/errors/done?item=6040=802


Donc le point A) est réglé.

Reste

B) Supprimer les tags ref:INSEE des noeuds "place" qui sont des noeuds 
membres d'une relation commune déléguée
C) Proposer la suppression de tous les tags ref:INSEE de tous les noeuds 
"place"




c'est une édition de masse vu si tu ne vérifies pas les 2052 objets
individuellement. pour la doc et pour être tranquille, perso
je le ferrai dans les règles de l'art ou ne le ferrait pas.
le plus long dans ce genre d'opération, ce n'est pas de faire la page
wiki et les 3 tags en plus sur le changeset, c'est tout le reste qui
doit de toute façon être fait (discuter, faire la requête, vérifier
si on n'a pas de cas tordus, ...)


Maintenant que la majorité des erreurs est corrigée, on peut peut-être 
éviter le point B, et tout gérer d'un seul coup en supprimant tous les 
ref:INSEE des noeuds "place", non ?


En attendant, je vais faire un ticket pour Osmose, il ne devrait pas 
proposer ce genre de modification sur les nodes "place", uniquement sur 
les relations.



Stf



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

Re: [OSM-talk-fr] annonce des modifs importantes des données [était: Osmose et les mauvais noms de communes]

[Vincent de Château-Thierry]

> De: "marc marc" 
> 
> alors, allons-y dans un nouveau fil :)

Merci d'avoir amorcé :)
 
> dans un monde idéal :
> - mettre un mot sur la page wiki de la clef me semble un bon début,
> avec un lien sur la discussion talk-fr par exemple.
> en passant, on pourrait corriger le onNode=yes
> pour éviter la loterie, on peux s’abonner aux pages spéciales.
> c'est pas non plus interdit d'au moins lire les titres de talk-fr :)
> 
> - chaque projet utilise cette fonction bien pratique qui consiste àe
> déclaration de ce qu'il utilise. cela permettrait de savoir qui
> avertir.
> c'est ce qui a été utilisé par la personne ayant proposé de déprécier
> la clef diaper https://taginfo.openstreetmap.fr/keys/diaper#projects
> hélas pour nous (ou pour les utilisateurs de cette données),
> il n'y a rien de communiqué pour la clef ref:INSEE
> https://taginfo.openstreetmap.fr/keys/ref:INSEE#projects
> la discussion précédente pour que les rendus "osm-fr" le fasse
> a eu 0 réponse. même pas un "pas le temps" ou "trop dur"
> ceux cyclo l'a fait en partie suite à ma discussion avec Lucas.

> - une annonce sur le site ? pq pas, mais c'est aussi de la pure
> loterie,
> je ne m'attend pas à ce que chaque utilisateur des données consulte
> différents sites, il faut du "push" (email, ...).
> 
> - les canaux "push" : osmweekly, cette liste de diffusion (à mes yeux
> c'est pour cela que les éditions de masse doivent détectable au
> titre,
> cela permet à ceux qui veulent de filtrer rapidement),
> mastodon et bien sur les gafam pour leurs partisants.
> 
> Si une Xieme nouvelle liste venait à être créé, à mon avis il
> faudrait
> se limiter à y poster le sujet avec lien vers la discussion ici.
> 
> Ceci dit, on est très peu nombreux à proposer des éditions de masse
> et hormis celle en cours de discussion, je crois avoir été le seul
> ces 2
> dernières années en francophonie. pas l'impression que cela intéresse
> beaucoup de monde. cela me donne l'impression qu'un canal de + est
> peut-être surdimensionné.
> Et puis il y a les éditions "pas de masse" qui impacte aussi (cfr
> le centre géodésique de la France qui était utilisé par un rendu
> commercial qui ne gérait pas les pays sous forme de relation)
> et là... ca avait été discuté... mais si les pro ne suivent pas
> la communauté dont il utilise les données... j'ai du mal à trouver
> une solution.

Talk-fr, le wiki, taginfo, osmweekly : certes, mais mon point est justement de 
chercher à atteindre les consommateurs (je choisis volontairement ce mot) de 
nos données *en dehors* de notre ecosystème. Tout ce que tu énumères est à 
l'intérieur de notre microcosme. Ce que j'imagine est plutôt un canal (quelle 
que soit sa composante technique) auquel toute personne qui veut être tenue au 
courant des évolutions notables de contenu et/ou de modélisation pourrait 
s'abonner, afin que les annonces faites par ce canal trouvent leur cible. Je 
pense à un canal auquel, par exemple, on pourrait inciter à s'abonner notamment 
sur les pages de téléchargement de données (planet.osm.org, 
download.geofabrik.de, etc).

vincent

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

Re: [OSM-talk] OSM very old data

[Frederik Ramm]

Hi,

On 25.10.19 09:52, Tom Ka wrote:
> - any recommendation for tool/app/etc to process v0.3 data (up to
> 01.05.2006 on planet/cc-by-sa) (and convert them to v0.6)?

There's a perl script "04to05.pl" in SVN, this works for 0.3 data as well.

> - is history before 01.05.2006 (easily) available (other archive or
> local source) (Europe or CZ would be enough)?

We didn't have history files at the time and those were times when we
still used segments, so in today's history files these early times
cannot be represented (at least not for ways). I am not aware of any
older files. But the amount of .cz data in that old planet file is so
small (7251 nodes and 7453 extremely short ways) that it probably
wouldn't make a lot of sense to go back further.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[Vincent de Château-Thierry]

> De: "marc marc" 
> Le 25.10.19 à 12:08, Stéphane Péneau a écrit :
> 
> > Il faut trouver la bonne requête overpass
> 
> c'est bancal comme critère à cause du caractère non obligatoire et
> franco-fr du tag admin_type:FR mais si tu veux, voici à quoi cela
> ressemblerait https://overpass-turbo.eu/s/Nrp
> 2052 occurrences.

Vu le graphique d'Osmose on doit largement pouvoir restreindre la population 
des noeuds à inspecter si on ajoute comme critère que ces noeuds doivent avoir 
été modifiés depuis début 2019 (mais désolé Stephane mais mon Bac moins 5 en 
Overpass m'interdit de te proposer quoi que ce soit d'efficace sur ce point :/ )

> > Pour ces 2 points, est-ce vraiment nécessaire de passer
> > par toute la partie administrative ?
> 
> c'est une édition de masse vu si tu ne vérifies pas les 2052 objets
> individuellement.

Point à moduler en fonction du point précédent... Une population de quelques 
dizaines-centaines de noeuds ça se passe en revue un par un, avec JOSM et le 
plugin todolist, quitte à morceler le travail sur plusieurs sessions et/ou 
plusieurs contributeurs. Y a même des outils pour se partager le territoire 
façon parts de gâteau ;)

vincent

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

Re: [talk-au] LPI NSW Lot Boundaries—worthwile to request?

[Luke Stewart]

Also with the boundary only layer you can have the satellite view in full
focus whilst also editing without having the other features of the base map
such as address, buildings, etc.

Cheers,
Luke
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] LPI NSW Lot Boundaries—worthwile to request?

[Luke Stewart]

I'm not proposing to import the boundaries into the database, only showing
up as an overlay in the editor. Whether there is a feature there to be
mapped along the boundary can of course only be determined by aerial
imagery.

Cheers,
Luke
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Silent Spike]

On Fri, Oct 25, 2019 at 1:26 PM Silent Spike 
wrote:

> The crossing=marked/unmarked tagging is inspired from a proposal I
> believe, because there is ambiguity to the controlled/uncontrolled tagging
> whereas there's an explicit obvious answer as to whether a crossing has
> markings or not.
>

For those who can't see the slack archive (don't have an account) in my
last post, the discussion points to these proposals:

https://wiki.openstreetmap.org/wiki/Proposed_features/Unambiguous_crossings
https://wiki.openstreetmap.org/wiki/Proposed_features/crossing%3Dmarked
https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:signals
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Silent Spike]

On Fri, Oct 25, 2019 at 12:57 PM Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

>
> It would also be really good if we could get the standard UK crossing
> types (zebra, pelican, toucan, pegasus) added to the iD presets to
> help UK editors add that information. Currently typing those names in
> iD doesn't give anything helpful (apart from zebra that returns
> "Marked Crossing") and there are only the marked and unmarked crossing
> options if you type "crossing" in.
>


I have floated this idea out before (
https://osmus.slack.com/archives/CBK3JLUJU/p1561914872093800) as it is now
possible to create region specific iD presets. However, the whole crossing
tagging scheme is a mess currently and iD would like to wait until
proposals are completed to clean it up before messing with crossing presets.

The crossing=marked/unmarked tagging is inspired from a proposal I believe,
because there is ambiguity to the controlled/uncontrolled tagging whereas
there's an explicit obvious answer as to whether a crossing has markings or
not.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSRM-talk] Exclude bridge from OSRM calculation

[Steven M. Ottens]

Hi Andres,

The public web service doesn't allow for exclusion of roads/bridges. If 
you setup your own copy of OSRM you obviously do have the freedom to 
exclude anything.


Alternatively you could look into Rural Accessibility Map. An 
application on top of OSRM developed for the Worldbank which is used to 
calculate the impact of road improvements on the accessibility of a 
region. You can use it to other way around as well: Calculate the impact 
of a bridge collapse.


http://rah.surge.sh/about+

https://github.com/WorldBank-Transport/ram-backend

Cheers

Steven

On 25-10-2019 12:31, ANDRES ABARCA wrote:
Hi! I'm a PhD student at IUSS Pavia doing research on the impact of 
bridge collapse.
I want to use the OSRM public web server to calculate a duration 
matrix using the Table Service. How can I exclude a specific bridge 
(or several) from the query?


We use OSM information, so we do have the OSM id numbers for the 
bridges we would be excluding.


Thanks for any assistance you can provide.

Best regards,

Andres Abarca
PhD Student
IUSS Pavia

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

Re: [OSM-talk] OSM very old data

[Tom Ka]

Most dumps/diffs are newer then 2007, the only older dirs are in
https://planet.osm.org/cc-by-sa/history/, but those are diffs (not
full dumps) and all in 2004 and lot in 2005 are empty, which is weird.
Being diffs I would need starting dump to update to use them anyway.

Bye tkk

pá 25. 10. 2019 v 13:48 odesílatel Mateusz Konieczny
 napsal:
>
>
>
>
> 25 Oct 2019, 09:52 by tomas.kaspa...@gmail.com:
>
> - is history before 01.05.2006 (easily) available (other archive or
> local source) (Europe or CZ would be enough)?
>
> https://planet.osm.org/cc-by-sa/ ?
>
> ___
> 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: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Robert Whittaker (OSM lists)]

On Fri, 25 Oct 2019 at 11:45, Jez Nicholson  wrote:
> +1 for a bot edit

My initial instinct was to say this too. But if most of these
crossing=zebra tags were added by iD users who selected "Marked
Crossing" and never saw the zebra tag, then how sure are we that
almost all Marked Crossings in the UK will be zebras?

Perhaps a Maproulett challenge would be a better way, if aerial
imagery is usually good enough to identify zebra crossings.

> are you suggesting to just add crossing_ref=zebra, or to convert 
> crossing=zebra into highway=crossing + crossing=uncontrolled too?

If edits are made, we should convert the crossing=* tag too. But we
should probably decide what value that should take. iD seems to be
suggesting crossing=marked rather than crossing=uncontrolled. However,
the former is not documented in the wiki:
https://wiki.openstreetmap.org/wiki/Key:crossing .

It would also be really good if we could get the standard UK crossing
types (zebra, pelican, toucan, pegasus) added to the iD presets to
help UK editors add that information. Currently typing those names in
iD doesn't give anything helpful (apart from zebra that returns
"Marked Crossing") and there are only the marked and unmarked crossing
options if you type "crossing" in.

Robert.

-- 
Robert Whittaker

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

Re: [OSM-talk] OSM very old data

[Mateusz Konieczny]

25 Oct 2019, 09:52 by tomas.kaspa...@gmail.com:

> - is history before 01.05.2006 (easily) available (other archive or
> local source) (Europe or CZ would be enough)?
>
https://planet.osm.org/cc-by-sa/  ?

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

[OSM-talk-fr] annonce des modifs importantes des données [était: Osmose et les mauvais noms de communes]

[marc marc]

Bonjour,

Le 25.10.19 à 11:32, Vincent de Château-Thierry a écrit :

 > comment informer les consommateurs des données des changements opérés
 > en base massivement. Documenter le wiki ne fait pas de mal, mais ça
 > demande à chacun de tomber sur la bonne page d'information a
 > posteriori, ce qui relève de la pure loterie. Faut-il une annonce
 > sur le site openstreetmap.fr ? Un canal d'annonce type liste
 > de discussion ou fil RSS ? Un compte twitter ? Un peu tout ça ?
 > Cette question mériterait un fil dédié.

alors, allons-y dans un nouveau fil :)

dans un monde idéal :
- mettre un mot sur la page wiki de la clef me semble un bon début,
avec un lien sur la discussion talk-fr par exemple.
en passant, on pourrait corriger le onNode=yes
pour éviter la loterie, on peux s’abonner aux pages spéciales.
c'est pas non plus interdit d'au moins lire les titres de talk-fr :)

- chaque projet utilise cette fonction bien pratique qui consiste àe 
déclaration de ce qu'il utilise. cela permettrait de savoir qui avertir.
c'est ce qui a été utilisé par la personne ayant proposé de déprécier
la clef diaper https://taginfo.openstreetmap.fr/keys/diaper#projects
hélas pour nous (ou pour les utilisateurs de cette données),
il n'y a rien de communiqué pour la clef ref:INSEE
https://taginfo.openstreetmap.fr/keys/ref:INSEE#projects
la discussion précédente pour que les rendus "osm-fr" le fasse
a eu 0 réponse. même pas un "pas le temps" ou "trop dur"
ceux cyclo l'a fait en partie suite à ma discussion avec Lucas.

- une annonce sur le site ? pq pas, mais c'est aussi de la pure loterie,
je ne m'attend pas à ce que chaque utilisateur des données consulte 
différents sites, il faut du "push" (email, ...).

- les canaux "push" : osmweekly, cette liste de diffusion (à mes yeux 
c'est pour cela que les éditions de masse doivent détectable au titre, 
cela permet à ceux qui veulent de filtrer rapidement),
mastodon et bien sur les gafam pour leurs partisants.

Si une Xieme nouvelle liste venait à être créé, à mon avis il faudrait 
se limiter à y poster le sujet avec lien vers la discussion ici.

Ceci dit, on est très peu nombreux à proposer des éditions de masse
et hormis celle en cours de discussion, je crois avoir été le seul ces 2 
dernières années en francophonie. pas l'impression que cela intéresse 
beaucoup de monde. cela me donne l'impression qu'un canal de + est
peut-être surdimensionné.
Et puis il y a les éditions "pas de masse" qui impacte aussi (cfr
le centre géodésique de la France qui était utilisé par un rendu 
commercial qui ne gérait pas les pays sous forme de relation)
et là... ca avait été discuté... mais si les pro ne suivent pas
la communauté dont il utilise les données... j'ai du mal à trouver
une solution.

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

[Talk-GB] Parish Councils needs

[Edward Bainton]

A follow-up to my earlier, narrower query (subject line now changed)

Can Overpass measure the length of roads?

Eg, if a parish council wants to know how many miles of roads it has to
sweep. (Assume filtering by road type is possible to exclude driveways,
etc; assume all roads their responsibility.)

What about area of grass to cut? (add together all parks, football pitches,
etc - assume tagged *operator=Footon Parish Council*).

Thanks as ever,

Edward eteb3

-- Forwarded message -
From: Dave F via Talk-GB 
Date: Wed, 23 Oct 2019 at 17:17
Subject: Re: [Talk-GB] Reference numbers for UK admin areas?
To: Talk-GB@openstreetmap.org 


Try this:
https://overpass-turbo.eu/s/Nor

area(3601608485); // Sutton
//node[amenity=grit_bin]
nwr[building](area);
out meta center;

As you want a specific area, the way I do it is to get the relation
boundary's id (from the link you gave in the forum)   & add it to
36 (which is the start of the databases numbering for relations
so they don't overlap with ways & nodes).

DaveF

On 23/10/2019 16:32, Edward Bainton wrote:
> This is Sutton the parish within the City of Peterborough unitary
authority
> (there is another in Beds and another in Norfolk).
>
> OP here: https://forum.openstreetmap.org/viewtopic.php?id=67698
>
> The challenge was to get Overpass to return grit bins in *this *Sutton,
and
> not in all places called Sutton.
>
> The context (not in OP) was a query from someone who works with parish
> councils asking whether OSM is a feasible GIS for their asset management -
> because (1) parish councils are third parties to the Public Sector Mapping
> Agreement and (2) they have just had a lot of  assets (or should that be
> liabilities?) devolved to them from higher tiers of government.
>
> Edward
>
> On Wed, 23 Oct 2019 at 16:25, Dave F via Talk-GB <
talk-gb@openstreetmap.org>
> wrote:
>
>> Which Sutton?
>>
>> Could you post the OP?
>>
>> DaveF
>>
>>
>>
>>
>>
>> On 23/10/2019 15:49, Edward Bainton wrote:
>>
>> Hi all
>> On the forum marczoutendijk gave me an Overpass query to find grit-bins
in
>> Sutton.
>>
>> He added an admin-level to distinguish the parish of Sutton from the
London
>> borough.
>>
>> The only issue is, there are at least three Suttons at admin_level=10 (as
>> it happens, not far from each other).
>>
>> They have ref numbers thus: ref:gss=E04001120 (for example)
>>
>> Does anyone know what these are? There is a webpage in the wiki here,
but I
>> can't make sense of it.https://wiki.openstreetmap.org/wiki/Item:Q2647
>>
>> Thanks,
>>
>> Edward
>>
>>
>>
>>
>> ___
>> Talk-GB mailing listTalk-GB@openstreetmap.orghttps://
lists.openstreetmap.org/listinfo/talk-gb
>>
>>
>> ___
>> 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
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Brian Prangle]

I think all 3 tags should be the  standard.

On Fri, 25 Oct 2019 at 11:45, Jez Nicholson  wrote:

> +1 for a bot edit
>
> are you suggesting to just add crossing_ref=zebra, or to convert
> crossing=zebra into highway=crossing + crossing=uncontrolled too?
>
> On Fri, Oct 25, 2019 at 8:23 AM Mateusz Konieczny 
> wrote:
>
>>
>>
>>
>> 24 Oct 2019, 22:48 by rob.j.nicker...@gmail.com:
>>
>> Hi all,
>>
>> *Before I start this message, I would like to say that I am looking for
>> solutions and not wishing to open the flood gates on abuse of the iD
>> editors. On the whole they do a great job and even when we disagree it
>> should be with respect. Right now on to the message itself:*
>>
>>
>> It seems like the iD editor's "upgrade this" feature is replacing
>> crossing=zebra with crossing=marked but NOT adding crossing_ref=zebra to
>> the node. If lots of users make use of this "feature" in the UK then we
>> stand to lose some valuable data. Taginfo UK says there are 4,710
>> crossing=zebra features in the UK.
>>
>> I have added a comment on to the GitHub issue but no reply yet.
>> https://github.com/openstreetmap/iD/issues/6962
>>
>> I would suggest opening a new issue request GB specific - maybe with
>> something like
>> "I checked sample of 100 crossing tagged this way, error rate is low".
>>
>> Comments in a closed issue are likely to be lost/unnoticed.
>>
>> Though with just 5k crossing it seems that bot edit would be preferable if
>> - error rate is considered low
>> - crossing_ref tagging is acceptable
>> - there is no realistic plan to fight with iD over deprecating
>> crossing=zebra
>> - bot edits are considered as acceptable
>>
>> Why bot edit is preferable?
>> - cooperation with iD developers is not necessary
>> - more people can do it (I may do it in case of a clear support)
>> - adding complex region-based handling for 5k objects is making
>> maintenance of editor
>> complex, it is likely to not be done by iD developers
>> ___
>> 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
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[marc marc]

Le 25.10.19 à 12:08, Stéphane Péneau a écrit :
> A) Corriger les noeuds place qui ont été modifiés par erreur.
> 
> Je ne sais pas si la liste des "erreurs" corrigée donnée par Osmose 
> recense tous les cas. Si non, il y a t-il un moyen de vérifier tout ça 
> simplement ?

de quelle liste d'erreur corrigés parles-tu ?
osmose donne généralement la liste des erreurs NON corrigées.
le plus simple me semble être de faire 2 exports overpass csv
des noeuds place=* aujourd'hui et avant la chute du nombre de cas
en comparant les name=* cela donnera les problèmes potentiels.
ceci dit, sans vouloir te démotiver, lors du vandalisme en Occitanie,
il n'était que 3 à se farcir les vérifs.
Christian a peut-être un script car il en avait remit un grand nombre.

> B) Supprimer les tags ref:INSEE des noeuds "place" qui sont des noeuds 
> membres d'une relation commune déléguée

mais pas que. le problème se pose même s'il n'y a pas de commune 
déléguée ou s'il n'en sont pas membre.

> Il faut trouver la bonne requête overpass

c'est bancal comme critère à cause du caractère non obligatoire et 
franco-fr du tag admin_type:FR mais si tu veux, voici à quoi cela 
ressemblerait https://overpass-turbo.eu/s/Nrp
2052 occurrences.
je n'ai pas tenu compte des autres valeurs plus exotique 
https://taginfo.openstreetmap.fr/keys/admin_type:FR#values

> Pour ces 2 points, est-ce vraiment nécessaire de passer  
> par toute la partie administrative ?

c'est une édition de masse vu si tu ne vérifies pas les 2052 objets 
individuellement. pour la doc et pour être tranquille, perso
je le ferrai dans les règles de l'art ou ne le ferrait pas.
le plus long dans ce genre d'opération, ce n'est pas de faire la page 
wiki et les 3 tags en plus sur le changeset, c'est tout le reste qui
doit de toute façon être fait (discuter, faire la requête, vérifier
si on n'a pas de cas tordus, ...)

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

[Talk-it] Mappare una scuola due

[Lorenzo Pesci]

Ho cercato di seguire il dibattito sulle scuole, perdendomi un po' nei 
dettagli.

La cosa che ancora mi confonde è perché la wiki dice:
Il nome della scuola deve essere riportato nel tag name=* e deve essere 
applicato sullo stesso elemento che possiede il tag amenity=school.


Io trovo un'area con più edifici (es. materna e elementare e media) ma 
senza nome proprio;
gli edifici hanno un nome proprio ma, secondo Wiki, questo va accanto 
ad amenity.


Dunque delle due l'una:
1) name (scuola) accanto a building e name (del plesso se ne ha uno) 
accanto ad amenity
2) Spezzo l'area principale in varie sotto-aree amenity=school con il 
name della singola scuola


Il primo contrasta con wiki, il secondo con la realtà.

Infine se voglio pescare dati in maniera semplice per filtrare le 
scuole del mio comune (caso reale) recupero una miscela di 
building/amenity/name poco gestibile.


Lorenzo


Con Tiscali Mobile Smart 30 hai minuti illimitati, 30 Giga e 100 SMS a 
soli 7,99€ al mese. L'attivazione è gratis e disdici quando vuoi. 
http://tisca.li/smart30




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

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Andy Townsend]

On 25/10/2019 11:43, Jez Nicholson wrote:

+1 for a bot edit


Perhaps Maproulette would be a better option?  Zebra markings would 
often be visible on aerial imagery, and a comparison of newer vs older 
imagery might allow people to identify recent changes*.


Best Regards,

Andy

* Somewhat offtopic, with almost all of the wood/forest edits I've been 
doing recently I've used surveys to confirm which imagery is latest (and 
around https://www.openstreetmap.org/#map=13/54.2593/-1.2397 it's Maxar 
Premium), but using Bing for extra clarity and better alignment, and 
also using OS OpenData waterway and road centreline data for alignment.



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

Re: [Talk-it] mappare sede associazione Esperantista

[Marco Ciampa]

On Fri, Oct 25, 2019 at 10:19:49AM +0200, Martin Koppenhoefer wrote:
> Am Do., 24. Okt. 2019 um 16:57 Uhr schrieb Marco Ciampa  >:
> 
> > > "esperanto=yes" senza contesto mi sembrerebbe più un tag per un
> > > oggetto dove si capisce / parla esperanto. Se si riferisce al nome della
> > > via, sarei più per un tag come questo:
> > > https://taginfo.openstreetmap.org/keys/name%3Aetymology%3Awikidata
> >
> > Non mi è ben chiaro a che serva questo tag, mi spieghi per favore?
> 
> è un tag che descrive l'etimologia del nome della strada (cosa significa /
> a cosa si riferisce, spesso sono persone)
> 
> > Mi pare abbia a che fare con wikipedia, ma non tutto ciò che è marcato con
> > un riferimento "esperantista" ha una voce su wikipedia (anzi, ben pochi a
> > dir la verità...). Quindi come marcare un tale oggetto?
> 
> si riferisce a wikidata, e se la voce non c'è la potresti creare, comunque,
> esperanto ha il numero 143, quindi ci hanno pensato proprio con priorità :)

Intendi che lo hanno fatto quasi da subito? Si, gli esperantisti non sono
moltissimi (ma comunque milioni) e molto, molto attivi (vedi wikipedia in
Esperanto...)

> > > ce ne sono già 61:
> > > https://taginfo.openstreetmap.org/tags/name%3Aetymology%3Awikidata=Q143
> >
> > In tutto il mondo? Pochini... e come avere l'elenco di questi oggetti,
> > per capire cosa/dove sono?
> >
> 
> 
> se guardi in alto a destra sulla pagina linkata, c'è un riferimento a
> "overpass turbo", cliccando si apre questo servizio che ti cerca tutti gli
> oggetti:
> https://overpass-turbo.eu/?w=%22name%3Aetymology%3Awikidata%22%3D%22Q143%22+global

Ottimo, grazie!

Allora, vediamo se ho capito bene. Quel tag, potrebbe essere l'ideale
candidato a sostituire il tag generico "esperanto=yes" per peraltro non
mi pare stia avendo successo nella procedura di accettazione di
standardizzazione nel caso di ricorrenza di "Esperanto" nel nome.

Nel caso nel nome ci sia "Zamenhof" o "Esperant-qualcosa" come Esperantista?

Diciamo che uno voglia fare "pulizia" e voglia sostituire ogni generico
riferimento a: esperanto=yes con i tag suddetti. Quale sarebbe il metodo
migliore per evitare di farlo a mano?

--

Best regards,
Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




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

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Jez Nicholson]

+1 for a bot edit

are you suggesting to just add crossing_ref=zebra, or to convert
crossing=zebra into highway=crossing + crossing=uncontrolled too?

On Fri, Oct 25, 2019 at 8:23 AM Mateusz Konieczny 
wrote:

>
>
>
> 24 Oct 2019, 22:48 by rob.j.nicker...@gmail.com:
>
> Hi all,
>
> *Before I start this message, I would like to say that I am looking for
> solutions and not wishing to open the flood gates on abuse of the iD
> editors. On the whole they do a great job and even when we disagree it
> should be with respect. Right now on to the message itself:*
>
>
> It seems like the iD editor's "upgrade this" feature is replacing
> crossing=zebra with crossing=marked but NOT adding crossing_ref=zebra to
> the node. If lots of users make use of this "feature" in the UK then we
> stand to lose some valuable data. Taginfo UK says there are 4,710
> crossing=zebra features in the UK.
>
> I have added a comment on to the GitHub issue but no reply yet.
> https://github.com/openstreetmap/iD/issues/6962
>
> I would suggest opening a new issue request GB specific - maybe with
> something like
> "I checked sample of 100 crossing tagged this way, error rate is low".
>
> Comments in a closed issue are likely to be lost/unnoticed.
>
> Though with just 5k crossing it seems that bot edit would be preferable if
> - error rate is considered low
> - crossing_ref tagging is acceptable
> - there is no realistic plan to fight with iD over deprecating
> crossing=zebra
> - bot edits are considered as acceptable
>
> Why bot edit is preferable?
> - cooperation with iD developers is not necessary
> - more people can do it (I may do it in case of a clear support)
> - adding complex region-based handling for 5k objects is making
> maintenance of editor
> complex, it is likely to not be done by iD developers
> ___
> 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

[OSRM-talk] Exclude bridge from OSRM calculation

[ANDRES ABARCA]

Hi! I'm a PhD student at IUSS Pavia doing research on the impact of
bridge collapse.

I want to use the OSRM public web server to calculate a duration matrix
using the Table Service. How can I exclude a specific bridge (or several)
from the query?

We use OSM information, so we do have the OSM id numbers for the bridges we
would be excluding.

Thanks for any assistance you can provide.

Best regards,

Andres Abarca
PhD Student
IUSS Pavia
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[Stéphane Péneau]

Le 25/10/2019 à 11:32, Vincent de Château-Thierry a écrit :


Il y a forcément des usages par ci par là qui perdurent et utilisent en direct 
ces points, par facilité ou méconnaissance de la modélisation par relation et 
rôle admin_centre.
Ca amène à la question (récurrente) de comment informer les consommateurs des 
données des changements opérés en base massivement. Documenter le wiki ne fait 
pas de mal, mais ça demande à chacun de tomber sur la bonne page d'information 
a posteriori, ce qui relève de la pure loterie. Faut-il une annonce sur le site 
openstreetmap.fr ? Un canal d'annonce type liste de discussion ou fil RSS ? Un 
compte twitter ? Un peu tout ça ? Cette question mériterait un fil dédié.



Tu le lances ?



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

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[Stéphane Péneau]

En fait il y a plusieurs points avec des importances différentes :

Les plus importants :

A) Corriger les noeuds place qui ont été modifiés par erreur.

Je ne sais pas si la liste des "erreurs" corrigée donnée par Osmose 
recense tous les cas. Si non, il y a t-il un moyen de vérifier tout ça 
simplement ?


B) Supprimer les tags ref:INSEE des noeuds "place" qui sont des noeuds 
membres d'une relation commune déléguée


Il faut trouver la bonne requête overpass. Je n'en suis pas capable sans 
y passer quelques heures. On peut aussi le faire manuellement. A 
plusieurs, ça ne devrait pas être très long.


Pour ces 2 points, est-ce vraiment nécessaire de passer par toute la 
partie administrative ?



Par la suite, et là on a plus de temps, et il faut le faire dans les règles

C) Proposer la suppression de tous les tags ref:INSEE de tous les noeuds 
"place"



J'ajouterais bien qu'un noeud "place" comme admin_centre d'un EPCI type 
comcom, c'est erroné de mon point de vue, mais c'est un autre débat.


Stéphane


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

Re: [Talk-it] Mappatura resti di baraccamenti della Grande Guerra

[Danilo De Martin]

>
> penso che neanche barracks vada bene, perché dalla tua descrizione le
> strutture non erano mai caserme, o sì?


infatti, Martin, come segnalavo questa è una delle perplessità che mi trovo
tra i piedi. L'utilizzo di barracks potrebbe tuttavia essere giustificato
da una "interpretazione allargata" della loro funzionalità, così come
espressa (in modo molto succinto) nel relativo wiki [1], ossia "where
soldiers live and work" che qui provo a illustrare .

Ovviamente la cosa va considerata nel contesto dello svolgimento della
Grande Guerra. Una buona parte delle baracche cui si fa riferimento era
utilizzata per ricovero della truppa e dentro il loro perimetro i soldati
"vivevano e operavano": la baracca era sostanzialmente il loro alloggio.

Nella guerra di posizione che si era venuta a creare, alla giornata sotto
fuoco nemico d'artiglieria potevano seguire trenta giorni di relativa
tranquillità (a parte l'insidia del tiro dei cecchini) seguiti, a loro
volta, da una o più giornate di tentativi d'assalto, per poi tornare a
"vivere e operare" alloggiati nelle baracche. Durante l'inverno le attività
ostili erano sostanzialmente... congelate (a parte isolate sortite) e nelle
baracche il problema più grande diventava (paradossalmente) come passare il
tempo.

Se poi andiamo a vedere la voce su wikipedia [2] troviamo che la caserma
"Nel linguaggio militare è definita una mera "facilitazione logistica": in
sostanza, un luogo in cui i militari vengono acquartierati, al riparo dalle
intemperie, in attesa di un eventuale impiego specifico".

Da tutto ciò io mi sono immaginato le baracche, anche quelle in prima linea
come nel caso di Monte Piana, come una sorta di caserma essenziale
(ovviamente la caserma canonica ha tutta una serie di altri servizi...) da
cui la possibile descrizione come abandoned:military=barracks (o forse
ancor meglio ruins:military=barracks) con il contesto storico definito da
start_date=1915.

Va anche detto che, al pari delle caserme canoniche che normalmente
presentano edifici per l'alloggio, per le cucine, per i magazzini, analoga
situazione poteva presentarsi al fronte laddove la morfologia non fosse
risultata d'ostacolo allo sviluppo dell'accampamento. In questa foto [3]
dell'accampamento ala destra dell'esercito austro-ungherese al Monte Piano,
per esempio, l'edificio in primo piano costituiva la cucina, i due edifici
centrali erano gli alloggi (con dormitorio), la mezza baracca a sinistra
aveva funzioni di magazzino, quella piccola più lontana era la fureria.
Ovviamente ci sono molte baracche, soprattutto dalla parte italiana,
isolate rispetto all'acquartieramento principale in relazione tanto alla
morfologia del territorio occupato quanto alle necessità logistiche da
garantire.

Finisco col dire che come succede in statistica, dove se sottoponi a
tortura i numeri puoi far loro dire quello che vuoi, può essere che quella
che ho appena descritto sia una interpretazione "un po' troppo allargata",
ed è uno dei motivi per cui ho chiesto consiglio sull'argomento.

Ciao. Danilo

[1] https://wiki.openstreetmap.org/wiki/Tag:military%3Dbarracks
[2] https://it.wikipedia.org/wiki/Caserma
[3]
http://www.danil.com/blog/wp-content/uploads/2019/10/100af-ala-destra-parte-cop.jpg

Il giorno mer 23 ott 2019 alle ore 07:48 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> > On 22. Oct 2019, at 14:11, Danilo De Martin 
> wrote:
> >
> > si potranno anche definire più aree che individuano zone di battaglia
> specifiche cui attribuire un historic=battlefield, ma non certo le singole
> postazioni. Inoltre, anche memorial=war_memorial mi sembra fuori luogo così
> come building=construction.
>
>
> +1
>
> penso che neanche barracks vada bene, perché dalla tua descrizione le
> strutture non erano mai caserme, o sì?
>
>
> 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

[Talk-gb-westmidlands] Saturday at Houton

[Brian Prangle]

Hi everyone

Let's meet at the Visitors Centre Car Park for 10am to decide what and how
to map. The Tuning Fork(adjacent) do good grub so we could have lunch
there. If there has been insufficient progress on new roads/houses since
our last visit to occupy us, we can discuss where else to map

Regards

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

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[Vincent de Château-Thierry]

Bonjour,

> De: "marc marc" 
> 
> Le 25.10.19 à 09:57, Stéphane Péneau a écrit :
> > L'explication de cette erreur [2] indique que dans le cas des
> > communes
> > fusionnées, il faut supprimer le tag re:INSEE du noeud place
> 
> > Je pense qu'il faut corriger ça assez vite et supprimer
> > les ref:INSEE des noeuds "place" des communes déléguées. L'idéal
> > serait
> > peut-être de le faire sur tous les noeuds "place" puisque sa place
> > est
> > plutôt sur la relation de la commune
> 
> Je partage ton avis : il faut supprimer ref:INSEE de tous les noeuds
> vu que la ref concerne la commune et non le village/ville même
> parfois
> il a le même nom. il y a le même soucis avec les tag wikipedia (qui
> parle souvent de la commune et non spécifiquement du village) et
> website
> (qui est souvent celui de la mairie et non du village). mais ces 2
> méritent une opération séparée.

D'accord aussi.
La généralisation du tag ref:INSEE sur les nodes chefs-lieux de communes date 
de 2012, et était motivée par l'absence d'une couche complète de limites 
administratives sous forme de relations. Ca se voulait une solution d'attente, 
qui aurait du prendre fin une fois toutes les limites admin tracées, fin 2013.

Il y a forcément des usages par ci par là qui perdurent et utilisent en direct 
ces points, par facilité ou méconnaissance de la modélisation par relation et 
rôle admin_centre.
Ca amène à la question (récurrente) de comment informer les consommateurs des 
données des changements opérés en base massivement. Documenter le wiki ne fait 
pas de mal, mais ça demande à chacun de tomber sur la bonne page d'information 
a posteriori, ce qui relève de la pure loterie. Faut-il une annonce sur le site 
openstreetmap.fr ? Un canal d'annonce type liste de discussion ou fil RSS ? Un 
compte twitter ? Un peu tout ça ? Cette question mériterait un fil dédié.

vincent

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

Re: [talk-cz] Jak v iD editoru vybrat konkretni ze soubeznych linii?

[jzvc via talk-cz]

Dne 25.10.2019 v 11:09 Tomas Novotny napsal(a):

Ahoj,

On Thu, 24 Oct 2019 20:30:20 +0200
jzvc via talk-cz  wrote:


Cus,

celkem jednoduse, vymenis iD za Josm. To na co si narazil je jedna z velmi
mnoha veci, ktery v tom proste delat nejde(pripadne drbanim se nohou za
krkem) a pokud hodlas editaci venovat nejaky ten cas delsi nez par minut,
velmi rychle zacnes narazet na dalsi a dalsi. Typicky si celkem rychle
nabijes ... tam, kde jsou relace v relacich a pod.

kdyz uz tu zaznel JOSM, tak jen doplnim, jak se to dela. Drzis klavesu alt a
klikas na linii. Postupne to vybira ty linie pod sebou.

T.


A nebo na to kliknes strednim tlacitkem a vyberes si ze seznamu, kterej 
je vcetne relaci.






BTW: Nevim jak se chova iD, nepouzivam, ale hypoteticky by to mohlo jit
tak, ze z te linie vytahnes dalsi node nekam stranou, cimz odkryjes linii
pod ni (a nasledne ho pripadne smaznes). Ale mozna ti to ten node hodi pres
vsechny, pak si nepomuzes. Navic takovych linii muze byt pres sebe vic, a
pak je tento zpusob prace ponekud nestastny.

Dne 24.10.2019 v 11:17 Petr Vozdecký napsal(a):

Ahoj vsem,

poradi mi prosim nekdo, jak v iD editoru vybrat prave jednu konkretni >
linii, pokud jich je "na sobe" nekolik?

Pokud je to jednoduchy soubeh napr. dvou ploch, pak se to da vybrat >
nalezenim casti linie, ktera neni nikde v soubehu s jinou. Pokud je to >
napr. slozita relace a nektera linie je po cele sve delce v soubehu s >
jinymi, je to slozitejsi, ale da se to vybrat krkolome pres relaci. > Ale
v ostatnich pripadech jsem u iD editoru v koncich...

diky za jakoukoliv radu

vop

___
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

Re: [talk-cz] Jak v iD editoru vybrat konkretni ze soubeznych linii?

[Tomas Novotny]

Ahoj,

On Thu, 24 Oct 2019 20:30:20 +0200
jzvc via talk-cz  wrote:

> Cus,
> 
> celkem jednoduse, vymenis iD za Josm. To na co si narazil je jedna z velmi
> mnoha veci, ktery v tom proste delat nejde(pripadne drbanim se nohou za
> krkem) a pokud hodlas editaci venovat nejaky ten cas delsi nez par minut,
> velmi rychle zacnes narazet na dalsi a dalsi. Typicky si celkem rychle
> nabijes ... tam, kde jsou relace v relacich a pod.

kdyz uz tu zaznel JOSM, tak jen doplnim, jak se to dela. Drzis klavesu alt a
klikas na linii. Postupne to vybira ty linie pod sebou.

T.

> BTW: Nevim jak se chova iD, nepouzivam, ale hypoteticky by to mohlo jit
> tak, ze z te linie vytahnes dalsi node nekam stranou, cimz odkryjes linii
> pod ni (a nasledne ho pripadne smaznes). Ale mozna ti to ten node hodi pres
> vsechny, pak si nepomuzes. Navic takovych linii muze byt pres sebe vic, a
> pak je tento zpusob prace ponekud nestastny.
>
> Dne 24.10.2019 v 11:17 Petr Vozdecký napsal(a):
> > Ahoj vsem,
> >
> > poradi mi prosim nekdo, jak v iD editoru vybrat prave jednu konkretni >
> > linii, pokud jich je "na sobe" nekolik?
> >
> > Pokud je to jednoduchy soubeh napr. dvou ploch, pak se to da vybrat >
> > nalezenim casti linie, ktera neni nikde v soubehu s jinou. Pokud je to >
> > napr. slozita relace a nektera linie je po cele sve delce v soubehu s >
> > jinymi, je to slozitejsi, ale da se to vybrat krkolome pres relaci. > Ale
> > v ostatnich pripadech jsem u iD editoru v koncich...
> >
> > diky za jakoukoliv radu
> >
> > vop
> >
> > ___
> > 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

Re: [OSM-talk-fr] Osmose et les mauvais noms de communes

[marc marc]

Le 25.10.19 à 09:57, Stéphane Péneau a écrit :
> L'explication de cette erreur [2] indique que dans le cas des communes 
> fusionnées, il faut supprimer le tag re:INSEE du noeud place

> Je pense qu'il faut corriger ça assez vite et supprimer 
> les ref:INSEE des noeuds "place" des communes déléguées. L'idéal serait 
> peut-être de le faire sur tous les noeuds "place" puisque sa place est 
> plutôt sur la relation de la commune

Je partage ton avis : il faut supprimer ref:INSEE de tous les noeuds
vu que la ref concerne la commune et non le village/ville même parfois 
il a le même nom. il y a le même soucis avec les tag wikipedia (qui 
parle souvent de la commune et non spécifiquement du village) et website 
(qui est souvent celui de la mairie et non du village). mais ces 2 
méritent une opération séparée.

> à certains utilisateurs des données (Christian ?)

qui serrait une mauvaise utilisation et qui ne fonctionnerait qu'en 
partie vu qu'une partie des noeuds place ont déjà été corrigé :)

> Je ne sais pas s'il y a un moyen de faire ça de manière plus  
> ou moins automatique.

dans l'idéal, il faut :
- lire 
https://wiki.openstreetmap.org/wiki/FR:Politique_de_modification_automatis%C3%A9e
- changer le titre pour annoncer une demande d'édition de masse
- attendre "un certain temps" pour que tout le monde ai le temps de 
réagir et/ou d'adapter son utilisation erronée éventuelle.
- faire l'opération et la documenter sur le wiki

Si tu n'es pas motivé par la partie "administrative",
je veux bien m'y coller.
sinon je te laisse volontiers le faire :)

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

Re: [Talk-it] mappare sede associazione Esperantista

[Martin Koppenhoefer]

Am Do., 24. Okt. 2019 um 16:57 Uhr schrieb Marco Ciampa :

> > "esperanto=yes" senza contesto mi sembrerebbe più un tag per un
> > oggetto dove si capisce / parla esperanto. Se si riferisce al nome della
> > via, sarei più per un tag come questo:
> > https://taginfo.openstreetmap.org/keys/name%3Aetymology%3Awikidata
>
> Non mi è ben chiaro a che serva questo tag, mi spieghi per favore?



è un tag che descrive l'etimologia del nome della strada (cosa significa /
a cosa si riferisce, spesso sono persone)



> Mi
> pare abbia a che fare con wikipedia, ma non tutto ciò che è marcato con
> un riferimento "esperantista" ha una voce su wikipedia (anzi, ben pochi a
> dir la verità...). Quindi come marcare un tale oggetto?
>


si riferisce a wikidata, e se la voce non c'è la potresti creare, comunque,
esperanto ha il numero 143, quindi ci hanno pensato proprio con priorità :)



>
> > ce ne sono già 61:
> > https://taginfo.openstreetmap.org/tags/name%3Aetymology%3Awikidata=Q143
>
> In tutto il mondo? Pochini... e come avere l'elenco di questi oggetti,
> per capire cosa/dove sono?
>


se guardi in alto a destra sulla pagina linkata, c'è un riferimento a
"overpass turbo", cliccando si apre questo servizio che ti cerca tutti gli
oggetti:
https://overpass-turbo.eu/?w=%22name%3Aetymology%3Awikidata%22%3D%22Q143%22+global

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

Re: [Talk-it] Via Abarth Torino

[Gianluca Boero]

Avevo già letto anche io della notizia su altre fonti.

Non so in che punto è della circoscrizione di Mirafiori.

Per mapparla correttamente bisogna visionare il luogo. Ci passo 
raramente da quelle parti e ora con il blocco del traffico ancora di 
meno. Spero che qualche mappatore di Torino città provveda a inserirla.



Il 24/10/19 22:43, Lorenzo Rolla ha scritto:
Buonasera, non volendo creare problemi sulle mappe, segnalo che è 
stata dedicata una via a Carlo Abarth (costruttore auto sportive). Un 
cordiale saluto.


https://www.fcaheritage.com/it-it/heritage/eventi/via-carlo-abarth

--
Lorenzo Rolla


___
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] 1. Re: Mappare una scuola due

[Martin Koppenhoefer]

Am Fr., 25. Okt. 2019 um 09:07 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> si applica sempre all’oggetto che viene descritto (amenity=school, name
> ecc.), di cui ci deve stare solo uno.




intendevo: per ogni scuola (come entità / istituzione) ci deve stare
un'oggetto amenity=school, ovviamente nello stesso edificio ci possono
essere più scuole.

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

[OSM-talk-fr] Osmose et les mauvais noms de communes

[Stéphane Péneau]

Bonjour,

Par hasard, j'ai constaté le changement de nom d'un noeud "place" qui 
était aussi le nom de la commune, vers le nom de la commune fusionnée.


"Saint-André-Treize-Voies" était devenu "Montréverd" [1]

"Saint-André-Treize-Voies" existe toujours en tant que lieu, et en tant 
que commune déléguée. La modification était donc erronée.



Le changeset mentionnait Osmose, et j'ai retrouvé le type d'erreur en 
question : http://osmose.openstreetmap.fr/fr/errors/?item=6040=802


L'explication de cette erreur [2] indique que dans le cas des communes 
fusionnées, il faut supprimer le tag re:INSEE du noeud place pour éviter 
ce genre de faux positif. Je suis plutôt d'accord avec ça.


En regardant le graphique de ce nombre "d'erreur" [3], on part d'environ 
950 erreurs pour descendre progressivement à 800, puis une grosse chute 
à 650.


On a donc potentiellement de nombreux noeuds "place" erronés dans 
OpenStreetMap. Je pense qu'il faut corriger ça assez vite et supprimer 
les ref:INSEE des noeuds "place" des communes déléguées. L'idéal serait 
peut-être de le faire sur tous les noeuds "place" puisque sa place est 
plutôt sur la relation de la commune, mais je crains que ça pose 
problème à certains utilisateurs des données (Christian ?).


Je ne sais pas s'il y a un moyen de faire ça de manière plus ou moins 
automatique. Pour ma part, j'ai supprimé les ref:INSEE concernés sur les 
Pays de la Loire, et j'ai corrigé ceux qui avaient été incorrectement 
modifiés en m'aidant de la liste "corrigé" d'Osmose :


http://osmose.openstreetmap.fr/fr/errors/done?item=6040=802


Stéphane

[1] https://www.openstreetmap.org/node/432702418/history
[2] https://wiki.openstreetmap.org/wiki/FR:Osmose/issues#6040
[3] http://osmose.openstreetmap.fr/fr/errors/graph.png?item=6040=802


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

[OSM-talk] OSM very old data

[Tom Ka]

Hello,

I'm trying to create map of Czech Republic with older versions of OSM
data. No problem to proceed to 21.04.2009 (first v0.6 data) and with
older (0.35 + --migrate) osmosis to 10.10.2007 (first v0.5 data). All
data are from https://planet.openstreetmap.org/cc-by-sa/. I got in
troubles when I want to go further in history:

- any recommendation for tool/app/etc to process v0.3 data (up to
01.05.2006 on planet/cc-by-sa) (and convert them to v0.6)?
- is history before 01.05.2006 (easily) available (other archive or
local source) (Europe or CZ would be enough)?

Thank you in advance
tkk.

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

Re: [Talk-GB] Zebra crossings being lost in iD - how to respond

[Mateusz Konieczny]

24 Oct 2019, 22:48 by rob.j.nicker...@gmail.com:

> Hi all,
>
> Before I start this message, I would like to say that I am looking for 
> solutions and not wishing to open the flood gates on abuse of the iD editors. 
> On the whole they do a great job and even when we disagree it should be with 
> respect. Right now on to the message itself:
>
>
> It seems like the iD editor's "upgrade this" feature is replacing 
> crossing=zebra with crossing=marked but NOT adding crossing_ref=zebra to the 
> node. If lots of users make use of this "feature" in the UK then we stand to 
> lose some valuable data. Taginfo UK says there are 4,710 crossing=zebra 
> features in the UK.
>
> I have added a comment on to the GitHub issue but no reply yet.
> https://github.com/openstreetmap/iD/issues/6962 
> 
>
I would suggest opening a new issue request GB specific - maybe with something 
like 
"I checked sample of 100 crossing tagged this way, error rate is low".

Comments in a closed issue are likely to be lost/unnoticed.

Though with just 5k crossing it seems that bot edit would be preferable if
- error rate is considered low
- crossing_ref tagging is acceptable
- there is no realistic plan to fight with iD over deprecating crossing=zebra
- bot edits are considered as acceptable

Why bot edit is preferable?
- cooperation with iD developers is not necessary
- more people can do it (I may do it in case of a clear support)
- adding complex region-based handling for 5k objects is making maintenance of 
editor
 complex, it is likely to not be done by iD developers
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] 1. Re: Mappare una scuola due

[Martin Koppenhoefer]

sent from a phone

> Il giorno 24 ott 2019, alle ore 20:46, Cascafico Giovanni 
>  ha scritto:
> 
> Per il tag ref direi che CODICESCUOLA va bene. Resta da capire a che 
> geometria applicarlo



si applica sempre all’oggetto che viene descritto (amenity=school, name ecc.), 
di cui ci deve stare solo uno.

Questi codici le hanno tutte le scuole oppure solo quelle pubbliche?

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

Re: [OSM-talk-fr] Prestation pour déployer des serveurs de tuile OSM

[Vincent Bergeot]

Bonjour,

sans doute connais-tu mais au cas où, je remets la page wiki Fr des 
Services commerciaux basés sur OSM : 
https://wiki.openstreetmap.org/wiki/FR:Services_commerciaux_bas%C3%A9s_sur_OSM


Bonne journée

Le 24/10/2019 à 17:26, Marc SIBERT via Talk-fr a écrit :

Bonjour,

Je suis à la recherche d'une structure qui pourrait accompagner mon 
employeur pour implémenter une solution de serveurs de tuiles OSM 
interne (type mapnik). La solution sera déployée sur des machines 
virtuelles, probablement en CentOS. L'ensemble du travail devra être 
documenté à l'issue de la prestation pour en assurer son exploitation.


Contactez-moi en direct si vous êtes intéressés. Il s'agirait d'une 
prestation dont la durée sera à préciser.


Cordialement,
--
Marc Sibert
m...@sibert.fr 

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



--
Vincent Bergeot

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