RFC : We need icons to support infographic reports

[felix-yew]

Problem

We will have need icons to support infographics report in a new InaSAFE version release. The icons will represent a hazard, exposure, and/or maybe impact result. Moreover, this icon will support the innovative infographics report style.

Duration

December 2016

Proposers

@felix-yew with input from :
@Charlotte Morgan
@timlinux
@samnawi
@ivanbusthomi

Proposal

I will propose the icon to support the InaSAFE infographic report. The icons come from OCHA Visual Information Unit (UNOCHA). I hope this icon can support to create an infographic that produces from InaSAFE in v.3.5.x and latest. There are will divide in apart based on exposure title.

A. People

This is a people's icon that I propose :

And, an icon to support minimum needs report (based on Perka BNPB no.7/2008) :

B. Structures

This is a structure's icon that I propose :

*) from thenounproject.com by Nicolas Vicent. I use this icon consider the neutral place for pray.

C. Roads

This is a road's icon that I propose :

D. Land cover

This is a land cover icon that I propose :

E. Places

This is a place's icon that I propose :

**) from thenounproject.com

F. Exposure

This is an exposure icon that I propose :

Feel free to discuss, especially the icon come from thenounproject.com maybe we can modify or create a new icon to support the object.

CC

@Charlotte-Morgan
@timlinux
@fredychandra
@samnawi
@ivanbusthomi
@lucernae
@ismailsunni

[Charlotte-Morgan]

Hi @felix-yew - these look good. I think the building looks different to the one we use in InaSAFE?

[Charlotte-Morgan]

@felix-yew - we need to progress this. Lets focus on the population and minimum needs only for now.
I think it would be good to have different icons for women and hygiene packs. Is it possible to find a different icon for the hygiene packs? Once we have the icons agreed - we need to find the svg icons and share them. You need to compile them (only the ones we need now for your template) and I can upload them to the system.
@timlinux @lucernae - this is as discussed yesterday

[timlinux]

Thanks @Charlotte-Morgan

@felix-yew could you prepare these in a standard folder (containing .svg icons plus an accompanying license file for each icon). @Charlotte-Morgan I have been thinking about the discussion we had in JK about adding icons to definitions and I think there is a better way:

For a given definition e.g.:

generic_hazard_classes = {
    'key': 'generic_hazard_classes',
    'name': tr('Generic classes'),

We save the icon using the key name e.g.:

generic_hazard_classes.svg
generic_hazard_classes.license

For minimum needs we will need some special behavior since the needs are defined by the user. Think that we should provide some default icons for rice, water etc. but we would need a more explicit way to link the minimum need to the icon (e.g. adding a property in the minimum needs definition).

[felix-yew]

Hi, @Charlotte-Morgan - thank you for your feedback. That is good, so I can focus to create the population and minimum needs reports.
About the icons for women and hygiene packs, I still don't get the proper icon to support the hygiene packs. Please let me know if there is some suggestion to support the hygiene packs icon, I really appreciate it. And, I will compile the icon in svg and share it.

@timlinux - I will create a note about the icon's source in the shared folder.

[Charlotte-Morgan]

Hi @timlinux - thanks for the feedback.

Can I please confirm a couple of points:

1. I think I understand that we need to use standard file names for icons to match the definitions.
   Does this mean we need to add definitions for all things like adult, youth, elderly etc etc etc?
   Do these belong in concepts.py or can we use fields.py ?

2. What is the format of the licence file?
   I'm guessing it will mention the source and original file name if we are not retaining that in our system.

3. Where should the folder of icons and licence files be put?

My preference would be to retain the original source file names from UNOCHA or Noun Project if we can. but that would mean adding the icon file source to the definition explicitly.

@felix-yew - lets wait for Tim's advice before you compile too many files and we need to change all the names.

cc @ismailsunni

[timlinux]

Hi @felix-yew and @Charlotte-Morgan

So here are my thoughts...

PROS for using definition key based names:

• changing or localising the icons (e.g. different symbol for rice in Japan than in Indonesia) will not need any code changes.
• we could mix icons from different sources yet still have a consistent icon naming scheme.
• cleaner definitions files - we don't need to litter SVG entries around every definition.

CONS for using definition key based names:

• we lose the original source file names
• anything else?

Regarding the other questions from Charlotte:

I think I understand that we need to use standard file names for icons to match the definitions.
Does this mean we need to add definitions for all things like adult, youth, elderly etc etc etc?
Do these belong in concepts.py or can we use fields.py ?

Yes we should define everything but I think that is a good thing. I would say they should go in concepts.py or perhaps a new demography.py (but we can easily move them around after they are created so concepts.py to start).

What is the format of the licence file?

Early on in the project, Ole established a license file format that looks like this:

https://github.com/inasafe/inasafe_data/blob/master/exposure/DKI_buildings.lic

Its going to be a bit of work to create one for each file but it has the advantage that we can automatically test that every icon is properly licensed (we have a make ip_audit test for this), so my first suggestion would be to continue with this approach.

I'm guessing it will mention the source and original file name if we are not retaining that in our system.

Where should the folder of icons and licence files be put?

They should be placed in the resources directory. I think for now placing them under

https://github.com/inasafe/inasafe/tree/develop/resources/img

in a new definitions folder. The folder (which you would need to create) can just contain a long list of files (i.e. I am not suggesting to use subfolder organisation at this point.

[felix-yew]

Hi @Charlotte-Morgan ,

Lets focus on the population and minimum needs only for now.

About the population and minimum needs, I have written the RFC at #3366

Hi @timlinux ,

Thank you for your feedback, a suggestion from you, we will need the patience to prepare it.

Early on in the project, Ole established a license file format that looks like this:
https://github.com/inasafe/inasafe_data/blob/master/exposure/DKI_buildings.lic
Its going to be a bit of work to create one for each file but it has the advantage that we can automatically test that every icon is properly licensed (we have a make ip_audit test for this), so my first suggestion would be to continue with this approach.

According to the licence (*.lic) so if we add new icons to support the new report, like an infographic, we must write the licence in each icon or there is another suggestion about it? After I check the *.lic I see metadata, I need to know about the datafile means, like :

• checksum
• publishable
• accountable
• IP_owner
• IP_info

If the icon is acceptable, maybe I can help to prepare the metadata of the icons image, but I need little training how to prepare and write the licence 😄

[Charlotte-Morgan]

Hi @timlinux - thanks for the advice. Biggest con is it looks like we have a lot of work to do on this, and creating a burden to maintain.

• entry in concepts.py for every parameter we report against
• icon for each
• licence file for each

If all the icons are in one folder, can we make a single license file with records for each icon?

I agree with @felix-yew that the license file format may not have everything we need, and may have things we do not understand. We would want to state:
icon name
original file name
source

The data license file format looks a bit over the top to me.

If however, we just list the icon file in the concepts.py and the source / link it would be 'just another attribute' of the concept. This would be heaps easier to set up.

We are using international icons and symbols so the chance that Japanese rice is different to Indonesian rice is hopefully quite small.

I am prepared to write to UNOCHA to get approval for the icons we plan to use if that helps, we could see if we can get our version 'approved' as having a standard meaning

[timlinux]

Biggest con is it looks like we have a lot of work to do on this, and creating a burden to maintain.

I think the burden is less in my approach. In the one case we have the burden placed in creating lots of image entries in each dictionary so that we can reference it properly by name, in the other we need to rename the images to a standard naming and add some dictionary items.

entry in concepts.py for every parameter we report against

Yes. I think a lot of these will go into the postprocessor definitions for example here: https://github.com/inasafe/inasafe/blob/develop/safe/definitionsv4/post_processors.py#L125

icon for each

Yes. We can start small and add the post processors, key things like hazard and exposure types, and minimum needs (which will probably not fit the above structure yet so we should consult with @ismailsunni , @lucernae and @Gustry for their thoughts on it).

licence file for each
If all the icons are in one folder, can we make a single license file with records for each icon?

Yes - having one file which simply lists all the icons used and their origin is also fine with me. That might reduce the overhead of maintaining separate license files a bit...

I agree with @felix-yew that the license file format may not have everything we need, and may have things we do not understand. We would want to state:
icon name
original file name
source

Also fine for me. My previous post was a suggestion for if we want to keep things consistent, but its not critical for me.

The data license file format looks a bit over the top to me.

:-) No worries lets do something simpler if you prefer.

If however, we just list the icon file in the concepts.py and the source / link it would be 'just another attribute' of the concept. This would be heaps easier to set up.

OK as mentioned above I think there would actually be less work by taking a hybrid of our two approaches: name the files after the keys, maintain a text document listing all the files and their origin ('the license file'). But I also dont mind putting the file name explicitly in the concepts.py if that is what you prefer.

We are using international icons and symbols so the chance that Japanese rice is different to Indonesian rice is hopefully quite small.

Yes it was a contrived example.

I am prepared to write to UNOCHA to get approval for the icons we plan to use if that helps, we could see if we can get our version 'approved' as having a standard meaning

I think they are published under a license which does not require approval to use, though they mention they would like it if projects let them know that they are using them:

"The symbols can be downloaded for free on ReliefWeb and The Noun Project. Whenever possible, credit as follows: “Source: OCHA”. We would appreciate a notification via email with a link to your work for our records. " - http://www.unocha.org/top-stories/all-stories/ocha-launches-500-free-humanitarian-symbols

[timlinux]

(concepts.py and other related definitions I meant to say above)

[Charlotte-Morgan]

@timlinux - can we please discuss this so we are clear on how to progress. See #3473

[felix-yew]

To support the new population analysis in ticket #4069 and it will influence the infographic analysis results of the age, gender, and vulnerability, especially the icon. As the new mock up that I have been shared in here in ticket #3473, the missing icon is child bearing age. I modify this icon that comes from woman icon (UNOCHA). Here is the icon for child bearing age in PNG and SVG format (in zip file).

Woman child bearing age_edit.zip

Let me know if there is still have some missing icon.

[Charlotte-Morgan]

thanks @felix-yew - I can add these and update the license file

[felix-yew]

you're welcome @Charlotte-Morgan

[Charlotte-Morgan]

hi @felix-yew can you please make an icon for child?
Its the same as youth but would be great if you can share the resized one. Thx

[felix-yew]

No worries, I have resized the child icon into 50 px.
PNG format

SVG format (use the online converter)
child.zip

Let me know if the icon is not what you expected, I will correct it.

[felix-yew]

this is for disable icon

disable.zip

[Charlotte-Morgan]

thank you @felix-yew - you are a champion :)

[lucernae]

Note for whoever will implement the icon to the report 😄 (maybe @myarjunar ):

1. It is very recommended to have the icon as True SVG, which means it is a picture defined by svg syntax like graph, lines, etc. Check the svg content, it could be an SVG but on the inside is just base64 formatted png data. Big reason for using true SVG is the flexibility, you can color it, resize and scale programmatically.

2. Sometimes, the SVG size needs to be normalized in order for it to be scaled nicely on html. You have to define the boundary of its viewport, for example to make the whitespace in all sides in equal amount so it will scale uniformly. Set the anchor point to the center so it will scale proportionally in all direction. And then, set the boundary so it will have proper size, for example youth icon needs to be apparently smaller than adult, so you should include more whitespace to the top of the icon to give some extra space. For these tasks, I used free tools called Boxy SVG.

[Charlotte-Morgan]

hi @lucernae - thank you for the great advice.
@felix-yew - please take note of this for the icons we need and get @ivanbusthomi or Kartoza to assist with making true SVG if necessary. Try Boxy SVG :)

[ivanbusthomi]

Hi mas @lucernae ,

It is very recommended to have the icon as True SVG, which means it is a picture defined by svg syntax like graph, lines, etc. Check the svg content, it could be an SVG but on the inside is just base64 formatted png data. Big reason for using true SVG is the flexibility, you can color it, resize and scale programmatically.

So I checked the three files above provided by mas @felix-yew, and I can confirm that the last two files are true svg, while the women with child bearing age are still in a png-inside-an-svg format.
Quick question,does any version of svg works? because I notice that the version is slightly older than the one we already used.

[lucernae]

Quick question,does any version of svg works? because I notice that the version is slightly older than the one we already used.

I haven't tested yet, but I think the version doesn't make so much difference.
If you want to upgrade the version, you can open it in Boxy SVG and save it again.

[felix-yew]

Hi mas @lucernae - I have already use the Boxy SVG to re-save the icon and @ivanbusthomi has tested the SVG and it works properly.

[timlinux]

Can we get an update on the status of this issue @felix-yew ?

[felix-yew]

Yes @timlinux I think we have updated the icon. I think we can close this ticket, but, we can open again if necessary.