Re: [OSM-talk-fr] Urgent pour lundi : projet de loi pour une école de la confiance - soutenir les amendements 836 et 837 - priorité au logiciel libre

[Jean-Christophe Becquet]

Le 12/02/2019 07:18, Jean-Christophe Becquet a écrit :
> Les amendements 836 et 837 proposant l'inscription d'une priorité au
> logiciel libre et aux formats ouverts dans les services publics de
> l'enseignement ont été déplacés « après l'article 24 » du projet de
> loi. Les débats sur le logiciel libre auront sans doute lieu mercredi
> 13 ou jeudi 14 février

Bonjour,

Les débats ont eu lieu vendredi soir. Les amendements ont été rejetés.
Alain, pourrais-tu STP arrêter la cyberaction ?


Frédéric Couchet : Les amendements priorité aux logiciels libres dans
l'éducation ont été rejetés lors de l'examen en séance publique du
projet de loi pour une école de la confiance. Place au Sénat. #DirectAN
#PJLEcole #LoiBlanquer
https://twitter.com/fcouchet/status/1096541335744663553

Les débats en vidéo :
http://videos.assemblee-nationale.fr/video.7282336_5c671f7d1b1fb.3eme-seance--pour-une-ecole-de-la-confiance-suite-15-fevrier-2019
à partir de 01:58:40, durée 8 minutes.
https://twitter.com/fcouchet/status/1096689614247641088

Les amendements :
- 836 http://www.assemblee-nationale.fr/15/amendements/1629/AN/836.asp
- 837 http://www.assemblee-nationale.fr/15/amendements/1629/AN/837.asp


Prochaine étape : le sénat.

Bonne journée

JCB
-- 
Conférence « Communs numériques - Cartes sensibles » 26 février à Digne
https://twitter.com/mairiedigne/status/1092322448769458177

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

Thanks for the heads up. As I said, we are not in a rush here, and will 
first transfer the discussion to the Montreal list, then start a page on 
the import wiki and take it from there. On top, the pre-processing will 
be a bit of work as well.


There is lots of data for the City of Montreal that can be imported: 
fire and police stations, free wifi access, traffic lights, swimming 
pools to name but a few. For now, we are talk about including the 
address and building heights into the building import.


I know from reading the Montreal list that someone else is importing bus 
stops at the moment.


Cheers,
Tim

On 2019-02-16 13:07, John Whelan wrote:
If CC-BY 4.0 works great.  I'd go for any addresses etc and any bus
stops you can get hold of as well.

Just be aware that we had a fairly large number of questions asked about
the license etc when we did Ottawa and one of the people questioning
referred the license to the LWG.  Even the basis of CANVEC licensing
came into question at the time.

Many of the questions came from German and other European mappers.

I understand the City of Toronto's Open Data license was referred as
well but that was about two years ago and I note that the LWG web site
has no mention of it so it is probably still in the queue.

Good Luck

Cheerio John

Tim Elrick wrote on 2019-02-16 12:22 PM:

Hi John,

Thanks for pointing me to the license website. The open data of the 
City of Montreal is licensed CC-BY 4.0 and the City has explicitly 
granted OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original 
open data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

    Hi all,

    After following the building import discussion for a while now, I
    wanted to chime in as well.

    After moving to Montréal from Germany recently, I got more engaged
    with the local mappers here in MTL (beforehand, I was more analysing
    OSM data scientifically).

    I took part in the initial meeting of the Building Canada 2020
    initiative, in which great interest in the project was expressed by
    many institutions, organizations and businesses. However, apart from
    Statistics Canada, municipalities and OSMappers no one seemed to be
    willing to invest into the effort to support the initiative with
    manpower or funding (to my knowledge). Therefore, I found it quite
    impressive what StatCan has achieved with the Open Building Database
    and do not share the view of some on this list that the initiative
    got off on the wrong foot; but that all water under the bridge now.

    So, yes, there seems to be some interest to use the data from the
    Open Building Database in OSM easily. However, I am also hesitant,
    that one massive import can be the answer.

    I'm generally hesitant with imports as such, maybe because I was
    acculturated in OSM in Germany where OSMappers value original
    entries much more than secondary data. Further, I'm skeptical, that
    secondary data is necessary better than original data (even from
    mapathons). I initiated two mapathons with university students in
    the context of Building Canada 2020. Both mapathons resulted in
    mostly nice buildings, I would say - and, when there is the odd
    not-so-nice building, there is still the validation step as we
    always used the tasking manager [1]. By the way, both mapathons used
    the ID editor; and, of course, you can square buildings in ID as
    well; so, I don't really understand the ID editor bashing that
    appears on this list here now and then. That said, of course, I
    prefer JOSM over ID as it is the more versatile tool, but to
    introduce interested persons to editing in OSM, ID is really nice.

    I'm even more skeptical about imports after Yaro pointed us to the
    Texas import [2]. I wonder why there was no outcry there (or maybe
    there was and I did not hear about it) - the imported data is
    terrible: no 

Re: [Talk-es] Importación de límites administrativos de Fornes

[Alejandro S.]

Buenos días,

¿La idea es unir los puntos de amojonaimento con rectas? En el boe definen
más finamente por donde va el límite (siguiendo el trazado de ríos,
acequias y caminos) Aprovechando que son pocos puntos ¿no sería más
interesante trazar el límite aprovechando también esta información?

Saludos,
  Alejandro Suárez


On Thu, 14 Feb 2019 at 12:20, Jesús Lopez  wrote:

> Según el Instituto Nacional de Estadística (INE) [1] además del de Fornes
> se han creado otros seis municipios nuevos en España entre el 1 de enero de
> 2018 y el 1 de enero de 2019. Convendría repasar el estado en que están, si
> ya están creados o si se está prevista su importación.
>
> Saludos,
> Jesús
>
> [1] http://www.ine.es/daco/daco42/codmun/codmunmod.htm
>
> El 14 feb 2019, a las 11:05, Jorge Sanz Sanfructuoso 
> escribió:
>
> Hola.
>
> Esto me ha recordado que faltaba de cambiar otro pueblo en Salamanca qué
> cambio sus fronteras. Mozodiel de Sanchiñigo que cambio de ayuntamiento
> [1][2]. Cuando completes este me miro como ha quedado el tramite de esta
> importación y como va y lo realizo para este otro límite. Y así veo todo el
> proceso de las importaciones como funciona. Habra que dar uso a esa
> "plantilla".
>
> Un saludo.
>
> [1] http://bocyl.jcyl.es/html/2017/01/30/html/BOCYL-D-30012017-4.do
> [2] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2017-1331
>
>
> El mié., 13 feb. 2019 a las 19:16, Rafael Avila Coya (<
> ravilac...@gmail.com>) escribió:
>
>> Hola a todos/as:
>>
>> Carlos Antonio Rivera [1] comentó en grupo de Telegram que deseaba
>> añadir los límites municipales de Fornes [2], en la provincia de Granada.
>>
>> Este municipio se creó con fecha 2 de Octubre de 2019 como segregación
>> del de Arenas del Rey, del que ya era entidad menor local.
>>
>> Para ello he creado una wiki [3], que debemos aún modificar (es sólo un
>> esbozo). Esta wiki, además, puede ser usada como "plantilla" para otras
>> importaciones similares en el futuro.
>>
>> Por lo pronto, una cosa a modificar es que la vía de límite
>> administrativo a importar (límite entre resto de Arenas del Rey y
>> Fornes) se puede (y se debe) mejorar con las descripciones del BOE.
>>
>> Es una importación muy sencillita. Cuando la tengamos lista la
>> comentamos en la lista de imports, y listo para importar.
>>
>> Saludos,
>>
>> Rafael.
>>
>> [1] https://www.openstreetmap.org/user/kapazao
>> [2] https://www.openstreetmap.org/node/1110117318
>> [3]
>>
>> https://wiki.openstreetmap.org/wiki/ES:Importaci%C3%B3n_L%C3%ADmites_Ayuntamiento_de_Fornes_(Granada)#Changeset_Tags
>> 
>>
>
> ___
> 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: [Talk-it] Tag place

[Martin Koppenhoefer]

sent from a phone

> On 16. Feb 2019, at 15:30, Andy Townsend  wrote:
> 
> If the community would like help with reverting these changes then the DWG 
> will be able to assist, but what would be really useful would be a full list 
> of changes that need to be reverted.


There are also other unrelated edits from the past which are unresolved, e.g. 
cs 40996308 is an undiscussed import with potentially incompatible sources (at 
least they haven’t been disclosed), admittedly this is from more than 2 years 
ago (deletes a lot of ways with higher versioncount), is it too late now?


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

Re: [talk-cz] Data telefonich budek

[Majka]

Co zkusit tiskové mluvčí, ať to předají dál?
https://www.o2.cz/spolecnost/279191-media/

Aspoň je to pak konkrétní osoba, sama tím směrem chci jít taky tam, kde lepší 
kontakt není ... 

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

[talk-cz] Data telefonich budek

[Miroslav Suchý]

Narazil jsem na:
https://www.o2.cz/osobni/286484-mapa_pokryti_vta/
Nemate nekdo nejaky rozumny kontakt do O2? Protoze ten moloch ma jenom
infolinky na kterych mi predpokladam nikdo souhlas s exportem pro OSM neda.
Mirek

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

Re: [Talk-transit] Defining service on railway=tram

[Jarek Piórkowski]

On Sat, 16 Feb 2019 at 11:39, Markus  wrote:
>
> Hi Jarek,
>
> I'd welcome a tag for tram tracks that normally aren't used except for 
> diversions (in case of breakdowns, accidents, road/track works, events etc.) 
> or for drives to the depot. However, i'm unsure whether service=siding is a 
> good fit for these tracks. I'm not an expert in trams/trains, but wouldn't 
> service=spur fit better? Otherwise it might make sense to invent a new tag, 
> maybe service=irregular/auxillary/minor/secondary?

Hi Markus,

Thanks for your input.

I agree with you that "siding" is not a good description, but it
seemed the least-wrong one of the 4 railway values in use. "Spur" to
me sounds like something that branches off and ends (as illustrated
for railways). Meanwhile with service=siding I am looking for a
description for tracks that connect two stretches of regular tracks.

I do like your suggestions - "irregular" should be clear enough, and I
like "auxillary" as well except I don't know if its meaning is
commonly-enough understood. "Minor" seems like it could be
misunderstood: if you have two lines, one of which runs more
frequently than the other, are the tracks of the less-frequent line
"minor"? Or how about service=detour?

I chose "siding" because I didn't want to invent new tag value, to
avoid too big and slow of a change. But maybe we should do it, what do
you think?

Existing values are used:
- in editor presets, including iD and JOSM presets for tram tracks -
both have "Spur", "Yard", "Siding", and "Crossover" in a dropdown for
tram tracks, so matching the railway ones. Arguably it would be good
to update those values for tram anyway, e.g. if we were to recommend
that "spur" not be used on trams
- in rendering: default layer hardcodes 3 current values for tram
service (excluding crossover) - though if I'm understanding it right,
it should be easy enough to change in
https://github.com/gravitystorm/openstreetmap-carto/blob/dd096af4f566eb9c31e50ac447215f68e45b563f/project.mml#L514
- transport layer seems to render service=siding thinner, but
presumably also updateable; openrailwaymap doesn't seem to render tram
service tags in a special way so no problem there

Or how about if we were recommend that of the current options, siding
should be used (to attempt to standardize what we have); and in
parallel launch a formal proposal process for adding more proper tram
service=irregular?

Thanks again,
--Jarek

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

Re: [Talk-ca] Some feedback on import quality in Toronto

[John Whelan]

If CC-BY 4.0 works great.  I'd go for any addresses etc and any bus 
stops you can get hold of as well.


Just be aware that we had a fairly large number of questions asked about 
the license etc when we did Ottawa and one of the people questioning 
referred the license to the LWG.  Even the basis of CANVEC licensing 
came into question at the time.


Many of the questions came from German and other European mappers.

I understand the City of Toronto's Open Data license was referred as 
well but that was about two years ago and I note that the LWG web site 
has no mention of it so it is probably still in the queue.


Good Luck

Cheerio John

Tim Elrick wrote on 2019-02-16 12:22 PM:

Hi John,

Thanks for pointing me to the license website. The open data of the 
City of Montreal is licensed CC-BY 4.0 and the City has explicitly 
granted OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original 
open data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

    Hi all,

    After following the building import discussion for a while now, I
    wanted to chime in as well.

    After moving to Montréal from Germany recently, I got more engaged
    with the local mappers here in MTL (beforehand, I was more analysing
    OSM data scientifically).

    I took part in the initial meeting of the Building Canada 2020
    initiative, in which great interest in the project was expressed by
    many institutions, organizations and businesses. However, apart from
    Statistics Canada, municipalities and OSMappers no one seemed to be
    willing to invest into the effort to support the initiative with
    manpower or funding (to my knowledge). Therefore, I found it quite
    impressive what StatCan has achieved with the Open Building Database
    and do not share the view of some on this list that the initiative
    got off on the wrong foot; but that all water under the bridge now.

    So, yes, there seems to be some interest to use the data from the
    Open Building Database in OSM easily. However, I am also hesitant,
    that one massive import can be the answer.

    I'm generally hesitant with imports as such, maybe because I was
    acculturated in OSM in Germany where OSMappers value original
    entries much more than secondary data. Further, I'm skeptical, that
    secondary data is necessary better than original data (even from
    mapathons). I initiated two mapathons with university students in
    the context of Building Canada 2020. Both mapathons resulted in
    mostly nice buildings, I would say - and, when there is the odd
    not-so-nice building, there is still the validation step as we
    always used the tasking manager [1]. By the way, both mapathons used
    the ID editor; and, of course, you can square buildings in ID as
    well; so, I don't really understand the ID editor bashing that
    appears on this list here now and then. That said, of course, I
    prefer JOSM over ID as it is the more versatile tool, but to
    introduce interested persons to editing in OSM, ID is really nice.

    I'm even more skeptical about imports after Yaro pointed us to the
    Texas import [2]. I wonder why there was no outcry there (or maybe
    there was and I did not hear about it) - the imported data is
    terrible: no parallel to street buildings, no right angles,
    sometimes even not the right size of building parts. Fact is that
    secondary data buildings footprints can be from many different data
    sources - from AutoCAD, handdrawn by a municipal GIS experts to
    photogrammetric and satellite machine learning sources; all those
    sources have their peculiarities, which I think, you cannot satisfy
    in one import plan fits all - especially, as the Open Building
    Database in Canada is stitched together from those very different
    sources.

    In Montreal, e.g., the source for the Open Building Database is the
    données ouvertes des 

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

Hi John,

Thanks for pointing me to the license website. The open data of the City 
of Montreal is licensed CC-BY 4.0 and the City has explicitly granted 
OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original open 
data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

Hi all,

After following the building import discussion for a while now, I
wanted to chime in as well.

After moving to Montréal from Germany recently, I got more engaged
with the local mappers here in MTL (beforehand, I was more analysing
OSM data scientifically).

I took part in the initial meeting of the Building Canada 2020
initiative, in which great interest in the project was expressed by
many institutions, organizations and businesses. However, apart from
Statistics Canada, municipalities and OSMappers no one seemed to be
willing to invest into the effort to support the initiative with
manpower or funding (to my knowledge). Therefore, I found it quite
impressive what StatCan has achieved with the Open Building Database
and do not share the view of some on this list that the initiative
got off on the wrong foot; but that all water under the bridge now.

So, yes, there seems to be some interest to use the data from the
Open Building Database in OSM easily. However, I am also hesitant,
that one massive import can be the answer.

I'm generally hesitant with imports as such, maybe because I was
acculturated in OSM in Germany where OSMappers value original
entries much more than secondary data. Further, I'm skeptical, that
secondary data is necessary better than original data (even from
mapathons). I initiated two mapathons with university students in
the context of Building Canada 2020. Both mapathons resulted in
mostly nice buildings, I would say - and, when there is the odd
not-so-nice building, there is still the validation step as we
always used the tasking manager [1]. By the way, both mapathons used
the ID editor; and, of course, you can square buildings in ID as
well; so, I don't really understand the ID editor bashing that
appears on this list here now and then. That said, of course, I
prefer JOSM over ID as it is the more versatile tool, but to
introduce interested persons to editing in OSM, ID is really nice.

I'm even more skeptical about imports after Yaro pointed us to the
Texas import [2]. I wonder why there was no outcry there (or maybe
there was and I did not hear about it) - the imported data is
terrible: no parallel to street buildings, no right angles,
sometimes even not the right size of building parts. Fact is that
secondary data buildings footprints can be from many different data
sources - from AutoCAD, handdrawn by a municipal GIS experts to
photogrammetric and satellite machine learning sources; all those
sources have their peculiarities, which I think, you cannot satisfy
in one import plan fits all - especially, as the Open Building
Database in Canada is stitched together from those very different
sources.

In Montreal, e.g., the source for the Open Building Database is the
données ouvertes des batiments. This is photogrammetric imagery
probably turned into AutoCAD files, which then were exported to a
shapefile and geojson. The building outlines are impressively
precise, however, the open data files contain building blocks not
single buildings [3], however, offer building dividers in a separate
shapefile (I assume due to the export from AutoCAD, see second image
in [3]). Unfortunately, the Open Building Database only included
those building blocks in their data set, making it not very easy to
import into OSM (as they do not include the building dividers).
Hence, a bit of non-trivial pre-processing of the original données
ouvertes des 

Re: [Talk-transit] Defining service on railway=tram

[Markus]

Hi Jarek,

I'd welcome a tag for tram tracks that normally aren't used except for
diversions (in case of breakdowns, accidents, road/track works, events
etc.) or for drives to the depot. However, i'm unsure whether
service=siding is a good fit for these tracks. I'm not an expert in
trams/trains, but wouldn't service=spur fit better? Otherwise it might make
sense to invent a new tag, maybe
service=irregular/auxillary/minor/secondary?

Regards

Markus

On Mon, 11 Feb 2019, 17:35 Jarek Piórkowski  Hello,
>
> In tram systems, some of the tracks might not be used regularly for
> passenger service. Some might be garage or work area tracks, and
> others might be used only for detours or emergency service.
>
> The `service` key seems a natural match for tagging this, but its
> values specified for railways aren't a close fit for trams (a railway
> "yard" is somewhat different from a tram "yard", trams rarely have
> "spurs", etc) and tram-specific values were never defined. I have
> looked into various values currently used in tagging systems around
> the world and would like to suggest tram-specific guidelines to add to
> Key:service on wiki.
>
> Please see
> https://wiki.openstreetmap.org/wiki/User:Jarek_Pi%C3%B3rkowski/Key:service
> for the suggested addition and
> https://lists.openstreetmap.org/pipermail/tagging/2019-January/042313.html
> for more background including a survey of existing tagging.
>
> Any thoughts are welcome, in particular if someone has an opinion on
> whether this warrants a formal proposal process.
>
> Thanks,
> --Jarek
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-ca] Some feedback on import quality in Toronto

[john whelan]

When you look at importing Montreal you might like to look at the following
first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper record
fine but if they are no longer part of the community then there maybe a
problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick  wrote:

> Hi all,
>
> After following the building import discussion for a while now, I wanted
> to chime in as well.
>
> After moving to Montréal from Germany recently, I got more engaged with
> the local mappers here in MTL (beforehand, I was more analysing OSM data
> scientifically).
>
> I took part in the initial meeting of the Building Canada 2020 initiative,
> in which great interest in the project was expressed by many institutions,
> organizations and businesses. However, apart from Statistics Canada,
> municipalities and OSMappers no one seemed to be willing to invest into the
> effort to support the initiative with manpower or funding (to my
> knowledge). Therefore, I found it quite impressive what StatCan has
> achieved with the Open Building Database and do not share the view of some
> on this list that the initiative got off on the wrong foot; but that all
> water under the bridge now.
>
> So, yes, there seems to be some interest to use the data from the Open
> Building Database in OSM easily. However, I am also hesitant, that one
> massive import can be the answer.
>
> I'm generally hesitant with imports as such, maybe because I was
> acculturated in OSM in Germany where OSMappers value original entries much
> more than secondary data. Further, I'm skeptical, that secondary data is
> necessary better than original data (even from mapathons). I initiated two
> mapathons with university students in the context of Building Canada 2020.
> Both mapathons resulted in mostly nice buildings, I would say - and, when
> there is the odd not-so-nice building, there is still the validation step
> as we always used the tasking manager [1]. By the way, both mapathons used
> the ID editor; and, of course, you can square buildings in ID as well; so,
> I don't really understand the ID editor bashing that appears on this list
> here now and then. That said, of course, I prefer JOSM over ID as it is the
> more versatile tool, but to introduce interested persons to editing in OSM,
> ID is really nice.
>
> I'm even more skeptical about imports after Yaro pointed us to the Texas
> import [2]. I wonder why there was no outcry there (or maybe there was and
> I did not hear about it) - the imported data is terrible: no parallel to
> street buildings, no right angles, sometimes even not the right size of
> building parts. Fact is that secondary data buildings footprints can be
> from many different data sources - from AutoCAD, handdrawn by a municipal
> GIS experts to photogrammetric and satellite machine learning sources; all
> those sources have their peculiarities, which I think, you cannot satisfy
> in one import plan fits all - especially, as the Open Building Database in
> Canada is stitched together from those very different sources.
>
> In Montreal, e.g., the source for the Open Building Database is the
> données ouvertes des batiments. This is photogrammetric imagery probably
> turned into AutoCAD files, which then were exported to a shapefile and
> geojson. The building outlines are impressively precise, however, the open
> data files contain building blocks not single buildings [3], however, offer
> building dividers in a separate shapefile (I assume due to the export from
> AutoCAD, see second image in [3]). Unfortunately, the Open Building
> Database only included those building blocks in their data set, making it
> not very easy to import into OSM (as they do not include the building
> dividers). Hence, a bit of non-trivial pre-processing of the original
> données ouvertes des batiments would be necessary to import them into OSM
> (as the building divider file does also include roof extensions and roof
> shapes). The local OSM group is discussing this pre-processing for a while
> now at their local meetings (we started discussing this even before the
> Building Canada 2020 initiative started). As the City of Montreal has
> granted OSM the explicit use of their open data file, the way forward, we
> think, is to pre-process the original files. Further, there is extensive
> overlap of existing buildings with the open data file. Therefore, the
> imports in Montreal would have to happen in very small batches to not
> destroy the work of other OSMappers.
>
> I am also pretty skeptical about the simplification of the secondary data
> before importing that was suggested on the list 

[Talk-it] R: R: R: R: R: Tag place

[Fayor Uno]

Sul revert motivato solo su una questione di "approccio" è chiaro che non sono 
d'accordo. Nonostante quello che qualcuno vuole fare credere, non faccio 
import, modifiche automatiche o roba simile. Ogni modifica è ponderata e frutto 
di analisi di dati, rimane comunque opinabile come del resto ogni cosa, ma è 
fatta innanzitutto in buona fede e seguendo le linee esistenti di mappatura.

Ho risposto alle critiche di chiunque, anche di chi a mio parere conosce poco o 
nulla dell'argomento, e non penso mi si possa rimproverare di dire 
stupidaggini. Espongo il mio modo di pensare per onestà intellettuale, che 
penso qualcuno anche qui in lista condivida, anche se non si esprime.
E sono consapevole che per alcuni, chiamiamoli maggioranza qualificata, questo 
non valga nulla, ma pazienza, il popolo è sovrano quantitativamente e a volte 
solo pigro, come dimostra la vicenda dei toponimi sardi.

Da: Andrea Albani 
Inviato: sabato 16 febbraio 2019 14:24
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] R: R: R: R: Tag place

Il giorno sab 16 feb 2019 alle ore 13:06 Fayor Uno 
mailto:fay...@hotmail.com>> ha scritto:
Quale sarebbe il nesso tra l'ultimo mio messaggio da cui sei voluto ripartire e 
quello che hai scritto?

Una cosa banale... il fatto che era l'ultimo tuo del thread.

Quel messaggio mi sembra orientato proprio verso il miglioramento del senso di 
comunità, in quanto esprime accordo a una modifica di quanto attualmente 
previsto dal wiki e lancia una proposta.

Prendo atto, ma intanto le tue modifiche a tappeto sono lì sulla mappa. Ripeto 
non è una questione tecnica ("ho agito riportando il tutto alle specifiche 
della wiki"), ma di approccio.

Per i tag place io sono d'accordo nel considerare quanto proposto da Andrea 
Musuruane e discusso in ML inglese, ovvero un approccio "qualitativo" senza 
crociate sulla population.

La ML mi sembra si sia espressa in maggioranza relativa anche per alcuni revert 
motivati. Qual'è il tuo intendimento su questo ?

Il giorno sab 16 feb 2019 alle ore 13:06 Fayor Uno 
mailto:fay...@hotmail.com>> ha scritto:
Quale sarebbe il nesso tra l'ultimo mio messaggio da cui sei voluto ripartire e 
quello che hai scritto?
Quel messaggio mi sembra orientato proprio verso il miglioramento del senso di 
comunità, in quanto esprime accordo a una modifica di quanto attualmente 
previsto dal wiki e lancia una proposta.



Da: Andrea Albani mailto:aob...@gmail.com>>
Inviato: sabato 16 febbraio 2019 11:15
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] R: R: R: R: Tag place

Ciao Fayor,

vorrei ripartire da questo tuo ultimo messaggio per focalizzare l'attenzione 
non tanto sul dettaglio, ma su una questione di fondo.
Non sei nuovo in OSM così come in questa lista e non ho dubbi che tu sia mosso 
dall'intenzione di migliorare la mappa, ma alcune volte agisci come se mappare 
fosse un'attività privata.
Ti è stato fatto notare nelle discussioni di diversi tuoi changeset dove hai 
prese di posizione molto nette derivanti dalla certezza che hai di operare 
secondo le regole.
Nel caso che ha animato questo thread appare chiaro che hai molta attenzione 
per ciò che è scritto sulla wiki, ma sembra che tu ponga in secondo piano le 
altre regole "sociali", la "stratificazione storica" delle feature della mappa 
e l'opinione dei mappatori locali.
Fai cambiamenti importanti in territori così distanti fra loro che, 
diciamocelo, con altissima probabilità non frequenti, e lo fai senza far sapere 
prima alla comunità cos'hai intenzione di fare. Mi rendo conto che è più 
oneroso parlarne prima, trovare una sintesi delle posizioni e poi apportare i 
change, ma è quello che fa funzionare OSM come progetto condiviso.
Per motivi simili a quanto sopra sei per altro già stato "ammonito" 3 volte con 
3 user blocks, l'ultimo sei mesi fa. In uno di questi, ad opera di Andy 
Townsend, che penso possiamo ritenere al di sopra delle parti, c'è questa frase:

"Rather than simply restating your case over and over again I would suggest 
that you try and work together with those in the OSM community in Italy who 
hold different views to you to try and understand their position rather than 
simply imposing a top-down solution."

Mi piace pensare che questa occasione possa essere di stimolo a migliorare il 
nostro senso di comunità per fortuna già ben espresso in ML da molti esempi 
positivi.

Ciao


Il giorno ven 15 feb 2019 alle ore 19:25 Fayor Uno 
mailto:fay...@hotmail.com>> ha scritto:
Sono d'accordo, ma è necessario trovare un criterio il più possibile oggettivo 
e verificabile, altrimenti per Tizio un posto è una città e per Caio è un paese.
Io propongo di considerare inizialmente la popolazione ed apportare correttivi 
nei casi più dubbi, magari anche con l'elenco dettagliato e condiviso delle 
località che derogano alla regola.


Da: Alecs via Talk-it 
mailto:talk-it@openstreetmap.org>>
Inviato: 

Re: [Talk-it] Tag place

[Andy Townsend]

(apologies for posting in English; Italian auto-translation follows)

Obviously, we've been here before with this user.  I've asked at 
https://www.openstreetmap.org/changeset/66616609 where that mechanical 
edit was first discussed.  I'm guessing, from reading this thread, that 
it wasn't.  It also seems that people here are broadly in favour of 
reverting these changes.


If the community would like help with reverting these changes then the 
DWG will be able to assist, but what would be really useful would be a 
full list of changes that need to be reverted.


Best Regards,

Andy Townsend, on behalf of OSM's Data Working Group


(traduzione automatica)

Ovviamente, siamo già stati qui con questo utente. Ho chiesto a 
https://www.openstreetmap.org/changeset/66616609 dove è stata discussa 
per la prima volta quella modifica meccanica. Sto indovinando, dalla 
lettura di questo thread, che non lo era. Sembra anche che le persone 
qui siano ampiamente a favore del ripristino di questi cambiamenti.


Se la comunità desidera aiutare a ripristinare queste modifiche, il DWG 
sarà in grado di fornire assistenza, ma ciò che sarebbe davvero utile 
sarebbe un elenco completo di modifiche che devono essere ripristinate.


I migliori saluti,

Andy Townsend, a nome del Data Working Group di OSM
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] R: R: R: R: Tag place

[Alecs via Talk-it]

E' inevitabile che siano casi singoli di disaccordo, nel mondo reale nemmeno
la distizione tra amenity=restaurant e amenity=cafe (o bar, pub, fast_food)
è così netta, può capitare che locali di una stessa catena siano
classificati da mappatori diversi in modo diverso, eppure funziona nel
complesso, non mi sembra ci sia bisogno di regole particolarmente
stringenti. Così come funziona la classificazione delle strade per
importanza, che è un caso simile a questo dei centri abitati. Capitano casi
di disaccordo, ma in generale funziona più che bene, pur senza criteri
rigidi di riferimento, il buon senso di chi conosce la zona è sufficiente.

Escluderei la lista scritta di eccezioni, mi sembra ingestibile, sarebbe
solo una complicazione in più.

Concordo in toto con il messaggio di Andrea Albani.

Aggiungerei una nota a margine: per la quantità di dati presenti in OSM, la
classificazione dei centri abitati, per quanto immediatamente evidente su di
una mappa agli occhi di chi la osserva per la prima volta, non è nemmeno una
delle questioni a cui credo vada dedicato troppo tempo a mio parere. Non c'è
bisogno di OpenStreetMap per sapere quanti abitanti ha Crevalcore e se è più
o meno grande di Casalecchio di Reno, ce n'è bisogno per avere
(potenzialmente) a disposizione tutte le strade, gli edifici, i numeri
civici e molti altri dettagli di entrambi.

Alessandro


fayor wrote
> Sono d'accordo, ma è necessario trovare un criterio il più possibile
> oggettivo e verificabile, altrimenti per Tizio un posto è una città e per
> Caio è un paese.
> Io propongo di considerare inizialmente la popolazione ed apportare
> correttivi nei casi più dubbi, magari anche con l'elenco dettagliato e
> condiviso delle località che derogano alla regola.





--
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: [OSM-talk-fr] Terrain militaire

[Vincent Privat]

Qu'est-ce qui te fait penser que la zone militaire est plus restreinte que
l'enceinte du fort ?

Le ven. 15 févr. 2019 à 16:26, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Florian LAINEZ" 
> >
> > Hello,
> > Je me demande s'il existe un jeu de données Open Data qui délimite
> > les zones militaires en France. Je n'ai rien trouvé sur data.gouv.fr
> > ni autre part.
> >
> > Use case : en me penchant sur le fort de Montrouge , je pense que la
> > zone militaire est bien moins grande que l'enceinte effective du
> > fort historique. Je ne comprends d'ailleurs pas pourquoi sur
> > l'orthophoto de l'IGN cette zone n'est pas floutée comme pour les
> > autres zones militaires. D'ailleurs peut-être quelqu'un a-t-il
> > recensé ces zones floutées (à la main ou en rétro-ingénierie) ?
> >
> > Question subsidiaire : quel tag utiliser sur les routes dans les
> > zones militaires ? access=no me parait le meilleur candidat mais ne
> > retranscrit pas vraiment la réalité. access=private ne me convient
> > pas non plus. Je vois que les valeurs restricted ou military sont
> > également utilisées mais elles ne sont pas documentées.
>
> Le jeu de données que ça m'évoque c'est
> https://www.geoportail.gouv.fr/donnees/zones-interdites-a-la-prise-de-vue-aerienne
> mais ça n'est pas strictement un jeu de données sur les zones militaires.
> En plus le Fort de Montrouge n'y est même pas recensé... Bref je réponds à
> côté /o\
>
> vincent
>
> ___
> 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] R: R: R: R: Tag place

[Andrea Albani]

 Il giorno sab 16 feb 2019 alle ore 13:06 Fayor Uno  ha
scritto:

> Quale sarebbe il nesso tra l'ultimo mio messaggio da cui sei voluto
> ripartire e quello che hai scritto?
>

Una cosa banale... il fatto che era l'ultimo tuo del thread.

Quel messaggio mi sembra orientato proprio verso il miglioramento del senso
> di comunità, in quanto esprime accordo a una modifica di quanto attualmente
> previsto dal wiki e lancia una proposta.
>
> Prendo atto, ma intanto le tue modifiche a tappeto sono lì sulla mappa.
Ripeto non è una questione tecnica ("ho agito riportando il tutto alle
specifiche della wiki"), ma di approccio.

Per i tag place io sono d'accordo nel considerare quanto proposto da Andrea
Musuruane e discusso in ML inglese, ovvero un approccio "qualitativo" senza
crociate sulla population.

La ML mi sembra si sia espressa in maggioranza relativa anche per alcuni
revert motivati. Qual'è il tuo intendimento su questo ?

Il giorno sab 16 feb 2019 alle ore 13:06 Fayor Uno  ha
scritto:

> Quale sarebbe il nesso tra l'ultimo mio messaggio da cui sei voluto
> ripartire e quello che hai scritto?
> Quel messaggio mi sembra orientato proprio verso il miglioramento del
> senso di comunità, in quanto esprime accordo a una modifica di quanto
> attualmente previsto dal wiki e lancia una proposta.
>
>
> --
> *Da:* Andrea Albani 
> *Inviato:* sabato 16 febbraio 2019 11:15
> *A:* openstreetmap list - italiano
> *Oggetto:* Re: [Talk-it] R: R: R: R: Tag place
>
> Ciao Fayor,
>
> vorrei ripartire da questo tuo ultimo messaggio per focalizzare
> l'attenzione non tanto sul dettaglio, ma su una questione di fondo.
> Non sei nuovo in OSM così come in questa lista e non ho dubbi che tu sia
> mosso dall'intenzione di migliorare la mappa, ma alcune volte agisci come
> se mappare fosse un'attività privata.
> Ti è stato fatto notare nelle discussioni di diversi tuoi changeset dove
> hai prese di posizione molto nette derivanti dalla certezza che hai di
> operare secondo le regole.
> Nel caso che ha animato questo thread appare chiaro che hai molta
> attenzione per ciò che è scritto sulla wiki, ma sembra che tu ponga in
> secondo piano le altre regole "sociali", la "stratificazione storica" delle
> feature della mappa e l'opinione dei mappatori locali.
> Fai cambiamenti importanti in territori così distanti fra loro che,
> diciamocelo, con altissima probabilità non frequenti, e lo fai senza far
> sapere prima alla comunità cos'hai intenzione di fare. Mi rendo conto che è
> più oneroso parlarne prima, trovare una sintesi delle posizioni e poi
> apportare i change, ma è quello che fa funzionare OSM come progetto
> condiviso.
> Per motivi simili a quanto sopra sei per altro già stato "ammonito" 3
> volte con 3 user blocks, l'ultimo sei mesi fa. In uno di questi, ad opera
> di Andy Townsend, che penso possiamo ritenere al di sopra delle parti, c'è
> questa frase:
>
> "Rather than simply restating your case over and over again I would
> suggest that you try and work together with those in the OSM community in
> Italy who hold different views to you to try and understand their position
> rather than simply imposing a top-down solution."
>
> Mi piace pensare che questa occasione possa essere di stimolo a migliorare
> il nostro senso di comunità per fortuna già ben espresso in ML da molti
> esempi positivi.
>
> Ciao
>
>
> Il giorno ven 15 feb 2019 alle ore 19:25 Fayor Uno 
> ha scritto:
>
> Sono d'accordo, ma è necessario trovare un criterio il più possibile
> oggettivo e verificabile, altrimenti per Tizio un posto è una città e per
> Caio è un paese.
> Io propongo di considerare inizialmente la popolazione ed apportare
> correttivi nei casi più dubbi, magari anche con l'elenco dettagliato e
> condiviso delle località che derogano alla regola.
>
> --
> *Da:* Alecs via Talk-it 
> *Inviato:* venerdì 15 febbraio 2019 18:50
> *A:* talk-it@openstreetmap.org
> *Cc:* Alecs
> *Oggetto:* Re: [Talk-it] R: R: R: Tag place
>
> Andrea Musuruane wrote
> >  Tra l'altro se la funzione population->place fosse *iniettiva* non
> > avremmo bisogno del tag place.
>
> Esatto, il nodo della questione è sempre quello, se place dipende così
> rigidamente dalla popolazione, non ha senso di esistere come tag a sè.
> Invece lo ha proprio nella misura in cui l'importanza di un centro abitato
> dipende anche da altro.
>
> Non ci vedo nulla di strano se ad esempio Vipiteno (che fayor ha appena
> cambiato da town a village perchè ha meno di 6 mila abitanti, dopo che per
> anni era stata town https://www.openstreetmap.org/node/64777232/history)
> sia
> più importante di Favaro Veneto (che lo stesso fayor ha promosso a town
> perchè supera di poco i 10 mila
> https://www.openstreetmap.org/node/697239111/history). Il primo è il
> centro
> più importante della sua valle, il secondo è praticamente una propaggine di
> Mestre, difatti i mappatori locali le avevano taggate in modo diverso
> (Favaro Veneto era perfino 

[Talk-it] R: R: R: R: R: Tag place

[Fayor Uno]

Quale sarebbe il nesso tra l'ultimo mio messaggio da cui sei voluto ripartire e 
quello che hai scritto?
Quel messaggio mi sembra orientato proprio verso il miglioramento del senso di 
comunità, in quanto esprime accordo a una modifica di quanto attualmente 
previsto dal wiki e lancia una proposta.



Da: Andrea Albani 
Inviato: sabato 16 febbraio 2019 11:15
A: openstreetmap list - italiano
Oggetto: Re: [Talk-it] R: R: R: R: Tag place

Ciao Fayor,

vorrei ripartire da questo tuo ultimo messaggio per focalizzare l'attenzione 
non tanto sul dettaglio, ma su una questione di fondo.
Non sei nuovo in OSM così come in questa lista e non ho dubbi che tu sia mosso 
dall'intenzione di migliorare la mappa, ma alcune volte agisci come se mappare 
fosse un'attività privata.
Ti è stato fatto notare nelle discussioni di diversi tuoi changeset dove hai 
prese di posizione molto nette derivanti dalla certezza che hai di operare 
secondo le regole.
Nel caso che ha animato questo thread appare chiaro che hai molta attenzione 
per ciò che è scritto sulla wiki, ma sembra che tu ponga in secondo piano le 
altre regole "sociali", la "stratificazione storica" delle feature della mappa 
e l'opinione dei mappatori locali.
Fai cambiamenti importanti in territori così distanti fra loro che, 
diciamocelo, con altissima probabilità non frequenti, e lo fai senza far sapere 
prima alla comunità cos'hai intenzione di fare. Mi rendo conto che è più 
oneroso parlarne prima, trovare una sintesi delle posizioni e poi apportare i 
change, ma è quello che fa funzionare OSM come progetto condiviso.
Per motivi simili a quanto sopra sei per altro già stato "ammonito" 3 volte con 
3 user blocks, l'ultimo sei mesi fa. In uno di questi, ad opera di Andy 
Townsend, che penso possiamo ritenere al di sopra delle parti, c'è questa frase:

"Rather than simply restating your case over and over again I would suggest 
that you try and work together with those in the OSM community in Italy who 
hold different views to you to try and understand their position rather than 
simply imposing a top-down solution."

Mi piace pensare che questa occasione possa essere di stimolo a migliorare il 
nostro senso di comunità per fortuna già ben espresso in ML da molti esempi 
positivi.

Ciao


Il giorno ven 15 feb 2019 alle ore 19:25 Fayor Uno 
mailto:fay...@hotmail.com>> ha scritto:
Sono d'accordo, ma è necessario trovare un criterio il più possibile oggettivo 
e verificabile, altrimenti per Tizio un posto è una città e per Caio è un paese.
Io propongo di considerare inizialmente la popolazione ed apportare correttivi 
nei casi più dubbi, magari anche con l'elenco dettagliato e condiviso delle 
località che derogano alla regola.


Da: Alecs via Talk-it 
mailto:talk-it@openstreetmap.org>>
Inviato: venerdì 15 febbraio 2019 18:50
A: talk-it@openstreetmap.org
Cc: Alecs
Oggetto: Re: [Talk-it] R: R: R: Tag place

Andrea Musuruane wrote
>  Tra l'altro se la funzione population->place fosse *iniettiva* non
> avremmo bisogno del tag place.

Esatto, il nodo della questione è sempre quello, se place dipende così
rigidamente dalla popolazione, non ha senso di esistere come tag a sè.
Invece lo ha proprio nella misura in cui l'importanza di un centro abitato
dipende anche da altro.

Non ci vedo nulla di strano se ad esempio Vipiteno (che fayor ha appena
cambiato da town a village perchè ha meno di 6 mila abitanti, dopo che per
anni era stata town https://www.openstreetmap.org/node/64777232/history) sia
più importante di Favaro Veneto (che lo stesso fayor ha promosso a town
perchè supera di poco i 10 mila
https://www.openstreetmap.org/node/697239111/history). Il primo è il centro
più importante della sua valle, il secondo è praticamente una propaggine di
Mestre, difatti i mappatori locali le avevano taggate in modo diverso
(Favaro Veneto era perfino suburb, ma evidentemente il fatto che in mezzo ci
sia un confine di municipalità cambia tutto). Stesso discorso per Chiavenna
ad esempio, potrebbe benissimo essere town
https://www.openstreetmap.org/node/62516647/history
Non prendiamoci in giro, non stiamo parlando di 20 modifiche, sono decine e
decine fatte tutte allo stesso modo.

La cosa che proprio non ha senso, e che purtoppo succede spesso, è cambiare
la classificazione di un centro abitato giusto perchè ha qualche decina di
abitanti in più o in meno della mitica soglia dei 10 mila, come se da un
mese all'altro l'importanza di un centro abitato potesse veramente cambiare
per qualche famiglia che si è trasferita, perchè di questo stiamo parlando.
Di esempi penso ce ne siano molti, al volo ho trovato questi:
Verucchio https://www.openstreetmap.org/node/69301805/history
Vigonovo https://www.openstreetmap.org/node/64778773/history
San Felice Circeo https://www.openstreetmap.org/node/72961005/history
Asola https://www.openstreetmap.org/node/62513613/history
Monteriggioni 

Re: [talk-ph] Feb 16 Mindanao Mapping Party

[maning sambale]

I’ve had discussions with OSMF and HOT the guidelines don’t really apply to
> volunteer mapping parties
>

This is great information. May we get a public record of this discussion?
I was not personally aware of exemptions in the guidelines provided by the
OSMF:
https://wiki.osmfoundation.org/w/images/6/62/Organised_Editing_Guidelines.pdf


> This kicks off a four month first phase initiative as we continue field
> work and OSM mapping workshops, map validation and community building
> across 60 local municipalities and NGOs in Mindanao.
>

The above statements does not add up to me based on the previous statement
that this is a volunteer effort though.


> For the validation, we have a support group to help ensure new mappers
> have a positive experience and aren’t intimidated by other mapper’s
> comments. They will tag their edits as #newbie. Local Youthmappers
> chapters, George Washington University Humanitarianian Mapping Society, and
> HOT will support the validation of their edits and provide community and
> technical support.
>

Looking forward to the validation process!

cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://github.com/maning
http://twitter.com/maningsambale
--
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-it] R: R: R: R: Tag place

[Andrea Albani]

Ciao Fayor,

vorrei ripartire da questo tuo ultimo messaggio per focalizzare
l'attenzione non tanto sul dettaglio, ma su una questione di fondo.
Non sei nuovo in OSM così come in questa lista e non ho dubbi che tu sia
mosso dall'intenzione di migliorare la mappa, ma alcune volte agisci come
se mappare fosse un'attività privata.
Ti è stato fatto notare nelle discussioni di diversi tuoi changeset dove
hai prese di posizione molto nette derivanti dalla certezza che hai di
operare secondo le regole.
Nel caso che ha animato questo thread appare chiaro che hai molta
attenzione per ciò che è scritto sulla wiki, ma sembra che tu ponga in
secondo piano le altre regole "sociali", la "stratificazione storica" delle
feature della mappa e l'opinione dei mappatori locali.
Fai cambiamenti importanti in territori così distanti fra loro che,
diciamocelo, con altissima probabilità non frequenti, e lo fai senza far
sapere prima alla comunità cos'hai intenzione di fare. Mi rendo conto che è
più oneroso parlarne prima, trovare una sintesi delle posizioni e poi
apportare i change, ma è quello che fa funzionare OSM come progetto
condiviso.
Per motivi simili a quanto sopra sei per altro già stato "ammonito" 3 volte
con 3 user blocks, l'ultimo sei mesi fa. In uno di questi, ad opera di Andy
Townsend, che penso possiamo ritenere al di sopra delle parti, c'è questa
frase:

"Rather than simply restating your case over and over again I would suggest
that you try and work together with those in the OSM community in Italy who
hold different views to you to try and understand their position rather
than simply imposing a top-down solution."

Mi piace pensare che questa occasione possa essere di stimolo a migliorare
il nostro senso di comunità per fortuna già ben espresso in ML da molti
esempi positivi.

Ciao


Il giorno ven 15 feb 2019 alle ore 19:25 Fayor Uno  ha
scritto:

> Sono d'accordo, ma è necessario trovare un criterio il più possibile
> oggettivo e verificabile, altrimenti per Tizio un posto è una città e per
> Caio è un paese.
> Io propongo di considerare inizialmente la popolazione ed apportare
> correttivi nei casi più dubbi, magari anche con l'elenco dettagliato e
> condiviso delle località che derogano alla regola.
>
> --
> *Da:* Alecs via Talk-it 
> *Inviato:* venerdì 15 febbraio 2019 18:50
> *A:* talk-it@openstreetmap.org
> *Cc:* Alecs
> *Oggetto:* Re: [Talk-it] R: R: R: Tag place
>
> Andrea Musuruane wrote
> >  Tra l'altro se la funzione population->place fosse *iniettiva* non
> > avremmo bisogno del tag place.
>
> Esatto, il nodo della questione è sempre quello, se place dipende così
> rigidamente dalla popolazione, non ha senso di esistere come tag a sè.
> Invece lo ha proprio nella misura in cui l'importanza di un centro abitato
> dipende anche da altro.
>
> Non ci vedo nulla di strano se ad esempio Vipiteno (che fayor ha appena
> cambiato da town a village perchè ha meno di 6 mila abitanti, dopo che per
> anni era stata town https://www.openstreetmap.org/node/64777232/history)
> sia
> più importante di Favaro Veneto (che lo stesso fayor ha promosso a town
> perchè supera di poco i 10 mila
> https://www.openstreetmap.org/node/697239111/history). Il primo è il
> centro
> più importante della sua valle, il secondo è praticamente una propaggine di
> Mestre, difatti i mappatori locali le avevano taggate in modo diverso
> (Favaro Veneto era perfino suburb, ma evidentemente il fatto che in mezzo
> ci
> sia un confine di municipalità cambia tutto). Stesso discorso per Chiavenna
> ad esempio, potrebbe benissimo essere town
> https://www.openstreetmap.org/node/62516647/history
> Non prendiamoci in giro, non stiamo parlando di 20 modifiche, sono decine e
> decine fatte tutte allo stesso modo.
>
> La cosa che proprio non ha senso, e che purtoppo succede spesso, è cambiare
> la classificazione di un centro abitato giusto perchè ha qualche decina di
> abitanti in più o in meno della mitica soglia dei 10 mila, come se da un
> mese all'altro l'importanza di un centro abitato potesse veramente cambiare
> per qualche famiglia che si è trasferita, perchè di questo stiamo parlando.
> Di esempi penso ce ne siano molti, al volo ho trovato questi:
> Verucchio https://www.openstreetmap.org/node/69301805/history
> Vigonovo https://www.openstreetmap.org/node/64778773/history
> San Felice Circeo https://www.openstreetmap.org/node/72961005/history
> Asola https://www.openstreetmap.org/node/62513613/history
> Monteriggioni https://www.openstreetmap.org/node/1123275673/history
> Senza contare che quelli sono gli abitanti del comune, incluse eventuali
> frazioni, e non solo di quel centro abitato.
>
> Però ragazzi, se siamo d'accordo tocca a noi intervenire e modificare, non
> discutere soltanto, altrimenti gli errori rimangono, e soprattutto
> costituiscono un esempio per i nuovi mappatori, che giustamente si adeguano
> a quello che vedono attorno a loro.
>
> Alessandro
>
>
>
> --
> Sent from: